fast-storage auf restliche gluster ausdehnen

[Rüdiger Kupper]

Vorgehen wie in #4873 beim slow-storage.
Zuvor sicherstellen, dass auf den SSD genug Speicher frei ist, um eine zweite Kopie aller Daten aufzunehmen.

[Rüdiger Kupper]

Ich habe gestern mal die ~/.cache/-Verzeichnisse der Nutzer gelöscht, nun ist fast-storage zu 34% gefüllt, damit sollten wir für eine Kopie auf der sicheren Seite sein. Aber noch einmal die einzelnen Bricks genau anschauen, die sind nicht unbedingt gleichmäßig gefüllt.

[Rüdiger Kupper]

Okay, habe den Füllstand der bricks angeschaut. Nach der Datenübertragung von gluster5,6 auf gluster1,2,3,4 wäre demnach die LVM-Volumes zu max. 76% gefüllt. Wenn nicht wieder ein Schüler eine 300GB-Datei ins sein Home schreiben lässt, dann müsste uns das genug Luft lassen. Keine Ahnung, wie lange das Übertragen dauern wird, könnten mehrere Tage sein. Ich werfe den Prozess heute Nachmittag mal an. Vorausgesetzt es läuft so problemlos wie beim new-slow-storage, dann könnten wir zu den finalen Schritten übergehen (letzter Sync und alle Clients umstellen).

[Rüdiger Kupper]

Vorgehen (analog zu #4873):

• sicherstellen, dass die nötigen Bricks auf gluster1-4 existieren
• sicherstellen, dass die Bricks keinerlei Daten (mehr) enthalten

auf einem gluster:

# gluster volume add-brick new-fast-storage replica 3 \
gluster1:/mnt/gluster/b-new/brick gluster3:/mnt/gluster/b-new/brick \
gluster2:/mnt/gluster/b-new/brick gluster4:/mnt/gluster/b-new/brick \
gluster1:/mnt/gluster/c-new/brick gluster3:/mnt/gluster/c-new/brick \
gluster2:/mnt/gluster/c-new/brick gluster4:/mnt/gluster/c-new/brick \
force

[Rüdiger Kupper]

Ergebnis:

root@gluster1:~# gluster volume info new-fast-storage
 
Volume Name: new-fast-storage
Type: Distributed-Replicate
Volume ID: d8ed8e70-3278-4f81-83c0-6800957c3151
Status: Started
Snapshot Count: 0
Number of Bricks: 4 x 3 = 12
Transport-type: tcp
Bricks:
Brick1: gluster5:/mnt/gluster/b-new/brick
Brick2: gluster1:/mnt/gluster/b-new/brick
Brick3: gluster3:/mnt/gluster/b-new/brick
Brick4: gluster6:/mnt/gluster/b-new/brick
Brick5: gluster2:/mnt/gluster/b-new/brick
Brick6: gluster4:/mnt/gluster/b-new/brick
Brick7: gluster5:/mnt/gluster/c-new/brick
Brick8: gluster1:/mnt/gluster/c-new/brick
Brick9: gluster3:/mnt/gluster/c-new/brick
Brick10: gluster6:/mnt/gluster/c-new/brick
Brick11: gluster2:/mnt/gluster/c-new/brick
Brick12: gluster4:/mnt/gluster/c-new/brick
Options Reconfigured:
performance.client-io-threads: off
storage.fips-mode-rchecksum: on
transport.address-family: inet
nfs.disable: on

[Rüdiger Kupper]

Gluster markiert nun alle Dateien als "zu heilen" und überträgt sie so in die neuen Bricks.

[Rüdiger Kupper]

Derzeit scheint der Vorgang im Bereich von 200.000 zu heilender Dateien zu stagnieren. Die Zahl nimmt mal zu und mal ab.

Beobachten auf einem beliebigen gluster mit

# gluster volume heal new-fast-storage statistics heal-count

[Rüdiger Kupper]

Vorgang wurde heute Nachmittag abgeachlossen.

Notiz:
Der Prozess stagnierte zuerst, nachdem alle Daten aus den b-Bricks übertragen waren. Nach einem stop/start des Volumes lief der Prozess dann für die c-Bricks. Der Effekt ist mir schon bei früheren Versuchen azfgefallen. Müsste ein Bug in Gluster sein, aber offenbar unkritisch.

[Rüdiger Kupper]

Nun verbleibt noch, an einem freien WE alle Clients abzuhängen, die neuen Volumes ein letztes mal mit rsync zu aktuaüisieren u.d auf allen Clients in der fstab die neuen Volumes einzutragen.