The IBM® Lotus Notes® Traveler server task itself cannot be clustered to support a high-availability environment. The Lotus Notes Traveler service does recognize that a remote mail file is clustered or has additional replicas defined otherwise, and it switches over to sync mail from replicas if the primary mail server of the user is down.
The Lotus® Traveler service detects mail file replicas by reading the replica entries in the Lotus Domino® cluster directory database (cldbdir.nsf
) on the mail server of the user. This database must grant at least reader access to the Lotus Notes Traveler server. Otherwise, the Lotus Traveler server never fails over the connection to an alternate server for mobile users if their primary Domino mail server is down.
It is possible to set up multiple Lotus Notes Traveler servers. Each could have the same access to all the mail files of a user on remote servers. If a Lotus Notes Traveler server is not responsive, the user can manually reconfigure the device client settings to point to another Lotus Notes Traveler server. However, after a device switches to a new server, the sync anchors do not match between the server and device. The protocol initiates a sync refresh, where all of the data on the device is replaced by a fresh copy of the data from your mail database. Internally, the Lotus Notes Traveler server keeps track of each piece of data that is on a device. If a device switches to another server, then this history is lost. This is because these tracking databases are not on the network or shared between Lotus Notes Traveler servers.
When multiple Lotus Notes Traveler servers have been deployed, do not place an IP sprayer or load balancer in front of these servers. Since the Lotus Notes Traveler server databases are not common, mobile devices will constantly refresh their data as device requests are sprayed to different Lotus Notes Traveler servers, making the system unusable.
Parent topic: Planning for installation and configuration