Unter einem Quorum(system) oder einer Voting Disk in einem Verteilten System versteht man eine Komponente des Cluster Managers eines Computerclusters zur Wahrung der Datenintegrität im Fall eines Teilausfalls, zu dessen Zeitdauer weiterhin Daten geschrieben werden könnten. Für jegliche Lese- und Schreiboperation müssen mehrere Knoten, angelehnt an ein Quorum in der Politik, zustimmen, oder konkreter, exklusiv gelockt werden. Wie viele Knoten für Lese- und Schreiboperationen exklusiv gelockt werden müssen, hängt davon ab, ob in dem Verteilten System Verfügbarkeit oder Konsistenz (siehe CAP-Theorem) Vorrang haben. Bei Ausfall des Cluster Interconnects (der Verbindung zwischen den Clusterknoten) besteht das Risiko einer Aufspaltung des Gesamtsystems in unerwünschterweise autonom agierende Einheiten (Netzwerkpartitionen), die fast immer die Datenintegrität bedroht (Split-Brain-Problem). Durch wechselweises oder konkurrierendes Schreiben in die logische Struktur der Voting Disk wird im Falle eines unterbrochenen Interconnects entschieden, welcher Teil des Clusters überleben soll. Die Voting Disk liegt auf Shared Storage.
Anders formuliert: Ein Cluster stimmt einer Schreiboperation zu, wenn N Knoten die Schreiboperation in ihrem Speicher umgesetzt und dies bestätigt haben. Diese Zahl N nennt man das Quorum.
Ein Beispiel für den Fall des Oracle RAC, es überlebt:
- bei asymmetrischer Teilung (z. B. 2:3 Knoten) der größere Teil
- bei gerader Teilung (z. B. 2:2 Knoten) der Teil mit dem größeren Workload.
Eine derartige Unterscheidung nach einem Ausfall des Interconnects als Kommunikationskanal wäre ohne eine „Abstimmung“ auf Massenspeicher unmöglich. Da fast alle Clustermanager auf einen Ausfall der Zwischenverbindung mit dem Neustart mindestens eines Knotens reagieren, ist auch die persistente Speicherung des Clusterstatus in der Voting Disk von Vorteil: Es entfällt ein Gutteil der Neuverhandlungen über Verfügbarkeiten und Masterstatus. Diese Verhandlungen bedingen ohne die persistente Voting Disk oft mehrere Neustarts. Damit steigt bei Verwendung eines Quorums die Verfügbarkeit der Einzelknoten durch entfallende Neustartzyklen.
Probleme und Lösungen Bearbeiten
Die Voting Disk selbst ist – sobald sie verwendet wird – integraler Bestandteil des Clusters. Ist ein vormals verfügbares Quorum während des Clusterbetriebes plötzlich nicht mehr greifbar, fällt das gesamte System aus. Dies gilt natürlich insbesondere bei Ausfall einer einzelnen Shared Storage. Den damit entstandenen Single Point of Failure zu vermeiden, ist derzeit Bestrebung aller Hersteller von Clusterware.
Der gebräuchliche Ansatz zur Lösung dieser Probleme ist die Spiegelung der Voting Disk über mehrere physische Medien. Dabei zeigen sich jedoch andere Probleme:
- Die Voting Disks müssen garantiert konsistent und mit möglichst geringer Latenz behaftet sein.
- Ebenfalls kontraproduktiv wäre ein Split-Brain-Szenario mit Aufteilung der Voting Disks zwischen den potentiell autonomen Untereinheiten. Diesen Konflikt löst z. B. Oracle Clusterware mit einer ungeraden Anzahl der Quoren.
Die Königslösung für Konsistenz-, Latenz- und Verfügbarkeitsprobleme stellt die (u. U. sehr teure) storageseitige Replikation im Storage Area Network (SAN) dar. Sie präsentiert allen Cluster-Membern transparent ein einziges repliziertes Gerät und entlastet dadurch Clusterware, Cluster-Member und Administratoren.
Literatur Bearbeiten
- Chanda Ray: Distributed Database Systems. Pearson Education India, 2009, ISBN 978-81-317-2718-8, Chapter 10: Distributed Recovery Management.
Einzelnachweise Bearbeiten
- Martin Fowler: Quorum - martinfowler.com. Abgerufen am 23. Februar 2021 (englisch).