Fileserver System für kleine Daten

[Hades2k]

Moin,
nach dem Aufräumen meines Netzwerkes bin ich endlich beim Server angelangt und suche jetzt Erfahrungen und Empfehlung was ich damit anstellen soll

Das Ding lief bis jetzt auf Debian Basis mit zwei Raid 5 Systemen und ext4 mit Augenmerk auf Read und große Dateien.
Das Ziel soll werden das das Ding für kleine Dateien (zwischen 10 und 40Mb) optimal laufen soll und Read/Write gute Leistungen erzielt.

Die Frage ist wie sich das am besten bewerkstelligen lässt, bei Debian und Softraids bleiben? Wenn ja welches Dateisystem drüber laufen lassen? BSD als FreeNas nutzen? Raids oder ZFS oder was auch immer...

Das Gerät lief jetzt seit knapp 2 Jahren und habs nicht mehr angefasst weil es einfach genau das gemacht hat was es sollte deswegen bin ich da nen bisschen raus

[bluesunset]

10-40Mbyte Dateien fallen nicht in die klassische Kategorie von klein. XFS nimmt man eher bei solchen und größeren Dateien. Bei wirklich kleinen Dateien und als viel frequentierten Server - was privat weniger der Fall ist - eher JFS (soll damit am wenigsten Energie benötigen).
Sofern dein System gut läuft und du damit zufrieden bist, würde ich nichts ändern. Vor allem solltest du auch ein Backup der Daten haben. Sprich, auf zwei Medien. Quasi das Original und mindestens eine Kopie. Wenn du ein neues Raid erstellst fehlt dir eine Kopie.

Wenn dann stell dir lieber eine 500/750VA USV-Anlage hin.

[Hades2k]

Naja klein im Gegensatz zu dem bisherigen Einsatz von Projektfiles in der Größe 20-50Gb und viel frequentiert ist es nicht wirklich, stimmt.
Und da das ganze wird offsite gebackupped, sowie auch auf 2 externe HDDs, soweit bin ich damit zufrieden - aber da muss ich mich über die Organisation der Daten keine Gedanken machen...

[Sukrim]

"kleine Dateien" sind eher ein paar kB max. - z.B. Text-eMails in einzelnen Dateien gespeichert. 10-40 MB ist weit über dem, was derzeitige Dateisysteme als "klein" betrachten.

Ist Linux vorgegeben, oder würdest du dir auch einen Windowsserver zulegen? Welches OS haben die Clients?

Generell empfehle ich bei sowas eher WHS + externes Backup, da die Einrichtung extrem einfach ist. Wenn du aber schon Linuxerfahrung hast, und ohnehin schon einen Server laufen hast, würde ich den ehrlich gesagt einfach laufen lassen und einfach nur ein externes Backup anlegen. RAID5 hilft nur, online zu bleiben, aber hilft nicht gegen Datenverlust - sobald 2 HDDs zugleich ausfallen, sind sogar _alle_ Dateien weg.

[Hades2k]

Deswegen hab ich ja nirgendwo geschrieben das das Raid das Backup ersetzen soll sondern wie gesagt die Verfügbarkeit erhöhen und vielleicht die Geschwindigkeit stabilisieren...
Server OS ist mir wursch solange es das was es macht gut macht, Clients laufen allerdings alle auf MacOSx.
Primäreinsatz sollen Bilder und Videos werden und da fast zu 95% RAW Files deswegen hatte ich mal mit ZFS und Deduplizierung geliebäugelt weil es da sehr viele sich wiederholende Muster in den Dateien gibt sodass man vielleicht Platz sparen und Leistung gewinnen könnte. Da ich damit aber keine Erfahrung habe wollte ich mal eher in die Richtung fragen.

[bluesunset]

Bei Bildern und Videos bezweifle ich etwas die Möglichkeiten zur Reduzierung der Datenmenge anhand von blockbasierter Deduplizierung. Du wirst wohl auch schon so neumodische HDDs mit 4kByte Sektoren einsetzen...
Copy on Write wird bei dir wohl auch nicht umbedingt benötigt, da du wohl eher bearbeitete Kopien erstellst als das Original zu überschreiben.
Sofern du keine 8 besser 16GByte im Rechner hast würde ich eher von ZFS abraten.

Wie gesagt, achte auf ECC-RAM und setzte eine USV-Anlage vor den Rechner. XFS ist das Dateisystem deiner Wahl.

[Sukrim]

Solange die Muster nicht 1:1 gleich sind (z.B. mehrere Versionen der gleichen Datei) hilft dedup bei Fotos und Videos leider wenig. Das mit Backup war auch eher zur Sicherheit, falls noch andere mitlesen. Eventuell würde es sich ja sogar lohnen, auf den Windows Server 8 zu warten. Egal was die Linuxfans da immer mit LVM, BTRFS, ZFS und co. sagen - ReFS hat einige Features, die SEHR sexy klingen und die es so noch nirgendwo gibt!

[bluesunset]

Eventuell würde es sich ja sogar lohnen, auf den Windows Server 8 zu warten. Egal was die Linuxfans da immer mit LVM, BTRFS, ZFS und co. sagen - ReFS hat einige Features, die SEHR sexy klingen und die es so noch nirgendwo gibt!

Welche Features gibt es so noch nicht wo anders? Etwa das "Datenbank" basierte Dateisystem, welches Microsoft übrigens schon für Windows Longhorn aka Vista vor über 6 Jahren versprochen hat?
Hier entsteht die neue Generation von Dateisystemen für Windows: ReFS - Die Entwicklung von Windows*8 - Site Home - MSDN Blogs Volumeverfügbarkeit bei Ausfällen
Zum Thema muss man leider per Hand runterscrollen, da kein Anker gesetzt wurde.
Wie sinnvoll ist es, wenn man einen Rechner ohne ECC-Ram hat, man im schlimmsten Falle falsche Prüfsummen für die Metadaten oder gar die Daten selbst hat und diese dann vom Dateisystem ohne Nachfragen komplett gelöscht werden? Im einfacheren Falle dürfte ein defekter/nicht lesbarer Sektor innerhalb Zeit x reichen damit das Dateisystem eine ganze Datei löscht. Ich stelle mir das interessant vor bei einer virtuellen HDD für VMware und Co.
Eine Zusammenfassung gibt es auch unter Unverwüstlich - ReFS: Microsofts neues Dateisystem für Windows 8 - Golem.de wo unter anderem das Dateisystem zuerst auf Windows Servern und später auf den Clients eingeführt wird.

LVM ist btw. kein Dateisystem sondern ein Volumenmanager, der bei ZFS schon integriert ist - welches seinerseits nur unter Solaris/BSD nutzbar ist. BTRFS ist die Eigenentwicklung unter Linux eines moderneren Dateisystems mit Raidfunktionalität.
Beide, sowohl ZFS als auch BTRFS würde ich nicht als primären Produktiven Datenspeicher ohne ein kontinuierliches Backup einsetzen wollen.

JFS (IBM) und XFS (SGI) sind beides stabile Dateisysteme mit deutlich mehr als 10 Jahren produktivem Einsatz. Diese Dateisysteme sind auch erweiterbar.

Mit einem aktuellen Debian squeeze 6.0 lässt sich auch einfach ein verschlüsseltes LVM mit dem Graphischen Installer einrichten ohne Handbücher oder Tutorials zu studieren. Hätte es ja sonst auch nicht ausprobiert. Der Mensch ist halt faul...

[Sukrim]

Naja, da ReFS auch Redundanzen verwalten kann, sollten auch gekippte RAM-Bits kein Problem darstellen (und ehrlich gesagt - die sind da schon SEHR selten...). Wie reagieren denn deine Favoriten auf gekippte Bits im RAM?

Features die ich z.B. nirgendwo anders gefunden habe: 400GB HDD + 350 GB HDD + 500 GB HDD = zwischen 1250 GB und 625 (je nach Redundanzwünschen) Speicherplatz. Man braucht mehr Speicher? Festplatte kaufen, einhängen, fertig. Windows Home Server v1 konnte das damals so ähnlich, hatte aber mit VSS und diversen Attributen so seine Probleme, da das auf Dateilevel und nicht auf Blocklevel lief.
Außerdem endlich mal eine Abkehr von diesem dauernden Journaling. Desweiteren Clustering (womit ich dann vielleicht endlich alle PCs daheim clustern könnte!) und ich finde es auch recht interessant, von vornherein auf "resilience" als Designziel zu setzen. So viele Checksummen etc. hat wohl nicht mal ZFS...

ZFS und BTRFS (vielleicht?) bieten da eher was in Richtung RAID an: Man braucht gleich große Partitionen (im obigen Beispiel sehr viele 50 GB Partitionen...), die man dann spiegeln oder stripen oder XORen kann. ZFS gibt's übrigens schon länger auch unter Linux, aber nicht wirklich nativ (FUSE) und BTRFS hat noch immer(!) kein fsck - in der Zeit in der das rauskommt, bringt ja sogar MS ein neues Dateisystem raus...

Die Einrichtung kann kompliziert wie nur was sein, das wäre mir recht egal - hauptsache danach läuft das System extrem stabil und verkraftet Ausfälle/Erweiterungen/Lastspitzen gut.

[bluesunset]

Bitfehler? Kenn ich nicht.
P3-S Dual 1,4GHz 6GByte SDRAM 133 MHz registerd ECC (1GByte Module)
4x Xeon 7120N 32GByte DDR2 400MHz registerd ECC RAM gespiegelt - 16GByte Nutzbar dafür dürfen komplette Speichermodule defekt werden.
785G mit X2 250, 890FX mit X2 245e sowie nun neu 890FX mit 8120FX alle drei Rechner mit DDR3 ECC RAM.
USV-Anlagen: 4x1500VA, 2x750VA, 1x500VA

Wie sinnvoll es ist verschieden alte HDDs zu einem Software Raid1 hinzuzufügen bleibt mal dahingestellt. Bietet Microsoft auch ein schönes dump an wie XFS?

Und bezüglich deiner Seltenheit von fehlerhaftem Ram, da gabs ne schöne Veröffentlichung:
Fefes Blog
DRAM error rates: Nightmare on DIMM street | ZDNet

Was passiert bei einem Bitfehler bei einem Software Raid1 - woher soll die Software wissen welche Kopie nun die fehlerfreie ist? Prüfsummen? Wurden die ohne Fehler gespeichert, was ist wenn du zwei verschiedene Prüfsummen hast? Frag doch mal Microsoft ob sie bei Ihren Tests in den Windows 2008 Servern RAM ohne ECC drinnen hatten. Denke mal kaum.

Zu XFS noch: XFS (Dateisystem)

Informationen über freie Speicherbereiche werden in B⁺-Bäumen abgelegt, wodurch es möglich ist, passende Speicherbereiche zu finden und so eine Fragmentierung größtenteils zu vermeiden.

Ich glaube das Microsoft Ihre B+- Bäume auch als den heiligen Gral angepriesen haben...
Die 8000 PetaByte - welches ein einzelnes 64Bit XFS speichern kann - dürften Privat wohl noch einige Zeit lang ausreichen. Im Enterprise Segment ist man gerade mal bei 1-2 stelligen PetaByte Bereichen.

JFS hatte B+- sogar schon vor dem Jahre 2000, siehe:
Linux-Dateisysteme: XFS und JFS

Edit:
http://www.chip.de/artikel/Windows-L..._12859951.html

Windows Longhorn Alpha Build 4029
WinFS: Das neue Dateisystem
28.11.2002

Falls es bis Ende diesen Jahres größere Verbreitung finden sollte, hat es ja nur 10 Jahre gedauert... aber ist klar. Man hat ja erst einmal bei JFS, XFS und ZFS abschauen müssen was ein moderneres Dateisystem alles können sollte.
Und ja, ich bin etwas verärgert, da dieses Dateisystem schon für Windows Longhorn von Microsoft versprochen wurde.

[josen]

Moin,

just for the Record: XFS ist nicht nur bluesunsets Favorit. Ich habe ein Linux Software-RAID mit XFS, das Dateisystem auf diesem RAID dass ich immer wieder von Server zu Server mitschleppe wird im März acht Jahre alt und hat während der Zeit mehr Geschichten und Dramen erlebt und mehr Hardware gesehen, als mir lieb ist. Trotzdem läuft es. Und die MD5 Prüfsumme der Zufallszahlen Datei "zeitkapsel.raw" stimmt auch nach der Zeit noch.

Hier für den Serverbetrieb zu einem Dateisystem zu raten, dass nichtmal erschienen ist, ist naiv. Das Dateisystem sollte Bitfehler ohne Probleme behandeln können? Sollte? 640KB Arbeitsspeicher sollten für jeden reichen. Wie funktioniert das genau, mit dem Festplatte diesem magischen Verbund hinzufügen? Muss dafür das Dateisystem ausgehängt werden? Oder gar der Computer neugestartet werden? Das muss ich beides nicht, mein Dateisystem wird online und eingehangen vergrößert.

Ob der TE jetzt XFS nutzen sollte? Weiss ich nicht. Ich würde das Dateisystem empfehlen, mit dessen Recovery-Werkzeugen du am vertrautesten bist. Geht um deine Daten

Grüße

[Hades2k]

Haste deinen Kernel für squeeze geupdated? Der läuft bei mir ja jetzt schon so lange und war immer zufrieden damit - kann ruhig so weiter laufen

[josen]

Moin,

der Kernel rennt als Version 3.1.X, logisch. Wenn du den weiterhin einsetzen willst, schau ich mal, dass ich die kommenden Wochen ein Release fürs Web mache.

Grüße

[Sukrim]

ReFS != WinFS! WinFS war ein anderes Konzept und ist schon seit Jahren so tot wie Reiser's Frau.

ReFS lässt sich eher mit DriveExtender 2.0 wie er für WHS 2011 geplant war vergleichen - Erweiterungen gehen natürlich live und ohne Neustart. Genaueres: siehe Virtualizing storage for scale, resiliency, and efficiency - Building Windows 8 - Site Home - MSDN Blogs

Was passiert bei einem Bitfehler bei einem Software Raid1 - woher soll die Software wissen welche Kopie nun die fehlerfreie ist? Prüfsummen?

Ja, man hat eine Prüfsumme und hasht den Block jeweils auf Platte 1 und Platte 2. Es gibt dann 4 Fälle: Beide korrekt, A inkorrekt + B korrekt, A korrekt + B inkorrekt, beide inkorrekt.

Wurden die ohne Fehler gespeichert, was ist wenn du zwei verschiedene Prüfsummen hast?

Wenn man 2 verschiedene Prüfsummen hat, nimmt man den Block, der die korrekte Prüfsumme hat. Wenn beide nicht stimmen, gibt's entweder Erasure/Parity-Codes um das gekippte Bit zu retten, oder man hat eben einen Datenblock verloren. In der Praxis wird man vermutlich erstmal nochmals versuchen den Block + die Prüfsumme neu auszulesen und nochmal zu checken, daher müsste auf beiden HDDs im gleichen Sektor ein Bit kippen oder im RAM 2x hintereinander die Prüfsumme zerstört werden. Die Wahrscheinlichkeit für sowas ist auch bei nicht-ECC RAM gering. Sehr gering.

Frag doch mal Microsoft ob sie bei Ihren Tests in den Windows 2008 Servern RAM ohne ECC drinnen hatten. Denke mal kaum.

...dass die antworten werden. Aber nett getrollt/geflamed! Ich gehe mal davon aus, dass auch Microsoft-Ingenieuren die Möglichkeit in den Sinn kommt, dass man RAM nicht 100%ig vertrauen kann.

Was an B(+,*,...)-Trees besonders sein soll, lernt man im 3. Semester in Informatik. Soll MS jetzt plötzlich komplett neue Datenstrukturen erfinden (die es eventuell eh gar nicht gibt), wenn schon bekannte Lösungen für diverse Probleme publiziert sind? WinFS wird übrigens nie so kommen wie angekündigt, ReFS ist wie gesagt eher ein clustered NTFS mit Prüfsummen, Mirroring und moderneren Konzepten als wirklich "WinFS 2.0".


Zurück zum OP:
Momentan würde ich eben, wie gesagt, gar nichts an dem Setup ändern (außer eben Software aktuell halten etc) - sollte die Leistung nicht reichen, kann man sich ja Mountoptionen + Filecaching genauer ansehen. Ob jetzt XFS, ReFS, HAMMER, BTRFS oder sonstwas - es limitiert meist ohnehin das Netzwerk bei seq. Zugriff bzw. die HDD bei Randomzugriffen bzw. das verwendete Protokoll (SMB, NFS...) bei beidem, aber kaum das Dateisystem.

[gea]

Deswegen hab ich ja nirgendwo geschrieben das das Raid das Backup ersetzen soll sondern wie gesagt die Verfügbarkeit erhöhen und vielleicht die Geschwindigkeit stabilisieren...
Server OS ist mir wursch solange es das was es macht gut macht, Clients laufen allerdings alle auf MacOSx.
Primäreinsatz sollen Bilder und Videos werden und da fast zu 95% RAW Files deswegen hatte ich mal mit ZFS und Deduplizierung geliebäugelt weil es da sehr viele sich wiederholende Muster in den Dateien gibt sodass man vielleicht Platz sparen und Leistung gewinnen könnte. Da ich damit aber keine Erfahrung habe wollte ich mal eher in die Richtung fragen.

Ohne Angabe wieviel Clients gleichzeiti zugreifen sollen, kann man schwer etwas empehlen.
Ich würde mir in der Reihenfolge Gedanken machen.

Können zumindest die Lesezugrifffe aus dem RAM bedient werden?
Das OS sollte daher den ganzen freien RAM zu Cachen nutzen (bei Solaris z.B. ist das die default Einstellung).
Wenn nicht, dann nach Möglichkeit ein Raid mit SSD Cache nehmen (Entweder per Raid-Controller mit SSD-Cache, SSD-only Raids oder ZFS Hybrid-Speicher)

Bei mehreren gleichzeitigen Zugriffen ist die sequentielle Raid-Leistung eher unwichtig.
Es kommt vor allem auf gute I/O Leistung an. Damit gibt es bei allen gestripten Raid's (Raid5, Raid6, Raid-Z)
Probleme. Da müssen für jeden Datenblock die Köpfe aller Platten positioniert werden. Die I/O Leistung ist dann
etwa so gut wie bei einer Platte. Ausweg: Ein Raid-10 oder bei ZFS ein Pool mit vielen gespiegelten vdevs (mehrfach gestriptes-Raid-10)

Ansosten: ZFS ist ausgereift und stabil aber auch bei einer/ wenigen Platten langsamer als andere Dateisysteme. Es skaliert allerdings sehr gut mit der Anzahl der vdevs im Pool und ist gut erweiterbar. Von der Datensicherheit (selbstreparierendes Dateisystem mit Prüfsummen auf Datenebene) und den Online-Scrubbing Möglichkeiten momentan noch einzigartig (Plattentest ohne dismount). Das wird immer wichtiger, je größer die Platten werden. Damit steigen die Fehlermöglichkeiten und die Anzahl der Silent-Errors die man mit Scrubbing beheben kann.

Echtzeit Deduplizierung wie bei ZFS ist für diesen Fall eher untauglich. Selbst wenn die Dateien 80% identische Datenblocks hätten, wäre der Performanceverlust und der Speicherbedarf viel zu hoch. Lieber mehr Platten einsetzen.