Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. The customer has DataPower appliances deployed using either an Active/Passive or Active/Stand-by configuration. All DataPower appliances in any of these configurations have unique IP addresses.
  2. Two DPOD nodes are installed (requires DPOD version 1.0.5.0+), one operates as the Active node and the other one as Standby. After installing the secondary DPOD node, it must be configured to run in Standby state. See "makeStandby" API under DR REST API.
  3. Both DPOD nodes should have the same environment name. The environment name is set by the customer during DPOD software deployment or during upgrade, and is visible in the top navigation bar (circled in red in the image below):



  4. When the DPOD node is in a DR Standby mode, a label is displayed next 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. See the image below:



  5. As both nodes are up, no configuration or data replication can exist in this scenario. The customer is expected to configure each DPOD node as a standalone including all system parameters, security groups / roles/ LDAP parameters/ Certificates, custom reports and reports scheduling, custom alerts and alerts scheduling, maintenance plan and user preferences. DPOD is not performing any configuration synchronization.
  6. Importantly, the customer must add DataPower instances to each installation in order to monitor all DataPower Devices (active, standby and passive). Starting with DPOD v11.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). The customer must add DataPower instances to the standby DPOD node 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 node 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 addresses.
  8. The customer has a 3rd party software tool or scripts that can:
    1. Identify unavailability of the primary DPOD node.
    2. Change the state of the secondary node (that is in standby state) to Active state
  9. The standby DPOD node can still be online as disk replication is not required.
  10. This scenario will not provide High Availability for data. To load data from the Primary node, the customer is required to restore backups taken from primary nodes.
  11. During state transition of the Secondary DPOD from Active back to Standby there might be some data loss.

...

  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 nodes are installed (both are v11.0.5.0+), both running in Active state. 
  3. Both DPOD nodes must have different environment names. The environment name is set by the customer during DPOD software deployment, and is visible at the top navigation bar .
  4. Both DPOD nodes are configured separately to monitor all DataPower Devices (active, standby and passive). Starting with DPOD v11.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 nodes are up, no configuration replication can exist in this scenario.
  5. As both nodes are up, no data replication can exist in this scenario. The customer is expected to configure each DPOD node as a standalone deployment, including all system parameters, security groups / roles/ LDAP parameters / Certificates, custom reports and reports scheduling, custom alerts and alerts scheduling, maintenance plan and user preferences. DPOD is not performing any configuration synchronization.
  6. Importantly, the customer must add DataPower instances to each installation to monitor all DataPower Devices (active, standby and passive). Starting with DPOD v11.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). The customer must add DataPower instances to the standby DPOD node 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 node 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 addresses.
  8. The customer added DataPower devices to the standby DPOD node and set the agents for each device from the Device Management page in the web console (or by using the Devices REST API). The customer is expected to replicate all configurations and definitions for each installation. DPOD replicates neither data nor configurations/definitions.
  9. Important!Since the two installations are completely independent and no data is replicated - data inconsistency may follow, as one may capture information while the other is in Down state for maintenance or even started in different time. This might affect reports and alerts.
  10. Important! - Each DPOD installation will create 2 log targets for each domain. If one DataPower is connected to 2 DPODs - then for each domain you will need 4 log targets. As DataPower have a limitation of ~1000 log targets starting FW 7.6, the customer must take care to not reach the log targets limit.
  11. All logs and information will be sent twice over the network thus network bandwidth will be doubled !

...

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