Purpose
Introduction
MobiLink in a Failover and Load Balancing Environment
MobiLink Requirements for Failover
When a MobiLink server fails, there must be a load balancer to perform the following operations:
- Detect whether the MobiLink server is available.
- Send synchronizations to the MobiLink server when it becomes available.
- Stop sending synchronizations to the MobiLink server when it is unavailable.
- Prevent concurrent synchronization from the same remote ID.
MobiLink Requirements for Load Balancing
Concurrent Synchronizations
Client/ Server Communication Failures are Common
- Remote ID R1 is in the middle of a long synchronization.
- A communication failure occurs. Note that the MobiLink server is still processing the synchronization and may not notice the failure yet, either because of network conditions or because the synchronization is performing a lengthy operation in the consolidated database at the time.
- The user of R1 sees the failure and retries the synchronization immediately.
- The second synchronization begins processing in a second MobiLink server, while the first synchronization is still in progress in the first MobiLink server. The second synchronization is concurrent with the first one.
What a Load Balancer Can Do to Prevent Concurrent Synchronization
Many load balancers support the concept of stickiness, or persistence. This feature works as follow:
- Each time an IP address connects to the load balancer, the load balancer looks for an existing association between an IP address and a MobiLink server. If an association exists, the load balancer sends the connection to the same MobiLink server; otherwise, it picks a new MobiLink server, records the association, and forwards the connection (this is the stickiness/persistence part).
- When an IP address connects to the load balancer for the first time, the load balancer randomly (or based on load) picks a MobiLink server to handle the connection. The load balancer records the association between the IP address and the specific MobiLink server. Removing stickiness/persistence lets the same IP address get load balanced to a different MobiLink server later. This should help reduce the skewed loads sometimes caused by stickiness/persistence.
When Stickiness/ Persistence is Not Feasible
TCP/IP Synchronization
HTTP/HTTPS Synchronization
The load balancer must perform the following operations:
- Inspect the HTTP headers. The load balancer looks for the ml-client-id header and extracts the remote ID.
- Each time a remote ID connects, the load balancer looks for an existing association between a remote ID and a MobiLink server. If an association exists, the load balancer sends the connection to the same MobiLink server; otherwise, it picks a new MobiLink server, records the association, and forwards the connection.
- When a remote ID connects for the first time, the load balancer randomly (or based on load) picks a MobiLink server to handle the connection. The load balancer records the association between the remote ID and the specific MobiLink server. Removing stickiness/persistence lets the same remote ID get load balanced to a different MobiLink server later. This should help reduce the skewed loads sometimes caused by stickiness/persistence
A new feature was added to the MobiLink Server in v17.0.10 build 6073 in an attempt to allow the MobiLink Server to work with more restrictive load balancers, or with load balancers outside of your control. If your load balancer cannot be configured to inspect the ml-client-id custom HTTP header, but can be configured to inspect HTTP cookies to perform load balancing, you can now use the client_id_cookie stream option with the HTTP and HTTPS streams to cause the MobiLink Server to also set an HTTP cookie with the given name that contains the same value placed in the ml-client-id custom HTTP header. For example, the MobiLink Server startup options below will set the commonly used JSESSIONID cookie with the value of the ml-client-id header.
- -x http(port=8080;client_id_cookie=JSESSIONID)
- -x https(port=8443;client_id_cookie=JSESSIONID;identity=ml.crt;identity_password=never_publish_the_identity_password)
The load balancer must perform the following operations:
- Detect whether or not the MobiLink server is available.
- Send synchronizations to the MobiLink server when it is available.
- Stop sending synchronizations to the MobiLink server when it is unavailable.
- Prevent concurrent synchronization from the same remote ID.
Let time, T, in seconds, be significantly longer than the longest possible synchronization.
- If the remote IP addresses are both static and always visible to the load balancer:
- Use a load balancer that supports both stickiness/persistence and a timeout on the stickiness/persistence, using the remote IP address.
- Otherwise:
- If using HTTP or HTTPS, use a load balancer that supports both stickiness/persistence and a timeout on the stickiness/persistence, using the ml-client-id HTTP header.