Waschzettel für eine Datenmigration

[KaeTuuN]

Moin zusammen,

da der ZFS Pool für meine Nextcloud sich langsam füllt, möchte ich die Daten auf einen neuen umziehen und würde gerne einmal gegenprüfen lassen, ob das so klappen würde, oder ich einen Denkfehler habe. Ich bin für Verbesserungsvorschläge, sachliche Kritik und Anregungen offen!

Mein Setup:
Debian 13 + OpenZFS
5 x 1 TB SATA-SSD raidz1 (entspricht raid5), Name: nextcloud, mount: /srv/nextcloud
3 x 4 TB SATA-SSD raidz1 (entspricht raid5), Name: nextcloud_data, mount: /srv/nextcloud_data
Datenmenge: ca. 3,2 TB

Aktueller Plan

1. Einbau der neuen SSDs (Ausfall von ca. 30 Minuten)
2. Neuen zfs-volume erstellen
   

   zpool create -O encryption=aes-256-gcm -O keylocation=<file:///path/to/key> nextcloud_data raidz1 /dev/disk/by-uuid/UUID1 /dev/disk/by-uuid/UUID2 /dev/disk/by-uuid/UUID3

   
   
3. Erstmigration der Daten im laufenden Betrieb (Hierbei kann es, je nach sonstiger Last auf dem Server, zu etwas längeren Antwortzeiten bei der Nutzung kommen)
   

   rsync -AavxP --bwlimit=45000 /srv/nextcloud/ /srv/nextcloud_data/

   Durch die Begrenzung mit '--bwlimit=45000' sollte sichergestellt sein, dass die Auswirkungen auf den Betrieb minimal sind.
4. Wenn der Lauf durch ist (ca. 18-22 Stunden) fast das gleiche nochmal:
   

   rsync -AavxP --bwlimit=45000 --delete-after /srv/nextcloud/ /srv/nextcloud_data/

   Hierdurch werden die Änderungen, die es seit Start des ersten Durchlaufs gegeben hat nach synchronisiert (idR 5-10 GB).
   Durch Verwendung von '--delete-after' wird sichergestellt, dass keine Daten bestehen bleiben, deren Quelle inzwischen gelöscht wurde.
5. Nextcloud stoppen
6. Ein letzter Datensync um wirklich alles auf den gleichen Stand zu bringen (Dieses mal mit voller Geschwindigkeit):
   

   rsync -AavxP --delete-after /srv/nextcloud/ /srv/nextcloud_data/

7. Einige ZFS Befehle:
   

   zfs umount -r nextcloud    //unmount vom aktuellen nextcloud volume
   zfs export nextcloud    //Kann nicht schaden...
   zfs set mountpoint=none nextcloud    //Den Mountpoint soll gleich das neue Volume bekommen, daher hier entfernen, damit es keine Konflikte gibt
   zfs umount -r nextcloud_data    //Vorbereiten zum Umhängen
   zfs set mountpoint=/srv/nextcloud nextcloud_data    //Damit es für die Nextcloud Instanz keine Änderungen gibt
   zfs load-key -L <file:///path/to/key> nextcloud_data    //Zumindest früher wurde bei einem umount auch der Key mit entladen, daher muss der wieder geladen werden
   zfs mount nextcloud_data    //Mounten des neuen Volumes im alten Pfad

8. Prüfen ob die Daten lesbar sind und wenn ja, Nextcloud wieder Starten
9. Logs beobachten, ob es zu Fehlern kommt
10. Wenn alles gut ging, kann der alte ZFS Pool gelöscht werden und die SSDs ausgebaut werden. (Ausfall von ca. 20 Minuten, kann auch später erfolgen)

Ist jetzt doch länger geworden, als ich gedacht hatte... Danke schon mal an alle, die bis hierhin gelesen haben!

Mfg Kae

 

[madmax2010]

nice

im prinzip brauchst du nicht mal rsync und kannst das alles ZFS Nativ machen
zrepl hat da doku zu
https://zrepl.github.io/usage/runbooks/migrating_sending_side_to_new_zpool.html

 

[foofoobar]

Ich bin nicht so der Mega-zfs-heini, aber zum vollständigen kopieren von zfs-filesystem nutzt man eher zfs send anstatt rsync.

 

[KaeTuuN]

Danke für den Tipp mit zfs send! Hat da einer von euch schon Erfahrungen mit? Ich habe auf die schnelle leider nichts dazu gefunden, wie ich damit die Bandbreite begrenzen kann und meine Sorge ist, dass dann Quelle und Ziel komplett im I/O-Limit kleben und das System während der Zeit für die Anwender nicht nutzbar ist. Das möchte ich unbedingt vermeiden!
Kurz zur Einordnung: Das ganze ist ein privater Server, auf dem aber immerhin mehrere dutzend Menschen (Freunde und Familie) einen Account haben und das auch sehr aktiv nutzen.

Mfg Kae

 

[madmax2010]

Ich habe ZFS send durchaus schon genutzt. Sehr komfortabel

https://docs.oracle.com/en/operatin...4/manage-zfs/setting-io-bandwidth-limits.html

ich habe i.d.r immer limits auf dem dataset direkt gesetzt.

auf dem aber immerhin mehrere dutzend Menschen (Freunde und Familie) einen Account haben und das auch sehr aktiv nutzen.

aus dem Grund. Fair Use einfach per default

 

[TorenAltair]

das System während der Zeit für die Anwender nicht nutzbar ist. Das möchte ich unbedingt vermeiden!

In so einem Fall nimmst Du besser die Daten aus dem letzten Backup und synchronisierst dann nur noch die Änderungen.

 

[madmax2010]

naja, darum hat man ja ZFS

 

[TorenAltair]

ZFS

Verhindert aber ja nicht, dass wenn ich die Datenträger durch Kopieren an die Kotzgrenze bringe, dass das System nicht mehr ordentlich reagiert.

 

[Fortatus]

Oder zfs send mit pipeviewer kombinieren, um nur die Datenrate von send zu regeln und zu begrenzen:

Beispiel

zfs send -R oldpool@migration_oldpool_newpool | pv -L 10m | zfs recv -F newpool

 

[foofoobar]

Danke für den Tipp mit zfs send! Hat da einer von euch schon Erfahrungen mit? Ich habe auf die schnelle leider nichts dazu gefunden, wie ich damit die Bandbreite begrenzen kann und meine Sorge ist, dass dann Quelle und Ziel komplett im I/O-Limit kleben und das System während der Zeit für die Anwender nicht nutzbar ist.

Probiere es vorher mit IO-"Last" aus: "tar cf - /foo | cat > /dev/null" (ggf. mehrere davon laufen lassen)

Disclaimer: Ich habe was im Hinterkopf das das direkte angeben von /dev/null von tar erkannt wird oder wurde.

 

[Ack der III]

Alternativ oder sogar zusätzlich zu pv kannst du auch mit ionice die IO-Prioriät des Prozesses von zfs send heruntersetzen. Mit -c 3 versetzt du einen Prozess z.B. in die Idle-Klasse. Sprich die IO-Operationen des Prozesses werden nur ausgeführt, wenn sonst keine anderen Operationen anstehen. Dadurch sollte der Einfluss auf das Gesamtsystem minimiert werden.

 

[KaeTuuN]

https://docs.oracle.com/en/operatin...4/manage-zfs/setting-io-bandwidth-limits.html
ich habe i.d.r immer limits auf dem dataset direkt gesetzt.

Uhhhhh, das ist elegant! writelimit auf das Ziel und dann kann ich das mit zfs send langsam in sync bringen und dann zum Schluss einfach switchen! Wieder was gelernt!

Vielen dank auch an die anderen! pv und ionice werde ich mir auf jeden Fall auch merken, wenn ich das mal für nicht zfs Systeme mache! :-)

Mfg Kae

 

[foofoobar]

Uhhhhh, das ist elegant! writelimit auf das Ziel und dann kann ich das mit zfs send langsam in sync bringen und dann zum Schluss einfach switchen! Wieder was gelernt!

Wahrscheinlich lohnt das throttling nicht, mit nur einem job kriegt man die Queues nicht sonderlich voll.

Wenn du mal richtig darauf hauen willst:

find . -type f -print0 | xargs -0 -r -I{} -P20 sh -c 'cat "{}" > /dev/null'

-P ist die Härte des Baseballschlägers

 

[KaeTuuN]

Ich hab gestern noch einige Tests mit zfs send/recieve gemacht und mache die Migration jetzt schlicht damit. Obwohl der Durchsatz deutlich höher ist, als bei meiner Variante, und die Laufwerke an der Leistungsgrenze operieren, ist die gefühlte Geschwindigkeit für die Anwender identisch. Danke für den Tipp!

Mfg Kae

 

[foofoobar]

Ich hab gestern noch einige Tests mit zfs send/recieve gemacht und mache die Migration jetzt schlicht damit. Obwohl der Durchsatz deutlich höher ist, als bei meiner Variante, und die Laufwerke an der Leistungsgrenze operieren, ist die gefühlte Geschwindigkeit für die Anwender identisch. Danke für den Tipp!

Hier mal simulierte 1, 2, 20 Jobs die parallel auf eine Spindel zugreifen.
Solange die Queue (areq-sz) relativ leer ist ist auch die Latenz (await) niedrig und das Zeug was etwas von der Platte haben will bekommt das auch "schnell": (Dort liegen viele 20M Häppchen auf einem ext4)

$ sar --human -d 1 | awk 'BEGIN { len = i = 15 } $3 == "DEV" { if(i >= len) { print; i=0 } i++; next } $3 ~/^sdc/ { print }'
06:00:57 PM       DEV       tps     rkB/s     wkB/s     dkB/s   areq-sz    aqu-sz     await     %util
06:00:58 PM       sdc     54,00    216,0k      0,0k      0,0k      4,0k      0,14      2,65      2,8%
06:00:59 PM       sdc      0,00      0,0k      0,0k      0,0k      0,0k      0,00      0,00      0,0%
06:01:00 PM       sdc     73,00     17,9M      0,0k      0,0k    251,6k      0,08      1,12      8,0%
06:01:01 PM       sdc    699,00    169,6M      0,0k      0,0k    248,5k      1,06      1,51     84,4%
06:01:02 PM       sdc    861,00    210,0M      0,0k      0,0k    249,8k      1,21      1,40     99,6%
06:01:03 PM       sdc    896,00    218,4M      0,0k      0,0k    249,6k      1,15      1,28    100,0%
06:01:04 PM       sdc    926,00    228,2M      0,0k      0,0k    252,3k      1,21      1,30    100,0%
06:01:05 PM       sdc    896,00    218,9M      0,0k      0,0k    250,2k      1,19      1,33     99,2%
06:01:06 PM       sdc    935,00    228,3M      0,0k      0,0k    250,0k      1,17      1,25    101,2%
06:01:07 PM       sdc    879,00    217,4M      0,0k      0,0k    253,3k      1,14      1,29     99,2%
06:01:08 PM       sdc    898,00    222,7M      0,0k      0,0k    254,0k      1,21      1,34    100,4%
06:01:09 PM       sdc    915,00    226,2M      0,0k      0,0k    253,2k      1,25      1,37    100,0%
06:01:10 PM       sdc    709,00    175,7M      0,0k      0,0k    253,8k      0,91      1,29     78,0%
06:01:11 PM       sdc      0,00      0,0k      0,0k      0,0k      0,0k      0,00      0,00      0,0%
06:01:12 PM       sdc      0,00      0,0k      0,0k      0,0k      0,0k      0,00      0,00      0,0%
06:01:12 PM       DEV       tps     rkB/s     wkB/s     dkB/s   areq-sz    aqu-sz     await     %util
06:01:13 PM       sdc      0,00      0,0k      0,0k      0,0k      0,0k      0,00      0,00      0,0%
06:01:14 PM       sdc      0,00      0,0k      0,0k      0,0k      0,0k      0,00      0,00      0,0%
06:01:15 PM       sdc      0,00      0,0k      0,0k      0,0k      0,0k      0,00      0,00      0,0%
06:01:16 PM       sdc      0,00      0,0k      0,0k      0,0k      0,0k      0,00      0,00      0,0%
06:01:17 PM       sdc      7,00     52,0k      0,0k      0,0k      7,4k      0,10     13,57      3,6%
06:01:18 PM       sdc   1574,00      7,4M      0,0k      0,0k      4,8k      9,90      6,29     94,8%
06:01:19 PM       sdc   1754,00      6,9M      0,0k      0,0k      4,0k     14,31      8,16     99,6%
06:01:20 PM       sdc    359,00      1,4M      0,0k      0,0k      4,1k      2,26      6,30     20,0%
06:01:21 PM       sdc     61,00    584,0k      0,0k      0,0k      9,6k      0,15      2,49      6,4%
06:01:22 PM       sdc    178,00     44,0M      0,0k      0,0k    253,1k      0,51      2,86     19,6%
06:01:23 PM       sdc    789,00    194,1M      0,0k      0,0k    251,9k      3,01      3,82    101,2%
06:01:24 PM       sdc    827,00    205,0M      0,0k      0,0k    253,9k      3,01      3,64    100,0%
06:01:25 PM       sdc    838,00    207,4M      0,0k      0,0k    253,4k      2,75      3,28    100,0%
06:01:26 PM       sdc    746,00    182,8M      0,0k      0,0k    251,0k      2,97      3,98     99,6%
06:01:27 PM       sdc   1073,00    168,3M      0,0k      0,0k    160,6k     10,73     10,00    100,4%
06:01:27 PM       DEV       tps     rkB/s     wkB/s     dkB/s   areq-sz    aqu-sz     await     %util
06:01:28 PM       sdc    810,00    169,4M      0,0k      0,0k    214,1k      6,41      7,91    100,0%
06:01:29 PM       sdc    853,00    211,7M      0,0k      0,0k    254,1k      2,67      3,13    100,0%
06:01:30 PM       sdc    929,00    207,2M      0,0k      0,0k    228,4k      3,81      4,10    100,0%
06:01:31 PM       sdc    842,00    206,9M      0,0k      0,0k    251,6k      2,92      3,46     99,6%
06:01:32 PM       sdc    821,00    203,9M      0,0k      0,0k    254,3k      2,93      3,57    100,4%
06:01:33 PM       sdc    872,00    216,0M      0,0k      0,0k    253,7k      2,78      3,19    100,0%
06:01:34 PM       sdc    805,00    199,4M      0,0k      0,0k    253,6k      2,86      3,56    100,0%
06:01:35 PM       sdc    729,00    180,7M      0,0k      0,0k    253,9k      2,33      3,19     84,0%
06:01:36 PM       sdc      0,00      0,0k      0,0k      0,0k      0,0k      0,00      0,00      0,0%
06:01:37 PM       sdc     77,00    360,0k      0,0k      0,0k      4,7k      2,30     29,84     11,2%
06:01:38 PM       sdc   2238,00      9,6M      0,0k      0,0k      4,4k     37,88     16,93     85,2%
06:01:39 PM       sdc    500,00    108,4M      0,0k      0,0k    221,9k     21,78     43,56     85,6%
06:01:40 PM       sdc    515,00    141,3M      0,0k      0,0k    281,0k     33,59     65,23     99,2%
06:01:41 PM       sdc    461,00    142,7M      0,0k      0,0k    317,0k     32,22     69,89    100,8%
06:01:42 PM       sdc    414,00    137,9M      0,0k      0,0k    341,1k     25,05     60,50     98,8%
06:01:42 PM       DEV       tps     rkB/s     wkB/s     dkB/s   areq-sz    aqu-sz     await     %util
06:01:43 PM       sdc    609,00    157,7M      0,0k      0,0k    265,1k     42,10     69,13    101,2%
06:01:44 PM       sdc    768,00    192,7M      0,0k      0,0k    256,9k     26,67     34,72     99,2%
06:01:45 PM       sdc    827,00    204,7M      0,0k      0,0k    253,5k     28,56     34,54    100,8%
06:01:46 PM       sdc    754,00    190,5M      0,0k      0,0k    258,7k     34,06     45,17    100,0%
06:01:47 PM       sdc    762,00    191,5M      0,0k      0,0k    257,3k     28,08     36,86    100,0%
06:01:48 PM       sdc    805,00    198,4M      0,0k      0,0k    252,3k     28,65     35,59    100,0%
06:01:49 PM       sdc    674,00    172,3M      0,0k      0,0k    261,8k     35,16     52,17    100,0%
06:01:50 PM       sdc    737,00    182,7M      0,0k      0,0k    253,9k     29,07     39,45    100,0%
06:01:51 PM       sdc    759,00    188,6M      0,0k      0,0k    254,5k     27,82     36,66    100,0%
06:01:52 PM       sdc    769,00    192,6M      0,0k      0,0k    256,5k     38,15     49,61    100,0%
06:01:53 PM       sdc    794,00    198,5M      0,0k      0,0k    256,0k     25,20     31,74    100,0%
06:01:54 PM       sdc    760,00    190,6M      0,0k      0,0k    256,8k     35,69     46,96     99,6%
06:01:55 PM       sdc    838,00    209,8M      0,0k      0,0k    256,4k     33,22     39,64    100,4%
06:01:56 PM       sdc    751,00    190,6M      0,0k      0,0k    259,9k     34,02     45,30    100,0%
06:01:57 PM       sdc    804,00    202,8M      0,0k      0,0k    258,3k     29,78     37,03    100,0%