Bei der Wahl des „richtigen“ Dateisystems unter Linux & Co. ist nicht immer trivial wie gedacht. Zum Betrieb eines kleinen LAMP oder LEMP Server tut es das Standard Linux Dateisystem ext4. Benötigt man zum Beispiel aber eine Plattform um Datenaustausch mit großen Datenmengen und vielen Dateien, die dann auch noch flexibel sein soll, ist die Planung des Dateisystems schon mal kniffelig. Das gleiche gilt beim Einsatz von Datenbanken, da auch hier die Wahl des Dateisystems einen großen Einfluss auf die Leistung haben kann. Aus diesem Grund möchte der Artikel ein paar Denkanstöße geben und Überlegungen aufzeigen die man anstellen sollte um das passende Dateisystem auszuwählen. Aber im Endeffekt muss das jeder für sich entsprechend seinen Anforderungen selbst entscheiden – mit etwas Unterstützung des Beitrags.
Wirft man einen Blick auf die aktuellen lokalen Dateisysteme, so sind es effektiv nur ein paar wenige die eine Rolle spielen. Als erstes ist hier ext4 zu nennen, gefolgt von XFS und den neuen Vertretern btrfs und ZFS. Nicht zu vergessen der Logical Volume Manager LVM2. Dieser ist zwar kein Dateisystem gehört aber trotzdem mit dazu. Grundsätzlich unterscheiden sich ext4 und XFS zu btrfs und ZFS darin, dass die beiden ersten keinen Volumen Mananger oder auch RAID direkt im Dateisystem implementiert haben und auch keine Prüfsummen zur Verfügung stellen. Wird bei ext4 oder XFS ein Volume Manager benötigt, kommt LVM2 zum Einsatz.
Schaut man sich die Distributionen RHEL/CentOS, SLES oder Ubuntu an zeigt deutliche Unterschiede. RHEL/CentOS setzen auf XFS mit der Option LVM, SLES auf btrfs für das root-Dateisystem und XFS für die Partitionen der Daten. Bei Ubuntu ist es ext4 mit optionalen LVM und ab 16.04 sogar ZFS, wobei XFS natürlich auch zur Verfügung steh. Diese Unterschiede zeigen sich auch in der Weiterentwicklung bzw. in dem Engagement von Redhat, SuSE und Canonical. Redhat treibt die Weiterentwicklung von XFS voran und hat sich passend zur Strategie Permabit einverleibt. Die Unterstützung von btrfs wird hingegen eingestellt und in RHEL 8 dürfte diese entsprechend den Ankündigungen nicht mehr vorhanden sein. SuSE hingegen treibt seinerseits die Entwicklung von btrfs massiv voran. Canonical sieht die Zukunft eher bei ZFS, btrfs ist hier ebenfalls kein großes Thema. Grundsätzlich unterstützen alle aber den supporteten Einsatz ext4 und XFS.
Das Dateisystem ext4 ist seit 2008 der Nachfolger von ext3 und wird direkt vom Kernel unterstützt. XFS ist ursprünglich von SGI aus dem Jahr 1994 und gilt als eines der stabilsten Dateisysteme überhaupt. Es wurde von Beginn an als 64-bit Dateisystem entwickelt und kam auf SGI eigener Hardware und eigenen IRIX zum Einsatz. Seit 2001 steht es für Linux zur Verfügung und wird entsprechend gepflegt und vor allem auch erweitert. In 2016 kam CoW mit dem Kernel 4.13 hinzu. ZFS ist aus dem Jahr 2006 und stand mit Solaris 10 für den Einsatz bereit. btrfs kam als Beta im Jahr 2007 und in 2014 als Stabil in den Linux Kernel. ZFS ist das Vorbild von btrfs und gehören beide durch den Aufkauf von Sun Microsystems zu Oracle. In der Entwicklung hängt btrfs noch deutlich hinter ZFS zurück. Produktiv lassen sich bei btrfs nur die RAID Level 0 und 1 bzw. diese in Kombination nutzen. RAID 5 und 6 sind noch nicht für den produktiven Einsatz geeignet. Diese Einschränkungen gibt es bei ZFS hingegen nicht. Hier stehen auch entsprechend höhere RAID Level zur Verfügung.
Das besondere an diesen beiden Dateisystemen sind u.a. die Prüfsummen die zum Beispiel auch vor BitRot Fehlern schützen und natürlich der integrierte Volume Manager und Snapshots. ZFS im Besonderen und btrfs in Teilen sind primär dafür gemacht direkt auf der Hardware und vor allem ohne RAID Controller betrieben zu werden. Damit ZFS seine Stärken voll ausspielen kann ist es wichtig, dass es die Platten direkt im Zugriff hat. Ein Einsatz in virtuellen Umgebungen ist nur bei entsprechenden Rahmenbedingungen sinnvoll. Wer derzeit im großen Stil große Datenmengen ablegen bzw. bereitstellen muss und den Einsatz von ZFS plant sollte dies eher mit FreeBSD statt Linux und direkt auf der Hardware in Betracht ziehen. Die Entwicklung unter Linux ist noch nicht auf dem Niveau von FreeBSD. Dies setzt aber auch entsprechendes KnowHow voraus. Ist dieses KnowHow nicht vorhanden ist eine fertige kommerzielle Lösung wohl doch die bessere Wahl. Ein Blick Richtung Quantum (Xcellis, DXi, …) oder auch iX Systems hilft eine Menge Ärger zu vermeiden. Dazu kommt noch, wie man große Datenmengen passend sichern kann. Die Ablage der Daten ist ja nur das halbe Problem.
Da die allermeisten Systeme in virtuellen Umgebungen betrieben werden dürften, bleibt unter bestimmten Bedingungen btrfs und vor allem ext4 und XFS als mögliche Kandidaten übrig. Hier stellt sich dann die Frage, wenn ext4 und oder XFS zum Einsatz kommen mit oder ohne LVM? Wie schon eingangs erwähnt ist ext4 für eher kleine virtuelle Instanzen eine gute Wahl. Beim Einsatz von Datenbanken ist die Nutzung von LVM oft nicht supportet. Der Einsatz von LVM bietet sich natürlich für die Ablage von Daten an, da sich Dank des LVM die Speicherkapazitäten sehr einfach im laufenden Betreib erweitern lassen. XFS mit LVM bieten sich u.a. auch für Repositories an. Wer ein stabiles und auch zuverlässiges Dateisystem sucht, ist bei XFS gut aufgehoben. In virtuellen Umgebungen sollte man noch bedenken, dass ja nach Backup-Lösung ein File-Level-Restore (FLR) nicht möglich ist, wenn LVM, btrfs oder ZFS genutzt wird. Daher ist dieses auch bei der Planung zu berücksichtigen. Auf der anderen Seite bietet die Möglichkeit auf Dateisystemebene Snapshots zu erstellen auch viele Vorteile. Hier kommt es wieder genau auf die Anforderungen an, wie man sich entscheiden sollte.
Bei einer kleinen WordPress Applikation ist ext4 ohne LVM eine gute Wahl. Benötigt man eine NextCloud oder einen Seafile Server so ist zumindest für die Datenablage XFS mit LVM in Betracht zu ziehen. Wer also Stabilität und Zuverlässigkeit sucht und eher etwas konservativer herangehen möchte, was auch wirklich Sinn macht, denn hier geht es um wichtige Daten, sollte Richtung XFS und optional LVM tendieren. Der Einsatz von btrfs ist bei entsprechenden Rahmenbedingungen auch möglich, jedoch sollte man daran denken, dass Redhat dieses Dateisystem in Zukunft nicht mehr unterstützen möchte. Stand jetzt scheidet ZFS unter Linux noch aus, wobei es großes Potential für die Zukunft hat.
Ein kleiner Exkurs am Ende des Beitrags will noch etwas die verteilten Dateisysteme beleuchten. Es soll aber auch nicht über die Leuchtkraft eins Teelichts hinausgehen und sich auch nur auf GlusterFS und Ceph beschränken. Gerade im Bereich HPC, also die Systeme die in den top500.org Listen auftauchen, nutzen andere Distribiuted Filesysteme, die aber auch für (fast) alle anderen Fälle mehr als nur uninteressant sein dürften.
Mit GlusterFS und Ceph lassen sich verteilte Dateisysteme auf Basis normaler x86_64 Server mit internen Platten aufbauen. Beide setzen auf lokale Dateisysteme auf und bieten dann auch, wie zum Beispiel ZFS, entsprechenden Prüfsummen an um sich vor Fehler wie sie durch BitRot entstehen zu schützen. Der primäre Unterschied ist, dass GlusterFS ein Dateisystem mit etwas Object Store Eigenschaften ist und Ceph ein Object Store mit Dateisystem und iSCSI Option darstellt. Ceph ist jünger und gilt als etwas weniger ausgereift gegenüber GlusterFS. Aber beide bieten GeoReplication an, was sie wiederum für weltweit verteilte Systeme interessant macht. Hinter beiden steht u.a. Redhat und beide bilden die Basis der kommerziellen Redhat Storage Server mit GlusterFS und Ceph. SuSE bietet ebenfalls einen Storage mit Ceph an. Da GlusterFS als auch Ceph OpenSource Systeme sind, kann man solche Storage Lösungen auch selbst aufbauen. Aber auch hier gilt, dass das KnowHow dafür vorhanden sein muss. Kommerzielle Systeme gibt es in diesem Bereich auch. Wirft man einen Blick in den Gartner so findet man hier EMC, IBM oder Scality. Redhat gehört zu den Visionären. Aber auch Quantum mit dem Produkt Lattus gehört mit zu den großen Herstellern von Object Storages.
Die Speicherung großer Mengen an unstrukturierten Daten stellt IT Abteilungen immer mehr vor Probleme. Der klassische Weg einen Fileserver zu nutzen, wenn dieser auch heute als virtuelle Instanz betrieben wird, ist bei stetig wachsenden Volumina keine Lösung die wirklich skaliert. Daher entscheiden sich immer mehr in Richtung Enterprise NAS Lösung die im Frontend Shares bereitstellen und im Backend Storage Lösungen sind die massiv mit Disk und oder Tape skalieren und gleichzeitig eine geeignete Sicherung darstellen.
Bei Fragen stehen wir wie gewohnt zur Verfügung.