Le moyen le plus sûr de quitter HiveMQ Cloud Serverless sans interrompre le service consiste à faire tourner les deux brokers en parallèle pendant un temps et à relayer les messages entre eux. Les appareils et les applications peuvent alors migrer groupe par groupe, et un appareil encore sur HiveMQ continue de dialoguer avec une application qui a déjà migré. Cet article montre comment construire ce relais, comment éviter les boucles de messages et comment migrer les clients par vagues avant l'échéance du 31 décembre 2026.
Pourquoi un relais est nécessaire
Ni HiveMQ Cloud Serverless ni un broker cloud managé comme ConnectMQ ne créeront pour vous un pont vers un autre broker côté cloud. La solution est un petit processus de relais que vous exploitez vous-même : il se connecte aux deux brokers comme un client MQTT ordinaire, s'abonne à des topics choisis d'un côté et les republie de l'autre. Comme il ne s'agit que d'un client, il fonctionne avec n'importe quel broker conforme aux standards et ne nécessite aucune permission particulière.
devices (still on HiveMQ) --> HiveMQ Serverless --relay--> ConnectMQ --> moved consumers
moved command senders --> ConnectMQ --relay--> HiveMQ Serverless --> devices
Si vous exploitez déjà Mosquitto sur site, sa fonction de bridge peut faire le même travail ; voir migrer Mosquitto vers un broker MQTT cloud et configuration d'un bridge Mosquitto.
Le problème des boucles et comment l'éviter
Si le relais transfère le topic site1/# de HiveMQ vers ConnectMQ et aussi de ConnectMQ vers HiveMQ, chaque message fait des allers-retours à l'infini. Empêchez les boucles dès la conception :
- Transférez dans un seul sens. La télémétrie circule dans un sens (de l'ancien vers le nouveau), les commandes dans l'autre (du nouveau vers l'ancien). Ne transférez jamais le même filtre de topic dans les deux sens.
- Utilisez l'option No Local de MQTT 5 sur les abonnements, pour que le relais ne reçoive pas ses propres publications sur le même broker.
- Marquez les messages relayés avec une user property MQTT 5, comme
relayed=1, et ignorez les messages qui la portent déjà.
Le script ci-dessous applique ces trois règles.
Un relais complet en Python
Ce relais utilise paho-mqtt 2.x et MQTT 5 des deux côtés. La télémétrie et les statuts vont de HiveMQ vers ConnectMQ ; les commandes vont de ConnectMQ vers HiveMQ.
# pip install "paho-mqtt>=2.0"
import os, ssl
import paho.mqtt.client as mqtt
from paho.mqtt.packettypes import PacketTypes
from paho.mqtt.properties import Properties
from paho.mqtt.subscribeoptions import SubscribeOptions
# Filtres de topics par sens (ne jamais mettre le même filtre dans les deux)
OLD_TO_NEW = ["site1/+/telemetry", "site1/+/status"]
NEW_TO_OLD = ["site1/+/cmd"]
def make_client(client_id, user, password):
c = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=client_id, protocol=mqtt.MQTTv5)
c.username_pw_set(user, password)
c.tls_set(cert_reqs=ssl.CERT_REQUIRED)
c.reconnect_delay_set(min_delay=1, max_delay=60)
return c
old = make_client("relay-old-1", os.environ["HIVEMQ_USER"], os.environ["HIVEMQ_PASSWORD"])
new = make_client(os.environ["CMQ_CLIENT_ID"] + "_relay", os.environ["CMQ_USER"], os.environ["CMQ_PASSWORD"])
def is_relayed(msg):
props = getattr(msg, "properties", None)
return any(k == "relayed" for k, _ in (getattr(props, "UserProperty", None) or []))
def forward(target):
def on_message(client, userdata, msg):
if is_relayed(msg):
return
props = Properties(PacketTypes.PUBLISH)
props.UserProperty = [("relayed", "1")]
target.publish(msg.topic, msg.payload, qos=min(msg.qos, 1), retain=msg.retain, properties=props)
return on_message
def subscriber(filters):
def on_connect(client, userdata, flags, reason_code, properties):
print("connected:", reason_code, "subscribing to", filters)
opts = SubscribeOptions(qos=1, noLocal=True)
for f in filters:
client.subscribe(f, options=opts)
return on_connect
old.on_connect, old.on_message = subscriber(OLD_TO_NEW), forward(new)
new.on_connect, new.on_message = subscriber(NEW_TO_OLD), forward(old)
old.connect(os.environ["HIVEMQ_HOST"], 8883)
new.connect("broker.connectmq.com", 8883)
new.loop_start()
old.loop_forever()
Exécutez-le sur un hôte fiable, proche des deux brokers, par exemple une petite VM cloud ou un conteneur, avec les identifiants dans des variables d'environnement. La QoS est plafonnée à 1 pour que le relais fonctionne sur le plan Serverless gratuit ; passez-la à 2 à partir de Serverless (Paid) si vos flux l'exigent. Les flags retain sont conservés : les messages de statut retenus publiés sur HiveMQ apparaissent donc aussi comme retenus sur ConnectMQ.
Deux remarques pratiques :
- Le relais compte pour une connexion sur chaque broker. Incluez-le dans le dimensionnement du nouveau plan.
- Supervisez-le comme un composant de production. Si le relais s'arrête, les messages entre clients migrés et non migrés s'arrêtent aussi. Exécutez-le sous systemd ou avec une politique de redémarrage de conteneur.
Le plan de vagues
Migrez les clients dans un ordre qui préserve chaque flux de données.
| Vague | Qui migre | Pourquoi dans cet ordre |
|---|---|---|
| 0 | Démarrage du relais | Les deux brokers voient la même télémétrie et les mêmes commandes |
| 1 | Consommateurs backend : bases de données, moteurs de règles, Node-RED, tableaux de bord | Ils reçoivent les données des appareils via le relais |
| 2 | Un groupe pilote d'appareils issus de sites et de versions de firmware différents | Validation en conditions réelles avec un risque limité |
| 3 à N | Les appareils restants, par lots, par site ou par gamme de produits | Déploiement maîtrisé avec points de contrôle |
| Finale | Les producteurs de commandes, puis arrêt du relais | Les appareils sont déjà sur le nouveau broker |
Après chaque vague, vérifiez que :
- Le nombre de connexions dans le tableau de bord ConnectMQ correspond au nombre de clients migrés.
- Les topics attendus apparaissent dans l'explorateur de topics en direct.
- L'état de connexion de chaque client sur
$SYS/broker/connection/{clientId}/stateindique que les appareils migrés sont en ligne. - Aucun client migré ne se connecte encore à HiveMQ (vérifiez la console HiveMQ).
- Le nombre de connexions reste dans les limites du plan ; les clients MQTT 5 reçoivent
0x97en cas de dépassement de quota.
Retour arrière
Tant que l'ancien cluster fonctionne, chaque vague peut être annulée en restaurant les paramètres de connexion précédents. Gardez les anciens paramètres disponibles dans votre système de provisioning jusqu'à la fin de la dernière vague. C'est la principale raison de ne pas repousser la migration aux derniers jours de décembre : après le 31 décembre 2026, il n'y a plus rien vers quoi revenir.
Checklist de bascule
- Tous les appareils et toutes les applications tournent sur le nouveau broker.
- La console HiveMQ n'affiche plus aucune connexion client en dehors du relais.
- L'état retenu est présent sur le nouveau broker, republié par les appareils ou restauré depuis un export. Voir suppression des données HiveMQ Serverless.
- Arrêtez le relais et surveillez pendant une journée tout client qui réapparaîtrait sur HiveMQ.
- Supprimez le cluster HiveMQ Serverless et retirez l'ancien nom d'hôte de la configuration, des valeurs par défaut du firmware et de la documentation.
Pour le processus de bout en bout, consultez le guide de migration HiveMQ Serverless. Vous pouvez construire et tester le relais dès aujourd'hui avec un broker gratuit sur app.connectmq.com.
Questions fréquentes
HiveMQ Cloud peut-il faire un pont direct vers ConnectMQ ?
Pas côté cloud. Exécutez un client relais comme le script ci-dessus, ou un bridge Mosquitto sur votre propre infrastructure, qui se connecte aux deux brokers comme un client MQTT normal.
Les appareils remarqueront-ils la migration ?
Les appareils qui migrent subissent une brève reconnexion lorsque leurs paramètres changent. Ceux qui n'ont pas encore migré ne voient aucun changement, car le relais continue d'acheminer leurs données vers les applications migrées.
Le relais ajoute-t-il de la latence ?
Il ajoute un saut supplémentaire, généralement de quelques millisecondes à quelques dizaines de millisecondes selon l'endroit où il tourne. Placez-le près des deux brokers et retirez-le une fois la migration terminée.
Le relais doit-il utiliser la QoS 1 ou la QoS 2 ?
La QoS 1 est un bon choix par défaut et fonctionne sur tous les plans ConnectMQ. Assurez-vous que les consommateurs gèrent les doublons occasionnels, que la QoS 1 autorise. N'utilisez la QoS 2 que là où les doublons sont inacceptables et si votre plan la prend en charge.
