Administrator's Blog

Heute ist es mal wieder so weit, dass ich Apple verfluche und tatsächlich in Erwägung ziehe, keine Computer mehr aus diesem Hause zu kaufen. Morgen sieht das sicher wieder anders aus, zumal auch andere Hersteller derartige Probleme habe. Aber der Reihe nach:

Bei meinem MacBook Pro Late 2009 fehlt einer der 4 Gummifüße am Boden. Dies fiel mir gestern auf und ich weiss leider nicht, wie oder wo er abhanden kam. Aber so schlimm fand ich das gar nicht, denn ich habe ja Apple Care für dieses Gerät abgeschlossen und die würden sicher eine unproblematische Lösung für das Problem haben.

Das erwies sich leider als Tagtraum. Ein nette, wenn auch mit mangelhaften Deutsch-Kenntnissen ausgestattete, Dame an der frecherweise kostenpflichtigen Apple-Care Hotline sicherte mir zu, dass der lokale Apple-Partner um die Ecke die Füße da hat und i.d.R. auf Kulanz gratis tauscht. Das klang toll. Leider wusste der Apple-Partner davon nichts und versicherte mir, dass es die Gummifüße nicht einzeln gibt. Abhilfe schafft wohl nur eine neue Unterseite, die mit mindestens 80 EUR einschlägt. Das erschien mir irgendwie zuviel für einen fehlenden Gummifuß. Immerhin "friemelte" der nette Herr einen Gummifuß von einem defekten Unibody-MacBook Pro ab und gab ihn mir mit.

Der passte jedoch nicht, da man die Füße nicht unbeschadet aus einem intakten Unterboden herausbekommt - warum auch, schließlich ist das sicher nicht vorgesehen. Aus Frust folgt ein weiterer kostenpflichtiger Anruf bei Apple-Care. Diesmal hatte ich einen netten Mann am Telefon, der sogar meine Sprache konnte. Ironischerweise versicherte er mir ebenfalls, dass es die Füße nicht einzeln gibt und äußerte ein wenig Unverständnis über die Aussage seiner Kollegin von vorher. Selbstverständlich sind solche Sachen übrigens nicht von Apple-Care abgedeckt, wäre ja auch zu schön gewesen.

Jetzt hatten sie mich tatsächlich so weit, dass ich für 80 EUR beim lokalen Partner einen kompletten neuen Unterboden bestellen wollte. Schließlich habe ich hier ein MacBook Pro für über 2000 EUR rumliegen und es kann wohl nicht angehen, dass dieses Teil auf dem Tisch kippelt.

Doch der Schock folgte beim optimistisch getätigten Bestell-Anruf für den Unterboden. Ich sollte mein MacBook Pro dann mal vorbeibringen und könnte es in einer Woche wieder abholen. Hallo, gehts noch? Die Apple-Richtlinien erfordern es explizit, dass das MacBook Pro die ganze Zeit dort bleibt. Meine Vorstellung war allerdings, dass ich einfach den neuen Unterboden bekomme und diesen dann selbst montiere. Die 10 Schrauben dafür bekomme ich gerade noch verarbeitet. Eine Woche ohne mein Arbeitsgerät mit all seinen Daten drauf sind eigentlich unmöglich.

Ende vom Lied ist jetzt, dass ich den geschenkten Gummifuß nun soweit mit Feile und Schere bearbeitet habe, dass ich ihn mit Sekundenkleber ankleben konnte. Ob und wie lange das hält kann man leider nicht wissen. Auf jeden Fall mal wieder nicht gerade ein Service-Highlight von Apple. Bei dem Preis für Apple-Care eigentlich eine Frechheit.

Viele unserer (Web)Server loggen auf einen zentralen Logging-Server, der via syslog-ng die Logdaten einsammelt und einheitlich zur Verfügung stellt. Besonders bei Webclustern, wo ein Loadbalancer die Anfragen auf diverse Server verteilt, ist z.B. ein zentrales Apache-Logfile u.A. für die Logfile-Auswertung wünschenswert. Außerdem kann man dann mit logcheck nette Security-Auswertungen etc. für alle Server gemeinsam machen und muss dies nicht auf jeder Kiste einzeln tun.

Bisher lief der Logging-Server auf Linux-Basis, nachts wurden die zig GByte großen Logfiles des letzten Tages dann komprimiert. Das hat soweit auch ganz gut funktioniert, nur leider wird es an der Stelle nervig, wenn man in den Logfiles der letzten Monate etwas sucht und dann beispielsweise 200 GByte an GZIP-Files durchsuchen muss. Ganz davon abgesehen sorgte die nächtliche Komprimierung via logrotate (GZIP) doch für eine ordentliche Serverlast über Stunden hinweg (CPU und I/O gleichermaßen).

Als Lösung fiel die Wahl jetzt auf FreeBSD 8.1 als OS für den Loghost. Filesystem ist, wie könnte es anders sein, nun ZFS! Und dank "eingebauter" Komprimierung ist die Verwaltung der Logfiles jetzt deutlich angenehmer. Auf Filesystem-Ebene via GZIP komprimiert ergibt sich für den Nutzer kein Nachteil, die CPU-Last wird nicht mehr auf die Nacht verteilt, sondern permanent beim Schreiben der Files - aber eben kaum merklich, da konstant und minimal. Die Kompressionsrate ist identisch mit der früheren Kompression unter Linux. Neben GZIP stand noch LZJB als Methode zur Auswahl. Das soll wohl schneller sein, komprimiert aber nicht so akkurat wie GZIP.


Wie erstellt man nun ein solch komprimiertes Filesystem via ZFS?

Man erstellt einen zpool z.B. als RAID-1 via:

zpool create data mirror /dev/da1 /dev/da2

Nun erstellt man das Filesystem via:

zfs create -o compression=gzip -o mountpoint=legacy data/varlog

Mit -o gibt man die Optionen an, hier gzip. Default ist die Kompression auf Stufe 6 (=ausgewogen) eingestellt, man könnte aber auch gzip-9 für maximale Kompression verwenden.

mountpoint=legacy bedeutet, dass ZFS sich nicht um die Verwaltung des Mountpoints kümmert. Default würde dies sonst unter /data/varlog gemountet werden. Da wir aber /var/log haben möchten, behelfen wir uns mit diesem Eintrag in der /etc/fstab:

data/varlog /var/log zfs rw 1 0

Tricky war allerdings, dass der Installer selbst dies nicht zur Verfügung gestellt hat (zumindest haben wir es nicht gesehen..). Daher wurde normal mit UFS installiert und anschließend die neue Partition erstellt, gemountet und mit den Inhalten aus der alten UFS-Partition gefüllt. Eine etwas umständliche Methode, die allerdings problemlos funktioniert hat.

Die Kompression kann man via ls und du sehr gut nachvollziehen, da ls die ursprüngliche Dateigröße anzeigt. Mit du sieht man dann die tatsächliche Größe auf Platte:

# l -h apache_central.log-20110109
-rw------- 1 root wheel 3.9G Jan 9 06:25 apache_central.log-20110109

# du -sh apache_central.log-20110109
412M apache_central.log-20110109

Insgesamt ein sehr nettes Szenario, um Speicher zu sparen und Logfiles dauerhaft vorzuhalten, ohne sich durch viele GZIP-Files wühlen zu müssen. Die Performance ist ingesamt gut, es gibt eigentlich keine Probleme trotz sehr großer Logfiles, die täglich anfallen.

Ich bin ja ein gebrandmarktes Kind, was Internet-Geschwindigkeit angeht. Schließlich hatte ich dank meiner vorherigen "schlechten" Wohnlage (hier ein Posting aus 2006 dazu) noch lange nur ISDN zur Verfügung, wo meine Kollegen alle schon mind. 6000er DSL oder sowas hatten. Der blanke Hass war das, ehrlich. Immerhin konnte ich Downloads auf Arbeit tätigen, denn da gab es schon lange eine 100MBit/s Leitung danke des direkten Anschlusses an unser Rechenzentrum. Schon eine echte Flatrate war damals ein Traum, von 10, 50 oder gar 100Mbit/s zu Hause konnte ich nur träumen.

Die letzten Jahre 3 hatte ich dann allerdings erst 16.000er DSL von Alice und bisher eine 32.000er Leitung via Kabel Deutschland. Allein der Upload von nur 1-2 MBit/s nervte, besonders beim Abgleich von Fotos zu Flickr oder anderen Diensten mit entsprechend hohem Datenaufkommen von zu Hause aus.

Da kam das neue Angebot von Kabel Deutschland mit bis zu 100MBit/s down und 6Mbits/s up für mich wie gerufen. Es ist erst seit ca. einer Woche hier in Dresden verfügbar, daher gehöre ich quasi zu den ersten Kunden vor Ort, die den Spaß nutzen dürfen.



Und es ist wirklich ein toller Spaß, denn die versprochene Datenrate wird wirklich fast erreicht. Dazu trägt einerseits das neue Cisco-Kabelmodem (wow, endlich Markenware auch zu Hause) Cisco EPC3212 mit Gbit-Ethernet und andererseits natürlich meine Apple Time Capsule mit 5GHz WLAN @ 300Mbit/s bei. Ein normales 54MBit-WLAN würde natürlich hier nicht mehr reichen.

Insgesamt also soweit sehr empfehlenswert und, wenn der Speed dauerhaft so hoch und konstant verfügbar ist, preislich durchaus in Ordnung. Klar, der Upload könnte noch schneller sein, aber das wird wohl privaten Haushalten noch lange vorenthalten werden.

Das Advanced Format für Festplatten bringt mehr Platz für Daten auf dem gleichen Platz einer Festplatte. Eine wirklich gute Sache, die aktuell vor Allem Western Digital voranzutreiben scheint (eine WD "Fachinformation" dazu gibt es hier als PDF).

Versprochen wird bessere Fehlerkorrektur und Kompatibilität mit Windows sowie OS-X. Leider taucht hier Linux vorerst nicht auf, da das Advanced Format erst ab 2.6.31 unterstützt wird. Die meisten Server-Distributionen (Debian stable etc.) setzen jedoch natürlich nicht auf einen so aktuellen Kernel.

Dieses Problem hatten wir bereits mit mehreren Systemen sowohl unter Linux aus auch unter FreeBSD. Trotz RAID-10 mit 4 WD20EARS 2 TB Platten und aktueller Hardware kamen wir unter Debian kaum über 20 MByte/sec Transferrate (dd mit oflag=direct, mit oflag=dsync sogar nur 13 MByte/sec). Auch die Anpassungen der Blocksize via fdisk halfen leider nicht weiter, da i.d.R. bei einem Server ja noch ein RAID-Controller dazwischenhängt. Was sich dort genau abspielt, konnten wir nicht herausfinden. WD beschreibt dieses Vorgehen zwar selbst auf seinen Support-Seiten, Hilfe brachte es aber dennoch nicht.

Ob dieses Vorgehen bei direkt angeschlossenen Platten, also ohne RAID-Controller, womöglich zu einem normalen Datendurchsatz führt, bleibt mangels Test derzeit hier noch unbeantwortet. Für die meisten Serversysteme ist dies allerdings sowieso nicht relevant, da dort normalerweise ein RAID erwünscht ist.

So blieb in allen Fällen bisher nur der Einsatz anderer Platten, die nicht das Advanced Format einsetzen. Das gleiche RAID 10 hat nun dank Seagate-Platten locker den 6-fachen Durchsatz. Generell ist, sofern man nicht eine Distribution mit aktuellem Kernel wie Ubuntu 10.04LTS mit 2.6.32 benutzt, die Verwendung von "normalen" Festplatten wohl die bessere Wahl.

Immer mehr ISPs packen in ganz normale Server-Angebote eine SSD bzw. man kann sie optional dazu buchen. Jüngst hatten wir ein Kundensystem zur Administration, wo das der Fall war. Der Server hatte konkret 4 x 1 TB SATA II Platten (RAID 10) an einem RAID-Controller und eine Intel 80 GB SSD direkt am SATA-Controller. Der Kunde hatte natürlich gehofft, mit der SSD seinem Server den gewissen Performance-Kick geben zu können, denn bekanntermaßen sind SSDs einfach unglaublich schnell.

Der ISP hatte spontan direkt das Linux-Sytem auf der SSD installiert, wohl um die tolle Performance beim Bootvorgang etc. auszunutzen. Das ist ja auch gut und schön, nur wozu hat man denn dann ein RAID 10? Wenn die SSD mal ein Problem hat, war es das für den Server. Für ein Produktivsystem eher ungeeignet. Also installierten wir das System auf dem RAID 10. Doch was nun auf die SSD? Die Datenbank wäre eine gute Sache, doch auch hier mangels Redundanz nicht empfehlenswert. Denn einen kompletten Datenbank-Fail nach SSD-Problemen will man natürlich auch nicht haben. Also die DB auch auf das RAID 10. Selbiges gilt für Web- und Anwendungsdaten.

So bleibt eigentlich nur, die SSD für Swap oder /tmp bzw. andere Temporäre-Daten wie PHP-Sessionfiles etc. zu verwenden. Dafür lohnt sich aber eigentlich das Ganze nicht. Wären allerdings 2 SSDs im RAID1 drin, sähe die Sache schonmal anders aus.

Das dachte sich wohl auch Serverloft und schreibt bei EINER SSD direkt mal RAID1 dahinter - was auch immer das bedeuten soll. Der Preis ist allerdings wirklich sehr gut, wobei die oben genannten Probleme natürlich auch hier wieder mangels einer 2. SSD wieder zutreffen.

Fazit:
SSD im Server zum Produktiveinsatz macht eigentlich nur unter speziellen Bedingungen (viele temp. Files, Caching etc.) oder als RAID mit mind. 2 SSDs Sinn.