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:
Digi-Quick
Urgestein
- Mitglied seit
- 02.09.2009
- Beiträge
- 7.082
guckste hier:
und holst einfach einen M2 auf U.2 AdapterFestplatten & SSDs Solid State Drives (SSD) mit Schnittstelle: U.2/SFF-8639, IOPS 4K schreiben: ab 200k IOPS, Besonderheiten: Power-Loss Protection Preisvergleich Geizhals Deutschland
Preisvergleich und Bewertungen für Festplatten & SSDs Solid State Drives (SSD) mit Schnittstelle: U.2/SFF-8639, IOPS 4K schreiben: ab 200k IOPS, Besonderheiten: Power-Loss Protectiongeizhals.de
ASRock-Rack X570D4U : meine - etwas spezielleren - Erfahrungen....
ACHTUNG: "Wall of Text" folgt 8-) Ein Neuer Terminalserver soll gebaut werden, auf dem auch eine recht anspruchsvolle Anwendung läuft (Agenda). Nachdem die Hardware für die ursprünglich geplante Intel Plattform zur Zeit überhaupt nicht lieferbar ist bin ich kurzfristig zu AMD umgeschwenkt...
www.hardwareluxx.de
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.
Immer als Mirror!
Wenn ein vdev (normal oder special, bis auf L2Arc und Slog) ausfällt, bedeutet das Pool lost - alles weg!
Digi-Quick
Urgestein
- Mitglied seit
- 02.09.2009
- Beiträge
- 7.082
dann kannst du aber nur 2 (PCIe X4) oder maximal 4 (PCIe X2) U2 SSDs anschließen - jedenfalls bei den 8i Versionen, bei den 16i Versionen entsprechend doppelt so viel
Netleader
Enthusiast
- Mitglied seit
- 08.07.2011
- Beiträge
- 61
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]"
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:
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
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.
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.
Luckysh0t
Enthusiast
Man bräuchte quasi ein Skript/Job auf OmniOS was per SSH analog zum NFS Dataset gleich die Einbindung am ESXi macht - nach erstellung.(opt-in)
Bierjpg
Enthusiast
- Mitglied seit
- 10.02.2009
- Beiträge
- 432
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 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.
Laut Datenblatt hat sie "Power-loss protection (data at rest)". Wobei ich nicht genau beurteilen kann war mit "data at rest" gemeint ist.
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
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
Ja aber das haben keine M.2 mit mehr als 40k IOPS
Bist du da sicher, was das nicht Vorhandensein von PLP angeht? Was ist mit der Micron 7300 Pro und Max?
Netleader
Enthusiast
- Mitglied seit
- 08.07.2011
- Beiträge
- 61
Ich hab gestern das review von STS gesehen die 7400er haben PLP.
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.
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?
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.
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.
@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.
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.
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
- 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
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.
