3 Vorüberlegungen
Bevor wir uns die Grundkonfiguration eines Zwei-Knoten-Clusters genauer ansehen, gibt es einige grundlegende Überlegungen.
Wenn Sie Ihre Auswahl bereits getroffen haben oder spezielle Anforderungen haben, können Sie dieses Kapitel getrost überspringen - allerdings auf eigene Gefahr.
Ich lese mir selbst nicht gerne endlose Einführungen durch, und ich kenne Kollegen, die die Einführungen sehr sorgfältig gelesen haben und dann nicht wussten, was sie tun sollten, wenn es an die Umsetzung ging.
Wichtig bei den Vorüberlegungen ist für mich, unnötige Arbeit zu vermeiden, damit man am Ende eines Testlaufs oder auch in einem laufenden, produktiven Cluster keine Ausfallzeiten hat.
Und nichts ist tödlicher für einen Cluster als nicht verfügbar zu sein.
Deshalb gilt auch hier das alte Heimwerker-Motto:
Erst messen - dann schneiden!
3.1 Festplattenlaufwerke - physikalisch im Vergleich zu LVM
Werfen wir also zunächst einen Blick darauf, wie das Laufwerk "konzipiert" werden sollte.
Nehmen wir zunächst ein "physisches Festplattengerät", d.h. eine zusätzliche Festplattenpartition, zusätzlich zu den "klassischen" Partitionen wie swap, root (/) und /home.
Diese Lösung hat den Vorteil, dass es keine zusätzliche "Virtualisierungsschicht" gibt, die die Verarbeitungsvorgänge aufhält, was im Zweifelsfall zu Leistungseinbußen führen könnte.
Der Nachteil ist, dass eine nachträgliche Vergrößerung oder Verkleinerung nur mit erhöhtem Aufwand durchgeführt werden kann, wenn tatsächlich Hardware ausgetauscht werden muss.
Die Verwendung von Logical Volume Manager, kurz LVM, verschafft mehr Spielraum, fügt aber eine Virtualisierungsschicht hinzu, was auf sehr engen Systemen zu den oben erwähnten Leistungseinbußen führen kann.
DRBD kann mit beiden Varianten arbeiten!
In den Systemen, die ich eingerichtet habe, verwende ich in der Regel den Logical Volume Manager, da der Vorteil des nachträglichen Hinzufügens von Festplatten den Nachteil der Leistungsverschlechterung überwiegt.
3.2 Auswahl der Filesysteme
Im Prinzip könnte ein DRBD auch als RAW-Gerät verwendet werden. Ob und welches Dateisystem auf dem DRBD-Gerät "läuft", spielt eigentlich keine Rolle. Dennoch möchte ich die unterschiedlichen Arbeitsweisen der verwendeten Dateisysteme näher beleuchten, um Ihnen die Entscheidung zu erleichtern. Alle Dateisysteme haben ihre spezifischen Vor- und Nachteile, die auf ihrer Arbeitsweise beruhen.
Aus vielleicht verständlichen Gründen werde ich an dieser Stelle nicht näher auf Baumstrukturen oder Ähnliches eingehen. Wenn Sie sich für diese speziellen Punkte interessieren, sollten Sie die einschlägige Fachliteratur oder https://www.wikipedia.com zu Rate ziehen.
3.2.1 UFS / ext2
Das gute alte "UNIX File System" - denn dafür steht UFS - wurde in den frühen 1980er Jahren entwickelt und war bis Anfang der 1990er Jahre das Standard-Dateisystem für alle UNIX-Derivate. Heute wird es jedoch nur noch in Einzelfällen verwendet.
Das Grundkonzept wurde jedoch an die folgenden Dateisystemgenerationen weitergegeben:
- Alle Daten werden in Blöcken auf der Festplatte gespeichert und
- um zu einem Datenblock zu gelangen, wird die Adresse des Speicherblocks in einem "Superblock" genannten Bereich gespeichert, auf den das Betriebssystem zuerst zugreift.
Auf diese Weise erhält man eine Baumstruktur, da jeder gespeicherten Datei eine bestimmte "Inode-Nummer" zugewiesen wird.
Wird nach einer bestimmten Datei innerhalb des Dateisystems gesucht, muss immer der gesamte Dateibaum durchsucht werden, was bei größeren Dateibäumen mit vielen Unterstrukturen vergleichsweise lange dauern kann.
Das "zweite erweiterte Dateisystem" ("second extended filesystem" ext2) übernimmt im Wesentlichen diese Struktur, doch können so genannte "Plugins" - d. h. Erweiterungen - hinzugefügt werden, um die Fragmentierung, Komprimierung und Wiederherstellung gelöschter Daten zu ermöglichen.
3.2.2 ext3 / ext4
Die Dateisysteme ext3 und ext4 haben sich aus dem Dateisystem ext2 weiterentwickelt, indem ein so genanntes journal hinzugefügt wurde und die Möglichkeit besteht, die Größe des Dateisystems zu ändern, während das Dateisystem in Gebrauch ist.
In einem Journaling-Dateisystem werden alle Änderungen in einem speziellen Speicherbereich namens journal aufgezeichnet, bevor der eigentliche Schreibvorgang in den ausgewählten Block stattfindet. Dies erleichtert die Rekonstruktion der Schreibvorgänge, wenn z. B. das System abstürzt oder der Strom während des Schreibvorgangs ausfällt.
Ein weiterer Punkt der Verbesserung von ext3 bzw. ext4 gegenüber ext2 war die Erhöhung der verwendbaren Dateisystempartitionen von 16 TB auf 32 TB für ext3 und 1 EB (= Exabyte) für ext4. Solche Gerätegrößen konnte man sich bei der Entwicklung des UFS noch gar nicht vorstellen.
Hinzu kommen die Erweiterungen hinsichtlich der Anzahl der Dateien und Verzeichnisse sowie der Größe der einzelnen Dateien, die bei ext2 noch auf 2 TB begrenzt war, bei ext3 zwischen 16 GB und 2 TB liegen konnte und bei ext4 schließlich nur durch die Größe der Festplattenpartition begrenzt ist.
3.2.3 xfs
Das Dateisystem xfs, ursprünglich von Silicon Graphics (SGI) exklusiv für das hauseigene UNIX-System ÏRIXëntwickelt, ist eines der ältesten Dateisysteme. Aber nur weil etwas in die Jahre gekommen ist, heißt das nicht, dass es "schlecht" sein muss. Mit Maximalwerten von 16 EB pro Dateisystem, einer maximalen Anzahl von 263 Dateien und einer Größe pro Datei von 8 EB setzt es Maßstäbe.
Es hat auch deutliche Vorteile gegenüber ext3 und BtrFS, insbesondere in Bezug auf die Geschwindigkeit.
Vor einiger Zeit hatte ich einen Fall, bei dem etwa 100 GB von einem Host auf einen anderen kopiert werden mussten. Das Quelldateisystem war ein BtrFS und die Kopie lief - um LAN-Ressourcen zu sparen - über ein TAR, das auf dem Quellrechner komprimiert, durch einen SSH-Tunnel geschoben und auf dem Zielrechner wieder dekomprimiert wurde.
Diese Arbeit hat etwas mehr als eine Stunde gedauert - wahrscheinlich, weil das Dateisystem viele Unterverzeichnisse hatte.
Nachdem die Arbeiten am Quelldateisystem abgeschlossen waren, u.a. wurde es auf 200 GB vergrößert, entschied ich mich spontan für xfs als neues Dateisystem.
Die Wiederherstellungszeit betrug 20 Minuten!
Natürlich bin ich seither ein bekennender Fan dieses Dateisystems, zumal sich der Durchsatz im Normalbetrieb bestätigt hat.
3.2.4 BtrFS
Das BtrFS - buchstabiert B-Tree-Filesystem und nicht "Better FS" oder gar "Butter FS" - verfolgt einen völlig anderen Ansatz als die bisher im Linux-Umfeld verfügbaren Dateisysteme. Es basiert teilweise auf den Überlegungen des ZFS, das etwa sieben Jahre zuvor ebenfalls von Sun Microsystems entwickelt wurde (inzwischen in ORACLE aufgegangen). Es verfügt über integriertes RAID, Volume Management, prüfsummenbasierten Schutz vor Datenübertragungsfehlern und verwendet copy-on-write.
copy-on-write ist eine Methode, bei der eine Kopie erst dann real ist, wenn sie von einer der Parteien geändert wird. Solange alle Beteiligten ihre Kopie nicht geändert haben, genügt es, das Original einmal zu speichern - im jeweiligen Dateisystem. Das integrierte RAID-System unterscheidet zwischen belegten und freien Datenblöcken, so dass beim Wiederaufbau eines ausgefallenen RAID-Volumes nur der belegte Speicherplatz gespiegelt werden muss, was eine enorme Zeitersparnis bedeutet. Darüber hinaus arbeitet dieses RAID mit größeren Datenblöcken als bei klassischen RAID-Verfahren. Bei einem RAID1 werden nicht alle Datenblöcke eines Datenträgers gespiegelt - unabhängig davon, ob sie belegt sind oder nicht -, sondern nur die belegten Blöcke werden auf alle verfügbaren Datenträger verteilt. Auf diese Weise kann ein RAID1 aus einer ungeraden Anzahl von Festplatten mit unterschiedlichen Kapazitäten gebildet werden, ohne dass Speicherplatz verloren geht.
Die "B-Baum-Struktur" - nach der das Dateisystem benannt ist - stammt von dem zentralen Konzept von xfs.
BtrFS wird nun von SuSE als Dateisystem der Zukunft verwendet, während RedHat im August 2017 ankündigte, dass es die langfristige Unterstützung für BtrFS in RHEL einzustellen. Wobei es bisher bei dieser Ankündigung geblieben ist und z.B. fedora1 ganz automatisch BtrFS verwendet, wenn bei der Installation nichts anderes gewählt wird.
Zusätzlich zu den oben beschriebenen Erfahrungen sollten die folgenden Überlegungen im Hinblick auf die Verwendung von BtrFS auf Produktionsservern in Verbindung mit DRBD angestellt werden:
- Die meisten Linux-Server, die als 19-Zoll-Geräte gekauft werden, sind mit einem Hardware-RAID-Controller ausgestattet. Das bedeutet, dass die RAID-Funktionalität von BtrFS hier nicht benötigt wird, da die an den RAID-Verbund angeschlossenen Festplatten ohnehin die gleiche Kapazität haben, da sonst der Hardware-RAID-Controller nicht richtig funktioniert oder der Speicherplatz nicht genutzt werden kann.
- Die oben erläuterte ...
