Live-Migration

Server werden ersetzt: Hardware altert, Anbieter wechseln, Regionen verschieben sich. rdc repo migrate verschiebt ein laufendes Repository mit einem einzigen Befehl auf eine andere Maschine, und mit --checkpoint macht sogar der Prozessspeicher den Trip mit. Die Demo-App pulse hält einen Zähler im RAM; nach dem Umzug zählt sie weiter, statt von vorn zu beginnen.

Tutorial ansehen

So läuft der Umzug ab

Zwei Phasen, minimale Ausfallzeit

Phase eins kopiert den Großteil der Daten, während die App weiterläuft. Phase zwei sichert die laufenden Prozesse per CRIU (für Container mit Label rediacc.checkpoint=true), überträgt das finale Delta samt Prozesszustand und setzt alles auf der neuen Maschine fort. Die Ausfallzeit ist das Delta, nicht die Datenmenge.

Schritt 1: Der Beweis - ein Zähler im RAM

rdc term connect --machine <machine-name> --repository pulse --command 'docker logs heartbeat_app --tail 5'

Die App führt einen In-Memory-Zähler und protokolliert alle fünf Sekunden einen Beat. Der Zähler lebt nur im RAM: Ein Neustart des Prozesses würde ihn auf eins zurücksetzen.

memory counter=6 und steigt, einmal pro fünf Sekunden. Der Zähler lebt nur im Prozessspeicher. Würde der Prozess neu starten, begänne er bei eins.

Schritt 2: Live migrieren

rdc repo migrate --name pulse --from <machine-name> --to <target-machine> --checkpoint --skip-dns

Migration mit Checkpoint: Phase eins überträgt die 2 GB Masse, während die Quelle online bleibt. Dann erstellt eine kurze Umschaltung einen Checkpoint der laufenden Prozesse und überträgt das finale Delta. Die Ausgabe zeigt jede Phase und die tatsächliche Ausfallzeit.

Die Ausgabe erzählt den Umzug: Phase eins überträgt die 2 GB Hauptdaten, während die Quelle online bleibt, dann gibt die Cutover-Zeile die tatsächliche DOWNTIME aus: einige Dutzend Megabyte und ungefähr zwanzig Sekunden - für ein zwei Gigabyte großes Repository.

Schritt 3: Das neue Zuhause prüfen

rdc repo list --machine <target-machine>

Repositories auf der Zielmaschine auflisten: pulse ist gemountet, Docker läuft und die Container sind aktiv.

Auf dem Ziel ist pulse eingehängt, Docker läuft, Container sind aktiv.

Schritt 4: Die Quelle ist gestoppt

rdc repo list --machine <machine-name>

Auf der Quelle ist das Repository gestoppt und ausgehängt: kein Docker, null Container. Das Image wird als Basis für künftige Delta-Übertragungen behalten.

Die Quelle listet das Repository noch, aber ehrlich: nicht eingehängt, kein Docker, null Container. Dort läuft nichts mehr. Das Image wird absichtlich behalten als Basis für den nächsten Delta Transfer, sodass ein zukünftiger Push zurück günstig ist.

Schritt 5: Der Zähler zählte weiter

rdc term connect --machine <target-machine> --repository pulse --command 'docker logs heartbeat_app --tail 5'

Die Logs auf der neuen Maschine zeigen, wie der Zähler dort weiterzählt, wo der Checkpoint ihn eingefroren hat, ohne auf eins zurückzusetzen. Der Prozessspeicher hat die Reise mitgemacht.

memory counter=17, dann 18, 19, 20… Er machte genau dort weiter, wo der Checkpoint ihn eingefroren hatte, statt bei eins neu anzufangen. Das ist Prozessspeicher, der den Trip macht; die App hat nie bemerkt, dass sie die Maschine gewechselt hat.

Ohne --checkpoint verschiebt migrate trotzdem Daten und Container; sie starten auf dem Ziel frisch neu, statt mittendrin weiterzumachen.

Weiter: Delta Transfer.