Langsamer Login aus dem Lehrerzimmer -- Switch resetten?

[Rüdiger Kupper]

Ich beobachte bei allen Geräten aus dem Lehrerzimmer im Lehrernetz sehr lange Loginzeiten (2 Minuten).

• Direkt an ltspl1
• an Clients an ltspl1

• Über VNC an ltspl2 geht der Login problemlos, so wie immer.
• Aber: Boote ich meinen Client von ltspl2, dauert der Login wieder.

Da der Login über VNC absolut problemlos geht kann das Problem nicht an den Servern liegen.
Ich vermute eher, dass der Switch im Lehrerzimmer hängt, doch leider weiß ich nicht, wie man den neu startet. Weder weiß ich, wo der Schalter ist, noch wo das Stromkabel hinführt, und leider bin ich auch zu klein, um es herauszufinden :-).

Bitte mal den Switch resetten und sehen, ob's dann tut. Wenn das die Ursache ist, sollte ins LZ ein neuer Switch.

[Rüdiger Kupper]

Kollege kroe berichtet heute wieder von fehlendem Ton.

Eben sitze ich unten in der NwT und habe nacheinander meinen Client von allen Schülerservern gebootet.

Ergebnis:

• ltsp{1,3,5,6,8}: Reibungsloser Login, besser geht's nicht
• ltsp{2,4}: Zwei Minuten Loginzeit, genau so wie heute auch vom Lehrerzimmer ins Lehrernetz

Aber: Nach dem Login funktionierte in jedem Fall der Ton.

@bau

Probleme vom LZ, 2.U und 4.U, was sagt dir das über den betroffenen Switch?

@kroe

In welchen U hattest Du heute den fehlenden Ton?

[bau]

Lehrerzimmer: Gleicher Phänomen wieder wie in den Ferien - lightdm spinnt total rum. Erst nachdem ich auch noch das Paket network-manager deinstalliert hatte funktionierte der lightdm wieder normal mit schnellem Login - irgendwie hängt der Login vom Networkmanager ab!

[bau]

ltsp4: kein Login am Server möglich - lightdm hängt total - es geht nichts. Deinstallation des nm hilft nichts - komische Sache!

Vorschlag für Weiteres Vorgehen:

• alle Clients auf ltsp8 umhängen
• proxmoxltsp4 aufsetzen
• Backup von ltsp8 einspielen und anpassen
• Clients hälftlich auf ltsp4 (virtuell) umhängen

[bau]

OK, Clients von ltsp4 sind nun alle auf ltsp8 gehängt.
Morgen werde ich die zweite SSD in den ltsp4 hängen und proxmox draufspielen.

Hast du schon ein Script, welches die Anpassungen nach dem Restore macht?

[Rüdiger Kupper]

Glaube ich nicht.

• Wie erklärst Du Dir, dass der Login per VNC am ltspl2 innerhalb von

drei Sekunden geht, aber von einem Client im LZ, der von ltspl2 gebootet
ist, hängt? Das hängt ja logischerweise nicht mit der Software auf dem
Server zusammen, ob lightdm oder sonstwas, sonst müsste es beide
Loginwege betreffen.

• Wie erklärst Du Dir, dass der Login auch direkt anm ltspl1 hängt,

obwohl er direkt an ltspl2 zügig geht? Das hängt doch damit zusammen,
wie der ltspl1 an's Netzwerk angehängt ist. Wo steht denn proxmoxltspl2
eigentlich, udn wie ist er an's Netzwerk angeschlossen?

Lehrerzimmer: Gleicher Phänomen wieder wie in den Ferien - lightdm spinnt
total rum. Erst nachdem ich auch noch das Paket network-manager
deinstalliert hatte funktionierte der lightdm wieder normal mit schnellem
Login - irgendwie hängt der Login vom Networkmanager ab!

Ja, vermutlich, aber der Grund ist doch nicht der Netzwerk*manager*,
sondern, das *Netzwerk*, auf das der Manager zugreift! Logisch, wenn Du
das Paket deinstallierst, das Netzwerkzugriffe macht, ist das Problem
scheinbar erstmal verschwunden, doch damit behebst Du ein Symptom, nicht
die Ursache.
Oder wieso läuft der Login per VNC an ltspl2 flüssig, obwohl ich dort
keins der Pakete deinstalliert habe? Dort läuft alles, Netzwerkmanager,
Zeitgeist, etc, und man kann sich innerhalb von drei Sekunden einloggen.
Erst, wenn man aus dem LZ vom ltspl2 bootet, fangen die Probleme an. Das
ist doch kein Softwareproblem des ltspl2...

Grüße,
Rüdiger

[bau]

• proxmoxltspl2/ltspl2 hängen über 100MBit in der Chemie am Netz
• alle anderen Server hängen per Gigabit-Anbindung am Netz
• Umzug des ltsp4 von U4 nach U1 brachte keinerlei Verbesserung Da standen dann ltsp1 und ltsp4 nebeneinander am gleichen Switch (also vollkommen gleiche Netzanbindung), auf ltsp1 ging alles auf ltsp4 nicht, nach dem Plattentausch das gleiche nur andersrum. Es liegt also logischerweise an irgendwas am Server!
• ltsp6 läuft virtuell bislang ohne Probleme
• ltspl2 ist auch virtuell - hier managed der drunterliegende proxmox die Netzzugriffe, der ProxMox bringt seine eigenen Netzwerktreiber mit!
• am ltsp2 sitze ich grade - ein Login ging weder für linadmin noch für mich, mit einem service lightdm stop habe ich den Server abgeschossen (keine Tastatureingabe mehr möglich), nach einem reboot geht jetzt wieder alles

neuer Test:
ltsp4 hat ja keine Funktion mehr - ich hänge den jetzt mal an 100MBit - mal sehen :-)

[bau]

Test hat ergeben:

• Reboot alleine machte gar nichts - Loginprobleme bleiben bestehen
• Umstecken des Netzwerkkabels in 100MBit / Reboot / schnelle Anmeldung
• Zurückstecken auf 1GBit / immernoch schnelle Anmeldung
• Reboot / immernoch schnelle Anmeldung
• Heißt also: Irgendwas stimmt mit dem Netzwerkkartentreiber nicht!
• Fazit: Server virtualisieren, Proxmox hat wie gesagt seine eigenen Netzwerkkartentreiber dabei - die wissen wahrscheinlich warum - beim Installieren wird zunächst die Debian-Firmware deinstalliert und die ProxMox-Firmware installiert. Mach ich wahrscheinlich heute abend.

[bau]

proxmoxl1 ist ebenfalls per 100MBit am Switch angeschlossen (Patchfeld 4 Port 5).
Ich teste jetzt mal ihn auf 1GBit umzustecken.

[Rüdiger Kupper]

Okay.

1. proxmoxltspl2 und ltspl2 hängen also nur mit 100MBit am Netz -- das finde ich bemerkenswert, denn auf dem neuen ltspl2 geht der Login (über VNC) so schnell wie nirgends sonst. Das fühlt sich fast an, als würde ich an meinem eigenen Notebook sitzen. Die SSD scheint also einen enormen Geschwindigkeitsvorteil zu bringen, viel mehr als die Frage, ob das Netz GBit oder 100MBit macht. --> SSD anschaffen und Server virtualisieren :-).
2. Was ich mir nach wie vor nicht erklären kann, aber auch irgendwie mit dem Netz zusammenhängt, ist der Unterschied beim Login per VNC und von einem LtspClient:
   • Login per VNC (z.B. von mir zuhause aus): 2-3 Sekunden(!). Und da muss die Grafik immerhin durch mein billiges Alice-Modem, über einen 16MBit DSL-Anschluss, ins O2-Netz, an irgend einem Internet-Exchange in einer unbekannten Stadt (vermutlich Frankfurt?) ins BelWue-Backbone, zurück nach Freudenstadt, durch unseren IP-Fire und Switch in die Chemie. Und das alles doppelt verschlüsselt durch ein VPN und einen SSH-Tunnel.
   • Login von meinem Client im LZ aus: 2 Minuten. Und da geht die Grafik nur durch unser Netzwerk, über eine unverschlüsselte X-Verbindung. Neben der Grafik tauschen der LtspClient und Server noch weitere Daten aus, z.B. wird das Homeverzeichnis des Nutzers lokal auf dem Client gemountet, ev. angeschlossene USB-Speichergeräte werden vom Client auf dem Server gemountet, der Client meldet sich beim Epoptes-Server an, etc. Irgendwie schafft es dieser Netzverkehr, sich in unserem Netzwerk zu blockieren.

Vorschlag: Du hast doch einen Client in der Chemie, stöpsel den mal direkt an den Switch an, an dem auch (proxmox)ltspl2 hängt und boote den Client. Geht der Login dann schneller?

[Rüdiger Kupper]

Achso: Der Netzwerkkarte und -treiber des (proxmox)ltspl2 sind natürlich in beiden Fällen die selben. Die scheiden also als Ursache aus.

[bau]

Ich habe grade meinen Chemie-Client an den 100MBit-Switch (Lehrernetz) in der Chemie gehängt und von ltspl2 gebootet - Login war NICHT möglich (minutenlang drehendes Rädchen). Neu booten von ltspl1 und dann schneller Login (16 Sekunden).

Verbindung per VNC kannst du nicht vergleichen, das ist einfach ein Protokoll, welches sehr effizient das Bildschirmbildchen von A nach B schickt. Beim Login auf dem Client aber muss eine Sitzung auf dem CLIENT (nicht wie bei VNC auf dem Server) gestartet werden!

[jas]

Am 26.03.2014 17:48, schrieb Kepler-Trac:
sagt mal, ich weiß, ich habe keine Ahnung, aber könnte es sein, dass wir 
irgendwo einen "Kurzen" drin haben könnten, also dass irgendein Kollege 
mal Zwei Buchsen mit einem Kabel versehen haben könnte?

LtspL2 ist ein virtualisierter Server oder? Wo steht denn eigentlich der 
physikalische Teil?

[Rüdiger Kupper]

Replying to bau:

Verbindung per VNC kannst du nicht vergleichen, das ist einfach ein Protokoll, welches sehr effizient das Bildschirmbildchen von A nach B schickt. Beim Login auf dem Client aber muss eine Sitzung auf dem CLIENT (nicht wie bei VNC auf dem Server) gestartet werden!

Das stimmt nicht, auch bei LTSP wird die Sitzung auf dem Server gestartet. Das kannst Du einfach überprüfen, indem Du dich mal direkt auf einem Client als root einlogst (STRG+ALT+1) und die Nutzerliste anschaust: Die Nutzer sind nicht auf dem Client eingeloggt. Der Client ist nur ein Sichtgerät für die Grafik, ebenso wie der VNC-Client für den Proxmox. Das Protokoll ist aber unterschiedlich: Nicht VNC, sondern das klassische (urururalte) X-Protokoll. Also: entweder X funktioniert nicht, oder es liegt an einem der Servicves, die bei LTSP außer der Grafik noch gestartet werden:

• Homeverzeichnis des Nutzers vom Server auf den Client lokal mounten
• USB-Laufwerke vom Client auf den Server mounten (denn dort läuft ja die Sitzung des Nutzers, nur so kann er auf die USB-Laufwerke zugreifen, die am Client eingestöpselt sind)
• Auf dem Client läuft ein Pulseaudio-Server und der LtspServer verbindet sich als Pulseaudio-Client damit, um den Ton die die Sitzung des Nutzers (die auf dem LtspServer läuft!) durch die Soundkarte des Clients auszugeben.

Diese Prozesse laufen beim VNC-Zugang nicht ab. Doch ich erkenne nicht, wieso irgend etwas davon ein Problem sein sollte!

[Rüdiger Kupper]

Replying to jas:

sagt mal, ich weiß, ich habe keine Ahnung, aber könnte es sein, dass wir
irgendwo einen "Kurzen" drin haben könnten, also dass irgendein Kollege
mal Zwei Buchsen mit einem Kabel versehen haben könnte?

Das kann immer sein. Allerdings: Wenn Jens den Client an den selben Switch angestöpselt hat wie den Server, dürfte selbst das kein Problem sein.

LtspL2 ist ein virtualisierter Server oder? Wo steht denn eigentlich der
physikalische Teil?

In der Chemie-Vorbereitung.

[bau]

Einen "Kurzen im Netz" erkennst du recht schnell, denn dann geht im gesamten Netz wirklich garnichts mehr! Das hatten wir schon zweimal, die Switche blinken nur noch wild, und du bekommst nicht mal mehr eine kleine MinWebSeite im Browser angezeigt.

[bau]

Replying to kup:

Achso: Der Netzwerkkarte und -treiber des (proxmox)ltspl2 sind natürlich in beiden Fällen die selben. Die scheiden also als Ursache aus.

das geht glaube ich doch über zwei verschiedene NIC:

• VNC wird vom proxmoxltspl2 über die Hardware direkt rausgeschickt
• LTSP-X wird vom ltspl2 über die virtuelle NIC an vmbr1 gejagt
• Eine VNC-Verbindung zum ltspl2 haben wir nicht in Betrieb - oder? Da würde das xdmcp-Protokoll funktionieren (bietet ja der lightdm an).

[Rüdiger Kupper]

Replying to bau:

das geht glaube ich doch über zwei verschiedene NIC:

• VNC wird vom proxmoxltspl2 über die Hardware direkt rausgeschickt
• LTSP-X wird vom ltspl2 über die virtuelle NIC an vmbr1 gejagt

Dann wäre es ein Problem der virtuellen Netzwerkkarte? Vielleicht lässt die sich noch geschickter konfigurieren? (Ich dachte, ich hätte virtIO gewählt, dann greift die VM auch direkt auf die Hardware des Hosts zu. Mal nachsehen.)

• Eine VNC-Verbindung zum ltspl2 haben wir nicht in Betrieb - oder? Da würde das xdmcp-Protokoll funktionieren (bietet ja der lightdm an).

Derzeit nicht, kässt sich aber machen.

[Rüdiger Kupper]

Virtuelle Netzwerkkarte in ltspl2 steht auf virtIO, genauso wie die der virtualisierten Schülernetzserver ltsp6 und ltsp8.

Warum funktionieren ltsp6 und ltsp8 absolut problemlos, aber ltspl2 nicht?

[Rüdiger Kupper]

Ich versuche gerade, auf ltspl2 ein Systemupdate zu machen -- schon das Aktualisieren der Paketliste dauert ewig. Das Netzwerk auf ltspl2 ist einfach gähnend langsam! Das wird wohl auch der Grund sein, dass die Logins nicht klappen.

[Rüdiger Kupper]

Woran liegt jetzt das? Doch irgendwo etwas, das Netzwerklast generiert?
Hast Du die Switche im Lehrernetz eigentlich mal resettet?

[Rüdiger Kupper]

Interessant -- jetzt fluppt der Systemupdate wieder.
(Login geht trotzdem nicht :-( )

[Rüdiger Kupper]

Jucheee, ich hab's -- also, jedenfalls den Grund, warum der Login nicht ging:

Ltsp benutzt für den ersten Teil des Bootvorgangs TFTP, und zwar sog. "sicheres" TFTP. Sicher heißt: der Client kann nichts vom Dateisystem sehen, was oberhalb des exportierten Ordners liegt (/var/lib/tftpboot/ltsp/i386/). In dem Ordner liegt auch die lts.conf, die alle wichtigen Einstellungen für den Client enthält. Nun war ich so clever, aus dieser Datei einen Link zu machen, damit sie immer auf aktuellem Stand ist. Nur zeigte der Link leider nach /root/LTSP-setup/lts.conf, also außerhalb des exportierten Dateibaums.
Ähem.
Damit existierte diese Datei für den Client leider nicht.
Ich habe jetzt statt des Links die Datei hinkopiert -- und schon klappt der Login, juchee!

Was dadurch allerdings nicht behoben ist, sind die zeitweise langen Verbindungszeiten zum ltspl2 (wie heute mit ssh demonstriert). Das äußert sich in manchmal klemmenden Services (plank-Menü, Startleiste, etc.)

Wenn wir noch herausfinden, woran das liegt, sollte alles klappen!

[bau]

OCZ Vertex 460 SSD für die Server bestellt.
Liefertermin wird irgendwann nächste Woche sein!

[Rüdiger Kupper]

Super, die haben recht gute Testergebnisse!

• Welche Größe hast Du genommen, 120GB?
• Denk dran, auf den betreffenden Rechnern den TRIM-Support des Linux-Kernels zu aktivieren. (Mount-Option discard in der /etc/fstab setzen.) Das sorgt dafür, dass die SSD-laufwerke ihre Leistung länger aufrechterhalten (weil dann Speicherzugriffe gleichmäßiger verteilt werden können)

[Rüdiger Kupper]

• Außerdem sollte TRIM mit ext4 benutzt werden, auf proxmoxltspl2 läuft derzeit ein ext3-Dateisystem. (Grund? War das für Proxmox empfohlen?)

​http://askubuntu.com/questions/18903/how-to-enable-trim

[bau]

Es sind alles die 120GB Platten.

In der Installationsanleitung von proxmox auf Debian Wheezy (​http://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Wheezy) steht:

We recommend to use ext3 filesystem for best OpenVZ performance and stability. 

Da wir kein OpenVZ benutzen könnten wir auch EXT4 einsetzen.

Wie soll ich den Mount-Parameter die die SSD in der fstab setzen? Dort mounte ich ja nur die logical-Volumes? Ich habe den Eintrag für proxmoxltspl2 auf der paedml nun in der ~/.ssh/config eingetragen, so dass man sich jetzt per

ssh proxmoxltspl2

einloggen kann. Die Schlüssel kopiere ich gleich noch rüber.

[Rüdiger Kupper]

Replying to bau:

Wie soll ich den Mount-Parameter die die SSD in der fstab setzen? Dort mounte ich ja nur die logical-Volumes?

Aus dem proxmox-Forum (​http://188.165.151.221/threads/6500-SSD-for-High-Performance-Proxmox-Host):

In addition, don't forget to configure things like TRIM, I/O Scheduler, possibly journals if you use EXT3 or EXT4, etc.
[...] The VM's themselves should ALSO be configured to behave nicely as if they were installed directly onto a SSD in a physical machine.

Also:

• in der fstab des Hosts (proxmox) den "discard"-Eintrag für das root-Filesystem des Hosts hinzufügen
• innnerhalb der VMs in deren fstab ebenfalls die "discard"-Einträge hinzufügen

Mit einer der nächsten kernelversionen ist "discard" hoffentlich ohnehin der Default.

Es scheint übrigens möglich zu sein, direkt beim Aufsetzen des Proxmox ext4 statt ext3 zu wählen, siehe hier: ​http://www.jamescoyle.net/how-to/261-proxmox-advanced-install-settings

[bau]

Den Typ des Filesystems kann ich bei der Debian-Installation beliebig auswählen!
Ich bin mir nicht sicher, was da in die fstab rein soll - kannst du das bitte hineinschreiben, dann habe ich einen Präzedenz-Rechner, auf dem ich nachsehen kann.

[Rüdiger Kupper]

Ich habe unter AdminSsd eine Liste geschrieben, was man auf einem
Rechner mit SSD konfigurieren sollte. Die kannst Du auch bei Deinem
Notebook nochmal durchsehen.
Z.B. gibt's vielleicht Firmwareupdates für unsere Platten.

Am 29.03.2014 12:27, schrieb Kepler-Trac:

[jas]

Wie siehts hier eigentlich aus, eigentlich besteht speziell dieses Problem ja nicht mehr...

[Rüdiger Kupper]

Nach Einbau der SSD und Neuaufsetzen eines virtualisierten ltspl2 funktionierte alles problemlos, ohne dass man irgendwelche Services hätte deaktivieren müssen, etc.
Ich halte es inzwischen für unahrscheinlich, dass diese unspezifischen Symptome, die alle irgendwie mit Netzwerkzugriffen zu tun haben, an einer bestimmten Software liegen. Sie scheinen immer mal wieder überraschend aufzutreten (wie z.B. gestern und heute wieder), ohne dass wir die Ursache (Marder?!) finden können.