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 Notes
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.
- 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 the amount of data.
- IBM Notes 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.
- The new server URL is <hostname>/traveler. However, for backwards compatibility with existing IBM Notes Traveler clients, <hostname>/servlet/traveler is still supported.
- 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 synchronization state data will have to be recreated as devices synchronize with the server.
- 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 Notes Traveler servers in the pool, for example: *.mycompany.com.
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 Notes
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:
- Set up and validate the initial IBM Notes Traveler High Availability pool.
Note that once the new environment is set up and validated, new users can be provisioned for the HA pool.
- Upgrade all of the existing IBM Notes 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.
- 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.
- Configure an existing IBM Notes Traveler server for the HA pool database.
This configuration change will not take affect until the server is restarted.
- 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.
- 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.
- 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.
- 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.
At any point in this process after the data has been transferred, a server can be removed from the HA pool.
Parent topic: Planning for migration