FH Lübeck seit Mittwoch 19 Uhr auf Moodle 2.3

Gestern war das erste große Update auf Moodle 2.3 und es hat leider nicht reibungslos funktioniert. Was ist passiert?

Wir hatten uns eigentlich gut vorbereitet und auch alles getestet. Auf unseren Testinstallationen sind alle Skripte einwandfrei durchgelaufen und auch der Zeitrahmen war mit maximal 8 Stunden definiert gewesen. Wir haben jedoch mit mit weniger gerechnet bzw. gehofft. Das Update haben wir schon am Wochenende begonnen, als wir zum ersten mal alle Kurse kopiert hatten, was auch einwandfrei funktioniert hatte. Am Dienstag wollten wir dann nur die Kurse anfassen, die sich in den letzten zwei Tagen geändert hatten. Dafür hatten wir ein SYNC-Skript gebastelt, was uns dann 230 von 680 Kursen ausgegeben hatte. Das sparte uns 60 % der Arbeit und wir gingen zuversichtlich an die Arbeit. Leider hat das importieren der Kurse aber sehr viel länger gedauert, als erhofft. Hier hätten wir schon misstrauisch werden können, aber umfangreiche Server Arbeiten sind oft schwer zu schätzen. Wir haben dann gemerkt, dass der erste Zeitplan aus dem Ruder läuft und der Restore bis nach Mitternacht laufen wird.

Am nächsten morgen haben wir dann alle Kurse überprüft und gemerkt, dass 12 von 680 Probleme erzeugt haben. Warum es beim Testlauf geklappt hat, ist uns immer noch ein Rätsel. Wir haben dann viele Restarbeiten durchgeführt und sind um 12:30 Uhr online gegangen (geplant war 12 Uhr). Aber das System hat sich sofort aufgeschaukelt und ist in Überlast gegangen. Wir hatten zig httpd-Prozesse mit CPU Last von jeweils 30%, was nicht normal ist. Dann ging die Fehlersuche los und das optimieren, z.B. PHP-Cache, MySQL-optimize, RAM erhöhen, Configs überprüfen, CSS überprüft usw. Zum Schluss haben wir den gesamten Cluster verschoben, damit der Storage Zugriff schneller ist, was aber auch keine Besserung brachte. Jetzt haben wir nach dem berühmten Zitat von Sherlock Homes “Wenn man das Unmögliche ausgeschlossen hat, muss das, was übrig bleibt, die Wahrheit sein, so unwahrscheinlich sie auch klingen mag.” gehandelt und den ganzen Server getauscht. Wir haben zwar keinen Fehler gefunden, aber irgendwo hatte der Linux Server ein merkwürdiges Eigenleben, was nicht erklärbar war. Das es am Server lag, war extrem unwahrscheinlich. Immerhin haben wir schon mehrere hundertmale Server geklont und so ein Verhalten war noch nie  (nein das stimmt nicht, ca. 4 Jahren ist es her) passiert. Eine Stunde später hatten wir einen neuen Klon aufgesetzt, das Moodle-Data Verzeichnis neu gemounted und den Datenbank-Dump eingespielt. Dann noch den DNS Eintrag neu geschrieben und das System war gegen 19 Uhr online .

Am nächsten Tag lief das System stabil und ohne Lastprobleme. Alle konnten arbeiten, was erstmal das wichtigste war. Im Laufe des Tages summierten sich mehrere kleine Baustellen. Bei einigen Kursen haben wir Probleme mit den Einsendeaufgaben, andere hatten Probleme mit Riesenkursen (teilweise mehrere Gigabyte groß) und das größte Problem war ein Designfehler mit alten Internet Explorer Versionen. Das meiste konnten wir am Donnerstag beheben aber bei zwölf Kursen sitzen wir immer noch dran.

Jetzt nach drei Tagen kann man rückblickend sagen, das wir insgesamt einfach Pech hatten. Wir haben das fehlerhafte System “Montagsserver” getauft und überlegen, ob wir es von VMware untersuchen lassen. Zuerst hatten wir kein Glück und dann kam noch Pech dazu 🙂 Ich fand es ziemlich gut, dass wir Mittwoch Nachmittag innerhalb von 60 Minuten ein neues leistungsstarkes System aufgesetzt bekommen haben und so schnell auf den Vorfall reagieren konnten. Jetzt läuft das System schon einige Tage problemfrei und wir haben keien Kritiken bekommen. Wir ITler sind ja meist schon glücklich, dass sich niemand beschwert. Lob kriegen wir fast nie zu hören…