Die letzten Tage bei der HPI Schul-Cloud waren geprägt durch stark wachsende Nutzungszahlen, Erreichbarkeitsprobleme und den vorgezogenen Umzug der HPI Schul-Cloud auf eine neue Infrastruktur, ein wirklicher Kraftakt für unser Team. Doch nun ist es vollbracht: Die Kinderkrankheiten sind inzwischen kuriert, das System läuft stabil und performant in der neuen Hostingumgebung. Zeit also, einen Blick auf unsere neue Infrastruktur zu werfen.

Vor dem Umzug hatten wir alle Server des Pilotprojektes in einer privaten Cloud (OpenStack) direkt am HPI betrieben. Das war ausreichend für die Lastszenarien vor den Schulschließungen durch Corona: Pilotschulen kamen nach und nach in geregelten Onboarding-Wellen hinzu, oft mit schmalem WLAN und ohne flächendeckend vorhandene Endgeräte. Das brachte unsere Server nicht ins Schwitzen. Die Situation änderte sich deutlich durch die Schulschließungen in Deutschland. Nun waren unsere Nutzer:innen jeweils mit eigenem Endgerät in meist gutem WLAN unterwegs. Dies machte den Auszug aus dem HPI-Netz dringend erforderlich.

Mit unserer neuen, Kubernetes-basierten Infrastruktur sind wir jederzeit skalierungsfähig. Durch das Hosting in einem deutschen Rechenzentrum werden wir nun nicht mehr durch die Anbindung des HPIs an das Internet limitiert, die wir uns zudem mit OpenWHO teilten, der vom HPI betriebenen, ebenfalls stark frequentierten Krisenmanagement-Plattform der Weltgesundheitsorganisation. Die auf OpenWHO in aktuell zwölf Sprachen angebotenen COVID–19-Trainingskurse für Fachkräfte im Gesundheitssystem verzeichneten in sechs Wochen über 200.000 neue Einschreibungen.

Das sind die Komponenten unserer neuen Infrastruktur

Die technischen Eckdaten: Alle Dienste laufen containerisiert in einem Kubernetes-Cluster (K8s). Dieser besteht momentan aus drei „echten“ Servern und zehn virtuellen Maschinen (VMs). Das ergibt in Summe 86 CPU-Kerne und 508,48 GB Arbeitsspeicher. Persistente Volumes werden via Gluster bereitgestellt. Da hier keine Nutzerdaten liegen, reicht wenig Speicherplatz (262,58 GB). Das K8s-Cluster ist in mehrere Namespaces unterteilt und umfasst nur produktiv laufende Instanzen. Dienste wie Redis (Key-Value-Storage und Cache) oder RabbitMQ (Anwendungsinterner Nachrichtenbus) laufen ebenfalls im Cluster.

Eine Firewall und ein Loadbalancer sorgen für Sicherheit und eine Verteilung der einkommenden Anfragen. Test- und Staging-Instanzen laufen in einem eigenen, getrennten Cluster.

Manche Dienste wie zum Beispiel der Anti-Virus-Scan liegen aus Sicherheitsgründen außerhalb des Clusters auf virtuellen Servern. Auch die momentan vier Server für Videokonferenzen (Big Blue Button) und die (virtuellen) Server für den neuen Messenger auf Basis von Riot/Matrix, an dem wir gerade arbeiten, liegen aus Sicherheitsgründen außerhalb des Clusters.

Die Datenbanken, MongoDB und PostgreSQL, liegen auf dedizierten Servern und sind jeweils redundant ausgeführt. Die MongoDB besteht aus einem Replica-Set mit drei Nodes, Postgress aus zwei Servern. Alle Dateien, die hoch- und runtergeladen werden, landen auf einem verwaltenden Dateispeicher, welcher über das S3-Protokoll angebunden ist. Somit wird das K8s-Cluster beim Up- und Download von Dateien nicht belastet.

Zum Monitoring wird Prometheus eingesetzt. Ein Grafana-basiertes Dashboard visualisiert die dort erfassten Metriken und Daten. Fehler, die beim Betrieb der Cloud oder in den Clients auftreten, werden anonymisiert in einer eigenen Sentry-Instanz geloggt. Interne Logs werden via Syslog auf zwei Syslog-Servern innerhalb des Clusters gespeichert. Backups erfolgen übrigens verschlüsselt in über das S3-Protokoll angebundenen Buckets.

Auszug aus dem Grafana-Dashboard mit fünf der Worker-Nodes des K8s-Clusters. Gut zu sehen: Auch zu Hause wird am Vormittag mehr gelernt. Je nachdem, welche Dienste auf einem Knoten laufen, unterscheiden sich CPU und Speicherauslastung

Derzeitige Auslastung und nächste Schritte

Mit dem Abschluss des Umzuges ist die Erreichbarkeit der HPI Schul-Cloud wieder gewährleistet. Wir haben die letzten bekannten Leistungsprobleme der Anwendung behoben und sind gut aufgestellt für die Entwicklungen der kommenden Wochen. Gemessen an der momentanen Anzahl der Zugriffe ist noch einiges an Reserve vorhanden. Wir sind bei circa 25% CPU-Auslastung der Datenbank (ohne Backup und Failovernodes), 20% des Arbeitsspeichers und unter 20% Auslastung der CPUs des Clusters.

Und sollte es doch irgendwo mal knapp werden, werden wir rechtzeitig durch unser Monitoring darauf aufmerksam und können kurzfristig Ressourcen aufstocken oder umverteilen. Wir arbeiten daran, zukünftig bei Lastspitzen automatisiert weitere VMs in unsere Instanz hinzuzufügen und diese wieder abzuschalten, wenn sich unsere Nutzer:innen am Nachmittag anderen Dingen als der HPI Schul-Cloud zuwenden.

Wir bedanken uns bei all unseren Nutzer:innen für die entgegengebrachte Geduld während der Umzugsarbeiten. Auch uns als Team der HPI Schul-Cloud stellte die Corona-Situation kurzfristig vor große Herausforderungen. Nun sind wir mit einer skalierenden Infrastruktur für digital gestütztes Lernen gut gerüstet, die kommende Zeit gemeinsam durchzustehen.

Euer Team der HPI Schul-Cloud