|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Request For Enhancement - Hot Backups of DataPower |
« View previous topic :: View next topic » |
Author |
Message
|
PeterPotkay |
Posted: Fri Jul 11, 2014 9:05 am Post subject: Request For Enhancement - Hot Backups of DataPower |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Please vote for this if you think its a good idea.
Even if you are a lost MQ guy that wandered into this DataPower Forum, if you consider this a good idea please vote for it. Imagine that unless you stopped all the queue manager MS03 would occasionally lock up the queue manager, requiring the server to be rebooted to allow any more runmqsc commands to be issued? That is what I am dealing with here with DataPower. PMR concluded "working as designed - open an RFQ".
Bookmarkable URL: http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=56017
Description: We are requesting that DataPower is enhanced to allow the secure-backup command and/or the export command to be run without having to quiesce the appliance first. Customers expect that modern solutions allow for backups of configuration data to be accomplished without an outage.
Should the backup command encounter conditions that preclude a successful backup, the command should end gracefully with an appropriate reason code and not hang the appliance.
Use case: While the commands can be executed currently without first quiescing, we have experienced rare failures where the secure-backup command will hang. Transactions continue to process, but all further commands are ignored in the default domain. The referenced PMR concluded this is working as designed - the hung command necessitating a reboot is not a problem since "best practices" were not followed and the appliance was not quiesced first.
It is not a trivial matter to quiesce an appliance hosting dozens of domains and hundreds of services. Outages are hard to come by. Requesting an outage to take a backup of configurations is seen as a gap in the product by the business community used to giant databases being backed up while they run, to servers being backed up while they run.
We execute our backups via automated scripts on a central server that contacts all our appliances via ssh. The backup script becomes exponentially more complicated if you need to quiesce an appliance with dozens of domains, to wait and verify they are all down, to bring them up and to check that they are all up.
Adding a quiesce is not without risk. The potential exists the unquiesce may encounter issue for one or more domains. In an unattended script that becomes a problem. Yes, we have monitoring, but it takes time to respond to the alerts during which time we are in an unplanned extended outage.
We wish to be able to schedule our secure-backups during periods of low activity on the appliance and not have to take an outage on that appliance, to not have to incur the risk and complexity of quiescing and unquiescing multiple domains. The presumed risk is that the unquiesce runs into trouble and we leave the appliance with one or more domains down.
We wish to be able to run the secure-backup knowing that if it encounters problems, it ends gracefully with an appropriate error code, and doesn't leave us with an appliance that needs to be rebooted.
I appreciate that in a Lab environment its super easy to quiesce the appliance. And/or to reboot it if the command hung. In a production environment, scheduling outages is difficult. Incurring outages on a regular basis to get regular backups is not ideal. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|