LL#6 – Liebes Logbuch…
…endlich ist Uberspace 7.15 draußen, mit dem es endlich den lang ersehnten Support für DKIM gibt - und einen ganzen Haufen neuer Versionen: PHP bietet jetzt auch Version 8.2, node.js auch Version 18 und 19, .NET die Version 7, und für PostgreSQL stellen wir die Versionen 14 und 15 bereit. Wovon die Trennung weiterhin schwerfällt, ist PHP 7.4 - nach monatelanger Vorankündigung des End-of-Life-Termins und angekündigter Umschaltung auf PHP 8 gab es dann doch hier und da noch eine ganze Reihe Supportanfragen, und oft auch die erschrockene Erkenntnis, das Software, die heute noch nicht mit PHP 8 kann, in der Regel selbst schon ganz schön Staub angesetzt hat und vielleicht selbst ein Update vertragen könnte. Wie bisher kümmern wir uns darum, die Software, die Uberspace für euch ausmacht, aktuell zu halten - bitte kümmert euch analog dazu um die Software, die ihr selbst installiert. Danke! <3
Beim Operations-Team ging’s mit Hardware-Ausbau weiter. An unserem Standort FRA4 haben wir zusätzliche neue Verkabelung zwischen Racks bekommen, die es ermöglicht, nun auch dort mit dem Aufbau eines Proxmox Backup Servers zu beginnen, der unser bestehendes rsync-Backup (das allen unter /backup bereitsteht) künftig noch mit einem zweiten Backup mit dem Schwerpunkt Disaster Recovery zu ergänzen. Und während dort der Aufbau voranschreitet, ist an FRA3 der Meilenstein erreicht: Alle dort laufenden VMs werden nun zusätzlich im PBS gesichert. Am dortigen Standort haben wir auch noch einen weiteren PBS dazugenommen, damit es hier keine Engpässe gibt. Und währenddessen beginnt an unserem Standort FRA1 - wo wir keine Uberspace-VMs, aber andere Kundensysteme und einige interne Dinge stehen haben - der Aufbau eines weiteren Proxmox-Clusters, der dann auch das Hosting der dortigen VMs mittelfristig übernehmen wird.
Ceph-Cluster-Upgrades (also von einer Major-Version auf die nächste) sind nun ebenfalls etwas, was in der Vergangenheit viel Handarbeit gemacht hat - und nun aber von Ansible erledigt wird: Node für Node wird upgedated und dessen OSDs einmal neu gestartet, um sich mit neuer Version wieder in den Cluster einzufügen - und wir müssen nur noch zuschauen und nur einspringen, wenn was nicht klappt. Nach entsprechenden Tests sind nun die beiden Cluster an FRA3 und FRA4 erstmalig auf diesem Weg aktualisiert worden - null Downtime.
Schraubarbeit findet auch virtuell an der nächsten Uberspace-Version statt. Das Aufsetzen neuer VMs mit EFI als Bootsystem läuft nun nach einigem zermürbenden Debugging reibungslos. Nächstes Etappenziel: Die komplette Automation der Installation. Bisher war das initiale Aufsetzen einer neuen VM noch Handarbeit in Proxmox, und erst danach wurde ein Ansible-Playbook losgelassen, was aus dieser Basis-VMs eine Uberspace-VM gemacht hat. Künftig wollen wir uns auch diesen ersten Schritt automatisieren. Mal schauen, wie’s klappt!
Unser Monitoring erfährt permanente Liebe. Das war nicht immer so, aber je besser am Ende alles funktioniert, desto mehr motiviert es auch. Es ist immer ein bisschen schwierig, CPU-Auslastung zu überwachen, denn es gehört ja nun mal zum Wesen von Shared Hosting, dass sich mal diese und mal jene Nutzerin CPU-Zeit nehmen kann - die CPU-Kerne sind ja letztlich auch dafür da, um auch benutzt zu werden. Alarme auf hoher CPU-Nutzung sind daher aber auch nur so mittelpraktisch, denn oft genug nutzt eine Userin zwar mal vorübergehend viel CPU-Zeit, aber die stand eben auch zur Verfügung und insofern hat das gar kein Problem gemacht. Neu ist nun, dass wir vor allem ein Auge auf die CPU-Steal-Werte haben, also wo VMs tatsächlich CPU-Zeit nutzen, die anderswo auch gebraucht würde. Im Ergebnis erhoffen wir uns davon bessere Diagnose von Engpässen, und gleichzeitig aber auch möglichst nur noch dann Alarme im OnCall, wenn auch ein tatsächliches Problem entsteht. Und schließlich hat auch der Mail-Bereich noch einige Werte von Dovecot, Haraka und rspamd dazubekommen, die uns hilfreich erschienen.
Durch den Wechsel auf performante SSDs und Verbesserungen am Bootprozess sind wir inzwischen soweit, dass ein Bootvorgang eines U7-Hosts sich nur noch in einem Bereich von ca. 1-2 Minuten bewegt. Damit konnte nun endlich ein kleines internes Projekt realisiert werden, das wir schon lange auf dem Schirm hatten, nämlich: Gelegentlich Reboots von VMs durchzuführen, die eine sehr hohe Uptime haben. Das mag erstmal Verwunderung auslösen, gilt doch eine hohe Uptime in der Regel als Zeichen hoher Stabilität. Nun ist es allerdings auch so, dass gar nicht mal so wenige Applikationen schlicht Arbeitsspeicher “zumüllen”, also mit der Zeit immer mehr und mehr RAM verbrauchen. Zwar haben wir RAM-Limits pro Nutzerin, aber das hilft eher bei einzelnen Prozessen, die völlig ausufern, nicht so sehr, wenn es viele Prozesse gibt, die alle so ein bisschen den RAM vollaufen lassen. Schließlich gibt es auch im laufenden Betrieb immer wieder Updates auch von Libraries, wo weiterhin laufende Prozesse von Nutzerinnen immer noch die vorherige Library-Version benutzen - eben bis sie einmal neu gestartet werden. Nun ließe sich das zwar sehr selektiv auf die betreffenden Prozesse anwenden; angesichts der kurzen Dauer einer reboot-bedingten Downtime ist es allerdings viel pragmatischer, das periodisch einfach für alle Prozesse durchzuführen, in dem die gesamte VM einmal neustartet. Keine Sorge: Sie laufen auch weiterhin monatelang am Stück; das ist also nichts, was jetzt jede Nacht oder so passieren würde. Nebeneffekt: Es deckt dann auch etwas früher auf, wenn ein Dienst nicht reboot-sicher konfiguriert war, also z.B. nur per Hand gestartet wurde statt als supervisord-Service eingerichtet zu werden. Mit etwas öfteren Reboots als nur alle paar Jahre mal gibt es auch bessere Chancen, so etwas ein bisschen zeitnäher zu bemerken.
Was uns in letzter Zeit Kopfzerbrechen gemacht hat, waren bündelweise neu angelegte Accounts, die einzig und allein dafür genutzt worden sind, um ein Spamtool darauf zu installieren und so viele Mails wie möglich rauszuhauen. Wir haben im Hintergrund eine ganze Reihe an Gegenmaßnahmen erarbeitet, die dafür sorgen, dass derartige Accounts nicht mehr erst durch Beschwerden auffallen und dann manuell gesperrt werden müssen, sondern dass Automatismen das auf Basis verschiedener Kriterien binnen Sekunden erledigen - und in den Logfiles zu sehen, wie Spammer ein Spamtool hochladen und bereits der erste Zugriff per Browser in einem HTTP-Status 403 resultiert, sorgt schon durchaus für eine gewisse Befriedigung. Am Ende ist es ja auch wichtig, dass wir unsere Mail-Reputation anderen Mailservern gegenüber möglichst positiv halten - schnelles Reagieren auf Abuse-Meldungen gehört insofern mit dazu, aber eben auch so wie hier ein proaktives Eingreifen, um zu vermeiden, dass es überhaupt zu einem Spamvorfall kommt.
Was gerade im Hintergrund läuft, ist auch noch eine größere Runde Updates: Bislang haben wir auf unseren Uberspace-VMs MariaDB 10.3 eingesetzt. Die Versionsserie wird auch noch weiterhin mit Updates gepflegt, allerdings nicht mehr lange: Im Mai dieses Jahres ist damit Schluss. Um uns etwas mehr Spielraum zu verschaffen, bekommen die Uberspace-VMs nun sukzessive nicht nur Updates auf die 10.4, sondern dann auch gleich auf die 10.5 und dann auf die 10.6, die die aktuelle Long-Term-Support-Version darstellt. Die Updates laufen nach und nach, es wird jeweils ein zusätzliches Backup zwischen jedem Versionswechsel gemacht, damit auch wirklich nichts schiefgeht.
Last but not least… was wir auf dem Teamtreffen im letzten Herbst begonnen haben, fand nun seine Fortsetzung: Nämlich eine Lohnrunde, bei wir alle gemeinsam unsere Gehaltsvorstellungen für die nächsten sechs Monate teamintern transparent machen, zunächst anonym, dann personenbezogen, und darüber sprechen, was wir uns leisten können und wollen - oder auch leisten müssen, denn dass Energiekosten und Inflation in jedem einzelnen persönlichen Portemonnaie spürbar sind, ist ja kein Geheimnis. Die Planung, damit in zwei Stunden durchzukommen, erwies sich zwar als ein wenig zu ambitioniert; am Ende haben wir - durchaus verbunden mit einer Einigung auf die Löhne bis zur Jahresmitte - eine ganze Reihe an Learnings mitgenommen, was wir bei der nächsten Lohnrunde besser machen wollen, und außerdem eine ganze Reihe an finanzbezogenen Themen, die in unterschiedlichen und kleinen Gruppen besprochen werden und aufzeigen, dass Transparenz beim Gehalt eigentlich nur ein Anfang sein kann. Auch wenn es vielleicht erstmal knirscht und immer noch neu und ungewohnt ist: Wenn in der Vergangenheit lediglich der Umstand der Intransparenz (sprich, jeder verhandelt sein Gehalt mit dem Chef) dafür gesorgt, dass Konflikte auf den Tisch kommen, dann ist es gut, wenn sie eben jetzt auf den Tisch kommen. Was uns dennoch eint, ist die Zuversicht, mit diesem Weg enger zusammenwachsen zu können.
Soviel für heute - diesmal unvermeidlich mit dreifach donnerndem Helau aus Mainz. Bis in Bälde!
J.