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:

1. All-In-One with a single network interface
2. All-In-One with two network interfaces
3. All-In-One with external self service console
4. All-In-One with remote collector
5. High availability, resiliency and disaster recovery
   
   TODO HK: replace all pictures - rename IDOD to DPOD

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 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 is an external Self Service 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.

The DPOD 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 they 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 DPOD Remote Collector

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 the DPOD Remote Collector alongside the All-In-One DPOD instance.

A Remote Collector is normally deployed in sites which are geographically separated from the DPOD main installation. 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 the DPOD main installation.

This setup is appropriate when the existing DataPower 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 can support few HA-DR scenarios. For a list and detail explanation please review the section High Availability, Resiliency or Disaster Recovery

TODO HK - add HA Scenario details