Das CAP-Theorem ist der Eckpfeiler der Theorie verteilter Systeme. Natürlich lässt die Kontroverse darüber nicht nach: Die darin enthaltenen Definitionen sind nicht kanonisch und es gibt keinen strengen Beweis ... Dennoch verstehen wir, fest auf den Positionen des alltäglichen gesunden Menschenverstands™ stehend, intuitiv, dass der Satz wahr ist.
Das Einzige, was nicht offensichtlich ist, ist die Bedeutung des Buchstabens „P“. Wenn der Cluster geteilt wird, entscheidet er, ob er nicht antwortet, bis ein Quorum erreicht ist, oder ob er die verfügbaren Daten zurückgibt. Abhängig von den Ergebnissen dieser Auswahl wird das System entweder als CP oder AP klassifiziert. Cassandra kann sich beispielsweise in beide Richtungen verhalten, abhängig nicht einmal von den Clustereinstellungen, sondern von den Parametern jeder einzelnen Anfrage. Aber wenn das System nicht „P“ ist und sich spaltet, was dann?
Die Antwort auf diese Frage ist etwas unerwartet: Ein CA-Cluster kann nicht geteilt werden.
Was ist das für ein Cluster, der sich nicht teilen kann?
Ein unverzichtbares Merkmal eines solchen Clusters ist ein gemeinsames Datenspeichersystem. In den allermeisten Fällen bedeutet dies, dass die Verbindung über ein SAN erfolgt, was den Einsatz von CA-Lösungen auf große Unternehmen beschränkt, die in der Lage sind, eine SAN-Infrastruktur zu unterhalten. Damit mehrere Server mit denselben Daten arbeiten können, ist ein geclustertes Dateisystem erforderlich. Solche Dateisysteme sind in den Portfolios von HPE (CFS), Veritas (VxCFS) und IBM (GPFS) verfügbar.
Oracle-RAC
Die Option „Real Application Cluster“ erschien erstmals 2001 mit der Veröffentlichung von Oracle 9i. In einem solchen Cluster arbeiten mehrere Serverinstanzen mit derselben Datenbank.
Oracle kann sowohl mit einem geclusterten Dateisystem als auch mit seiner eigenen Lösung arbeiten – ASM, Automatic Storage Management.
Jede Kopie führt ihr eigenes Tagebuch. Die Transaktion wird von einer Instanz ausgeführt und festgeschrieben. Wenn eine Instanz ausfällt, liest einer der überlebenden Clusterknoten (Instanzen) sein Protokoll und stellt die verlorenen Daten wieder her – und stellt so die Verfügbarkeit sicher.
Alle Instanzen verwalten ihren eigenen Cache und dieselben Seiten (Blöcke) können sich gleichzeitig in den Caches mehrerer Instanzen befinden. Wenn außerdem eine Instanz eine Seite benötigt und diese sich im Cache einer anderen Instanz befindet, kann sie diese mithilfe des Cache-Fusion-Mechanismus von ihrem Nachbarn abrufen, anstatt sie von der Festplatte zu lesen.
Aber was passiert, wenn eine der Instanzen Daten ändern muss?
Die Besonderheit von Oracle besteht darin, dass es keinen dedizierten Sperrdienst hat: Wenn der Server eine Zeile sperren möchte, wird der Sperrdatensatz direkt auf der Speicherseite platziert, auf der sich die gesperrte Zeile befindet. Dank dieses Ansatzes ist Oracle der Performance-Champion unter den monolithischen Datenbanken: Der Sperrdienst wird nie zum Engpass. In einer Cluster-Konfiguration kann eine solche Architektur jedoch zu intensivem Netzwerkverkehr und Deadlocks führen.
Sobald ein Datensatz gesperrt ist, benachrichtigt eine Instanz alle anderen Instanzen darüber, dass für die Seite, auf der dieser Datensatz gespeichert ist, eine exklusive Sperre gilt. Wenn eine andere Instanz einen Datensatz auf derselben Seite ändern muss, muss sie warten, bis die Änderungen an der Seite festgeschrieben werden, d. h. die Änderungsinformationen werden in ein Journal auf der Festplatte geschrieben (und die Transaktion kann fortgesetzt werden). Es kann auch vorkommen, dass eine Seite nacheinander durch mehrere Kopien geändert wird und Sie dann beim Schreiben der Seite auf die Festplatte herausfinden müssen, wer die aktuelle Version dieser Seite speichert.
Das zufällige Aktualisieren derselben Seiten auf verschiedenen RAC-Knoten führt zu einem drastischen Rückgang der Datenbankleistung, bis zu dem Punkt, an dem die Clusterleistung geringer sein kann als die einer einzelnen Instanz.
Die korrekte Verwendung von Oracle RAC besteht darin, die Daten physisch zu partitionieren (z. B. mithilfe eines Mechanismus mit partitionierten Tabellen) und über einen dedizierten Knoten auf jeden Satz von Partitionen zuzugreifen. Der Hauptzweck von RAC war nicht die horizontale Skalierung, sondern die Gewährleistung der Fehlertoleranz.
Wenn ein Knoten nicht mehr auf einen Heartbeat reagiert, startet der Knoten, der ihn erkannt hat, zunächst einen Abstimmungsvorgang auf der Festplatte. Sollte der fehlende Knoten hier nicht vermerkt sein, dann übernimmt einer der Knoten die Verantwortung für die Datenwiederherstellung:
- „friert“ alle Seiten ein, die sich im Cache des fehlenden Knotens befanden;
- liest die Protokolle (Redo) des fehlenden Knotens und wendet die in diesen Protokollen aufgezeichneten Änderungen erneut an, wobei gleichzeitig überprüft wird, ob andere Knoten neuere Versionen der geänderten Seiten haben;
- Rollt ausstehende Transaktionen zurück.
Um den Wechsel zwischen Knoten zu vereinfachen, verfügt Oracle über das Konzept eines Dienstes – einer virtuellen Instanz. Eine Instanz kann mehrere Dienste bedienen und ein Dienst kann zwischen Knoten verschoben werden. Eine Anwendungsinstanz, die einen bestimmten Teil der Datenbank bedient (z. B. eine Gruppe von Clients), arbeitet mit einem Dienst, und der für diesen Teil der Datenbank verantwortliche Dienst wird auf einen anderen Knoten verschoben, wenn ein Knoten ausfällt.
IBM Pure Data Systems für Transaktionen
Im Blue Giant-Portfolio erschien 2009 eine Clusterlösung für DBMS. Ideologisch gesehen ist es der Nachfolger des Parallel Sysplex-Clusters, der auf „normaler“ Ausrüstung basiert. Im Jahr 2009 wurde DB2 pureScale als Software-Suite veröffentlicht und im Jahr 2012 bot IBM eine Appliance namens Pure Data Systems for Transactions an. Es sollte nicht mit Pure Data Systems for Analytics verwechselt werden, das nichts anderes als ein umbenanntes Netezza ist.
Auf den ersten Blick ähnelt die Architektur von pureScale der von Oracle RAC: Auf die gleiche Weise sind mehrere Knoten an ein gemeinsames Datenspeichersystem angeschlossen, und jeder Knoten führt seine eigene DBMS-Instanz mit eigenen Speicherbereichen und Transaktionsprotokollen aus. Aber im Gegensatz zu Oracle verfügt DB2 über einen dedizierten Sperrdienst, der durch eine Reihe von db2LLM*-Prozessen repräsentiert wird. In einer Cluster-Konfiguration wird dieser Dienst auf einem separaten Knoten platziert, der in Parallel Sysplex als Coupling Facility (CF) und in Pure Data als PowerHA bezeichnet wird.
PowerHA bietet die folgenden Dienste an:
- Sperrenmanager;
- globaler Puffercache;
- Bereich der Interprozesskommunikation.
Um Daten von PowerHA zu den Datenbankknoten und zurück zu übertragen, wird Remote-Speicherzugriff verwendet, daher muss die Cluster-Verbindung das RDMA-Protokoll unterstützen. PureScale kann sowohl Infiniband als auch RDMA über Ethernet nutzen.
Wenn ein Knoten eine Seite benötigt und sich diese Seite nicht im Cache befindet, fordert der Knoten die Seite im globalen Cache an und liest sie nur dann von der Festplatte, wenn sie nicht vorhanden ist. Im Gegensatz zu Oracle geht die Anfrage nur an PowerHA und nicht an benachbarte Knoten.
Wenn eine Instanz eine Zeile ändern möchte, sperrt sie diese im exklusiven Modus und die Seite, auf der sich die Zeile befindet, im freigegebenen Modus. Alle Sperren werden im globalen Sperrenmanager registriert. Wenn die Transaktion abgeschlossen ist, sendet der Knoten eine Nachricht an den Sperrmanager, der die geänderte Seite in den globalen Cache kopiert, die Sperren aufhebt und die geänderte Seite in den Caches anderer Knoten ungültig macht.
Wenn die Seite, auf der sich die geänderte Zeile befindet, bereits gesperrt ist, liest der Sperrmanager die geänderte Seite aus dem Speicher des Knotens, der die Änderung vorgenommen hat, gibt die Sperre frei, macht die geänderte Seite in den Caches anderer Knoten ungültig und Geben Sie die Seitensperre an den Knoten weiter, der sie angefordert hat.
„Verschmutzte“, also veränderte Seiten können sowohl von einem regulären Knoten als auch von PowerHA (Castout) auf die Festplatte geschrieben werden.
Wenn einer der pureScale-Knoten ausfällt, ist die Wiederherstellung auf die Transaktionen beschränkt, die zum Zeitpunkt des Ausfalls noch nicht abgeschlossen waren: Die von diesem Knoten in abgeschlossenen Transaktionen geänderten Seiten befinden sich im globalen Cache auf PowerHA. Der Knoten startet in einer reduzierten Konfiguration auf einem der Server im Cluster neu, macht ausstehende Transaktionen rückgängig und gibt Sperren frei.
PowerHA läuft auf zwei Servern und der Masterknoten repliziert seinen Status synchron. Wenn der primäre PowerHA-Knoten ausfällt, arbeitet der Cluster weiterhin mit dem Backup-Knoten.
Wenn Sie über einen einzelnen Knoten auf den Datensatz zugreifen, ist die Gesamtleistung des Clusters natürlich höher. PureScale kann sogar feststellen, dass ein bestimmter Datenbereich von einem Knoten verarbeitet wird, und dann werden alle mit diesem Bereich verbundenen Sperren lokal vom Knoten verarbeitet, ohne mit PowerHA zu kommunizieren. Sobald die Anwendung jedoch versucht, über einen anderen Knoten auf diese Daten zuzugreifen, wird die zentrale Sperrverarbeitung fortgesetzt.
Interne Tests von IBM bei einer Workload von 90 % Lesen und 10 % Schreiben, die realen Produktions-Workloads sehr ähnlich ist, zeigen eine nahezu lineare Skalierung bis zu 128 Knoten. Testbedingungen werden leider nicht bekannt gegeben.
HPE NonStop SQL
Das Hewlett-Packard Enterprise-Portfolio verfügt außerdem über eine eigene hochverfügbare Plattform. Dabei handelt es sich um die NonStop-Plattform, die 1976 von Tandem Computers auf den Markt gebracht wurde. 1997 wurde das Unternehmen von Compaq übernommen, das wiederum 2002 mit Hewlett-Packard fusionierte.
NonStop wird zum Erstellen kritischer Anwendungen verwendet – zum Beispiel HLR oder Bankkartenverarbeitung. Die Plattform wird in Form eines Software- und Hardwarekomplexes (Appliance) geliefert, der Rechenknoten, ein Datenspeichersystem und Kommunikationsgeräte umfasst. Das ServerNet-Netzwerk (in modernen Systemen Infiniband) dient sowohl dem Austausch zwischen Knoten als auch dem Zugriff auf das Datenspeichersystem.
Frühe Versionen des Systems verwendeten proprietäre Prozessoren, die miteinander synchronisiert waren: Alle Vorgänge wurden synchron von mehreren Prozessoren ausgeführt, und sobald einer der Prozessoren einen Fehler machte, wurde er ausgeschaltet und der zweite arbeitete weiter. Später wechselte das System zu herkömmlichen Prozessoren (zuerst MIPS, dann Itanium und schließlich x86) und es wurden andere Mechanismen zur Synchronisation eingesetzt:
- Nachrichten: Jeder Systemprozess verfügt über einen „Schatten“-Zwilling, an den der aktive Prozess regelmäßig Nachrichten über seinen Status sendet; Wenn der Hauptprozess fehlschlägt, beginnt der Schattenprozess ab dem in der letzten Nachricht festgelegten Zeitpunkt zu arbeiten.
- Abstimmung: Das Speichersystem verfügt über eine spezielle Hardwarekomponente, die mehrere identische Zugriffe akzeptiert und diese nur ausführt, wenn die Zugriffe übereinstimmen; Anstelle einer physischen Synchronisierung arbeiten Prozessoren asynchron und die Ergebnisse ihrer Arbeit werden nur zu E/A-Momenten verglichen.
Seit 1987 läuft auf der NonStop-Plattform ein relationales DBMS – zunächst SQL/MP, später SQL/MX.
Die gesamte Datenbank ist in Teile unterteilt, und jeder Teil ist für seinen eigenen Data Access Manager (DAM)-Prozess verantwortlich. Es bietet Datenaufzeichnungs-, Caching- und Sperrmechanismen. Die Datenverarbeitung erfolgt durch Executor-Server-Prozesse, die auf denselben Knoten wie die entsprechenden Datenmanager ausgeführt werden. Der SQL/MX-Scheduler verteilt Aufgaben auf die Ausführenden und aggregiert die Ergebnisse. Wenn vereinbarte Änderungen erforderlich sind, wird das von der TMF-Bibliothek (Transaction Management Facility) bereitgestellte zweiphasige Commit-Protokoll verwendet.
NonStop SQL kann Prozesse priorisieren, sodass lange analytische Abfragen die Transaktionsausführung nicht beeinträchtigen. Ihr Zweck ist jedoch genau die Verarbeitung kurzer Transaktionen und nicht die Analyse. Der Entwickler garantiert die Verfügbarkeit des NonStop-Clusters auf dem Niveau von fünf „Neunen“, d. h. die Ausfallzeit beträgt nur 5 Minuten pro Jahr.
SAP HANA
Die erste stabile Veröffentlichung des HANA DBMS (1.0) erfolgte im November 2010 und das SAP ERP-Paket wurde im Mai 2013 auf HANA umgestellt. Die Plattform basiert auf gekauften Technologien: TREX Search Engine (Suche im Spaltenspeicher), P*TIME DBMS und MAX DB.
Das Wort „HANA“ selbst ist ein Akronym für High performance ANalytical Appliance. Dieses DBMS wird in Form von Code bereitgestellt, der auf jedem x86-Server ausgeführt werden kann. Industrielle Installationen sind jedoch nur auf zertifizierten Geräten zulässig. Verfügbare Lösungen von HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Einige Lenovo-Konfigurationen ermöglichen sogar den Betrieb ohne SAN – die Rolle eines gemeinsamen Speichersystems übernimmt ein GPFS-Cluster auf lokalen Festplatten.
Im Gegensatz zu den oben aufgeführten Plattformen handelt es sich bei HANA um ein In-Memory-DBMS, d. h. das primäre Datenabbild wird im RAM gespeichert und nur Protokolle und regelmäßige Snapshots werden zur Wiederherstellung im Katastrophenfall auf die Festplatte geschrieben.
Jeder HANA-Clusterknoten ist für seinen eigenen Teil der Daten verantwortlich, und die Datenzuordnung wird in einer speziellen Komponente – dem Namensserver – gespeichert, der sich auf dem Koordinatorknoten befindet. Daten werden nicht zwischen Knoten dupliziert. Sperrinformationen werden ebenfalls auf jedem Knoten gespeichert, das System verfügt jedoch über einen globalen Deadlock-Detektor.
Wenn sich ein HANA-Client mit einem Cluster verbindet, lädt er dessen Topologie herunter und kann dann direkt auf jeden Knoten zugreifen, je nachdem, welche Daten er benötigt. Wenn sich eine Transaktion auf die Daten eines einzelnen Knotens auswirkt, kann sie lokal von diesem Knoten ausgeführt werden. Wenn sich jedoch die Daten mehrerer Knoten ändern, kontaktiert der initiierende Knoten den Koordinatorknoten, der die verteilte Transaktion öffnet, koordiniert und sie mithilfe eines festschreibt optimiertes Zwei-Phasen-Commit-Protokoll.
Der Koordinatorknoten ist dupliziert, d. h. wenn der Koordinator ausfällt, übernimmt sofort der Backup-Knoten. Wenn jedoch ein Knoten mit Daten ausfällt, besteht die einzige Möglichkeit, auf seine Daten zuzugreifen, darin, den Knoten neu zu starten. In der Regel unterhalten HANA-Cluster einen Ersatzserver, um einen verlorenen Knoten darauf schnellstmöglich neu zu starten.
Source: habr.com