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

 DPOD HA/DR planning and configuration has several ways to be achieved depends on the customer's requirements, implementation and infrastructure.

Important HA\DR considerations

Before deciding on your options of implementing HA/ DR solution with DPOD, you should understand your needs and your infrastructure limitation and be able to answer the following questions after you consult your BCP/DR/System/Network Admin:

 1. DPOD can capture vast amount of data for large installations. If you are going to replicate this to DR this can consume significant network bandwidth or sometimes even 3rd party storage replication license costs.

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

2. What software customer use 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 assist identify and relaunch DPOD on a different cluster member?

3. Customer is expected to have an Active/Passive software or mechanism to identify DPOD server is inactive and launch a new one in an active Cluster member.

Do you have such tool (DR Software)?

4. When launching a new DPOD instance on the backup cluster member, customer must understand if the new launched server is keeping the same network configuration of the primary node (for example : IP Address, DNS, NTP, LDAP, SMTP)  or if this configuration might be changed.

5. Customer must know their DataPower architecture (Active/Passive or Active/Active ...) and if it is an active / passive solution will the passive DataPower will have the same IPs.

If DataPower IP address will be changed than some DPOD configuration will become obsolete and DPOD should reconfigured.

Common scenario of implementing HA\DR scenario of DPOD

Scenario A- Active/Passive - DPOD IP Address is the same

Assumptions:

1. Customer have DataPower appliances in Active/Passive or Active/Standby or Active/Active configuration. All DataPower appliances in any configuration must have unique IP address
2. DPOD will be installed once and will be configured to monitor all DataPower appliances (active, standby and passive).
3. All DPOD network services (NTP, SMTP, LDAP ..) must have the same IP address (otherwise a post configuration script is required to be run by the DR software)
4. Customer must have a storage replication capabilities to replicate DPOD disks based on the disks’ replication policy described above.
5. Customer is required to have a  3rd party software tool or scripts that can provide:

• • Identify unavailability of primary DPOD server/s.
  • Launch the passive DPOD servers with the same IP address

6. The passive DPOD server cannot be up since it must have the same IP address as the active DPOD.

In a disaster scenario:

1. Customer DR software should Identify DPOD failure (for example by ping to IP access UI URL or both)
2. Customer DR Software should launch the passive DPOD server and change its IP address (if not already configured) to be the same as the failed active DPOD.
3. DPOD will be available in the following way:

• • Since the passive DPOD has the same IP all data DataPower appliances will be able to access it and since all
  • Since all DataPower appliances will have the same IPs than 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. Customer have DataPower appliances in Active/Passive or Active/Stand-by. All DataPower appliances in any configuration must have unique IP address
2. DPOD will be installed once and will be configured to monitor all DataPower appliances (active, standby and passive).
3. All DPOD network services (NTP, SMTP, LDAP ..) must have the same IP address (otherwise a post configuration script is required to be run by the DR software)
4. Customer must have a storage replication capabilities to replicate DPOD disks based on the disks’ replication policy described above.
5. Customer is required to have a  3rd party software tool or scripts that can provide:

• • Identify unavailability of primary DPOD server/s.
  • Launch the passive DPOD servers with different IP address

6. The passive DPOD server still cannot be up since disks are required to replicate.

In a disaster scenario:

1. Customer DR software should Identify DPOD failure (for example by ping to IP access UI URL or both)
2. Customer DR Software should launch the passive DPOD server and change its IP address (if not already configured) to be the different address from the failed active DPOD.
3. Customer DR Software should run commands/script to change DPOD IP address as described in documentation.
4. Customer DR Software must change DNS name for DPOD server web console to reference to actual IP or use an NLB in front of both DPOD web console.
5. DPOD create 2 aliases in each configured DataPower. Customer DR Software should run a script with SOMA request to change this aliases to DPOD current IP address and enable and disable all DPOD log targets .(Please refer to 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, all the DataPower appliances’ will be able to access it since their internal host alias point to DPOD will be replaced (step 5)
  • Since all DataPower appliances will have the same IPs than 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 by step 4 

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

Assumptions:

1. Customer have DataPower appliances in Active/Passive or Active/Standby. All DataPower appliances in any configuration must have unique IP address
2. After installing the DPOD that is supposed to be standby device, run the makeStandby DR REST API
3. DPOD will be installed, maintained and configured twice. DPOD will be configured to monitor all DataPower (active, standby and passive) - in v1.0.6.0 a new API was exposed to add a new DataPower to DPOD and it can be consumed from a script
   Since both servers are up no replication can exist.
4. The customer will need to add devices to the standby DPOD and set the agents for each device from the Device Management page in the web console or using the Device REST API, setting up the devices in the standby DPOD will not make any changes on the monitored devices (no log targets, host aliases or configuration changes will be made)
   When the DPOD installation is in DR Standby mode, a message will appear next to the environment name (press F5 to reflect recent changes if you just changed DPOD from active to standby or vice versa)
   
   
   
   
   
5. All DPOD network services (NTP, SMTP, LDAP ..) must have the same IP address (otherwise a post configuration script is required to be run by the DR software)
6. Customer is required to have a 3rd party software tool or scripts that can provide:

• • Identify unavailability of primary DPOD server/s.
  • Launch the passive DPOD servers with different IP address

6. The standby DPOD server can still be online since NO disks are required to be replicated.

7. It is acceptable for a customer to have its standby DPOD activated without any of data collected by the active DPOD since no replication occurs.

 In a disaster scenario:

1. Customer's DR software should Identify DPOD failure (for example by ping to IP, access UI URL, or both)
2. The customer's DR Software should enable the standBy installation by calling a REST API called standbyToActive (see DR REST API reference) - this REST API will point DPOD's log targets and host aliases on the monitored devices to the standby machine.
3. Customer's DR Software must change DNS name for DPOD server web console to reference to 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, all the DataPower appliances’ will be able to access it since their internal host alias points to DPOD will be replaced by the REST API called in step 2
• Since all DataPower appliances will have the same IPs - 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 by step 3
• Note - All Data from the Active DPOD will not be available !

 In a "Return to Normal" scenario:

1. Right after launching the Active installation, run a REST API called standbyToInactive (see DR REST API reference) to disable the StandBy installation  
2. Call a REST API to re-enable the Active installation - activeBackToActive (see DR REST API reference) - this REST API will point DPOD's log targets and host aliases on the monitored devices back to the active DPOD machine
3. Customer's DR Software must change DNS name for DPOD server web console to reference to actual IP or use an NLB in front of both DPOD web console.

Backups

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