datenklause.de » FreeBSD

Schreck lass nach

sirko — Wed, 16 Jun 2010 11:58:30 +0000

Immer wenn ich ins Büro komme und das alte, letzte Woche ausgetauschte Storage-System auf dem Basteltisch sehe, kriege ich einen mittleren Schreck. Ach ja, das ist ja das alte. Was sich nach dem Ausschalten übrigens nicht wieder einschalten ließ.
Und das neue System in Betrieb zu nehmen, war auch keine leichte Geburt. FreeBSD 8.0 mit ZFS als NFS-Server mit UDP zickte an einigen Ecken (mbuf Leakage, Infinite Retry Loop), Jumbo-Frames funktionieren immer noch nicht.
Aber so ist das an der blutigen Kante. Der Umstieg beschert erst einmal zahlreiche schlaflose Nächte, dafür klopft man sich hinterher jahrelang auf die Schulter. ZFS kommt dem, was ich mir vor drei Jahren gewünscht habe schon ziemlich nahe, es ist nur noch kein verteiltes Dateisystem. Aber skalierbar. Skalierbar! Es ist einfach nur praktisch, die Dateisystemgröße während des laufenden Betriebes ändern zu können, indem man einfach die Festplatten nacheinander austauscht und in den Pool integriert. Und von SSD-RAIDs als L2ARC und ZIL Devices für den Pool habe ich damals noch nicht einmal zu träumen gewagt.

IO-Killer

sirko — Tue, 13 Apr 2010 11:30:21 +0000

Wir hatten hier einen Kunden, der es geschafft hat, mit einer zweistelligen Anzahl von Script-Aufrufen am Tag ein echter IO-Killer zu werden.
Wie er das gemacht hat? Mit seiner php_error.log.
Ja, wirklich. In einem seiner Scripte ist ein Loop, die php_error.log wuchs in nur einer Stunde auf 116 MB. Es werden megabytegroße Brocken bei jedem Script-Aufruf via NFS zu den Fileservern übertragen.
Nein das war es noch nicht. Man versuche sich nur einmal vorzustellen, was passiert, wenn der Surfer bei seinem Browser den Reload-Button drückt und die Datei vom anderen Prozess ja noch gelockt ist, weil der megabyteweise Fehlermeldungen schreiben will, bis er durch die Laufzeitbeschränkungen gekillt wird. So etwas kann sich wunderschön hochschaukeln. Hossa!
Wir bauen uns jetzt ein neues Accounting-Tool. Das Accounting von FreeBSD mit sa ist ja ganz nett, aber zum Erkennen von Übeltätern bei kurzen Lastspitzen von IO auf einem Load Balanced Cluster völlig ungeeignet. Was wir brauchen, ist eine Auswertung für frei wählbare Intervalle und verschiedene Kriterien (CPU, Anzahl der Aufrufe, Disk-IO und CPU Storage Integral) auf allen Servern insgesamt und nicht eine Gesamt-Auswertung bis zum letzten Rotation der Accounting-Datenbank auf einzelnen Webservern. Scheint auf den ersten Blick ziemlich einfach umzusetzen zu sein, wir rotieren einfach jede Minute und schreiben die absoluten Accounting-Daten in eine zentrale MySQL-Datenbank. Und die kann man ja dann ganz einfach nach Belieben abfragen, sortieren oder sogar zusammengefasste Verlaufskurven für einzelne Kunden auf dem gesamten Cluster erstellen.

Adieu ipfw.

sirko — Thu, 04 Mar 2010 02:04:02 +0000

Nachdem über vier Jahre ipfw und pf parallel auf unserem Router liefen, war es vor einigen Minuten soweit, ipfw in den Ruhestand zu schicken. pf hat sich bewährt, die Syntax ist einfach, die Funktionalität ist super. Ich weiss nicht, ob Ihr abschätzen könnt, was für ein Aufwand die Übersetzung der Regeln bedeutete: Hut ab vor meinem fleißigen Kollegen. So, und jetzt gehen wir ins Bett. Probleme sind nicht zu erkennen, Nagios zeigt nur grün, falls Irgendetwas doch noch zickt sehen wir das in der Nacht eh nicht.
Und sechs Stunden Schlaf sollte man vor dem nächsten Arbeitstag doch haben, oder?

Preußische Administratoren

sirko — Fri, 29 Jan 2010 11:17:29 +0000

Man sagt, wenn der Preuße nicht meckert, ist er nicht glücklich. Findet ein Preuße etwas so richtig Klasse, äußert er seine Begeisterung mit den Worten “Da kann man ja nicht meckern.”

Ich bin Preuße durch und durch.

So und jetzt komme ich mal zum Thema Netzwerkkarten. Über all die Jahre haben wir da so Einige in Betrieb gehabt. Striktes Verbot herrscht inzwischen für Realtek-Chipsätze. Diese Dinger gingen immer schneller kaputt, als man den Server ins Rack geschraubt hatte. Äußerst stabil laufen seit jeher eigentlich nur Karten mit Intel-Chipsatz. Unter FreeBSD war das früher der fxp-, inzwischen der em-Treiber.
Sagen wir mal: Über Karten mit Intel-Chipsätzen kann man nicht meckern.
Es gibt viele Hersteller, die auf die grandiose Idee kommen, mehrere verschiedene NICs auf einem Motherboard zu verbauen, wahrscheinlich aus Kostengründen. Sinn macht das nicht.
Server im Produktionsbetrieb sind bei uns üblicherweise an zwei Netze angeschlossen. Wird das zweite Netz nur zur Konfiguration benutzt, tolerieren wir auch schon mal ein zweites NIC mit anderem Chipsatz, wie vor einer Weile bei einem Board mit einem Intel-NIC und einem von NVIDIA. Das lief einige Monate völlig stabil, schliesslich gab es auf dem zweiten NIC keinen nennenswerten Traffic. Dann wurde das Setup umgestellt und über das zweite NIC lief auch NFS. Was passierte? Das NVIDIA-NIC starb. Ihr wisst, wie eine Netzwerkkarte stirbt? Gaaanz langsam. Schleichend. Man bekommt davon kaum etwas mit. Es gibt keine Fehlermeldung. Bumms, NFS hängt, man kann noch zwischen den Konsolen umschalten aber Einloggen ist nicht mehr drin. Wenn man Glück hat, findet man danach eine Fehlermeldung “kernel: nfs server blafasel… not responding” im Log. Aber nur wenn man Glück hat. Natürlich passiert das mitten in der Nacht, man stapft schlaftrunken bei minus zwanzig Grad durch den Schnee, findet das Logfile ganz sicher ohne irgendwelche Fehlermeldungen vor, startet die Kiste neu und wird vier Stunden später erneut vom Monitoring mit einem SMS-Bombardement geweckt. Am nächsten Morgen ist dann der Support dran, der die verärgerten Kunden beschwichtigen darf. Kennt Ihr Kunden, die sich mitten in der Nacht in einer Mail über irgendetwas ärgern? Nein?
Sie verwenden das gleiche Vokabular wie der schlaftrunkene Administrator bei der nächtlichen Arbeit.

Eine FreeBSD-Story

sirko — Fri, 22 Jan 2010 12:51:53 +0000

Also manchmal könnte man verrückt werden. Zum Beispiel, wenn man sich eine große Maschine – sagen wir mal, im fünfstelligen Preisbereich – kauft und danach feststellt, dass man sie nicht nutzen kann. ZFS ist das einzige Filesystem unter FreeBSD das mit Dateisystemen größer als zwei Terabyte umgehen kann und ACLs unterstützt. Seit Version 8.0 ist ZFS für den produktiven Einsatz freigegeben, auch ACLs werden unterstützt. Nur zu dumm, dass die Userland-Tools wie setfacl oder getfacl noch nicht mit dabei sind. Die gibts erst in der HEAD, der blutigen Kante. Damit kann man aber keine Kiste im Produktionsbetrieb fahren und Webserver ohne ACLs wären… sagen wir mal, die Originaldaten vieler Kunden würden im Sekundentakt durch Malware ersetzt werden.

Nun ja. Ein Hoch auf Open Source Software. Der Entwickler der ACL-Unterstützung für FreeBSD portiert uns jetzt die Tools in die 8.0.
Ja!

ZFS in Betrieb

sirko — Wed, 01 Jul 2009 14:41:23 +0000

Da komme ich aus dem Urlaub zurück und erfahre, dass wir nun einen ersten Server unter FreeBSD mit einem ZFS-Pool am Start haben (natürlich für ein unkritisches System). Ein Kollege meinte, daß “ZFS schneller performt, als alle RAID-Systeme, die wir bisher am Start hatten“.
Und das sind Einige…

Ausblick auf FreeBSD 8

sirko — Fri, 20 Mar 2009 12:50:28 +0000

What’s cooking for FreeBSD 8?
Ohne GCC? Wenn das mal gut geht…
ULE rennt bei uns sowieso schon in Produktion, ja der ist schnell.
Endlich multiple IPs und eigene Firewalls für Jails, die man an eine CPU binden kann.
Lots of ZFS Bugfixes: Hello, I’m still missing ACLs!
Bis zu 6GB Kernel-Memory: Macht Sinn. U.a. für ZFS;-)
Okay, FreeBSD 8 kann als Gast-System im Xen laufen, aber Xen ist doch ein alter Hut, KVM löst ihn doch sowieso allmählich ab?
Die neuen Kernel Threads muß ich mir noch genauer anschauen.
Bis zu 30% mehr Geschwindigkeit auf Prozessoren ab vier Kernen mit Superpages, oho.
Dtrace werde ich mir auch genauer anschauen, Sun hat ja lange einen riesen Wirbel darum gemacht.
Komisch, NFS Kernel Locking läuft doch bei uns seit 6.3 ohne Probleme?
NFSv4 kommt: Testen.