JARVIS
Eingesetzt wird GlusterFS in der Version 3.4.2 mit einem Distributed Filesystem über 3 Bricks. Alle Bricks haben die selbe Größe und wurden bisher, wie erwartet, beschrieben. Normalerweise sollte Gluster die Dateien über die Bricks verteilt schreiben und dabei darauf achten, dass die zu kopierende Datei nicht die Größe des freien Speichers eines Bricks überfüllt. Sollte dies der Fall sein, sollte automatisch ein passender Brick gewählt werden.
Nun nähert sich das Volume (vol1) dem Ende ist fast voll. Brick 1 hat noch ca. 55,8GB, Brick 2 ca. 10GB und Brick 3 nur noch 44,6GB frei. Nun wurden weitere Daten kopiert, wobei hierunter eine eine einzelne Datei mit über 41GB war. Leider wurde diese auf Brick 2 versucht zu schreiben, was in diesem Moment jedoch nur noch 10GB frei hatte und der Kopiervorgang fehlschlug.
1. Überprüfung des Volumes
# gluster volume info vol1
Volume Name: vol1 Type: Distribute Volume ID: 05bca65e-8a7f-4647-804a-7e1ed3f8b685 Status: Started Number of Bricks: 3 Transport-type: tcp Bricks: Brick1: 192.168.0.41:/media/node01/vol1 Brick2: 192.168.0.21:/media/node02/vol1 Brick3: 192.168.0.43:/media/node03/vol1 Options Reconfigured: auth.allow: 192.168.0.* cluster.min-free-disk: 500MB
Soweit so gut, die Option cluster.min-free-disk ist auch nicht zu hoch gesetzt, sodass es eigentlich funktionieren sollte. Noch eine Überprüfung der einzelnen Bricks:
2. Überprüfung der Free Inode und einzelnen Brickeigenschaften
# gluster volume status vol1 detail
Status of volume: vol1 ------------------------------------------------------------------------------ Brick : Brick 192.168.0.41:/media/node01/vol1 Port : 49152 Online : Y Pid : 2929 File System : ext4 Device : /dev/md2 Mount Options : rw,noatime,user_xattr,barrier=1,stripe=512,data=ordered Inode Size : 256 Disk Space Free : 55.8GB Total Disk Space : 10.9TB Inode Count : 11426432 Free Inodes : 11072722 ------------------------------------------------------------------------------ Brick : Brick 192.168.0.21:/media/node02/vol1 Port : 49154 Online : Y Pid : 2834 File System : ext4 Device : /dev/md2 Mount Options : rw,noatime,user_xattr,barrier=1,stripe=512,data=ordered Inode Size : 256 Disk Space Free : 10.0GB Total Disk Space : 10.9TB Inode Count : 11426432 Free Inodes : 11064647 ------------------------------------------------------------------------------ Brick : Brick 192.168.0.43:/media/node03/vol1 Port : 49152 Online : Y Pid : 2841 File System : ext4 Device : /dev/md2 Mount Options : rw,noatime,user_xattr,barrier=1,stripe=512,data=ordered Inode Size : 256 Disk Space Free : 44.6GB Total Disk Space : 10.9TB Inode Count : 11426432 Free Inodes : 11083681
Auch hier sieht alles gut aus. Da ich zwischenzeitlich keine Infos aus der Community erhalten hatte, machte ich mich an den Befehl Fix-Layout:
3. mit Fix-Layout soll die Gluster-Struktur korrigiert werden:
# gluster volume rebalance vol1 fix-layout start (force)
volume rebalance: vol1: success: Starting rebalance on volume vol1 has been successful.
ID: 73f7bcf9-5f5c-4857-9edd-84f1f4d68f30
Kontrolle des Status:
# gluster volume rebalance vol1 status
Node Rebalanced-files size scanned failures skipped status run time in secs --------- ----------- ----------- ----------- ----------- ----------- ------------ -------------- localhost 0 0Bytes 0 0 0 in progress 169.00 localhost 0 0Bytes 0 0 0 in progress 169.00 localhost 0 0Bytes 0 0 0 in progress 169.00 192.168.0.21 0 0Bytes 0 0 0 in progress 169.00 volume rebalance: vol1: success:
Ok soweit gut, danach dann noch ein Rebalance der einzelnen Bricks und der Neuverteilung des freien Speichers:
4. Gluster soll den freien Bereich auf den Bricks neu sortieren
# gluster volume rebalance vol1 start
volume rebalance: vol1: success: Starting rebalance on volume vol1 has been successful. ID: 0bf73f9c-0a84-4b12-a37e-1ed8c667758a Every 10,0s: gluster volume rebalance vol1 status Tue Feb 4 15:19:33 2014 Node Rebalanced-files size scanned failures skipped status run time in secs --------- ----------- ----------- ----------- ----------- ----------- ------------ -------------- localhost 0 0Bytes 72 0 0 in progress 22.00 localhost 0 0Bytes 72 0 0 in progress 22.00 localhost 0 0Bytes 72 0 0 in progress 22.00 192.168.0.41 0 0Bytes 431 0 0 in progress 22.00 volume rebalance: vol1: success:
Nun noch den Status prüfen:
# gluster volume rebalance vol1 status
Node Rebalanced-files size scanned failures skipped status run time in secs --------- ----------- ----------- ----------- ----------- ----------- ------------ -------------- localhost 525 476.2MB 330361 0 52227 completed 9554.00 localhost 525 476.2MB 330361 0 52227 completed 9554.00 localhost 525 476.2MB 330361 0 52227 completed 9554.00 192.168.0.41 2712 115.7GB 333092 0 29084 completed 12808.00 volume rebalance: vol1: success:
Obiges ist ein nicht zum Zusammenhang passendes Beispiel. Der freie Speicher wurde tatsächlich so aufgeteilt, dass jeder Brick nahezu die selbe Größe an freien Speicher hat. Abschließend dannn ein erneutes kopieren der 41GB Datei und siehe da es klappt. Im übrigen muss nur ein Rebalance ausgeführt werden, also kein fix-layout zuvor. Bei mir kam es jedoch mit sinkendem freien Speicher immer wieder zu diesem Fehler, also das der falsche Brick angesteuert wurde. Mal Brick 3, dann Brick 2, sodass ich immer eine rebalance ausführen musste.
Eine abschließende Lösung habe ich leider noch nicht.
Interessiert in verschiedenste IT Themen, schreibe ich in diesem Blog über Software, Hardware, Smart Home, Games und vieles mehr. Ich berichte z.B. über die Installation und Konfiguration von Software als auch von Problemen mit dieser. News sind ebenso spannend, sodass ich auch über Updates, Releases und Neuigkeiten aus der IT berichte. Letztendlich nutze ich Taste-of-IT als eigene Dokumentation und Anlaufstelle bei wiederkehrenden Themen. Ich hoffe ich kann dich ebenso informieren und bei Problemen eine schnelle Lösung anbieten. Wer meinen Aufwand unterstützen möchte, kann gerne eine Tasse oder Pod Kaffe per PayPal spenden – vielen Dank.