Configuring the disaster recovery instance

To set up the disaster recovery instance, the ftm/drmode annotation parameter must be set to active or passive.

Use the following instructions to set up the disaster recovery instance of FTM.

Configure and install FTM operators.
Prepare the persistent volumes and other required configuration.
Set up your Db2® database on the disaster recovery site according to the database setup instructions.
When you are provisioning an FTM disaster recovery instance, add the following configuration to your custom resource file:
```
kind: FTM
metadata:
  annotations:
    ftm/drmode: active
```
Ensure all other component configurations match your production configuration such as replica count, memory, CPU, and number of IBM® App Connect independent servers.
Ensure that any customized properties in your primary site are copied over to use the correct information pertinent to your disaster recovery site. The following information must be modified in the customized configuration: Db2 connection string, IBM MQ connection string, and RMI/IIOP entries. Copy the following data from your primary site to the same location in your disaster recovery site.
- User exits. Any user exits that are developed and deployed on your primary site must be copied to your disaster recovery site and deployed. User exits do not change frequently and do not need to be replicated. Establish an operational process on how user exits are copied and deployed to the disaster recovery site.
- Custom user registry. Any user registries that are developed and deployed on your primary site must be copied to your disaster recovery site and deployed. User registries do not change frequently and do not need to be replicated. Establish an operational process on how user registries are copied and deployed to the disaster recovery site.
- Customized configuration files for Gateway, Transaction Server, and Business Rules components. The default configuration files for these components are built into the respective container images. XML files, such as ListenerProfileReference.xml and SchedulerReference.xml that are used by Transaction Server are also part of the Transaction Server image. Establish an operational process on how the customized configuration files are copied over and deployed to the disaster recovery site.
- Customized configuration files for Liberty-based components. The default configuration files for all Liberty-based components are built into the respective container images. If those configuration files are overridden for customization purposes, the modified versions must exist on the disaster recovery site. Establish an operational process on how the customized configuration files are copied over and deployed to the disaster recovery site.
- Check image files. All the image files that were written to the pv-ftm-image-data persistent volume also need to be copied from your primary site to your disaster recovery site.
Ensure that the IBM App Connect pods use the same IBM App Connect topology for the disaster recovery site. This configuration requires the primary and disaster recovery sites to synchronize the pv-ftm-ace-workflows contents and the IBM App Connect section in the custom resource.
After the FTM disaster recovery instance is provisioned, conduct a user acceptance test to validate the system.
Reconfigure the custom resource by changing the ftm/drmode annotation parameter from active to passive to scale down all FTM components on Red Hat® OpenShift®. The status of the FTM instance is set to Ready after the FTM instance is initialized. This status is the same whether FTM is in active or passive mode.
Set up ongoing data updates on the disaster recovery site from the primary site.