search

SeppPenner / NetCoreMQTTExampleCluster

NetCoreMQTTExampleCluster is a project to run a multi MQTT broker system based on MQTTnet, Dapper (for database connection) and Orleans.
MIT License
44 stars 14 forks source link

Why not put the broker in silo? #1

Open ElderJames opened 2 years ago

ElderJames commented 2 years ago

Hi @SeppPenner ,

I was very inspired by this project.

But I have a question, can we make the broker and silo run in the same service? Instead of being a ClusterClient. If this works, the brokers can follow silo in the cluster.

Best Regards.

SeppPenner commented 2 years ago

You can run the silo host and the MQTT broker part on the same host system or the silo and the MQTT broker part in the same service, but that's not the original idea of the system. If you do that, the way Orleans is intended to be used is broken. The idea was to have multiple instances of the MQTT broker as "frontend" systems and the data logic in the background within the silos / grains (As described in the image below):

Orleans from https://www.youtube.com/watch?v=_yw9HvJdzBo

If you run the MQTT broker part within the silo service, you don't have a distributed system anymore, but a centralized system. For that use case, you should take a look at the https://github.com/chkr1011/MQTTnet.Server which is a single service system and probably better for that use case.

ElderJames commented 2 years ago

Thank you for your reply.

I'm still a bit confused. Silo themselves are clustered, but why is the broker running on each silo instance not clustered?

SeppPenner commented 2 years ago

The broker can be kind of clustered as well:

grafik

Just by adding multiple instances of the MQTT broker "talking" to one or more silo hosts, the MQTT brokers can be clustered. That was the original idea (As the regular MQTT broker is not able to do clustering on its own). The broker can talk to one silo host (Just for synchronization of the MQTT brokers) or to multiple silo hosts (Synchronization and redundancy).

ElderJames commented 2 years ago

Thank you for the detailed explanation.

My understanding of clustering is that first the mqtt client should only need to connect to one endpoint, and then implement load balancing at the endpoint to distribute the links to multiple broker nodes. If the connection is disconnected for a period of time and when it is linked again, it is assigned to another node, then the messages from the previous proxy are sent to the client from that node.

At the moment you don't seem to have implemented load balancing with this design.

SeppPenner commented 2 years ago

It's not really load balancing as we know it in a classical way, but Orleans offers load balancing (https://dotnet.github.io/orleans/docs/implementation/load_balancing.html). I didn't want to re-invent things and therefore rely on the Orleans standard machanisms :)

ElderJames commented 2 years ago

Yes, I would also like to take advantage of Orleans' clustering mechanism. Orleans' silo is embedded load balancing, using one of the nodes as a gateway endpoint. I want the Mqtt Broker to also take advantage of Orleans' cluster implementation for routing Mqtt messages