[Sammelthread] ZFS Stammtisch

[Gelöschtes Mitglied 304674]

Ist aber halt auch eine 2.5"HDD,z umindest laut Datenblatt. Da sind dann die Werte nix besonderes.

Ups... dann ist die bei Geizhals wohl in die falsche (3,5") Kategorie rein gerutscht.

Okay, sorry für das bisschen Offtopic hier.

 

[CommanderBond]

Was den Stromverbrauch von HDDs angeht... ich habe die Tage folgendes gefunden:
Seagate SkyHawk 1TB, SATA 6Gb/s (ST1000LV000)

Leistungsaufnahme: 1.7W (Betrieb), 0.5W (Leerlauf)
Steht sogar so im Datenblatt.

Kann das überhaupt sein? So wenig für eine HDD?

naja hab hier noch ne 250GB 3,5er. Die verbraucht auch deutlich weniger als 4TB HDDs einfach weil dort meist nur ein Platter dreht. Das macht halt auch noch Unterschied ob nur eines dreht oder 6 bis 7.

 

[olqs80]

Hallo,
Bin gerade am ausprobieren von Napp-It um mir vielleicht ein bisschen Ram auf meinem All-in-One ESX zu sparen und bekomme einen Fehler beim Pool einrichten mit ashift=12.
Was ich gemacht habe:
OmniOs napp-it Image runtergeladen. OmniOS geupdated (OmniOS v11 r151030ap), Nappit geupdated auf die 19.12a1 homeuse. Eine SSD als RDM an die VM durchgereicht.
Wenn ich jetzt einen neuen Pool mit ashift=12 anlegen will, dann bekomme ich folgende Fehlermeldung:
property 'ashift' is not a valid pool property
Mit Auto wird der Pool mit ashift=9 also 512 Byte Blöcken angelegt.

Was muss ich machen um einen Pool mit ashift=12 anlegen zu können?

 

[gea]

OmniOS unterstützt erst in der Version 151032 das direkte Einstellen von ashift beim Anlegen eines vdev. Am einfachsten Updaten auf 151032, siehe Punkt 4, in https://napp-it.org/manuals/index.html

Bei 151030 könnte man ashift nur über das Editieren der Platteneigenschaften in sd.conf bei SAS/Sata Platten erreichen.

siehe Release Notes:

omnios-build/doc/ReleaseNotes.md at r151032 · omniosorg/omnios-build

Build system for OmniOS. Contribute to omniosorg/omnios-build development by creating an account on GitHub.

github.com

alternativ das ESXi ova Template mit aktuellem OmniOS 151032 stable nehmen

napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana and Solaris : Downloads

napp-it.org - ZFS NAS SAN Server mit einer durch den Benutzer anpassbaren Weboberfläche // All In One server = virtualisierter lauffähiger ZFS-Server

napp-it.org

 

[fdiskc2000]

Hate ich auch gerade, habe auch noch die 151030. Allerdings ging es bei mir auch mit auto

 

[gea]

Bei ashift=auto wird die physical sectorsize der Platte ausgelesen und benutzt. Bei einer 4k Platte bedeutet das ashift=12. Hat man aber eine Platte mit physical=512B und möchte ashift=12 erzwingen brauchts das neue OmniOS oder ein Editieren der sd.conf..

Auch wegen der vielen neuen Features wie smb3, ZFS Verschlüssellung, special vdev, trim etc würde ich aber ein Update empfehlen.

 

[olqs80]

@gea
Danke dir, wollte nicht nur zum Testen von der LTS Version weg. Dann werde ich heute Mal updaten.

Edit:
Nach Update auf die 151032 geht alles. Nochmals danke

 

[gea]

Für kommerzielle Cloudlösungen gibts Amazon S3
Ist wahnsinnig schnell und skaliert bis unendlich,

Falls jemand mit minIO ein dazu kompatiblen inhouse oder home Server
auf OmniOS/ZFS Basis mit minIO ausprobieren möchte:

unter OmniOS/napp-it
- Update napp-it auf 20.dev oder 19.12b home/free
- Menu Services > minIO S3 Services: install minIO
- Menu ZFS filesystems :S3cloud aktivieren z.B. :9000

im Browser dann ip:9000

Mann kann das Dateisystem zusätzlich per SMB oder NFS sharen,
muss nur auf die Rechte etwas achten.

Amazon S3 compatible ZFS cloud with minIO

Due a customer/my request, OmniOS added minIO client and server and rclone to the extra repo Package Catalog MinIO | Enterprise Grade, High Performance Object Storage MinIO | MinIO Client Quickstart Guide MinIO | The MinIO Quickstart Guide MinIO Enjoying Role in Emerging Cloud Architecture...

forums.servethehome.com

Macht richtig Spaß und hat nicht die Komplexität und Abhängigkeiten
von Owncloud und Konsorten. Einschalten und tut einfach.

minIO ist mal eine Lösung die richtig gefällt. Der ganze Server ist ein einzuges File
und nicht 500 Dateien mit ihren Abhängigkeiten (AMP Stack) und Empfindlichkeiten.

 

[morph027]

Definitiv, nutz ich auch schon ewig, auch genial im eingebauten Clustermodus, hab da auf meiner alten Arbeit mal ein Mini-CDN mit aufgesetzt. Geiler Shice!

Hat halt (noch) keine Versionierung, aber dafür haben wir ja erst mal ZFS

 

[you]

Mh. Heisst das, man kann min.io als Nextcloud-Ersatz nutzen? Einfach auf napp-it installieren, auf den Endgeräten einen Client installieren und Dateien über Geräte hinweg synchron halten? Gibt es eine Empfehlung für solch einen GUI-Client für MAC?

Nextcloud läuft bei mir und ich fasse die Installation ewig nicht an, weil Updates in der Vergangenheit regelmässig in die Grütze gegangen sind.

 

[gea]

Ja
Auf den Engeräten kann man direkt einen Webbrower für upload und download nutzen. Muss also da nichts installieren (Wahnsinnig schnell). Man kann auch rclone nutzen (rsync für Cloud), Duplicati als Backupprogramm für OSX, Linux und Windows, https://www.duplicati.com/ oder andere Clients z.B. VEEAM.

Ich habe mich auch schon mit NextCloud versucht und es gelassen. Das ist ein Überteil mit soviel Abhängigkeiten und Angriffspunkten. MinIO ist dagegen die Offenbarung. Tut einfach, ist wahnsinnig schnell und es ist lediglich EINE relativ kleine Datei. Installieren, ein/ausschalten und es tut. Es gibt auch keinerlei Abhängigkeiten zum OS oder anderen Applikationen wie bei ander Diensten wo eins von den vielen Sicherheitsupdates die es da notwendigerweise gibt (denke an Apache, mySQL und den vielen PHP Modulen) irgendo anders zu Problemen führt. Auch kann man per Client mit Anmeldung auf ein S3 Share oder per Link auf eine Datei den man im minIO Webclient für 1-7 Tage erzeugt.

S3 im Single Client Modus (ohne Cluster) arbeitet mit SMB (bis auf die fehlenden Dateirechte) problemlos zusammen. Versionierung über ZFS Snaps und Windows vorherige Version sollte also keine Probleme bereiten. Verschlüssellung des ZFS Dateisystems rundet das Ganze perfekt ab.

 

[Shutterfly]

Schönen guten Tag zusammen,

ich hätte zum Thema ZFS einmal eine Frage, weswegen ich mich nun hier das Gespräch mit den Profis suchen würde: Bislang betreibe ich einen Heim-Server mit 4x 2TB WD Red für NAS-Funktionalitäten, welche ich aufgrund von Flexibilität mit SnapRAID und MergerFS realisiert habe.

Grundsätzlich bin ich mit der Lösung zufrieden, sie läuft seit gut 3,5 Jahren problemlos. Damals hatte ich mich auch mit ZFS beschäftigt, es jedoch vorschnell abgetan, da ich die Anforderungen an das System noch nicht kannte und ZFS mir zu unflexibel war.

Inzwischen weiß ich, dass von den 6 TB Speicherplatz nach fast 4 Jahren gut 60% gefüllt sind und für mich nun immer mehr die Frage in den Raum rückt: Ist mein System stabil und sicher. Offsite Backups der wichtigsten Daten sind natürlich vorhanden und nicht Gegenstand meiner Überlegung.

Nun gut, lange Rede, kurzer Sinn: Ich habe mich nun noch einmal in ZFS eingelesen und überlegt, wie ich ein ZFS-Setup aufbauen könnte und wie später eine Erweiterung aussehen könnte, wenn die Platten doch mal nicht reichen. Da ich ein z2 aufgrund des Speicherplatzes nicht machen kann, wäre maximal ein z1 möglich. Auf der offiziellen ZFS-Doku wird jedoch von z1 abgeraten:

Two-disk failures are common enough[5] that raidz1 vdevs should not be used for data storage in production.

Persönlich habe ich in meiner beruflichen Erfahrung nie ein Two-Disk failure erlebt, jedoch würde ich deswegen diesen nicht ausschließen, vor allem weil meine Daten nicht repräsentativ sind. Wie ist hier eure persönliche Einschätzung? Wenn ich es richtig verstanden habe, dann ist bei Verlust von zwei Platten bei z1 der ganze Pool verloren oder? Bei meiner aktuellen Lösung wären nur die Daten auf den jeweiligen Platten verloren, da kein Striping stattfindet (mit allen Vor- und Nachteilen natürlich).

Dann noch eine Frage zur Erweiterung: Gehen wir von oben genannten raidz1 aus, welcher nun zu voll ist. Wenn ich nun den Pool Vergrößern möchte, dann geht dies effektiv nur indem ich parallel einen neuen Pool eröffne oder?

 

[CommanderBond]

Bedenke dass nicht zwangsweise 2 Platten komplett ausfallen müssen. Es kann auch eine ausfallen und die zweite hat Lesefehler. Dann hast du bei einem Z1 eben schon Datenverlust.
Bedenke auch dass zum Wiederherstellen bei Z1 eben von allen Platten gelesen werden muss. Ein Mirror hat hier Vorteile weil im Fehlerfall weniger gelesen werden muss und damit es ne geringe statistische Fehlerwarscheinlichkeit gibt.

Von daher würd ich auch Z1 eher meiden vorallem bei großen Platten. Aber es kommt auch drauf an was man genau vor hat. Am Ende muss man das selbst abschätzen

 

[Shutterfly]

Das selbst abschätzen ist für mich als Unwissenden aber durchaus schwierig, da ZFS mit all seinen Funktionen, Möglichkeiten und dadurch verbundene Bedingungen nicht mal eben von außen so einfach ersichtlich ist.

Ich habe auch schon nach einem "ZFS into the nutshell" für Anfänger gesucht, wo all die möglichen bzw. relevanten Konfigurationen und deren Kombinationen vorgestellt und beleuchtet werden. Leider habe ich bislang nichts gefunden, wo ich sage, dass es mir hilft.

Für mich bleibt irgendwie das Gefühl, dass ZFS sich mit 4 Festplatten nicht so wirklich lohnt sondern erst ab 8 irgendwie so richtig interessant wird.

 

[gea]

Prinzipiell hat ZFS auch schon bei einer Platte (ohne Raid) wichtige Vorteile wie

- Copy on Write
Damit ist das Dateisystem crashsicher auch bei einen Absturz beim Schreiben der sonst ein korruptes Dateisystem bedeuten kann

Snaps/ Versionierung
Damit wird ein vorhandener Datenbestand readonly eingefroren. Wichtig gegen Ransomware. Man kann tausende Snaps anlegen ohne Performanceverlust. Snaps belegen nur den Platz geänderter Datenblöcke. Tausend identische Saps belegen keinen Platz.

Echtzeit Prüfsummen auf Metadaten und Daten
Jede Datenverfälschung warum auch immer wird sofort entdeckt.

Dazu Trim, Verschlüssellung und leistungsfähige Schreiblese Caches (RAM) und sicheres sync Schreiben.

Mit Raid
Wegen Copy on Write gibt es kein Writehole Problem wie bei klassichem Raid. Selbst bei einem Absturz beim Schreiben bleibt ZFS Raid valide. Wird ein Prüsummenfehler beim Lesen oder Scrubben entdeckt, wird er automatisch repariert. Dazu Verfügbarkeit/ Schutz gegen Hardwareausfall. Mit 3way Mirror oder Z3 dürfen z.B. ohne Datenverlust drei Platten je vdev/Einzelraid ausfallen.

Am einfachsten startet man bei TFS mit einem einfachen Mirror aus zwei Platten. Erweitern kann man so einen Pool mit einem weiteren Mirror oder Tausch der Platten gegen größere.

Mit ZFS Z1 ist das Fehlerrisiko übrigens geringer als mit Raid-5.
Fallt bei Raid-5 eine Platte aus, so bedeutet der nächste Fehler üblicherweise Array lost. Bei ZFS Z1 lediglich den Verlust der betriffenen Datei.

 

[Shutterfly]

Das Copy on Write ggf. jedoch auch zum Problem werden kann (in anderem Kontext) musste ich auch schon feststellen: https://www.ixsystems.com/community...d-why-we-use-mirrors-for-block-storage.44068/

Am einfachsten startet man bei TFS mit einem einfachen Mirror aus zwei Platten. Erweitern kann man so einen Pool mit einem weiteren Mirror oder Tausch der Platten gegen größere.

Ein Mirror würde in meinem Fall aber ja auch nicht gehen, da bei einem Mirror mit 4 Platten, effektiv nur zwei übrig bleiben.

 

[gea]

Bei vier Platten sind die üblichen Varianten 2 x Mirror (Raid 10) oder Raid-Z1. Raid-Z2 ginge auch. Da könnten zwar 2 beliebige Platten ausfallen wäre aber ansonst langsamer als Raid-10 bei kleinen Dateien.

Wenn man für alle wichtigen Daten ein Backup hat wäre Z1 am effektivsten was Platz angeht. Selbst wenn man eine Redundanz hat bei der mehrere Platten ausfallen können, sollte man ohnehin ein Disasterbackup (schützt gegen Feuer, Diebstahl, Amok Hardware) haben. Ich habe das zwar in den 10 Jahren seit ich ZFS nutze nicht mehr gebraucht da ich alles was ich verlor aus Snaps wiederherstellen konnte und das Raid (Z2/Z3) immer ausreichend gut war, aber irgendwann werde ich es brauchen.

 

[Shutterfly]

Z1 wäre für mich auch die einzige Option.

Wichtige Daten werden regelmäßig auf eine USB-Platte übertragen. Wirklich wichtige Daten gehen auch Offsite. Daher könnte ich mit dem Risiko leben.

Gedankenspiel: Wenn ich Z1 wählen würde und dann wäre der Platz eng, hätte ich zwei Optionen:

1. Platten nach und nach aus dem Z1 austauschen bis alle Platten getauscht sind und dann stünde der neue Speicherplatz zur Verfügung.
2. Einen zweiten Pool aufmachen und parallel betreiben (sei es nun Mirror, Z1 oder was auch immer)

Bei Variante 1 benötige ich direkt vier neue Platten, bei Variante 2 kann dies nicht zu einem gemeinsamen Storagepunkt zusammengefasst werden oder?

 

[gea]

1. Ja

2. Nein.
Man kann zwar weitere Pools anlegen, aber hier geht es ja darum die Kapazität eines Pools zu vergrößern. Dazu würde man an das erste Raud-Z1 einfach ein oder weitere Raid-Z1 anfügen. Bei traditionellem Raid würde man da von Raid 50 sprechen. Jedes witere Raid das man an den Pool anfügt vergrößert sofort dessen Kapazität und für neue Daten die Performance - mit der Zeit auch für vorhandene Daten.

 

[Digi-Quick]

Das Copy on Write ggf. jedoch auch zum Problem werden kann (in anderem Kontext) musste ich auch schon feststellen: https://www.ixsystems.com/community...d-why-we-use-mirrors-for-block-storage.44068/

Hier geht es um VMs und die Fragmentierung derselben.

VMs packt man auf SSDs, damit löst sich das Thema Fragmentierung in Luft auf zzgl. der besseren Performance

Des weiteren werden die Kosten für große SSDPools für VMs angemeckert.
Auch hier gilt "Teile und Hersche": VMs auf SSD-Pool, Nutzdaten auf HDD Pool (per SMB, NFS oder iSCSI an die VMs angebunden)

Wo war noch gleich das Problem?

@gea:
Du vermeidest immer wieder gerne den Nachteil zu nennen, den man hat, wenn man einen Pool durch anfügen eines weiteren VDEVs vergrössert (entspricht Raid 10/50/60).geht ein VDEV hops, ist der Pool futsch - verhält sich bei Raid 10/50/60 aber auch nicht anders.
Die Wahrscheinlichkeit, daß ein Raidz1 VDEV beim rebuild stirbt ist durchaus mit gegeben - je nach Größe und URE (UBER) der verwendeten HDDs.
(Führt eigentlich ein Lesefehler beim Resilver automatisch zum Abbruch wie beim "klassischen" Raid Rebuild, oder wird trotzdem weiter resilvered und nur die nicht rekonstruierbare Datei angemeckert?)

 

[Shutterfly]

Da ich derzeit auf meinem HDD-Pool, um mal beim Wording zu bleiben, auf VMs für KVM liegen habe, war das für mich relevant ohne es explizit erwähnt zu haben

 

[gea]

@gea:
Du vermeidest immer wieder gerne den Nachteil zu nennen, den man hat, wenn man einen Pool durch anfügen eines weiteren VDEVs vergrössert (entspricht Raid 10/50/60).geht ein VDEV hops, ist der Pool futsch - verhält sich bei Raid 10/50/60 aber auch nicht anders.
Die Wahrscheinlichkeit, daß ein Raidz1 VDEV beim rebuild stirbt ist durchaus mit gegeben - je nach Größe und URE (UBER) der verwendeten HDDs.
(Führt eigentlich ein Lesefehler beim Resilver automatisch zum Abbruch wie beim "klassischen" Raid Rebuild, oder wird trotzdem weiter resilvered und nur die nicht rekonstruierbare Datei angemeckert?)

Es ist immer ein Abwägen. Ein Z1/Raid-5 hat eine gewisse Wahrscheinlichkeit eines Totalverlusts. Bei einem 2xZ1/Raid 50 verdoppelt sich das. Ein 2 x Z2/ Raid 60 hat eine viel geringere Fehlerwahrscheinlichkeit, kostet halt mehr. So wie hier @home durchaus ein Argument, wobei ich auch kommerzielle Nutzer betreue die entgegen meinem Rat n x Z1 einsetzen (billig und schnell).

Immerhin weiß ZFS bei einem Lesefehler durch die Daten-Prüfsummen welche Datei davon betroffen ist. Im Gegensatz zu traditionellem Raid 1/5/50/6/60 ist daher das Raid nicht verloren/korrupt sondern nur die betroffene Datei. wird als defekt gekennzeichnet.

 

[asche77]

Ein Z1/Raid-5 hat eine gewisse Wahrscheinlichkeit eines Totalverlusts. Bei einem 2xZ1/Raid 50 verdoppelt sich das.

.
Die Erhöhung der Ausfallwahrscheinlichkeit dürfte nicht linear verlaufen, sondern stärker als linear ansteigen, je mehr singuläre Risiken zusammenkommen.

Der Pool überlebt ja nur, wenn SOWOHL vdev1 ALS AUCH vdev2 überleben.

Meine Stochastik Kenntnisse sind aber auch zu verrostet um das in eine näherungsweise Formel zu kleiden...

 

[jonofe]

Die Erhöhung der Ausfallwahrscheinlichkeit dürfte nicht linear verlaufen, sondern stärker als linear ansteigen, je mehr singuläre Risiken zusammenkommen.

Solange die Ausfallwahrscheinlichkeit der einzelnen vdevs gleich ist (z.B. weil gleiche Platten, gleichen Alters verwendet werden), ist die Steigerung des Riskos linear, denn die Risiken des Ausfalls von vdev1 und vdev2 sind unabhängig voneinander, daher addieren sich die Wahrscheinlichkeiten.

 

[Shutterfly]

Ich bin noch fleißig am recherchieren und einlesen. Ich hatte eingangs vergessen zu erwähnen, dass die vier HDDs derzeit alle per LUKS vollverschlüsselt sind und beim Boot mit jeweils einem eigenem Key geöffnet werden.

Hat jmd. Erfahrungen mit verschlüsselten ZFS Pools und kann diese empfehlen oder aus zu nennenden Gründen gerade nicht empfehlen? Ich möchte mit der Verschlüsselung das Szenario eines Einbruchs und Diebstahls abdecken.

Liebäugel derzeit mit FreeNAS.

 

[gea]

ZFS Verschlüssellung mit einem eigenen Schlüssel je Dateisystem läuft bei Original ZFS unter Solaris seit fast 10 Jahren perfekt. In OpenSolaris war das fast fertig. Datto hat das dann unter Open-ZFS auf dieser Basis fertigentwickelt. Seit letztem Jahr ist das nun in Illumos (NexentaStor,OI,OmniOS, SmartOS) und Linux enthalten und kann als stabil gelten.

Free-BSD hängt aktuell durch den Wechsel von Illumos zu Linux als Upstream fast ein Jahr hinterher. Neue ZFS Features wie Verschlüssellung oder special vdevs sind da noch nicht enthalten.

 

[Shutterfly]

Wenn ich das nun richtig verstehe, dann soll FreeNAS das noch nicht können? War darüber gestolpert, dass FreeNAS mit Version 8 oder 9 eine Full Disk Encryption per geli eingeführt hat. Eine native ZFS Verschlüsselung wäre vermutlich besser/schöner, jedoch würde dies meinem Wunsch nach Verschlüsslung doch erst einmal ausreichend genug nachkommen oder übersehe ich etwas?

Nachtrag: Was ich gerade gesehen habe. Oder ist geli nicht so schön, da ZFS dann "Zugriff" auf die eigentliche Hardware verliert?

 

[gea]

Geli ist wie Luks eine Verschlüssellung der Festplatten außerhalb von ZFS. Beide Verfahren sind inkompatibel und eigentlich mit ZFS eine Sackgasse.

 

[Shutterfly]

Na dann scheint ZFS für mich derzeit wohl gestorben zu sein. Unter Linux scheint es hier offenbar auch noch das ein oder andere Problem zu geben: https://github.com/openzfs/zfs/issues/9458

 

[gea]

Wie bereits angemerkt, man kann ZFS auch mit Geli, Luks laufen lassen oder auf Original ZFS unter Solaris gehen (immer noch das schnellste ZFS) oder einen Solaris Fork nehmen. Da ist ZFS am Besten integriert, man hat alle aktuellen Features und den kernelbasierten SMB Server. Und es tut einfach ohne die Linux Adventuregames.