[Sammelthread] ZFS Stammtisch

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
In den server kommt ein 9400er HBAs also das anschließen der u.2 ist kein problem. Was würdest Du vorschlagen ein POOL aus 4x P900 oder die S4500 als mirror und 2 P900 als special mirror vdev?
Ich habe dein Doc. zu den special vdevs gelesen war sehr aufschlussreich, ich kannte den Kram noch garnicht.

Bei einem reinen Optane Pool werden alle io Aktionen sehr schnell ausgeführt, auch sync write (besser als 10 Gb/s Netzwerke). Bei einem langsameren Pool hat man dessen geringere Performance auch bei sync. Fügt man einen special vdev Mirror aus Optane hinzu, dann erreicht man im Wesentlichen

- es werden small io beschleunigt bzw Dateisysteme deren recsize <= dem Schwellwert ist.
Einzelne Dateisysteme haben damit volle "Optane Performance"

- Der Zugriff auf Metadaten die noch nie gelesen wurden oder die sich nicht im Arc befinden wird schneller,

aber:
- Sync write bleibt relativ schlecht auf den S4500 (so schlecht sind die aber auch nicht, eventuell bringt ein Optane Slog nur etwas mehr)
- Metadaten die schonmal gelesen wurden (Arc) werden eh aus dem noch schnelleren RAM bedient


Ganz ersetzt ein special vdev damit ein Slog oder L2Arc nicht.
- Persistent L2Arc würde einen schnellen größeren und dauerhaften Cache ermöglichen
- Slog sync write beschleunigen.

Eine Option z.B. unter ESXi wären mehrere kleinere virtuelle Platten oder ein Partitionieren (hat eigene Probleme) der P900,
z.B. Slog 15GB, L2Arc 5 x RAM und den Rest als special vdev mirror. Ist aber nicht ganz ideal unter dem Aspekt "keep it simple".

Special vdev
Wenn man nur Metadaten und small io darauf packt (also nicht komplette Dateisysteme) ist der Über Alles Vorteil recht gering sofern man nicht sehr viele Metadaten immer wieder neu einlesen muss. Ein Mailserver mit > 1M Dateien würde sehr gut von special vdev profitieren. Ein Mediaserver kaum.
 
Zuletzt bearbeitet:
Wenn ich das richtig gesehen habe kann man auch ein dedup vdev anlegen. Dann könnte man z.b. 1x Special Vdev aus Optane SSDs anlegen und 1x ein DEDUB Vdev.
 
guckste hier:
und holst einfach einen M2 auf U.2 Adapter ;)

Fazit: es funzt nicht zu 100%, Raidfunktionalität via CPU (RaidXpert2) habe ich nicht hinbekommen, ob Intels VROC da besser funktionieren würde kann ich nicht sagen.
 
Wenn ich das richtig gesehen habe kann man auch ein dedup vdev anlegen. Dann könnte man z.b. 1x Special Vdev aus Optane SSDs anlegen und 1x ein DEDUB Vdev.

Immer als Mirror!
Wenn ein vdev (normal oder special, bis auf L2Arc und Slog) ausfällt, bedeutet das Pool lost - alles weg!
 
Bei einem reinen Optane Pool werden alle io Aktionen sehr schnell ausgeführt, auch sync write (besser als 10 Gb/s Netzwerke). Bei einem langsameren Pool hat man dessen geringere Performance auch bei sync. Fügt man einen special vdev Mirror aus Optane hinzu, dann erreicht man im Wesentlichen...
Ich konnte mein RR & RW problem auf LXC eingrenzen. Unter Windows hab ich das problem nicht (sehr kurios). Ich werde wohl auf lange Sicht wohl auf 4x P900 gehen mehr wie 500gb für VMs brauche ich z.Z. nicht.
 
Recursive Datasets für VM-storage (ESXi, NFS)?

Setup: all-in-one: ESXi 7.03c / OmniOS r40 als storage VM / ESXi bindet storage via NFS3 an

Ich würde meinen VM-storage gerne in recursive datasets aufteilen, dh. 1 dataset = 1 VM. Vorteil: Leichter rollback (nur) dieser VM, separate snapshots, direkter Rückgewinn von freiem Platz wenn ich sie endgültig lösche

Mein "Problem":
Derzeit müsste ich die datasets alle einzeln als NFS-Freigabe in ESXi einbinden.

Ich würde dort aber lieber nur 1x das parent-dataset VMstorage einbinden und dann in die Unterordner wechseln können. Per SMB geht das (ich kann -> VMstorage -> VM-Unterordner ansteuern und Dateien öffnen), per NFS in ESXi sehe ich den Unterordner aber er ist leer.

EDIT: Die Lösung ist das setzen der sharenfs-Option "nohide": "pfexec zfs set sharenfs=nohide,[sonstige optionen] [parent-dataset]"
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: gea
Zumindest das Rollback einzelner VMs geht problemlos und einfach via zusätzlicher SMB Freigabe des NFS Shares und Windows "vorherige Version" auf den Ordner einer VM. Snapshots gezielter löschen ist ein Argument.

Nachteil:
Bei inkrementeller rekursiver Replikation fehlen die Basissnaps neu angelegter VMs. Man muss also aufpassen und Replikation wird deutlich aufwendiger sofern man nicht auch einen Replikationsjob per untergeordnetem Dateisystem erzeugt. Bei eher wenigen Dateisystemen (<20) ist der Aufwand ok

Der Tipp mit nohide ist prima
 
Zuletzt bearbeitet:
Leider scheint die NFS-Freigabe via "nohide" Probleme zu machen:

Seit ich das nutze, werden meine VMs nach ein paar Minuten gestoppt mit der Fehlermeldung (in etwa) "The lock protecting test.vmdk has been lost, possibly due to underlying storage issues. If this virtual machine is configured to be highly available, ensure that the virtual machine is running on some other host before clicking OK" (vgl. https://kb.vmware.com/s/article/1022119)

Ich stelle jetzt wieder um auf die "alten" VMs unter dem Haupt-NFS-Ordner.
 
OK, wenn ihr auf die Idee kommen solltet Dedup zu fahren, sollte man keine Files löschen.
Das Löschen einer 5TB File hat meine special-VDEVs so mit IOs bombadiert, dass andere Dinge, (wie das Kopieren von Daten auf das ZFS blockiert wurden.)

Ich weiss noch nicht was die Leistung gezogen hat beim Löschen, ob das die Metadaten auf dem Special Vdev waren oder die Dedup Files.
Ich denke Dedup ist mehr etwas für einen Backup Server. Und selbst hier sollte man die SSDs für Dedup von den Metadata SSDs trennen. Evlt kann man ja dann für die Metadaten kleinere Optane nehmen.

Es gibt das special vdev dedup, dieses sorgt dafür, dass special_small_blocks und Metadaten nicht auf das vdev für für die dedup tabellen landen. Weiterhin scheint es möglich zu sein ein Limit zu setzen für spezial_small_blocks. So dass Metadaten nicht auf das/die HDD Vdevs rüberfallen.
 
Das ist Marketing und bedeutet, dass sie kein "echtes" PLP hat - das würde nämlich die Daten "in flight" schützen (im DRAM Cache) und nicht nur die, die schon sicher auf dem flash gelandet sind.
 
asche77 die SSD scheint keinen DRAM Cache wenn ich das richtig gesehen habe. Daher ist die Frage: was wird nicht geschützt? Ich gehe davon aus, die Blöcke welche vom Controller auf die Flash Chips geschrieben werden.
 
Ja, alles was noch nicht fix auf den flash geschrieben wurde (inkl die FTL).

Letztlich geht es doch um die Frage, wann die SSD einen sync write als erledigt bestätigt - die PLP SSD macht das fix, da sie wegen PLP Puffern kann; die normale (SATA) SSD muss immer erst schreiben, checken und kann dann erst bestätigen. Daher so langsame sync writes (kein Cache, keine optimierung der Schreibzugriffe/queue, damit auch random und nicht sequential performance, vermutlich deutlich höhere write amplification).

Wie das bei dieser micron nun genau ist - keine Ahnung.... Micron schreibt allgemein hier was dazu: https://www.micron.com/-/media/clie.../ssd_power_loss_protection_white_paper_lo.pdf
 
Der Käufer einer SSD möchte hohe Performance (zumindest auf dem Datenblatt) und niedrige Preise. Der Hersteller kann das liefern mit der Einschränkung dass eine hohe Schreibperformance nur ein paar Sekunden und nur bei neuen/leeren SSDs bzw nach Trim möglich ist. Stürzt der Rechner beim Schreiben ab, ist die Konsistenz der Daten, des Dateisystems oder des Raid nicht gewährleistet.

Will man hohe Performance (nicht nur auf dem Datenblatt oder da mit realistischeren Werten), anhaltend gute Schreibperformance und sicheres Schreiben steigt der Aufwand und die Kosten erheblich. Selbst bei Intel Optane die ohne Dram Cache arbeiten, garantiert Intel nur bei den Datacenter Modellen Powerloss Protection, nicht bei den "billigeren" Consumer Modellen,

Für den Hersteller ist das lösbar. Es gibt entweder billige "Desktop" Modelle die dafür geeignet und schnell sein können (z.B. Samsung EVO/Pro) oder Datacenter Modelle die teurer sind, ihre Performance halten (auch ohne Trim das ja auch Performance kostet) und bei denen ein Absturz beim Schreiben eben keinen Verlust bestätigter Schreibvorgänge zur Folge hat.

Für den Kauf bedeutet das meist entweder billig und unsicher oder teurer und sicher.
 
Gegeben ist ein HP ProLiant DL360 Gen9 mit 2x Netzteil, USV, Smart Storage Battery (mom leider defekt). Wenn ich einen SSD-Spiegel mit PLP einsetze, ist es dann noch notwendig für eine Windows-VM (Datenbank - FiBu, Bank) den Modus write-sync einzusetzen, oder ist es nur eine zusätzliche Sicherheit?
 
Gegeben ist ein HP ProLiant DL360 Gen9 mit 2x Netzteil, USV, Smart Storage Battery (mom leider defekt). Wenn ich einen SSD-Spiegel mit PLP einsetze, ist es dann noch notwendig für eine Windows-VM (Datenbank - FiBu, Bank) den Modus write-sync einzusetzen, oder ist es nur eine zusätzliche Sicherheit?

Wenn der Rechner ohne sync write abstürzt, ist der komplette Inhalt des rambasierten Schreibcaches verloren. Das können mehrere GB bestätigte Schreibvorgänge sein. Bei einer Finanzbuchhaltung kann es dabei passieren dass Geld von einem Konto abgebucht ist, es aber noch nicht auf ein anderes Konto "sicher auf Platte" aufgebucht wurde. Bei einer VM kommt dazu dass ein Absturz beim Schreiben nicht nur Datenverlust bedeutet sondern oft zusätzlich ein korruptes ntfs Dateisystem. ZFS als Dateisystem ist zwar wegen Copy on Write crashsicher - nicht jedoch die Daten.

Schlechter Plan! Sync write ist bei Datenbanken sogar noch wichtiger als plp.
Eigentlich ist es aber so, man braucht beides.

Wie beim Auto. Auch da braucht man Nackenstütze und Sicherheitsgurt gleichzeitig damit man bei einem Auffahrunfall von vorne und von hinten geschützt ist.
 
Zuletzt bearbeitet:
thx@gea

das heist also ich buche das volle Programm für ein Produktivsystem, bestehend aus USV, 2x Netzteil, Smart Sorage Battery, 2x SSD mit PLP als Mirror und ein SLOG-Device (imho auch als Mirror). Mal schauen, ich habe mom 2x SSD und 6x SAS-HDD, ich kann anstelle des opt. LW eine SSD einsetzen für OmniOS/NappIt, für das SLOG-Device muss ich mal nach PCIe-Lösung schauen.
 
Smart storage battery? ZFS willst du nur an einem HBA betreiben für ein Produktivsystem. Niemals nicht an einem Hardware RAID Controller!
 
Bei SSDs ist ein Slog nicht nötig.
Einfach einen Mirror machen und sync aktivieren. Wenn man Top Performance möchte, halt die besseren write optimierten SSD nehmen (Datacenter NVMe oder SAS SSD wie WD SS530/540 oder Seagate Nytro)
 
@mrpasc
Der HPE Smart Array P440ar läuft im HBA-Modus, die Raid-Funktion wird nicht genutzt. Mit der Batterie könnte ich eine PowerLessProtection bei den SAS-HDD nachbilden (glaube ich zumindest).

@asche77
Ich dachte man sollte ein SLOG auf einem Mirror betreiben. Ich werde es so machen wie @gea es schrieb und das SLOG weglassen.
(Ist sogar einfacher, da ich nicht genügend SATA/SAS-Ports frei habe und mir keine PCIe-Lösung basteln muss).

Danke Euch für die Infos.
 
Slog muss kein mirror sein. Beim Ausfall wird der Pool langsamer (bei sync writes) aber grds. kein Datenverlust.*
Special vdev "muss" mirror sein.

(Geändert)
 
Zuletzt bearbeitet:
nur als kleine Ergänzung zum Gesagten

- Hardware Raidkarte mit "HBA Modus".
Man benötigt einen guten und stabilen Treiber für die Raidkarte.
Das ist bei Unix (Free-BSD, OmniOS, Solaris) nicht unbedingt der Fall
Besser einen reinen LSI-HBA nehmen, ideal mit IT Firmware, IR Firmware ist ok

- Powerloss und mechanische Festplatte
ist unkritisch da ZFS write back Cache kontrollieren kann.

-Single Slog
Wenn das Slog einfach ausfällt: Pool wird zum protokollieren genutzt. Kein Datenverlust - Pool wird nur langsamer
Wenn das Slog ausfällt und der Rechner abstürzt: Datenverlust
Wenn das Slog beim Schreiben disconnected (z.B. man zieht das Kabel oder die Platte). Io Error, System steht, Datenverlust

-Special vdev
geht nicht als Raid-Z, nur Basic und Mirror
 
Wenn das Slog ausfällt und der Rechner abstürzt: Datenverlust
Wenn das Slog beim Schreiben disconnected (z.B. man zieht das Kabel oder die Platte). Io Error, System steht, Datenverlust
Dumme Frage: gilt das (zumindest das erste) nicht unabhängig von slog ja oder nein? Auch bei sync writes ohne slog gibt es doch Datenverlust (RAM) wenn der Rechner beim Schreiben des ZIL auf den Pool abstürzt.
 
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