Vermehrte Netzwerk-Hänger

[Rüdiger Kupper]

In den letzten Tagen wirkt das Netzwerk langsamer als zuvor. Logins dauern oft wieder im Minutenbereich. Selbst während ich dieses Ticket schreibe (einfache HTML-Maske!), hängt der Cursor immer wieder für ein paar Sekunden. Webseiten mit mehreren Elementen brauchen gefühlt lange zum Laden.

Woran könnte das liegen?

[bau]

Bei meinen Anmeldungen heute ging während der Anmeldung der LOAD auf bis zu 3,7 - nach der Anmeldung war alles wieder normal. Während des Schreibens eines Tickets greift er TRAC nichta uf das Netzwerk zu - wieso soll das ein Netzwerkproblem sein?

[Rüdiger Kupper]

Ich glaube, dass Firefox während ich schon getippt habe, noch damit beschäftigt war, die Seite zu laden. Da ist ja nicht viel drauf außer den Trac- und Keplerlogos und Text. Doch das hat offenbar so lange gedauert, dass ich in der Zwischnzeit die Hälfte des Textes tippen konnte.

[Rüdiger Kupper]

Replying to bau:

Bei meinen Anmeldungen heute ging während der Anmeldung der LOAD auf bis zu 3,7

Da ich den 64bit-Client ganz neu aufgesetzt habe, kann ich jetzt auch eindeutig sagen, wer der Übeltäter ist: Der Login ging die ganze Zeit wie geschmiert. Auch noch, nachdem ich das Linuxmuster-Paket 'linuxmuster-cleint-auth' installiert hatte (LDAP-Anbindung an paedml).
Auch das Paket 'linuxmuster-client-shares' führte zu keinen Problemen (das mountet die CIFS-shares über pam.mount beim Login).
Die Login-Hänger fingen an mit der Installation von 'linuxmuster-client-profile'. Das ist das Paket, das beim Login die Daten des Vorlagen-Nutzers rüberkopiert. Und es implementiert die Verlinkung der Config-Dateien aus dem 'einstellungen'-Verzeichnis auf dem Server ins lokale Homeverzeichnis. Ich denke, dass es dieser Mechanismus ist, der sich irgendwo verschluckt und auf ein Timeout wartet.
Vielleicht probiere ich mal, unsere Linkstruktur zu vereinfachen. Wir haben ja eine ganze Linkkette, um die Konfigurationen unter Linuxmuster und LTSP gleichermaßen verwenden zu können.

[bau]

Vorschlag:
Wir verzichten wieder auf diesen Mechanismus - ich finde, der hat mehr Probleme gemacht als dass er was bringt. Wenn wir wie früher die HomeVZ der User an die richtige Stelle einhängen, dann reicht das doch.
Dann sollten wir uns auch gleich überlegen, wie wir die Tauschlaufwerke einhängen, denn das sollte ja auch mit dem User geschehen, wenn wir das in eine Struktur mounten können (z.B. /tauschen/username/...) dann sollten nach meinem Dafürhalten auch Mehrfachanmeldungen problemlos gehen.

[bau]

Bei der Recherche zu "Subnetting und VLANs mit linuxmuster.net 6.1" (siehe ​https://www.linuxmuster.net/wiki/dokumentation:addons:subnetting:start) bin ich darauf gestoßen, dass eventuell unser grünes Netz ungewollt ziemlich groß geworden ist und deshalb ab und zu Netzwerkhänger auftreten. Problem könnte sein, dass ich allen Switchen VLAN-interfaces im grünen VLAN mir IP's aus dem grünen Netz gegeben habe. Da auch Level 2 Switche im Rennen sind (nur ISO/OSI Schicht 2 mit MAC möglich, keine IP-Identifizierung auf Schicht 3 möglich) könnten Pakete unnötig weit im Netzwerk verteilt werden.

Abhilfe:

• Einrichtung eines eigenen VLAN für das Switchmanagement mit eigenen IP-Adressen
• Einrichtung von Routen zu diesem VLAN, so dass es vom Server und aus dem Lehrernetz erreichbar ist

[Rüdiger Kupper]

Replying to bau:

Bei der Recherche zu "Subnetting und VLANs mit linuxmuster.net 6.1" (siehe ​https://www.linuxmuster.net/wiki/dokumentation:addons:subnetting:start) bin ich darauf gestoßen, dass eventuell unser grünes Netz ungewollt ziemlich groß geworden ist und deshalb ab und zu Netzwerkhänger auftreten. Problem könnte sein, dass ich allen Switchen VLAN-interfaces im grünen VLAN mir IP's aus dem grünen Netz gegeben habe. Da auch Level 2 Switche im Rennen sind (nur ISO/OSI Schicht 2 mit MAC möglich, keine IP-Identifizierung auf Schicht 3 möglich) könnten Pakete unnötig weit im Netzwerk verteilt werden.

Das klingt doch wenigstens mal nach einer Arbeitshypothese!

Abhilfe:

• Einrichtung eines eigenen VLAN für das Switchmanagement mit eigenen IP-Adressen
• Einrichtung von Routen zu diesem VLAN, so dass es vom Server und aus dem Lehrernetz erreichbar ist

Bin gespannt, wie sich das auswirkt!

[Rüdiger Kupper]

Eben gerade hat lat minutenlang darauf gewartet, dass einfach nur das Horde-Interface im Browser aufging. Als es dann da war, war es unbenutzbar (linker Teil des Fensters doppelt, dafür hat der rechte gefehlt).

[bau]

Nun gut, die Switche, die kein VLAN 7 (grünes Netz) anbieten haben jetzt IP's aus dem von mir erzeugten Management-VLAN 999 (IP 172.16.0.0/24) - somit wird unerwünschter Traffic hier schonmal total verhindert.

Ich habe erste Tests zu Subnetting gemacht, das ist gernicht besonders schwer, die Idee:

• nahe gelegene Bereiche werden in ein Subnet zusammengefasst (z.B. oberer PC-Raum, U1, U2, U3, U4, ...)
• am besten so, dass das VLAn nur an einem Switch anliegt
• der Traffic im grünen Netz wird damit nicht im ganzen Netz sondern nur im betroffenen Subnetz verteilt
• einer der Layer-3-Switche routet das VLAN, hier kann durch ACL festgelegt werden, welche Pakete wohin dürfen (das ist das Default-Gateway für dieses SubNetz)
• mindestens ins Servernetz (10.32.1.0/24) muss geroutet werden

Das 10.32.X.Y-Netz muss also in Subnetze geteilt werden, die Musterlösung macht das so:

• 10.32.Subnetz.Rechner
• damit müssen wir unser schönes System mit den Raumnummern in der IP aufgeben

[bau]

Ich habe gerade in U1 einen Cisco 4003 mit einer WS-X-4448 (48x GBit) in Betrieb genommen.
Dadurch sparen wir drei kleinere Switche ein, das Gerät ist auch nicht besonders viel lauter, als der 3548 (2x GBIC / 48x 100MBit), weil per VTP alle VLANs auf dem Switch verfügbar sind. Hier können wir auch das Subnetting testen.

Ich sitze grade am Client in 5.05, der Login geht kein bisschen schneller, als vorher, die Load ging diesmal auf 4.27 hoch, erst als sie wieder auf 2 gesunken war, habe ich meine Seitenleiste bekommen. Verbindung zum Server ist mit dem neuen Switch gigantisch (Gigabit-NIC an GigabitPort über 3GBit Trunk-Verbindung zum zentralen Switch) - zwischendurch hat der Firefox mal nicht mehr reagiert (wurde sogar ausgegraut), die Netzverbindung stand aber - da ist also irgendwas am Client nicht in Ordnung.

Wie gesagt: Ich schlage vor, den linuxmuster-client wieder abzuschaffen und die HomeVZ der User entweder per NFS oder per CIFS an die korrekte Stelle zu mounten.

[Rüdiger Kupper]

Können wir durchaus mal probieren. Wenn wir damit Erfolg haben, können wir das ja den LM-Leuten ans Herz legen. Vielleicht geben die das CIFS ja doch irgendwann auf.

[bau]

OK, da kommt aber etwas Arbeit auf uns zu, denn NFS ist ja nur mit Kerberos sicher zu kriegen.
Zum Testen ist NFS aber ohne Sicherheit auch ganz gut zu nutzen

[Rüdiger Kupper]

Genau. Ich mache das christof-Image jetzt erstmal wie bisher fertig, danach probieren wir mal an einem Rechner die unverschlüsselte NFS-Lösung.

[bau]

Sodele - im Stützpunkt im U4 (Raum 5.47) schnurrt jetzt auch ein Cisco 4003.
Verbindung zum zentralen cisco0027 per 4GBit Glasfaser-Trunk.
Alle Clients sind nun über das 48Port GBic-Modul angebunden.
Auch hier konnte ich beobachten, dass der WLAN AP sofort schneller reagiert hat.
Ich glaube, die Umstellung lohnt sich!

[Rüdiger Kupper]

Super, es geht aufwärts!

[Rüdiger Kupper]

Ich konnte heute endlich den Übeltäter einkreisen: Es ist die Verlinkung des lokalen .config-Verzeichnsses ins Homeverzeichnis des Nutzers auf dem Server (über den Linuxmuster-profile-Mechanismus.)
Im config-Verzeichnis liegen alle persönlichen Einstellungen des Nutzers. Die meisten davon sthen ibzwischen in einer Datenbank namens user.conf, die dort liegt. Unmittelbar nach dem Einloggen wollen natürlich allerlei Prozesse auf diese DB zugreifen. (Daher hat man sich ja gerade für eine Datenbank entschieden, weil die für viele gleichzeitige Lesezugriffe optimiert ist.) Bei uns liegt diese DB nicht nur im Netzwerk (dumm für viele gleichzeitige Zugriffe), sondern das Netzwerk-Share wird auch erst beim Login des Nutzers gemountet. Das dauert ein bisschen, und in dieser Zeit verschlucken sich die Prozesse, die darauf zugreifen wollen, vor allem wohl Nautilus. Wir haben es also mit einer Race-Condition zu tun. Daher klappt der Login auch manchmal flotter und manchmal dauert's ewig. Je nachdem, wie schnell das Mounten klappt und welche Prozesse gegenseitug auf die Config und auf einander warten.
Ich schätze, der CIFS-Treiber kommt nicht gut mit den Dateianfragen an eine noch nicht ganz vergügbare Datei klar.

Abhilfe

1. Das config-Verzeichnis nicht ins Netzwerk verlinken. Der Login dauert dann akzeptabel lang, etwa 10 Sekunden. Alle Einstellungen des Nutzers gelten nur für diesen speziellen Rechner und gehen beim nächsten Sync verloren. -- unbefriedigend für die Nutzer.
2. Lightdm beibringen, die Sitzung erst Hubstarten, wenn der CIFS-Daemon die Verbindung wirklich hergestellt hat. -- Das fang ich gar nicht erst an, das müssten die LML-Entwickler machen.
3. Den LML-Mechanismus gar nicht verwenden. Stattdesden den gesamten Homeverzeichnis-Baum auf einmal beim Boot über NFS mounten. Dann stehen die Homeverzeichnisse der Nutzer beinahe Login bereits zur Verfügung. So haben wir es jahrelang auf den LTSP-Servern praktiziert und so läuft es in Millionen von Linux-Netzwerken.

Ich bin für Methode 3. Sie löst viele Probleme und hat nur begrenzte Nachteile:

• NFS ist nicht sehr sicher, solange es nicht verschlüsselt ist. Können wir aber dran arbeiten.
• Nutzer können gegenseitig ihre Homeverzeichnisse sehen. Lässt sich über richtige Wahl der Berechtigungen lösen.

Dafür:

• entfällt das lästige Home_auf_Server-Gedöns
• können den Nutzern keine Dateien mehr verloren gehen, weil sie sie zufällig in lokalen Home abgespeichert haben.
• geht der Login schneller
• entfällt das aufwändige Warten des Verlinkmechanismus'
• entfällt komplett das blöde CIFS mit all seinen Problemen (wie fehlerhaften Rechteabbildungen, fehlender Case-Sensitivität, etc.)

[bau]

Ich bin absolut dafür (also für Lösung 3)!
Wäre ein Workaround nach 1. schnell umzustellen?
Bis zu den Somerferien würden wir die nicht vorhandenen Einstellungen eher ertragen, als die ewige Loginzeit.

[Rüdiger Kupper]

Ja, das ginge von heute auf morgen. Habe ich auch schon überlegt.

[bau]

Prima, dann lasse ich mich mal von den schnellen Anmeldungen überraschen :-)

[Rüdiger Kupper]

Ab morgen liegen die conf-Verzeichnisse überall lokal.
Für das christof-Image versuchen wir die Einbindung per NFS.