Das perfekte Server-Dateisystem

Irgendwie finde ich einfach nicht das perfekte Dateisystem für einen stabilen Betrieb.

Gerade heute Nachmittag gab es einen Ausfall eines Storage Systems, das leider nicht redundant war.

Als ich im Rechenzentrum angekommen bin, fuhr der Server nur teilweise hoch und sobald er die Root-Partition mounten hätte sollen, gab es entweder eine Kernel-Panic oder einen Neustart des Servers.

Rebootkonsole via CD: Selbes Problem.

Superklasse.

Dateisystem: ReiserFS

Ich testete nun wirklich schon viele Dateisysteme, aber bisher machte wirklich jedes Probleme.

EXT3: Schafft zu wenig Ordner pro Unterordner, was bei Storage Server bzw. großen Kunden total uninteressant ist. Performance ist auch nicht die Beste.

XFS: Schafft super viele Ordner, soll angeblich auch stabil laufen, tut es aber nicht wirklich immer. Hatte mehr defekte XFS Dateisysteme, als EXT3 (!)

ReiserFS: Etwas veraltet, Reiser 4 will ich nicht verwenden, da zu wenig lange stable

So was verwenden?

JFS: Keine Erfahrung, wurde in den 90ern von IBM entwickelt – Frage ist, ob das was taugt.

GFS: Von Redhat2003 gekauft, klingt interessant wegen dem Locking, aber ob es was taugt ebenfalls keine Ahnung

Tja, und dann bleiben nur noch Exoten.

Das Problem: Man sieht erst wie gut ein Dateisystem ist, wenn man es über eine lange Zeit testet und dies unter permanenter Last. Wenn es da besteht und das über z.B. drei Jahre, dann kann man sagen: “ja, das ist super”.

Weitere Problemstellung: Wenn man Backups macht und ebenfalls große Mengen an sehr kleinen Daten hat, dann kann ein normales Backup schon mal 2-3 Tage dauern, wenn man das System nicht komplett unter Last stellen will. Im Falle des Falles, hat man dann zwar ein Backup, es dauert aber 2-3 Tage, natürlich kann’s kürzer sein, bis es wieder hergestellt ist. Da wir sehr viel auf HP und IBM Hardware setzen, haben wir mit SCSI Festplatten und der allgemeinen Hardwareumgebung schon sehr gute Voraussetzungen, als so manch anderer. Die Hardware ist da selten der Fall – Problem wird’s dann wenn das Dateisystem versagt und dann wird es wirklich bitter, weil dann beisst man sich wirklich ins Hinterteil.

DRBD und Konsorten:

Wer denkt, dass er mit einem serverübergreifenden Array besser bedient ist, der irrt ebenfalls, denn diese Fehler werden direkt auf’s andere System gespiegelt. Außer der Fehler ist akut und schnell eingetreten, dann hat man noch eine Chance (so wie bei dem Fall heute).

Wenn wer Vorschläge hat, nur her damit 🙂

, , ,

5 thoughts on “Das perfekte Server-Dateisystem

  • Xeco says:

    ich schätze, dass das momentan noch keine wirkliche alternative für den produktiven Einsatz ist, aber ZFS klingt eigentlich sehr interessant.

  • aw says:

    Stimmt, das klingt wirklich interessant. Für Linux allerdings nicht möglich, da dies ein anderes Lizenzmodell verwendet.
    Die Portierung ist aber aktuell nur über eine nicht gerade produktivsystemtaugliche Unterplattform möglich.

    Was dran cool ist ist aber die Vereinigung der Funktionen die Raid und LVM bieten inkl. viel besseren Weiterentwicklungen.

    Ich hoffe das Gerücht wird bald wahr: http://www.linux-magazin.de/news/geruechte_um_zfs_fuer_den_linux_kernel

  • brott says:

    Zum Backup-Speed: Schonmal daran gedacht, die Clustergröße etwas runterzuschrauben? Wenn ein Cluster jetzt beispielsweise doppelt so groß als die Durchschnittsdatei ist, verlaufen deine Backups zur Hälfte mit Füllbits – wär die Clustergrößer kleiner, hätte er also nur noch die Hälfte zu kopieren.

    Hm, macht das Sinn?

  • aw says:

    Hmm – kopiert werden ja die Files und die Aktionen wie “File anlegen”, “File schließen”, … dauern ja auch – ob man die durch die Clustergröße beinflussen kann, bezweifle ich.
    Hast du schon Erfahrung damit?

  • brott says:

    Erfahrung nur in der Theorie 😉
    Aber fakt ist ja, dass immer ein ganzes Cluster kopiert werden muss – auch wenn das File nur die Hälfte davon belegt. Rechne mal die Durchschnittsgröße deiner Dateien aus und vergleichs mit der Clustergröße. Ist da enormer Unterschied, hilft eine Optimierung an der Stelle sicher etwas.

Leave a Reply