D: Migrating Bridge and eFTL Services

You can migrate from Release 5.4 transport bridge processes to Release 6.x FTL servers that provide bridge services. Similarly, you can migrate from Release 3.4 eFTL servers to Release 6.x FTL servers that provide eFTL services. This task leverages fault tolerance and interoperability to migrate without interrupting service to clients. Complete this task.

1. Designate host computers where FTL servers will provide bridge services.
   You can keep these 6.x services on their former 5.4 hosts, or consolidate these services into existing 6.x FTL servers (that you arranged in earlier migration phases) or designate new hosts for these services.

   If you move services to different hosts, consider FTL 5.4 performance history to ensure adequate processing cycles, memory, and I/O bandwidth.

   You may continue to provide the same number of bridge services, or you may increase that number for greater fault tolerance.

2. Designate host computers where FTL servers will provide eFTL services.
   Keep these 6.x services on their former 3.4 hosts for simplicity and convenience.

   Note: It is important to keep eFTL services on their former host computers (from eFTL 3.4), so that clients can connect to them at the same URLs.

   You may also increase the number of eFTL services for greater capacity.

3. Install FTL Release 6.x on all relevant hosts.
4. Install eFTL Release 6.x on all relevant hosts.
5. Make a reference copy of the FTL server configuration file from the previous stage.
6. Modify your working copy of the FTL server configuration file to include the relevant bridge services and eFTL services (6.x).
   For each additional FTL server, add an auxiliary server section.
   Add bridge sections and eftl sections to the FTL servers that you designated in step 1. For example:

   globals:
   
       core.servers:
           ftl1: host1:8080 # 5.x client port
           ftl2: host2:8080 # 5.x client port
           ftl3: host3:8585
   
   servers:
   
       ftl1:
           - realm:
               data: /myhome/ftlserver/data
           - persistence:
               name: psvc1
           - bridge:
               names:
                 - bridgeA
                 - bridgeB
   
       ftl2:
           - realm:
               data: /myhome/ftlserver/data
           - persistence:
               name: psvc2
           - eftl: {}
   
       ftl3:
           - realm:
               data: /myhome/ftlserver/data
           - persistence:
               name: psvc3
   
       ftl4:
           - ftl:
               server: bridge-host4:8585
           - bridge:
               names:
                 - bridgeA
                 - bridgeB
   
       ftl5:
           - ftl:
               server: bridge-host5:8585
           - bridge:
               names:
                 - bridgeA
                 - bridgeB
   
       ftl6:
           - ftl:
               server: eftl-host6:9191
           - eftl: {}
   
       ftl7:
           - ftl:
               server: eftl-host7:9191
           - eftl: {}

   Important: Define these additional FTL servers as auxiliary servers. That is, define their host and port values in the servers section, but do not add them to the core.servers map.
   Incorporate the other relevant command line arguments into the new parameter sections in the configuration file.

   During migration of eFTL servers, old eFTL clients using the eFTL 3.x library connect to the replacement eFTL services (6.x) at their old (3.x) addresses (for example, eftl-host6:9191). Configure the auxiliary servers that provide eFTL services with the old URLs for backward compatibility.

7. Repeat these substeps on each FTL server host.
   1. If a transport bridge process (5.4) is running on the host, stop the bridge process.
   2. If an eFTL server (3.4) is running on the host, stop the eFTL server.
   3. If an existing FTL server (6.x) is running on the host, stop the FTL server.
   4. Start an FTL server (6.x) on the host.
      The FTL server reads its modified configuration file and provides the specified services.
   5. Verify the status of those services in the monitoring GUI of the FTL server.
   6. Verify client status in the monitoring GUI of the FTL server.
   7. If the FTL server provides a persistence service, verify the quorum state.
   8. Repeat for the next FTL server host.
   At this point, all FTL services are running, and they provide all the new bridge services and eFTL services.
8. Stop any remaining old transport bridge processes (5.4).