paedml: Gluster schreibt massenweise Einträge in /var/log

[Rüdiger Kupper]

Siehe z.B. /var/log/glusterfs/home-teachers-.log.1

Es scheint zwei Arten von Einträgen zu geben:

1. Art

Sieht aus wie das Problem vom Montag, Dateien können nicht kopiert oder verschoben werden. Betroffen waren heute z.B. Nutzer ling und lehm. Wo waren die heute? (Ling lässt auf BK schließen).

@lehm

Hattest Du heute irgendwo an einem Schülerrechner das Problem, dass Dein Zweifaktor-Code nicht genommen wurde? Wenn ja, wo war das?

2. Art

Scheint auf abgefangene/optimierte rsync-Umbenennungen hinzuweisen, also wie hier beschrieben: ​https://developers.redhat.com/blog/2018/08/14/improving-rsync-performance-with-glusterfs
Fragt sich nur, wieso das alles im Log protokolliert wird?!

[Rüdiger Kupper]

Zu Art 1: Vermutlich ist doch noch igendwo mindestens ein Client übrig, der über NFS zugreift. (Z.B. BK -> prüfen)

Zu Art 2: Hier ist ein Bugreport, der danach aussieht, der ist aber von glusterfs v.3…
​https://bugzilla.redhat.com/show_bug.cgi?id=1318001

[bau]

Ja, das war ein BK-Rechner, den ich heute während der Besprechung mit dem Script glusterscript.sh verarztet habe. An dem war vorher LING und dann sicher LEHM dran.

[bau]

Wir sollten einfach mal den NFSd auf dem paedml abschalten - oder wird der noch irgendwo benutzt?

[Rüdiger Kupper]

Zu 2: Die Log-Einträge sind vom Level "INFO" und das scheint tatsächlich der Default-Level zu sein, der noch geloggt wird. Ich muss also rausfinden, wie man den Log-Level auf "WARNING" umstellt.

[Rüdiger Kupper]

Replying to bau:

Ja, das war ein BK-Rechner, den ich heute während der Besprechung mit dem Script glusterscript.sh verarztet habe. An dem war vorher LING und dann sicher LEHM dran.

Ah, okay, dann ist das schon mal geklärt.

[Rüdiger Kupper]

Nutzer jetterjon aus der 6c saß demnach heute auch an einem Rechner, der noch NFS macht. -> Computerraum?

[Rüdiger Kupper]

Okay, der Log-Level wird beim Mount-Befehl gesetzt. Habe ich in der fstab auf paedml überall hinzugefügt:

# Gluster-Volumes                                                                                                                                     
#gluster1:/fast-storage /mnt/gluster/fast-storage glusterfs acl,_netdev,nofail,log-level=WARNING 0 0                                                 
#gluster1:/slow-storage /mnt/gluster/slow-storage glusterfs acl,_netdev,nofail,log-level=WARNING 0 0                                                  

# Direkte Mounts der Verzeichnisse students, teachers, share                                                                                          
gluster1:/fast-storage/students    /home/students/     glusterfs acl,_netdev,nofail,log-level=WARNING 0 0
gluster1:/fast-storage/teachers    /home/teachers/     glusterfs acl,_netdev,nofail,log-level=WARNING 0 0
gluster1:/slow-storage/share       /home/share         glusterfs acl,_netdev,nofail,log-level=WARNING 0 0

Wir wir das nun im laufenden Betrieb ändern, weiß ich aber nicht. Geht das mit einem remount?

[Rüdiger Kupper]

Und vermutlich müssen wir erst wieder die bind-Mounts von außen nach innen abbauen …
Ich wage es gar nicht zu sagen: Ein Reboot des paedml würde es auch tun :-D…

[Rüdiger Kupper]

Vermutlich sollten wir den Loglevel auch auf den Clients auf "WARNING" setzen. Aber da passieren ja nicht so viele rsyncs … Ich mache die Änderung im Jochen-Image.

[Rüdiger Kupper]

Also, nach einem Neu-Mount oder Reboot sollten die vielen Info-Messages in den Logs weg sein. Aber ich mache da jetzt nichts ohne baus Zustimmung :-D.

[Rüdiger Kupper]

Replying to bau:

Wir sollten einfach mal den NFSd auf dem paedml abschalten - oder wird der noch irgendwo benutzt?

Ja, hierfür:

/var/cache/sophomorix/tasks              /nfsexport/tasks              none      bind  0       0
/home/ftp/Scans                          /nfsexport/home/ftp/Scans     none      bind  0       0
/home/samba/cds                          /nfsexport/home/cds           none      bind  0       0
/var/www/interaktiv/kepler_login/bilder  /nfsexport/bilder             none      bind  0       0
/home/ftp                                /nfsexport/ftp                none      bind  0       0

Aber die Exports von /home/{teachers,students,share} könnten wir entfernen.

[Rüdiger Kupper]

Replying to kup:

Nutzer jetterjon aus der 6c saß demnach heute auch an einem Rechner, der noch NFS macht. -> Computerraum?

Ah, nein, der stand bestimmt an einer Arbeitsstation! Haben wir die vergessen?

[Rüdiger Kupper]

Replying to kup:

Okay, der Log-Level wird beim Mount-Befehl gesetzt. Habe ich in der fstab auf paedml überall hinzugefügt:
Wir wir das nun im laufenden Betrieb ändern, weiß ich aber nicht. Geht das mit einem remount?

Ich habe im Manual gelesen, man kann den Loglevel der Clients auch vom Server aus steuern, das werde ich mal probieren. Dann können wir uns die Mountoptionen bei jedem Client sparen (und den Neustart) ;-).

[bau]

Angekündigte Downtime des Paedml am Freitag - verbunden mit dem resize der LV vg—home und vg—var:

• Paedml herunterfahren
• lv mit KPartX auf dem ProxMoxPaedml verfügbar machen
• lvreduce von vg—home von 400GB auf 100GB
• lvextend von vg—var von 400GB auf 600GB
• kPartX-Volume wieder entfernen (Macht der LVM das automatisch mit? Ansonsten muss der Proxmox auch noch neu starten)
• Paedml neu starten

[Rüdiger Kupper]

Wichtig: Vor dem lvreduce muss das ext4-Dateisystem im LV auf die neue Größe reduziert werden – sonst ist das danach zerstört.
Das geht mit resize2fs. Alternativ: der lvreduce-Befehl hat auch eine Option, dafür, dass er das selbst erledigt: "--resizefs". Die habe ich immer benutzt und es hat bisher immer gut funktioniert.

[bau]

lvreduce hat etwa eine dreiviertel Stunde gedauert - lvresize auf 600G ging recht schnell.
Problem: die glusters sind nicht alle korrekt eingebunden:

• /home/students läuft
• /home/share hat Probleme
• /home/teachers hat Probleme

[bau]

OK, students hatte den gleichen Fehler - habe nun alle drei erstmal mit umount und anschließendem mount zum Laufen bekommen - Aktion ist somit abgeschlossen.