Fileserver - optimales Dateisystem, aber welches?!

[Macer89]

Hallo & guten Morgen!

Ich habe mir schon seit geraumer Zeit Gedanken darüber gemacht, welches Dateisystem ich in Zukunft für meinen Fileserver einsetzen soll.
Leider bin ich zwischen den ganzen Möglichkeiten zu keinem wirklichen Endergebnis gekommen und sehe mittlerweile auch den Wald vor lauter Bäumen nicht mehr.

Im Endeffekt möchte ich eine Linux-Distribution dazu verwenden, Solaris, etc eher ungern.
Immer wieder stoße ich auf den Begriff "ZFS", da es aber unter Linux nativ nicht unterstützt wird käme jedoch nur "btrfs" als Möglichkeit in Frage. Dieses ist aber noch mehr oder weniger experimentell (auch wenn manche Distris es schon als produktiv-einsetzbar sehen).

Die Anforderungen an das Dateisystem sollten sein:

• Verwaltung großer Datenmengen möglich (>50TB)
• Vermeidung von Datenkorruption (z.B. Speicher-, Controllerfehler)
• Ablage aller möglichen Dateigrößen (viele kleine Dateien bis hin zu großen ISO-Images/Backups)

Wie seht ihr das? Welches Dateisystem ist eurer Meinung nach dafür am geeignetsten? Gängige wie XFS, Reiser4 oder Ext4?
Welche habt ihr im Einsatz und würdet ihr sie auch wieder verwenden bzw. hattet ihr schon spezielle Probleme die mit anderen nicht aufgetreten wären?

Bin gespannt auf eure Meinungen!

 

[hotzen]

Trotzdem: ZFS :P
Nimm halt Nexenta, da hast du dann ein Debian Userland unter dem Popo und fühlst dich ein klein wenig fast zu Hause

 

[sandreas]

Ich bin auch für ZFS. Ein Jammer, das Linux das wegen den Lizenzen nicht nativ implementieren kann. Bei FreeNAS hast du mit Konsole nix am Hut... nutzt auch ZFS. Ich nutze es schon länger und bin begeistert.

 

[Macer89]

Okay, es scheint also so als wäre ZFS genau die eierlegende Wollmilchsau die ich suche.

@ hotzen
Nexenta gibt es nicht frei oder? Ich habe nur eine Trial-Version gefunden (NexentaStor).

@ sandreas
FreeNAS klingt im Prinzip auch nicht schlecht, wäre auf jeden Fall sehr einfach zu administrieren, werde es mir auch einmal angucken. Das Problem dabei ist wohl die Erweiterbarkeit für andere Dienste.

Vielleicht sollte ich doch auch noch Solaris in den Augenschein nehmen, das wäre dann wohl OpenIndiana oder?
Sind die Unterschiede zwischen Solaris und Linux sehr gravierend oder lebt man sich relativ schnell in die Solaris-Welt ein, wenn man bis dato noch keine Erfahrung damit gemacht hat?

 

[gea]

Okay, es scheint also so als wäre ZFS genau die eierlegende Wollmilchsau die ich suche.

@ hotzen
Nexenta gibt es nicht frei oder? Ich habe nur eine Trial-Version gefunden (NexentaStor).

@ sandreas
FreeNAS klingt im Prinzip auch nicht schlecht, wäre auf jeden Fall sehr einfach zu administrieren, werde es mir auch einmal angucken. Das Problem dabei ist wohl die Erweiterbarkeit für andere Dienste.

Vielleicht sollte ich doch auch noch Solaris in den Augenschein nehmen, das wäre dann wohl OpenIndiana oder?
Sind die Unterschiede zwischen Solaris und Linux sehr gravierend oder lebt man sich relativ schnell in die Solaris-Welt ein, wenn man bis dato noch keine Erfahrung damit gemacht hat?

Die Unterschiede zwischen Linux und Solaris (Unix) liegen vor allem im Packetmanagement (pkg install irgendwas anstatt apt get install irgendwas).
Die größten Unterschiede sind ansonsten im Service-Management. Solaris ist da komfortabler aber eben etwas anders. Unterschiede gibt es auch beim Einstellen von Systemparametern oder Netzwerkadaptern. Vieles wird da nicht durch Editieren von Dateien in /etc eingestellt sondern durch CLI-Konfigurationsprogramme.

Wenn ich hier von Solaris spreche, dann meine ich alles was aus dem OpenSource Project OpenSolaris hervorgegangen ist, also Solaris 11 (nicht frei) und den freien Fork Illumos (Das Kernel Project mit Basistools) und die darauf aufbauenden OpenSource Distributionen wie Illumian, OpenIndiana oder SmartOS.

Probleme gibt es oft, wenn etwas selbst kompiliert werden soll und die Packete nur für Linux vorbereitet sind.
Alles was für den SAN oder NAS Betrieb nötig ist, ist aber vorhanden und oft besser integriert als bei Linux. Man merkt halt, dass Solaris neben Windows und OSX ein Full-featured Server-OS aus einer Hand ist. Insbesondere der SMB Server von Solaris ist eine Klasse für sich. Richtig Windows compatible ACL und Zugriff auf snaps mit Windows- vorherige Version, integriert als ZFS Eigenschaft. Das gilt auch für iSCSI und Comstar. Da ist Solaris einfach Klasse.

Eine Aussage, die ich oft höre, ist in dem Zusammenhang immer wieder: Ich bin überrascht, wie problemlos alles funktioniert. Das bin ich von Linux so nicht gewohnt. Auch die Dokumentation (von Oracle) ist eine Klasse für sich, vieles davon auch in deutsch. Ich selbst habe mehrere Anläufe gemacht, meine Windows Server mit Linux zu ersetzen, habe es dann aber immer gelassen weil es eben nicht wirklich funktionierte und die Vorteile eher gering waren. Erst mit Solaris und ZFS sehe ich einen riesigen Nutzen und es ist wirklich bedienbar und viel problemloser als meine Windows 2008 Filer. Ich nutze da aber den im Solaris-Kernel integrierten SMB Server und nicht SAMBA (ist bei Solaris optional)

Für einen Fileserver würde ich auf jeden Fall eine Storage Distribution mit Web-UI wählen. Als z.B. NexentaStor CE (mit Nexenta Web-UI, ohne Support aber frei bis 18TB) oder ein OpenSource OS wie OpenIndiana oder Illumian oder Solaris 11 (nur frei für nichtkommerziellen Einsatz und Tests). Für diese habe ich das Web-UI napp-it zusammen mit einem Online-installer entwickelt. Damit läßt sich rund um ZFS und NAS/SAN alles per Browser einstellen. Die größte Verbreitung und das breiteste Einsatzspektrum hat OpenIndiana vor allem in der Live-Version mit GUI und Timeslider (Tolles Tool, man wählt einen Ordner und geht in der Zeit zurück, Viel besser als ein Snap-Datum auszuwählen und dann auf Dateisuche gehen)

Die wichtigste Alternative ist Free-BSD oder Free-NAS. Da fehlen zwar die Highlights wie der Solaris SMB Server oder Comstar. Dafür gibt es aber mehr Packete z.B. DLNA mediaserver etc für Zuhause. Es ist aber stabil und die Neuheiten von Illumos (da findet die freie ZFS Entwicklung statt, wird benutzt in Nexenta4, Illumian, SmartOS, OpenIndiana) kommen da noch am schnellsten an.

ZFS unter Linux sehe ich stark im Kommen. Ist halt interessant wenn man unbedingt Linux braucht. Ich halte es aber bereits für einsetzbarer als Btrfs . Da ZFS jetzt auch (wieder) unter OSX verfügbar ist, entwickelt es sich ohnehin gerade zum universellen Dateisystem jenseits von NTFS. Und wer es mal getestet hat, will eh nichts anderes mehr. Selbst neueste Enwicklungen wie Btrfs oder WinFS hinken da noch hinterher - wenn sie denn mal stabil verfügbar sind. Ext, HFS, NTFS, Reiser, XFS und andere sind da eh keine wirkliche Alternative (spezielle Anwendungsfälle ausgenommen)

 

[TCM]

Welche Möglichkeiten hab ich eigtl. bzgl. Encryption?

Solaris 11 scheint ja verpönt zu sein, weil die Developer weggerannt sind. Ich wollte ungern im ZFS noch verschlüsselte Container anlegen. Tut sich bei den Solaris-Clones überhaupt irgendwas in der Richtung?

 

[bluesunset]

Debian Squeeze (6.0) hat einen (relativ) einfachen grafischen Installer bei dem du auch eine Komplettverschlüsselung einrichten kannst. Als Dateisysteme bietet sich JFS (von IBM) für / an (vor allem viele kleine Dateien) und XFS (SGI) für alles andere. Beides sind 64bit Dateisysteme. Im falle von XFS auch recht Hardware nahe max. Transferraten.

Gegen Speicherfehler hilft nur vernünftige Hardware mit ECC. SAS Festplatten haben einen kontiunierlichen Hintergrundscan der Festplattenoberfläche in der Firmware eingebaut. Dieser läuft ohne Zutun eines Raidcontrollers oder einer extra Software ab.

 

[gea]

Welche Möglichkeiten hab ich eigtl. bzgl. Encryption?

Solaris 11 scheint ja verpönt zu sein, weil die Developer weggerannt sind. Ich wollte ungern im ZFS noch verschlüsselte Container anlegen. Tut sich bei den Solaris-Clones überhaupt irgendwas in der Richtung?

Im Moment gibt es in ZFS eingebaute Verschlüsselung nur von Oracle mit Solaris 11 und ZFS V31+.
Es tut sich aber schon etwas. Insbesondere bei Delphix (da sind einige von den ZFS Entwicklern "hingelaufen") wird an Feature-Flags gearbeitet. Damit lassen sich ZFS Entwicklungen verschiedener Firmen koordinieren. Ich denke dass die wichtigsten Features dann in den Illumos Kernel einfliessen, damit diese Pool (haben dann Version 1000) kompatibel bleiben. Kompatibilität mit Oracle ZFS ab V. 29 kann man wohl abschreiben. Oracle wird das nicht offenlegen und die anderen wollen unabhängig von Oracle sein.

http://blog.delphix.com/csiden/files/2012/01/ZFS_Feature_Flags.pdf
Fork Yeah! The Rise and Development of illumos

---------- Post added at 15:20 ---------- Previous post was at 14:59 ----------

Gegen Speicherfehler hilft nur vernünftige Hardware mit ECC. SAS Festplatten haben einen kontiunierlichen Hintergrundscan der Festplattenoberfläche in der Firmware eingebaut. Dieser läuft ohne Zutun eines Raidcontrollers oder einer extra Software ab.

Vernünftige Hardware ist das eine aber es gibt Speicherfehler und andere Probleme,
an die man anders herangehen muss.

siehe http://www.as-systeme.de/sites/default/files/events/SolarisStep_ZFS_0.pdf

1.
Das sind z.B. silent errors, auch als Datenrost bezeichnet, die zufällig oder durch Umwelteinflüsse auftreten
- umso häufiger, je größer die Platten sind. Die kann eine einzelne Platte nicht erkennen.

2.
Fehler jenseits der Platte, also durch Kabel, Controller oder Treiber bedingt

3.
Fehler bei Arrays über mehreren Controllern

4.
Speicherfehler durch Benutzerfehler (Virus, hoppla gelöscht, was nun, ich brauche die Dateiversion von gestern, die jetzige ist Mist..)
Backup, na klar, ist aber von vorgestern, außerdem Backup dauert ....
Was jetzt gebraucht wird ist kein Disaster-Backup, sondern Verfügbarkeit

5.
Speicherverlust durch fehlende Hardware
(Raidcontroller stirbt irgendwann, Daten weg, außer man findet in ein paar Jahren bei ebay noch einen gleichen/compatiblen Controller)

6.
Raid ist voll: alles neu aufbauen und umkopieren, wachsen geht nicht


Und um genau diese Probleme geht es; die werden weder durch ein herkömmliches Hardware-Raid beherrscht noch durch andere Dateisysteme (außer teilweise btrfs). Diese Fehler werden bei ZFS durch folgende Mechanismen beherrschbar:

- Prüfsummen auf alle Daten
Damit erkennt das Betriebssystem beim Lesen sofort fehlerhafte Daten - warum auch immer-
Durch die Prüfsummen werden die Fehler sofort repariert ("selbstheilend")

Manche sagen dazu: ZFS ist instabil, dauernd Dateifehler.
Grund ist aber, ZFS ist stabil - alle anderen System merken diese Fehler einfach nicht oder zu spät.

- scrubbing
Das ist ein Online Lesevorgang auf alle Daten um Hintergrund. Dabei werden die Prüfsummen ausgewertet und Fehler - selbst bei
offenen Datein- repariert (also kein offline Filecheck der Tage dauert). Ideal gegen zu spät erkannte Dateifehlen bei selten genutzten Dateien. Man weiß halt, dass der gesamte Datenbestand ok is (wird übrigens bei Desktop-Platten wöchentlich empfohlen)

- Software Raid
ZFS baut Datenpools in Software über beliebige Controller und Platten. Dank CopyOnWrite gibt es auch kein Write-Hole wie bei Hardware-Raid. Batterien auf den Controllern werden nicht gebraucht.

-Ausbaubar
Ein 128bit ZFS Pool kann praktisch unbeschränkt wachsen. Es ist so konzipiert, dass es keine erreichbaren Grenzen hat.

-Snapshots
Durch CopOnWrite (dabei werden keine Datenblöcke geändert, sondern immer neu geschrieben) kann der aktuelle Datenbestand in Sekundenbruchtreilen eingefroren werden und bleibt zugänglich. Lediglich weitere Änderungen verbrauchen dann Platz. Durch dieses Konzept sind selbst Tausende snapshots im MInutenabstand bei Riesen-Dateien kein Problem.

dazu Online Komprimierung, Deduplizierung, Quoten auf User und Datasets, Reservierungen, Verschlüsselung bei Solaris, keine Pfadlängenprobleme, keine max Partitionsgröße, keine Grenze in der Anzahl von Dateien und viele andere Dinge (Grenzen sind da aber jenseits von relevant), sehr flexible Aufteilung eines Datenpools auf datasets (sowas wie Partitionen)

...... und tausend andere nette Dinge

 

[antilope114]

Im Moment gibt es in ZFS eingebaute Verschlüsselung nur von Oracle mit Solaris 11 und ZFS V31+.
Es tut sich aber schon etwas. Insbesondere bei Delphix (da sind einige von den ZFS Entwicklern "hingelaufen") wird an Feature-Flags gearbeitet. Damit lassen sich ZFS Entwicklungen verschiedener Firmen koordinieren. Ich denke dass die wichtigsten Features dann in den Illumos Kernel einfliessen, damit diese Pool (haben dann Version 1000) kompatibel bleiben. Kompatibilität mit Oracle ZFS ab V. 29 kann man wohl abschreiben. Oracle wird das nicht offenlegen und die anderen wollen unabhängig von Oracle sein.

Also im Prinzip heißt das, es werden momentan einfach zwei Versionen von zfs weiterentwickelt - einmal inhouse bei Oracle (und das soll woll qualitativ nicht mehr mithalten können weil wesentliche Innovatoren abgewandert sind) und zum zweiten unter dem Illumos-Dach, dezentral aber doch organisiert durch die Einführung von Flags.

Wenn ich das richtig sehe ist es auf jeden Fall aufgrund der neu zu erwartenden Features besser, auf z.B. OpenIndiana zu setzen; meine ZFS V.33 Pools von Solaris 11 werde ich aber dann neu erstellen müssen?

 

[josen]

Hallo,

bis auf das Scrubbing, das du unter Linux nicht findest, ausser du schreibst es dir selbst, kann man mit Debian GNU/Linux oder Ubuntu oder oder sehr gut deine Anforderungen erfüllen, ich habe was ganz ähnliches in Betrieb.

- Linux Software-RAID
Auch hier, Linux Software-RAID über den md-Layer ist sehr ausführlich getestet und in seiner Funktion sehr verlässlich.

- dm-crypt für die Verschlüsselung
Ist zusammen mit TrueCrypt (wobei ich davon unter Linux abraten würde) die Standardlösung für verlässliches und sehr ausführlich getestete Verschlüsselung.

- XFS als Dateisystem
Selbe wie oben. Die angeblichen Probleme mit vielen kleinen Dateien konnte ich nicht nachvollziehen. Außerdem ist XFS für langlebige Datenbestände sehr gut mit Verwaltungswerkzeugen ausgestattet.

Ich setze das obige Setup, also XFS auf dm-crypt über Software-RAID seit 2003 ein. Das aktuelle Dateisystem habe ich 2006 erstellt und immer wieder zwischen den Servern mitgenommen, beziehungsweise erweitert. Mit dem Setup ist möglich:
- Online Defragmentierung
- Online RAID-Level Migration (Linux Software-RAID Konvertierung :: Linux)
- Online Dateisystem Resizing
- Online Dateisystem Prüfung (fsck)

Nur fürs resizen des dm-crypt Volumes musst du eine Downtime einplanen, aber auch nur für das dm-crypt Volume und auch nur einige Minuten.

Ich hab mir 2009 ZFS auf Solaris mal genauer angeschaut, will aber keine Empfehlung für oder wieder abgeben. Ich für mich persönlich bleibe bei Linux und obiger Installation, weil ich mich mit Linux am besten auskenne und im Notfall am besten reagieren kann.

Wenn du Fragen zu diesem Setup hast, sag an

Grüße

EDIT: Von Newcomern im Dateisystemberich wie BTRFS würde ich immer erst ein paar Jahre die Finger lassen, bis sie nicht nur nicht mehr "EXPERIMENTAL" im Kernel deklariert sind, sondern wenn genug Leute ihre Daten damit erfolgreich nicht verloren haben. Dass man ohne fsck auskommen wollte und nun doch eins programmiert, spricht für mich schon Bände.

EDIT2: Endlich hab ich den Link zur XFS Sichtweise auf Daten gefunden: http://lwn.net/Articles/476465/ (Post von dgc) Lies es dir mal durch, wenn dich der Unterschied (BTRFS,ZFS) <-> XFS interessiert.

 

[DocSilly]

Die Anforderungen an das Dateisystem sollten sein:

• Verwaltung großer Datenmengen möglich (>50TB)
• Vermeidung von Datenkorruption (z.B. Speicher-, Controllerfehler)
• Ablage aller möglichen Dateigrößen (viele kleine Dateien bis hin zu großen ISO-Images/Backups)

Ich vertrau da auf ZFS, seit etwas über einem Jahr läuft daheim mein NAS mit aktuellem Solaris/ZFS. Scrub hat schon einige Hardwarefehler entdeckt. Eines Tages, das NAS lief gerade ein paar Monate ohne Probleme, tauchten eines Tages beim Scrubbing haufenweise Dateifehler in den stündlichen Snaps auf (aber nicht die eigentlichen Dateien). Es stellte sich heraus das einer der vier ECC Speicherriegel die Ursache war. Und vor kurzem wurden Festplatten erkannt obwohl der S.M.A.R.T. Status noch keinen Alarm schlug. Es gab keine eigentlichen Dateifehler aber dafür einige CKSUM Error bei einer Festplatte. Diese Festplatte wies dann bei einem erweiterten Test defekte Sektoren auf.
Der Empfehlung von Oracle beim Einsatz von Desktop Festplatten wöchentlich zu scrubben kann ich nur zustimmen. Bei einem Resilver, der bei mir einige Tage in Anspruch nahm, fiel dann eine zweite Festplatte aus.
Wikipedia hat ZFS so beschrieben:

Data Integrity

One major feature that distinguishes ZFS from other file systems is that ZFS is designed from the ground up with a focus on data integrity. That is, protect the user's data on disk, against silent data corruption caused by e.g., bit rot, cosmic radiation, current spikes, bugs in disk firmware, ghost writes, etc..

 

[TCM]

Ich halte Prüfsummen mitllerweile für unumgänglich, weswegen ich ZFS einfach voraussetze.

Das Dilemma ist jetzt halt, ob ich jetzt noch einen Pool mit ZFS v31 aufsetze und einfach storageseitig bei Solaris 11 bleibe oder einen v28-Pool mit einem alternativen System aufsetze und mir darin mit Containern einen abfrickle, bis die mal in die Pötte kommen.

Da das Storage-System keine Dienste hostet und nicht von außen zu erreichen wäre, könnte es eigtl. egal sein, wie es mit Solaris 11 weitergeht, wenn es jetzt läuft und die Features hat, die ich brauche.

 

[hotzen]

Du kommst halt ums verrecken nicht an Updates, das ist das bittere. Ich bin auf Solaris 11 Express und da is mal jar nichts mit Updates, da brauchst du einen Support-Contract mit Oracle für
Und leider ist auch Solaris nicht vor kritischen Bugs in SSH, OpenSSL & Co gefeit ...

Für meinen neuen Filer gehe ich auf NexentaStor Community Edition und wechsel dann auf deren Version 4, die auf illumos/illumian aufbaut, also der Muddi von OpenIndiana, dem neuen OpenSolaris.
Dafür muss ich dann halt auch in Kauf nehmen die vdevs platt zu machen, weil die wie bei dir eine neuere ZFS-Version sind.

Wegen der dann fehlenden ZFS-Encryption muss ich mir noch Gedanken machen. Kennt da jemand Alternativen?

 

[DocSilly]

Du kannst auf Solaris 11 Release upraden, nur ist die Sache mit ein wenig Fummelei verbunden. Zuerst muss man PKG selbst updaten.

docsilly@nas:~# pkg update
docsilly@nas:~# pfexec pkg install pkg:/package/pkg

Danach sollte es klappen mit dem Update-Manager das System auf Solaris 11 Release zu bringen. Ich hab da eine Weile nach der Lösung suchen müssen
Nach den Updates/Reboot kann man die ZFS Pools upgraden.

docsilly@nas:~# zpool upgrade
This system is currently running ZFS pool version 33.

All pools are formatted using this version.

 

[Macer89]

Hallo!

Ich habe mir all eure Posts durchgelesen und diesbezüglich noch etwas nachgelesen und recheriert.
Die Lösung von Nexenta wird anscheinend gerne verwendet, allerdings ist hier das Problem, dass die freie Version (Community Edition) limitiert ist (<= 18TB).
Bei OpenIndiana wird ZFS gut unterstützt, aber leider in der aktuellen Unterstützung (noch) keine Encryption, wo man hier wohl auch zuvor manuell durch eine Block-/Device-Verschlüsselung Hand anlegen müsste.
Solaris 11 würde dann zwar die Verschlüsselungs-Funktion unterstützen, aber stirbt halt dann in absehbarer Zeit weg...

Eigentlich finde ich die Lösung von josen auch ganz vielversprechend, so wie er sagt ist XFS + LVM + Linux (dm-crypt + mdadm).

Wie sieht es mit dem Speicherverbrauch bzw. der CPU-Leistung aus? Ich meine was ich gelesen habe, wird aufgrund von ZFS mit sehr großen Speichermengen (vor allem pro TB) gerechnet um performant zu sein. Mir ist schon klar, dass es sich bei mir zu Hause um keinen Produktionsserver handelt, aber auch wenn es nur ein einfacher Home-Fileserver ist, dann sollten Kopiervorgänge doch nicht unendlich Zeit in Anspruch nehmen. Bzw. ich will nicht 24 GB RAM mit einer Hex-Core CPU kreuzen müssen, damit ich dort ZFS betreiben kann.

Die meisten hier die einen Fileserver neu aufsetzen, setzen nach wie vor auf Linux (inkl. natives Filesystem)... so 100% überzeugt bin ich nicht von ZFS, obwohl sich ja das Ganze mit Prüfsummen, etc. nett anhört, aber wie der Ressourcenhunger dann ist schreckt mich schon etwas ab.
Außerdem will ich keinesfalls auf Datenverschlüsselung verzichten. Haben die Leute die hier ZFS verwenden auch eine Verschlüsselung in Verwendung, wenn ja welche?

 

[gea]

Wie sieht es mit dem Speicherverbrauch bzw. der CPU-Leistung aus? Ich meine was ich gelesen habe, wird aufgrund von ZFS mit sehr großen Speichermengen (vor allem pro TB) gerechnet um performant zu sein. Mir ist schon klar, dass es sich bei mir zu Hause um keinen Produktionsserver handelt, aber auch wenn es nur ein einfacher Home-Fileserver ist, dann sollten Kopiervorgänge doch nicht unendlich Zeit in Anspruch nehmen. Bzw. ich will nicht 24 GB RAM mit einer Hex-Core CPU kreuzen müssen, damit ich dort ZFS betreiben kann.

Die meisten hier die einen Fileserver neu aufsetzen, setzen nach wie vor auf Linux (inkl. natives Filesystem)... so 100% überzeugt bin ich nicht von ZFS, obwohl sich ja das Ganze mit Prüfsummen, etc. nett anhört, aber wie der Ressourcenhunger dann ist schreckt mich schon etwas ab.
Außerdem will ich keinesfalls auf Datenverschlüsselung verzichten. Haben die Leute die hier ZFS verwenden auch eine Verschlüsselung in Verwendung, wenn ja welche?

Nur weil Sun Solaris und ZFS für die Ansprüche großer Datacenters entwickelte, heisst das noch lange nicht, dass es nicht auch auf kleiner Hardware gut läuft. Es gibt hier genügend Leute, die es auf z.B. auf einem HP Microserver mit 4GB RAM aufwärts einsetzen und damit (single user) Transferraten von 80GB+/s erreichen. Man kann aber sagen, dass Solaris 2 GB braucht und alles darüber zum Cachen von Schreib und Leseaktionen nutzt. Daher gilt bei ZFS: desto mehr RAM, desto schneller. Mit Verschlüsselung braucht man allerdings mehr CPU Leistung oder es wird halt deutlich langsamer. (abhängig vom Grad der Verschlüsselung). Auch braucht Deduplizierung sehr viel RAM-Speicher. Das ist aber bei Linux und Software-Raid nicht anders, egal ob ZFS oder nicht.

Verschlüsselung geht neben der Solaris 11 Methode (in ZFS eingebaut) auch mit verschlüsselten File-devices.
Siehe http://www.hardwareluxx.de/community/f101/zfs-stammtisch-570052-73.html#post18731400

 

[josen]

Hallo Macer,

na das freut mich zu hören. Insbesondere freu ich mich aber, dass du versuchst die technisch beste und nicht die coolste Lösung zu finden

Um mal eine Hausnummer ins Spiel zu bringen:

root@fserv1int:/mnt/failsafe# spew -g --read-after-write 1g testdatei1GB
Total iterations:                               11
Total runtime:                            00:02:38
Total write transfer rate (WTR):   415738.03 KiB/s
Total read transfer rate (RTR):    420650.00 KiB/s

Das ist XFS+dm-crypt+Software-RAID über 5x Hitachi Deskstar 5K3000 auf einem Xeon E3 1220. CPU-Last während des Tests liegt so bei 0% Wait (warten auf RAID I/O) und 4.9% User (das Benchmarktool) und 3% System (XFS+Software-RAID und bischen dm-crypt Verwaltung). Das ist allerdings nur der sequentielle Maximaldurchsatz, bei zufälligen Zugriffen siehts natürlich ganz anders aus.

Wieviel Arbeitsspeicher die Arbeitsprozesse von Software-RAID und dm-crypt verbrauchen konnte ich leider nicht rausfinden, die laufen im Kernelspace und das mag top scheinbar nicht.

Grüße

EDIT: Kann Solaris+ZFS AES-NI auf Intel bzw. AMD nicht nutzen? Das ist für mich ein Killer-Feature.

 

[DocSilly]

Laut https://blogs.oracle.com/cmt/en/entry/oracle_tde_and_hardware_accelerated soll es gehen:

Oracle TDE and Hardware Accelerated Crypto
By Stefan Hinker on Nov 08, 2011

Finally, there's a clear and brief description of the hardware and software required to use hardware accelerated encryption with Oracle TDE.. Here's an even shorter summary ;-)

SPARC T4 or Intel CPU with AES-NI
Solaris 11 or Linux (a patch for Solaris 10 will be provided eventually)
Oracle 11.2.0.3
If you use Linux, Oracle DB 11.2.0.2 with patch 10296641 will also work.

The longer version of this summary is available as MOS-Note 1365021.1

Happy crypting!

Leider kann ich zur Zeit nicht auf das ausführlichere Dokument zugreifen um zu sehen ob es da Limitationen bei den non-SPARC CPUs gibt. Eine weitere (und noch nicht abgeschlossene) Diskussion dazu gibt es hier ZFS AES without AES-NI hardware support - [H]ard|Forum