ThingWorx Azure IoT Hub Connector in a ThingWorx High Availability Cluster
ThingWorx Azure IoT Hub Connector in a ThingWorx High Availability Cluster
As of version 4.1.0 of the ThingWorx Azure IoT Hub Connector, the Connector can operate in a ThingWorx High Availability (HA) Clustering environment, whether you are using the ThingWorx Azure Industrial IoT (IIoT) OPC UA integration or using Azure IoT SDKs to connect Edge devices to ThingWorx via the Connector.. This topic provides an overview of how the Connector handles messages in an HA Cluster, how service discovery works with a Connector, how to configure the Connector for use in an HA Cluster, and troubleshooting information. For complete information about ThingWorx HA Clustering, refer to the section, ThingWorx High Availability in the ThingWorx Platform 9 Help Center. It is assumed that you have set up the cluster.
* 
If you are using the Connector with Azure IoT SDKs to connect Edge devices to ThingWorx, you can also use version 4.0.0 with version 9.0.3 of the ThingWorx Platform in High Availability (HA) Cluster mode. If you are using the Connector in the Azure IIoT OPC UA integration, you must use v.4.1.0 of the Connector to run in a ThingWorx HA cluster. For both uses of the Connector, an issue in versions 9.0.0 through 9.0.2 of the ThingWorx Platform prevented the Connector from working with the platform in an HA Cluster.
This topic explains the following aspects of running the ThingWorx Azure IoT Hub Connector in a ThingWorx High Availability (HA) Clustering environment:
How the Azure IoT Hub Connector Handles Ingress Messages in a Cluster
The ThingWorx Azure IoT Hub Connector uses a round robin policy for distributing ingress messages across the available ThingWorx Platform instances. This policy provides load distribution and fault tolerance.
Here are the rules for this round robin policy:
1. Only connected and writable ThingWorx Platform instances are considered for routing an incoming message. In this context, writable means that the buffer for writing messages has not exceeded the high watermark configured in the property, cx-server.transport.websockets.connections.highWaterMark.
2. Each message is routed to the next connected and writable ThingWorx instance, based on a circular list of ThingWorx instances.
3. If one instance in the list is not connected or not writable, the Azure IoT Hub Connector routes the message to the next instance in the list.
4. If none of the ThingWorx instances are connected or writable, request messages result in an exception being returned. For the Azure IoT Hub Connector, the result is a 500 Internal Error response being sent to the edge device.
When an Azure IoT Hub Connector is disconnected from all ThingWorx instances, all Edge WebSockets are closed. However, it is possible for a new Edge WebSocket to connect to the Connector.
Multi-Part Request Messages
The following rules govern how multi-part messages are routed by an Azure IoT Hub Connector in an HA cluster:
1. The first chunk of a multi-part message is routed like any other message. It is sent to the next connected and writable ThingWorx instance according to the round-robin policy.
2. Subsequent chunks of the multi-part message routed to the same ThingWorx instance that the first chunk was routed to.
3. If the ThingWorx instance to which the chunks are routed becomes disconnected or not writable, the Connector fails the request and sends an error response to the edge device.
Service Discovery
The service discovery feature enables the Azure IoT Hub Connector to react to dynamic configuration of ThingWorx Platform instances in a ThingWorx High Availability (HA) Clustering environment. Administrators do not have to configure the platform instances manually and restart the Azure IoT Hub Connector when the platform instances change.
More specifically, the service discovery feature enables the Azure IoT Hub Connector to respond to platforms being added to and removed from the cluster. Detection of ThingWorx Platform instances going up and down keeps the Connector instances connected correctly in the cluster. The Remote Things connected through HAProxy can still receive property updates from the Edge when one platform instance in the cluster goes down.
Service Discovery Configuration for an Azure IoT Hub Connector is required when operating in an HA Clustering environment.