Zusammenfassung: Wir haben die LaMetric-IoT-Plattform von DigitalOcean zu Hetzner umgezogen, und die Geräteflotte durfte dabei nicht offline gehen. Eine Web-App kann eine Wartungsseite zeigen, ein vernetztes Gerät nicht. Die Server waren der einfache Teil. Sicher wurde der Umzug durch die Geräte und den Ablauf: die Cloud über einen Namen statt über eine Adresse finden, auf beiden Seiten Broker betreiben, mit Jitter wiederverbinden, die Daten prüfen, bevor der Verkehr umzieht, und auf beiden Seiten dieselben Dashboards beobachten. Die Umschaltung blieb für die Nutzer unbemerkt, und die monatlichen Infrastrukturkosten sanken um mehr als 80 %.
Warum wir umgezogen sind
Der Grund war wirtschaftlich. Hetzner bot für dasselbe Geld deutlich mehr Ressourcen: mehr CPU, mehr RAM und 20 TB Bandbreite pro Monat. In unserer Grössenordnung sprach das für sich. Die monatlichen Infrastrukturkosten sind seitdem um mehr als 80 % gesunken.
Schwierig am Umzug waren nicht die Server. Schwierig war die Flotte.
Warum eine Flotte kein Wartungsfenster hat
Was macht ein vernetztes Gerät den ganzen Tag? Es baut eine MQTT-Verbindung zur Cloud auf und hält sie offen. Es sendet Messwerte, hört auf Befehle und wartet auf Updates. Es erwartet, dass die Cloud dort ist, wo sie vor einer Minute war, und dass dieselbe Anfrage dieselbe Antwort bekommt.
Zieht eine Web-App auf einen anderen Host um, ist der schlimmste Fall eine kurze Wartungsseite. Nutzer sehen sie, warten und laden neu. Ein Gerät in einer Küche oder in einer Fabrikhalle wartet nicht höflich. Es versucht es nach eigenem Zeitplan erneut, oder es gibt auf und zeigt einer Person eine Fehlermeldung, die nie Teil einer Migration sein wollte.
Die LaMetric-Cloud bedient rund 75’000 Geräte mit 99,9 % Verfügbarkeit. Bei einem Umzug wie diesem wird diese Zahl gewonnen oder verloren. Die folgenden Hinweise sind die Checkliste, die wir jedem Team geben würden, das ein laufendes Geräte-Backend zwischen Anbietern verschiebt.
Was ein Umzug im laufenden Betrieb braucht
- Geräte, die die Cloud über einen DNS-Namen finden, nie über eine fest eingetragene IP. Senken Sie die TTL Tage vor der Umschaltung, damit die Änderung die Geräte nach dem Wechsel schnell erreicht.
- Eine Weile Broker auf beiden Seiten. Geräte landen beim Wiederverbinden auf dem neuen, der alte bedient die übrigen weiter.
- Wiederverbinden mit Backoff und Jitter in der Firmware. Tausende Geräte sollen den neuen Broker nicht in derselben Sekunde treffen.
- Daten verschieben und prüfen, bevor der Verkehr umzieht, mit einem Weg zurück, falls die Zahlen nicht stimmen.
- Auf beiden Seiten dieselben Dashboards: verbundene Geräte, Nachrichtenrate, Fehlerrate.
Jeder dieser Punkte wirkt klein. Zusammen entscheiden sie darüber, ob niemand die Migration bemerkt oder ob daraus ein Vorfall wird.
Wie der Umzug ablief
Eine Flotte von Tausenden vernetzten Geräten umzuziehen, erforderte sorgfältige Planung und mehrere abgestimmte Schritte:
- Ein Spiegelbild der Infrastruktur beim neuen Anbieter aufsetzen.
- Datenbankreplikation und MQTT-Broker-Bridging zwischen den beiden Umgebungen einrichten.
- Inhalte mit eigenen Skripten synchronisieren.
- Die Cloudflare-Caches der Website vor der endgültigen Umschaltung leeren.
- Umschalten.
Das Überraschende war, wie unspektakulär die Umschaltung verlief. Trotz all dieser beweglichen Teile blieb sie für die Nutzer unbemerkt: keine Beschwerden, keine sichtbare Störung. So sollte sich eine Infrastruktur-Migration von aussen anfühlen.
Name statt Adresse
Die erste Entscheidung fällt Jahre vor jedem Umzug: Woher weiss ein Gerät, wo die Cloud ist? Ist die Antwort eine in die Firmware einkompilierte IP-Adresse, wird der Umzug zu einem Firmware-Release, das jedes Gerät erreichen muss, bevor Sie etwas umschalten können. Ist die Antwort ein DNS-Name, ist der Umzug eine DNS-Änderung.
DNS hat seinen eigenen Haken. Resolver speichern Antworten so lange, wie die TTL es vorgibt, und manche Geräte und Gateways speichern länger. Deshalb sinkt die TTL Tage vor der Umschaltung und nicht erst am Tag selbst: So verkürzt man, wie lange Clients noch auf die alte Infrastruktur auflösen. Die alten, langlebigen Antworten sollen abgelaufen sein, bevor Sie sich auf die neue, kurzlebige verlassen.
Zwei Broker gleichzeitig
Eine harte Umschaltung verlangt von allen Geräten, im selben Moment umzuziehen. Ein Broker auf jeder Seite nimmt diesen Moment weg. Geräte, die sich nach der DNS-Änderung wiederverbinden, bekommen die neue Adresse und landen auf dem neuen Broker. Geräte, die sich noch nicht wiederverbunden haben, bleiben auf dem alten und funktionieren weiter.
Der Umzug geschieht dann über Stunden oder Tage im Tempo der Geräte selbst, statt in einem Schritt, den man nicht zurücknehmen kann. Der Preis: Eine Weile kann eine Nachricht an zwei Orten ankommen. Alles Nachgelagerte, von der Speicherung bis zu den Apps, die Gerätedaten lesen, muss damit umgehen können. Planen Sie das vor der Umschaltung.
Jitter, damit Sie Ihren eigenen Broker nicht überrennen
Wenn ein Broker Verbindungen trennt, verbinden sich Geräte neu. Tun sie das alle nach festem Takt, kommen sie alle zugleich. Bei 75’000 Geräten ist das ein selbst gemachter Lasttest, und der neue Broker trifft darauf mit kalten Caches und ohne Vorgeschichte.
Exponentielles Backoff mit zufälligem Jitter in der Firmware verteilt diese Wiederverbindungen über die Zeit. Das kostet ein paar Zeilen Code und schützt jeden Ausfall und jeden Umzug, den Sie je haben werden. Fehlt es Ihren Geräten, ist die Ergänzung per OTA-Update die beste Vorbereitung auf eine Migration. Es ist auch ein weiterer Grund, warum ein zuverlässiger Update-Weg an erster Stelle steht: Das Wiederverbindungsverhalten einer Flotte, die Sie nicht erreichen, können Sie nicht korrigieren.
Daten prüfen, einen Weg zurück behalten
Den Verkehr zu verschieben ist der sichtbare Teil. Die Daten zu verschieben ist der Teil, der still Schaden anrichten kann. Kopieren Sie sie auf die neue Seite, bevor die Geräte folgen, vergleichen Sie sie mit der alten Seite und verschieben Sie erst dann den Verkehr. Legen Sie vorher fest, was «die Zahlen stimmen nicht» heisst und was Sie dann tun.
Der Weg zurück ist wichtiger als der Weg nach vorn. Ein Plan, der nur funktioniert, wenn nichts schiefgeht, ist kein Migrationsplan. Läuft die alte Seite noch und ist die TTL noch niedrig, ist der Rückweg eine DNS-Änderung und kein Neuaufbau. Schalten Sie die alte Seite erst ab, wenn die Zahlen auf der neuen den Erwartungen entsprechen.
Dieselben Dashboards, beide Seiten
Einen Umzug, den man nicht sieht, kann man nicht beurteilen. Legen Sie vor der Umschaltung dieselben drei Ansichten auf beide Seiten: wie viele Geräte verbunden sind, wie viele Nachrichten pro Sekunde fliessen und wie viele Fehler die Geräte melden. Während des Umzugs sollte die Zahl der verbundenen Geräte von einer Seite zur anderen wandern, während die Summe gleich bleibt und die Fehlerrate dort bleibt, wo sie war.
Sinkt die Summe, schaffen es Geräte nicht, sich wiederzuverbinden. Steigt die Fehlerrate auf der neuen Seite, unterscheidet sich dort etwas von der alten. Weil die Dashboards gleich sind, dauert der Vergleich Sekunden statt einer Untersuchung.
Eine kurze Checkliste für Ihren eigenen Umzug
- Findet jedes Gerät die Cloud über einen Namen, und wissen Sie, wie lange jedes Gerät oder Gateway diesen Namen zwischenspeichert?
- Können Sie alten und neuen Broker nebeneinander betreiben, und kommt alles Nachgelagerte mit Nachrichten zurecht, die an einem von beiden ankommen?
- Verbinden sich Geräte mit Backoff und Jitter wieder, oder alle auf einmal?
- Haben Sie die Daten auf der neuen Seite geprüft, bevor der Verkehr umzieht, und kennen Sie den Weg zurück?
- Sind verbundene Geräte, Nachrichtenrate und Fehlerrate auf beiden Seiten auf einem Bildschirm sichtbar?
Lautet eine Antwort «nicht sicher», ist das die Arbeit vor der Umschaltung, nicht danach.
Wie wir helfen
Bei Smart Atoms bauen wir Geräte-Backends und die Firmware, die mit ihnen spricht, vom ersten Prototyp bis zur Flotte, die online bleibt. Dazu gehören MQTT-Broker, Flottenverwaltung, Monitoring und Over-the-Air-Updates, bewährt auf der LaMetric-Plattform. So gehen wir bei Cloud-Architektur-Review und Migration vor. Wenn Sie eine Migration planen oder Ihr Wiederverbindungsverhalten prüfen lassen möchten, bevor es darauf ankommt, sprechen Sie mit einem Ingenieur.
Quelle: Smart Atoms, aus dem Betrieb der LaMetric-IoT-Plattform (rund 75’000 Geräte online).
