2021-03-27 23:43

Galera Clusterarithmetik

Galera Cluster ist ein Replikationslösung für MySQL und MariaDB. Galera ermöglicht es, die Datenbank als verteilten Multi-Master Cluster auf Basis einer synchronen Datenreplikation zu betreiben.

Das bedeutet, dass eine Applikation auf jedem Knoten des Clusters Lese- und Schreibzugriffe durchführen kann. Der Clustermechanismus garantiert, dass alle schreibenden Transaktionen im Cluster entweder ganz oder gar nicht ausgeführt werden, und dass das auf allen Knoten in der gleichen Reihenfolge passiert. Anwendungen bekommen bei einem Schreibzugriff erst dann eine Bestätigung, wenn die Transaktionen auf allen Knoten angekommen ist.

In MariaDB ab Version 10.1 ist Galera Cluster bereits eingebaut und muss nur noch in der Konfiguration aktiviert werden. Für MySQL muss Galera manuell installiert werden; in MySQL ab 5.7.17 steht mit Group Replication ein vergleichbarer Clustermechanismus zur Verfügung.

Absolute Mehrheit

Galera Cluster funktioniert, wie viele andere Cluster-Lösungen, Quorum-basiert. Knoten, die im Gegensatz zur Mehrheit eine Transaktion nicht ausführen oder die auf Netzwerkpakete nicht mehr reagieren, werden aus dem Cluster ausgeschlossen. Der Cluster bleibt funktionsfähig, solange eine Mehrheit (Quorum) noch nicht ausgeschlossen wurde. Die Mehrheit muss mehr als die Hälfte umfassen, damit ein Split-Brain Szenario, bei dem der Cluster in zwei gleich große Hälften zerfällt und diese separat weiter arbeiten, ausgeschlossen ist.

Daraus ergibt sich, dass der Cluster stets mit einer ungeraden Anzahl von Knoten betrieben werden sollte und davon immer mehr als die Hälfte verfügbar sein muss. Die naheliegenden Topologien eines Galera Clusters bestehen also aus mindestens drei Knoten.

Da bei IT-Systemen nicht nur einzelne Knoten ausfallen können, sondern ganze Standorte, sollten die drei Knoten an unterschiedlichen Standorten betrieben werden. Ein Standort ist dabei eine in sich geschlossene Räumlichkeit, die in Bezug auf die typischen Bedrohungen wie Stromversorgung, Brand und Überflutung unabhängig von den anderen Standorten ist. Zudem sollten die drei Standorte unabhängig vernetzt sein; d.h. es darf keine Kabelführung geben, bei der die paarweisen Verbindung zwischen zwei Standorten an einer Stelle zusammenlaufen und durch ein singuläres Ereignis gemeinsam beschädigt werden könnten.

+---+---+---+
| A | B | C |
+---+---+---+
| 1 | 1 | 1 |
+---+---+---+

Die Abbildung stellt einen Galera Cluster dar, der an drei Standorten A, B und C jeweils einen Knoten hat.

Wenn die oben genannten Anforderungen an die Unahängigkeit der Standorte und ihrer Netzwerkverbindung gegeben sind, dann toleriert dieser Cluster den Ausfall eines einzelnen Knotens oder, was in diesem Fall das gleiche ist, den Ausfall eines der drei Standorte.

Allerdings müssen gelegentlich auch Wartungsarbeiten an Clusterknoten durchgeführt werden, etwa das Einspielen von Security Updates oder Arbeiten an der Hardware. Dabei muss der Knoten vorübergehend aus dem Clusterverbund herausgenommen werden, z.B. um die MariaDB neu zu starten oder die Maschine zu rebooten.

Bei einem sauberen Shutdown wird der Knoten aus dem Galera Clusterverbund abgemeldet. Der Cluster besteht also fortan aus zwei Knoten. Hierbei ist keine Redundanz mehr gegeben. Denn wenn ein weiterer Knoten ausfällt, kann der verbleibende das nicht von einem Unterbruch der Netzwerkverbindung unterscheiden, was eine Split-Brain Situation zur Folge hätte. Keiner der beiden verbleibenden Knoten verfügt mehr über das Quorum, weshalb die Datenbank auf keinem der Knoten mehr genutzt werden kann. Wir kommen weiter unten darauf zurück.

Zwei Knoten

Obwohl ein Galera Cluster meistens auf drei oder mehr Knoten basiert, ist technisch gesehen auch der Aufbau eines 2-Node Clusters möglich.

+---+---+
| A | B |
+---+---+
| 1 | 1 |
+---+---+

Hier gilt das gleiche wie oben beim 3-Node Cluster gesagte, wenn einer der drei Knoten zwecks Wartungsarbeiten aus dem Clusterverbund herausgenommen wurde. Wegen des Quorums von 2 toleriert der Cluster weder den Ausfall eines Knotens oder Standortes, noch den Ausfall der Netzwerkverbindung zwischen ihnen.

Das kann man besser lösen.

Eine Frage der Gewichtung

In einem Galera Cluster kann das Gewicht jedes Knotens manuell eingestellt werden. Nur das Gewicht bzw. die Summe der Gewichte entscheiden über das Quorum im Cluster. Damit sind auch sinnvolle Clustertopologien mit einer geraden Anzahl an Knoten möglich.

In der folgenden Abbildung wird ein Cluster aus zwei Knoten gezeigt, bei dem einer ein Gewicht von 2, der andere den Standardwert 1 hat. Somit ist das Gesamtgewicht des Clusters 3, das Quorum liegt bei 2.

+---+---+
| A | B |
+---+---+
| 2 | 1 |
+---+---+

Dadurch werden die Redundanzeigenschaften des Clusters im Vergleich zum letzten Aufbau etwas besser. Wenn der Knoten am Standort B oder der gesamte Standort ausfällt, hat A weiterhin das Quorum und kann den Datenbank-Dienst aufrechterhalten. Umgekehrt gilt das allerdings nicht, wenn der Knoten bei A ausfällt, erbringt der andere am Standort B keinen Datenbank-Dienst mehr.

Dieses Setup kann eingesetzt werden, wenn die Anwendung ausschließlich am Standort A betrieben wird und der Standort B lediglich wegen der redundaten Datenhaltung betrieben wird.

Eine Sonderform bilden Anwendungen, wo am Standort A die Daten bearbeitet und geändert, am Standort B lediglich gelesen werden. Ein Beispiel wäre ein Content Management System, in dem Daten für Webseiten bearbeitet werden, am Standort A und der Webserver, der die Daten nur liest und öffentlich publiziert, am Standort B. Hier kann die Galera-Systemvariable wsrep_dirty_reads auf eins gesetzt werden. Das bewirkt, dass der Knoten am Standort B bei Ausfall des Clusters weiterhin für Lesezugriffe zur Verfügung steht. Der Default ist es, dass Clusterknoten außerhalb des Quorums keine Lesezugriffe mehr erlauben, um keine veralteten Daten auszuliefern. Welcher der Einstellungen sinnvoller ist, hängt von der Anwendung ab.

Zurück zu dem Beispiel mit drei Knoten. Auch hier kann es sinnvoll sein, den Knoten ein unterschiedliches Gewicht zu geben.

+---+---+---+
| A | B | C |
+---+---+---+
| 4 | 3 | 2 |
+---+---+---+

Die in der Abbildung gezeigte Topologie hat zunächst die gleichen Redundanzeigenschaften wie der ursprünglich beschriebene 1-1-1 Cluster. Es darf ein beliebiger Knoten bzw. Standort ausfallen, ohne dass das Quorum unterschritten würde und der Cluster ausfiele. Wenn ein Knoten für die Wartungsarbeiten aus dem Clusterverbund entfernt wird, hat dieser Cluster aber etwas bessere Redundanzeigenschaften als der ursprüngliche. Es darf immer noch der Knoten mit dem geringeren Gewicht ausfallen. Lediglich bei Ausfall des Knotens mit dem größeren Gewicht wäre der Clusterbetrieb eingestellt.

Wie redundant soll ein Cluster sein?

Bevor neue Cluster-Topologien diskutiert werden, sollen hier die Anforderungen gezeigt werden, die an einen Galera Cluster sinnvollerweise gestellt werden:

• Der Cluster soll den Ausfall von beliebigen Knoten tolerieren, solange es weniger als die Hälfte aller Knoten insgesamt sind. Bei drei oder vier Knoten soll also einer ausfallen können, bei fünf oder sechs Knoten zwei, bei sieben oder acht Knoten drei. Es soll kein Split-Brain Szenario möglich sein.
• Das selbe soll für die Standorte gelten. Da wir hier nur drei Standorte betrachten, soll ein Standort vollständig ausfallen dürfen, ohne den Clusterbetrieb einzuschränken.
• Die selben Eigenschaften sollten sinngemäß gelten, wenn ein beliebiger Knoten zu Wartungszwecken aus dem Clusterverbund herausgenommen wird. Auch hier soll kein Split-Brain Szenario entstehen können.

Ein Cluster mit vier Knoten?

Entsprechend der reinen Lehre soll ein Cluster immer eine ungerade Anzahl an Knoten haben. Das folgende Beispiel zeigt, warum:

+---+---+---+
| A | B | C |
+---+---+---+
| 1 | 1 | 1 |
| 1 |   |   |
+---+---+---+

Hier wird am ersten Standort ein weiterer Knoten vorgehalten, beispielsweise um ihn aus dem Anwendungsbetrieb herauszuhalten und für Backup- und Analysezwecke zu nutzen. Der dargestellte Cluster hat jedoch den Nachteil, dass es zu einer Split-Brain Situation kommen kann, wenn je zwei Knoten von den anderen zwei isoliert sind; beispielsweise, wenn der Standort A ausfällt oder von den anderen beiden Standorten netzwerktechnisch getrennt wird.

Galera Cluster erlaubt es, ein Gewicht von null einzustellen, so dass ein Knoten bei der Berechnung des Quorums nicht mehr berücksichtigt wird. Eine naheliegede Überlegung wäre, dem zusätzlichen Knoten am Standort A das Gewicht null zu geben.

+---+---+---+
| A | B | C |
+---+---+---+
| 1 | 1 | 1 |
| 0 |   |   |
+---+---+---+

Der resultierende Cluster erlaubt den Ausfall eines beliebigen Knotens oder Standorts, hat ansonsten jedoch vergleichbare Nachteile wie der 1-1-1 Cluster aus dem ersten Beispiel. Wenn einer der Knoten mit Gewicht eins zu Wartungszwecken aus dem Verbund genommen wird, bleibt ein 1-1-0 Cluster, der bei Ausfall eines weiteren eins-Knotens das Quorum verliert.

Eine bessere Topologie ist diese:

+---+---+---+
| A | B | C |
+---+---+---+
| 5 | 6 | 8 |
| 4 |   |   |
+---+---+---+

Dieser Cluster toleriert den Ausfall eines beliebigen Knotens sowie den Ausfall eines beliebigen Standortes. Zudem toleriert er den Ausfall von zwei Knoten, solange nicht der mit dem Gewicht acht dabei ist.

Weiterhin kann ein beliebiger Knoten in Wartung genommen werden. Für den verbleibenden 3-Node Cluster gilt in jedem Fall, dass ein einzelner Knoten ausfallen kann, ohne dass das Quorum unterschritten oder ein Split-Brain möglich wäre. Wenn sich der in Wartung befindliche Knoten am Standort A befindet, gilt zudem, dass ein beliebiger der drei Standorte ausfallen darf, ohne das Quorum zu unterschreiten. Wenn dagegen ein Knoten am Standort B oder C in Wartung ist, verbleibt ein 2-Node Cluster mit den oben beschriebenen Einschränkungen.

Drei von fünf

Um einen Ausfall zweier beliebiger Knoten zu tolerieren, sind mindestens fünf Knoten notwendig.

+---+---+---+
| A | B | C |
+---+---+---+
| 6 | 5 | 7 |
| 5 | 5 |   |
+---+---+---+

In dem gezeigten Cluster können zwei beliebige Knoten oder ein beliebiger Standort ausfallen, ohne das Quorum zu unterschreiten. Wenn ein Knoten in Wartung ist, kann ein weiterer beliebiger ausfallen. Sofern der in Wartung befindliche Knoten an den Standorten A oder B ist, wird zudem der Ausfall eines ganzen Standortes toleriert. Nur bei Wartungsarbeiten an dem Knoten an Standort C verbleibt ein Cluster über zwei Standorte, bei dem Standort A nicht ausfallen darf.

Volle Standortredundanz

Mit sechs Knoten ist es möglich, ohne und mit Wartungsarbeiten den Ausfall beliebiger zweier Knoten oder eines beliebigen Standortes zu tolerieren.

+---+---+---+
| A | B | C |
+---+---+---+
| 6 | 5 | 4 |
| 4 | 4 | 4 |
+---+---+---+

Der gesamte Cluster hat ein Gewicht von 27, für ein Quorum sind also 14 Punkte nötig. Bei Ausfall zweier beliebiger Knoten bleiben mindestens 17 Punkte übrig, ebenso beim Ausfall eines Standortes. Egal, welcher der Knoten in Wartung genommen wird, es verbleibt in jedem Fall ein 5-Node Cluster, bei dem zwei beliebige Knoten oder ein beliebiger Standort ausfallen können, ohne das Quorum zu unterschreiten. In allen Fällen ist kein Split-Brain Szenario möglich.

Impressum