Früher…
Seit 2018 nutzt das SGS seine eigene Cloud, die SGSCloud. Lange bevor die offizielle Chatplattform LOGINEO Messenger verfügbar war hatten sich am SGS, parallel zum Ausbau des flächendeckenden WLANs, die schulintern gehosteten Plattformen „Chat“ und „Drive“ als Kommunikations- und Cloudlösung etabliert.
Bei den beiden Diensten handelt es sich um eine Kombination von Server- und Clientsoftware, die vom Hersteller unserer Serverhardware Synology zur Verfügung gestellt wird. Über die vergangenen Jahre haben sich beide Lösungen im (normalen) Schulalltag als datensichere und komfortable Alltagshelfer erwiesen.
Kurzfristige Absprachen per Chat oder der Austausch von und das gemeinsame Arbeiten an digitalen Inhalten für den Unterricht in Form von Texten, Tabellen und Präsentationen wurde immer mehr vom Kollegium und den Schülerinnen und Schülern genutzt.
Die technischen Probleme, die es während des „Normalbetriebs“ in dieser Zeit gab, beschränkten sich im Wesentlichen auf gelegentliche Ausfälle bedingt durch die unzureichende Breitbandanbindung der Schule.
…und heute.
Mittlerweile haben sich die Zeiten geändert. Seit dem März 2020 kann von einer normalen Nutzung der Dienste nicht die Rede sein; es ist vielmehr ein Dauerstresstest für alle digitalen Plattformen, die alle mit dem erhöhten Ansturm zu kämpfen haben.
Bereits Anfang April 2020 zeige sich, dass vor allem auch der Chat so seine Probleme mit der hohen Anzahl von Anfragen hat. Seit diesem Zeitpunkt stehe ich in regelmäßigem Kontakt mit dem Serverhersteller. Wir haben das Problem, eine Unzulänglichkeit in der Implementierung der Serversoftware, identifiziert. Der Hersteller sichert (schon seit längerem) substanzielle Hilfe in Form eines Updates zu.
Bislang lässt aber eine Lösung auf sich warten. Auf Fachchinesisch: Wir stecken in einem Vendor-Lock. Diesen Hinweis und auch den entscheidenden Tipp für eine mögliche Lösung der Situation gaben dann zwei sehr nette IT-Experten des Internetgiganten Akamai.net, deren Kerngeschäft unter Anderem und passenderweise die Hochverfügbarkeit von Netzanwendungen ist.
Die Lösung…
Der Ausbruch aus dem Lock-in des Serverherstellers heißt: OpenSource! Um genau zu sein: Rocket.Chat. Diese Kommunikationsplattform ist ebenso eine Kombination aus Server- und Clientanwendungen. Im Gegensatz zur Software des Serverherstellers handelt es sich aber hierbei um quelloffene Software, die von einer weltweiten Entwicklergemeinde gepflegt wird und für jeden frei verfügbar ist. Das bedeutet auch, dass jeder die Software auf seine Bedürfnisse anpassen kann.
Sehr viele Unternehmen und fast alle Universitäten setzen auf Rocket.Chat. Damit kommt das Tool unseren Schülerinnen und Schülern auch im Sinne der Wissenschaftspropädeutik und Berufsbildung hinsichtlich der digitalen Kommunikationskompetenzen entgegen.
Task 1 – die Hintergrundarbeit
Sicher ist sicher
Der erste Schritt bei der Einrichtung der neuen Chat-Serverstruktur war die Installation des Serverdienstes auf verlässlicher und gesicherter Serverhardware. Seit vor einigen Jahren durch einen Einbruch Hardware aus dem SGS entwendet wurde ist klar, dass eine Schule nicht unbedingt der uneingeschränkt sicherste Ort ist. Ebenso muss durch geeignete organisatorische und technische Maßnahmen sichergestellt werden, dass die Serverhardware und die dort gespeicherten Daten sicher vor Zugriffen unbefugter Personen sind. Weiter sollte ein Server über eine stabile Breitbandanbindung, sichere Stromversorgung und Kühlung verfügen.
All dies lässt sich in einer Schule nur schwer umsetzen. Und so folgte ich dem zweiten Hinweise der IT-Profis: Nutzt gemietete Serverhardware in einem professionellen Rechenzentrum. Durch meine Erfahrungen mit der Nutzung von Hochleistungsrechnern habe ich mich für den Serverstandort Frankfurter vom Anbieter AWS entschieden. Die Datenverarbeitung erfolgt dabei in einem ISO 27001 zertifizierten Rechenzentrum, welches die Daten DSGVO-konform im Auftrag der Schule verarbeitet. Sämtliche Datenübertragung findet SSL verschlüsselt statt.
Last bis zum Geht-nicht-mehr
Wie kann sichergestellt werden, dass die neue Serverstruktur nicht ähnliche Probleme bekommt, wie der alte Server?
Hier eine kurze technische Erklärung. Das Problem beim alten Serverdienst war darin begründet, dass ein bestimmter Bestandteil des Backends nur auf einem CPU Thread lief, nämlich das webauth-backend. Im Grunde ist das Problem der jetzigen Software auch so vorprogrammiert, wie ich auf den Hinweis eines netten, sehr fachkundigen Kollegen durch Recherchen erfuhr. Jedoch an sich schon einmal geringer ausgeprägt.
Das Backend von Rocket.Chat läuft auf Node.js, was gerade aufgrund seiner Struktur darauf spezialisiert ist, viele parallele Anfragen schnell abarbeiten zu können. Die zugrundeliegende NOSQL-Datenbank MongoDB ist für schnelle Abfragen von JSON und BSON Objekten ausgelegt; im Gegensatz zum PostgresQL Datenbankserver, der die Grundlage für den Synology Chat darstellt.
Auch Node.js läuft zunächst einmal nur auf einem Thread. Heißt: auch ein noch so großer Server könnte dann nicht weiterhelfen, die Performance sicherzustellen. Aber – im Gegensatz zur Lösung von Synology – können wir uns hierauf einstellen.
Viel hilft viel
Die Lösung ist, nicht nur einen sondern direkt mehrere Chat-Serverinstanzen zu erstellen. Anfragen an den Chatserver rocket.sgscloud.de landen nicht direkt beim Chat-Server sondern werden zunächst vom „Türsteher“ in Empfang genommen, einem Reverse Proxy mit Load Balancer.
Dieser regelt zum Einen die SSL-Verschlüsselung mittels Let’s Encrypt Zertifizierung und andererseits verteilt er die Anfragen auf die verschiedenen Server-Installationen im lokalen virtuellen Netz. Fallen zeitweise Server aus, erkennt dies der Load Balancer und spart es sich, die Anfragen weiterzuleiten, bis der Serverdienst wieder online ist. Die entsprechenden Services erkennen abgestützte Prozesse und starten diese nach einiger Zeit neu, so dass es keine dauerhaften Ausfälle im laufenden Betrieb geben kann.
Die Rocket.Chat Implementation ist dabei so intelligent, dass sie die einzelnen Instanzen untereinander per Event informiert, wenn es etwas neues gibt. Wenn z.B. ein User A eine Nachricht sendet, und die Sende-Anfrage zufällig bei Server 1 landet, aber der Adressat, User B, auf Server 4 unterwegs ist, erhält Server 4 den Event mitgeteilt und User B seine Nachricht. Und das, ohne dass der Endanwender etwas mitbekommt.
Insgesamt ergibt sich also die Situation, dass wir, sobald wir einen Engpass entdecken, diesen durch das Klonen zusätzlicher Serverinstanzen relativ kurzfristig durch beliebige Erhöhung der Kapazitäten beheben können.
Task 2 – die Vordergrundarbeit
Apps für alle
Die Apps von Rocket.Chat gibt es bereits in den einschlägigen App Stores. Davon abgesehen, dass sich Rocket.Chat auch im Browser sehr gut anpassen und branden lässt, ist es immer von Vorteil, eine native App auf dem jeweiligen Betriebssystem zur Verfügung zu haben. So können etwa problemlos Fotos und Dateien über die Chat App versendet werden und auch Sprachnachrichten (bei vorhandener Nutzereinwilligung selbstredend) per Mikrofon-Freigabe versendet werden.
Warum ist es also sinnvoll, sich die Arbeit zu machen, die nativen Apps für mobile Endgeräte mit eigenem Logo und Screenshots zu versehen (…was ein unfassbar unterschätzter Zeitaufwand ist; dazu lohnt sich fast ein eigener Artikel…)? Der Grund dafür ist einfach: Das Push Gateway.
Push it!
Jeder App-Entwickler kann per Zertifikat und private Key mit den einschlägigen Push-Servern von Apple und Google von seiner Serverinstallation die berühmt berüchtigten Push-Benachrichtigungen auf die Endgeräte der Nutzer (nur bei vorhandener Zustimmung, selbstredend) senden.
Die Entwickler vom Rocket.Chat teilen gerne ihren Quellcode, aber (logischerweise) nicht ihre private Keys und Push Zertifikate. Daher haben die Anbieter ein ausgelagertes Push-Gateway implementiert, mit dem die Rocket.Chat Installation redet, um die Push Nachrichten zu versenden.
Der Anbieter hat hier seinen Nutzern ein Limit von 10000 Push Nachrichten pro Monat auferlegt. Danach wird es teuer (d.h. 3$ pro User für ein höheres Limit von 25000 Push Nachrichten) oder es gibt eben keine Push-Nachrichten mehr.
Die Alternative ist: Kompiliere die Apps mit deinen eigenen Distributionszertifikaten (und eben auch dem eigenen Logo und dem voreingestellten Server), und verwende auf der Serverinstallation deine eigenen Push-Zertifikate, um die Nachrichten zu versenden. Das hat den Vorteil, dass der Push-Nachrichtenversand nicht mehr von einem externen Gateway abhängt und dass eine unbegrenzte Anzahl an Push-Nachrichten verschickt werden kann.
…und neue Probleme?
Ja, es wird natürlich neue Probleme geben. Das offensichtlichste Problem ist, dass wir keinerlei Erfahrungswerte über die Auslastung des Systems mit über 800 aktiven Nutzern haben. Es ist nicht realistisch anzunehmen, dass die Konfiguration unseres Serverclusters schon im ersten Anlauf optimal ist, und das ist in beide Richtungen gemeint: Entweder, die Server reichen für die Last nicht aus in Hinblick auf RAM oder CPU (die Netzanbindung mit 5 GBit/s wird reichen…), oder die 4 Serverinstanzen sind gar nicht erforderlich und kosten nur unnötig Geld.
In beiden Fällen wäre eine Nachjustierung nötig. Da dies durch im Wesentlichen durch das Hochfahren neuer Serverinstanzen (und Anmeldung beim Loadbalancer) oder das Abschalten von Serverinstanzen (und Abmeldung beim Loadbalancer) recht möglich ist, werden diese Anlaufschwierigkeiten eher gering ausfallen und dann auch dauerhaft beseitigt werden können. Und hier schließt sich der Fall: Eine solche Perspektive der Feintuningmöglichkeit des Chat-Servers ist mit dem alten System einfach nicht gewährleistet.
TL;DR
Wenn du eine datensichere und zeitgemäße OpenSource Chat-Plattform haben möchtest: Installiere Rocket.Chat hinter einem Nginx-Reverse Proxy mit Load Balancer in einem DSGVO-konformen Rechenzentrum deiner Wahl, kompiliere die mobilen Apps und signiere sie mit deinem jeweiligen Entwickleraccount.