Page Comparison

...

DPOD will be available in the following way:

• As the passive DPOD server has the same IP, all DataPower appliances will be able to access it.
• Since all DataPower appliances will have the same IP addresses - DPOD can continue to sample them.
• Since the passive DPOD server has the same IP address as the primary one, access to DPOD console will be with the same URL.

...

1. The customer's DR software should Identify a failure in DPOD primary server (e.g. by pinging access IP, sampling user interface URL or both).
2. The customer's DR software should launch the passive DPOD server using a different IP address than the failed primary server (or change the IP address if not already configured that way).
3. The customer's DR software should execute a command/script to change DPOD's IP address as described in documentation.
4. The customer's DR software should change the DNS name for the DPOD server's web console to reference an actual IP address or use an NLB in front of both DPOD web consoles.
5. The customer's DR software should disable all DPOD log targets, update DPOD host aliases and re-enable all log targets in all DataPower devices. This is done by invoking a REST API to DPOD. See See "refreshAgents" API under Devices REST API, under "Setup all devices' host aliases - for DR").

DPOD will be available in the following way:

• Although the passive DPOD server has a different IP address, all the DataPower appliances will still be able to access it since their internal host aliases pointing to DPOD will be replaced (step 5 above).
• As all DataPower appliances retain the same IP addresses - DPOD can continue to sample them.
• Although the passive DPOD server has a different IP, all users can access DPOD’s web console because its DNS name has been changed or it is behind an NLB (step 4 above).

Scenario C

...

: Active/Standby – 2 DPOD

...

separate installations

Assumptions:

1. The customer has DataPower appliances in deployed using either an Active/Passive or Active/Standby Stand-by configuration. All DataPower appliances in any configuration must of these configurations have unique IP addresses. 
2. Two DPODs DPOD servers are installed (both are >= v1.0.5.0+), one operates as the active machine and the other one as standby. After installing the standby DPOD device, makeStandby server, it was configured as a standby server. See "makeStandby" API under 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 DPOD servers should have the same environment name. The environment name is set by the customer during DPOD software deployment, and is visible at the top navigation bar (circled in red in the image below):
   
   
   
   
4. When the DPOD installation server is in DR Standby mode, a message is shown מext next 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. See the image below:
   
   
   
   
5. Both DPODs DPOD servers are configured separately to monitor all DataPower Devices (active, standby and passive) - in . Since DPOD v1.0.5.0 a new REST API was exposed may be utilized to add a new DataPower device to DPOD and it can be consumed using a script without using the UI (see the Devices REST API)
   . As both servers are up, no configuration replication can exist in this scenario.
6. The customer added DataPower devices to the standby DPOD server 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 server 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 addresses even after failover (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 a passive DPOD serversserver using a different IP address to than the active primary one.
9. The standby DPOD server can still be online as disk replication is not required.

 During During a disaster:

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

DPOD will be available in the following way:

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

...

1. Right after re-launching the Active installationprimary server, execute the following REST API call: standbyToInactive (see DR REST API reference) to disable the Stand-by installation.Execute a call to the following REST API to re-enable the Active installation: activeBackToActive (see DR REST API reference) - this call call the "standbyToInactive" API (see DR REST API) to disable the standby server.
2. Call the "activeBackToActive" API (see DR REST API) to re-enable the primary server - this will point DPOD's log targets and host aliases on the monitored devices back to the active primary DPOD machineserver.
3. The customer's DR Software must software should change the DNS name for the DPOD server's web console to reference an actual IP address or use an NLB in front of both DPOD web consoleconsoles.

Backups

 To improve product recovery, an administrator should perform regular backups as described in the backup section.