Page Comparison

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

 DPOD There are multiple methods available to achieve DPOD HA/DR planning and configuration has several ways to be achieved depends . These methods depend 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 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. What The software customer use 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 assist help identify and relaunch DPOD on a different cluster member?

3. Customer The customer is expected to have an Active/Passive software or another mechanism in place to identify when the DPOD server is 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, customer must understand if :

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. Customer must know their Some DataPower architecture solutions (Active/Passive or Active/Active) effect DPOD configuration. ..) and if it is 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

...

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

...

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. Customer have The customer has DataPower appliances in deployed using either an Active/Passive or , Active/Standby or Active/Active configuration. All DataPower appliances in any configuration must of these configurations have unique IP addressaddresses.
2. DPOD will be is installed once and will be configured to monitor all DataPower appliances (active, standby and passive).
3. All DPOD network services (NTP, SMTP, LDAP ..etc) 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 The customer has storage replication capabilities to replicate DPOD disks based on the disks’ replication policy described above.
5. Customer is required to have a  The customer has a 3rd party software tool or scripts that can provide:

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

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

...

During a disaster

...

:

1. Customer The customer's DR software should Identify DPOD failure (for example by ping to IP access UI e.g. by pinging access IP, User Interface URL or both)
2. Customer 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 same as the failed active DPOD.
   
   

DPOD will be available in the following way:

Since
• As 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
• 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. Customer have The customer has DataPower appliances in deployed using either an Active/Passive or Active/Stand-by configuration. All DataPower appliances in any f these configuration must have unique IP addressaddresses.
2. DPOD will be is installed once and will be configured to monitor all DataPower appliances (active, standby and passive).
3. All DPOD network services (NTP, SMTP, LDAP ..etc) 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 The customer has storage replication capabilities to replicate DPOD disks based on the disks’ replication policy described above.
5. Customer is required to have a  The customer has a 3rd party software tool or scripts that can provide:

• • Identify unavailability of the primary DPOD server/s.
  • Launch the passive DPOD servers with different using a different IP address to the active one

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

...

During a disaster

...

:

1. Customer The customer's DR software should Identify DPOD failure (for example by ping to IP access UI failure (e.g. by pinging access IP, User Interface URL or both)
2. Customer The customer's DR Software should launch the passive DPOD server and change its IP address (if not already configured) to be the a different address from to the one used by the failed active DPOD.
3. Customer The customer's DR Software should run execute a commands/script to change DPOD's IP address as described in documentation.
4. Customer The customer's DR Software must change the DNS name for the DPOD server's web console to reference to an actual IP or use an NLB in front of both DPOD web console.
5. DPOD create creates 2 aliases in each configured DataPower. Customer The customer's DR Software should run a script with a SOMA request to change this 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’
• appliances will still be able to access it since their internal host alias
point
• pointing to DPOD will be replaced. (
step
• Step 5 above).
Since
• As all DataPower appliances
will have
• retain the same
IPs than
• 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
by step 4 
• . (Step 4 above).

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

Assumptions:

1. Customer have The customer has DataPower appliances in either an Active/Passive or Active/Standby configuration. All DataPower appliances in any configuration must have unique IP addressaddresses. 
2. Install two Two DPODs are installed, one operates as the active machine and the other one as the standby machine, after . After installing the standby DPOD that is supposed to be standby device, run the makeStandby DR REST API to  was executed to designate it as such.
3. When the DPOD installation is in DR Standby mode, a message will appear next is shown ext to the environment name in the Web Console. A refresh (press F5) may be required to reflect recent changes if you just run the makeStandby API has just been executed, or when the DPOD status has changed DPOD from active to standby or vice versa).
   
   
   
   
4. Both DPODs will need to be 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 to DPOD and it can be consumed from using a script
   Since As both servers are up no replication can exist in this scenario.
5. Specfiically, the customer will need to add 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 using (or by using the Device REST API, setting AP). 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)
   
6. All DPOD network services (NTP, SMTP, LDAP ..etc) must have the same IP address (otherwise a post configuration script is required to be run by the DR software)
7. Customer is required to have The customer has a 3rd party software tool or scripts that can provide:
   • Identify unavailability of the primary DPOD server/s.
   • Launch the passive DPOD servers

...

1. •  using a different IP address to the active one

...

1. The standby DPOD server can still be online

...

1. as disk replication is not required.
2. As no replication takes place, the customer may have the standby DPOD activated (without any data collected by the active DPOD

...

1. ).

...

 During a disaster

...

:

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

...

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

...

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

...