Es gibt mal wieder ein neues U7-Release, dessen Änderungen sich wie üblich im ChangeLog nachvollziehen lassen. Neben diversen Updates und der Bereitstellung weiterer Kommandozeilentools (auf eure Wünsche hin - wir leiten ganz oft aus Supportanfragen ab, was potentiell sinnvoll und praktisch für alle wäre!) haben wir einen Mechanismus eingebaut, der allen supervisord-Services, die keine startsecs-Angabe haben, automatisch startsecs=30 verpasst. Hierbei handelt es sich um eine Einstellung, wie lange ein Service mindestens laufen muss, damit supervisord ihn als korrekt funktionierend betrachtet. Standardmäßig wird hier seitens supervisord nur 1 Sekunde lang gewartet - allerdings ist der Start einiger Applikationen, insbesondere derer mit vielen Abhängigkeiten und Modulen, so komplex, dass er länger als eine Sekunde dauert. Bricht der Service dann erst etwas später ab, startet supervisord ihn neu. Dabei wird unterschieden zwischen den Services, die mindestens startsecs viele Sekunden gelaufen sind: Bricht der Service früher ab, klemmt supervisord ihn nach zwei weiteren erfolglosenen Versuchen ab; hat er aber die Mindestdauer an Laufzeit erreicht, erfolgen diese Neustarts wieder und wieder. Das bedeutet, dass ein kaputter Service dann unendlich oft neu gestartet wird, permanent - und dabei jedes Mal aufs Neue CPU-Zeit verbraucht, in einem Umfang, der dann gelegentlich auch unser Monitoring Alarm schlagen lässt. Das ist schlecht für alle: Für uns, weil es gegebenenfalls zur Unzeit jemanden rausklingelt, um sich so eine Situation persönlich anzuschauen, und für euch, weil solche Vorgänge CPU-Zeit “klauen”, die anderswo sicher besser genutzt wäre. Leider ist es seitens supervisord nicht möglich, hier global einen anderen Wert als 1 Sekunde vorzugeben - das ist fest einkompiliert. Wir haben bereits versucht, anzuregen, eine entsprechende globale Einstellung anzuregen, leider ohne Erfolg. Daher nun die alternative Strategie: Wir verpassen jeder einzelnen Service-Konfiguration die entsprechende Einstellung. Wer an dieser Stelle andere Werte einstellen möchte, ist natürlich herzlich willkommen - die werden dann nicht angefasst.

Wann kommt nach U7 eigentlich U8? U7 hat seinen Namen daher, dass es auf CentOS 7 basiert, und bereits jetzt ist klar: Ein Uberspace auf Basis von CentOS 8 wird es nicht geben, denn während CentOS 7 noch gepflegt wird, ist CentOS 8 bereits seit einem Jahr end of life und CentOS gibt es in der bisherigen Form (als freie Variante des kommerziellen Enterprise Linux) auch nicht mehr. Intern laufen nun entsprechend die Überlegungen, die nächste große Uberspace-Version auf der 9er-Version einer anderen freien RHEL-Alternative wie z.B. Rocky Linux laufen zu lassen, oder aber den noch größeren Schritt zu gehen und auf eine ganz andere Distribution, vorzugsweise eine Rolling-Release-Distribution zu wechseln. Und während die technische Diskussion läuft, gibt es parallel dazu auch einen Prozess der Namensfindung, denn wenn wir uns nicht mehr an CentOS-Release-Nummern orientieren, woran dann? Intern nutzen wir “Uberspace Next” bzw. “unext” als Arbeitstitel, aber eine Versionsbezeichnung bzw. ein Schema für die Zukunft schwebt uns durchaus auch schon vor… mehr dazu, wenn’s aktueller wird.

PHP 7.4 ist Geschichte. In einer geplanten Aktion haben wir alle, die noch PHP 7.4 nutzen, mit einem Monat Vorlauf vor dem EOL-Termin per Mail auf das anstehende Supportende dieser Version hingewiesen und erklärt, wie auf PHP 8 umgestellt werden kann (und ggf. auch erstmal wieder zurück, falls es dabei Probleme gibt, die noch unter der alten Version gefixt werden müssen). Am Stichtag haben wir dann alle verbliebenen Accounts mit PHP 7.4 auf PHP 8 umgestellt - und nicht nur das: auch nahezu alle Lab-Guides, die noch auf PHP 7.4 referenziert haben, wurden mit einem “PHP 8 update”-Label versehen und in akribischer Kleinarbeit durchgetestet - mit dem guten Ergebnis: Die allermeisten davon funktionieren auch weiterhin einwandfrei.

Auch im Rechenzentrum ist wieder viel passiert. Zu den Dingen, die sich leider nicht mit einem einfachen yum upgrade oder apt-get upgrade aktualisieren lassen, gehören leider nahezu alle sonstigen Hardwaregeschichten, von Switchen und Routern bis hin zu Konsolenservern, über die wir z.B. an Management-Ports von Steckdosenleisten drankommen. Hier kommen dann leider eher archaische Prozesse zum Tragen, wo von USB-Sticks gebootet und von dort neue Firmware geflasht werden muss… aber nur, weil das ungleich schwieriger ist, können wir es ja nicht bleiben lassen. Gerade die Konsolenserver haben sich als besonders widerspenstig erwiesen, aber siehe da: Wenn die den USB-Stick nicht erkennen wollen oder die Firmware nur teilweise laden, reicht es “schon” aus, sie via Steckdose 5-10 Mal kalt neuzustarten - und “schon” klappt es irgendwann. Nun endlich sind auch diese Biester alle wieder firmwaretechnisch auf dem neuesten Stand.

Da wir nun endlich wieder mehr Switche im Rechenzentrum haben (siehe LL#3), konnten endlich einige Arbeiten durchgeführt werden, die schon lange vorbereitet waren und wo uns sehr geschmerzt hat, dass wir die Hardware für den Ausgleich von Engpässen längst fertig vor Ort stehen haben, aber mangels der Lieferung von Switchen nicht einbauen konnten. Nun ist es endlich gelungen, unseren ohnehin schon größten, aber auch ausgelastetsten Cluster an FRA3 mit gleich drei weiteren Nodes auszustatten. Das erlaubt nicht nur im Alltag eine leichtere Verteilung von Ressourcen, sondern auch eine leichtere planmäßigere Außerbetriebnahme einzelner Nodes, die z.B. reparaturbedürftig sind.

Hier und da stoßen wir bei unseren eigenen Fähigkeiten an Grenzen, die wir lieber Menschen mit besseren Kenntnissen überlassen möchten, aber dann wiederum ist der Bedarf nicht so groß, um daraus eine feste Stelle zu schaffen. Wir haben daher erstmalig gezielt nach einer Freelancerin gesucht, die uns bei einigen sehr spezifischen Dingen konkret unterstützen kann. Wir haben viel positives Feedback und auch eine ganze Reihe an Bewerbungen erhalten, so dass wir uns hier inzwischen für eine Person entscheiden konnten. Wir freuen uns auf die Zusammenarbeit!

Eine kleine, aber sehr praktische Änderung gibt’s bei den Proforma-Rechnungen, konkret bei ihrer Nummerierung: Die Proforma-Rechnungsnummern haben nun den Präfix “U-” bekommen. Hintergrund war zunächst, dass wir neben Uberspace auch einige größere Serverkunden haben, die wir über ein anderes Buchhaltungssystem abrechnen, das ebenfalls mit Rechnungsnummern arbeitet - und die Nummern der Proforma-Rechnungen nähern sich jenen Rechnungsnummern langsam aber sicher an, was zu Missverständnissen führen könnte. Der Präfix hatte dann aber auch noch einen Nebeneffekt: Da wir jene Verwendungszwecke nun an eben jenem Präfix gut automatisiert erkennen können, konnten wir auch für jene nun eine automatische Einbuchung realisieren. Bisher war das Handarbeit, denn eigentlich sollen Überweisungen ja immer mit dem Usernamen im Verwendungszweck erfolgen, was auch auf den Proforma-Rechnungen so vermerkt ist. Aber Gewohnheiten ändern sich nur langsam, und so gibt es immer wieder Leute, die dann doch mit der Rechnungsnummer überwiesen haben, was dann wiederum Handarbeit für uns beim Einbuchen bedeutete.

Auch im Bereich OnCall gibt’s wieder ein Vorankommen: Die bestehende Dokumentation, die jenen, die gerade Bereitschaft haben, leichte Antworten auf die Frage liefern soll, was genau geprüft oder unternommen werden soll, wenn dieses oder jenes passiert, wurde nun so umgebaut, dass wir in den automatischen Alerts, die wir von Prometheus über den Alertmanager erhalten, nun Runbook-Links haben, die unmittelbar auf die zum Alert gehörende Dokumentation zeigen. Denn seien wir ehrlich: Wer nachts um vier rausgeklingelt wird, dessen Gedächtnis ist da vielleicht nicht gerade in Bestform, und eine klare “prüfe dieses, tue jenes”-Anweisung wird dann sehr dankbar angenommen. Aber natürlich geht es auch darum, zu vermeiden, überhaupt nachts rausgeklingelt zu werden - vor allem wegen Dingen, die schon tagsüber hätten erledigt werden können. So arbeitet unser Plattenplatz-Monitoring nun dreistufig, mit verschiedenen Prioritäten, die teils eben schon großzügiger als früher - aber nur während der normalen Arbeitszeiten - warnt, wenn sich irgendwo ein Blockdevice langsam füllt, bevor es zu einem Engpass kommt, der mitten in der Nacht jemanden rausklingeln muss. Mit den neuen Warnstufen können wir dem besser vorbeugen - für ruhigeren Schlaf und damit mehr Energie und Konzentration am Tag.

Zum Schluss noch eine Nachricht, die mit einem lachenden und einem weinenden Auge daherkommt: Sabrina wird unser Supportteam zum Ende des Jahres verlassen. Zwar war es von vorneherein klar, dass ihre Tätigkeit bei uns nur studienbegleitend ist und insofern irgendwann ein Ablaufdatum haben wird, aber nichtsdestotrotz kam es dann doch irgendwie sehr plötzlich. Mit weiterhin großer Verbundenheit verabschieden wir Sabrina mit den besten Wünschen für ihre künftige Doktorandinnenstelle - und haben aber auch schon ein paar gemeinsame Hintergedanken, wie sie uns auch in Zukunft noch ein bisschen erhalten bleiben kann.

Und damit schließe ich für heute das Logbuch erstmal wieder, mit urlaubsmäßig frisch durchgepustetem Kopf, ein wenig wehmütig, aber voller guter Wünsche für die Zukunft. Wenn’s klappt, lesen wir uns an dieser Stelle so in knapp zwei Wochen nochmal, ansonsten wieder im neuen Jahr. Euch allen eine gute Zeit, bis dahin,

J.

• ← Previous Post
• Next Post →