Secure restore for WebSphere DataPower SOA Appliances

This article describes best practices for the secure restore function for WebSphere DataPower SOA Appliances, focusing on activities immediately after restoring an appliance.

Joseph E. Furbee (jefurbee@us.ibm.com), Software Test Specialist, IBM Software Services for WebSphere, IBM

Photo of Joe FurbeeJoe Furbee is a Software Test Specialist with IBM Software Services for WebSphere. He has testing experience with WebSphere middleware, SOA implementations, CRM Siebel, and education software. While working on WebSphere DataPower SOA Appliances, he has been involved in multi-box management, zSystem enterprise integration, and special customer issues.



John J. Majikes (majikesj@us.ibm.com ), Senor Software Engineer, WebSphere DataPower Team, IBM

Photo of John MajikesJohn Majikes is a Senor Software Engineer on the WebSphere DataPower Team. He has worked on various mainframe hardware, marketing, and software development projects. John is currently pursing a Ph.D. in Software Engineering at North Carolina State University.



30 May 2012 (First published 30 June 2010)

Also available in Russian

Introduction

The Disaster Recovery Mode function secure-restore in IBM® WebSphere® DataPower® enables administrators to restore an appliance with the backup previously created by a secure-backup. Both secure-backup and secure-restore were new with 3.8.1. The secure-restore function executes on an appliance that has a valid network configuration and storage definition. But the secure-restore overwrites this valid configuration information with the restored backup files and then reboots the appliance. Before placing the device into service it is best practice to verify some configuration information restored from the backup.

Passwords

Generally, appliance backups are done automatically. After a secure-restore, user and administrator passwords are set to their value at the time of the secure-backup.

People might not know what their passwords were at the time the backup was done, and the backup data would be useless if no administrator knows their password and could not log on to manage the device. Therefore, when the secure-restore is done, the administrator id admin has its password reset to admin. All other user ids and passwords are restored to the backup values.

The administrator should immediately log in using the admin id, which will require the default password to be changed. Then the admin id can be used to reset any user or administrator password on the appliance. A list of user ids defined on the appliance can be used to proactively warn users that their passwords have been changed. From the Command Line Interface (CLI) enter co; show usernames, or from the Web GUI click Administration => Manage User Account to get the list of user ids defined on the appliance.

Figure 1. Web GUI list of users defined on an appliance
Web GUI list of users defined on an appliance

Network configuration

If the secure-restore is done on the same appliance in the same network where the secure-backup was done, and if no network changes have occurred since the backup, then the network configuration after the secure-restore will not require any modification. However, if any network changes occurred after the backup was done, or if the secure-restore was done on a different appliance, the network configuration will need to be changed. For example, if the secure-restore is done in a test area or otherwise physically secure location, then after the restore reboots the appliance, the network configuration will be incorrect for the test area location.

Therefore the administrator should immediately log into the CLI via the serial port or SSH (Secure Shell) and confirm that the network configuration is correct for the location of the appliance. This confirmation should include at least a show interface and show name-server command. To view the network interface from the CLI enter co; show interface, or from the Web GUI click Network => Interface => Ethernet Interface.

Figure 2. Ethernet interfaces defined to an appliance
Ethernet interfaces defined to an appliance

RAID Devices

A secure-restore requires that the appliance have at least as much storage as the backed-up appliance. However if the restore is being done to upgrade an appliance at end of life or after a disaster, the replacement appliance will most likely have a larger storage capacity than the the backed-up appliance. In the case of a larger RAID device, the restored configuration might include information that contradicts the new appliance’s configuration. The administrator should verify the configuration data by browsing some files on the RAID device.

For an installation that had an existing backup and restore method for data on the RAID device, the secure-backup might have been done without a backup of the RAID device data. In this case, the backed-up configuration includes definitions for a RAID device but it does not include the RAID data itself, which could result in a RAID device that needs to be reconfigured and then have the RAID data restored using the existing restore method.

The administrator should immediately log in to the appliance to browse some data on the RAID device to confirm that the RAID device is configured correctly. To view the directory name used for the RAID device from the CLI enter co; show raid-volume, or from the Web GUI click Objects => System Settings => Hard Disk Array. Figure 3 shows a RAID directory name of myraid. To view files on the RAID device from the CLI, enter co; dir local:///myraid, or from the Web GUI click Control Panel => File Management => local: => myraid.

Figure 3. Web GUI view of the hard disk array
Web GUI view of the hard disk array
Figure 4. Web GUI view of RAID file names
Web GUI view of RAID file names

iSCSI Devices

If multiple iSCSI volumes exist on an appliance, the secure-restore assumes that the volumes are configured identically to the backed-up appliance. If there is a mismatch in the iSCSI volume configuration, the secure-restore will restore the data to the wrong iSCSI volume, reboot the appliance, and use the previous iSCSI configuration information, which will point to iSCSI volumes that weren't restored.

For example, if two iSCSI volumes Logical Unit Number (LUN) 0 and LUN 1 are configured on the appliance being backed up, but the secure-restore was done on an appliance with LUN 1 and 2, then the data would be restored to iSCSI volumes LUN 1 and 2 but the rebooted appliance would point to iSCSI volumes LUN 0 and 1.

The administrator should immediately log in to the appliance to browse some data on the iSCSI device to confirm that the iSCSI volumes are configured correctly. To view the directory name of each iSCSI volume from the CLI, enter co; show iscsi-volume, or from the Web GUI click Object => Network Settings => iSCSI Volume. Clicking on each volume name shows the mount point directory name -- similar to RAID devices, as shown in Figure 3 above. In this case myiscsi-0 and myiscsi-1 are the directory mount points, as shown in Figure 4 above.

Figure 5. iSCSI volume listing
iSCSI volume listing

TAM Configuration

If the customer is running the TAM libraries and has at least one TAM object configured, it's possible for them to run into issues with the SSL keystore if multiple devices are using the same files. The TAM configuration file, keystore and password stash file should be unique for each object. Here are a few scenarios where a customer could see problems:

  1. If after the restore both appliances are up and a TAM object on one of the appliances refreshes the keystore file, the corresponding object on the other appliance will fail to transition up from the down state because the SSL key will no longer match with the version on the policy server.
  2. If the new device's hostname is different from the old device, and a TAM object on the new device attempts to automatically refresh the keystore, the refresh may fail because the DN configured for the object will not match the device's hostname.
  3. If a TAM object on the original device refreshed the keystore or password stash file after the secure backup was created, the object will not come up after it is restored. This can affect both the cases where the restore occurs on the same device or a different device.

In all cases, the best practice is to generate a unique set of files (config, keystore and stash) for each TAM object.

WebSphere MQ

MQ messages are consumed either in destructive mode (the default) or in 'browse' mode. The default, destructive, mode causes each message to be de-queued as it is read. So, if the DP appliances are doing their MQ business this way, then each appliance will see roughly half the messages that arrive on the queue.

The other mode (called browsing the queue), lets the application (DP appliance in this case) see the messages, but does not de-queue them. If two applications (or appliances) are browsing the same queue, each will see all the messages on that queue.

In either case, the best practice is to review the resulting post-restore MQ configuration objects and adjust according to desired behavior.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=499052
ArticleTitle=Secure restore for WebSphere DataPower SOA Appliances
publish-date=05302012