Fast-storage in neues Volume übertragen

[Rüdiger Kupper]

Im Zuge der Erweiterung auf 6 Gluster-Server werde ich das Volume fast-storage einmal in ein neues Volume kopieren. Ziel: Damit werden die letzten verbleibenden Inkonsistenzen zwischen den Servern behoben. (Die aind zwar nicht kritisch, aber nerven).

[Rüdiger Kupper]

Vorgehen

• gluster5/6 in storage pool aufnehmen
• bricks einrichten wie beschrieben
• auf gluster1–4 in VG b/c je zweites thin LV einrichten (mit anderem Namen, z.B. *-new), gleiche Größe (Overprovisioning!)und formatieren
• volume new-fast-storage einrichten über alle sechs gluster. (auf 1–4 on den new-bricks, auf 5/6 in den normalen bricks)

• auf einem geeigneten Rechner (backup?) beide fast-storages mounten
• kompletten Inhalt mit rsync rüberkopieren (richtige Parameter wählen, siehe altes Ticker?)

• vor dem finalen rsync
  • alle Clients runterfahren, (auch auf backup/paeml unmount?)
  • cloud stoppen
  • volume fast-storage stoppen, auf read-only setzen, starten

• finales rsync wie oben
• beide volumes stoppen
• umbenennen:
  • fast-storage -> old-fast-storage
  • new-fast-storage -> fast-storage
• neues fast-storage starten
• prüfen, ob mount auf clients/backup/paedml funktioniert

[Rüdiger Kupper]

Alternative:

• neues Volume erst nur auf gluster5/6 erstellen
• kopieren wie beschrieben
• altes Volume entfernen
• neues Volume auf gluster1–4 erweitern

[Rüdiger Kupper]

Variante 1 scheitert an zu wenig Platz in der c-Brick. Es hätte geklappt, wenn die Daten gleichmäßig auf die bricks verteilt wären (wie es sein sollte), doch die c-Brick ist deutlich mehr belegt als b. Die Sache wird allmählich besorgniserregend. Ein Rebalance möchte ich mit disesem angeaschlagenen Volume nicht wagen, damit nicht doch noch Datenverlust auftritt.

Also Alternative probieren. Zuvor am slow-storage testen.

[Rüdiger Kupper]

New-slow-storage und new-fast-storage sind eingerichtet auf gluster5,6.
Daten sind per rsync übertragen und können mit rsync aktualisiert werden:

root@proxmoxls2:~# df -h /mnt/gluster/new*
Dateisystem                Größe Benutzt Verf. Verw% Eingehängt auf
gluster1:/new-fast-storage  3,7T    1,4T  2,4T   37% /mnt/gluster/new-fast-storage
gluster1:/new-slow-storage   15T    565G   14T    4% /mnt/gluster/new-slow-storage
root@proxmoxls2:~# date; rsync -aAX --delete --numeric-ids -H  /mnt/gluster/fast-storage/ /mnt/gluster/new-fast-storage/; date
Sa 29. Apr 17:03:55 CEST 2023
So 30. Apr 02:07:05 CEST 2023
root@proxmoxls2:~# date; rsync -aAX --delete --numeric-ids -H  /mnt/gluster/slow-storage/ /mnt/gluster/new-slow-storage/; date
So 30. Apr 14:31:49 CEST 2023
So 30. Apr 14:47:25 CEST 2023

[Rüdiger Kupper]

Verrückt ist, dass das Aktualisieren der 1,4TB fast-storage 9 Stunden dauert, von 565GB slow-storage aber nur 16 Minuten!
Und dabei sind nicht mal viele Daten geflossen, denn kurz zuvor hatte ich die Befehle schonmal ausgeführt. Die Zeit wird also für das Vergleichen der Metadaten aller Dateien gebraucht.
Die Zahl der Dateien im fast-storage (Homeverzeichnisse) scheibt hier ausschlaggebend zu sein. Sind halt sehr viele.

[bau]

Herzlichen Glückwunsch!

[Rüdiger Kupper]

Danke!
new-slow-storage ist auch bereits erfolgreich auf alle sechs Server ausgedehnt. Das gleiche muss nun mit new-fast-storage geschehen. Im Gegensatz zum slow-storage könnte dabei aber der Speicherplatz knapp werden (ist derzeit zu etwa 40% gefüllt). Danach sollten dann also die Clients zuügig umgestellt werden, so dass sie die new-fast/slow-storage mounten und nicht mehr fast/slow-storage. Das muss auch auf allen Clients gleichzeitig erfolgen, damit nicht manche noch ihre Daten an die alte Stelle schreiben