• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

ZFS On Linux in den Ports

cabriofahrer

Well-Known Member
#26
Ich finde die Ausführungen hier sehr interessant. Ich war nicht komplett im Bilde über die Vielfalt der existierenden, mittlerweile sogar gescheiterten und auch zukünftigen Dateiensysteme unter Linux, seien diese nun vielversprechend oder nicht.

Also mal ganz einfach, pragmatisch, realistisch und frei von irgendwelchen Ideologien gefragt: Welche Konstellationen (Betriebsystem und Dateiensystem) sind für z.B. für ein Unternehmen produktiv einsetztbar, sei es für NAS, Samba, NFS, HTTP, FTP, etc?

Mit Sicherheit sind FreeBSD bzw. FreeNAS mit ZFS da eine gute Option, oder? Aber bei Linux? Was wäre da die aktuell beste Wahl? Z.B. Debian, CentOS oder OpenSUSE womit? Ext4 oderLVM?
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#27
Bei FreeBSD ist die Sache einfach. ZFS. Nichts gegen UFS, aber ZFS ist einfach x-fach flexibler. Bei Linux ist die Sache viel kompliziert, da Linux etliche Dateisysteme und Abstraktiontechniken hat. Grob zusammengefasst kann man aber sagen, dass man einen Volume Manager nutzen sollte. Das wäre dann LVM2. Darüber wird meistens Ext4 oder XFS gelegt.

Insgesamt ist meine bescheidene Meinung aber ganz einfach, dass man sein Gesamtsystem so homogen wie möglich halten sollte. Wenn ich 20 Linux-Kisten habe, macht es wenig Sinn eine FreeBSD-Kiste daneben zu stellen. Das gilt genauso für Windows, FreeBSD und alle anderen Systeme. Und auch zwischen einzelnen Linux-Distros. Wenn ich hauptsächlich auf Debian setze, will ich ein Red Hat oder OpenSuse daneben wenn möglich vermeiden.
 

-Nuke-

Well-Known Member
#28
Produktiv einsetzbar ist fast alles. Fragt sich halt nur was deine Anforderungen sind. ZFS ist toll für Datawarehousing. Checksummen, Snapshots, Kompression, Deduplication, komplexe RAID Setups...
Das braucht aber auch nicht unbedingt jeder alles.

LVM ist kein Dateisystem, sondern ein Volume Management. Darauf läuft dann das Dateisystem (ext4, xfs, ...). Das erlaubt dann auch Snapshots und jeweilige Volumes / Partitionen.

btrfs ist von den Features her ZFS ähnlich, nur RAID5/6 sollte man noch eher lassen. Der Rest ist eigentlich stabil. Die meisten Quirks wurden bereits behoben (oder eher drum rum gearbeitet), aber manchmal braucht das Dateisystem ein paar Streicheleinheiten (z.B. btrfs balance).

ZFS hat aber einen großen Nachteil für eher kleinere Umfelder (Privatleute und kleinere/mittlere Firmen), den die anderen Alternativen nicht haben. Einen zpool zu erweitern ist teuer. Es ist bisher nicht möglich z.B. aus einem 3 Disk RAIDZ ein 4 Disk RAIDZ zu machen. Das soll noch kommen, aber auch hier mehr ein Workaround mit relativ viel Plattenplatz-Verschleiß. Will man mehr Speicher kann man nur einen komplett neuen Pool hinzufügen. D.h. mindestens 3 weitere Platten, wovon dann wieder eine komplett für Redundanz draufgeht. Defragmentieren kann man ein ZFS Dateisystem auch nicht. Das ist zwar selten ein Drama, aber halt ein Punkt auf der Liste.

Meidet man btrfs und ZFS verliert man im Grunde Checksummen für Daten und transparente Kompression. Ob das mit den Checksummen für Daten jetzt so ein Drama ist sei mal dahin gestellt. Kann man auch mit einem Layer darüber nachbauen. Bei Kompression kommt es auch auf den Anwendungsfall an. Gerade moderne Dokumenten-Formate sind bereits von Haus aus komprimiert. RedHat arbeitet zur Zeit aber auch an einem Kompressions-Layer ähnlich LVM für Linux (VDO).

Unterm Strich hat alles Vor- und Nachteile. Grob kann man sagen: ZFS hat viele Features, ist einfach zu benutzen, aber praktisch recht teuer und unflexibel. Alles Andere hat nicht alle Features von ZFS, ist aber flexibler und billiger.
 

cabriofahrer

Well-Known Member
#29
Insgesamt ist meine bescheidene Meinung aber ganz einfach, dass man sein Gesamtsystem so homogen wie möglich halten sollte. Wenn ich 20 Linux-Kisten habe, macht es wenig Sinn eine FreeBSD-Kiste daneben zu stellen. Das gilt genauso für Windows, FreeBSD und alle anderen Systeme.
Sicherlich sinnvoll, aber im Falle von Windows wohl sehr teuer, wenn man alles auf Windows setzen will:

Einfache und günstige Workstations werden standardmäßig mit einer Windows Home Version ausgeliefert. Windows Home kann aber m.E. noch nicht mal Active Directory, eine der zentralen und wichtigsten Funktionen, um mit Windows 2016 Server (selbst sehr teuer) ein Netzwerk einzurichten. Da müsste man also alle Workstations auf Windows Pro oder sogar Enterprise upgraden (auch teuer), nur um AD nutzen zu können, richtig?

Da wäre es doch eine günstige Alternative, die Workstations mit Windows Home zu belassen und als zentralen Server FreeBSD oder Linux einzurichten, z.B. mit samba. Als open source Alternative zu AD gibt es glaube ich sssd, ldap und Kerberos, wobei ich die Einzelheiten leider noch nicht kenne.
 
#31
Da wäre es doch eine günstige Alternative, die Workstations mit Windows Home zu belassen und als zentralen Server FreeBSD oder Linux einzurichten, z.B. mit samba. Als open source Alternative zu AD gibt es glaube ich sssd, ldap und Kerberos, wobei ich die Einzelheiten leider noch nicht kenne.
Bitte Informiere dich, worin sich ein AD von einem einfachen LDAP (ggf. mit Kerberos) unterscheidet. Microsoft ist nicht bei NT4 stehen geblieben ;-)
 

medV2

Well-Known Member
#32
LVM2 auf Linux ist halt schon ziemlich toll, und ist wohl das Ding was ich auf BSD häufig vermisse. Mit Thin-provisioning kann der LVM auch sehr performant Snapshots erstellen und man ist allgemein sehr flexibel. Die Linux Softraids sind auch sehr brauchbar, das Softraid 5/6 unterstützt auch das teilweise resilver und hat Schutz gegen Writeholes.
RedHat bastelt mit stratis übrigends grad alle diese Funktionen zusammen um mit einem Kommand flexibel den Speicher einzuteilen und eine ähnliche Funktionalität wie mit zfs hinzubekommen. Ist kürzlich erst in V1 erschienen und kann noch nicht allzu viel aber gefällt mir vom Ansatz.

XFS kann übrigends Metadata Checksummen und es sollen auch welche für Nutzdaten kommen. Wer Checksummen braucht kann sich auch über dm-crypt und LUKS helfen, da gibts wie in geli auch authenticated encryption. Letzteres allerdings noch relativ neu.

Was btrfs zutrifft muss ich -Nuke- zustimmen. Ich hatte lange Zeit auch Probleme mit btrfs, allerdings stammten da meine Erfahrungen von rhel. Im letzten Jahr musste ich mich vermehrt mit sles beschäftigen und auch eine komplette Test-Infra damit aufbauen. Da hab ich eigentlich nur gutes damit erlebt. Allerdings unterstützt sles natürlich nur ein Subset aller btrfs Features. Die Suse Leute stecken auch noch viel Zeit in die Entwicklung von btrfs, ist auch derzeit der größte Kontributor.
 
H

holgerw

Guest
#33
Hallo,

vielleicht kann mir jemand von den professionellen Nutzern folgendes erklären:
Es war hier schon ein paar Mal davon die Rede, wie teuer der Einsatz von zfs werden kann.
Sicherlich wird im professionellen Umfeld nicht mit einem einfachen Mirror gearbeitet werden, sondern mit Raid-Verbünden aus mehreren Festplatten.
Aber wozu eigentlich? Das erste, was ich bei tiefgehenderen Diskussionen zu zfs hier gelernt habe, ist, dass es keinerlei Ersatz für eine vernünftige Backup-Vorgehensweise ist. Nur: Wenn ich die habe, wofür dann noch teure Raid-Konstellationen mit zfs?
Ich glaube schon, dass es dafür Argumente gibt .... Und vielleicht kann da mal jemand etwas genaueres zu sagen.
 
Zuletzt bearbeitet von einem Moderator:
H

holgerw

Guest
#35
Ganz einfach: Weil du während dein Backup auf neue Platten zurückgespielt wird nicht damit arbeiten kannst. Überleg mal was das kostet wenn ne ganze Abteilung darauf wartet dass das Backup zurück gespielt wurde :)
Also bedeutet das dann mehrfache Redundanz, nicht nur hinsichtlich Backups sondern auch hinsichtlich Verfügbarkeit.
Und Verfügbarkeitsredundanz ist mit einfachen Mirrors nicht zu haben.
Gut, das ist natürlich dort ein wichtiger Aspekt, wo lückenlose Verfügbarkeit eine große Rolle spielt.
 

-Nuke-

Well-Known Member
#36
Ein RAID hilft ja nicht nur zur Verfügbarkeit, sondern auch zur Datenkonsistenz. Gerade bei sterbenden Platten, die durch einen Headcrash oder was auch immer noch ein paar ihrer Daten mitnehmen. Das fängt dann das RAID ab und kaputte Daten landen nicht im Backup.

Ob man nun ein RAID1, RAID5 oder RAID6 nimmt ist halt eine Kostenfrage. Beim RAID1 oder RAID5 ist immer die Frage: Jetzt ist mir eine Platte an Alterschwäche gestorben. Was ist, wenn beim Neubau der neuen Platte eine weitere stirbt? RAID6 erweitert das und es müssten ganze 2 Platten dabei sterben. Bei RAID1 und RAID5 wäre das RAID in so einem Fall komplett tot.

Es gibt ja übrigens auch nicht nur das klassische RAID. Mit verteilten Systemen wie glusterfs können sogar ganze Computer ausfallen und die Daten sind trotzdem noch da. Das ist dann eine noch mal teurere Lösung als ein RAID6. Nach oben geht's halt immer. Aber hier ist dann die Backup-Komponente schon mit drin.

Ansonsten ja, je nachdem wie das Backup gemacht wurde und wie viele Daten es sind, ist "Backup zurückspielen" nicht immer die allerbeste Lösung. Außerdem ist das Backup selten aktuell. Man verliert also meistens einen halben bis einen ganzen Tag Arbeit. Wenn man seine Backups in die Cloud schiebt, dann kann der Zugriff auf die Backups je nach Anbieter sogar auch noch mal extra Geld kosten.
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#38
Wieso ist ReFS mehr o. weniger als gescheitert anzusehen?
Naja, von den hochtrabenden Ankündigungen des Dateisystems für die nächsten 20 Jahre ist doch kaum mehr was übrig. Das einzige Desktop-Windows, was ReFS noch voll unterstützt ist "Windows 10 Pro for Workstations". Was zumindest ich bisher in der Praxis nicht einmal gesehen habe. Unter Windows Server 2019 ist es in der berüchtigten Datenträgerverwaltung und co. nicht mehr die Standardauswahl, stattdessen ist man dort wieder auf NTFS... Booten von ReFS geht auch nach wie vor nicht, Hard Links und Quotas sind meines Wissen bisher auch nicht implementiert. Microsoft wird ReFS sicher weiter unterstützen, gerade für große Volumes und im Zusammenspiel mit Storage Spaces. Aber NTFS ersetzen wird es wohl nicht mehr.

Bitte Informiere dich, worin sich ein AD von einem einfachen LDAP (ggf. mit Kerberos) unterscheidet. Microsoft ist nicht bei NT4 stehen geblieben ;-)
Naja, man kann mit Samba ja inzwischen ein vollwertiges Active Directory betreiben. Aber man will es nicht. Zumindest nicht außerhalb vollständig kontrollierter Umgebungen. Da reicht ein Windows-Update durch Microsoft, was irgendwas subtil ändert, und der ganze Mist fliegt in 1000 Scherben auseinander.

Aber um dann langsam mal zum Thema zurückzukommen. Es gab auf freebsd-fs@ ein paar mehr Informationen zu ZFS on Linux auf FreeBSD. Unter anderem fertige Installationsimages für FreeBSD 12-STABLE und 13-CURRENT. Der Stand ist, dass ZoL plattformunabhängig gemacht wurde, es ist also nicht mehr hart an Linux gebunden, sondern unterstützt auch FreeBSD als vollwertige Host-Plattform. Derzeit unterstützt es noch kein TRIM, mit dem nächsten Release 0.8.0 wird es allerdings eine bessere TRIM-Implementierung als ZFS on FreeBSD derzeit hat bekommen. Details hier: https://lists.freebsd.org/pipermail/freebsd-fs/2019-April/027603.html

Allgemein zum Thema ZFS ist das monatliche "ZFS Leadership Meeting" immer recht interessant. Die sind öffentlich, man kann sich per Telefon einwählen. Leider ist die Zeitverschiebung nach Kalifornien doch schon recht stark. Protokolle, Termine und Telefonnummern sind unter https://docs.google.com/document/d/1w2jv2XVYFmBVvG1EGf-9A5HBVsjAYoLIFZAnWHhV-BM/edit und Aufzeichnungen auf Youtube unter https://www.youtube.com/channel/UC0IK6Y4Go2KtRueHDiQcxow/videos
 
H

holgerw

Guest
#40
Hallo,

danke für die Info.

Zu Deiner Frage, Robert:
Mit einfachem Mirror meine ich einen Verbund aus zwei Festplatten. Und natürlich steht beim Ausfall einer Platte die zweite zur Verfügung, aber steht sie das auch für die Zeit, in der eine neue Platte in den Mirror eingefügt wird? Wird nicht durch den Austausch der defekten Platte Verfügbarkeit kurz unterbrochen?
Vielleicht kannst Du oder jemand anderes dazu noch etwas Info geben.
 

medV2

Well-Known Member
#41
Hallo,

danke für die Info.

Zu Deiner Frage, Robert:
Mit einfachem Mirror meine ich einen Verbund aus zwei Festplatten. Und natürlich steht beim Ausfall einer Platte die zweite zur Verfügung, aber steht sie das auch für die Zeit, in der eine neue Platte in den Mirror eingefügt wird? Wird nicht durch den Austausch der defekten Platte Verfügbarkeit kurz unterbrochen?
Vielleicht kannst Du oder jemand anderes dazu noch etwas Info geben.
Ja da bist du dauerhaft verfügbar. Während des resilver etwas weniger performant aber nie komplett unverfügbar.
 

mr44er

Well-Known Member
#43
Danke, mir war bis eben nicht klar, ob während des Resilver-Vorganges dier Verfügbarkeit unterbrochen ist.
Weil ich das gerade quasi vor der Nase habe :) :

Code:
Sufficient replicas exist for the pool to continue functioning in a degraded state.
Solange das bei 'zpool status' steht, ist der Pool verfügbar. Egal, was du tust. Resilver, scrub, send, receive etc.

Wenn du Daten währenddessen draufschiebst, verlängert sich ein bereits laufender scrub/resilver-Vorgang. Du musst dann nicht nochmal von vorne beginnen.

Unverfügbar wird er nur, wenn man je nach Raidlevel eine Platte zuviel offline schaltet, respektive eine zuviel gestorben ist.
 

pit234a

Well-Known Member
#44
Wird nicht durch den Austausch der defekten Platte Verfügbarkeit kurz unterbrochen?
Und ich weiche nun mal bewusst von den bereits gegebenen Antworten ab und sage: ja, kurz.
Aber das sage ich so nur, weil ich ein wenig den Trotzkopf raus hängen lassen möchte.
Wenn du nicht die entsprechende HW hast, um Platten im laufenden Betrieb tauschen zu können, musst du natürlich kurz ausschalten. Das gilt dann aber immer, unabhängig von der möglichen Redundanz.

Die mögliche Redundanz wirkt sich dann aber ein wenig auf die Performance bei der Wiederherstellung aus. Hast du einen mirror aus zwei Geräten, wird ein defektes beim Wiederherstellen die Performance etwas mehr belasten, als wenn du einen mirror aus drei Geräten hast und hier einen Tausch vornimmst.

Zu dem teuren "Aufbohren" eines Pools möchte ich noch sagen, dass ich das ebenfalls schon lästig empfunden habe. Das gilt für das Hinzufügen von Platten generell (was ja noch ganz gut geht), das Hinzufügen größerer Platten oder das Erweitern auf eine höhere Redundanz. Hat man sich aber erst mal für eine generelle Aufrüstung entschieden und stellt einen neuen Pool her, dann ist die Übertragung der Daten wiederum ein rechter Genuss mittels zfs send/recv.
Im privaten Umfeld kann man mit solchen Lösungen ganz gut leben.
 

medV2

Well-Known Member
#45
Zu dem teuren "Aufbohren" eines Pools möchte ich noch sagen, dass ich das ebenfalls schon lästig empfunden habe. Das gilt für das Hinzufügen von Platten generell (was ja noch ganz gut geht), das Hinzufügen größerer Platten oder das Erweitern auf eine höhere Redundanz. Hat man sich aber erst mal für eine generelle Aufrüstung entschieden und stellt einen neuen Pool her, dann ist die Übertragung der Daten wiederum ein rechter Genuss mittels zfs send/recv.
Im privaten Umfeld kann man mit solchen Lösungen ganz gut leben.
Ihr müsst das positiv sehen: Man bekommt die Chance sein Backup und den Recoveryprozess zu testen, wie oft hat man das schon!
Dann ist das Aufbohren auch nicht mehr so teuer ;)
 

mr44er

Well-Known Member
#46
die Chance sein Backup und den Recoveryprozess zu testen, wie oft hat man das schon!
...erstmal zwei Diazepam rein und stilecht mit Fusel runterspülen. :D

Aber das sage ich so nur, weil ich ein wenig den Trotzkopf raus hängen lassen möchte.
Wenn du nicht die entsprechende HW hast, um Platten im laufenden Betrieb tauschen zu können, musst du natürlich kurz ausschalten. Das gilt dann aber immer, unabhängig von der möglichen Redundanz.
Neckisch, gefällt mir. ;)
Natives SATA wurde laut Spezifikation mit hotplug entwickelt. Das wird auch funktionieren, wenn im BIOS AHCI/native gestellt ist und dass der FreeBSD-Treiber es kann, setze ich einfach mal voraus.
Wenn man während eines notwendigen Plattentausches noch solche Eier hat, könnte man es im laufenden Betrieb tun. :p

Aber ja, besser nicht nachmachen. An offenen Geräten nicht rumfummeln, ohne vorher dem Stromstecker zu ziehen! :belehren:
 

medV2

Well-Known Member
#47
Natives SATA wurde laut Spezifikation mit hotplug entwickelt. Das wird auch funktionieren, wenn im BIOS AHCI/native gestellt ist und dass der FreeBSD-Treiber es kann, setze ich einfach mal voraus.
Wenn man während eines notwendigen Plattentausches noch solche Eier hat, könnte man es im laufenden Betrieb tun. :p

Aber ja, besser nicht nachmachen. An offenen Geräten nicht rumfummeln, ohne vorher dem Stromstecker zu ziehen! :belehren:

Naja mit Wechselrahmen geht das schon, bzw. auf "richtiger" Serverhardware hat man sowieso Fronteinschübe da geht das auch ohne Probleme.
Aber ja am privaten Gammelserver mach ich das auch vorsichtshalber im OFF Zustand.
 

cabriofahrer

Well-Known Member
#49
Es ist bisher nicht möglich z.B. aus einem 3 Disk RAIDZ ein 4 Disk RAIDZ zu machen. Das soll noch kommen, aber auch hier mehr ein Workaround mit relativ viel Plattenplatz-Verschleiß.
Könntest Du das etwas genauer erläutern? Wenn ich das richtig verstehe, meinst Du, man fügt einem schon erstellten RAIDZ mit 3 Platten eine vierte hinzu und erwartet, dass das RAIDZ sich automatisch auf die vier Platten verteilt, richtig?

Dazu eine Vorfrage, da ich mich mit ZFS noch gar nicht viel beschäftigt habe: Angenommen, man hat ein RAIDZ mit 3 Platten, eine verreckt und wird ersetzt: Geht das im laufenden Betrieb und wird dann automatisch mit der ausgetauchten Platte das RAIDZ wieder hergestellt?
 

medV2

Well-Known Member
#50
Zu Frage 2: Ja. Vorausgesetzt du kannst bei deiner HW die Platte im Betrieb tauschen.

Ad 1: Ist in Planung, wird dir aber nicht die ganze neue Platte ab Platz dazu geben. Für alle schon geschriebenen Daten bleibt die Stripesize gleich, nur bei neuen Daten hast du die neue max. Stripesize. Sprich wenn du schon 1TB auf dem RAID hast (inkl Redundanz) wird das auch auf dem erweitertem 1TB belegen.