Data center architecture
Due to the synchronous replication architecture used by Db2® Mirror, a high-speed network connection is required, which limits the maximum distance
between the nodes. 
Some of the supported high-speed network protocols are non-routable or do not encrypt the data sent over the wire between the two nodes. Choosing to use high-speed network adapters that support encryption provides an implementation where Db2 Mirror replication is both secure and can be physically separated by up to 10 kilometers. 
There are
multiple configurations supported and several options are shown in this section as examples. Your
specific implementation will depend on your business resilience and disaster recovery
requirements.
Db2 Mirror environment with one storage server
Using one storage server is a basic configuration for using Db2 Mirror. From a setup perspective, this has some advantages. When you use one storage server you can take advantage of FlashCopy® to set up your environment very quickly. If you have a disaster recovery strategy that provides storage resiliency, then this might be a configuration to consider. You can choose to reduce your hardware footprint further by implementing Db2 Mirror across two LPARs on the same Power® server, but at a cost of decreased resiliency.
Basic environment with two storage servers
Using multiple storage servers provides additional redundancy by helping to ensure that the active node remains running and available during a storage outage. With two storage servers, remote copy technologies will be used instead of FlashCopy to set up Db2 Mirror. Multiple HMCs provide an additional layer of redundancy and are fully supported by the Db2 Mirror setup process.
Db2 Mirror between data centers
The nodes can be physically located within different data centers, up to 10 kilometers apart, depending on the type of adapters and network topology in the environment. Using an encrypted protocol is recommended to protect the data as it is being synchronously replicated between the nodes.
Db2 Mirror and disaster recovery considerations
Db2 Mirror is a continuous availability solution. It is not to be considered a disaster recovery (DR) solution. Db2 Mirror can be used within your DR strategy to greatly improve your availability even within a disaster situation.
The following figure is an example of one way that Db2 Mirror can be configured to include disaster recovery.
In the figure above, on the left, is a pair of continuously available Db2 Mirror nodes. The maximum distance between the nodes is
between 200 meters and 10 kilometers, depending on the type of adapters and network topology in the
environment.
In the figure above, on the right, is a disaster recovery site. You have options for disaster recovery solutions at this site. You might have a single Power server that may or may not have another Db2 Mirror pair, or you might have another Db2 Mirror pair using multiple Power servers and multiple storage servers. Regardless of which disaster recovery solution you choose, both production nodes must be replicated to the disaster recovery site for a complete solution.
The communication between the continuous availability site (left) and the disaster recovery site (right) can be achieved using various technologies such as PowerHA® Metro/Global Mirror with IASPs, full system replication, or one of the many logical replication solutions that are on the market.
Additional disaster recovery options
Using a mirrored pair within the disaster recovery site provides additional protection in the event you are required to role swap to the DR site. With this type of configuration, you have a continuously available environment even at your DR site.
The next figure shows a topology that includes multiple Power servers in both the continuously available primary data center as well as a continuously available solution in the disaster recovery site.
The next two figures show configurations that provide additional redundancy with multiple Power servers as well as multiple storage servers.
Db2 Mirror can also support DR configurations that use logical replication as shown below. Check with your logical replication vendor for supported configurations.
