Ergänzung Cache Drives zu einem bestehenden dRaid / I/O Probleme Validierung

[Fab1984]

Hallo zusammen,

wir haben ein draid1-10-33-1 mit 34x 16TB und bei einem Validierungstask (VM ca. 10TB) mit hoher, täglichen Datenbestandveränderung im Einsatz. der Server hat nur 64GB RAM.

Da der eine Task immer für I/O Probleme sorgt, möchten wir gerne das bestehende Storage mit 2x NVMe I/O Cache Cards (Samsung PM1735) 3,2TB erweitern und den RAM auf 256GB aufrüsten. Die Frage ist, ob wir den Cache zu dem bestehenden draid hinzufügen (z. B. unter ZFS) können, ohne die Daten zu verlieren. Oder ob es schon reicht den RAM zu erweitern?

Über ein kurzes Feedback würde ich ich sehr freuen.

Beste Grüße

 

[news]

Hallo,

wenn die Hardware es hergibt, ext. PCIe 3 4 Lanes verfügbar sind, dann würde ich noch mindestens 2x, besser mit 3x oder mehr SATA 3 SSDs ein ZFS Special Device als ZFS Mirror anhängen.

Z.B. über so eine Erweiterungskarte:
https://www.alternate.de/DeLOCK/PCIe-6P-SATA-PCIe-x4Karte-LP-Controller/html/product/1675689?sug=sata pcie controller

Das dann für zukünftig die Speicherung der Meta-Daten übernimmt. Das sind u.a. die verketteten Listen der Speicherorte der (default) 128 kB Blöcke.
Das läuft sonst noch über die HDDs und die können i.a. nicht so viele IOPS.

Ich sehe es nicht als Erfolgreich an, alles über ein NVMe ZFS Mirror Write Cache laufen lassen zu wollen, wenn die IOPS der HDDs das Problem sind.

Sicherlich sind 10 TB sehr viele Daten und je nach Backbone dauert das seine Zeit.

* Über welche Netzwerktopologie läuft dein Backupweg?

* Wie hoch ist im Augenblick Deine nomineller Durchsatz?
Siehe: "iperf3 - perform network throughput tests" über iperf3.
$ apt install iperf3

Wie hoch die die absolute lineare Schreibrate auf einen ZFS Server.

Z.b. eine 1 GByte Datei per rsync -avP <quelle> <ziel> übertragen.
Die Datei kann man so erzeugen:
$ dd if=/dev/random of=<file> bs=1M count=1024
$ time rsync -avP <file> root@<server-ip>:/tmp/

Evtl. auch dann mal auf 10, 25, 50 oder 100 GByte Dateigröße vergrößern, dann sieht man, wann das Caching nicht mehr greift.

 

[news]

Ups, mein Fehler habe draid überlesen:

https://openzfs.github.io/openzfs-docs/Basic Concepts/dRAID Howto.html

 

[Fab1984]

Hallo,

danke für das Feedback, auch wenn sich mir der tatsächliche Lösungsansatz noch nicht erschließt ;-)

Wir verfügen über eine 100GBE Topologie, aber die Backupserver sind "nur" über 40 GBE angebunden. Es werden zwei Netzwerkkarten genutzt die über MLAG und LACP an zwei Switche gehen (no single point of failure). Gesichert wird von Nodes mit NVMe´s Only.

Der Write Durchsatz liegt bei ca. 400-500 MB/Sek., was schon sehr darauf hindeutet, dass die HDD voll befeuert werden und vermuten lässt, dass die I/O Probleme daher kommen. Aber viel wichtiger: Der Fehler tritt ja beim Validierungstask auf, also bei einem eher Read-Intensive Task.

Ich freue mich über weiteres Feedback, insbesondere ob und wie wir den Cache auf ein bestehende draid vdev integrieren können, ohne die Daten und Ordnerstrukturen zu verlieren. Die Komponenten haben wir schon und sind auch für den eigenen Erfahrungsschatz gewillt, das zu testen.

Beste Grüße

 

[Dunuin]

SLOG und L2ARC sind unproblematisch. Das sind ja echt nur Caches die nach belieben hinzugefügt und auch wieder entfernt werden können.
SLOG hilft ausschließlich bei Sync Writes (Null Nutzen bei den normalen Async Writes).
L2ARC hilft nur beim Lesen und ist nur selten hilfreich. Da müsstest du schon immer die gleichen Daten wieder und wieder lesen und die müssen dann auch in den L2ARC passen.
Auch nicht vergessen: Je größer der L2ARC desto mehr RAM wird gebraucht -> desto weniger RAM hast du für den ARC -> du reduzierst die Größe deines weitaus schnelleren ARC für mehr aber viel langsameren L2ARC.

Special Devices helfen beim Lesen+Async Schreiben, sind aber kein Cache. Sprich sind deine Special Devices kaputt, sind auch alle Daten auf den HDDs weg. Also für ausreichend Redundanz sorgen. Auch hilft ein Special Device nur bei neuen Daten da die alten Metadaten nicht von den HDDs auf die SSDs kopiert werden.
Und ein Special Device kannst du nicht mehr entfernen, ohne den ganzen Pool zu zerstören, also nicht unbedacht hinzufügen.

Ich persönlich würde bei größeren HDD Pools auch immer SSDs als Special Devices einplanen, dass da wenigstens die ganzen kleinen Metadaten IO nicht mehr auf die HDDs gehen.

 

[Fab1984]

Danke für die umfangreiche Info. Hast du ein Best Practice oder White Paper wie Special Devices genau funktionieren und anzuwenden sind?
Insbesondere in Kombination mit unserem dRaid oder würde man hier eine gänzlich andere Strategie verfolgen?

 

[Dunuin]

Special devices sind wie der Name schon sagt spezielle Vdevs. Die sind dann nicht Teil vom draid vdev sondern vom Pool. Die OpenZFS Dokumentation ist da leider nicht sehr ergiebig was was Special Devices angeht:
https://openzfs.github.io/openzfs-docs/man/master/7/zpoolconcepts.7.html#special
https://openzfs.github.io/openzfs-docs/man/master/7/zpoolconcepts.7.html#Special_Allocation_Class

Aber die draid Anleitung sagt auch:

If a dRAID pool will hold a significant amount of small blocks, it is recommended to also add a mirrored special vdev to store those blocks.

 

[Falk R.]

Du kannst die Special Devices auch in einem anderen Raid laufen lassen. Daher mache ich bei Datengrab Servern mit RaidZ immer schnelle SSDs (gern NVME) als Special Device im Mirror. Da die nicht so groß sein müssen, sind die im Recovery auch veil schneller als eine HDD und da reicht in der Regel ein Mirror.

 

[Dunuin]

Du kannst die Special Devices auch in einem anderen Raid laufen lassen. Daher mache ich bei Datengrab Servern mit RaidZ immer schnelle SSDs (gern NVME) als Special Device im Mirror. Da die nicht so groß sein müssen, sind die im Recovery auch veil schneller als eine HDD und da reicht in der Regel ein Mirror.

Special Devices können außerdem kein raidz/draid. Da gehen nur Mirrors (Raid1) und Striped Mirrors (Raid10). Gut...und Single Disk...aber wer so etwas nutzen würde der würde auch auch auf raid0 für die HDDs setzen . Wenn man aber auf gleiche Redundanz wie z.B. ein Raidz2 oder Raidz3 kommen will, dann kann man einen Mirror nicht nur aus 2 sondern auch aus 3 oder 4 SSDs erstellen, das da dann 2 oder 3 beliebige SSDs aus dem 3 oder 4 Disk Mirror ausfallen können.

 

[news]

Guten Morgen,

ich streue noch einen Praxisbeitrag:

* https://forum.level1techs.com/t/zfs-metadata-special-device-z/159954

 

[Fab1984]

Wir haben das nun entsprechend umgesetzt, aber leider immernoch das selbe Problem bei den 10 TB VMs.

Wir haben das vorhandene draid ZFS durch Samsung PCIe NVMe im raid 1 ergänzt.
Zusätzlich haben wir auf 512 GB DDR4-RAM und 2x Xeon E5-2697A v4 aufgerüstet.

Liegt es eventuell an der Backupstrategie im Snapshot Modus und der langen Vorhaltezeit?

Für Lösungsvorschläge in alle Richtungen bin ich offen.

 

[Falk R.]

Wir haben das nun entsprechend umgesetzt, aber leider immernoch das selbe Problem bei den 10 TB VMs.

Wir haben das vorhandene draid ZFS durch Samsung PCIe NVMe im raid 1 ergänzt.
Zusätzlich haben wir auf 512 GB DDR4-RAM und 2x Xeon E5-2697A v4 aufgerüstet.

Liegt es eventuell an der Backupstrategie im Snapshot Modus und der langen Vorhaltezeit?

Für Lösungsvorschläge in alle Richtungen bin ich offen.

Hast du die als Cache Disk oder Special Device?

 

[Fab1984]

Special device

 

[Dunuin]

ZFS verschiebt keine existierenden Metadaten auf die Special Devices. Alles was vorher langsam war wird es also auch bleiben außer du löscht alles an Daten und schreibst es neu.

 

[Sebi-S]

ZFS verschiebt keine existierenden Metadaten auf die Special Devices. Alles was vorher langsam war wird es also auch bleiben außer du löscht alles an Daten und schreibst es neu.

Die Frage ist, wie sich das System verhalten wird. Wird das System nach und nach schneller werden?
Oder wird das System bestehende alte Daten stets beibehalten, sodass es langsam bleibt?

 

[Falk R.]

Wenn du alles löschst, bleibt nix altes. Wenn man im ZFS clones macht oder Dedup eingeschaltet hat, die daten kopiert und dann die alten löscht, hilft das natürlich wenig. Wenn man eh alles löscht und dann neu schreibt, könnte man den Pool auch auflösen und neubauen wenn der leer ist.

 

[Dunuin]

Wird das System nach und nach schneller werden?
Oder wird das System bestehende alte Daten stets beibehalten, sodass es langsam bleibt?

Alles neue an Daten wird natürlich das System über die Zeit schneller werden lassen. Das tolle an PBS ist ja aber gerade die Deduplikation, dass da nichts erneut gespeichert wird, was bereits im Datastore existiert. Deine alten Daten werden also nie überschrieben, außer du löscht sie, damit sie erneut geschrieben werden müssen. Und da auch deine neuen Backups weiterhin die alten Chunks verwenden, werden auch neue Backups nie wirklich schnell sein, da ja auf die alten langsamen Daten verwiesen wird.

 

[Sebi-S]

Alles neue an Daten wird natürlich das System über die Zeit schneller werden lassen. Das tolle an PBS ist ja aber gerade die Deduplikation, dass da nichts erneut gespeichert wird, was bereits im Datastore existiert. Deine alten Daten werden also nie überschrieben, außer du löscht sie, damit sie erneut geschrieben werden müssen. Und da auch deine neuen Backups weiterhin die alten Chunks verwenden, werden auch neue Backups nie wirklich schnell sein, da ja auf die alten langsamen Daten verwiesen wird.

Okay, danke für die Klarheit.
Jetzt möchte ich die Backups die ich bereits habe nicht unbedingt alle über den Haufen werfen. So wie du die Lage beschreibst würde es jedoch funktionieren wenn ich neue Datastores anlege und Backups ab sofort in einen anderen Datastore im gleichen Pool ablege, richtig?

 

[Dunuin]

Was du auch machen kannst, wenn du mehr als 50% frei hast ist, dass du einen neuen Datastore auf dem selben Storage anlegst. Dann alles per lokalem Sync Job vom alten auf den neuen Datastore syncen und re-verify durchführen. Dann entweder den alten Datastore löschen und die Backups auf dem neuen belassen. Oder alternativ alle Backup Snapshots vom alten Datastore prunen, 24h + 5min warten, GC laufen lassen, wieder alles zurück syncen, re-verify und dann den neuen Datastore löschen.
Hauptsache die Chunks werden alle einmal neu geschrieben.

 

[Falk R.]

Okay, danke für die Klarheit.
Jetzt möchte ich die Backups die ich bereits habe nicht unbedingt alle über den Haufen werfen. So wie du die Lage beschreibst würde es jedoch funktionieren wenn ich neue Datastores anlege und Backups ab sofort in einen anderen Datastore im gleichen Pool ablege, richtig?

Falls du einen neuen Namespace meinst, dann hilft das nix, da auch dann nur neue Chunks geschrieben werden und sonst auf die alten Referenziert.