I have started reading some details about MQTT protocol and its implementation. I came across the term 'cluster' a lot. Can anyone help me understand what does 'cluster' mean for MQTT protocol?
In this comparison of various MQTT protocol, there is a column for the term 'cluster'
Forwarding messages with topic bridge loops will not result in a true MQTT broker cluster, which will lead to drawbacks lined out above.
A true MQTT broker cluster is a distributed system that represents one logical MQTT broker. A cluster consists of various individual MQTT broker nodes, that are typically installed on separate physical or virtual machines and or connect over a network.
Typical advantages of MQTT broker clusters include:
Elimination of the single point of failure
Load distribution across multiple cluster nodes
The ability for clients to resume sessions on any broker cluster
Scalability
Resilience and fault tolerance - especially useful in cloud environments
I recommend this blogpost, if you're looking for a more detailed explanation.
A cluster is a collection of MQTT brokers set up to bridge all topics between each other so that a client can connect to any one of the cluster members and still publish and receive messages to all other clients no matter which cluster member they are connected to.
A few things to be aware of:
Topic bridge loops, where a message is published to one cluster member which is then forwarded to another cluster member, then another and finally back to the original. If this happens the original broker doesn't have a way to know it originally pushed this to the other cluster members so the message and end up in a loop. Shared message state databases or using a single bridging replication broker can fix this.
Persistent subscriptions/sessions, unless brokers have a pooled session cache then clients will not retain session or subscription status if they connect to a different cluster member when reconnecting.
Related
I have the doubt if a MQTT Broker also can be a client? Or I must need to separate and get a dispositive to act as a broker and another as a client. I'm not finding information on internet.
If I understand the question properly, what you are looking for is MQTT bridging.
This is where one broker acts as a client to a second (or multiple) broker and based on config copies messages on topics between the 2 brokers.
How this is configured depends on which broker you are using, but the concept is part of the spec (I don't think it's optional off the top of my head) so all brokers should support it
I am willing to create a mediator which is subscribed and published to 2 separate broker who have no access to topics of each other. The aim is to updates and create a logic of the message published by broker 1 and send it to broker 2 according to the set of rules
Do I need 2 separate ports ? As the topic level might be different in both brokers
Any help is much appreciated!!!
There is no MQTT standard (note, can only speak for 3.1.1) defined features that would allow a client maintain two concurrent connections. Therefore, this is entirely broker implementation-dependent and necessitates a bridge.
For example, the Eclipse Mosquitto broker can be configured as a bridge to another broker and even remap topics from itself to a different topic structure of the other. Please refer to the Mosquitto man page section Configuring Bridges for the specifics.
As far as creating a bespoke application, you can always write a simple Python program that is running two instances of an MQTT client (Eclipse Paho for example, which has a lightweight asyncio wrapper to facilitate concurrency), each connected to different brokers. The glue logic between them just has to re-publish an incoming subscribed topic message from Broker A to some topic, with or without a remapping step, to Broker B.
If the two brokers are both running locally on a single NIC, then you would need to use different ports.
Currently, I am doing some R&D on Thingsboard IOT platform. I am planning to deploy it in cluster mode.
When it is deployed, how two Thingsboard servers communicate with each other?
I got this problem in my mind because a particular device can send a message to one Thingsboard server (A) but actually, the message might need to be transferred to another server (B) since a node in the B server is processing that particular device's messages (As I know Thingsboard nodes uses a device hash to handle messages).
How Kafka stream forward that message accordingly when in a cluster?
I read the official documentation and did some googling. But couldn't find exact answers.
Thingsboard uses Zookeeper as a service discovery.
Each Thingsboard microservice knows what other services run somewhere in the cluster.
All communications perform through message queues (Kafka is a good choice).
Each topic has several partitions. Each partition will be assigned to the respective node.
Message for device will be hashed by originator id and always pushed to the constant partition number. There is no direct communication between nodes.
In the case of some nodes crash or simply scaled up/down, Zookeeper will fire the repartition event on each node. And existing partitions will be reassigned according to the line node count. The device service will follow the same logic.
That is all magic. Simple and effective. Hope it helps with the Thingsboard cluster architure.
I'm trying to help a customer connect their Mosquitto bridge to Azure IoT Edge. They have some legacy equipment that speaks MQTT, but because it can't do TLS and the topics can't be changed, we are trying to run the messages through the Mosquitto MQTT Broker, and over to IoT Edge via the Mosquitto bridge...
I've had no problems getting the actual connection made from the bridge to IoT Edge and I have messages flowing to the bridge. That connectivity works fine. The problem comes in the topics. I really can't change the topic structure that the client publish on. However, IoT Edge requires messages to be published on a specific MQTT topic (devices//messages/events). Where device_id is the name of my broker, let's say 'mymqttbroker' just for fun.
So, what I'm trying to do is to take the messages that some in on pretty much any topic, and resend those messages through the bridge on the devices/mymqttbroker/messages/events topic to IoT Edge.
I know the topic line in the bridge config has the remote_prefix and local_prefix parameters, but that won't cut it. Per this article, it says you can't do this..
"E.g A broker would receive messages to topic sensor1 and remap them to new_sensor1. Currently this form of remapping is not available,"
Any idea how to do something like this? is it possible? Essentially, is there any way in the bridge to accept messages from any topic, and republish them on a specific fixed topic?
The quick and dirty way is to write a little helper app that subscribes to the old topics and republishes to the new topics, then just bridge the new topics.
It does add another point of failure, but it's the only option for mosquitto.
If you are not wedded to mosquitto, you can build your own custom broker with something link mosca and add the remapping into the broker.
I was planning on using Mosca or Mosquitto brokers (due they are open source) in order to achieve a scalable architecture with messages queue replication to avoid losing a message not yet delivered by the broker in an eventual failure of the broker.
As I read, mosquitto is a mature and very stable solution with the capacity of horizontal scalability using bridges. But I couldn't find any plugin to write messages into a database (common to all brokers), so I think that this is a limitation since if we have i.e. two brokers load balanced and one of them die, then all the messages of this broker cannot be delivered until the broker recover.
Mosca in the other hand allows us to scale using Redis, and if the broker 1 die, then broker2 still can deliver messages because they are stored in a common database. And in that way I can use master-slave configuration of redis to avoid single point of failure.
So my questions are:
1) Is mosca a good choice for production?
2) Is it possible to use redis to allocate messages queues with mosquitto?
Horizontal scalability is incredibly hard to add as an feature to MQTT brokers, since it requires engineering for that scalability from the start. Also, just replicating queues for undelivered messages won't help for resilience or fault-tolerance.
Even if it would be easy to add, I would NOT go with redis, since it essentially loses messages: https://aphyr.com/posts/283-jepsen-redis
If you want horizontal scalability, I'd recommend to check out a broker that has clustering, horizontal (or better: linear) scalability built-in and does allow network splits.
Here is a series about MQTT and clustering: http://www.hivemq.com/blog/clustering-mqtt-introduction-benefits/