Home 
ORDIX News 2/2006 Unix/Linux/Open Source
ORDIX News 2/2006 Unix/Linux/Open Source
ORDIX News 2/2006 Unix/Linux/Open Source
ihrer MySQL-Applikationen haben.
| Cluster Eine Gruppe von vernetzten Computern, die von außen in vielen Fällen als ein Computer gesehen werden kann. Ziel des "Clustering" besteht meistens in der Erhöhung der Rechengeschwindigkeit und/oder der Verfügbarkeit gegenüber einem einzelnen Computer. |
| Node Der Begriff Node (Knoten) bezeichnet einen einzelnen Rechner in einem Cluster. Oftmals ist ein Node mit einer bestimmten Aufgabe betraut. |
| Storage Node Node zum Schreiben und Lesen von Daten. |
| SQL-Node Node für die Annahme und Verarbeitung der Anfragen von Applikationen und Usern |
| Management Node Node zur Verwaltung und Kontrolle der anderen Knoten |
| Single Point of Failure Unter einem Single Point of Failure oder kurz SPoF versteht man eine Komponente im Cluster, deren Ausfall den Komplettausfall des Clusters nach sich zieht. |
| Split Brain Ein Zustand in einem Cluster, in dem sich mehrere (Storage-)Nodes im aktiven Modus befinden. |
Weiterführende Links
Derzeit stehen circa 10 unterschiedliche Storage-Engines für unterschiedliche Anforderungsbereiche zur Verfügung [1].
Der Einfachheit halber gibt es für den Cluster-Betrieb auch eine eigene Storage-Engine: Network Database (NDB). Es ist allerdings darauf zu achten, dass diese Storage-Engine nur in den Downloadpaketen [2] enthalten ist, welche in ihrem Namen die Erweiterung "-max" tragen. Einschränkungen gibt es aktuell leider noch hinsichtlich der Datenbankgröße und der Fremdschlüsselunterstützung.
Sämtliche Daten einer Cluster-Datenbank werden momentan im Hauptspeicher der "Storage-Nodes" gehalten, so dass die Größe des Hauptspeichers gleichzeitig die Größe der Datenbank limitiert. Dieses Verhalten wird mit der nächsten MySQL Version 5.1 jedoch hinfällig sein.
Weitere aktuelle Einschränkungen der Storage-Engine NBD und deren geplante Weiterentwicklung finden Sie im Internet auf verschiedenen Webseiten [3, 4].
Der MySQL-Cluster bzw. die NDB-Storage-Engine setzt auf eine Share-Nothing-Strategie. Dies bedeutet, dass die an dem Cluster beteiligten Rechner keinerlei Hardware gemeinsam verwenden.
Dies hat zwei Vorteile:
Dieser Ansatz muss natürlich auch auf alle anderen Elemente im Cluster übertragen werden. So sollten z. B. redundante Netzwerkkarten, redundante Stromversorgungen usw. Verwendung finden, um nicht an einer anderen Stelle einen Engpass zu generieren.
Um einen Cluster aufzusetzen, braucht es mindestens drei Rechner:
Zwei Rechner sollten dabei die Verwaltung der Daten übernehmen, also die NDB Storage-Engines betreiben (Storage-Nodes). Zusätzlich können diese Rechner auch die mysqld-Prozesse (SQL-Nodes) betreiben, über welche die Applikationen bzw. Anwender ihre Anfragen absetzen.
Der dritte Rechner sorgt für die Organisation der Storage- und SQL-Nodes und übernimmt deren Überwachung (Management-Node).
Für unser Installationsbeispiel haben wir jedoch ein erweitertes Szenario gewählt. Hier übernehmen zwei separate Rechner die Rolle der SQL-Nodes, so dass insgesamt fünf Rechner (siehe Abbildung 1) an dem Cluster beteiligt sind:
 |
| Abb. 1: Die SQL- und Storage-Nodes werden vom Management-Server koordiniert. |
Die Installation eines Clusters sollte mit den Storage-Nodes beginnen. Dazu wird, wie gewohnt, die MySQL-Software installiert. Wahlweise kann man sich die Quell- oder Binärpakete herunterladen [5]. Beim Installieren eines Quellpaketes sollte unbedingt darauf geachtet werden, dass die Option -with-db-cluster aktiviert sein muss.
Die Konfiguration der Storageknoten im Anschluss an die Installation ist unproblematisch. In der entsprechenden Konfigurationsdatei (unter Linux z. B. /etc/my.cnf) muss lediglich hinterlegt werden, dass diese MySQL-Installation Teil eines Clusters ist.
Zusätzlich muss definiert werden, wo sich der dazugehörige Management-Node befindet. Die Installation der SQL-Nodes vollzieht sich genau nach demselben Muster (siehe Beispiel einer Konfigurationsdatei in Abbildung 2).
[mysqld] ndbcluster [mysql_cluster] ndb-connectstring = 172.17.30.100 # IP of Management Server |
Die unterschiedlichen Aufgaben der Storage- und SQL-Nodes ergeben sich - trotz einer identischen Konfiguration - später durch den Start unterschiedlicher Dienstprogramme auf den Nodes.
Für die Installation des Management-Nodes sind aus dem MySQL-Paket eigentlich nur zwei Programme notwendig. Aus dem Binärpaket können diese direkt extrahiert und auf dem Server abgelegt werden:
.../bin/ndb_mgm (Management-Client)
.../bin/ndb_mgmd (Management-Server)
Der Management-Server stellt im Cluster die zentrale Kommunikationsplattform dar und regelt die Verteilung der Aufgaben zwischen den beteiligten Systemen.
Über den Management-Client können aktuelle Statusinformationen über die Systeme bezogen, sowie einige "Verwaltungsaktionen" für die Clusterkomponenten veranlasst werden.
Darüber hinaus sollte für den Management-Server ein eigenes Arbeitsverzeichnis angelegt werden, welches die Konfigurationsdatei des Management-Nodes und später die erzeugten Logfiles des Clusters aufnehmen kann (unter Linux z. B. /var/lib/mysql-cluster).
Die Konfiguration ist im Gegensatz zu den Storage- und SQL-Nodes etwas umfangreicher, da der Management-Node alle am Cluster beteiligten Rechner und Aufgaben kennen muss (siehe Abbildung 3).
[NDBD DEFAULT] NoOfReplicas = 2 # Anzahl der beteiligten Storage-Nodes [MYSQLD DEFAULT] [NDB_MGMD DEFAULT] [TCP DEFAULT] [NDB_MGMD] HostName = 172.17.30.100 # IP des Management-Node [NDBD] HostName = 172.17.30.101 # 1. Storage-Node DataDir = /var/lib/mysql-cluster # Datenverzeichnis vom 1. Storage-Node [NDBD] HostName = 172.17.30.102 # 2. Storage-Node DataDir = /var/lib/mysql-cluster # Datenverzeichnis vom 2. Storage-Node [MYSQLD] HostName = 172.17.30.103 # 1. SQL-Node [MYSQLD] HostName = 172.17.30.104 # 2. SQL-Node |
| Abb. 3: Der Management-Node kennt die beteiligten Rechner und ihre spezifischen Aufgaben. |
Nachdem alle Komponenten installiert und konfiguriert sind, kann der Cluster gestartet werden. Als erste Komponente sollte der Management-Server hochgefahren werden, da dieser den anderen Nodes ihre Rolle im Cluster zuweist.
Dies geschieht über den Start des entsprechenden Dienstes:
ndb_mgmd
Anschließend werden die Storage-Nodes eingebunden. Dies erfolgt über den Start des MySQL-Dienstes "ndb", welchem beim allerersten Start die Option --initial spendiert werden muss:
ndb (--inital)
Abschließend werden die SQL-Nodes aktiviert. Auf diesen startet man, wie bei "gewöhnlichen" MySQL-Servern, den mysqld-Prozess mit den betriebssystemspezifischen Startskripten (unter Linux: /etc/init.d/mysql.server start). Damit ist der Cluster einsatzbereit.
Nach dem Start der Komponenten sollte überprüft werden, ob die Nodes ihre Aufgaben auch zuverlässig übernommen haben. Dazu kann auf dem Management-Node (oder auf allen anderen im Cluster befindlichen Rechnern) der entsprechende Client (ndb_mgm) genutzt werden.
Über das Kommando ndb_mgm -e show werden alle aktiven Nodes mit ihren entsprechenden Aufgaben und Stati ausgegeben (siehe Abbildung 4).
Connected to Management Server at: localhost:1186
Cluster Configuration
---------------------
[ndbd(NDB)] 2 node(s)
id=2 @172.17.30.101
(Version: 5.0.18, Nodegroup: 0, Master)
id=3 @172.17.30.102
(Version: 5.0.18, Nodegroup: 0)
[ndb_mgmd(MGM)] 1 node(s)
id=1 @172.17.30.100 (Version: 5.0.18)
[mysqld(API)] 2 node(s)
id=4 @172.17.30.103 (Version: 5.0.18)
id=5 @172.17.30.104 (Version: 5.0.18)
|
| Abb. 4: Über den Management-Client erfahren wir die Rollenverteilung im Cluster. Zunächst werden die Storage-Nodes, dann der Management-Node und anschließend die SQL-Nodes ausgegeben (vgl. Abb. 3). |
Im Prinzip könnte der Management Node nun wieder heruntergefahren werden, da alle beteiligten Rechner ihre Aufgaben und "Partner" kennen. Die reine Überwachung der Verfügbarkeit wird auch von den Storage-Nodes alleine gewährleistet.
Es gibt aber gute Gründe, warum der Management-Node weiter aktiv bleiben sollte. Über ihn können einzelne Nodes z. B. ab- oder dazugeschaltet werden oder es können auf den einzelnen Nodes Backups gestartet und auch wieder eingespielt werden.
Wie eben bereits beschrieben, sind die Storage-Nodes auch ohne den Management-Server in der Lage, den Ausfall eines Systems zu erkennen.
Allerdings gibt es einen Problemfall, bei dem die zusätzliche Überwachungsfunktionalität des Management-Nodes benötigt wird.
Sind die Storage-Nodes an zwei unterschiedlichen Standorten positioniert und kommt es zu einem Ausfall der Kommunikationsleitung (Heartbeat-Überwachung), so weiß keiner der beteiligten Storage-Nodes, ob der Partner ausgefallen oder derzeit aufgrund eines Netzwerkausfalls nur nicht zu erreichen ist (Split Brain Problem).
Es bedarf also einer Kontrollinstanz (Management-Node), die entscheidet, welcher Storage-Node weiter als Master fungiert. Dazu ist es natürlich notwendig, dass der Management-Node über eine separate Anbindung an die betroffenen Storage-Nodes verfügt (siehe Abbildung 5).
 |
| Abb. 5: Split-Brain-Problem: Bei einem Ausfall der direkten Leitung zwischen zwei Storage-Nodes muss eine dritte Instanz entscheiden, wer weiterhin als Master fungiert. Ansonsten würden in diesem Fall beide Storage-Nodes die Rolle des Masters übernehmen. |
Jetzt ist es an der Zeit, einige Crash-Szenarien zu simulieren und die Ausgabe des Management-Client (auf dem Management-Node) zu beobachten. Im ersten Schritt wird der 1. Storage-Node physikalisch ausgeschaltet (siehe Abbildung 6, [t1]).
[t1] ... [ndbd(NDB)] 2 node(s) id=2 (not connected, accepting connect from 172.17.30.101) id=3 @172.17.30.102 (Version: 5.0.18, Nodegroup: 0, Master) ... [t2] ... [mysqld(API)] 3 node(s) id=4 (not connected, accepting connect from 172.17.30.103) id=5 @172.17.30.104 (Version: 5.0.18) |
| Abb. 6: [t1] Ausfall des ersten Storage-Nodes. Der zweite Storage-Node wird im Bruchteil einer Sekunde zum neuen Master und übernimmt alle eingehenden Verbindungen. [t2] Ausfall des ersten SQL-Nodes. Die Applikationen und Anwender müssen jetzt über den zweiten SQL-Node auf ihre Daten zugreifen. |
Ohne Probleme übernimmt der 2. Storage-Node seine neue Rolle als Master. Zusätzlich wird danach ein SQL-Node "beseitigt". Die Applikationen und Anwender müssen nun über den anderen, verbliebenen SQL-Node auf ihre Daten zugreifen (siehe Abbildung 6, [t2]).
Für den Zugriff auf den richtigen SQL-Node ist in unserem Fall die Applikation selbst verantwortlich. Sie muss selbst erkennen, dass der SQL-Node 1 nicht mehr verfügbar ist und auf den 2. SQL-Node umschwenken.
Dieses Problem kann natürlich auch anders gelöst werden. Denkbar wäre z. B. der Einsatz eines Load Balancers, der im Normalfall (wenn alle SQL-Nodes arbeiten) die Anfragen gleichmäßig auf die verfügbaren Dienste verteilt.
Beim Verlust eines SQL-Nodes verteilt der Load Balancer die Anfragen dann auf die verbleibenden Systeme.
Im Portfolio der Firma MySQL AB ist der Cluster noch ein relativ neues Produkt. Die Einschränkungen der NDB-Engine sind derzeit deutlich spürbar.
Wenn diese Beschränkungen, wie in der Roadmap [4] versprochen, in der nächsten Version beseitigt werden, dürfte der MySQL-Cluster für viele Anwendungsbereiche eine interessante Alternative werden.
Besonders die Verarbeitung von größeren Datenmengen, unabhängig von der Hauptspeichergröße, muss schnellstmöglich gelöst werden.
Matthias Jung (info@ordix.de).