Persistence Configuration for Disaster Recovery

Any persistence cluster, except the default persistence cluster, can be used for disaster recovery.

To set up disaster recovery for a persistence cluster, you must make the following changes to the FTL realm configuration. See Persistence Cluster Configuration for information on how to use the FTL server GUI to configure DR. Also, refer to the sample realm configurations in the FTL installation.

  • For a given persistence cluster, create two server sets of persistence services. Each server set has a name. See Service Set Level.

    • One set is the primary set, which interacts with client applications at the primary site.

    • The other set is the standby set, which runs at the DR site and receives application data from the primary set.

    • Each set must have the same number of persistence services (usually three).

  • Select a protocol to use for communication between the primary and standby sets. See the DR Protocol field in Advanced Persistence Cluster Configuration.

    • Auto is usually the best choice. The primary and standby sets communicate using the DR host/ports specified in the FTL server yaml configuration file. You do not need to open any additional ports.

      • Caveat: If you are configuring DR for a persistence cluster at a satellite site, you must define a list of externally reachable addresses for each server site. In most cases, for the active site, this is the host/port of each FTL server at the active site, and for the standby site, this is the host/port of each FTL server at the standby site. However, if you have some kind of load balancer or ingress controller between the sites, use its host/port instead. See Externally Reachable Addresses. Also see Disaster Recovery for Routes.

    • Static TCP uses a dedicated port for lower latency. However, you must specify a host and port of each persistence service in both sets. See the DR Host and DR Port fields in the Advanced Persistence Cluster Configuration/ Advanced Persistence Server Properties section. See Advanced Persistence Cluster Configuration and Advanced Persistence Server Properties.

    • If your enterprise requires authentication or TLS, use the secure variants of these protocols (Secure Auto or Secure Static TCP).

  • Enable DR replication in the persistence cluster definition. This instructs the primary set to send application data to the standby set. See the DR Replication field in the Creating a Persistence Cluster section.

  • Determine which set should be the primary set. The value of the primary set field in the persistence cluster definition must be the name of the chosen set. See the Primary Set field in Advanced Persistence Cluster Configuration.

When activating a DR site, you must update the persistence cluster definition so that the value of the primary set field is the name of the standby set. This causes the standby set to activate and become primary. Note that the FTL administration tool can do this automatically, if desired.

Note: If you are not planning to enable DR for a persistence cluster, define only one server set. Do not define two server sets. The presence of a second server set indicates to FTL that DR is in use.

You must also ensure that each persistence store used for application data is configured to be replicated (persistent). Application data in non-replicated (non-persistent) stores is not replicated to the DR site. See Creating a Persistence Store for more information.