Using OADP for API Connect two data center disaster recovery instances

• Make sure that you configure OADP backups for both the active and warm-standby API Connect instances.

• You create OADP backups for API Connect instances with the same procedure you would use for instances that are not deployed by using the two data center topology.

• Restoring a warm-standby API Connect instance from an OADP backup is not supported. However, it is a best practice to configure API Connect backups on the warm-standby instance, so that if it is converted to be the active instance, scheduled backups can run without requiring any further configuration.

• For more information about the API Connect two data center disaster recovery (2DCDR) topology, see Installing a two data center deployment with Cloud Pak for Integration.

To use OADP with a 2DCDR API Connect cluster instance, set these labels:

oc label secret mgmt-encryption-key backup.apiconnect.ibm.com/component=apiconnectcluster
oc label secret ptl-encryption-key backup.apiconnect.ibm.com/component=apiconnectcluster
oc label issuer apic-self-signed backup.apiconnect.ibm.com/component=apiconnectcluster
oc label issuer apic-ingress-issuer backup.apiconnect.ibm.com/component=apiconnectcluster
oc label certificates.cert-manager.io apic-ingress-ca backup.apiconnect.ibm.com/component=apiconnectcluster
oc label certificates.cert-manager.io apic-mgmt-replication-client backup.apiconnect.ibm.com/component=apiconnectcluster
oc label certificates.cert-manager.io apic-ptl-replication-client backup.apiconnect.ibm.com/component=apiconnectcluster
oc label secret apic-mgmt-replication-client backup.apiconnect.ibm.com/component=apiconnectcluster
oc label secret apic-ptl-replication-client backup.apiconnect.ibm.com/component=apiconnectcluster
oc label secret apic-ingress-ca backup.apiconnect.ibm.com/component=apiconnectcluster

The appropriate recovery procedure for a 2DCDR architecture depends on the outage scenario. The table in this section describes recovery steps for various scenarios.

"DC1" refers to the original active data center and "DC2" refers to the original warm-standby data center.

* For scenarios 3 and 4, OADP restore returns a Completed status when successful.

• The warm-standby data center does not complete initialization

• Recovery for the API Portal and the API Manager subsystems does not complete

• Restoring the warm-standby when both data centers are down

For outage scenario 4 in Recovery scenarios, when the original active data center cannot be restored from backup, use the following procedure to restore the warm-standby data center and convert it to active as part of the restore. The following method uses Velero's resource modifiers feature as described in the Velero documentation.

1. Create a file called resource-modifier.yaml and paste in the following contents:

   version: v1
   resourceModifierRules:
   - conditions:
       groupResource: apiconnectclusters.apiconnect.ibm.com
       resourceNameRegex: ".*"
     namespaces:
       - <namespace>
       patches:
       - operation: test
         path: "/spec/management/multiSiteHA/mode"
         value: "passive"
       - operation: replace
         path: "/spec/management/multiSiteHA/mode"
         value: "active"
   - conditions:
       groupResource: 
         managementclusters.management.apiconnect.ibm.com
         resourceNameRegex: ".*"
         namespaces:
         - <namespace>
     patches:
     - operation: test
       path: "/spec/multiSiteHA/mode"
       value: "passive"
     - operation: replace
       path: "/spec/multiSiteHA/mode"
       value: "active"

   Replace <namespace> with the namespace where API Connect is deployed.

2. Create a configmap from this file (resource-modifier.yaml) in the OADP namespace:

   oc -n openshift-adp create cm apic-resource-modifier --from-file resource-modifier.yaml

3. Update the restore.yaml file used to create the OADP restore by adding the resource modifier:

   spec:
     resourceModifier:
       kind: ConfigMap
       name: apic-resource-modifier

4. Create the OADP restore from the restore.yaml file. For a detailed procedure, see "Restoring a backup" in Backing up and restoring IBM Cloud Pak for Integration.

5. Check the status of the API Portal pods as the restore progresses by running this command:

   oc -n <namespace> get pod -l app.kubernetes.io/instance=<api-portal-name> -w

6. When the API Portal pods reach Running state, run the following command to convert the API Portal cluster to active:

   oc -n <namespace> patch apiconnectcluster <api_connect_cluster_name> --type merge --patch '{"spec":{"portal":{"multiSiteHA":{"mode":"active"}}}}'

7. Run the following command periodically until the output displays progressing to active:

   oc -n <namespace> get ptl -o jsonpath={".items[0].status.haMode"}

8. When the message progressing to active is displayed, run the following command to convert the API Portal subsystem to stand-alone:

   oc -n <namespace> patch apiconnectcluster apic --type json -p='  [{"op": "remove", "path": "/spec/portal/multiSiteHA"}]'

9. Wait for the API Portal to reach Ready state. When it reaches Ready state, restore the API Portal database. Create a file named portal-restore.yaml with the following contents:

   apiVersion: portal.apiconnect.ibm.com/v1beta1
   kind: PortalRestore
   metadata:
     generateName: portal-restore-
   spec:
     type: all
     portalCluster: apic-ptl
     timestamp: now