Connecting and collecting data from thousands and millions of devices in a M2M environment will always be the biggest challenge for enterprises. As the number is huge, a single MQTT Broker cannot handle this high traffic and it eventually fails collapsing the entire data flow. Making the whole M2M environment as physically and functionally redundant is highly needed and this mandates the necessity of MQTT Broker clustering. Though the MQTT protocol, doesn't support high availability by default, the usual approach every one implements is the MQTT failover and our first release on high availability also follows the same. But this time, we introduce MQTT Broker with the cluster functionality built-in enabling Inter-broker communication without increasing the management load on your IT Team.

Let us dig deeper into this new functionality to know how it can help enterprises.

Built-in MQTT Cluster

The key role and responsibility the cluster set up holds is about ensuring that the broker is consistently functional without any failure. The cluster set up requires more than one MQTT Broker (each one installed on different physical or virtual servers) to be used but the whole set up will look like one broker to the clients / devices. And, all the nodes in the cluster must know each other. This is the part where MQTTRoute provides a breakthrough with its built-in new functionality. It comes up with the new Inter-broker communicator which enables all the brokers in the cluster to talk to each other ensuring continuous communication with the devices both ways irrespective of clients getting connecting to any broker in the cluster.


The ideology is that we don't want to wait for a Master Broker to get failed and wake the other brokers in the set up to make the service redundant. All the MQTT Brokers in the cluster will always be active and available and IBC in each brokers supports providing persistent communication between them.

Why IBC in Enterprise?

For ambitious MQTT deployments with many millions of clients, any number of broker nodes can be deployed & the data can be distributed maintaining stability and availability. Even if network splits occur or any kind of connectivity problem between nodes arises, the cluster as a whole is still available, as long as at least a single node is still healthy, and heals itself in error scenarios. This is because, whatever may be the count of MQTT servers, everything will be in active state, and the data will be distributed between the nodes.

High Availability cluster Architecture

HA Architecture

The above architecture illustrates that 2 or more MQTT Brokers are grouped together to form a clustered set up with IBC (Inter-broker communicator) enabled in all. The other prime components included in the set up are load balancer and Database.

Load balancer holds a major role in the clustered set up to balance the incoming connections to your broker nodes. In this new active-active mode, the load balancer will not wait for the master broker to get failed as it routes incoming connections to all the available nodes in the set up.


If in case of any failure identified in any of the brokers, load balancer makes a decision to stop en-routing connections to it and distributes the connections to the remaining available brokers. That decision could be based on the weightage or the performing ability of the MQTT Broker.


Finally, any redundant database will act as a common data storage option for all MQTT Brokers in the set up.

Setting up the MQTT Cluster in Multiple Environment

Our HA set up will not restrict users to implement only the specified load balancer and they can use any load balancer of their choice based on their requirements. The configuration in the load balancer depends on how they need to balance the connections to the brokers. However, making the best choice also depends on how & where the cluster set up is getting deployed.

For cloud deployments

In the case of cloud deployments, we don't need to worry much about the selection, as many of the cloud servers by default have load balancing services in them.

AWS Elastic Load Balancer (AWS ELB)

ELB is the load balancing service available for AWS deployments. The service comprises of 4 types of load balancers (Application, Network, Gateway, Classic) in it.


Please refer to the below documentation to select your desired one and get started with the configuration.

https://aws.amazon.com/elasticloadbalancing/getting-started/?nc=sn&loc=4

Azure Load Balancer

Azure Load Balancer is one of the high performance load balancing services for Azure-based deployments.


The set up of Azure load balancer for our HA architecture is already well documented and you can utilize the same to get the implementation done easily.

https://www.bevywise.com/blog/enterprise-iot-implementation-on-azure/

DigitalOcean Load balancer

Digital Ocean, another notable cloud service provider, is also providing load balancer which can be utilised for the HA implementation.


Refer to the below documentation for setting up the same.

https://docs.digitalocean.com/products/networking/load-balancers/how-to/create/

For on-premise deployments

There are a few load balancers that can be used for your on-premise deployments.


Nginx as a load balancer

For Linux based deployments, nginx is the well known and most used load balancer of all time. But it is necessary to go for the NGINX load balancer cluster for clustered architecture.

Refer to the documentation below for the configuration steps.

https://docs.nginx.com/nginx/admin-guide/high-availability/ha-keepalived-nodes/

Microsoft Network Load Balancer

If your desired deployment is in windows, you can get utilized with the Network load balancer which is available by default in all windows machines.

Documentation to have a look at the configurations to be done

https://learn.microsoft.com/en-us/windows-server/remote/remote-access/ras/cluster/configure/step-3-configure-a-load-balanced-cluster

We have also implemented the entire set up with Network load balancer (NLB) of Microsoft at our customer premises.

Configuring the Database

Despite the count, all the MQTT Brokers should possess the ability to deliver data to a singe database. The Database will store all the incoming data traffic from all the nodes, which makes it more seamless to synchronise data within brokers. The key benefit of this centralised storage is that, irrespective of the client's connection with any MQTT brokers, it helps in bypassing data to all the available brokers with the help of IBC to smoothen the publish-subscribe flow.


For example, consider a clustered set up with 2 MQTT Brokers connected to the load balancer and database. 'A' client, a publisher is connected to the Broker 1 and 'B' client, a subscriber is connected to the Broker 2 through load balancer. Now 'A' client publishes data in the topic mqtt1 and 'B' is subscribing to it. As per the set up, MQTT Brokers can talk each and share data from database through IBC. Database will enable Broker 2 to get the data received in Broker 1 and send it to the subscribed client 'B'. Thus, enabling all the brokers to receive and send data irrespective of who is the client connected to?


By the way, it is not mandatory to have only centralised storage. Implementing a Master/Slave set up for your data storage will also add weightage based on the requirement.


While selecting your desired database you can consider choosing MySQL or PSQL as it can very well scale for such clustered high availability.

Overall, the distributed architecture will provide a more robust and reliable network to handle traffic from huge number of clients.


Looking to run a more stable IoT deployment of tens of thousands of devices? Give MQTTRoute a try.


Get started by scheduling a FREE consultation.