Running On A Cluster

When running on a cloud cluster, Hadean Connect is able to automatically scale the number of Connect nodes to account for varying demand. This means that when running on a cluster it is important to implement logic to determine what nodes are running to ensure that your clients are able to connect and that your servers are sending out data to all available nodes.

Deploying Connect

To run on a cluster provisioned using the Hadean Platform, the Autoscaler and Muxer binaries and configuration files need to be deployed to the cluster machines, this can be performed from the command line passing in the location of the directory containing your Connect configuration files.
hadean cluster deploy autoscaler -n ${CLUSTER_NAME} -d <path_to_config_dir>
The path_to_config_dir is the location of the autoscaler.toml file. This would typically be in muxer-sdk/autoscaler/data
The path given should point to a directory containing the following, in the SDK downloadable bundle this directory can be found at muxer-sdk/autoscaler/data
├── autoscaler.toml
└── muxer
├── muxer
└── muxer_config.toml
The autoscaler.toml file contains information on how Connect will scale up and down. Details of available configuration options can be found in Configuring Automatic Scaling

Running the Hadean Connect

To start the Connect cluster the run command is used
hadean cluster run cluster_config.toml --name ${CLUSTER_NAME}
The cluster_config.toml file will have been generated when creating the cluster
In order to make use of dynamic scaling it is essential that the cluster configuration is set to enable metrics, which is the API Connect uses to query the state of its nodes.
Check that metrics_enabled is set to true in your cluster_config.toml
More information on configuring clusters can be found in the Platform SDK docs.

Detecting Changes in Node Configurations

The Connect network includes a webhook mechanism to periodically notify an interested system of the currently available Connect Nodes. This mechanism sends a REST web request with a fixed format data payload to a web endpoint of your choosing.
The data sent is in JSON format. An example of the JSON received can be seen below for a 2 Connect Node cluster. Each Node can either be in a "Ready" or "Provisioning" state. If it is in "Provisioning" then no other fields will be populated.
event: ‘heartbeat’,
client_count: 14
id: 1
location: “uksouth”
max_clients_allowed: 100
state: “Ready”
client_count: 8
id: 2
location: “uksouth”
max_clients_allowed: 100
state: “Ready”


The configuration of the webhook is specified via the autoscaler.toml configuration file in the section [discoverability.webhook]. An example configuration is listed below:
url = "https://customer-side:5000"
method = "POST"
heartbeat = 5
headers.authorization = "some-secret"
  • url - the url of the desired endpoint to be reached by the webhook
  • method- http method to be used by the webhook (POST/PUT)
  • heartbeat- period (in seconds) of the “heartbeat” requests made to the server. Note, this is not the rate at which Muxer Node configuration changes will be detected
  • headers.authorization - secret - used by the webhook for authorisation purposes