Disaster Recovery
You can use the disaster recovery feature to resume FTL communications after the main operations site becomes disabled. Application systems can continue after the interruption using replicated persistence data at a remote disaster recovery site.
The TIBCO_HOME/ftl/<n.n>/samples/yaml directory contains dr and dr-secure samples.
Prepared for Disaster
Figure 61: Servers Providing Realm and Persistence Services Configured for Recovery
The diagram above illustrates a set of FTL servers configured to prepare for recovery from a potential disaster, along with the services they provide and the application processes that they serve. Servers at the main site are on the left (gray). Components at the disaster recovery site are on the right (white).
At each site, each of three core main core servers explicitly provides a realm service and a persistence service. An application can connect to any local core server (blue lines).
Realm services and persistence services synchronize to the state of the local cluster leader. The leader communicates via WAN link, to synchronize the disaster recovery site with the latest realm definition and persistence data.
After Recovery
Figure 62: After Recovery
In the diagram above, a disaster has disabled the main site.
Administrators have manually cut over to the disaster recovery site:
- Administrators promote the disaster recovery FTL servers to primary FTL servers via the REST API.
-
In the realm configuration, Administrators have reconfigured the standby set of persistence services to be the primary set. Disaster recovery replication has been disabled for the persistence cluster.
Applications connect to the primary servers. The disaster recovery site now operates as the new main site.
Administrators can begin to set up another disaster recovery site.