Configuring policy-based replication

Policy-based replication helps you to replicate data between systems with minimal management, significantly higher throughput, and reduced latency compared to the asynchronous remote copy function. Use the management GUI or command-line interface to set up policy-based replication between two partnered systems.

Policy-based replication uses volume groups to automatically deploy and manage replication. This feature significantly simplifies configuring, managing, and monitoring replication between two systems. Policy-based replication simplifies asynchronous replication with the following key advantages:

Uses volume groups instead of consistency groups. With volume groups, all volumes are replicated based on the assigned policy.
Simplifies administration by removing the need to manage relationships and change volumes.
Automatically manages provisioning on the remote system.
Supports easier visualization of replication during a site failover.
Automatically notifies you when the recovery point objective (RPO) is exceeded.
Easy-to-understand status and alerts on the overall health of replication.

Policy-based replication supports asynchronous replication between two systems. If you currently use Global Mirror or Global Mirror with change volumes configurations to replicate data between two systems, it is possible to convert to policy-based replication from these configurations. Other remote copy functions, like 3-site partnerships, nondisruptive volume migration, and Metro Mirror cannot be converted to policy-based replication without first converting any relationships to Global Mirror.

Prerequisites

Before you can configure policy-based replication, ensure that the following prerequisites are met.

If you are configuring policy-based replication with IBM Storage Virtualize for Public Cloud on Microsoft Azure, ensure that all planning and installation tasks are complete. For more information, see the following topics:
- Planning an installation on Microsoft Azure
- If you plan to secure the connection between the production and recovery sites with a secured IP partnership, only certain Microsoft Azure regions are supported. For more information, see Planning secured IP partnerships.
- Installing IBM Storage Virtualize for Public Cloud on Microsoft Azure
It is recommended that each system uses a network time protocol (NTP) server to synchronize time between the systems in the partnership. It is possible that the authentication can fail if the time on each system is different.
The certificate issuer can be different for each system in the partnership. The system supports both internally signed certificates and externally signed certificates. Internally signed certificates are issued by the root certificate authority on the system. Externally signed certificates are issued and signed by a trusted, third-party CA. To verify the certificate issuer, log on to each system in the partnership and use the lssystemcert command or select System >Security>System Certificates for the management GUI.
When a partnership is created for policy-based replication in the management GUI, it automatically exchanges the certificates between system and creates a truststore on each of the systems. The GUI simplifies the certificate exchange and management for systems that use policy-based replication. If you are using the command-line interface, you must create a truststore on each system and exchange the certificates. To create certificates and truststore with the command-line interface, complete these steps:
1. When you create a certificate for policy-based replication on IBM Storage Virtualize for Public Cloud with Microsoft Azure, you must specify the local cluster IP address in the -subjectalternativename parameter. For example:
```
chsystemcert -subjectalternativename IP:1.2.3.20 
```
2. Generate and export the certificate from the production system. Use the chsystemcert command to manage certificates. Use the following command to export the certificate:
```
chsystemcert –export
```
  where -export attribute exports the system certificate. The certificate is exported to the /dumps/certificate.pem directory on the configuration system.
3. Copy this certificate from the production system using an SCP client and upload to the remote system.
4. To create the repository to store a collection of certificates, enter the following command:
```
mktruststore -file file_path -name truststore_name -restapi on
```
  where file_path specifies the location of the file to import the certificates, truststore_name specifies the name of the new certificate store, and on specifies the certificates in the store are used for the secured policy-based replication.
5. Follow all preceding steps for creating and storing the certificate from remote system to the production system.
6. Optionally, you can also check the list of current system certificates. Use the lssystemcert command to verify and list the system certificates.

As part of policy-based replication, the management GUI provides an interactive checklist to guide you through all the configuration steps. For example, the checklist provides links to launch directly to the remote system to complete the partnership and pool link configuration steps, and indicates when each step is completed. You can use this interactive checklist when you are configuring policy-based replication for the first time.

The following steps assume that you are configuring policy-based replication for the first time and partnered systems are currently not using the Global Mirror function to replicate data. If you currently replicate data between two partnered systems by using Global Mirror, you can convert the current configuration to policy-based replication. The remote-copy configuration can remain in place for a volume while the volume is configured with policy-based replication, so there is no period without a synchronized copy in place on the DR system. If you use policy-based replication configuration with secured IP partnership to secure connections, you also require an encryption license.