TODO - ADD Active/Active - full duplication scenario

TODO - fully explain Active / standby scenario and api process - step by step

DPOD  High Availability(HA), Resiliency or Disaster Recovery(DR) Implementation

There are multiple methods available to achieve DPOD HA/DR planning and configuration. These methods depend on the customer's requirements, implementation and infrastructure.

Important HA\DR considerations

Consult your BCP/DR/System/Network Admin and address the following questions before selecting the method(s) of HA/DR implementation with DPOD to use:

 1. For large installations, DPOD can capture vast volumes of data. Replicating that much data to for DR purposes may consume significant network bandwidth, and may incur 3rd party storage replication license costs.

You should consult and decide: Is it cost effective to replicate DPOD data or it is acceptable to launch DPOD on a backup server with configuration replication only?

2. The software used for Active/Passive scenario:

Does your DPOD runs on a virtual infrastructure like VMWare or can you use VMware VMotion or Active\Passive Cluster management tools that can help identify and relaunch DPOD on a different cluster member?

3. The customer is expected to have an Active/Passive software or another mechanism in place to identify when the DPOD server becomes inactive and launch a new one in an active Cluster member.

Do you have such a tool (DR Software)?

4. When launching a new DPOD instance on the backup cluster member:

Will the new server keep the same network configuration of the primary node (for example : IP Address, DNS, NTP, LDAP, SMTP)  or will the configuration change?

5.Some DataPower architecture solutions (Active/Passive or Active/Active) effect DPOD configuration. If the DataPower IP address changes - then your DPOD configuration may need to change.

Does your DataPower architecture use an active/passive deployment? If so - will the passive DataPower have the same IP addresses when it switches to active?

Common scenarios for implementing DPOD HA/DR

Scenario A- Active/Passive - DPOD's IP Address remains the same

Assumptions:

1. The customer has DataPower appliances deployed using either an Active/Passive, Active/Standby or Active/Active configuration. All DataPower appliances in any of these configurations have unique IP addresses.
2. DPOD is installed once and configured to monitor all DataPower appliances (active, standby and passive).
3. 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)
4. The customer has storage replication capabilities to replicate DPOD disks based on the disks’ replication policy described above.
5. 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 the same IP address as the active one.

6. The passive DPOD server is not up (since in this scenario it has the same IP address as the active DPOD).

During a disaster:

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 launch the passive DPOD server and change its IP address (if not already configured) to be identical to the failed active DPOD.
   
   

DPOD will be available in the following way:

• As the passive DPOD 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 has the same IP, access to DPOD console will be with the same URL.

Scenario B- Active/Passive – DPOD's IP Address is changed

Assumptions:

1. The customer has DataPower appliances deployed using either an Active/Passive or Active/Stand-by configuration. All DataPower appliances in any f these configuration must have unique IP addresses.
2. DPOD is installed once and configured to monitor all DataPower appliances (active, standby and passive).
3. 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)
4. The customer has storage replication capabilities to replicate DPOD disks based on the disks’ replication policy described above.
5. 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

6. The passive DPOD server is not up since disks replication is required.

During a disaster:

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 launch the passive DPOD server and change its IP address (if not already configured) to be a different address to the one used by the failed active DPOD.
3. The customer's DR Software should execute a commands/script to change DPOD's IP address as described in documentation.
4. 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.
5. DPOD creates 2 aliases in each configured DataPower. The customer's DR Software should run a script with a SOMA request to change the aliases to DPOD current IP address and enable and disable all DPOD log targets .(Please refer to the Devices REST API for API named - Setup all devices' host aliases -For DR )

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 5 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 4 above).

Scenario C- Active/Standby – 2 DPOD separated installation.

Assumptions:

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

 During a disaster:

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:

1. Right after re-launching the Active installation, execute the following REST API call: standbyToInactive (see DR REST API reference) to disable the Stand-by installation.
2. Execute a call to the following REST API to re-enable the Active installation: activeBackToActive (see DR REST API reference) - this call will point DPOD's log targets and host aliases on the monitored devices back to the active DPOD 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.

Backups

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