Nachdem der Großteil der Schülerinnen und Schüler am SGS wieder gezwungenermaßen im Homeschooling betreut werden, äußern sich wiederkehrende Performance-Probleme mit dem Chat- und Drive-Server des Städtischen Gymnasiums.
Bereits seit dem 10. November stehe ich hierzu in engem Austausch mit dem Serverhersteller Synology und dem Entwicklerteam in Taiwan. Ich möchte an dieser Stelle einmal darstellen, wie sich das Problem äußert, wie die Diagnose des Problems abläuft und wie der problematische Mechanismus lokalisiert wurde — und hoffentlich bald dauerhaft behoben werden kann; und wovon dies abhängt.
Es ist nicht die Leitung…
„Der Chat geht nicht, die Internetverbindung reicht nicht.“ — auf diese naheliegende Idee könnte man kommen. Wenn ein Web-basierter Dienst nicht reagiert, liegt es oft an nicht ausreichend vorhandener Bandbreite im Up- oder Downstream der eigenen oder der serverseitigen Internetanbindung. Das wir hier auch durchaus Probleme haben, habe ich schon einmal beschrieben. In diesem Fall liegt hier aber nicht die Ursache: Gerade eben z.B. war die Reaktionszeit des Chats zwar nicht so katastrophal wie heute morgen, aber die Leitung ist bei weitem nicht ausgelastet.
…aber auch nicht die CPU oder RAM Auslastung
Als zweiter möglicher Engpass könnte sich die Leistung des Servers selbst erweisen. Wir betreiben den Server dabei als virtuelle Maschine auf einem Synology Host, genauer gesagt einer RS4017xs+ mit 1TB redundantem Enterprise Class SSD Cache und 8 schnell drehenden 9 TB Serverplatten. Als Prozessor werkelt ein Intel Xeon D-1541 64-bit 8-Core mit 2,1 Ghz und den Speicher haben wir mit 64GB auf maximale Ausbaustufe gebracht. Zudem haben wir die Pro-Lizenz für die von Synology angebotene Virtualisierungslösung erworben, was bessere Verteilung der Hardware-Ressourcen des Hosts an die VMs erlaubt.
Zu viel Tech-Talk? Kurz gesagt: Das Teil hat Wumms. Mehr als genug für die zwei derzeit betriebenen virtuellen Maschinen. Das ist einmal der städtische WiFi-Controller für alle Schulstandorte und eben der Schulserver für das SGS.
Letztere VM nutzt derzeit 10 virtuelle CPUs und 6 reservierte CPU Threads mit hoher Priorität auf dem Host. Damit ist sehr viel, und im Grunde genommen sogar übermäßig viel, Rechenzeit für den Schulserver des SGS reserviert. Ein vorübergehender Zustand, der schlichtweg daraus resultiert, dass ich unzureichende Ressourcen als Fehlerquelle ausschließen wollte. Da wir Virtualisierung verwenden kann glücklicherweise jederzeit die Ressourcenzuweisung angepasst werden.
Die groben Angaben der Host-CPU Nutzung zeigen, dass zumindest zur Zeit keine wesentliche CPU Auslastung vorliegt. Aber auch ein Blick auf die Werte zur Hauptnutzungzeit weist keine Auffälligkeiten auf; hier lagen die beobachteten Werte immer in einem Bereich von maximal 10% bis maximal 15%.
Ans Eingemachte…
Natürlich gibt es noch weitere, potenzielle Engpässe, die einen Server in die Knie zwingen könnten. Um möglichst viele Parameter auf dem Host und auch auf der virtuellen Maschine überwachen zu können hat das Entwicklerteam von Synology den Performance-Monitor netdata auf unseren Systemen installiert. Hier lassen sich detailliert Leistungsdaten etwa für jede CPU oder auch Ein-/Ausgabewartezeiten, etwa verursacht durch langsame Plattenzugriffe, sehr detailliert beobachten.
Die Auswertung der Belastung des Gesamtsystems zeigt wieder nicht direkt Auffälligkeiten. Dies auch dann nicht, als die gesamte Jahrgangsstufe Q2 bei mehreren Belastungstest mitgeholfen hat, den Server herauszufordern (Rekord war ein Thread mit fast 1000 Kommentaren). Ebenso bemerkenswert war, dass während dieser Extrembelastung zwar nicht alle Nachrichten unmittelbar zugestellt werden konnten, aber die grundsätzliche Nutzung des Chats immer noch möglich war.
Somit musste noch etwas genauer hingeschaut werden. Ein Blick auf die Auslastung der einzelnen CPUs zeigte dabei eine Auffälligkeit: Während der intensiven Chat-Nutzung gibt es immer wieder Phasen mit erhöhter Auslastung, hauptsächlich CPU0. Gleichzeitige hohe iowait-Werte belegen, dass das System hier den Anfragen hinterher hinkt.
Es scheint sich um einen einzelnen Prozess auf dem Server zu handeln, der hier den Engpass bildet. Während eines weiteren Tests habe ich, auf Hinweis eines Synology Mitarbeiters, einen bestimmten Serverdienst überprüft und beim Auftreten von Symptomen neu gestartet. Es handelt sich hierbei um den Dienst „synocgid“ – das Backend für die Web-Authentifizierung der Synology Dienste Chat, Drive und DSM.
Das Ergebnis: Der Neustart brachte unter mittlerer Belastung sofort eine spürbare Verbesserung der Performance.
Der Türsteher…
Der Dienst ist dafür zuständig, bei Nutzeranfragen zu prüfen, ob der jeweilige Nutzer die Berechtigung für eine beabsichtigte Aktion hat. Dies tritt an unterschiedlichsten Stellen auf: Natürlich beim Anmelden an einen Dienst wie Chat oder Drive. Aber auch, wenn etwa die Chat-App kurz verlassen wird, und dann nach einiger Zeit wieder geöffnet wird. Die drei animierten Punkte am unteren Ende des Chat-Fensters dürften so manchem Nutzer schon die Nerven geraubt haben…
Aber auch bei anderen Aktionen muss die Berechtigung eines Nutzers (die ja grundsätzlich auch von einem Administrator jederzeit geändert werden könnte) überprüft werden. Die exakten Mechanismen in der Implementierung des Front- und Backends sind mir hierbei natürlich nicht bekannt, aber es muss z.B. immer wieder mal geprüft werden, ob ein Nutzer einen bestimmten Kanal überhaupt sehen oder betreten kann.
Also fallen bei der normalen Nutzung der Chat App nicht nur eine sondern pro Benutzer immer wieder mehrere Anfragen der App an den Serverdienst (den „Türsteher“) an, die durch diesen möglichst innerhalb von einigen Millisekunden beantwortet werden müssen. Ungünstig ist es, wenn in der Schlange vor der Disko schon viele hundert Anfragen stehen, die auch bearbeitet werden wollen.
Dies könnte unter anderem auch das Phänomen erklären, dass beim „Stresstest“ durch die Q2 die Reaktionszeit zwar recht hoch war, aber eine Nutzung immer noch möglich war: Die Überprüfung der Berechtigung beim aufeinanderfolgenden Senden von Nachrichten innerhalb eines Kanals wird offenbar nicht bei jeder einzelnen Nachricht neu geprüft.
Und eine weitere Beobachtung lässt sich so deuten: Obwohl dieser eine Serverdienst durchgängig bei 100% CPU liegt, zeigte die Gesamtauslastung deutlich geringere Auslastungen; was schlichtweg an der Tatsache liegt, dass der Prozess nur auf einer CPU und nicht per Multithreading auf mehreren Kernen läuft. Was bei einem vermutlich relativ simplen Serverdienst nicht erforderlich sein sollte.
…und die Lösung
Die kann nicht lauten, den überlaufenden Serverdienst, etwa per cronjob oder durch intelligenteres Scripting bei Bedarf neu zu starten. In den letzten Tagen des flächendeckenden Homeschoolings waren die Anfragen so zahlreich, dass nach einem Neustart der Dienstes dieser bereits nach ein paar Sekunden wieder bei 100% Auslastung.
Die Lösung ist eher die, dass unser Türsteher intelligenter und schneller arbeiten muss. Offenbar sind die internen Abläufe des synocgid Dienstes nicht derart effizient implementiert, dass er mit der parallelen und aktiven Nutzung von ca. 800 Nutzern dauerhaft zurechtkommt. Da die Implementierung des Dienstes nicht quelloffen ist, ist ein eigener Eingriff im System durch mich ausgeschlossen (ich denke mal, dass ein dekompilieren des backends irgendwo in den EULAs von Synology verboten wird ;)).
Zur Behebung des Problems haben die Support-Mitarbeiter von Synology die entsprechenden Log-Dateien und Beobachtungen des Leistungsdaten und die Ergebnisse der simulierten Serverbelastungen an die Entwicklungsabteilung gegeben. Nun gibt es zwei Möglichkeiten, mit denen diese das Problem lösen können: Entweder sie liefern einen Workaround oder, idealerweise, einen Patch für die problematische binary, der das Problem dauerhaft löst, und ggf. seinen Weg in ein zukünftiges offizielles Update findet.
Warum schreibe ich das?
Die letzten Wochen, Monate und im Prinzip das gesamte Jahr 2020 seit März treibt mich das Problem um, für die Schule eine Plattform zu nutzbar zu machen, die Homeschooling ermöglicht.
Die Etablierung des Chat-Systems hat dabei bereits 2018 begonnen. Und bis zum Beginn des Jahres 2020 hatte sich die Chat-App als gangbares Kommunikationsmedium im Schulalltag bewährt. Kollegiale Absprachen, aktuelle Hinweise an Lerngruppen und individuelle Nachrichten zwischen Schülerschaft und Kollegium waren jederzeit problemlos möglich. Sogar die Vorwahlen zu den Leistungskursen wurden bisweilen über das integrierte Abstimmungsmodul durchgeführt.
Ich bin mir sicher, dass ein wesentlicher Grund für die Akzeptanz des Dienstes die hohe Verfügbarkeit der App selbst ist, und deren Umsetzung bzw. überhaupt die Tatsache, dass es eine (native) App für Android und iOS gibt. Hier versagen leider viele andere (auch offizielle) Angebote, da sie auf Technologien basieren, die Ende der 90er vielleicht noch angesagt waren, heute aber nicht zeitgemäß weil nicht mobil-optimiert und reaktiv sind. Und unsere Nutzer (aus der Schüler- aber auch Lehrerschaft) sind aus ihrem digitalen Alltag anderes gewohnt.
Dann kam Tag X. Auf Grundlage der 5. Schulmail vom 15.3.2020 wurde in der am darauf folgenden Tag stattfindenden Lehrerkonferenz deutlich, dass wir auf unser bewährtes System, die Chat-App von Synology, setzen würden. Das zu diesem Zeitpunkt beschlossene Konzept, die Versorgung der Lerngruppen vorrangig zur „normalen“ Unterrichtszeit vorzunehmen, bereitete mir dort schon Kopfzerbrechen — würde die Internetleitung das hergeben? Und so Begann die Odyssee auf der Suche nach den eingangs beschriebenen Leistungsproblemen.
Warum ich das alles schreibe? Es passiert viel im Hintergrund, von dem man nichts mitbekommt. Die unzähligen zusätzlichen Stunden, die die Kolleg*innen bis tief in die Nacht hinein Schülerrückmeldungen verfassen, digitale Arbeitsaufträge erstellen, welche erprobte, analoge Arbeitsmaterialsammlungen in kürzester Zeit ersetzen müssen, die vielen Momente, die durch nicht funktionierende oder nicht reagierende Technik ungenutzt und abgenervt verstreichen. Und auch meine eigenen Bemühungen, die digitale Infrastruktur der Schule für den Einsatz in der Schule und außerhalb der Schule am Leben zu erhalten. Ich sehe das mittlerweile als einen festen Teil meiner Aufgabe an dieser Schule an, obwohl dies an keiner Stelle als eine meiner Dienstpflichten genannt wird. Es ist meine Aufgabe, weil diese Aufgabe in diesem Umfang nicht an andere Lehrer zu delegieren wäre, und weil eine umfangreiche und unmittelbare technische Unterstützung zur Zeit durch externe Dienstleister nicht realisierbar erscheint. Und daher wollte ich hier zumindest einen kleinen Einblick „hinter die Kulissen“ ermöglichen. Und das ist nur ein kleiner Teil des „Gesamtpakets“. Schließlich gibt es noch Beamer, Lautsprecher, AppleTVs, digitale Tafeln, Nutzerverzeichnisse, Dienst-iPads, Dienst-Emailserver, Arbeitsplätze, Softwareverteilung, Kopierer, Homepage, Vertretungsplan-App, Ausleih-Tablets, Rollkontainer voller Notebooks, das Schul-WLAN, Verwaltungssoftware, Schülerdatenbanken, Updates, Backups, VPN, VLAN, Fernwartung … Fortsetzung folgt?
Pingback: Der SGSChat – docwahle_it