Ich habe Hochverfügbarkeit eingeschaltet, und die Maschine stand trotzdem still: was HA wirklich verspricht

Du hast Hochverfügbarkeit eingeschaltet. Ein Knoten fiel aus, und deine Maschine kam tatsächlich auf dem anderen Knoten hoch. Doch dazwischen lieferte sie ein paar Minuten lang nichts, und du dachtest, es werde keine Unterbrechung geben.

Hier liegt das Missverständnis: Hochverfügbarkeit verspricht keinen unterbrechungsfreien Betrieb, sondern einen automatischen Neustart.

Zwei verschiedene Dinge

Verschieben im Betrieb ist geplante Arbeit. Du stößt es an, die Maschine wechselt samt Arbeitsspeicher auf den anderen Knoten und steht kaum still. Das ist das Werkzeug der Wartungsnächte.

Hochverfügbarkeit ist für einen ungeplanten Ausfall da. Bricht ein Knoten zusammen, ist alles, was in seinem Arbeitsspeicher lag, mit ihm gegangen; es gibt nichts mehr zu kopieren. Das Einzige, was getan werden kann, ist die Maschine auf einem anderen Knoten von vorn zu starten. Sie kommt also so hoch, wie dein Server nach einem Stromausfall hochkommt.

Deshalb sollte der Maßstab für HA nicht "gab es eine Unterbrechung" sein, sondern "wie lange dauerte die Unterbrechung".

Drei Dinge bestimmen die Dauer

Das Bemerken. Das Cluster entscheidet nicht sofort, dass ein Knoten wirklich gestorben ist. Ein Schwanken im Netz für den Tod zu halten und die Maschinen zu verschieben, ist schlimmer, als den Tod nicht zu bemerken. Deshalb gibt es eine Wartezeit.

Das Stilllegen des alten Knotens. Dieser Schritt wird am häufigsten missverstanden und ist der Kern dieses Artikels: bevor die Maschine auf dem neuen Knoten hochkommt, muss sicher sein, dass der alte wirklich steht. Lässt sich das nicht feststellen, startet das Cluster diesen Knoten zwangsweise neu.

Das klingt hart, doch die Alternative ist eine Katastrophe: ist der alte Knoten in Wahrheit oben und nur sein Netz getrennt, läuft dieselbe Maschine an zwei Stellen und schreibt von beiden Seiten auf dieselbe Platte. Die Daten werden unwiederbringlich beschädigt. Darum zieht das Cluster es vor, einen Knoten abzuschalten, bei dem es unsicher ist.

Das Hochfahren. Die Maschine startet auf dem neuen Knoten von vorn. Das Betriebssystem fährt hoch, Dienste starten, eine Datenbank erholt sich, falls es eine gibt. Diese Zeit ist die normale Startzeit deiner Maschine; das Cluster hat keine Möglichkeit, sie zu verkürzen.

Die Summe liegt in den meisten Umgebungen im Minutenbereich. Sie ist nicht null und wird es nicht sein.

Drei Bedingungen, damit HA überhaupt greift

Eine Mehrheit. HA hängt daran, dass das Cluster entscheiden kann. Ohne Mehrheit wird nichts verschoben. HA in einem Cluster aus zwei Knoten einzuschalten heißt, ein Sicherheitsnetz zu bauen, das genau dann versagt, wenn du es am nötigsten brauchst.

Die Sichtbarkeit der Platte vom anderen Knoten. Soll die Maschine auf dem neuen Knoten hochkommen, muss sie an ihre Platte kommen. Eine Maschine, die nur auf lokalem Speicher liegt, kann nirgendwohin.

Kapazität. Die verbleibenden Knoten müssen auch die Last des ausgefallenen tragen können. Sind beide Knoten zu achtzig Prozent voll, rettet dich HA nicht, es reißt auch den zweiten Knoten mit.

Schalte HA nicht für jede Maschine ein

Jede Maschine mit eingeschalteter HA wird zu etwas, das das Cluster ständig beobachtet und nach eigenem Ermessen startet oder stoppt. Das ist nicht immer, was du willst.

Der Prüfstein ist einfach: käme diese Maschine um drei Uhr nachts von selbst auf einem anderen Knoten hoch, würde es mich am Morgen beruhigen oder beunruhigen, das zu erfahren? Beruhigt es, schalte HA ein. Beunruhigt es, lass es; triff die Entscheidungen für diese Maschine selbst.

Was Atlas tut

Atlas markiert gesondert die Maschinen, die der Hochverfügbarkeitsverwaltung überlassen sind. Am meisten hilft das bei der Wartung: werden vor einer Aktualisierung die Maschinen eines Knotens aufgelistet, ist getrennt sichtbar, welche von deiner Entscheidung und welche von der des Clusters abhängen. Von Hand verschieben und der Verwaltung überlassen sind verschiedene Dinge, und sie zu verwechseln wird teuer.

Ein kleines, aber bedeutsames Verhalten: wurde auf der Installation nie Hochverfügbarkeit eingerichtet, sieht Atlas, dass die zugehörigen Konfigurationsdateien fehlen, und stellt diese Frage gar nicht erst, es gibt eine leere Antwort zurück. In einer Umgebung ohne HA hält das Produkt also weder dich noch das System damit auf, etwas zu suchen, das es nicht gibt.

Und eine Grenze gehört klar ausgesprochen: Atlas trifft und ändert die HA-Entscheidung des Clusters nicht. Ob eine Maschine der HA überlassen wird, ist deine Sache und die von Proxmox; Atlas macht es sichtbar, es entscheidet nicht für dich.