Preparing FTL Servers for a Disaster Recovery Site

The first task in arranging disaster recovery for TIBCO FTL is to configure and run FTL servers that parallel the servers at the main site.

Persistence Definitions

1. In the FTL server GUI of a primary server, define persistence clusters with redundant persistence services.
   The set of persistence services consists of two equivalent and parallel subsets:

   • Services at the main site
   • Services at the disaster recovery site
   Select the main site subset as the primary set.
2. Define disaster recovery transports.
   Configure the disaster recovery transport of each persistence service so that every persistence service at the main site can communicate with every persistence service at the disaster recovery site on this transport. That is, enable full mesh connectivity within each persistence cluster. (Nonetheless, only one pair of services at a time connect across the WAN link.)

   In addition to configuring the disaster recovery transports in the realm, it is good practice to verify the configuration of routers, firewalls, and other network infrastructure that connects the two sites.

3. Enable replication of persistence stores.
   Inspect each persistence store definition, and ensure that the Replicated check box is selected.
4. Deploy the realm definition.

Disaster Recovery Servers

5. Configure disaster recovery FTL servers at the disaster recovery site.
   1. Begin by copying the configuration file from the main site, and modify the disaster recovery site configuration as follows.
   2. For each core server, configure the parameter drfor, specifying the URL list of main site core FTL servers as its argument.
   3. If authentication is required, configure the user and password parameters with credentials that the disaster recovery servers can use to authenticate themselves to the primary FTL servers.

      Ensure that this user name is in the authorization group ftl-internal.

6. Start the core servers at the disaster recovery site.
   These FTL servers are affiliated with the primary servers at the main site. If a disaster disables the main site, administrators will restart these disaster recovery FTL servers as the new main core servers.
7. Start the auxiliary servers at the disaster recovery site.
   These FTL servers provide standby persistence services, which mirror the persistence servers at the main site. If a disaster disables the main site, administrators will reconfigure the persistence cluster's primary set so that these persistence services begin to service clients.

Primary Servers

8. Configure the core servers at the main site.
   For each core server, configure the parameter drto, specifying the URL list of disaster recovery core servers as its argument.
9. Start (or restart) the primary FTL servers at the main site, one at a time.
   The lead primary server attempts to connect to the lead disaster recovery server. Upon connection, the disaster recovery server receives the currently deployed realm definition from the primary server.

Satellite Servers

10. Start satellite FTL servers at the disaster recovery sites.
    Arrange a family structure that is parallel to the structure at the main sites.
    For task details, see Configuring Satellite FTL Servers.
11. Ensure that the persistence services are running properly at each site.
    Use the FTL server monitoring GUI to check the state of persistence services.