Skip to Content

What is the mimum requirement for a load balance in order to support MobiLink (SUP)


Version 11 and version 12 ML server support a load balancer in front of a farm ML servers as follows:

·         The minimum requirement is that the load balancer balance connections at the TCP/IP level to the ML server farm.

·         Fail-over can be achieved by having the load balancer ping the ML server using an empty TCP/IP connection.

·         Each ML server is connected to the SAME consolidated database, ie. there must be exactly ONE consolidated database per ML server farm

·         If SUP uses MobiLink's server-initiated synchronization (SIS), then the MobiLink Arbiter is required (See*d5e37718).

·         Each remote client may connect to ANY ML server in the farm, because all of the state information is in the consolidated database.

1.     Note that you CANNOT arbitrarily nor automatically move a remote from one consolidated database to another. Remotes (strictly speaking, a given subscription on a remote) must always continue to connect to the same consolidated database.

·         There must be NO Relay Server being used, because the load balancer must perform all load balancing.

·         This architecture handles persistent HTTP ML traffic.

·         To handle non-persistent HTTP ML traffic, an additional requirement is for the load balancer to support "stickyness" based on the client's IP address OR by inspecting headers.

1)     This means that each request as part of a synchronization session from the same remote MUST go to the SAME ML server.

2)     The stickyness may timeout if there is no traffic from that IP, so that the next time a session comes in from that remote, it may be load balanced.

·         Note that inspecting headers isn't possible if the load balancer isn't a TLS endpoint when HTTPS is used

·         The header to inspect is ml-client-id, which will contain the remote ID. All traffic with the same ml-client-id value must go to the same ML server within the stickiness timeout period, eg. 1 hour.

·         Note that some networks:

1)     Have volatile IP addresses, possibly changing in between requests for the same sync session

2)     Do not have access to the client device's IP address at the load balancer

3)     In the above two cases, non-persistent syncs would likely break regularly, if they worked at all

·         This nicely illustrates more advantages of the Relay Server in a MobiLink environment, since the RS isn't affected by these issues.

This architecture handles non-HTTP traffic.