[Sammelthread] ZFS Stammtisch

Mal ne Frage. Aktuell habe ich 4x 3tb und 2x 4 TB als striped mirror in einem pool zusammengefasst.
Ist es möglich, bei Erweiterung von weiteren 2x 4tb auf zwei raidz2 vdevs umzusteigen? Das es zu einem Datenverlust führen wird, ist mir bewusst.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Snapshots sind eine Eigenschaft eines ZFSDateisystems, genau wie SMB Shares unter dem Solaris SMB Server. Snaps als Windows vorherige Version gehen damit ohne weitere Einstellungen und normalerweise absolut problemfrei, wenn man mit der rechten Maustaste z.B. auf einen Ordner klickt und dann Eigenschaft > Vorgängerversion anwählt.

Probleme gibt es regelmäßig dann wenn unter OmniOS Dateisysteme geschachtelt sind und man in einem SMB Share in tieferliegende Dateisysteme wechselt oder wenn diese eindeutige Zuordnung Dateisystem=Share wie z.B. mit SAMBA nicht mehr gegeben ist. Oracle Solaris verhindert deshalb auch das Wechseln in tieferliegende Dateisystem.

Nach Möglichkeit daher freigegebende ZFS Dateisysteme nicht schachteln. Das kann auch zu ganz anderen Problemen führen, wenn man z.B. in einem Dateisystem Groß/Kleinschreibung als ZFS Eigenschaft beachtet und in einem anderen nicht oder aclmode/inherit unterschiedlich gesetzt hat.


Update
Die aktuelle Illumos/OpenIndiana Version (bzw OmniOS ab 151031) hat das Problem übrigens nicht mehr
Bug #11034: Restoring previous versions from snapshots doesnt work with nested datasets - illumos gate - illumos
 
Mal ne Frage. Aktuell habe ich 4x 3tb und 2x 4 TB als striped mirror in einem pool zusammengefasst.
Ist es möglich, bei Erweiterung von weiteren 2x 4tb auf zwei raidz2 vdevs umzusteigen? Das es zu einem Datenverlust führen wird, ist mir bewusst.


Zu welchem Zweck bzw. was soll das bringen?
Alles wegsichern und komplett neu anlegen, ein Haufen Arbeit aber wofür?
Kein Platz oder Performancegewinn (im Gegenteil) und (rein) theoretisch verbesserte Ausfallsicherheit, das wärs mir nicht wert.

cu
 
Und wieder einmal hat ZFS mir die Datenintegrität bewahrt. :)
Eine Backplane für 2,5"-Laufwerke (SSDs bei mir) bei mir ist offenbar beschädigt und spuckte CRC/CKSUM-Errors.
 
Hat jemand kluge Ideen, was diese Meldung tatsächlich bedeutet?
2019-11-01 18_51_22-Window.png

Diese habe ich nur bei der Config:
- OmniOS mit Nappit
- Univention UCS als Samba 4 DomainController
- Zugriff von einem Domainmember via IP (statt Hostname)
- oder Zugriff von einem Nicht-Domainmember via IP oder Hostname

Ich habe die Meldung nicht bei:
- OmniOS mit Nappit und Windows Domaincontroller
- oder Windows Fileserver und Univention UCS Samba 4 Domaincontroller

Jeglicher Eintrag dazu verweist auf Windows Maschinen, die in VMware geclont und nicht richtig angepasst wurden (selbe SID - SID ist bei meinen Geräten aber unterschiedlich). Ich habe:
- UCS Primary DC über das vorgesehene Univention Image
- UCS Backup DC über das vorgesehene Univention Image
- Windows 10 VM von Hand installiert
- OmniOS Template von gea (10.1.10.18) -> Join via GUI
- OmniOS selbst installiert und napp-it nachinstalliert (10.1.10.19) -> Join via GUI und von Hand über kclient und smbadm

Viele Grüße
Martin
 
Zuletzt bearbeitet:
Kann jemand bestätigen dass er ebenfalls Problem hat mit Apple und dem SMB Serven von OmniOS 151030? Apple hat ja einen SMB Client in deren DateienApp integriert. Der Zugriff und das Navigieren durch die Ordner funktioniert auch, allerdings friert die App ein sobald man versucht eine Datei zu öffnen. Sowohl unter iPadOS als auch unter iOS.

Hat es jemand mit der Bloody und SMB3 schonmal getestet und kann sagen ob der neue SMB Server da abhilfe schaffen wird? Oder gibts vielleicht schon nen Ticket? Weil ist ja etwas was denke ich viele Leute nutzen wollen würden.
 
Zuletzt bearbeitet:
Beide OmniOS sind bereits bloody. Die von Günther per pkg auf 33 aktualisiert, die andere ist die bloody ISO von Mitte Oktober, also wahrscheinlich 31.
 
Ich kann nicht sagen ob Gordon Ross (Nexenta) eine Lösung hat oder darauf antwortet. Er ist jedoch derzeit der beste Kenner/Entwickler von Illumos SMB. Eine Frage in illumos-discuss oder illumos-dev wäre es wert.
 
Zu welchem Zweck bzw. was soll das bringen?
Alles wegsichern und komplett neu anlegen, ein Haufen Arbeit aber wofür?
Kein Platz oder Performancegewinn (im Gegenteil) und (rein) theoretisch verbesserte Ausfallsicherheit, das wärs mir nicht wert.

cu
Wenn beim resilvern die zweite Platte aus dem mirror stirbt, dann ist das halt blöd.
 
Resilvern aus einem Mirror ist imho deutlichst weniger anspruchsvoll für die Platte als in einem RAID(z)X. Mirror läuft sequentiell, die Prüfsumme dagegen Kreuz und quer.
 
Ein Resilver liest alle Metadaten des Pools. Werden Daten gefunden, die auf einer defekten Platte liegen (Pool Layout egal) so werden diese aus Redundanz auf die neue Platte kopiert. Das hat zur Folge, dass die Resilverzeit von der Menge der Daten abhängt die wiederhergestellt werden müssen und da es sich um das Lesen/Schreiben kleiner Datenblöcke handelt, von den iops der beteiligten vdev.

Bei gleicher Datenmenge ist ein Multi-Mirror deshalb schneller, da die iops des Pools bei Mirrors ein mehrfaches des Wertes eines Raid-Z liegt.

ZFS dupliziert bei einem Mirror also nicht einfach die Platte wie viele andere Mirrors, sondern stellt lediglich betroffene Daten wieder her. Diese iops Betrachtung verliert aber mit sequentiellem Resilvering/ sorted Resilvering immer mehr an Bedeutung. Sequentielles Resilver liest zuerst alle Metadaten und sortiert die dann nach Zugriffsreihenfolge um dann so sequenziell wie möglich Daten wiederherzustellen. Die Resilverzeiten können sich da gerne mal halbieren.

Sequentielles Resilver ist seit langem in Solaris und seit diesem Sommer in Open-ZFS (Illumos, ZoL). Ein Scrub ist übrigens praktisch ein Resilver bei dem nur die Prüfsummen überprüft werden. Ein Wiederherstellen findet bei Prüfsummenfehlern statt.

Spezielle vdev erlauben seit neuem eh, die Vorteile von Platten und Raid-Z (billig, Kapazität) mit SSD/NVMe Mirrors (überragend schnell) für ausgewählte Daten zu kombinieren. Multi-Platten-Mirror/Raid-10 Mirrors sehe ich als Auslaufmodell (bis auf den Sonderfall 2/3way Mirror für ultimative Datensicherheit und Leseleistung mit lediglich zwei/drei Platten). Wenn mal hohe Kapazität bei generell hoher Performance gefragt ist, nimmt man halt reine SSD/NVMe Pools deren iops auch bei Raid-Z ausreichend hoch ist. Immerhin hat eine mechanische Platte nur ca 100 iops wöhrend eine Optane NVMe bis 500000 hat.

Sequential Resilvering | Bizarre ! Vous avez dit Bizarre ?
 
Zuletzt bearbeitet:
Hätte man eigentlich einen sinnvollen Vorteil, wenn man einen HDD/NVMe Mirror Kombi als special vdev betreibt und als Datengrab (HDD) bzw als VM Platz (SSD) nutzt +- Optane als Slog ?

Oder eher nur unnötige Komplexität ggü getrennte Mirror.

Würde eigentlich ein zfs send von einem special vdev pool auf einem "normalen" pool als Backup funktionieren ?
 
Zuletzt bearbeitet:
Ein special vdev sorgt zunächst dafür, dass Metadaten darauf landen. Metadaten machen ca 1% der Daten aus. Bei aktuellen Daten liegen die aber eh im Arc Cache. Ein special vdev sorgt nun dafür dass alle Metadaten schnell gelesen werden können, auch bei erstem Zugriff. Bei sehr vielen volatilen Daten sicher ein großer Vorteil, ebenso für Scrub/Resilver Zeiten. Mit wenig Daten/ wenig Usern (@home) eher zu vernachlässigen. Intel hat das für Datacenter Use konzipiert.

Anders sieht es mit small io aus. Damit kann man einzelne Dateisysteme z.B. VMs auf das special vdev zwingen. VMs haben damit volle NVMe Performance während für Filer/Backup die Platten genutzt werden. Das schöne dabei ist dass man dass flexibel einstellen kann. Das special vdev (Mirror bis Multi Raid-10) sollte dann halt ausreichend groß für Metadaten + schnelle Dateisyyteme sein.

Special vdev hilft auch bei sync write etwas. Ein Slog z.B. Optane ist dennoch mehr als sinnvoll.

Einem zfs send ist es egal, ob die Daten auf einem normalen oder special vdev liegen.

siehe meine Versuche
https://www.napp-it.org/doc/downloads/special-vdev.pdf
 
Kann ich denn einem bestehenden mirror einen weiteren mirror als striped hinzufügen? Mein proxmox Server läuft auf einem mirror aus zwei ssds und da ist das os und vms drauf. Wenn dann eine ssd aus dem alten mirror ausfällt, unterstützt dann der neue pool beim resilvern?
 
Ja, das kannst Du und ist die übliche Vorgehensweise.

Nein, das sind getrennte Mirror-pärchen. Wenn eine Platte aus dem ersten Mirror ersetzt wird, werden die Daten von der zweiten Platte übernommen. Die Platten 3/4 sind ein eigenes Paar.

- - - Updated - - -

Auf dem Bild erkennst Du die Logik und den Aufbau:
http://www.zfsbuild.com/pics/create_striped_mirror.jpg
 
Du kannst einem Pool, der aus einem Mirror-vdev besteht, natürlich ein weites Mirror-Vdev hinzufügen. Die Kapazität des neuen Mirror-Pärchen steht dann dem Pool umgehend zusätzlich zur Verfügung.
Null Problemo. ZFS verteilt dann jegliche neue Schreibanforderung auf beide vdevs. Beachte aber, dass Altdaten nicht neu verteilt werden, solange sie nicht neu geschrieben werden.


Damit gilt aber: Redundanz ist nur jeweils innerhalb eines vdevs gegeben. Sprich in Pärchen 0 und Pärchen 1 sind eben wie ein Raid0 gestriped und haben keinerlei gegenseitige Redundanzinformationen und können sich demensprechend nicht helfen. Nur innerhalb eines jeweiligen vdevs.
Fällt ein vdev aus => oh ohhhhhhhh für den Pool. Es darf bei so einem Pool also max. zeitgleich nur 1 Device pro Pärchen ausfallen.
Desto mehr Mirror-Pärchen, desto größer wird also das Risiko, so dass man bei notwendiger hoher Verfügbarkeit dann zu 2fach oder 3fach-Mirror gehen sollte. Ist aber dann ein fürs Homelab schon eher selten bis extrem seltener Bedarf.

PS: jetzt war martingo ein paar Sekunden schneller.

Vorteile: Die IOPS addieren sich pro Pärchen, während ein Raidz nur die IOPS bestenfalls eines einzigen Device haben. Beim Lesen kann ZFS auf alle 4 Platten gleichzeitig zugreifen. Für Datenbanken und andere Volumes mit viel Random I/O ideal. Raidz/2/3 ist dagegen effizienter wenns um sequentielle Schreibraten mit wenig Random geht.

Ich hab daher zwei Pools: einen Raidz2-Pool mit 6x14TB für Archiv, Media, etc und einen SSD-Pool mit 3*Mirrorpärchen (6*960GB Datacenter SSD) für VMs, Datenbanken, DMS und stetig genutzte Software. Mehrfach-Mirrorpärchen aus SAS/Sata-SSD aus Performancegründen werden aber relativ bald durch einfache NVMe-Mirror ersetzt, sofern genug PCIe-Lanes da sind. Ausnahme Hochlast-I/O z.B. für SQL- oder SAP-Maschinen.
 
Zuletzt bearbeitet:
System: Omnios r151026 mit Nappit 18.12p in einer Windows-Domäne

Ich habe gerade ein Problem mit der Berechtigungsvergabe. Ich habe ein ID-Mapping Admin@Domain = root angelegt.
Bevor ich dieses Mapping korrekt hinbekommen habe (Muss FQDN der Domain sein), habe ich immer Access denied bekommen.
Jetzt zeigt mir Windows immmernoch ein Kreuz bei dem Owner des Ordners (Administrator) an. Scheinbar passt Win der User nicht?

Jetzt bekomme ich den Hinweis, wenn ich einen AD-User zu einem Ordner-ACL hinzufügen will, dass kein Mapping zwischen dem Usernamen und der SID gemacht wurde.
Ich habe bereits ACL reset versucht, das hat keine Besserung gebracht.
Muss ich ein extra Mapping für jeden AD-User, den ich berechtigen möchte, erstellen, oder habe ich da irgendwas übersehen? Passt bei dem Admin/Root Mapping noch etwas nicht?

E: ich sehe gerade, wenn ich alle User-Mappings, die ich hinzufügen wollte, rausnehme, bekomme, ich dieselbe Fehlermeldung. Es scheint also tatsächlich mit dem Admin-Mapping zu tun zu haben.
Was mache ich da falsch? Mapping wurde folgendermaßen angelegt:
idmap add winuser:Administrator@Domain.FQDN unixuser:root

Bei anderen idmap Versuchen (nur Administrator, Administrator@DOMAIN, DOMAIN\Administrator) habe ich immmer einen Fehler beim Aufzählen der Elemente bekommen, wenn ich Berechtigungen setzen wollte.
 
Zuletzt bearbeitet:
Also ist es doch sinnvoller auf raidz2 zu setzen für Mediendateien?

Macht es Sinn raidz2 Pools mit mehreren vdevs anzulegen? Ich würde 2x 4x4tb und 1x 4x3tb zu einem Pool zusammenfassen. Es geht hier um reinen Netzwerkspeicher. Es sollen zwar auch Programme oder vms auf dem Server installiert werden, das wäre dann aber in ssd striped mirror.
 
Nein, es ist nicht sinnvoller. Hast Du unsere Posts und den verlinkten Artikel gelesen?

Sinnvoll ist externes Backup.
 
Denn Link kenne ich, berücksichtigt jedoch nicht, dass wenn zwei HDDs des selben mirrors hopps gehen, dass dann alles weg ist. hierbei geht es um Datenverfügbarkeit und nicht um Backups.
 
OmniOS 151032 stable ist da
Das ist das größte und umfassendste Update für Open-ZFS und OmniOS das jemals veröffentlicht wurde.
download: Downloads

Release notes
omnios-build/ReleaseNotes.md at r151032 · omniosorg/omnios-build · GitHub

Update
http://www.napp-it.org/doc/downloads/setup_napp-it_os.pdf

New Open-ZFS features:
- native ZFS encryption
- raw zfs send of locked and encrypted filesystems
- sequential/sorted resilver (can massively reduce resilver/scrub time
- manual and auto trim for the SSDs/NVMes in a pool
- Allocation classes for metadata, dedup and small io (mixed pool from disk/SSD/NVMe)
see https://www.napp-it.org/doc/downloads/special-vdev.pdf
a warning at this point: a zpool remove of a special vdev with a different ashift than the pool crashes Illumos/ZoL
- force ashift on zpool create/add

OmniOS related
-updated NVMe driver (with basic support for NVMe/U.2 hotplug)
-updates for newer hardware
-installer supports UEFI boot

- SMB 3.02 (kernelbased SMB) with many new features
see Pull Requests · illumos/illumos-gate · GitHub
- improvement for LX/ Linux zones, newer Linux distributions
- improvements for Bhyve
- improvements to the Enlightened Hyper-V drivers for running under Hyper-V or Microsoft Azure.

Napp-it 19.dev/19.h2.x supports the new features
 
Denn Link kenne ich, berücksichtigt jedoch nicht, dass wenn zwei HDDs des selben mirrors hopps gehen, dass dann alles weg ist. hierbei geht es um Datenverfügbarkeit und nicht um Backups.

Hi,

Du übersiehst den relevanten Unterschied. Das Resilvering bei einem RaidZ beansprucht die Festplatten so extrem viel stärker, dass die Wahrscheinlichkeit höher sein dürfte, dass Dir beim Resilvern noch zwei weitere Platten ausfallen, als es beim Mirror der Fall ist.
Wenn Du vernünftige Platten nutzt, dürfte es in Summe wahrscheinlich egal sein. Und da Du wie Du ja schon schriebst, SSDs verwendest, sind es keine riesigen Datenmengen. Und wie gea schon schrieb, spielen bei SSDs die IOPs nicht so sehr die Rolle wie bei HDDs.
Ich würde trotzdem dem striped mirror den Vorzug geben, bzw. tue es.
Du backupst ja ohnehin regelmäßig, wenn Du hierfür Snapshots per zfs send anlegst, ist das System (egal welche Variante) einigermaßen zügig wieder hergestellt

Nachdem Du Dich ja ohnehin schon für ein RaidZ2 entschieden hast, noch kurz auf Deine Frage bzgl. Stripe über Z2: ja, das geht ebenfalls (und ist ebenfalls in dem Link beschrieben).

- - - Updated - - -

Nachtrag: ich habe Deinen vorletzten Post nochmal gelesen und festgestellt, dass die SSDs sich nur auf den VM-Pool beziehen.

Sind Deine Datenplatten denn auch komplett sicher gebackupt? Also mind. zwei besser drei externe Disks die rotieren und die Netto-Gesamtkapazität von 20-22TB aufnehmen können?
Mal Nägel mit Köpfen: hast Du ein sicheres Backup für den Fall, dass der Pool die Grätsche macht? Ich will Dir nichts unterstellen, aber die Plattenkomposition und die mögliche Gesamtdatenmenge macht den Eindruck, dass Du schon eher darauf angewiesen bist, dass das RAID die Daten wiederherstellen kann und Du nicht alles sicher extern hast.

Das ist ja auch nicht schlimm, aber wenn Du mit offenen Karten spielst, kann man sicher auch etwas besser beraten.
Falls kein sicheres Backup: ist es zum Beispiel zwingend, dass alle zwölf HDDs im gleichen Pool sind? Handelt es sich bei allen Platten um gleiche Art (unabhängig von der Kapazität), also z.B. alles WD Red(+)?
 
OmniOS 151032 stable ist da

...

New Open-ZFS features:
- native ZFS encryption

...

Napp-it 19.dev/19.h2.x supports the new features

Danke für das Update, auch Deiner Tools. Das empfinde ich als Meilenstein.

Da werde ich am Wochenende mal Nägel mit Köpfen machen und updaten. Ich bin gespannt, wie das mit ZFS encryption läuft. Ich werde einfach eine meiner Backup-Platten plätten und das Ganze mal ausprobieren.
 
Läuft wunderbar mit Encryption. Günther hatte es für Oracle Solaris ja eh schon eingebaut, die Sache mit den Nested Encryptions ist scheinbar bei OmniOS gleich. D.h. Key nur für das oberste verschlüsselte Volume, der Rest erbt.
Nutze es aktuell schon in der Bloody und muss nur schauen, ob ich von 33 auf 32 downgraden kann.
 
Hi,

Du übersiehst den relevanten Unterschied. Das Resilvering bei einem RaidZ beansprucht die Festplatten so extrem viel stärker, dass die Wahrscheinlichkeit höher sein dürfte, dass Dir beim Resilvern noch zwei weitere Platten ausfallen, als es beim Mirror der Fall ist.
Wenn Du vernünftige Platten nutzt, dürfte es in Summe wahrscheinlich egal sein. Und da Du wie Du ja schon schriebst, SSDs verwendest, sind es keine riesigen Datenmengen. Und wie gea schon schrieb, spielen bei SSDs die IOPs nicht so sehr die Rolle wie bei HDDs.
Ich würde trotzdem dem striped mirror den Vorzug geben, bzw. tue es.
Du backupst ja ohnehin regelmäßig, wenn Du hierfür Snapshots per zfs send anlegst, ist das System (egal welche Variante) einigermaßen zügig wieder hergestellt

Nachdem Du Dich ja ohnehin schon für ein RaidZ2 entschieden hast, noch kurz auf Deine Frage bzgl. Stripe über Z2: ja, das geht ebenfalls (und ist ebenfalls in dem Link beschrieben).

- - - Updated - - -

Nachtrag: ich habe Deinen vorletzten Post nochmal gelesen und festgestellt, dass die SSDs sich nur auf den VM-Pool beziehen.

Sind Deine Datenplatten denn auch komplett sicher gebackupt? Also mind. zwei besser drei externe Disks die rotieren und die Netto-Gesamtkapazität von 20-22TB aufnehmen können?
Mal Nägel mit Köpfen: hast Du ein sicheres Backup für den Fall, dass der Pool die Grätsche macht? Ich will Dir nichts unterstellen, aber die Plattenkomposition und die mögliche Gesamtdatenmenge macht den Eindruck, dass Du schon eher darauf angewiesen bist, dass das RAID die Daten wiederherstellen kann und Du nicht alles sicher extern hast.

Das ist ja auch nicht schlimm, aber wenn Du mit offenen Karten spielst, kann man sicher auch etwas besser beraten.
Falls kein sicheres Backup: ist es zum Beispiel zwingend, dass alle zwölf HDDs im gleichen Pool sind? Handelt es sich bei allen Platten um gleiche Art (unabhängig von der Kapazität), also z.B. alles WD Red(+)?

Ich habe mehrere Server:

Proxmox: 1x zfs mirror aus 2 ssds für Host und vms; zfs raidz1 aus 3x 1tb 2.5" hdd für Daten

Fileserver: 4x3tb (Toshiba consumer) und 2x4 TB wd Red im striped mirror. Ich würde noch gerne 2x4tb zum striped mirror hinzufügen. Hier sind aktuell Mediendateien drauf.
Ich möchte noch 4 weitere 4tb reds hinzufügen. Da hin ich am überlegen, ob ich da einen weiteren pool hinzufügen soll als striped mirror oder raidz1 oder 2 oder die auch noch zum ersten pool hinzufügen soll.

Ich würde gerne die Mediendateien auf einen separaten pool packen. Da existieren auch keine Backups von. Wäre zwar ärgerlich, wenn es weg wäre, aber kein Weltuntergang. Die wichtigsten Dateien (Bilder, Dokumente...) sollen auf dem aktuellen pool bleiben, sind aber auch noch mehrfach gesichert (auf 2 andere Server und 1x 50 km entfernt)
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh