Load Balancers for ThingWorx High Availability
One or two load balancers are required for a ThingWorx HA configuration.
• One load balancer to direct traffic to the ThingWorx Connection Servers. It is only needed if ThingWorx Connection Servers are part of the deployment.
• One load balancer to direct traffic to the ThingWorx server that is the current leader. This load balancer is required in all ThingWorx HA configurations.
General Load Balancer Requirements
• The load balancer should operate within its own High Availability configuration.
• It can route web socket traffic.
• It can manage static (or sticky) sessions.
• (optional) It can manage SSL termination.
Load Balancer for ThingWorx Connection Servers
If a load balancer for the connections servers is needed, it should receive all ThingWorx traffic and distribute it based on these rules:
• The load balancer should only direct web socket traffic to the Connection Servers. User traffic and other non-web socket traffic should be directed to the other load balancer routing traffic to the ThingWorx leader.
• For best performance, the web socket traffic from an asset should always go to the same Connection Server using sticky sessions.
◦ If that Connection Server goes offline, then that asset’s traffic should be directed to another Connection Server.
◦ If the session between asset and Connection Server becomes inactive, then a new session can be established with any available Connection Server.
Load Balancer for ThingWorx Servers
All traffic to the ThingWorx server (user, asset, connection servers, and so forth) should be routed through this load balancer to ensure it is directed to the current ThingWorx leader.
The load balancer periodically calls a service on each ThingWorx server. This service responds with its leader status. The ThingWorx server that returns the leader code to the load balancer receives user and asset traffic. ThingWorx servers that return standby code should not receive traffic.
Any load balancer that can meet the following criteria may be used:
• The load balancer can periodically send the following GET statement to the ThingWorx leader and act on the response.
GET /Thingworx/Admin/HA/LeaderCheck
HTTP/1.0\r\nAuthorization:\ Basic\ <base64-encoded-string>
• where <base64-encoded-string> is a base64 encoded user:password string that matches the value of the LoadBalancerBase64EncodedCredentials settings in platform-settings.json.
• The load balancer should send this call to each ThingWorx leader every 15-20 seconds.
• A healthy response from the ThingWorx leader is the response code 200.
◦ While the leader is sending response code 200, the standby servers should be returning either 400, 401, or 503 response codes.
• If the leader sends three response codes that are not response code 200, then:
◦ The load balancer should check the standby ThingWorx servers for response code 200.
◦ The standby server that is now sending response code 200 should be regarded as the new ThingWorx leader.
◦ All traffic should be directed the new ThingWorx leader.
Any load balancer that can meet the above requirements can be used in the ThingWorx HA deployment. An example configuration of a load balancer is provided in the
HAProxy Example. The example is based on HAProxy (
http://www.haproxy.org).