[Sammelthread] ZFS Stammtisch

[mlampe]

Hallo,

Das siehst Du nicht falsch.
Beim Linux kennt das MDADM das EXT4 nicht. Auch ein LVM zwischen MDADM und EXT4 ändert an der Tatsache nichts. Das ist der Grund, wie bei jedem anderen HW-Raid-Controller auch,
dass alle Blöcke der HDD wiederhergestellt werden müssen. Egal ob diese im Dateisystem belegt waren oder nicht.
ZFS ist "Raid-Manager", Volume-Manager und Dateisystem in einem. Daher weiß ZFS beim Resilvern welche Blöcke belegt sind und damit wieder hergestellt werden müssen.

Ich benutze seit vielen Jahren ZFS aus unter anderem diesem Grund und möchte es nicht mehr missen.

 

[xymos]

Update: es ist amtlich. Während ich unter OmniOS immer nur pools mit "ashift=9" anlegen konnte, hat Solaris 11.3 auf Anhieb einen mit ashift=12 erstellt.

(Jetzt muss ich nur noch die sendmail Meldung wegbekommen "unable to qualify my own domain name (HOSTNAME) -- using short name")

Update2: Schreibperformance ist geringfügig besser, aber der Atom 330 mit seinen 2GB RAM macht nicht wirklich Spaß. Allerhöchstens was für Backup-Betrieb... trotz 4K Sektoren

Update3: Read-Performance ist allerdings m.E. für's erste völlig ok! Bis auf eine kurze Delle am absoluten Maximum des 1Gbit-Links:
Anhang anzeigen 333581

Ich habe mit OmniOS keine Probleme den Pool mit ashift=12 zu erstellen. Muss aber erwähnen, dass das nur mit Hilfe eine SAS Controllers funktionierte.
Der Zuwachs an Geschwindigkeit lag bei ca 110mb/s mit einem pool aus 5 platten @ RaidZ2.

 

[gea]

Es gibt dazu eine Wiki Seite
ZFS and Advanced Format disks - illumos - illumos wiki

Grundsätzlich gilt:
Ashift ist eine vdev Eigenschaft, keine Pool Eigenschaft
Im Gegensatz zu anderen ZFS Systemen gibt es bei Solaris keinen Option das beim Erstellen des Pools/vdevs anzugeben- eben weil das ursächlich eine Platteneigenschaft ist.
Wenn eine Platte eines neuen vdevs als 4k Platte erkannt wird, wird automatisch das vdev auf ashift=12 gesetzt
Wenn man nur 512b Platten einsetzt, sollte man ashift=12 erzwingen. Ansonst gibt es keine Möglichkeit eine ausgefallene Platte gegen ein neueres 4k Modell zu ersetzen.
Unter Solaris kann man in der sd.conf die Parameter einzelner Platten ändern. Der genutzte Controllertreiber muss das aber unterstützen. Der mpt Treiber für LSI HBAs macht das.

 

[zos]

16gb Stick geht aber wird schon knapp.

Es reicht locker wenn Du den rpool mit compression=lz4 anlegst (siehe howto)

 

[besterino]

Alles verstanden. Ich sagte ja auch nur, dass für mein System die automatische Erkennung der ashift Parameter unter Solaris 11.3 besser ist als unter OmniOS. Natürlich hängt das maßgeblich von den eingesetzten Platten und dem Controller /HBA ab.

 

[gea]

Ich habe das .ova Template (v15d) für den napp-it ZFS Server unter ESXi aktualisiert
Es enthält jetzt den Fix für den L2Arc bug und TLS für Googlemail

https://napp-it.org/downloads/napp-in-one.html

 

[Digi-Quick]

Digi-quick: wie kommst du darauf dass es nicht volllast ist? Bei der Platte kommt es drauf an welche Sektoren du in welcher Reihenfolge beschreibst daher liefert "volllast" nicht immer die gleiche Performance, dennoch wird die Hdd nicht weniger mechanisch belastet auch wenn deutlich weniger mb/s durchgehen. 5tage ist schon ne Hausnummer. Dafür sind die Platten einfach nicht konstruiert. Ich habe so meine Bedenken.

Die Platten laufen auch im Normalbetrieb nie unter "Vollast", da das GBit LAN limitiert.

Besser wäre es man würde bei nem Hdd Ausfall einfach alles woanders hinkopieren dann müsste man nur lesend auf die Platten zugreifen.

Prinzipiell 'ne gute Idee, würde bei zur Zeit ca. 60TB Belegung aber via GBit LAn mind. genauso lange dauern - un d würde ein weiteres Speichersystem mit entsprechend viel Kapazität erfordern. mein 2. "Backup NAS" für die wirklich wichtgen DSaten hat derzeit aber nur 16 TB Netto, reicht also hinten und vorne nicht (Grösseres System ist in Vorbereitung, dauert aber noch).

 

[Opticum]

gea: danke für das Update. Gibt es bezüglich der NFS Problematik schon Neuigkeiten? "Traue" mich noch nicht recht zu wechseln.

 

[CommanderBond]

Die Platten laufen auch im Normalbetrieb nie unter "Vollast", da das GBit LAN limitiert.

Was hat das eine jetzt mit dem anderen zu tun? Zusammenhang Resilvern und Gbit LAN?

Die Platten laufen beim Resilvern unter Volllast, was sollte sie denn sonst bremsen? Warum macht da die einzelne Platte wohl nur 10-20MB/s ? Weil sie mehr nicht schafft, ergo Vollast.

 

[gea]

gea: danke für das Update. Gibt es bezüglich der NFS Problematik schon Neuigkeiten? "Traue" mich noch nicht recht zu wechseln.

Esxi ist sehr heikel. Je nach Version gibt es da gern mal Probleme. OmniOS hat in der neuesten Version einige NFS Verbesserungen erhalten. Bei mit läuft das aktuelle OmniOS mit ESXi 5.5U2 und 6.00b problemlos, es gibt aber einzelne Berichte über "all Path Down" Probleme.

Mit ZFS ist das aber kein Problem. Updaten und bei Problemen auf den letzten Systemsnap zurückgehen. Auch der Aufwand mit einer parallelen Installation ist rechr gering. Neues System booten, Pool importieren, NFS an und in ESXi importieren - eventuell ESXi dann neustarten und VMs ins Inventar aufnehmen.

Bei NFS Problemen Queue Depth verringern (vgl https://kb.netapp.com/support/index?page=content&id=1014696 ) bzw e1000 und vmxnet3 probieren. Wenn das alles nicht hilft, eine andere ESXi Release probieren oder bei OmniOS 151012 bleiben.

 

[besterino]

Ich hätte da mal eine Frage zu Deduplication:

Ich plane einen 1TB Pool aus 4x 256GB SSDs (JBOD ohne Parity). Die Idee ist, diesen Storage allen PCs im Netz (ca. 4) als Hauptlaufwerk für Programme (nicht Nutzdaten) zur Verfügung zu stellen.

Für die weitere Planung würde mich nun zunächst interessieren, ob Deduplication auch über unterschiedliche ZFS Filesystems hinweg funktioniert? Konkret: wenn ich für jeden PC sagen wir ein 100GB Filesystem (zwecks iSCSI) auf diesem "SSD-Pool" anlege, dedupliziert der dann über alle diese Filesysteme?

Da die wesentlichen "großen" Programme auf allen Systemen voraussichtlich im Wesentlichen identisch sein werden (Office, Adobe & Co.), wäre meine Hoffnung, dass ich damit theoretisch ordentlich Platz sparen könnte. Bei SSDs mit den verhältnismäßig hohen Kosten pro GB dann doch zumindest eine Überlegung wert. Auch ist 1TB noch eine Menge, die ich mit meinen 32GB Hauptspeicher stemmen können sollte.

Oder ist Deduplication auch mit dem oben genannten Einsatzzweck einfach doch zu anfällig/kompliziert/sinnfrei für den Heimgebrauch?

 

[gea]

Der genannte Einsatzzweck mit einem eigenen kleinen Pool ist eine der wenigen Anwendungsfälle in denen ZFS Realtime dedup derzeit sinnvoll ist da damit eventuell hohe dedup Werte möglich sind.

Ich würde aber niemals ohne Redundanz arbeiten.
Dazu fallen auch SSDs zu oft aus und dann ist es zumindest ärgerlich und bedeutet Arbeit. Also eher Raid-Z1 als Raid-0

Ansonsten:
Dedup wird zwar als Eigenschaft eines Dateisystems aktiviert, arbeitet aber immer Poolweit. Das ist auch das Hauptproblem für normale Nutzung. Einmal aktiviert wird man das nur durch einen Pool-Destroy wieder los.

Ungünstig ist der hohe Ramverbrauch auch weil dieser RAM dann als Cache fehlt und da bringt er Performance. Da auch SSD inzwischen recht billig sind, ist es eine Abwägung.

 

[Ironcurtain86]

Hallo,

gea besteht evtl. die Möglichkeit, dass du ein Einsteiger-Tutorial für napp-it schreibst? Ich finde es für Neulinge irgendwie schwierig in das Thema zu kommen. Da wäre ein Tutorial auf Basis eines bekannten Systems (HP Microserver) für einen gängigen Anwendungsfall (Datenbackup) nicht schlecht.

Gruß

Ironcurtain

 

[besterino]

Ok, danke! Ich werde es vielleicht einfach mal ausprobieren. "no parity" ist für mich deshalb ok, weil ich 1x täglich den "kleinen" SSD-Pool auf meinen HDD-Pool wegsichern wollte. Da dort nur Programme liegen werden, betrifft der Verlust von 24h halt nur irgendwelche Softwareupdates usw... also nicht so schlimm. Da sind mir 256GB zusätzlich einfach wichtiger als Raidz.

@Ironcurtain86: äh... Napp-it Handbuch?

Wer das nicht liest, liest auch kein anderes Newbie-Tutorial. Man könnte das vielleicht nur etwas prominenter auf der HP platzieren.

 

[zos]

Dedup wird zwar als Eigenschaft eines Dateisystems aktiviert, arbeitet aber immer Poolweit. Das ist auch das Hauptproblem für normale Nutzung. Einmal aktiviert wird man das nur durch einen Pool-Destroy wieder los. Ungünstig ist der hohe Ramverbrauch auch weil dieser RAM dann als Cache fehlt und da bringt er Performance. Da auch SSD inzwischen recht billig sind, ist es eine Abwägung.

Ich nutze Dedup nicht und beabsichtige das auch nicht, aber trotzdem kam mir bei dieser Diskussion folgender Gedanke:

Da Dedup immer poolweit gilt und man im SOHO-Bereich inzwischen mit recht großen Platten von 4 bis 8TB, aber doch meist mit RAM <= 32GB arbeitet, wäre es doch möglich, mittels Slices/Partitions auf einer Platte zwei Pools anzulegen. Davon einen kleineren Pool, um diesen für Dedup zu nutzen. Man müsste also nicht direkt Massen an RAM dafür bereit stellen.

Abgesehen davon, dass das ziemlich unkonventionell ist, welche weiteren Nachteile (Disk-fail mal außen vor, regelmäßige Backups vorausgesetzt) holt man sich mit einer solchen Lösung ins Haus?

 

[gea]

Hallo,

gea besteht evtl. die Möglichkeit, dass du ein Einsteiger-Tutorial für napp-it schreibst? Ich finde es für Neulinge irgendwie schwierig in das Thema zu kommen. Da wäre ein Tutorial auf Basis eines bekannten Systems (HP Microserver) für einen gängigen Anwendungsfall (Datenbackup) nicht schlecht.

Gruß

Ironcurtain

Das wichtigste steht auf napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana, Solaris and Linux : Handbcher

Das Problem ist jedoch, dass napp-it ein offenes System ist.
Es läuft auf unterschiedlichen Distributionen und versucht die schier endlose Vielfalt der Ideen der früheren Sun Entwickler in den wichtigsten Funktionen per Web-UI bedienbar zu machen. Da ist oft ein einfaches HowTo zu oberflächlich und die Manuals von Sun/ Oracle erschlagen einen geradezu. Auch ist es gar nicht so einfach. ältere Solaris Express 11 Manuals (habe ich oben verlinkt) zu finden da nur die genau für Illumos passen. Die aktuellen Manuals sind für Oracle Solaris 11 und das ist bei manchen Details anders.

Datenbackup ist aber eh easy
Am Besten alles auf den Server legen und von da arbeiten. Dazu ausreichen Auto-Snaps anlegen lassen und zusätzlich ein Disaster-Backup wichtiger Daten auf andere Festplatten.

Alternativ:
Lokale Daten/ Ordner mit dem NAS syncron halten (per robocopy etc) und Snaps anlegen.
Disaster Backup nicht vergessen.

Professionell würde man zwei oder drei Systeme einsetzen, die sich selbstständig replizieren.

 

[besterino]

@zos: von ZFS Pools nur über Teile wird nach meiner Erfahrung außer zu Testzwecken überall abgeraten. Warum bekomme ich nicht mehr zusammen, war aber so gravierend, dass ich es für mich kategorisch ausgeschlossen hatte.

 

[gea]

@zos: von ZFS Pools nur über Teile wird nach meiner Erfahrung außer zu Testzwecken überall abgeraten. Warum bekomme ich nicht mehr zusammen, war aber so gravierend, dass ich es für mich kategorisch ausgeschlossen hatte.

Rein funktionell ist es kein Problem, Pools aus Partitionen aufzubauen.
Vom Handling her ist das aber ein Chaos. Wenn da eine Platte ausfällt, sind mehrere Pools betroffen. Dann eine kleine Unachtsamkeit und die Malaise ist perfekt. Daher macht man das einfach nicht sondern nimmt besser weitere kleinere Platten.

 

[zos]

@zos: von ZFS Pools nur über Teile wird nach meiner Erfahrung außer zu Testzwecken überall abgeraten. Warum bekomme ich nicht mehr zusammen, war aber so gravierend, dass ich es für mich kategorisch ausgeschlossen hatte.

Jeder root-pool ist ein Pool auf einem Slice. Wie ich schon schrieb, es ist unkonventionell und in Produtkionsumgebungen wird davon abgeraten (siehe hier: "Using slices in a ZFS configuration is not recommended for a production environment."), aber warum steht dort nicht, aber in diesem Zusammenhang ist es auch egal, in Produktionsumgebungen sollte es an einer Platte mehr oder weniger, bzw. an einem RAM-Riegel mehr oder weniger sowieso nicht scheitern.

Es geht mir hier um den SOHO-Bereich. Wie gesagt, ich persönlich habe bei mir @home keinen Anwendungsfall für dieses Szenario, die Frage, ob es "nur" unkonventionell oder gar gefährlich ist, ist eher theoretischer Natur. Aber trotzdem interessiert mich dann auch, warum genau es gefährlich ist und eine Antwort a la "davon wird abgeraten" ist mir nicht konkret genug.

EDIT: @gea: OK, das ist mir ja bewusst. Da es also keine weiteren Gründe zu geben scheint, mag es also durchaus Anwendungsfälle geben, in denen das vertretbar ist (wie immer gilt: Backups vorausgesetzt). Es ging ja um die Frage, wie man, wenig Systemressourcen vorausgesetzt, mit wenig RAM einen kleinen Pool mit Dedup betreiben könnte, da die property ja eben poolweit gilt.

 

[gea]

Was häufiger @home oder SoHo gemacht wird, ist eine schnelle SSD zu partitionieren und als L2ARC oder ZIL für einen oder mehrere Pools zu nutzen. Der Ausfall eines Log oder L2Arc stellt aber auch kein direktes Problem dar.

 

[Opticum]

gea: hast du eine Empfehlung was die Datensicherung über WAN angeht? Habe mein Benutzerverzeichnis (rd. 500 GB) was ich gern mit einer entfernen Maschine (ZFS könnte ich einrichten) abgleichen würde.
ZFS Send/Receive hate ich ins Auge gefasst. Läuft das gut über WAN? (20 Mbit Upload vorhanden)

 

[1chris]

gea: hast du eine Empfehlung was die Datensicherung über WAN angeht? Habe mein Benutzerverzeichnis (rd. 500 GB) was ich gern mit einer entfernen Maschine (ZFS könnte ich einrichten) abgleichen würde.
ZFS Send/Receive hate ich ins Auge gefasst. Läuft das gut über WAN? (20 Mbit Upload vorhanden)

zfs send/receive überträgt die Daten Block für Block (aus Snapshots). Das heißt du solltest an er Quelle (und am Ziel) lz4-compression aktivieren, damit die zu übertragende Datenmenge geringer wird.
Da du sicher die Kopieraktion über ssh laufen lässt, könnte man hier auch noch etwas mit Compression auf der Übertragungsstrecke rausholen (ssh-Option -C).

Sind die 500G Daten bereits komprimiert?

 

[Opticum]

1chris: ja, sind hauptsächlich .raw und .jpg Dateien und ein paar digitalisierte Videos + Office Dokumente. Gibt es dafür eine gute Anleitung? Wie läuft das mit inkrementellen Backups? Ich möchte ja später nur die Änderungen übertragen.

 

[1chris]

1chris: ja, sind hauptsächlich .raw und .jpg Dateien und ein paar digitalisierte Videos + Office Dokumente. Gibt es dafür eine gute Anleitung? Wie läuft das mit inkrementellen Backups? Ich möchte ja später nur die Änderungen übertragen.

Ich hab dir eben mal eine geschrieben. Schau mal hier:

zfs-server.de • Thema anzeigen - Howto: zfs send

Hab auch noch ein Skript dazu geschrieben, dass ich allerdings erst noch mal gegenchecken muss. LAde es dann auch dort hoch.

 

[Opticum]

1chris: besten Dank! Ich werde den Remote Server noch mit etwas RAM aufstocken damit ich ZFS / Napp-IT drauf laufen lassen kann und das ganze dann noch einmal testen.

 

[ludwinator]

zfs send/receive überträgt die Daten Block für Block (aus Snapshots). Das heißt du solltest an er Quelle (und am Ziel) lz4-compression aktivieren, damit die zu übertragende Datenmenge geringer wird.
Da du sicher die Kopieraktion über ssh laufen lässt, könnte man hier auch noch etwas mit Compression auf der Übertragungsstrecke rausholen (ssh-Option -C).

Sind die 500G Daten bereits komprimiert?

Das ist (leider) nicht korrekt. Komprimierte Blöcke werden grundsätzlich beim lesen entkomprimiert, auch bei zfs send.
Um die Datenmenge dennoch zu reduzieren, empfiehlt sich ein

zfs send ... |gzip -c|ssh remotehost "gunzip -d -c |zfs recv ..."

Hat natürlich nur Sinn, wenn auch Aussicht auf Kompression besteht, was bei jpg, raw und Video ja grds. nicht der Fall ist.
Mit 20MBit Upstream kann man aber schon ne ganze Menge sichern, vor allem wenn die Deltas zwischen den einzelnen Snapshots nicht allzu groß werden.
Die Urladung von 500GB sollte man aber per USB Platte o.ä. machen, das wird sonst wohl > 3 Tage dauern.


- - - Updated - - -

Ich hab dir eben mal eine geschrieben. Schau mal hier:

zfs-server.de • Thema anzeigen - Howto: zfs send

Hab auch noch ein Skript dazu geschrieben, dass ich allerdings erst noch mal gegenchecken muss. LAde es dann auch dort hoch.

Warum das Rad ständig neu erfinden, das Netz ist voll von (korrekten) Scripten, fertigen Tools, Anleitungen und Tipps. Und als Referenz gelten immer noch die Oracle Docs.
Beispiel: http://www.znapzend.org/ oder https://github.com/allanjude/zxfer
Deine Anleitung ist leider weder korrekt noch vollständig, sorry...

cu

 

[TCM]

Irgendwie muss man doch sein belangloses Forum pushen. :>

 

[ludwinator]

Der genannte Einsatzzweck mit einem eigenen kleinen Pool ist eine der wenigen Anwendungsfälle in denen ZFS Realtime dedup derzeit sinnvoll ist da damit eventuell hohe dedup Werte möglich sind.

Ich würde aber niemals ohne Redundanz arbeiten.
Dazu fallen auch SSDs zu oft aus und dann ist es zumindest ärgerlich und bedeutet Arbeit. Also eher Raid-Z1 als Raid-0

Ansonsten:
Dedup wird zwar als Eigenschaft eines Dateisystems aktiviert, arbeitet aber immer Poolweit. Das ist auch das Hauptproblem für normale Nutzung. Einmal aktiviert wird man das nur durch einen Pool-Destroy wieder los.

Ungünstig ist der hohe Ramverbrauch auch weil dieser RAM dann als Cache fehlt und da bringt er Performance. Da auch SSD inzwischen recht billig sind, ist es eine Abwägung.

Hier muss ich dir widersprechen, die DDT reicht zwar über den ganzen Pool, deduplizierte Blöcke werden aber tatsächlich nur in das Filesystem geschrieben, in dem dedup=on ist.
Es reicht also, nur dieses Filesystem wieder zu löschen, um die DDT wieder loszuwerden, der Pool selbst muss nicht zerstört werden.
Das lässt sich ganz leicht mit zpool status -D poolname verifizieren.
Damit erübrigt sich auch die ganze Partitioniererei, nur um dedup mal zu testen.


cu

 

[gea]

Prinzipiell stimme ich dem zu.

Da Dedup aber das Potential hat, die Pool Performance extrem zu verschlechtern würde ich das dennoch lieber nur auf einen kleinen dedizierten Pool für besondere Anforderungen beschränken. Es gibt zwar Verbesserungen z.B. bei Oracle dennoch würde ich Dedup derzeit nur im Ausnahmefall und bei nur kleinen Pools benutzen einfach weil Dedup=on massive Probleme bedeuten kann. Dedup=off heisst einfach dass man sich um RAM keine Sorgen machen muss.

 

[CommanderBond]

der Solaris SMB Server speichert die ACLs ja im Dateisystem so wie ich das verstanden habe. Aber wie läuft das normal unter Samba, wo werden die da gespeichert. Sind die wenn ich die Festplatten mit den Daten in ein anderes System stecke einfach weg? Oder gibts irgendeine Datei die Samba da anlegt wo alles drin gespeichert ist?