Markenhinweise

DRBD® und LINBIT® sind Marken oder eingetragene Marken der LINBIT in Österreich, den Vereinigten Staaten und anderen Ländern.

Bei anderen in diesem Dokument genannten Namen kann es sich um Marken oder eingetragene Marken ihrer entsprechenden Eigentümer handeln.

Lizenzhinweise

Hierbei handelt es sich um ein Handelsdokument der LINBIT und Adfinis SyGroup, für das Vertriebsbedingungen gelten. Weitere Informationen dazu finden Sie unter http://links.linbit.com/t-and-c.

1. Über DRBD
2. Einleitung
   2.1. DRBD Übersicht
   2.2. Galera Cluster Übersicht
3. Vergleich
   3.1. Netzwerkverkehr
   3.2. Commit Verzögerung
   3.3. Replikation
   3.4. Lastverteilung
   3.5. Ausfallsicherung
   3.6. Resynchronisierung
4. Zusammenfassung
5. Weitere Dokumentationen

1. Über DRBD

Bei der DRBD-Software handelt es sich um eine Linux-Kernel Replikationsfunktion auf Datenblock-Ebene, die weit verbreitet als Baustein für Shared-Nothing Cluster eingesetzt wird. Sie ist in Vanilla Kernels ab Version 2.6.33 enthalten und die erforderlichen Dienstprogramme für die Benutzerumgebung werden von den meisten Distributionen mitgeliefert. Darüber hinaus verfügen viele Distributionen über neuere DRBD-Versionen als die im Kernel-Paket enthaltene in Form von Extra-Paketen.

DRBD ist in der Lage, die Replikation über mehrere Netzwerkprotokolle und (gegenwärtig) in drei Modis durchzuführen – von synchroner Replikation für lokale HA Cluster bis hin zu asynchroner Replikation für die Weiterleitung von Daten zu einem Disaster-Recovery-Standort.

DRBD wird von LINBIT entwickelt und weltweit vertrieben; dies schließt die meisten Distributionen und Architekturen ein, mit einigen wenigen SLA Ebenen bis hinzu 24/7 E-Mail und telefonischer Verfügbarkeit.

Bei Galera Cluster handelt es sich um einen synchronen Multi-Master Datenbank-Cluster, der eine hohe Verfügbarkeit durch die Replikation der Transaktionen an alle Knoten im Cluster bereitstellt. Durch die Entfernung des von einem Zwei-Phasen-Commits eingebrachten Overheads und die Weiterleitung an einen Zertifikat basierten Replikationsmechanismus ermöglicht die Lösung eine fast lineare Skalierung bei gleichzeitiger hoher Verfügbarkeit und Konsistenz.

Galera wird von Codership entwickelt und wird vollständig in die Lösungen von MariaDB integriert und unterstützt. Adfinis SyGroup ist ein Partner von MariaDB und bietet Unterstützung bei der Implementierung, Überwachung und Wartung von MariaDB basierten Infrastrukturen.

2. Einleitung

In diesem Tech-Guide werden zwei verschiedene High-Availability Lösungen für MySQL Datenbanken verglichen; Bei der einen Lösung handelt es sich um eine Block-Device basierte Replikationslösung, die andere erweitert MariaDB Internals für die Bereitstellung einer synchronen Replikation.

Es werden einige Unterschiede aufgezeigt sowie Vor- und Nachteile diskutiert.

2.1. DRBD Übersicht

Bei DRBD handelt es sich um eine Block-Device basierte Replikationslösung, die einfach sicherstellt, dass ein Bereich an Speicherblöcken (einer Partition, Festplatte oder eines logischen Laufwerks usw.) an zwei Knoten (oder mit DRBD 9 an weiteren) identisch ist.

Dies bedeutet vollständige Unabhängigkeit von der diesen Speicher nutzenden Anwendung. Sogar das Dateisystem spielt keine Rolle – XFS, ext4, BTRFS usw. funktionieren gleich gut.

DRBD wird gewöhnlich über TCP/IP Verbindungen genutzt; mit DRBD 9 steht ebenfalls ein RDMA-Transport zur Verfügung, der die Netzwerkverzögerung reduziert und somit die Anzahl der verfügbaren IOPs ein wenig erhöht.

2.2. Galera Cluster Übersicht

Galera Cluster arbeitet innerhalb des MariaDB Binärprogramms. Über die Konfigurationseinstellungen lädt das mysql Binärprogramm die von Galera geteilte Bibliothek, die die Netzwerkkommunikation und die Replikation anderer mysql Prozesse an Remote-Netzknoten ermöglicht.

Gegenwärtig ist Galera Cluster nur mit der InnoDB Storage Engine kompatibel, da nur diese Engine die erforderliche Transaktionsunterstützung bereitstellt. Die Unterstützung weiterer Storage Engines ist möglich, sobald von diesen Transaktionen unterstützt werden.

3. Vergleich

3.1. Netzwerkverkehr

Da DRBD vom Dateisystem und den darüber liegenden Anwendungsebenen nichts mitbekommt, repliziert es alle Schreibvorgänge an den Remote-Netzwerkknoten – dass heißt Anwendungsdaten, Transaktionsprotokolle, Indizes sowie Metadaten des Dateisystems (z. B. Journal des Dateisystems, Inodes, Verzeichnisse).

Galera Cluster sendet einfach die logischen Änderungen, z. B. den Inhalt der Transaktion in Form eines gepackten Galera write-sets über das Netzwerk. Ein mehrere tausend Zeilen umfassendes UPDATE Statement hat ungefähr die Größe der aktualisierten Datensätze. Es existiert kein weiterer Overhead für Indizes oder Transaktionsprotokolle.

Die Galera Cluster Kommunikation kann entweder Unicast (TCP) oder Multicast (UDP) Verbindungen nutzen. Multicast eignet sich insbesondere für ausgedehnte Umgebungen, um den Netzwerkverkehr noch weiter zu reduzieren.

3.2. Commit Verzögerung

Mit DRBD existiert nur ein aktiver Master für diese Datenbank; sobald der endgültige Schreibvorgang auf der Festplatte für das COMMIT abgeschlossen ist, kann DRBD eine Bestätigung an die Anwendung senden. Je nach Stapelspeicher^[1] kann die Verzögerung weniger als 100 μsec betragen.

In Galera Cluster wird der Inhalt einer Transaktion an jeden Knoten im Cluster gesendet. Sobald der Client die Transaktion an einem Knoten bestätigt, sendet dieser Knoten das write-set an die anderen Knoten, die den Empfang bestätigen. Jeder Knoten führt anschließend eine Zertifizierung des ‘write-sets’ durch und nimmt die Transaktion lokal vor. Der Ursprungsknoten bestätigt die Transaktion an den Client, nachdem die lokale Zertifizierung erfolgreich abgeschlossen wurde.

Eine zusätzliche Verzögerung entsteht nur während des Sendeschritts und entspricht der längsten Roundtrip-Zeit zu irgendeinem der Knoten im Cluster. Für die Bereitstellung innerhalb der gleichen Colocation beträgt die Verzögerung normalerweise weniger als 400 μsec.

3.3. Replikation

DRBD unterstützt die synchrone und asynchrone Replikation; Letztere ist für das Disaster-Recovery über große Entfernungen hilfreich. Für diesen Fall gibt es ein separates Produkt (den DRBD Proxy), das die Komprimierung des Datenstroms der Replikation unterstützt und somit die erforderliche Bandbreite reduziert.

Galera Cluster kann nur synchron verwendet werden. Es können jedoch an jeden Galera Cluster Knoten asynchrone Standard MariaDB Replikations-Slaves angebunden werden. Da jedoch mit jedem Commit eine zusätzliche Verzögerungszeit in Verbindung steht, ist die Anzahl der Transaktionen, die über WAN-Bereitstellungen verarbeitet werden können, begrenzt. Eine Faustregel für die maximale Anzahl an Transaktionen lautet 1/RTT trx/s.

3.4. Lastverteilung

DRBD wird normalerweise in einem Aktiv/Passiv Setup verwendet, d. h. jede DRBD Ressource ist nur an einem Knoten aktiv^[2]. Dies bedeutet, dass nur ein Knoten Zugang zum Dateisystem hat, in dem eine Datenbank gespeichert wird ^[3]; dieser Knoten ist für das gesamte Statement Parsing, Abholen der Daten, Treffen von Entscheidungen und Schreiben zuständig.

Galera Cluster ist eine reine Multi-Master Lösung – jeder Knoten stellt seine eigenen Ressourcen bereit. Die einzige Auswirkung auf die Leistung entsteht durch das Senden der Transaktion an alle Knoten. Jeder Knoten kann für schreibgeschützte Anfragen verwendet werden, somit skaliert die Lese-Leistung linear. Optimistisch betrachtet kann ein gewisser Grad an Skalierbarkeit der Schreibvorgänge erreicht werden. Dies hängt jedoch von der Anwendungsstruktur ab^[4], bestenfalls kann die Schreibleistung um ca. 15 % gesteigert werden.

3.5. Ausfallsicherung

In einer HA-Umgebung muss ebenfalls eine Vorausplanung im Falle von Problemen vorhanden sein.

Wenn der aktive Knoten in einer DRBD Umgebung (aus welchen Gründen auch immer) ausfällt, muss der Cluster Stapel (normalerweise Pacemaker mit Heratbeat oder Corosync) das Problem erkennen und den Dienst auf einen anderen Knoten umschalten. Im schlimmsten Fall zieht dies eine Überprüfung des Dateisystems, eine Datenbankwiederherstellung und anschließend die Wartezeit nach sich, die erforderlich ist, um die Cachespeicher wieder verfügbar zu machen^[5].

Wenn bei Galera Cluster ein einziger Knoten ausfällt, arbeiten die verbleibenden Knoten im Cluster ohne Unterbrechung weiter. Ein Client, der gerade mit dem ausgefallenen Knoten verbunden ist, versucht die Verbindung über einen Loadbalancer^[6] wiederherzustellen. Die anderen Clients sind keiner Unterbrechung ausgesetzt. Wenn der ausgefallene Knoten wieder in Betrieb ist, kann eine Überprüfung des Dateisystems und eine Wiederherstellung der Datenbank erforderlich sein, wodurch dieser Knoten innerhalb dieser Zeit nicht für den Lastausgleich zur Verfügung steht.

3.6. Resynchronisierung

Nach einem Ausfall muss der ausgefallene Knoten sicherstellen, dass er die neuesten Daten erhält.

Das sich in der Block-Device Ebene befindende DRBD hält eine Bitmap der Dirty Datenböcke bereit und übernimmt diese einfach, sobald die DRBD Verbindung nach dem Ausfall wiederhergestellt ist. Der Kopiervorgang erfolgt in der auf der Festplatte vorliegenden Reihenfolge; die Leistung wird nur durch die Speicher- und Netzwerkhardware begrenzt. Bei einem 10 GBit Netzwerk und FusionIO Karten sollten 1,2 GByte/Sek. erreicht werden können.

Galera Cluster verfügt über zwei Wege für die Aktualisierung eines sich anschließenden Knotens. Wenn der Knoten bereits zuvor ein Mitglied des Clusters war und den Cluster nur für kurze Zeit verlassen hat^[7], versucht der Knoten einen Incremental State Transfer (IST) durchzuführen, indem er die Änderungen aus dem ‘write-set’ Cache eines anderen Knotens im Cluster herunterzieht.

Wenn kein anderer Knoten im Cluster die für den IST erforderlichen Änderungen aus seinem ‘write-set’ Cache zur Verfügung stellen kann oder wenn ein neuer Knoten dem Cluster hinzugefügt wird, wird ein Snapshot State Transfer (SST) durchgeführt. Dies bedeutet, dass alle Daten aus der Datenbank an den sich anschließenden Knoten übertragen werden. Galera wählt einen sogenannten Donor Knoten, der die Quelle für den Transfer darstellt. Da ein Donor einen großen Einfluss auf die Leistung haben kann, werden Donor-Knoten häufig aus dem Lastausgleich ausgeschlossen, um eine konsistente Lese- und Schreibleistung innerhalb des Clusters zu gewährleisten.

4. Zusammenfassung

Es folgt eine abschließende Tabelle auf Grundlage der oben diskutierten Themen.

	DRBD	Galera Cluster	Vorteil
Netzwerkverkehr	Alle geänderten Datenblöcke	nur Transaktionsinhalte	Galera
Verzögerung	μsec bis msec, je nach Speichersystem	msec, aufgrund von Userspace/Kernel Übergängen	DRBD
Replikation	synchron oder asynchron (Disaster-Recovery)	synchron oder asynchron	DRBD/Galera
Lastausgleich	Daten auf Datenblockebene können von anderen Knoten gelesen werden	vollständiger Multi-Master	Galera
Ausfallsicherung	Über Cluster-Stapel; Ausfallzeit Sekunden oder Minuten	andere Knoten arbeiten ohne Unterbrechung weiter	Galera
Resynchronisierung	Nur geänderte Datenblöcke, Datenblockgerät Reihenfolge	IST/SST	–

 

5. Weitere Dokumentationen

Die DRBD Projektseite. Unter der Adresse http://drbd.linbit.org, mit einer Menge an Informationen einschließlich eines Benutzerhandbuchs mit einem Umfang (bei der letzten Zählung) von 172 Seiten im PDF-Format – eine der umfangreichsten Projektdokumentationen in der Open Source Welt!

Die LINBIT Home Page. Die Website http://www.linbit.com beantwortet alle Ihre Fragen über den zahlungspflichtigen Support von den Entwicklern. Eine Übersicht über die unterstützten Plattformen, SLAs und Preise finden Sie unter http://www.linbit.com/en/products-and-services/drbd-support/pricing?id=358

Die Adfinis SyGroup Home Page. “We are the Linux Engineers” lautet der stolze Slogan auf https://adfinis.com. Mit mehr als 15 Jahren Linux-Erfahrung ist Adfinis SyGroup die erste Adresse in der Schweiz.

Die MariaDB Home Page. Die MariaDB Corporation https://mariadb.com ist die treibende Kraft hinter der Entwicklung von MariaDB und stellt zusammen mit ihren Partnern den Support und die Betreuung für MariaDB Produkte bereit.

---

1. RAID Controller mit BBU, FusionIO Karten und einige SSDs ↩

2. Die Verfügbarkeit eines Aktiv/Aktiv Cluster durch Aufteilen der aktiven Ressourcen auf die Knoten wird empfohlen. ↩

3. Das Aufteilen einer Datenbank funktioniert nicht. Sie können jedoch mehrere MySQL-Prozesse in einem DRBD-Cluster ausführen, bei dem jeder über eine eigene Datenbank und separate Service-IP-Adressen verfügt. ↩

4. z. B. Datenbank Hot Spots ↩

5. All dies kann von einem guten Speichersystem migriert werden. Einer unserer Kunden konnte diese Zeit durch den Wechsel der Speicherung von Festplatten auf FusionIO Karten von ca. 45 Minuten auf 30 Sekunden reduzieren. ↩

6. z. B. MariaDB MaxScale ↩

7. Zum Beispiel aufgrund eines Neustarts oder Upgrades und anschließendem Neustart von MariaDB. ↩