Das einzige, was nicht offensichtlich ist, ist die Bedeutung des Buchstabens "P". Wenn der Cluster aufgeteilt wird, entscheidet er, ob er nicht antworten soll, bis ein Quorum erreicht ist, oder ob die Daten angegeben werden sollen. Abhängig von den Ergebnissen dieser Auswahl wird das System entweder als CP oder als AP klassifiziert. Cassandra kann sich beispielsweise so und so verhalten, nicht einmal abhängig von den Clustereinstellungen, sondern von den Parametern jeder spezifischen Anforderung. Aber wenn das System nicht "P" ist und sich geteilt hat, was dann?
Die Antwort auf diese Frage ist etwas unerwartet: Der CA-Cluster kann nicht aufgeteilt werden.
Was ist dieser Cluster, der nicht geteilt werden kann?
Ein unverzichtbares Attribut eines solchen Clusters ist ein gemeinsam genutztes Datenspeichersystem. In den allermeisten Fällen bedeutet dies, dass eine Verbindung über ein SAN hergestellt wird, wodurch die Verwendung von CA-Lösungen auf große Unternehmen beschränkt wird, die eine SAN-Infrastruktur hosten können. Damit mehrere Server mit denselben Daten arbeiten können, ist ein Cluster-Dateisystem erforderlich. Solche Dateisysteme finden Sie in den Portfolios von HPE (CFS), Veritas (VxCFS) und IBM (GPFS).
Oracle RAC
Die Option Real Application Cluster wurde erstmals in der Version 2001 von Oracle 9i veröffentlicht. In einem solchen Cluster arbeiten mehrere Serverinstanzen mit derselben Datenbank.
Oracle kann sowohl mit einem Cluster-Dateisystem als auch mit einer eigenen Lösung arbeiten - ASM, Automatic Storage Management.
Jede Kopie führt ein eigenes Tagebuch. Die Transaktion wird in einer Instanz ausgeführt und festgeschrieben. Im Falle eines Instanzfehlers liest einer der überlebenden Clusterknoten (Instanzen) sein Protokoll und stellt die verlorenen Daten wieder her, wodurch die Verfügbarkeit sichergestellt wird.
Alle Instanzen verwalten ihren eigenen Cache, und dieselben Seiten (Blöcke) können sich gleichzeitig in den Caches mehrerer Instanzen befinden. Wenn eine Seite von einer Instanz benötigt wird und sich im Cache einer anderen Instanz befindet, kann sie über den Cache-Fusionsmechanismus vom „Nachbarn“ abgerufen werden, anstatt von der Festplatte zu lesen.
Aber was passiert, wenn eine der Instanzen Daten ändern muss?
Die Besonderheit von Oracle ist, dass es keinen dedizierten Sperrdienst gibt: Wenn der Server eine Zeile sperren möchte, wird der Sperrdatensatz direkt auf der Speicherseite abgelegt, auf der sich die gesperrte Zeile befindet. Dieser Ansatz macht Oracle zum Performance-Champion monolithischer Datenbanken: Der Sperrdienst wird nie zu einem Engpass. In einer Clusterkonfiguration kann diese Architektur jedoch zu starkem Netzwerkverkehr und Deadlocks führen.
Sobald ein Datensatz blockiert ist, benachrichtigt die Instanz alle anderen Instanzen, dass die Seite, auf der der Datensatz gespeichert ist, im exklusiven Modus erfasst wurde. Wenn eine andere Instanz einen Datensatz auf derselben Seite ändern muss, muss sie warten, bis die Änderungen auf der Seite festgeschrieben sind, dh die Änderungsinformationen werden in das Festplattenprotokoll geschrieben (und die Transaktion kann fortgesetzt werden). Es kann auch vorkommen, dass die Seite nacheinander um mehrere Kopien geändert wird. Wenn Sie die Seite dann auf die Festplatte schreiben, müssen Sie herausfinden, wer die aktuelle Version dieser Seite hat.
Durch das versehentliche Aktualisieren derselben Seiten auf verschiedenen RAC-Knoten wird die Datenbankleistung erheblich beeinträchtigt - bis zu einem Punkt, an dem die Clusterleistung langsamer sein kann als eine einzelne Instanz.
Die korrekte Verwendung von Oracle RAC besteht darin, Daten physisch zu partitionieren (z. B. mithilfe eines partitionierten Tabellenmechanismus) und über einen dedizierten Knoten auf jeden Partitionssatz zuzugreifen. Der Hauptzweck von RAC war nicht die horizontale Skalierung, sondern die Fehlertoleranz.
Wenn ein Knoten nicht mehr auf den Herzschlag reagiert, startet der Knoten, der ihn erkennt, zuerst die Festplattenabstimmung. Wenn der fehlende Knoten hier nicht markiert wurde, übernimmt einer der Knoten die Verantwortung für die Wiederherstellung der Daten:
- "Friert" alle Seiten ein, die sich im Cache des fehlenden Knotens befanden.
- Liest die Protokolle (Wiederherstellen) des fehlenden Knotens und wendet die in diesen Protokollen aufgezeichneten Änderungen erneut an. Dabei wird überprüft, ob andere Knoten neuere Versionen der geänderten Seiten haben.
- setzt nicht festgeschriebene Transaktionen zurück.
Um das Wechseln zwischen Knoten zu vereinfachen, hat Oracle 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 Basis bedient (z. B. eine Gruppe von Clients), arbeitet mit einem Dienst, und der für diesen Teil der Basis verantwortliche Dienst wird, wenn ein Knoten ausfällt, auf einen anderen Knoten verschoben.
IBM Pure Data Systems für Transaktionen
Die Clusterlösung für das DBMS wurde 2009 im Blue Giant-Portfolio veröffentlicht. Ideologisch ist es der Erbe des Parallel Sysplex-Clusters, das auf "konventioneller" Hardware basiert. 2009 wurde DB2 pureScale als Software-Suite veröffentlicht, und 2012 bietet 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 das umbenannte Netezza ist.
Die pureScale-Architektur sieht auf den ersten Blick wie Oracle RAC aus: Auf die gleiche Weise sind mehrere Knoten mit einem gemeinsam genutzten Speichersystem verbunden, und jeder Knoten führt eine eigene Instanz eines DBMS mit eigenen Speicherbereichen und Transaktionsprotokollen aus. Im Gegensatz zu Oracle verfügt DB2 jedoch über einen dedizierten Sperrdienst, der durch den Prozesssatz db2LLM * dargestellt wird. In einer Clusterkonfiguration 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:
- Schlossmanager;
- globaler Puffercache;
- der Bereich der Interprozesskommunikation.
Der Remote-Speicherzugriff wird verwendet, um Daten von PowerHA zu Datenbankknoten und umgekehrt zu übertragen. Daher muss die Clusterverbindung das RDMA-Protokoll unterstützen. PureScale kann sowohl Infiniband als auch RDMA über Ethernet verwenden.
Wenn ein Knoten eine Seite benötigt und sich diese Seite nicht im Cache befindet, fordert der Knoten eine Seite im globalen Cache an und liest sie nur dann von der Festplatte, wenn sie nicht vorhanden ist. Im Gegensatz zu Oracle geht die Abfrage nur an PowerHA und nicht an benachbarte Knoten.
Wenn die Instanz die Zeichenfolge ändern soll, blockiert sie sie im exklusiven Modus und die Seite, auf der sich die Zeichenfolge befindet, im freigegebenen Modus. Alle Sperren werden im globalen Sperrenmanager registriert. Nach Abschluss der Transaktion 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 mit der geänderten Zeichenfolge bereits gesperrt ist, liest der Sperrmanager die geänderte Seite aus dem Speicher des Knotens, der die Änderungen vorgenommen hat, gibt die Sperre auf, macht die geänderte Seite in den Caches anderer Knoten ungültig und gibt die Seitensperre an den Knoten weiter, der sie angefordert hat.
Schmutzige, dh geä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 nur auf diejenigen Transaktionen beschränkt, die zum Zeitpunkt des Fehlers noch nicht abgeschlossen waren: Die von diesem Knoten in den abgeschlossenen Transaktionen geänderten Seiten befinden sich im globalen Cache von PowerHA. Der Knoten wird in einer abgespeckten Konfiguration auf einem der Cluster-Server neu gestartet, setzt nicht festgeschriebene Transaktionen zurück und gibt Sperren frei.
PowerHA wird auf zwei Servern ausgeführt und der Masterknoten repliziert seinen Status synchron. Wenn der primäre PowerHA-Knoten ausfällt, arbeitet der Cluster weiterhin mit dem Standby-Knoten.
Wenn auf das Dataset über einen einzelnen Knoten zugegriffen wird, ist die Gesamtleistung des Clusters natürlich besser. PureScale bemerkt möglicherweise sogar, 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 IBM Benchmarks mit 90% Lese- und 10% Schreibarbeitslast, die den tatsächlichen Produktionsarbeitslasten sehr ähnlich sind, zeigen eine nahezu lineare Skalierung bis zu 128 Knoten. Die Testbedingungen wurden leider nicht bekannt gegeben.
HPE NonStop SQL
Das Hewlett-Packard Enterprise-Portfolio verfügt auch über eine eigene hochverfügbare Plattform. Dies ist die NonStop-Plattform, die 1976 von Tandem Computers gestartet wurde. 1997 wurde das Unternehmen von Compaq übernommen, das 2002 mit Hewlett-Packard fusionierte.
NonStop wird zum Erstellen kritischer Anwendungen verwendet, z. B. HLR- oder Bankkartenverarbeitung. Die Plattform wird in Form eines Software- und Hardwarekomplexes (Appliance) geliefert, der Rechenknoten, Datenspeichersystem und Kommunikationsausrüstung umfasst. ServerNet (in modernen Systemen - Infiniband) dient sowohl zum Austausch zwischen Knoten als auch zum Zugriff auf das Datenspeichersystem.
Frühere Versionen des Systems verwendeten proprietäre Prozessoren, die miteinander synchronisiert wurden: Alle Vorgänge wurden synchron von mehreren Prozessoren ausgeführt. Sobald einer der Prozessoren falsch war, wurde er ausgeschaltet und der andere funktionierte weiter. Später wechselte das System zu herkömmlichen Prozessoren (zuerst MIPS, dann Itanium und schließlich x86), und andere Mechanismen wurden für die Synchronisation verwendet:
- Nachrichten: Jeder Systemprozess hat 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 Moment zu arbeiten, der durch die letzte Nachricht bestimmt wurde.
- : , , ; , /.
Seit 1987 läuft auf der NonStop-Plattform ein relationales DBMS - zuerst SQL / MP und später SQL / MX.
Die gesamte Datenbank ist in Teile unterteilt, und jeder Teil ist für seinen eigenen DAM-Prozess (Data Access Manager) verantwortlich. Es bietet einen Mechanismus zum Schreiben, Zwischenspeichern und Sperren von Daten. Die Datenverarbeitung wird vom Executor Server-Prozess ausgeführt, der auf denselben Knoten wie die jeweiligen Datenmanager ausgeführt wird. Der SQL / MX-Scheduler teilt Aufgaben zwischen Ausführenden auf und führt die Ergebnisse zusammen. Wenn konsistente Änderungen vorgenommen werden müssen, wird das von der TMF-Bibliothek (Transaction Management Facility) bereitgestellte Zwei-Phasen-Festschreibungsprotokoll verwendet.
NonStop SQL weiß, wie Prozesse priorisiert werden, damit lange analytische Abfragen die Ausführung von Transaktionen nicht beeinträchtigen. Ihr Zweck ist jedoch genau die Verarbeitung von kurzen Transaktionen, nicht die Analyse. Der Entwickler garantiert die Verfügbarkeit des NonStop-Clusters auf der Ebene von fünf Neunen, dh die Ausfallzeit beträgt nur 5 Minuten pro Jahr.
SAP HANA
Die erste stabile Version des HANA DBMS (1.0) fand im November 2010 statt, 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 und MAX DB.
Das Wort "HANA" selbst ist eine Abkürzung für High Performance ANalytical Appliance. Dieses DBMS wird in Form von Code geliefert, der auf allen x86-Servern ausgeführt werden kann. Industrielle Installationen sind jedoch nur auf zertifizierten Geräten zulässig. Es gibt Lösungen von HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi und NEC. Einige Lenovo-Konfigurationen ermöglichen sogar den Betrieb ohne SAN - ein GPFS-Cluster auf lokalen Festplatten spielt die Rolle des gemeinsam genutzten Speichers.
Im Gegensatz zu den oben aufgeführten Plattformen ist HANA ein speicherinternes DBMS, dh das primäre Image der Daten wird im RAM gespeichert, und im Notfall werden nur Protokolle und regelmäßige Snapshots zur Wiederherstellung auf die Festplatte geschrieben.
Jeder Knoten des HANA-Clusters ist für seinen eigenen Teil der Daten verantwortlich, und die Datenzuordnung wird in einer speziellen Komponente gespeichert - dem Nameserver, der sich auf dem Koordinatorknoten befindet. Daten zwischen Knoten werden nicht dupliziert. Auf jedem Knoten werden auch Sperrinformationen gespeichert, das System verfügt jedoch über einen globalen Deadlock-Detektor.
Wenn ein HANA-Client eine Verbindung zu einem Cluster herstellt, lädt er seine Topologie und kann in Zukunft direkt auf jeden Knoten zugreifen, je nachdem, welche Daten er benötigt. Wenn eine Transaktion die Daten eines einzelnen Knotens beeinflusst, kann sie von diesem Knoten lokal ausgeführt werden. Wenn sich jedoch die Daten mehrerer Knoten ändern, kontaktiert der Initiatorknoten den Koordinatorknoten, der die verteilte Transaktion öffnet und koordiniert, und schreibt sie mithilfe eines optimierten Zwei-Phasen-Festschreibungsprotokolls fest.
Der Koordinatorknoten wird dupliziert. Wenn der Koordinator ausfällt, übernimmt der Sicherungsknoten sofort. Wenn jedoch ein Knoten mit Daten ausfällt, besteht die einzige Möglichkeit, auf seine Daten zuzugreifen, darin, den Knoten neu zu starten. In HANA-Clustern wird in der Regel ein Ersatzserver beibehalten, um den verlorenen Knoten so schnell wie möglich neu zu starten.