Hallo,
ich habe ein paar grundsätzliche Verständnisfragen zur Thematik ZVOL (genutzt für ein iSCSI-Target) und Snapshot-Replication auf eine zweite NAS.
Gegeben sind zwei TrueNAS Core mit jeweils 8 x 7 TB SSD-Speicher im RAIDZ2. Das primäre NAS stellt eine 30 TB-große iSCSI-LUN an ein XCP/Xen-Cluster bereit. Das ZVOL soll dabei in 15-Minuten-Intervallen auf das sekundäre NAS repliziert werden.
Soweit so einfach, die grundsäztzliche Einrichtung des Snapshot- Replication Tasks war kein Problem. Allerdings bin ich ziemlich schnell in das Problem gerannt, dass auf dem primären NAS keine Snapshots mehr erstellt werden konnten, weil bei der Anlage des ZVOLs offenbar die refreservation auf die volle Größe des ZVOLs gesetz wurde.
Wenn ich das richtig verstanden habe, dient dies dazu, den Pool-Speicher künstlich zu "verknappen", damit keine Snapshots mehr möglich sind, die im WorstCase soviel Speicherplatz wie 100% der ZVOL-größe benötigen. Mir ist klar, dass nur so sichergestellt werden kann, dass dem ZPool (und somit dem ZVOL) nicht der Speicher ausgeht und es dadurch zu Datenkorruption im ZVOL kommt.
Allerdings würde dies bedeuten, dass ich von dem 30 TB großen ZVOL keine Snapshots mehr machen kann, wenn etwa 9 TB belegt sind. D.h. der "Verschnitt" wäre gigantisch und extrem teuer.
Als Workaround hätte ich die Möglichkeit den Wert für "refreservation" entsprchend nach unten anzupassen. Aktuell fahre ich jetzt mit einem Wert von 5TB. Allerdings habe ich jetzt etwas "Angst", dass durch einen blöden Zufall doch der Speicher ausgeht und meine LUN korrumpiert. Mich würde daher eure Meinung interessieren, wie ihr das Risiko einschätzt, bzw. was getan werden kann, um das Risiko zu minimieren.
Damit ihr das besser nachvollziehen könnt, hier nochmal die konkreten Daten:
Wenn ich das richtig verstehe, ergeben sich daraus erstmal eine Pool-Netto-Kapazität von etwa 39 TB.
Das ZVOL "LUN0" ist 30 TB groß:
Aktuell sind dabei etwa 8,5 TB des ZVOLs aktiv genutzt (8,5 TB physisch, also komprimiert, 11,2 TB logisch unkomprimiert).
Und wie man sehen kann, habe ich jetzt eine 5TB "refreservation" angelegt, die auf den belegten Platz draufaddiert wird, um den verfügbaren Platz im Pool zu verknappen.
Da die Snapshots für die Replikation immer bereits nach einer Stunde wieder aufgelöst werden, würde ich nicht erwarten, dass die Snapshots selbst mehr als vielleicht 1 TB belegen. Grundsätzlich können die Snapshots ja nie mehr belegen, als in einer Stunde als Delta im ZVOL auflaufen kann, oder?
Aktuell belegen die Snapshots daher auch nur ein paar hundert MB:
Daher jetzt meine konkrete Frage an euch: halte ihr es für empfehlenswert bzw. "sicher", das Setup so zu betreiben? Wie groß würdet ihr die "refreservation" ansetzen, und warum? Wie groß schätzt ihr das Risiko eine Datenkorruption aufgrund einer "Überbuchung" des Pool-Speichers bei diesem Setup ein?
Nach meinem Verständnis wäre das schlimmste, was passieren könnte, dass ein Snapshot aus irgendeinem Grund über Tage oder Wochen unbemerkt bestehen bleibt und daher dann gefährlich viel Speicherplatz belegt, der irgendwann dazu führt, dass dem Pool der Speicher ausgeht und das ZVOL korrumpiert. Richtig?
Daher frage ich mich: Was kann gegen dieses Risiko eines "verwaisten" Snapshots getan werden? Reicht es, sich auf die Snapshot-Tasks zu verlassen? Gibt es eine Möglichkeit, sich vom TrueNAS-System in so einem Fall via E-Mail benachrichtigen zu lassen?
Ideal fände ich eine automatismus, der Snapshots im Notfall selbstständig löscht. Soweit ich weiss, ist das bei Linux-LVM-Snapshots der Fall: Wenn hier der VolumeGroup der Speicher ausgeht, weil ein Snapshot zu viel Platz belegt, dann wird der Snapshot vor erreichen der Speichergrenze automatisch gelöscht. Ich könnte jederzeit damit leben, dass ein Snapshot im Notfall gelöscht wird. Womit ich hingegen auf keinen Fall leben kann, wäre eine Korruption des ZVOLs.
Ich bin daher auf eure Meinung, Ideen und Anregungen gespannt.
Viele Grüße,
Jörn
ich habe ein paar grundsätzliche Verständnisfragen zur Thematik ZVOL (genutzt für ein iSCSI-Target) und Snapshot-Replication auf eine zweite NAS.
Gegeben sind zwei TrueNAS Core mit jeweils 8 x 7 TB SSD-Speicher im RAIDZ2. Das primäre NAS stellt eine 30 TB-große iSCSI-LUN an ein XCP/Xen-Cluster bereit. Das ZVOL soll dabei in 15-Minuten-Intervallen auf das sekundäre NAS repliziert werden.
Soweit so einfach, die grundsäztzliche Einrichtung des Snapshot- Replication Tasks war kein Problem. Allerdings bin ich ziemlich schnell in das Problem gerannt, dass auf dem primären NAS keine Snapshots mehr erstellt werden konnten, weil bei der Anlage des ZVOLs offenbar die refreservation auf die volle Größe des ZVOLs gesetz wurde.
Wenn ich das richtig verstanden habe, dient dies dazu, den Pool-Speicher künstlich zu "verknappen", damit keine Snapshots mehr möglich sind, die im WorstCase soviel Speicherplatz wie 100% der ZVOL-größe benötigen. Mir ist klar, dass nur so sichergestellt werden kann, dass dem ZPool (und somit dem ZVOL) nicht der Speicher ausgeht und es dadurch zu Datenkorruption im ZVOL kommt.
Allerdings würde dies bedeuten, dass ich von dem 30 TB großen ZVOL keine Snapshots mehr machen kann, wenn etwa 9 TB belegt sind. D.h. der "Verschnitt" wäre gigantisch und extrem teuer.
Als Workaround hätte ich die Möglichkeit den Wert für "refreservation" entsprchend nach unten anzupassen. Aktuell fahre ich jetzt mit einem Wert von 5TB. Allerdings habe ich jetzt etwas "Angst", dass durch einen blöden Zufall doch der Speicher ausgeht und meine LUN korrumpiert. Mich würde daher eure Meinung interessieren, wie ihr das Risiko einschätzt, bzw. was getan werden kann, um das Risiko zu minimieren.
Damit ihr das besser nachvollziehen könnt, hier nochmal die konkreten Daten:
Code:
root@storage1[~]# zpool list -v
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
boot-pool 872G 1.52G 870G - - 0% 0% 1.00x ONLINE -
da0p2 878G 1.52G 870G - - 0% 0.17% - ONLINE
tank 55.9T 12.2T 43.7T - - 1% 21% 1.00x ONLINE /mnt
raidz2-0 55.9T 12.2T 43.7T - - 1% 21.8% - ONLINE
gptid/0d42267f-d7e0-11ee-9f3d-e4434b30c7b6 6.98T - - - - - - - ONLINE
gptid/0d1bb6b8-d7e0-11ee-9f3d-e4434b30c7b6 6.98T - - - - - - - ONLINE
gptid/0d3679d6-d7e0-11ee-9f3d-e4434b30c7b6 6.98T - - - - - - - ONLINE
gptid/0d314011-d7e0-11ee-9f3d-e4434b30c7b6 6.98T - - - - - - - ONLINE
gptid/0d4393e8-d7e0-11ee-9f3d-e4434b30c7b6 6.98T - - - - - - - ONLINE
gptid/0d233216-d7e0-11ee-9f3d-e4434b30c7b6 6.98T - - - - - - - ONLINE
gptid/0d32cc31-d7e0-11ee-9f3d-e4434b30c7b6 6.98T - - - - - - - ONLINE
gptid/0d287d3d-d7e0-11ee-9f3d-e4434b30c7b6 6.98T - - - - - - - ONLINE
Wenn ich das richtig verstehe, ergeben sich daraus erstmal eine Pool-Netto-Kapazität von etwa 39 TB.
Das ZVOL "LUN0" ist 30 TB groß:
Code:
root@storage1[~]# zfs get all tank/lun0 NAME PROPERTY VALUE SOURCE tank/lun0 type volume - tank/lun0 creation Fri Mar 1 18:01 2024 - tank/lun0 used 13.7T - tank/lun0 available 30.9T - tank/lun0 referenced 8.65T - tank/lun0 compressratio 1.41x - tank/lun0 reservation none default tank/lun0 volsize 31.0T local tank/lun0 volblocksize 64K - tank/lun0 checksum on default tank/lun0 compression lz4 inherited from tank tank/lun0 readonly off default tank/lun0 createtxg 1163 - tank/lun0 copies 1 default tank/lun0 refreservation 5T local tank/lun0 guid 10687803515506356379 - tank/lun0 primarycache all default tank/lun0 secondarycache all default tank/lun0 usedbysnapshots 1.40G - tank/lun0 usedbydataset 8.65T - tank/lun0 usedbychildren 0B - tank/lun0 usedbyrefreservation 5.00T - tank/lun0 logbias latency default tank/lun0 objsetid 7811 - tank/lun0 dedup off default tank/lun0 mlslabel none default tank/lun0 sync standard default tank/lun0 refcompressratio 1.41x - tank/lun0 written 199M - tank/lun0 logicalused 11.2T - tank/lun0 logicalreferenced 11.2T - tank/lun0 volmode default default tank/lun0 snapshot_limit none default tank/lun0 snapshot_count none default tank/lun0 snapdev hidden default tank/lun0 context none default tank/lun0 fscontext none default tank/lun0 defcontext none default tank/lun0 rootcontext none default tank/lun0 redundant_metadata all default tank/lun0 encryption off default tank/lun0 keylocation none default tank/lun0 keyformat none default tank/lun0 pbkdf2iters 0 default tank/lun0 snapshots_changed Sat Mar 16 8:15:01 2024 - tank/lun0 org.truenas:managedby 91.89.172.190 local tank/lun0 org.freebsd.ioc:active yes inherited from tank
Aktuell sind dabei etwa 8,5 TB des ZVOLs aktiv genutzt (8,5 TB physisch, also komprimiert, 11,2 TB logisch unkomprimiert).
Und wie man sehen kann, habe ich jetzt eine 5TB "refreservation" angelegt, die auf den belegten Platz draufaddiert wird, um den verfügbaren Platz im Pool zu verknappen.
Da die Snapshots für die Replikation immer bereits nach einer Stunde wieder aufgelöst werden, würde ich nicht erwarten, dass die Snapshots selbst mehr als vielleicht 1 TB belegen. Grundsätzlich können die Snapshots ja nie mehr belegen, als in einer Stunde als Delta im ZVOL auflaufen kann, oder?
Aktuell belegen die Snapshots daher auch nur ein paar hundert MB:
Code:
root@storage1[~]# zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT boot-pool/ROOT/default@2024-03-01-14:29:47 4.72M - 1.51G - tank/lun0@auto-2024-03-16_07-15 351M - 8.65T - tank/lun0@auto-2024-03-16_07-30 139M - 8.65T - tank/lun0@auto-2024-03-16_07-45 129M - 8.65T - tank/lun0@auto-2024-03-16_08-00 113M - 8.65T - tank/lun0@auto-2024-03-16_08-15 108M - 8.65T -
Daher jetzt meine konkrete Frage an euch: halte ihr es für empfehlenswert bzw. "sicher", das Setup so zu betreiben? Wie groß würdet ihr die "refreservation" ansetzen, und warum? Wie groß schätzt ihr das Risiko eine Datenkorruption aufgrund einer "Überbuchung" des Pool-Speichers bei diesem Setup ein?
Nach meinem Verständnis wäre das schlimmste, was passieren könnte, dass ein Snapshot aus irgendeinem Grund über Tage oder Wochen unbemerkt bestehen bleibt und daher dann gefährlich viel Speicherplatz belegt, der irgendwann dazu führt, dass dem Pool der Speicher ausgeht und das ZVOL korrumpiert. Richtig?
Daher frage ich mich: Was kann gegen dieses Risiko eines "verwaisten" Snapshots getan werden? Reicht es, sich auf die Snapshot-Tasks zu verlassen? Gibt es eine Möglichkeit, sich vom TrueNAS-System in so einem Fall via E-Mail benachrichtigen zu lassen?
Ideal fände ich eine automatismus, der Snapshots im Notfall selbstständig löscht. Soweit ich weiss, ist das bei Linux-LVM-Snapshots der Fall: Wenn hier der VolumeGroup der Speicher ausgeht, weil ein Snapshot zu viel Platz belegt, dann wird der Snapshot vor erreichen der Speichergrenze automatisch gelöscht. Ich könnte jederzeit damit leben, dass ein Snapshot im Notfall gelöscht wird. Womit ich hingegen auf keinen Fall leben kann, wäre eine Korruption des ZVOLs.
Ich bin daher auf eure Meinung, Ideen und Anregungen gespannt.
Viele Grüße,
Jörn
