[Sammelthread] ZFS Stammtisch

[fard dwalling]

Wie riskant ist es denn eigentlich auch als vmstorage das Sync zu deaktivieren?

 

[gea]

Wie riskant ist es denn eigentlich auch als vmstorage das Sync zu deaktivieren?

Bei einem Schreibvorgang werden Daten geschrieben und Matadaten aktualisiert (wo liegen die Daten). So eine Aktion (nennt man auch atomarer Schreibvorgang) darf nie teilweise ausgeführt werden, sonst ist das Dateisystem korrupt. ZFS vermeidet das durch Copy on Write. Dabei wird solch eine atomare Schreibaktion komplett ausgeführt oder komplett verworfen (trotz Schreibens über den rambasierten Schreibcache)

Bei einer VM sieht das anders aus. Jeder Schreibvorgang geht in den rambasierten Schreibcache und wird der VM sofort als erfolgreich bestätigt und dann mit Verzögerung als eine große Schreibaktion auf Platte geschrieben. Über die atomaren Schreibvorgänge der VM hat ZFS keine Kontrolle.

Jetzt kommt es darauf an, wann eine VM abstürzt. Werden die Daten noch im Cache gesammelt, so sind die zwar verloren aber das Dateisystem bleibt valide. Ist der Cacheinhalt komplett auf Platte so ist das auch ok. Das Risko liegt darin dass Daten geschrieben sind, die zugehörige Matadatenänderung es aber nicht mehr auf Platte schafft (korruptes Dateisystem). Genau dagegen schützt sync write + Protokollierung der bestätigten Schreibaktionen (ZIL/Slog) die es noch nicht auf Platte geschafft haben um das beim Reboot nachzuholen.


too long to read...
VM Storage mit rambasiertem Schreibcache ohne Absicherung (sync): ziemlich riskant.

Vor allem weil man oft erst relativ spät mitbekommt wenn ein VM Dateisystem Macken hat. Selbst wenn man dann ein Backup hat, weiß man ja auch nicht sofort, ob das noch ok war....

 

[fard dwalling]

Mh, jetzt bin ich ja doch skeptisch.
Also Erklärung erfolgreich.

Wie macht VMware das denn direkt auf lokalen Datastore?

 

[gea]

Wie macht VMware das denn direkt auf lokalen Datastore?

Wenn ESXi direkten Zugriff auf die Platte hat und kein Ramcache aktiviert ist, kann es das weitgehend selbst garantieren. Nutzt man einen Raidcontroller mit Cache für ein lokal Datastore, so ist da aber auch Batterie/Flash als Sicherung nötig.

Ohne Schreib-Ramcache hat man halt das "Problem" dass dann auch kleinste Datenpakete (sagen wir mal 4k-64k) sofort auf Platte geschrieben werden (saulangsam) und nicht nur große sequentielle über den Cache. ZFS sammelt die kleinen Schreibaktionen im Cache und schreibt dann primär schnell in recsize (128k-1M)

 

[alex.]

Bin leider ratlos und könnte weiteren Input für die nächsten Schritte gut gebrauchen. Ich hab...

- die 4 neuen Festplatten um eine "Reihe" nach rechts gesetzt, hängen also nun an einem anderen Kabel am Controller >_> Problem besteht weiterhin, Kiste startet während des Scrubs neu - Scrub-Stand:

  pool: Spinning
 state: ONLINE
  scan: scrub in progress since Mon Nov  2 13:12:40 2020
        3.29T scanned at 2.17G/s, 2.07M issued at 3.88K/s, 12.8T total
        0 repaired, 0.00% done, no estimated completion time

- ich hab versucht die Datasets auf eine andere Platte zu sichern, musst auf Freenas U3.1 downgraden weil ich sonst die Replication nicht einrichten konnte - dürfte ein bekannter Bug sein. Bei Replizieren eines Datasets kams abermals zur Kernel Panic und reboot.

- Platten aus dem Server ausgebaut und in einen anderen Server (Supermicro X11) direkt an Intel SATA >_> Problem besteht weiterhin, Kernel Panic und Neustart während des Scrubs - Stand nachstehend:

  pool: Spinning
 state: ONLINE
  scan: scrub in progress since Mon Nov  2 17:45:09 2020
        3.29T scanned at 648M/s, 2.32T issued at 457M/s, 12.8T total
        0 repaired, 18.10% done, 0 days 06:41:47 to go

- Testweise das Log Device entfernt, selbiges Problem.

hm. ich bin ratlos, hat noch jemand eine Idee?

 

[Digi-Quick]

Moin, danke für die ausführliche Antwort, dann halte ich mal Ausschau nach ner DC3700.

Was für eine Größe sollte ich wählen? Einen reinen SSD-VM-Pool kann ich leider nicht machen da noch ein paar große VMs mit drauf sollen.
mg

Was ist denn eine Große VM?
die Betriebssysteme inkl. Anwendungne sind doch i.d.R. überschaubar, die Nutzerdaten gehören da getrennt und haben eigentlich nichts in der VM verloren.
Einbindung der Nutzerdaten via SMB, NFS - ggfs. als gemapptes Laufwerk, wenn UNC Pfade nicht gehen oder via iSCSI als Separates Volume.

 

[quotengrote]

iSCSI bin ich von weg, wenn dann FC :-D

Im Production-Pool >40 VM á 150-200GB

 

[CommanderBond]

ZFS can use hardware acceleration for Raid-Z

Auf der Seite heißt es "bei unterstützten CPUs". Was hat es damit genau auf sich? Welches Befehlsset ist das genau? Mir persönlich ist da nichts bekannt oder die Sache ist unbemerkt an mir vorrübergegangen?

 

[Stangensellerie]

Soweit ich das mitbekommen habe, gehts dabei um Intel QAT (Quick Assist Technology for improved cryptographic and compression performance) mittels spezieller Karte oder es werden dafür nur die entsprechenden CPU-Funktionen AES bzw AES-NI herangezogen.

 

[gea]

Es geht darum dass der Kernel FPU Funktionen einer aktuellen CPU (?) nutzen kann.

Bug #12793: kernel FPU support - illumos gate - illumos

Redmine

www.illumos.org

siehe auch Kommentare in:

12793 kernel FPU support · illumos/illumos-gate@2fc9ab6

Portions contributed by: Robert Mustacchi <rm@fingolfin.org> Reviewed by: C Fraire <cfraire@me.com> Reviewed by: Ryan Zezeski <ryan@zinascii.com> Reviewed by: Jason King <jason...

github.com

* Kernel FPU Usage
		* ----------------
		*
		* Traditionally the kernel never used the FPU since it had no need for
		* floating point operations. However, modern FPU hardware supports a variety
		* of SIMD extensions which can speed up code such as parity calculations or
		* encryption.

Wieviel das bringt, müsste man mal testen (151034 vs 151036)

 

[Luckysh0t]

Da da ja auch "encryption" genannt wird, könnte es ja nun auch da schnell genug laufen..im vgl zu den älteren Versionen.

 

[CommanderBond]

Ich denke AES Hardware Beschleunigung gibt es weiterhin noch net. Das hätte man sicherlich direkt erwähnt. Zumal ja auch nur von RaidZx die rede war. Encryption würde sich aber auf alles beziehen.

 

[Stangensellerie]

https://openzfs.org/wiki/ZFS_Hardware_Acceleration_with_QAT list sich interessant. Die Werte im ersten Pull sind schon ganz ordentlich.

 

[fard dwalling]

Moin Moin, wenn ich solche Meldungen im napp-it habe, kann ich wahrscheinlich von einem HDD Problem ausgehen oder?

Nov 7 21:25:04 appl-034 scsi: [ID 243001 kern.warning] WARNING: /pci@0,0/pci15ad,7a0@17/pci103c,158b@0 (mpt_sas0):
Nov 7 21:25:04 appl-034 mptsas_handle_event_sync: event 0xf, IOCStatus=0x8000, IOCLogInfo=0x31120436
Nov 7 21:25:04 appl-034 scsi: [ID 243001 kern.warning] WARNING: /pci@0,0/pci15ad,7a0@17/pci103c,158b@0 (mpt_sas0):
Nov 7 21:25:04 appl-034 mptsas_handle_event: IOCStatus=0x8000, IOCLogInfo=0x31120436
Nov 7 21:25:08 appl-034 scsi: [ID 107833 kern.notice] /pci@0,0/pci15ad,7a0@17/pci103c,158b@0 (mpt_sas0):
Nov 7 21:25:08 appl-034 Timeout of 10 seconds expired with 1 commands on target 12 lun 0.
Nov 7 21:25:08 appl-034 scsi: [ID 107833 kern.warning] WARNING: /pci@0,0/pci15ad,7a0@17/pci103c,158b@0 (mpt_sas0):
Nov 7 21:25:08 appl-034 Disconnected command timeout for target 12 w50014ee2b7caed7d, enclosure 1
Nov 7 21:25:08 appl-034 scsi: [ID 365881 kern.info] /pci@0,0/pci15ad,7a0@17/pci103c,158b@0 (mpt_sas0):
Nov 7 21:25:08 appl-034 Log info 0x31120436 received for target 12 w50014ee2b7caed7d.
Nov 7 21:25:08 appl-034 scsi_status=0x0, ioc_status=0x804b, scsi_state=0xc

Warum wird dann unter Pools und unter Disks alles als ok angezeigt?

 

[gea]

Die Meldungen besagen dass die Platte (target 12 w50014ee2b7caed7d) einen Timeoutfehler hatte. Im Gegensatz zu Hardwareraid reagiert ZFS da sehr gutmütig wenn die Platte dann später oder bei einem zweiten Versuch Daten liefert. Der Haupteffekt ist dann eine geringere Performance.

Man sollte das aber im Blick behalten. Das kann ja auch das erste Anzeichen eines Ausfalls sein.

 

[fard dwalling]

Die Platten hatte ich eh nur übergangsweise vorgsehen. Nach etwas längerem Suchen, konnte ich jetzt die eine ausmachen, die wohl diese TimeOuts hatte. Resilver läuft bereits.
Der Wechsel der Platte hat recht gut geklappt. Ich habe sie erst Offline genommen, dann gegen eine 6TB ausgetauscht und dann über Disc Replace den Tausch Prozess angestoßen.
Seither läuft das Resilver.

 

[you]

Hat irgendwer erfolgreich Omnios auf KVM (unter Proxmox) mit durchgereichtem HBA virtualisiert? Lt. OmniosCE soll das mit KVM ja gehen. Im ersten Schritt würde ich die Konfiguration gerne mal abgleichen. Danke.

 

[asche77]

Warum dann nicht gleich omnios bare metal + LX/bhyve zones?

 

[you]

Ich muss macos virtualisieren. Und das klappt vernünftig nur unter ESXI und kvm. Aktuell nutze ich daheim ESXI, auf der Arbeit allerdings proxmox. Und das will ich jetzt gleichschalten, bevorzugt ohne Abschied von OmniosCE/nappit zu nehmen. Die Alternative, TrueNAS, läuft auf Proxmox mit durchgereichtem 2008 LSI HBA im IT mode. Meine NAS Appliance soll nichts anderes machen als NASsen.

 

[gea]

Wäre mir deutlich zuviel "Vollwertkost" und Abhängigkeiten.

ESXi ist ja wie ipmi eher ein Bios/Firmware Addon.
Alle VMs inkl. Storage laufen darauf quasi gleichwertig und völlig ohne Abhängigkeiten.

Ein vollwertriges Debian als Basis um dann darauf ein vollwertiges Solarish für Storage zu virtualisieren, nur um daneben auch OSX zu haben...

Ich würde da eher Storage barebone eigenständig betreiben oder mich mit den Storageoptionen von Linux begnügen. OSX virtualisieren habe auch schon gemacht es dann aber gelassen und bei Bedarf einen Mac hingestellt und den per TimeMachine gesichert und die Daten per NFS/SMB/iSCSI bereitgestellt.

 

[you]

Wäre mir deutlich zuviel "Vollwertkost" und Abhängigkeiten.

Yepp. Deswegen habe ich es lange herausgezögert. Aber ich brauche es so, wie ich es geschrieben habe. Und daheim stelle ich mir keine zweite Maschine hin.

Falls also irgendwer Omnios erfolgreich auf KVM (unter Proxmox) mit durchgereichtem HBA virtualisiert hat, bitte melden ... Danke.

 

[gea]

OpenIndiana 2020.10

OpenIndiana, einer der wichtigsten Illumos (freie Solaris Forks) Distributionen neben OmniOS, NexentaStor and SmartOS und mehr oder weniger der Nachfolger von OpenSolaris mit einer Server und Desktop Version hat einen neuen Snapshot

neu z.B..:
SMB 3.11, Bhyve, FreeRDP, Remmina, Mate 1.24 and gcc10

OpenIndiana Hipster 2020.10 is here – openindiana

www.openindiana.org

 

[AliManali]

Wie ist das eigentlich? Ich hatte eben mal ein xigmanas mit einer virtuellen Platte am vSphere Host. Die Daten Platte war als NFS Freigabe auf einem napp-it. Dann habe ich auf napp-it per SMB zugergriffen, und versehentlich die VMDK gelöscht, auf der die xigmanas Daten drauf waren.

• wieso war das überhaupt möglich, obwohl xigmanas lief?
• wieso konnte ich noch munter weiter auf die "Platte" schreiben?
• einen Papierkorb hatte ich nicht aktiviert auf napp-it

Nicht weiter schlimm, das ist ein brutales Netzwerk, welches noch in der Entstehung ist. Aber muss ich davon ausgehen, dass ich am napp-it per SMB besser keine Fehler mache? Der Rest hat sonst snapshots, aber ich bin im Moment gerade etwas verunsichert, wie schnell da ganz blöde Fehler entstehen können, und ein komplettes Storage - mir nichts, Dir nichts - grad mal so gelöscht ist.

Kann ich am napp-it selber einen Papierkorb aktivieren, und wie wirkt sich das auf snaps aus? Ich habe versucht im Explorer versteckte Dateien einblenden, aber da wurde mir kein Papierkorb Ordner angezeigt.

 

[gea]

Wie ist das eigentlich? Ich hatte eben mal ein xigmanas mit einer virtuellen Platte am vSphere Host. Die Daten Platte war als NFS Freigabe auf einem napp-it. Dann habe ich auf napp-it per SMB zugergriffen, und versehentlich die VMDK gelöscht, auf der die xigmanas Daten drauf waren.

• wieso war das überhaupt möglich, obwohl xigmanas lief?

Eine vmdk ist nur in dem Moment geblockt, wenn darauf geschrieben wird. Läuft die VM quasi im Leerlauf, kann die vmdk gelöscht werden.

• wieso konnte ich noch munter weiter auf die "Platte" schreiben?

Das müsste man im Einzelfall untersuchen. Prinzipiell läuft die VM im Ram weiter. Bei einem Schreibversuch auf die nicht mehr vorhandene "Systemplatte" sollte es aber einen io Fehler geben.

• einen Papierkorb hatte ich nicht aktiviert auf napp-it

Napp-it (oder besser ZFS) hat kein Papierkorbkonzept (löschen->Papierkorb->Papierkorb leeren). Stattdessen kann über einen Snaps der jeweilige Dateistand bewahrt/versioniert werden. Zugriff darauf z.B. über Windows > vorherige Version.

Nicht weiter schlimm, das ist ein brutales Netzwerk, welches noch in der Entstehung ist. Aber muss ich davon ausgehen, dass ich am napp-it per SMB besser keine Fehler mache? Der Rest hat sonst snapshots, aber ich bin im Moment gerade etwas verunsichert, wie schnell da ganz blöde Fehler entstehen können, und ein komplettes Storage - mir nichts, Dir nichts - grad mal so gelöscht ist.

Kann ich am napp-it selber einen Papierkorb aktivieren, und wie wirkt sich das auf snaps aus? Ich habe versucht im Explorer versteckte Dateien einblenden, aber da wurde mir kein Papierkorb Ordner angezeigt.

Wie gesagt, ZFS hat kein Papierkorbkonzept sondern Versionierung mit Snaps (so viel und so oft wie man will, muss man halt aktivieren). Ein Windows Papierkorb arbeitet zunächst auch nur lokal. VSS (Windowsversionierung) ist optional je nach Windows. Zugriff auf ZFS Snaps nutzen das VSS shadow copies Konzept von Windows.

 

[AliManali]

Ja, danke!

Also ich habe nicht das xigmanas OS gleöscht. Sondern die virtuelle Datenplatte auf einem napp-it NFS Share. Das war ZFS, und da drauf eine SMB Freigabe über die ganze "Platte". Dann habe ich dem xigmanas quasi den Storage weg gezogen. Aber ich konnte da noch 20GB rauf kopieren, nachdem der Storage weg war. Nach einem Neustart am ESXi kam dann, vmdk fehlt. Bei 4GB für xigmanas.

Wie gesagt, ist nur Detail. Ein, zwei Tage Arbeit weg. Aber wenn ich mir da andere Verfehlungen meinerseits ausmale, dann gut Nacht. Ich habe da nur Wald und Wiesen Storage, ich kann mir eben mal löschen nicht überall grad leisten, wenn ich ehrlich bin. Mein ja nur.

 

[CommanderBond]

@CommanderBond : Du wurdest erhöhrt. Bitte sehr

Für 199eus das Stück nun 3 14TB Platten erworben. Wenn schon RaidZ1 so denke ich mir besser aus 3 als aus 4 Platten. 12 und 14TB sind öfter im Angebot in letzter Zeit, da lohnen die 8TB nicht mehr wirklich. Frage ist nur ob der Microserver die noch erkennt.

Nutze die LX Zones in OmniOS deren VMs auf nem Mirror aus 2mal Samsung 830 SSDs liegen.
Will die SSDs loswerden auch um Sata Ports freizu machen, wäre es empfehlenswert irgendeine kleine PCIe SSD dafür herzunehmen? bzw funktionieren die auch mit PCIe 2 oder erst ab Version 3? Und brauch man zwingend einen PCIe Slot mit x4 oder größer, oder geht auch x1 wenn man die Leistungseinbußen in Kauf nimmt?

 

[gea]

Ja, danke!

Also ich habe nicht das xigmanas OS gleöscht. Sondern die virtuelle Datenplatte auf einem napp-it NFS Share. Das war ZFS, und da drauf eine SMB Freigabe über die ganze "Platte". Dann habe ich dem xigmanas quasi den Storage weg gezogen. Aber ich konnte da noch 20GB rauf kopieren, nachdem der Storage weg war. Nach einem Neustart am ESXi kam dann, vmdk fehlt. Bei 4GB für xigmanas.

Wie gesagt, ist nur Detail. Ein, zwei Tage Arbeit weg. Aber wenn ich mir da andere Verfehlungen meinerseits ausmale, dann gut Nacht. Ich habe da nur Wald und Wiesen Storage, ich kann mir eben mal löschen nicht überall grad leisten, wenn ich ehrlich bin. Mein ja nur.

Genau deswegen macht man ja (viele) ZFS Snaps des NFS Dateisystems oder eines anderen ZFS Dateisystems. Egal ob man dann etwas löscht oder einfach einen früheren Stand braucht. Den z.B. Stand vor 15 Miniuten, vor einer Stunde, gestern 16:00, Donnerstag 22.10 abends, etc kann man dann schnell wiederherstellen. Man muss lediglich eine gewünschte Snap Historie einstellen.

Ob und wann eine VM bemerkt dass eine Platte weg ist liegt and ESXi bzw der VM. Schreiben bei Xigmanas geht ja auch zunächst in den Ram Schreibcache und wird - sofern sync nicht aktiviert- erst nach einer Verzögerung geschrieben. Dann sollte die fehlende Platte bemerkt werden. Kann aber durchaus sein, dass es lediglich einen Eintrag im System-Log gibt und auf der System Console.

Lediglich wenn die "Systemplatte" betroffen ist, wird es ein Panic/Absturz werden.

 

[asche77]

Für 199eus das Stück nun 3 14TB Platten erworben... Frage ist nur ob der Microserver die noch erkennt.

Selbst der G7 hat kein Problem mit den 14TB.
Aber besser 4 davon als RAID10, gibt halt die doppelten iops = mehr schwuppdizität.

 

[martingo]

Hi @gea,

ich habe die letzten Monate immer wieder mal Probleme, dass sich einzelne verschlüsselte Dateisysteme nicht automatisch ins OmniOS Dateisysteme mounten, sobald ich das übergeordnete Dateisystem entschlüssele. Zu Beginn hatte das immer funktioniert. Ca. die Hälfte funktioniert, die andere nicht. Struktur ist so:

tank01
> Encrypted
>> Shares
>>> Ablage
>>> Benutzer
>>> Develop
>>> Download
>>> Homemedia
>>> Multimedia
>>> Software
> Unencrypted
etc.

Die Verschlüsselung ist auf Encrypted konfiguriert. Alle anderen Dateisysteme werden entweder automatisch gemountet, sobald ich Encrypted unlocke oder eben nicht. Dann reicht ein manuelles "zfs mount tank01/Encrypted/Shares/Develop".
Die Dateisysteme, die nicht automatisch eingebunden werden, scheinen immer die selben zu sein. Berechtigungen und sonstige Einstellungen sind dort aber quasi identisch konfiguriert.
Gibt es da irgendwo ein Log oder hast Du andere Ideen? Das Log über den Button oben rechts zeigt nur die Befehle des Seite-ladens an. Die Entschlüsselung und das Mounten ist zu dem Zeitpunkt schon vorbei.

Viele Grüße
Martin

Nachtrag 16:12: warte erstmal, habe die Stelle in _lib/zfslib.pl gefunden, schaue es mir gerade an. In der Datei hatte ich damals ja schon für Solaris 11 das rekursive Mounten eingebaut, aber unter OmniOS scheint es irgendwie anders zu laufen.

Nachtrag 16:30: Ehrlich gesagt frage ich mich, wieso der unter OmniOS überhaupt irgendwelche Kind-Dateisysteme mountet. In Version 20.06a3 Pro sind die Zeilen 2260 bis 2350 relevant. Da wird an keiner Stelle etwas mit den Kind-Dateisystemen gemacht. In Z.2269 ist zwar ein Kommentar von mir, wo die Rede von rekursivem Mounten ist, aber das scheint nur von Solaris11 oben kopiert zu sein. In Solaris 11 gibt es "zfs key -r", das den Key lädt und dann rekursiv mountet. Auf meiner OmniOS Version (36) gibt es "zfs key" nicht, vermutlich wurde deshalb dort "load-key" genommen. "load-key" mountet aber nicht und "zfs mount" kennt auch unter OmniOS keine rekursive Option. Das muss ich mir nochmal ganz in Ruhe ansehen. Denke, es wird auf einzelne mount-Befehle in rekusiven Schleifen für alle Unter-Systeme hinauslaufen. Ich frage mich nur, wieso unter OmniOS überhaupt Untersysteme gemountet werden...

 

[gea]

Ich habe mich jetzt auch seit geraumer Zeit nicht mehr mit Verschlüssellung bei verschachtelten Dateisystemen beschäftigt. Klar ist dass Solaris und OmniOS (=Open-ZFS) sich anders verhalten und andere Befehle nutzen. Ein Problem auf das ich immer wieder dabei gestoßen bin ist ZFS Vererbung von Eigenschaften. Das was z.B. auf das Dateisystem Encrypted gesetzt ist, vererbt sich auf die tieferliegenden Dateisysteme. Ein unlock/mount dieses Dateisystems vererbt sich inkl. der Keys und SMB Shares und Mounts auf die enthaltenen Dateisysteme so dass diese dann alle zur Verfügung stehen.

Man kann auch einzelne Unter-Dateisysteme einzeln entriegeln und mounten. Wenn ich mich recht entsinne, sollte man jedoch vermeiden, mal etwas über das Parent und mal was über enthaltene Dateisysteme zu machen. Entweder immer alles einzeln bearbeiten oder immer über das Parent gehen oder man muss den Stand der Vererbung kontrollieren/setzen.

Das Problem kann man vermeiden, wenn man verschachtelte verschlüsselte Dateisysteme meidet. Hat man mal vererbte und per Dateisystem gesetzte ZFS Eigenschaften, dann kann man die auf Dateisystemebene löschen um wieder alles über Vererbung zu regeln.