Page Comparison

...

• 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 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 or it is behind an NLB (step 3 above).
• Note - All Data from the originally Active DPOD will not be available! 

 In a "Return to Normal" scenario:

1. Right after re-launching the primary server, 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 primary DPOD server.
3. 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.

Scenario D: Limited Active/Active – 2 DPOD separate installations

Assumptions:

1. The customer has DataPower appliances deployed using either an Active/Passive , Active/Active or Active/Stand-by configuration. All DataPower appliances in any of these configurations have unique IP addresses.
2. Two DPOD servers are installed (both are v1.0.5.0+), both operate as the active. 
3. Both DPOD servers should have the different 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. 
   Image Added
   
   
5. Both DPOD servers are configured separately to monitor all DataPower Devices (active, standby and passive). Since DPOD v1.0.5.0 a new REST API may be utilized to add a new DataPower device to DPOD without using the UI (see 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). Customer is expected to replicate all configurations and definitions for each installation. DPOD is not replication neither data nor configurations/definitions.
7. All DPOD network services (NTP, SMTP, LDAP etc.) have the different IP addresses .
8. Since the two installations are completely independant and no data is replicated this may lead to data inconsistency as once may capture information while the other is shut down for maintenance.
9. Each DPOD installation will create for each domain 2 log targets. If one DataPower is connected to 2 DPODs than for each domain you will need 4 log targets . As DataPower have a limitation of ~1000 log targets starting FW 7.6 than customer must be aware notreach limitation of log targets
   
   

During a disaster:

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).

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 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 or it is behind an NLB (step 3 above).
• Note - All Data from the originally Active DPOD will not be available! 

 In a "Return to Normal" scenario:

1. Right after re-launching the primary server, 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 primary DPOD server.
3. 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.

Backups

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

...