a sysadmin's life

Nachdem vor einigen Tagen ja das FreeBSD 6.0 RELEASE rausgekommen ist und ich im Vorfeld (eifrige Leser meines Blogs erinnern sich vielleicht) ja schon einiges an Tests gemacht habe, habe ich mir heute eine Dosis Adrenalin gegönnt:

Der erste Application Server des Core Systems ist heute auf RELENG_6 upgedated worden! Das Update (via Sourcen) habe ich komplett remote vorgenommen. Zunächst die neue Welt und den neuen Kernel bauen, dann den Kern installieren, im Singleusermode die Welt installieren und ein paar geringe Anpassungen vornehmen. Im Multiusermode habe ich die alten Libraries entfernt und alle installierten Pakete neu installiert. Auch hier gab es keine Probleme. Und so ist der Server jetzt mit allen Diensten wieder online.

Die Belastungsprobe kommt dann morgen, wenn die Maschine wieder mit ins Loadbalancing aufgenommen wird. Besonders gespannt bin ich auf den direkten Vergleich in der Performance gegenüber der gleichen Hardware unter FreeBSD 5.4-STABLE (SunFire V20z, Dual Opteron Maschinen), auch wenn ich bei der genutzten Software keine erheblichen Unterschiede erwarte, da nur wenig Threading im Spiel ist. Aber durch deutlich weniger Giant-Locking soll FreeBSD 6 ja durchaus gerade auf SMP-Systemen auch ohne Threads noch ein wenig an Performance nachlegen.

Es bleibt also spannend, Neuigkeiten gibt es sicher bald an dieser Stelle!

Ich hatte ja im Juli schon einmal über einen ersten Eindruck von FreeBSD 6 geschrieben. Mittlerweile sind zweieinhalb Monate vergangen, die Entwicklung ist einen Schritt weiter und ich hatte eine Chance, RELENG_6 (bzw. BETA5) auf einem Dual Opteron System zu testen. Ich habe die Maschine mit dd, bonnie++ und anderen Dingen, die das Filesystem belasten, gequält. Ich habe ein make -j80 buildworld mehrfach laufen lassen, ich habe ein natives JDK 1.5 (bootstrapped über JDK 1.4.2 im Linuxulator) gebaut. Ich habe Filesystem-Snaphots angelegt und gelöscht. Na eben alles, womit man so ein Maschinchen ein wenig aus der Reserve locken kann. Die Maschine läuft äußerst stabil und schnell. Ich habe bisher nur einen Weg gefunden, das System zum Hängen zu bringen, indem ich per sysctl oder powerd besonders niedrige Taktraten für die Prozessoren einstelle. Ich bin sicher, daß dieses Problem auch noch behoben wird, aber für meinen Anwendungsfall als Server im 24/7 Lastbetrieb sind diese Energiesparfunktionen eh unwichtig.

Ich werde mich trauen, demnächst (immerhin stehen wir kurz vor der 6.0-RELEASE) die ersten ein oder zwei Maschinen unter FreeBSD 6 in einen Produktionsbetrieb zu geben. Für Nachahmer sei hier nochmals der Hinweis gegeben: Don't do this at home kids! Die Rechner werden in einer Umgebung mit eng definierten und testbaren Aufgaben stehen und die Datenhaltung erfolgt auf einem anderen Server über NFS bzw MySQL. Zudem sind sie redundant ausgelegt. Wenn die mal crashen - und solange das FreeBSD-Team nichts anderes sagt ist 6 noch eine BETA! - dann sind die Auswirkungen peripherer Natur, will sagen, das merkt außer dem Loadbalancer kaum jemand. Wenn es denn soweit ist in den nächsten ein bis drei Wochen, dann werde ich hier sicher nochmal den dritten Teil der Geschichte zu erzählen wissen.

Ich konnte es, nachdem ich mir endlich ein neues Notebook gegönnt habe, ja nicht sein lassen und mußte auf meinem alten Notebook mal ein die BETA1 von FreeBSD 6.0 ausprobieren.

Die Bezeichnung BETA trägt die aktuelle Version noch ganz zu recht, wie allein die Installation offenbart. Neben Problemen mit dem CDROM (ich habe letztlich über NFS installiert) fiel mir im wesentlichen auf, daß offenbar die Integration des neuen DHCP Clients in sysinstall noch kein brauchbares Maß angenommen hat - zu deutsch: feste Netzwerkeinstellungen benutzen.

Nach der Installation mußte ich natürlich zunächst mal den wpa_supplicant testen - endlich weg von meinem alten netconf script, hin zu einer ins System integrierten Methode, automatisch ein bekanntes WLAN auszuwählen. Die manpage ist für den WEP-Fall leider eher noch wenig informativ, nach ein wenig suchen im Netz ist es jedoch recht einfach, eine passende Konfiguration zu erzeugen. Nachdem die dann drin war, klappte es auch ganz gut - bis auf die Tatsache, daß ohne Fehlermeldung die Netzverbindung irgendwann kommentarlos abbrach und auch nicht so einfach reaktiviert werden konnte. Ich hab's dann erstmal nicht weiter untersucht und mich lieber daran erfreut, daß Ziehen und Stecken des Netzwerkkabels mittlerweile durch den DHCP Client durch entsprechende Aktionen begleitet werden kann.

Eine Panic hab ich noch nicht provozieren können :-) Nach dem Ausschalten der Debugging-Optionen im Kernel und dem Anpassen der malloc flags machte das Notebook aber einen angenehmen Eindruck, was die Performance betraf.

Fazit: Es ist eine BETA, so wie es dransteht. Die Probleme scheinen mir aber eher kleinerer Natur und ich freue mich schon drauf, mal ein paar Lasttests zu machen und Vergleiche mit den laufenden 5er-Maschinen anzustellen, speziell wenn es um threaded applications geht, aber auch hinsichtlich der allgemeinen Performance.

Die große Migration ist ja nun vorüber. Nach ein paarmal Üben in Form diverser Migrationen einzelner virtual ISPs auf das Slave-System haben wir vor ca. drei Wochen (20. bis 22. Mai 2005) den ganzen großen Rest auf die neue Plattform migriert und aus dem Sklaven einen Meister gemacht.

In Anbetracht der großen gewachsenen Struktur des alten Systems haben wohl alle mit ziemlichen Problemen gerechnet - damit, daß uns irgendwelche Legacy-Dinge auf die Füße fallen, daß irgendeine Technik nicht so funktioniert, wie sie soll, eben damit, daß irgendetwas verdammt schiefgehen muß.

Das Migrationswochenende war anstrengend, es war hart für uns alle. Dennoch: Alle vorbereiteten Prozeduren haben wie geplant funktioniert und hielten sich auch ziemlich exakt im geplanten Zeitrahmen. Natürlich hat es am ein oder anderen Detail gewackelt, wo es die User deutlich gemerkt haben. Selbstverständlich gab es Dinge, die hinterher nicht so funktionierten (für den User), wie vorher - und die beim Test nicht berücksichtigt worden waren und nicht berücksichtigt werden konnten. Aber im großen Überblick hat es verdammt gut geklappt.

Am Montag stellte sich heraus, daß wir etwas mehr Rechenleistung benötigten, aber auch das konnten wir mit zwei weiteren Maschinen und deutlichen Optimierungen unter Last während innerhalb der Woche mit nur geringen Beeinträchtigungen für die Benutzer, vor allem aber ohne Datenverluste oder ähnliche Katastrophen beheben. In den letzten zwei Wochen sind an besonders sensiblen Stellen - ich nenne mal den CGI Server mit seinen tausenden von CGI-Scripten unserer User oder das völlig neu strukturierte Mailsystem - immer wieder Kleinigkeiten aufgefallen. Aber alles in einem Rahmen, der schnell lösbnar war, einfach will ich nicht in jedem Falle sagen.

Und warum ich das alles schreibe? Weil ich's einfach mal zusammenfassen wollte und mich bei meinen Kollegen, die dieses Blog zum Teil auch lesen, bedanken wollte. Besonders gilt dieser Dank natürlich dem harten Kern der Technik: Adrian (Sysadmin, Mail&Web Config), Marcel (Entwickler), Marko (Oracle und Radius) und Sebastian (Netzwerk, Loadbalancing, Hardware) - wir waren einfach ein verdammt gut funktionierendes Team. Und obwohl an keinem der Streß spurlos vorbeiging, gab es keine Reibereien und jeder hat zu jedem Zeitpunkt überdurchschnittlichen Einsatz gezeigt. Das hat einfach motiviert und Spaß gemacht.

Weiterer Dank gilt auf jeden Fall unserer Hotline, die die Sorgen der User ernstgenommen hat und uns mit gut aufbereiteten Informationen versorgt hat, um die entstandenen Probleme schnell und zur Zufriedenheit der Nutzer zu beheben. Ihr habt's keinen von uns hinten merken lassen, aber ich nehme mal an, manchmal habt ihr uns verflucht für das, was wir Euch da aufgebürdet haben, oder?

Und natürlich möchte ich hier auch Christian danken, der immer aufmunternde Worte bereit hatte, uns von den lästigen administrativen (im nicht-technischen Sinne) Aufgaben freigehalten hat und sicher auch manchmal als Pufferzone herhalten mußte für unser aller Streß - und das klaglos getan hat, auch wenn es nicht immer gerecht war (ihm gegenüber).

Zuguterletzt noch ein Danke an Jörn, der trotz allen Kostendrucksden Aufbau der neuen Plattform ermöglicht hat und uns bei unseren Lastproblemen mit seinem kurzfristigen Eingreifen und der Beschaffung der neuen Maschinen sowie seinen wie immer glänzenden Ideen, wenn es mal knifflig wurde, salopp gesagt an der ein oder anderen Stelle den Arsch gerettet hat.

Ich kann einfach aus vollstem Herzen sagen: Das beste Team, in dem ich jemals die Ehre hatte zu arbeiten!

Gestern war es dann endlich so weit. Nach langer Zeit fand ich Motivation und zeit, den IRC-Server endlich auf 2.11 upzudaten. Immerhin war ich wohl der fünftletzte im IRCnet - die Migration war aber auch sowas von überraschend schnell diesmal, da kann ja keiner mit rechnen. Und abgesehen davon habe ich schlißelich ja auch noch einen Job, mit dem ich Geld verdiene. Und der ist derzeit auch nicht wirklich ohne. Und wenn dann noch die Technik zu Hause rumzickt, so wie vorletzte Woche, dann frag ich mich schon manchmal, warum ich mir das alles antue. Wenn dann aber alles läuft und ich mit einem gewissen Stolz auf mein Werk schauen kann, dann weiß ich es meist wieder. Admins und Künstler sind in der Hinsicht vielleicht gar nicht mal so unterschiedlich.