That might be. I think we are talking about the same thing, but I guess you are drawing your boxes according to your infrastructure or the way you are deploying the components. At the end you need:
- 1 Network-Server Service (with many NS-Containers)
- 1 Application-Server Service (with many AS-Containers)
- 1 Gateway Service (with many GB-Containers)
That’s what I mean with clustering. MQTT has some Stateful-properties, that’s why I’d suggest you to pick a MQTT Server that supports clustering and shared topics like HiveMQ or VerneMQ. Again, it does not mean all the containers “Live” in one Container Stack, but in the case of MQTT, they should be aware of the others. I don’t know if mosquitto supports clustering, but you could “fake it” with bridging every mqtt-server with each other.
How you distribute the chirpstack components among your (Virtual-)Machines is more or less irrelevant. I’m guessing you are deploying them with docker-compose on N-Machines and that’s why they are grouped together?
If you are using Kubernetes for your deployment, maybe having a look at the Helm-Chart I maintain can help you with your setup. https://gitlab.com/wobcom/iot/chirpstack-helm/-/tree/master
We have 3 NS-Pods, 3 AS-Pods and the GBs are all deployed at the gateways, that’s why the Chart does not really deploy the GB.
Some screenshots from the dashboard: https://grafana.com/grafana/dashboards/13303
