Cluster & Live-Migration

Ein Knoten legt fest, die anderen folgen

Die naheliegende Alternative — jeder Knoten ändert, Widersprüche werden hinterher aufgelöst, der jüngere Zeitstempel gewinnt — setzt gleich laufende Uhren voraus, verliert von zwei gleichzeitigen Änderungen still eine, und man merkt es erst, wenn die Knoten auseinandergelaufen sind.

Mit einem führenden Knoten gibt es diese Fehlerklasse nicht: Es gibt genau eine Quelle, und ein Abgleich ist immer eine Richtung und nie eine Verhandlung.

Definitionen, keine Gigabyte

Über den Cluster-Kanal geht, was klein und beschreibend ist: Dieser Speicher liegt unter jenem Pfad, dieses Netz hängt an jener Bridge, dieses Abbild kommt von jener URL. Wo ein Knoten eine Datei braucht, holt er sie auf dem kurzen Weg — sie liegt schon da, weil der Speicher geteilt ist, oder sie hat eine Adresse und der Knoten lädt sie selbst.

Wo sie beides nicht hat, etwa bei einer hochgeladenen Datei, wird das gemeldet und nichts geschrieben. Ein Eintrag, der auf eine nicht vorhandene Datei zeigt, käme sonst erst zum Vorschein, wenn jemand daraus einen Gast bauen will.

Zwei Dinge werden bewusst nicht abgeglichen: Portweiterleitungen und feste Adressen. Beide zeigen auf einen Gast auf einem Knoten, und sie auf die anderen zu kopieren wäre falsch statt hilfreich.

Vertrauen, das sich nicht selbst abschaltet

Knoten sprechen HTTPS mit einem selbstsignierten Zertifikat. Die Prüfung einfach abzuschalten hieße, jeden im Netz mitmachen zu lassen. Stattdessen wird der Fingerabdruck beim Eintragen festgehalten und bei jeder Verbindung danach verglichen — wer sich dazwischenschiebt, hat einen anderen.

Wechselt ein Knoten sein Zertifikat, muss er neu eingetragen werden. Das ist Absicht und keine Unbequemlichkeit.

Gemeinsamer Speicher, und der Zaun, der dabei sein muss

Ein gewöhnliches Dateisystem auf einer LUN, die zwei Knoten gleichzeitig einhängen, ist binnen Sekunden zerstört, weil jeder für sich merkt, was frei ist, und keiner den anderen sieht. Ein Cluster-Dateisystem wird stattdessen von einem Sperrverwalter koordiniert, sodass mehrere Knoten sich eine LUN gefahrlos teilen.

Das ruht auf zwei Stücken, und beide sind hier Pflicht: der Sperrverwalter mit der Cluster-Mitgliedschaft darunter — und Fencing: Bevor ein Knoten die Sperren eines anderen übernehmen darf, wird der verdächtige Knoten hart abgeschaltet oder setzt sich selbst zurück. Ohne das erzeugt ein hängender, aber noch lebender Knoten ein geteiltes Hirn, und ein geteiltes Hirn auf einem gemeinsamen Dateisystem heißt Datenverlust.

Phillux weigert sich deshalb, einen solchen Speicher zu formatieren oder einzuhängen, solange Quorum und ein geprüftes Fence-Gerät fehlen. Diese Sperre ist kein Warnhinweis, sondern eine Verweigerung.

Eine laufende Maschine umziehen

Steht der gemeinsame Boden, wandert eine laufende VM live von einem Knoten zum anderen und bleibt auf dem Ziel definiert. Ihre Platte zieht nicht mit — beide Knoten sehen sie bereits, und genau darum musste der Speicher vorher geteilt sein.

Was sich auf einer Maschine nicht prüfen lässt, ist echte Mitgliedschaft mit echter Fence-Hardware. Die Sperren sind so gebaut, dass bis dahin nichts Halbes passiert — das ist die bessere Antwort als eine Funktion, die in der Vorführung geht und am Dienstag nicht.