Mirrored VDEV for caching

[tbol.inq]

Hallo zusammen,

ich habe 2 SSDs, die ich für einen Pool als Read-Cache verwenden möchte.
Muss ich diese vorher in einen Mirror packen und dann als Cache dem Pool hinzufügen oder packe ich einfach beide SSDs in den Cache?

Wie ist das dann wenn eine der beiden Disks ausfällt?

VG
Toni

 

[jgreco]

Es macht keinen Sinn, L2ARC zu spiegeln. Geht ein L2ARC verloren, werden die Daten bei Bedarf erneut aus dem Pool gelesen.

Bitte beachten Sie, dass Sie über ausreichend ARC verfügen sollten, um irgendwo zwischen 5:1 und 10:1 L2ARC-to-ARC zu unterstützen. In den meisten Fällen sollten Sie mindestens 64 GB ARC haben, bevor Sie einen L2ARC hinzufügen. Das bedeutet, dass Sie, wenn Sie TrueNAS CORE und 64 GB RAM haben, zwischen 320 GB und 640 GB L2ARC haben können. Oder für SCALE, wenn Sie 128 GB RAM haben, können Sie zwischen 320 GB und 640 GB L2ARC haben.

[via Google Translate, original:]
There is no point in mirroring L2ARC. If an L2ARC is lost, the data is re-read from the pool on demand.

Please note that you should have sufficient ARC to support somewhere between 5:1 and 10:1 L2ARC-to-ARC. You should have at least 64GB of ARC before adding an L2ARC in most cases. This means that if you have TrueNAS CORE and 64GB of RAM, you can have between 320GB and 640GB of L2ARC. Or for SCALE, if you have 128GB of RAM, you can have between 320GB and 640GB of L2ARC.

 

[tbol.inq]

Danke für die schnelle Antwort.
Wir haben circa 256 GB für ARC-Cache.

 

[ChrisRJ]

Jenseits der eigentlichen Frage koennte es hilfreich sein, mehr Informationen zum Use-Case und der Hardware zu haben. Denn die Frage impliziert, dass nicht so wahnsinnig viel Erfahrung mit TrueNAS/ZFS vorhanden ist. Und da besteht dann auch ein erhoehtes Risiko fuer andere Aspekte, die vielleicht nicht optimal geloest sind.

 

[bic]

Wir haben circa 256 GB für ARC-Cache.

Lies Dir bitte einmal bei diesem Link den Absatz zum L2ARC durch (aber gern auch alles andere). Vielleicht erweiterst Du dann doch lieber den Hauptspeicher

 

[tbol.inq]

@ChrisRJ bei der Hardware handelt es sich um ein TrueNAS R50 mit 23x12 TB, 2x3TB NVME SSDS, 32 GB NVME SLOG Device, 256 GB RAM. Der Use Case ist die Ablösung eines File-Servers für 2000 User, 100 TiB Volumen, mit 2000-3000 IOPS Average. Daten sollen ausschließlich per SMB bereitgestellt werden.

@bic: Danke für den Link, werde ich mir durchlesen.

Meine Grundidee war, die 2 3TB SSDS in einem mirrored vdev zu betreiben und dann einen Teil davon für den Cache und einen anderen als Deduplication Metadata Ziel zu verwenden (und da wäre ja etwas redundanz schon wichtig).

 

[Patrick M. Hausen]

SLOG ist sinnlos, da bei SMB nicht synchron geschrieben wird.

L2ARC bringt nur dann etwas, wenn der Speicher (RAM) ausgelastet ist, aber immer noch nennenswert ARC Misses auftauchen.

Von Deduplication würde ich kategorisch abraten.

Wenn der Einsatz ein SMB-Server für viele User ist, würde ich ein Metadata-VDEV empfehlen. Das beschleunigt Directory-Operationen enorm und damit auch das, was die Anwender als erstes wahrnehmen.

 

[tbol.inq]

@Patrick M. Hausen Danke für die Antworten. Aber warum Deduplication kategorisch ablehnen? Wir kommen von NetApp-Systemen, bei denen wir im CIFS Bereich bis zu 30% Einsparungen durch Deduplication haben. Darauf zu verzichten wäre sehr unschön. Ist das unter ZFS so ein Ding, dass das instabil oder schlecht läuft oder anfällig für Probleme ist?

Danke für den Hinweis bezüglichd es Metadata-VDEV :)

 

[Patrick M. Hausen]

Ist das unter ZFS so ein Ding, dass das instabil oder schlecht läuft oder anfällig für Probleme ist?

Es frisst Resourcen ohne Ende und mir persönlich zumindest ist es nach wie vor "zu heiß". 30% mehr Storage sind billig verglichen mit Datenverlust. Benutz mal die Suchfunktion hier im Forum.