La haute disponibilité d'un broker MQTT consiste à maintenir la communication entre appareils et applications lorsqu'une partie du système tombe en panne, et elle dépend autant de vos clients que du broker. Cet article explique les concepts clés, ce qui arrive réellement aux sessions et aux messages lors d'un basculement, comment concevoir des clients qui se rétablissent proprement, et quelles questions poser à tout fournisseur, ConnectMQ compris, avant de vous appuyer sur lui.
Ce que signifie la haute disponibilité pour MQTT
En termes d'infrastructure générale, la haute disponibilité consiste à concevoir un système de sorte que la défaillance d'un composant n'interrompe pas longtemps l'ensemble du service. Pour un broker MQTT, cela se décompose en trois questions distinctes :
- Les clients peuvent-ils se reconnecter rapidement ? Si le processus du broker, la machine ou le chemin réseau tombe en panne, combien de temps avant que les appareils puissent se reconnecter ?
- Qu'advient-il de l'état des sessions ? Les abonnements et les messages QoS 1 et 2 en file pour les clients hors ligne sont-ils préservés après la panne ?
- Qu'advient-il des messages en vol ? Les messages acceptés mais pas encore livrés sont-ils perdus, livrés une fois ou livrés deux fois ?
Les réponses varient selon les architectures, et un fournisseur excellent sur la première question peut ne rien promettre sur la troisième. Soyez précis sur celle dont vous avez besoin.
Les architectures de haute disponibilité courantes
| Schéma | Fonctionnement | Ce qui survit à la panne d'un nœud | Compromis |
|---|---|---|---|
| Nœud unique à redémarrage rapide | Un broker, redémarré ou remplacé automatiquement en cas de panne | La connectivité après redémarrage ; l'état dépend de la persistance | Simple ; brève interruption pendant le redémarrage |
| Actif-passif | Un nœud de secours prend le relais quand le principal tombe | La connectivité ; l'état seulement s'il est répliqué ou sur un stockage partagé | La capacité de secours reste inutilisée |
| Cluster actif-actif | Plusieurs nœuds servent les clients et routent les messages entre eux | La connectivité ; l'état si le cluster le réplique | Plus complexe ; surcoût de coordination entre nœuds |
| Brokers partitionnés | Brokers indépendants par site, tenant ou région | Seule la partition défaillante est touchée | Pas d'espace de topics global unique |
| Basculement côté client | Les clients connaissent un endpoint principal et un secondaire | La connectivité, si le secondaire est sain | L'état n'est pas partagé entre les deux brokers |
Aucun de ces schémas n'est universellement le meilleur. De nombreux systèmes IoT fiables utilisent un seul broker bien exploité par partition, associé à des clients résilients, car l'architecture la plus simple est celle qui offre le moins de façons de tomber en panne.
La place d'une offre managée
Soyons directs. ConnectMQ ne propose pas de clustering avec réplication des messages, et les sessions et messages en file ne sont pas conservés après un redémarrage du broker. Vous devez donc concevoir vos clients pour qu'ils tolèrent un redémarrage du broker en se reconnectant, en se réabonnant et en republiant tout ce qui est important, ce qui est de toute façon une bonne pratique sur n'importe quel broker.
En revanche, ConnectMQ offre pour la planification de la disponibilité un choix de modèles de déploiement. Une offre Dedicated vous donne un cluster isolé, de sorte que le trafic des autres tenants ne peut pas affecter le vôtre. BYOC exécute le broker dans votre propre compte cloud, géré par ConnectMQ, au sein de l'infrastructure, du réseau et des régions que vous maîtrisez déjà. Si vous avez besoin d'un objectif de disponibilité précis, discutez-en avec l'équipe pour un déploiement Dedicated ou BYOC plutôt que de supposer un chiffre.
Ce qui se passe lors d'un basculement
Lorsqu'un broker redémarre ou qu'un client est déplacé vers un autre nœud, la séquence typique est la suivante :
- La connexion TCP tombe. Le client le remarque immédiatement ou après son intervalle keepalive.
- Les autres abonnés reçoivent le message Last Will, si le broker le traite avant la panne, ou une mise à jour de statut plus tard.
- Le client se reconnecte avec une temporisation.
- Si le broker a toujours la session, le CONNACK indique que la session est présente et les abonnements sont intacts. Sinon, le client repart d'une session vierge et doit se réabonner.
- Les messages publiés pendant que le client était hors ligne ne sont livrés que si le broker les a conservés ; sinon, ils sont perdus.
La conclusion pratique : ne supposez jamais que l'étape 4 indique une session présente. Réabonnez-vous à chaque connexion, et conservez côté client tout ce que vous ne pouvez pas vous permettre de perdre jusqu'à son acquittement.
Concevoir des clients pour la haute disponibilité
Des clients résilients transforment un basculement du broker en simple accroc plutôt qu'en incident. Les schémas ci-dessous fonctionnent sur n'importe quel broker.
Se réabonner à chaque connexion
Placez les abonnements dans le callback de connexion, et non dans le code de démarrage, pour qu'ils soient rétablis après chaque reconnexion quel que soit l'état de la session.
Mettre en tampon localement jusqu'à l'acquittement
Pour les données importantes, conservez une file locale et ne retirez un élément qu'après l'acquittement par le broker d'une publication QoS 1. Notre guide store and forward MQTT couvre les tampons persistants sur les passerelles.
Basculer entre endpoints
Si vous exploitez plusieurs brokers, par exemple deux déploiements indépendants dans des lieux différents, le client peut alterner entre eux. Voici un exemple Python minimal avec paho-mqtt 2.x qui alterne les endpoints, se réabonne à la connexion et conserve en mémoire les messages non acquittés.
import json
import random
import threading
import time
import paho.mqtt.client as mqtt
ENDPOINTS = [("broker.connectmq.com", 8883), ("YOUR_SECONDARY_HOST", 8883)]
BASE = "acme/site1/line1/gw-01"
pending = {} # mid -> (topic, payload), retiré une fois acquitté
lock = threading.Lock()
def send(client, topic, payload):
with lock:
info = client.publish(topic, payload, qos=1)
pending[info.mid] = (topic, payload)
def on_connect(client, userdata, flags, reason_code, properties):
if reason_code.is_failure:
print("refused:", reason_code)
return
print("connected; session present:", flags.session_present)
client.subscribe(f"{BASE}/cmd/#", qos=1) # toujours se réabonner
client.publish(f"{BASE}/status", "online", qos=1, retain=True)
with lock:
unacked = list(pending.values())
pending.clear()
for topic, payload in unacked: # renvoyer les données non acquittées
send(client, topic, payload)
def on_publish(client, userdata, mid, reason_code, properties):
with lock:
pending.pop(mid, None)
def on_message(client, userdata, msg):
print("command:", msg.topic, msg.payload.decode())
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id="YOUR_CLIENT_ID", protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()
client.will_set(f"{BASE}/status", "offline", qos=1, retain=True)
client.on_connect = on_connect
client.on_publish = on_publish
client.on_message = on_message
index, delay = 0, 1
while True:
host, port = ENDPOINTS[index % len(ENDPOINTS)]
try:
client.connect(host, port, keepalive=30)
except OSError as exc:
print(f"{host} unreachable: {exc}")
index += 1
time.sleep(delay + random.random()) # temporisation avec gigue
delay = min(delay * 2, 60)
continue
delay = 1
client.loop_start()
time.sleep(2) # attendre le CONNACK
while client.is_connected():
reading = json.dumps({"ts": int(time.time()), "rpm": 1480})
send(client, f"{BASE}/telemetry", reading)
time.sleep(5)
client.loop_stop()
print(f"lost {host}, trying the next endpoint")
index += 1
En production, vous persisteriez pending sur disque et en plafonneriez la taille, mais la structure reste la même. Comme la QoS 1 autorise les doublons, les destinataires doivent tolérer qu'un message arrive deux fois après un basculement. Notez que chaque endpoint nécessite des identifiants valides pour ce broker.
Rendre les commandes idempotentes
Après un basculement, une commande QoS 1 peut arriver deux fois. Incluez un identifiant de commande et ignorez les doublons sur l'appareil.
Republier l'état plutôt que de compter sur le broker pour le conserver
Les messages retenus de statut et de configuration sont utiles, mais si le broker redémarre sans persistance, ils doivent être republiés. Faites republier l'état retenu par les appareils à chaque connexion, comme dans l'exemple.
Les questions à poser à tout fournisseur MQTT
Utilisez cette liste lors de vos évaluations et appels d'offres. Demandez des réponses écrites, et considérez toute réponse vague comme un « non ».
- Quelle est la topologie de déploiement de mon offre : nœud unique, actif-passif ou cluster ?
- Les sessions et les messages en file sont-ils conservés après un redémarrage du broker ?
- Les messages sont-ils répliqués entre nœuds avant d'être acquittés ?
- Comment les clients sont-ils redirigés après une panne : même nom d'hôte, changement DNS ou nouvel endpoint ?
- Quel est le délai de rétablissement typique après la panne d'un nœud, et est-il contractuel ?
- Existe-t-il un SLA publié, que couvre-t-il et quels sont les avoirs prévus ?
- Comment se déroulent la maintenance et les mises à niveau, et les clients sont-ils déconnectés ?
- Où se trouve la page de statut, et comment les incidents sont-ils communiqués ?
- Puis-je exécuter un déploiement dans un second lieu ou dans mon propre compte cloud ?
- Qu'advient-il de ma charge si un autre tenant se comporte mal sur une offre partagée ?
Pour notre propre service, la réponse aux questions 2 et 3 est que la persistance après redémarrage et la réplication des messages ne sont pas proposées, et pour les conditions de SLA, adressez-vous directement à l'équipe. Notre article sur le SLA d'un broker MQTT explique comment lire les clauses de SLA, et la checklist d'appel d'offres pour broker MQTT propose une liste d'évaluation plus longue.
Schémas pratiques de haute disponibilité sur un broker MQTT managé
En combinant les concepts ci-dessus, une approche réaliste pour la plupart des équipes ressemble à ceci :
- Choisissez un broker MQTT managé pour que les correctifs, le TLS et les pannes matérielles soient l'affaire de quelqu'un d'autre.
- Utilisez un déploiement Dedicated si vous avez besoin d'une isolation vis-à-vis des autres tenants.
- Utilisez BYOC si le broker doit résider dans votre propre compte cloud, à côté de vos autres systèmes.
- Partitionnez par site ou par client lorsqu'une panne ne doit pas affecter tout le monde.
- Construisez chaque client avec réabonnement à la connexion, mise en tampon locale, commandes idempotentes et temporisation avec gigue.
- Surveillez l'état des connexions, par exemple via
$SYS/broker/connection/{clientId}/state, et déclenchez une alerte lorsque des appareils passent hors ligne.
Pour la capacité en complément de la disponibilité, consultez comment faire évoluer un broker MQTT, et pour une vue d'ensemble de l'hébergement, lisez le guide sur le broker MQTT cloud.
Planifiez la disponibilité de votre MQTT avec ConnectMQ
ConnectMQ est un broker MQTT managé avec des options Serverless, Dedicated et BYOC, pour que vous puissiez choisir le modèle de déploiement adapté à vos besoins de disponibilité. Vous pouvez d'abord observer la logique de reconnexion de vos clients sur le serveur MQTT public gratuit, réservé aux tests et jamais aux données de production. Commencez ensuite gratuitement sur app.connectmq.com, sans carte bancaire, développez des clients résilients avec ce broker, et contactez l'équipe lorsque vous avez besoin d'un déploiement Dedicated ou BYOC.
Questions fréquentes
MQTT intègre-t-il la haute disponibilité ?
Non. Le protocole MQTT définit les sessions, la QoS et le Last Will, mais la haute disponibilité dépend de la façon dont le broker est déployé et dont les clients gèrent les reconnexions.
Ma session MQTT survivra-t-elle à un redémarrage du broker ?
Seulement si le broker persiste les sessions. De nombreux déploiements, dont le nôtre, ne conservent pas les sessions après un redémarrage : les clients doivent donc se réabonner et republier l'état important à chaque connexion.
Un cluster est-il indispensable pour un système MQTT fiable ?
Pas toujours. Des clients bien conçus, des brokers partitionnés et des déploiements isolés offrent à de nombreux systèmes une grande fiabilité sans cluster répliqué.
Que demander à un fournisseur au sujet de la haute disponibilité d'un broker MQTT ?
Interrogez-le sur la topologie, la persistance des sessions, la réplication des messages, le comportement en cas de basculement, les fenêtres de maintenance et les conditions écrites du SLA. Obtenez les réponses par écrit avant de vous engager.
