DPOD is designed for deployment using either a standalone (All-in-one) or a distributed topology using remote DPOD collectors.

There are 4 basic deployment options for DPOD:

All-In-One with a single network interface
All-In-One with two network interfaces
All-In-One with external self-service web console
All-In-One with remote collector
High availability, resiliency and disaster recovery

Scenario 1: All-In-One with a Single Network Interface

This is the most common deployment scenario. All DPOD components reside on the same appliance (either virtual or physical).

A single network interface is used both for communicating with DataPower Gateway and accessing DPOD Web Console.

This scenario is appropriate for cases in which there are no organizational restrictions on providing users with direct access to DPOD’s IP address.

Scenario 2: All-In-One with Two Network Interfaces

In this deployment scenario, all DPOD components reside on the same appliance (either virtual or physical). To address network and access restrictions, DPOD uses two network interfaces:

Network Interface 1 – for communicating with the DataPower Gateway
Network Interface 2 – for accessing DPOD Web Console

This deployment scenario is appropriate when a separation is required between network access from Web Console users and DataPower Gateway.

Note: It is the System Administrator’s responsibility to configure the second interface and make the proper static routing definitions.

Scenario 3: All-In-One with External Self Service Web Console

In this deployment scenario two DPOD instances are deployed. The first one is the All-In-One, internal instance which is fully operational. The second one is an external Self-Service Web Console that does not store data. It only serves as a UI component, communicating with the internal DPOD instance over HTTP.

This deployment scenario supports both single and dual network interfaces, as specified in the two preceding scenarios.

An organization should consider using this deployment scenario when DPOD users are members of a different network to DPOD itself, or when a separation is required between the user interface and the data stored in the system.

DPOD's External Self Service Console is an additional installation of DPOD. This second installation connects to the primary DPOD and enables developers to still use DPOD while only accessing the external DPOD, and does not require them to access through a more-secure network. This setup allows administrators to prevent unnecessary access to DataPower.

Using this deployment, developers will have access to Investigate.

Scenario 4: All-In-One with Remote Collector (should be replace with Federated Deployment)

This deployment scenario addresses deploying DPOD to monitor geographically dispersed locations. Communication with these locations is performed over WAN, and are susceptible to challenges of limited or unreliable network connectivity. To address this scenario, DPOD provides the ability to deploy instances of DPOD Remote Collector alongside the All-In-One DPOD instance.

A Remote Collector is normally deployed in sites which are geographically separated from DPOD main installation site. A Remote Collector deployed in a site communicates with the DataPower Gateways there using DPOD agents. The data it collects is then sent asynchronously to DPOD main installation site.

This setup is appropriate when the existing DataPower Gateway deployment includes geographically dispersed sites, especially if network access between them is unreliable or limited (e.g. because of bandwidth).

Please see detailed instructions and requirements for the DPOD Remote Collector deployment.

Scenario 5: High Availability, Resiliency and Disaster Recovery

DPOD supports a few HA-DR scenarios. For a list of supported scenarios and detailed explanation please review the section High Availability, Resiliency or Disaster Recovery.

DPOD is not supporting Data Replication as the amount and rate of the new data to be processed is high and the resources required to support the replication are usually found as not cost effective.

DPOD HA-DR capabilities are focus on the HA of the product components without the Store collected data.

Scenario 6: Federated Depolyment

DPOD supports adding multiple DPOD nodes to increase DPOD throuput to capture more data from DataPower Gateways.

Each Federated DPOD enviroment consist of a single cell Manager and multiple Federated Cell Members (FCM).

DPOD FCM's are not replicating any data between themselves, so adding more nodes will not provide any HA / DR capabilities.

After setup a DPOD Federated Enviroment you should bind each GW or Application Domain to only one FCM.

Currently DPOD support up to 7 FCMs.

All DPOD Federated Cell Members can be physical or virtual but all must be completly indetical in terms of CPU, memory storgae type and persistency and physical/virtual).

Browser not supported