Page Comparison

...

1. The customer has DataPower appliances in either an Active/Passive or Active/Standby configuration. All DataPower appliances in any configuration must have unique IP addresses. 
2. Two DPODs are installed (both are >= v1.0.5), one operates as the active machine and the other one as standby. After installing the standby DPOD device, makeStandby DR REST API was executed to designate it as such.
3. Both DPODs' environment name should be identical, the environment name was entered during the DPOD software deployment, the environment name is visible on the top navigation bar (circled in red in the image below)
   
   
   
   
4. When the DPOD installation is in DR Standby mode, a message is shown ext to the environment name in the Web Console. A refresh (F5) may be required to reflect recent changes if the makeStandby API has just been executed, or when the DPOD status has changed from active to standby or vice versa.
   
   
   
   
5. Both DPODs are configured separately to monitor all DataPower Devices (active, standby and passive) - in v1.0.5 a new API was exposed to add a new DataPower device to DPOD and it can be consumed using a script (see the Devices REST API)
   As both servers are up no replication can exist in this scenario.
6. The customer added devices to the standby DPOD and set the agents for each device from the Device Management page in the web console (or by using the Devices REST API). Setting up the devices in the standby DPOD will not make any changes to the monitored DataPower devices (no log targets, host aliases or configuration changes will be made)
   
7. All DPOD network services (NTP, SMTP, LDAP etc) have the same IP address (otherwise a post configuration script is required to be run by the DR software)
8. The customer has a 3rd party software tool or scripts that can:
   • Identify unavailability of the primary DPOD server/s.
   • Launch the passive DPOD servers using a different IP address to the active one
9. The standby DPOD server can still be online as disk replication is not required.

...

1. The customer's DR software should Identify DPOD failure (e.g. by pinging access IP, User Interface URL or both)
2. The customer's DR Software should enable the stand-by DPOD installation by calling the standbyToActive API (see DR REST API reference). This call will point DPOD's log targets and host aliases on the monitored devices to the standby machine.
3. The customer's DR Software must change the DNS name for the DPOD server's web console to reference an actual IP or use an NLB in front of both DPOD web console.

DPOD will be available in the following way:

• Although the passive DPOD has a different IP address, all the DataPower appliances will still be able to access it since their internal host alias pointing to DPOD will be replaced. (Step 2 above).
• As all DataPower appliances retain the same IP addresses - DPOD can continue to sample them.
• Although the passive DPOD has a different IP, all users can access DPOD’s web console because its DNS name has been changed. (Step 3 above).
• Note - All Data from the originally Active DPOD will not be available! 

 In a "Return to Normal" scenario:

...