An important certification acquired by Vittoriano Raffaelli during the course held in January in Montpellier by IBM technicians from Rochester, which will allow 01 Informatica Srl to be among the first companies in Europe to be able to install the brand new IBM product called DB2 Mirror. But what is DB2 Mirror?

Db2® Mirror is easy to deploy and adopt. Users and applications are largely unaware that synchronous replication is keeping the two nodes identical. The data on both nodes is available for production use.

You can choose to run your application on one of the nodes, with the other node in active standby mode with live production data ready to use. This is referred to as an active/passive environment. If your business has the requirement for real-time analysis of data, with Db2 Mirror there is an accessible copy of the production data on the second node. You can choose to run your production environment on one of the nodes, while running real-time queries and business intelligence on the second node with no performance impact to the production node.

For load balancing purposes, you can distribute users and applications across the nodes. This is called an active/active environment. Since updates to the replicated data are synchronous, users on both nodes see the same data. Within the IBM® i operating system, locking is implemented across the nodes to ensure the integrity of changes across the nodes. If a node becomes unavailable, users and applications can be redirected to the active node.

In each of these environments, with no application changes, you will see a reduction in production downtime due to outages.

One of the common pain points within a production environment is any outage required to perform system or application maintenance. Db2 Mirror can reduce and, in some cases, eliminate production outages due to planned IPLs and updates. With the ability to temporarily suspend replication, one node can continue processing transactions while the second node is IPLed or maintenance is applied. Once the IPL is complete and communication has been reestablished between the nodes, the changes that were tracked by the active node are pushed to the second node to make the database files identical again. Then the process can be reversed by suspending replication again and IPLing or performing maintenance on the first node.

A similar rolling upgrade strategy can be used to update your server or storage hardware. One node can be upgraded while replication is suspended and production continues on the other node. Replication can be resumed to bring the data up to date on the upgraded node. Then replication can be suspended again to upgrade the second node.

By implementing an architecture that uses an active/active database you can reduce the time to switch over and minimize data loss in an unplanned outage. The Db2 Mirror product helps facilitate that goal within a data center and is compatible with most existing disaster recovery strategies.

Because the data is synchronously replicated between the nodes, the recovery point objective (RPO) and recovery time objective (RTO) for outages can be reduced to near zero. Application changes are not required to see a reduction in production downtime due to outages. Further RTO improvements can be seen if your applications are designed to run in an continuously available environment.

In a Db2® Mirror environment, the data is synchronously replicated between the nodes. The recovery time and recovery point objectives for your users will depend on the application architecture.

The application architecture model shown below is common today. The application is designed to be accessed and run on a specific IBM® i node.

Figure 1. Classic application architecture
Classic application architecture

You can continue to run these applications in either an active/passive or active/active environment. If a node becomes unavailable because of a planned or unplanned outage, users might need to take action to switch to the remaining node. Application state data may need to be included in the replicated data. In this application environment, in addition to the load balancing or business intelligence opportunities available with the synchronous data transfer, Db2 Mirror generally allows for faster switchovers of the application than other high availability solutions since the data is immediately available on the remaining node.

Applications that have been separated into an application and a data layer may be able to exploit Db2 Mirror to achieve an even lower recovery time objective as shown in this figure.

Figure 2. Continuously available applications
Continuously available applications

If your applications already have a separate application layer (running on IBM i or some other platform) and are using a connection technology such as JDBC, your entire application may easily be ready for continuous application availability. The JDBC layer has the ability to have a secondary connection to another node. If the first node is no longer available, the JDBC connection will automatically switch to the secondary node. There are other types of connections that can be considered here as well that have built in failover.

ue to the synchronous design of Db2® Mirror, the distance between the nodes is limited to within a data center for most cases. There are multiple configurations supported, both for a data center Db2 Mirror implementation and for the addition of a disaster recovery solution. Several options are shown in this section as examples. Your specific implementation will depend on your business resilience requirement.

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 configuration very quickly. If you have a disaster recovery strategy to provide storage resiliency 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, at a cost of decreased resiliency.

Figure 1. Basic configuration with one storage server
Basic configuration with one storage server
Source:  IBM Documentation.