[ZFS] Fileserver Optimization

lockdoc

lockdoc

Well-Known Member
Hallo,

ich wollte die Netzwerkdurchschlagskraft meines Fileservers optimieren und habe dazu erstmal ein paar theoretische Fragen.

Derzeitiges Setup
+ 4x 1TB HDD
+ 6 GB RAM
+ ZFS Raid-Z (1)
+ Geli Encryption
+ 1GBit/s Netzwerk

1.) Macht es Sinn alle Daten in ZFS komprimiert abzuspeichern? Theoretisch sollte dann doch die Lese/Schreib-Geschwindigkeit schneller sein, als wenn es nicht komprimiert waere... da ja die HDD's der Flaschenhals eines Systems sind.

2.) Kann ich in den Server 2 Netzwerkkarten einbauen, diese softwareseitig zu einer zusammenschliessen? Wenn ich das selbe bei den Clients mache, habe ich dann 2 GBit/s theoretischen Durchsatz?


Ich will im Prinzip einen Superschnellen Fileserver haben, so dass die Clients nur das Betriebssystem selbst installiert haben und der Rest uebers Netzwerk geschiet.
Beispielsweise sollen auch die "Disks" (Die Datei) der Virtual Machines, welche ich auf dem Client ausfuehre, auf dem Server liegen.

Macht das alles Sinn, oder waere es einfach schneller, wenn die Clients die eigene Festplatte nutzen wuerden?
 
1.) Ob sich das lohnt hängt hauptsächlich von der Art deiner Daten ab. Video- und Audiodatein lassen sich kaum weiter komprimieren. Quelltext dagegen lässt sich gut komprimieren. Wenn du GELI unterhalb von ZFS verwendest wird Disk I/O auch leicht CPU limitiert hier kann Kompression helfen.

2.) Wenn du nur einen Client hast könntest du zwei Tunnel legen. Das skaliert nicht und ist ein hässlicher Workaround. Was du wahrscheinlich suchst ist lagg(4). All diese Protokolle setzen jedoch einen geeigneten Switch voraus.
 
hi

standart trunks gehen auch jedoch auch hier geeignete switschens vorraussetzung.

thema ist auch wie gut der system bus ist ...... es bringt nix mit trunk etc zu arbeiten

wenn der bus / das system schon mit einer netzwerkarte ausgelastet ist.
latenzen erhoehen sich eher d.h . fuer tts bzw io lastige anwendungen ist ein trunk
nur bedingt geeignet ..... das ist z.b. iscsi dual pathing besser.
holger
 
lockdoc schrieb:
Ich will im Prinzip einen Superschnellen Fileserver haben, so dass die Clients nur das Betriebssystem selbst installiert haben und der Rest uebers Netzwerk geschiet.
Zum Vergrößern anklicken....

klingt schon fast nach ThinClients. Wie wäre es wenn du den Fileserver gleich zu einem Virtualisierungshost aufbaust? Die Clients im Netz starten lediglich eine GUI zur Verwaltung der VMs, welche dann auf deinem 'File'server ausgeführt werden.
 
Crest schrieb:
1.) Ob sich das lohnt hängt hauptsächlich von der Art deiner Daten ab. Video- und Audiodatein lassen sich kaum weiter komprimieren. Quelltext dagegen lässt sich gut komprimieren. Wenn du GELI unterhalb von ZFS verwendest wird Disk I/O auch leicht CPU limitiert hier kann Kompression helfen.
Zum Vergrößern anklicken....

Also Es sind hauptsaechlich Videos, MP3's, Audiobooks, eBooks und halt VMImages und installierte Programme.

Macht es einen Unterschied ob Geli nun unterhalb oder oberhalb von ZFS liegt?


Edit:
Also mein CPU laeuft immer ganz ruhig unter 10%... darum wollte ich sozusagen wissen, wie ich ihm mehr Arbeit geben kann xD
 
Zuletzt bearbeitet:
Illuminatus schrieb:
Wie wäre es wenn du den Fileserver gleich zu einem Virtualisierungshost aufbaust?
Zum Vergrößern anklicken....
Na das lohnt erstmal nicht so. Es werden nur 3 Windows und eine Mac Kiste dran sein und da will ich das setup nicht zu komplex machen.


mrtonik schrieb:
Wenn das immer die Gleichen sind, lohnt sich evtl. dedup. Das würde dann auf jeden Fall mal Platz sparen.
Ob das was Performance-technisch verbessert weiß ich nicht.
Zum Vergrößern anklicken....
Danke fuer den Tipp, das kannte ich noch nicht. Platz ist allerdings kein Problem, sondern erstmal nur die Geschwindigkeit.
 
Für Deduplication benötigst du aber schnellen Speicher, um die Metadaten zu speichern. Viel Speicher. Da müsstest du schon auf mindestens 32GB RAM aufrüsten oder aber eine schnelle SSD als Cache-Device einsetzen...
 
Um noch mal die ZFS compression in den Raum zu werfen:

"soweit ich das verstanden habe, kann ich das getrost anmachen, da die CPU noch viel Luft hat. Es kann zu Performance Gewinn kommen, muss es aber nicht. Performance Verlust ist nicht in Sicht."

Ist das soweit korrekt?
 
lockdoc schrieb:
Um noch mal die ZFS compression in den Raum zu werfen:

"soweit ich das verstanden habe, kann ich das getrost anmachen, da die CPU noch viel Luft hat. Es kann zu Performance Gewinn kommen, muss es aber nicht. Performance Verlust ist nicht in Sicht."

Ist das soweit korrekt?
Zum Vergrößern anklicken....

Ja.

Eine halbwegs moderne CPU vorausgesetzt, liefert die lzjb-Kompression bei komprimierbaren Daten immer einen Performancegewinn. Bei nicht weiter komprimierbaren Daten (Videos/MP3/etc.) hast du zwar eine geringfügig höhere CPU-Belastung, aber keine Performance-Nachteile.
Die lzjb-Kompression würde ich grundsätzlich aktivieren - es sei denn die CPU ist wirklich sehr schwachbrüstig.

Die gzip-Kompression lässt sich parametrieren (gzip-1 bis gzip-9), braucht aber in jedem Fall erheblich mehr CPU-Leistung - liefert dafür auch bessere Kompression. Hier kann leicht die CPU der limitierende Faktor werden und der Durchsatz sinken.
Falls Platzgewinn die Nachteile in jedem Fall rechtfertigt (z.B. Logfile-Archivierung), kannst du die gzip-Kompression aktivieren. Ansonsten würde ich sehr genau testen, ob System und Daten dafür geeignet sind.

Zum Glück lässt sich die Kompression pro ZFS-Dateisystem separat einstellen, so dass man bedenkenlos mischen kann. :)
 
Ok, das hoert sich ja soweit erstmal ganz gut an.

Laut wiki ist die Disk->Buffer Transfer rate bis zu 1030 Mbits/sec. Der Buffer ist ja da in jedem Fall eh schneller, also sind die 1030 der bottleneck.

Mein Netzwek ist jetzt auch bei 1 Gbit/sec, also ca. gleich auf.

Jetzt kommt es natuerlich darauf an, dass ich die Daten auch ungefaehr so schnell uebers Netzwerk schicken kann, dass soll mit NFS und Samba geschehen. Hier haette ich natuerlich auch wuenschenswert Compression, da weiss ich jetzt aber noch nicht bescheid, ob das ueberhaupt moeglich ist.


Weiss eigentlich einer wie die Latency uebers Netzwek im Vergleich zu einer durchschnittlichen Desktopfestplatte ist?

Sind die annaehrende 1Gbit/sec uebers Netzwerk moeglich?
 
ueber netz bekommst du ca 80-95 MB /s maximal
und das nur bei entsprechendem equiqment ( switch m, netzwerk karte , mailboard )

und es ist abhaengig vom protocol was verwendet wird

holger
 
lockdoc schrieb:
Laut wiki ist die Disk->Buffer Transfer rate bis zu 1030 Mbits/sec. Der Buffer ist ja da in jedem Fall eh schneller, also sind die 1030 der bottleneck.
Zum Vergrößern anklicken....

In der Praxis liegt der Wert eher niedriger, weil die Zugriffszeit der Festplatten der limitierende Faktor ist.

Mit RAID-Z und 4 Festplatten kommst du beim Kopieren großer Dateien aber locker über diesen Wert.

lockdoc schrieb:
Jetzt kommt es natuerlich darauf an, dass ich die Daten auch ungefaehr so schnell uebers Netzwerk schicken kann, dass soll mit NFS und Samba geschehen. Hier haette ich natuerlich auch wuenschenswert Compression, da weiss ich jetzt aber noch nicht bescheid, ob das ueberhaupt moeglich ist.
Zum Vergrößern anklicken....

Das ist nicht möglich, die Dateien gehen unkomprimiert über die Leitung.

lockdoc schrieb:
Weiss eigentlich einer wie die Latency uebers Netzwek im Vergleich zu einer durchschnittlichen Desktopfestplatte ist?
Zum Vergrößern anklicken....

Im LAN kannst du ganz grob mit 1 ms rechnen, bei 7200-rpm-Festplatten mit 10 ms.

lockdoc schrieb:
Sind die annaehrende 1Gbit/sec uebers Netzwerk moeglich?
Zum Vergrößern anklicken....

Prinzipiell ja; je nach Anwendungsfall würde ich aber eher die Zugriffszeit der Festplatten als limitierenden Faktor sehen - vor allem, wenn es mehrere Clients plus VMs sind, die parallel auf das RAID-Z zugreifen. Dann geht die Performance ganz schnell in den Keller.
 
Azazyel schrieb:
Im LAN kannst du ganz grob mit 1 ms rechnen, bei 7200-rpm-Festplatten mit 10 ms.
Zum Vergrößern anklicken....

hmm, bei einem solchem Unterschied ueberlege ich gerade schon, ob ich mir meinen FreeBSD Desktop nicht doch diskless aufsetze und lieber noch 2 Festplatten zusaetzlich in den Server einbaue.

Ist es denn mit FreeBSD ueberhaupt moeglich das komplette System mit Xorg auf einem Server zu installieren und auff einem Desktop zu betreiben?

(Bei Windows muesste ich dann auch nochmal in einem anderen Forum nachfragen :huth:)
 
h^2 schrieb:
Hab das wochenlang versucht einzurichten. Wenn man nur einen millimeter vom dem PLan abweicht (anderer dhcp-server, anderer bootloader etc pp), dann geht alles in die Hose.
Zum Vergrößern anklicken....

Boot via iSCSI wäre noch eine Alternative für Windows- und Linux-Clients (geht es auch mit BSD?); FreeBSD als iSCSI-Server war aber zumindest unter 8.2-RELEASE eine einzige Katastrophe.
In der Zwischenzeit hat es dort zwar einige Patches gegeben; ob es inzwischen stabil und praxistauglich ist, habe ich aber noch nicht getestet.

Zusätzlich hat man auch noch den großen Nachteil, dass bei Ausfall/Neustart/Wartung des Servers am Client nichts mehr geht.

h^2 schrieb:
Mein Tipp: Spar dir die Zeit und Kauf ne kleine Platte oder SSD fuer den Client.
Zum Vergrößern anklicken....

Ich habe vor einiger Zeit meinen Desktop von Festplatte auf SSD migriert (die persönlichen Dateien liegen bei mir auch auf dem Fileserver). Der Performancegewinn ist so fantastisch, dass mir kein Rechner mehr ohne SSD unter den Schreibtisch kommt. Eine Latenz von weniger als 0.1 ms ist für den Desktop-Betrieb einfach genial! :)
 
Funktioniert in 8-STABLE und 9.0-BETA2 mit UFS einwandfrei, inzwischen sogar mit Snapshots. Mit ZFS geht's nicht und wird es vielleicht auch nie, da die Upstream-Entwicklung es zumindest bisher nicht vorsah. Allerdings gibt's inzwischen auch SSD, die auch ohne TRIM gut und dauerhaft zuverlässig funktionieren...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben