DPOD HA / 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 if it is cost effective to replicate DPOD data or it is acceptable to launch DPOD on backup server with configuration replication only?

1. What software customer use for Active/Passive scenario:
   1. Does your DPOD runs on a virtual infrastructure like VMWare and can you use VMware VMotion or other similar tools that can assist identify and relaunch DPOD on a different cluster member?

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

1. 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 (IP Address, DNS, NTP, LDAP, SMTP) of the primary one or if this will be changed.

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

C.    DPOD disks’ replication policy

1. DPOD has 3 disks:

• Disk 1 – Operating System,
• Disk 2 – Application & Configuration,
• Disk 3 – Data of all monitored Data Power’s transaction and configuration.

1. For launching DPOD server in a replicated environment customer must replicate Disk1 and Disk 2 on a regular basis as they usually have a reasonable rate of changes.
2. Disk 3 can have a lot of IOPS and bandwidth which can be a burden on replication mechanism.
   In cases it is acceptable for customer to launch its passive server without the data, customer can follow this step to create a clean working disk 3:
   1. Customer must create a full back of disk 3 when all DPOD services are down.
   2. Customer must copy the backup of disk 3 to passive DPOD server storage and make sure it is attached to the passive DPOD server.
   3. Customer must start the passive DPOD server and verify that DPOD is fully started and operational.
   4. Customer should delete DPOD data (if exists) using the DPOD web console (Manage -> Internal Health -> Store)
   5. Customer can shut down the secondary DPOD and start the replication for DISK 1 and 2 only.
   6. After each DPOD upgrade it is recommended to rerun this procedure in case directory structure in Disk 3 changed.

D.   common scenario of implementing HA\DR scenario of DPOD

                               i.            Scenario A- Active/Passive - DPOD IP is the same

1. Assumptions:
2. Customer have DataPower appliances in Active/Passive or Active/Stand-by or Active/Active configuration. All DataPower appliances in any configuration must have unique IP address
3. DPOD will be installed once and will be configured to monitor all DataPower appliances (active, standby and passive).
4. 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)
5. Customer must have a storage replication capabilities to replicate DPOD disks based on the disks’ replication policy described below.
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 the same IP address

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

1. In a disaster scenario:
2. Customer DR software should Identify DPOD failure (for example by ping to IP access UI URL or both)
3. 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.
4. 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.

                            ii.            Scenario B- Active/Passive – DPOD IP is changed

1. Assumptions:
2. Customer have DataPower appliances in Active/Passive or Active/Stand-by. All DataPower appliances in any configuration must have unique IP address
3. DPOD will be installed once and will be configured to monitor all DataPower appliances (active, standby and passive).
4. 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)
5. Customer must have a storage replication capabilities to replicate DPOD disks based on the disks’ replication policy described below.
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 the different IP address

1.  The passive DPOD server still cannot be up since disks are required to replicate.
   
   
   1. In a disaster scenario:
   2. Customer DR software should Identify DPOD failure (for example by ping to IP access UI URL or both)
   3. 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.
   4. Customer DR Software should run commands/script to change DPOD IP address as described in documentation.
   5. 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.
   6. 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 .(we expect this step to be removed in future versions)
   7. 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 e)
• 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 d

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

1. 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, maintained and configured twice (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.). DPOD will be configured to monitor all DataPower (active, standby and passive). Since both servers are up no replication can exist.
   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 below.
   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 different IP address

1. The standby DPOD server still can be up since NO disks are required to replicate.
2. It is acceptable for customer to have its standby DPOD to be activated without any of the collected by the active DPOD since no replication occurs.

1. 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 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.
   3. 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 (we expect this step to be removed in future versions)
   4. 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 e)
• 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 d