Integrating IBM Traveler servers into a High Availability (HA) pool

Existing IBM Traveler servers can be integrated into a High Availability pool.

All synchronization and administration data is automatically transferred to the HA pool database. This process is useful for consolidating an existing set of servers into a single HA pool, as well as moving off servers or transitioning to a different OS. For example, Windows 32-bit servers are not supported in a High Availability pool. However, it is possible to configure a IBM Traveler server running on a Windows 32-bit server to join an HA pool, regardless of the OS of the servers in the pool. The server data is automatically transferred to the HA pool database and then the Windows 32-bit server can be removed from the configuration and decommissioned.

Integration considerations

  • During the transfer of data from the internal database to the enterprise database, the server is unable to serve devices requests. This transfer process can take several hours, depending on the amount of data and on the network speed between the IBM Traveler server and the DB server. The two servers should not be geographically far apart.
  • IBM Traveler clients do not support changing the server address after provisioning. This means that to support the integration of existing servers with existing clients, the existing server address must be aliased to the front end address for the HA pool.
  • Once a server has been configured for an HA pool, the original internal database data is removed. It is possible to reconfigure an HA server as a standalone server, however, any device that connects to the now standalone server is treated as a new device and had to resync data.
  • If leaving the server in the pool, be sure to setup SSL in a similar manner for all servers in the pool. When possible, use the same SSL certificate for all IBM Traveler servers in the pool, for example: *.mycompany.com.
  • If leaving the server in the pool, update the External URL field on the Notes Traveler tab of the server document to match that of other servers in the pool.

Integration strategies

There are two strategies for integrating existing servers into an HA pool. One strategy is to build up the HA pool only from existing servers. The advantage of this strategy is that no additional servers are required for the IBM Traveler servers. The disadvantage is that you cannot validate the configuration until at least one of the servers has been reconfigured for HA. The second strategy is to set up a new HA pool and then integrate the existing servers into the pool. The advantage of this strategy is that the initial HA configuration can be validated without impacting the existing users. Then the integration of the existing servers can be staged. At the end of the integration, excess servers can be removed from the configuration. The disadvantage of this strategy is the requirement for additional hardware, at least until the integration is complete.

The following integration checklist assumes the second strategy:
  1. Set up and validate the initial IBM Traveler High Availability pool.

    Note that once the new environment is set up and validated, new users can be provisioned for the HA pool.

  2. Upgrade all of the existing IBM Traveler servers to the same version/release utilized by the HA pool.

    During the upgrade process, existing data and configuration is migrated as necessary. Depending upon the size of the database this process can take a while. Note that during this upgrade process, the server will not be available for device requests.

  3. (Optional) Configure the server for secure communication.

    If the HA pools is configured for secure server to server communication, enable this on the existing servers that will join the HA pool.

  4. Configure an existing IBM Traveler server for the HA pool database.

    This configuration change will not take affect until the server is restarted.

  5. Restart the server.

    Upon startup, the server will detect that it is now configured for an HA environment and will start transferring all of the user and administration data to the HA pool database. The server will not be available for requests until the data transfer is complete.

  6. Validate the configuration.

    Once the transfer is complete, the server is registered as part of the HA pool. This can be validated from the web administration interface or from any server in the pool.

  7. Update the network configuration such that the server address is aliased by the front end sprayer for the HA pool.

    Update the front end sprayer to service this server.

  8. Update the external URL setting for the server to coincide with the front end sprayer for the pool.

Repeat steps 3 through 8 for each server to be integrated into the HA pool.

After the data has been transferred, if desired, a server can be removed from the HA pool. Before doing so, be sure that the load balancer is no longer trying to send requests to the server being removed.