Immer größere Datenmassen sicher zu speichern ist eine Herausforderung für jede IT-Infrastruktur. Schon mit Gigabit-Ethernet lassen sich aber ... (mehr)

Debugging

Die möglichen Probleme mit einem Dateisystem sind sehr zahlreich. Die erhöhte Komplexität von Cluster-Dateisystemen macht das natürlich nicht einfacher. Aus OCFS2-Sicht kann es bei drei verschiedenen Schichten haken: an der Dateisystemstruktur auf der Platte, der Cluster-Konfiguration und/oder der Cluster-Infrastruktur. Zu Letzterer zählen der Netzwerkstack für Heartbeat, die Cluster-Kommunikation und eventuell auch der Zugriff auf den Datenträger. Außerdem sind hier die Probleme auf Fibre-Channel- und iSCSI-Ebene anzusiedeln.

Probleme in der Cluster-Infrastruktur untersucht der Admin wie gewöhnliche Netzwerk-, FC- oder iSCSI-Probleme. Ist die Cluster-Konfiguration nicht auf allen Knoten identisch, kann es ebenfalls zu Schwierigkeiten kommen. Der Admin kann hier mit »vi« , »scp« und »md5sum« der Sache auf den Grund gehen und das Problem lösen. Alternativ – vorausgesetzt die Cluster-Infrastruktur steht – synchronisiert ein Update der Konfiguration via »ocfs2console« die Cluster-Konfiguration auf allen Rechnern.

Es kann helfen, das problematische OCFS2-Volume komplett offline zu nehmen, also abzuhängen, und den Cluster-Service über »/etc/init.d/o2cb restart« auf allen Rechnern neu zu starten. Der Admin kann mit Hilfe von »tunefs.ocfs2« das Dateisystem sogar in eine Art Single-User-Mode setzen. Dafür setzt er den Mount-Typ von »cluster« auf »local« . Danach kann nur ein einzelner Rechner das Dateisystem mounten – und dies sogar ohne den Cluster-Stack.

Bei allen Aktionen muss dem Administrator bewusst sein, dass das Dateisystem von mehr als einem Rechner gemountet sein kann. Bestimmte Aktionen, etwa mit »tunefs.ocfs2« , funktionieren nicht, wenn ein weiterer Rechner auf das Dateisystem zugreift. Im Beispiel von Listing 6 versucht der Anwender das Label zu ändern. Der Vorgang schlägt fehl, obwohl das Dateisystem (auf diesem Rechner) offline ist. Dann hilft das Kommando »mounted.ocfs2« weiter. Es sieht im Header des OCFS2 nach, auf welchen Rechnern das Dateisystem online ist.

Listing 6

Debugging mit mounted.ocfs2

 

Die wichtigsten Daten über die Dateisystemstruktur befinden sich im Superblock. Wie andere Linux-Dateisysteme legt auch OCFS2 Sicherungskopien des Superblocks an. Das Konzept der OCFS2-Entwickler ist allerdings etwas ungewohnt: OCFS2 legt maximal sechs Kopien an und diese an nicht konfigurierbaren Offsets: 1 GByte, 4 GByte, 16 GByte, 64 GByte, 256 GByte und 1 TByte. Konsequenterweise haben OCFS2-Volumes kleiner als 1GByte keine (!) Kopie des Superblocks. Fairerweises sagt »mkfs.ocfs2« dies aber beim Anlegen des Dateisystems. Der Admin muss Ausschau nach der Zeile »Writing backup superblock: ...« halten. Ein netter Nebeneffekt der statischen Backup-Superblocks ist: Der Admin kann sie beim Filesystem-Check nach Nummern referenzieren. Im Beispiel von Listing 7 ist der primäre Superblock beschädigt, der Mount und ein simpler »fsck.ocfs2« funktionieren daher nicht. Mit Hilfe des ersten Backups gelingt aber die Wiederherstellung.

Listing 7

Superblocks wiederherstellen

 

Radio Eriwan

Im Prinzip ist es recht einfach, einen OCFS2-Cluster-aufzusetzen. Die Software ist für eine Reihe von Linux-Distributionen verfügbar, also macht schon die Installation keine großen Schwierigkeiten. Da OCFS2 mit iSCSI genauso funktioniert wie mit Fibre Channel, stellt auch die Hardware-Seite kein unlösbares Problem dar. Das Setup des Cluster-Framework ist recht einfach und sogar mit einfachen Tools wie »vi« zu bewerkstelligen.

OCFS2 bringt keine ausgeklügelten Fencing-Technologien wie andere Cluster-Dateisysteme mit. Das ist oft aber auch gar nicht nötig. Auch das Fehlen eines Cluster-fähigen Volumenmanagers erleichtert dem Anwender den Einstieg in die OCFS2-Welt. Durch die Einfachheit und geringe Komplexität im Vergleich zu anderen Cluster-Dateisystemen ist OCFS2 mehr als einen Blick wert.

Geschichtliches

OCFS2 ist ein recht junges Dateisystem. Wie die 2 im Namen bereits andeutet, ist die aktuelle Variante schon eine Weiterentwicklung. Den Vorgänger OCFS entwickelte Oracle für den ausschließlichen Einsatz im Real Application Cluster einer Oracle-Datenbank. Das neue OCFS2 sollte die Anforderung erfüllen, ein ausgewachsenes Dateisystem zu sein, das beliebige Daten speichert. Posix-Kompatibilität und die von Datenbanken gewohnte – und geforderte – Performanz waren weitere Randbedingungen. Nach zweijähriger Arbeit gaben die Entwickler Version 1.0 von OCFS2 heraus und schon ein Jahr später fand es sich im Vanilla-Kernel (2.6.16) wieder. Weite Verbreitung fand Version 1.2, was nicht zuletzt der Unterstützung der Enterprise-Linux-Distributionen zu verdanken ist. Seit einiger Zeit ist OCFS2 für die wichtigsten Vertreter der Linux-Familie verfügbar. Dies gilt gleichermaßen für die kommerziellen Varianten, etwa SLES, RHEL oder Oracle EL, wie für die freien Vertreter Debian, Fedora und Open Suse. Je nach Kernelversion erhält der Benutzer entweder die seit 2008 erhältliche Version 1.4 oder eben die zwei Jahre ältere 1.2-Variante. Der Kasten "OCFS2-Wahl" und Tabelle 3 zeigen, was es jeweils zu beachten gilt.

Tabelle 3

Neue Features von OCFS2 1.4

Feature

Beschreibung

Ordered Journal Mode

OCFS2 schreibt die Daten vor den Metadaten.

Flexible Allocation

OCFS2 unterstützt nun auch so genannte Sparse Files, also quasi Löcher in Dateien. Zusätzlich ist Pre-Allocation von Extents möglich.

Inline Data

Daten von kleinen Dateien speichert OCFS2 direkt in der Inode und nicht in Extents.

Clustered flock()

Der Systemaufruf »flock()« ist Cluster-fähig.

OCFS2-Wahl

Prinzipiell stößt der Admin auf zwei Version von OCFS2, entweder Version 1.2 oder 1.4. Was die Datenstruktur auf der Platte betrifft, sind beide Versionen kompatibel. Das bedeutet allerdings auch, auf die neuen Funktionen von 1.4 zu verzichten. Die Dokumentation listet zehn signifikante Unterschiede zwischen 1.2 und 1.4 auf. Die interessantesten führt Tabelle 3 auf. Egal für welche Version sich der Admin entscheidet, es gibt jedes Mal ein paar Dinge zu beachten. Das mit Version 1.4 ausgelieferte »mkfs.ocfs2« schaltet automatisch alle neuen Features ein und verhindert damit, dass OCFSv1.2-Rechner auf das Dateisystem zugreifen können. Der Admin kann sich behelfen, indem er mit »tunefs.ocfs2« die neuen Eigenschaften ausschaltet (Listing 8). Einfacher ist der Weg, die neuen Dateisysteme mit der Option »--fs-feature-level=max-compat« anzulegen. Auf der anderen Seite hilft »tunefs.ocfs2« bei der Migration von 1.2 zu 1.4.

Der Autor

Dr. Udo Seidel ist eigentlich Mathe- und Physiklehrer und seit 1996 Linux-Fan. Nach seiner Promotion hat er als Linux/Unix-Trainer, Systemadministrator und Senior Solution Engineer gearbeitet. Heute ist er Leiter eines Linux/Unix-Teams bei der Amadeus Data Processing GmbH in Erding.

comments powered by Disqus
Mehr zum Thema

Red Hats Global File System GFS2

Lastverteilung und Hochverfügbarkeit im SAN stellen hohe Ansprüche nicht zuletzt an das Dateisystem. Das Cluster-Dateisystem GFS2 ist angetreten, sich diesen Anforderungen zu stellen.

Artikel der Woche

Setup eines Kubernetes-Clusters mit Kops

Vor allem für Testinstallationen von Kubernetes gibt es einige Lösungen wie Kubeadm und Minikube. Für das Setup eines Kubernetes-Clusters in Cloud-Umgebungen hat sich Kops als Mittel der Wahl bewährt. Wir beschreiben seine Fähigkeiten und geben eine Anleitung für den praktischen Einsatz. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite