Migrating to Another Active Site

You can use the disaster recovery feature to migrate FTL operations to a different site, even though no disaster has occurred.

This task illustrates how you can temporarily use the disaster recovery feature to facilitate moving FTL operations to a new geographical location. (This process does not result in actual protection from a disaster.)

Note: This task requires that you are not already using the disaster recovery feature for its usual purpose.
This task uses the following terminology:
SitePrev (the Previous site)
The site that currently hosts FTL operations, the site from which you are migrating FTL operations.
SiteNew (the New site)
A site that you designate as the new active site, the site to which you are migrating FTL operations.
The many steps of this task follow this broad outline:
  • Arrange SiteNew as a temporary disaster recovery backup for SitePrev.
  • Allow time for SiteNew to automatically copy data from SitePrev.
  • Disable SitePrev, leaving all operations at SiteNew. (This step simulates a disaster, prompting migration to SiteNew.)
  • Clean up, deleting the disaster recovery configuration.
Complete these task steps during scheduled maintenance time so that enterprise-critical operations are not affected.

Procedure

  1. Define the persistence services you intend to deploy at SiteNew.
    In the FTL server GUI persistence clusters grid, define a second service set for the cluster, and define new persistence services in it.

    Deploy the updated realm definition.

  2. Copy the FTL server configuration file from SitePrev to SiteNew.
    Make a reference copy of the SitePrev configuration file.
  3. Modify your working copy of the SitePrev configuration file.
    Configure the drto parameter for each SitePrev core server to contain a list of the SiteNew core servers.
    In this example, bold type indicates modifications to the existing SitePrev configuration file: 
    globals:

    core.servers:
        ftl1:  host1:8585
        ftl2:  host2:8585
        ftl3:  host3:8585

servers:

    # Core servers with realm services
    ftl1:
        drto: >
            http://host-new1:8585
            |http://host-new2:8585
            |http://host-new3:8585
        - realm:
            data: /myhome/ftlserver/data

    ftl2:
        drto: >
            http://host-new1:8585
            |http://host-new2:8585
            |http://host-new3:8585
        - realm:
            data: /myhome/ftlserver/data

    ftl3:
        drto: >
            http://host-new1:8585
            |http://host-new2:8585
            |http://host-new3:8585
        - realm:
            data: /myhome/ftlserver/data

  # Auxiliary servers with persistence services
    ftl4:
        - persistence:
            name: psvc4  #Psvc numbering is parallel to aux server names.

    ftl5:
        - persistence:
            name: psvc5

    ftl6:
        - persistence:
            name: psvc6
  4. Modify the SiteNew configuration file.
    1. In the core.servers parameter and in the servers section, replace the SitePrev core servers with the SiteNew core servers.
    2. Configure the drfor parameter for each SiteNew server so it contains a list of the SitePrev core servers.
    3. Configure a realm service for each SiteNew core server.
    4. Configure a persistence service for each SiteNew auxiliary server.
      For each auxiliary server, specify a unique service name that you defined in step 1.
    5. If authentication is required, configure the user and password parameters, with credentials that the SiteNew primary servers can use to authenticate themselves to affiliated servers.
      Ensure that the user name is in the authorization group ftl-internal.
    6. Duplicate the other relevant persistence parameters from SitePrev servers to SiteNew servers.
    In this example, bold type indicates modifications to the existing SiteNew configuration file (which was a copy of the original SitePrev configuration file): 
    globals:

    core.servers:
        ftl-new1:  host-new1:8585
        ftl-new2:  host-new2:8585
        ftl-new3:  host-new3:8585

servers:

    # SiteNew core servers with realm services
    ftl-new1:
        drfor: >
            http://host1:8585
            |http://host2:8585
            |http://host3:8585
        - realm:
            data: /myhome/ftlserver/data

    ftl-new2:
        drfor: >
            http://host1:8585
            |http://host2:8585
            |http://host3:8585
        - realm:
            data: /myhome/ftlserver/data

    ftl-new3:
        drfor: >
            http://host1:8585
            |http://host2:8585
            |http://host3:8585
        - realm:
            data: /myhome/ftlserver/data

    #SiteNew auxiliary servers with persistence services
    ftl-new4:
        - persistence:
            name: psvc-new4  #Numbering follows aux server names.

    ftl-new5:
        - persistence:
            name: psvc-new5

    ftl-new6:
        - persistence:
            name: psvc-new6
  5. Stop and restart the core servers (with realm services) at SitePrev, one at a time.
    After restarting each server, and before restarting the next server, wait until the status of the restarted server becomes Running.
    Each FTL server will read the updated configuration file when it restarts.
  6. Stop and restart the auxiliary servers (with persistence services) at SitePrev, one at a time.
    After restarting each server, and before restarting the next server, wait until both the server and the persistence cluster to reach equilibrium:
    • Wait until the status of the restarted server becomes Running.
    • Wait until the status of the persistence cluster becomes Running.
    Each FTL server will read the updated configuration file when it restarts.
  7. Start disaster recovery FTL servers at SiteNew.
    1. First start the SiteNew core servers (with realm services).
    2. Then start the SiteNew auxiliary servers (with persistence services).
    At this point you have arranged SiteNew as a temporary disaster recovery backup for SitePrev.
  8. Stop all publishing activity at SitePrev, and wait for the persistence services to finish replicating the data.
    Gracefully stop all client applications at SitePrev.
    In the persistence clusters status table and its services list sub-tables, compare the history values of all the services at both sites. When they all match, replication of persistence data is complete.
    At this point the disaster recovery mechanism has copied data from SitePrev to SiteNew.
  9. Stop all FTL servers at SitePrev.
    At this point you have disabled SitePrev, leaving all FTL operations at SiteNew.
  10. Make another reference copy of the SiteNew configuration file.
  11. Modify your working copy of the SiteNew configuration file to eliminate the temporary use of the disaster recovery feature.
    Delete the drfor parameter from each SiteNew server, so they become primary FTL servers. For example: 
    globals:

    core.servers:
        ftl-new1:  host-new1:8585
        ftl-new2:  host-new2:8585
        ftl-new3:  host-new3:8585

servers:

  # SiteNew core servers with realm services
    ftl-new1:
        - realm:
            data: /myhome/ftlserver/data

    ftl-new2:
        - realm:
            data: /myhome/ftlserver/data

    ftl-new3:
        - realm:
            data: /myhome/ftlserver/data

    #SiteNew auxiliary servers with persistence services
    ftl-new4:
        - persistence:
            name: psvc-new4  #Numbering follows aux server names.

    ftl-new5:
        - persistence:
            name psvc-new5

    ftl-new6:
        - persistence:
            name psvc-new6
  12. Stop and restart the core servers at SiteNew, one at a time.
    Each FTL server will read the updated configuration file when it restarts.
    After restarting each server, and before restarting the next server, wait until the status of the restarted server becomes Running.
  13. Toggle the persistence primary set to SiteNew.
    1. Using the browser GUI of a primary FTL server at SiteNew, navigate to the clusters grid, and ensure that the Primary Set column is visible.
    2. Change the primary set of the persistence cluster so that the persistence services at the SiteNew will become the primary set.
    3. Delete the persistence services at SitePrev from the persistence cluster.
    4. Delete the (now empty) service set that contained the defunct persistence services at SitePrev.
    5. Deploy the new realm definition.
    6. Wait until the status of every FTL server becomes Running.
    7. Wait until the status of the persistence cluster becomes Running.
  14. Direct application clients to FTL servers at SiteNew.
    Start application clients at SiteNew. Explicitly supply the host and port locations of FTL servers at SiteNew.
    SiteNew is now the active site of FTL operations.