Um Strom zu sparen, wird der Schreib-/Lesekopf nach 8 Sekunden Inaktivität in die Parkposition gefahren (WD nennt das ItelliPark) - er liegt somit nicht mehr flach auf den Datenscheiben (Platter) auf, verringert dadurch den Luftwiderstand und hilft so Strom sparen.

Western Digital gibt in der Dokumentation zu den WD Caviar Green-Platten (PDF) 300.000 Load/unload cycles an. Bei 23.771 Cycles nach gerade einmal 300 Betriebsstunden würde das bedeuten, dass wir die spezifizierten 300.000 Cycles bereits nach 5,3 Monaten erreicht hätten.

Füttert man Google mit den passenden Parametern, so findet man nach etwas Recherche das Tool wdidle3 in Version 1.0.3. Gebootet vom USB-Stick via emulierter MS-DOS-Diskette (ein Hoch auf memdisk), verrät einem schließlich das Kommando wdidle3 /r die aktuelle Einstellung der erkannten Platten.

Mit wdidle3 /? bekommt man eine Auflistung der möglichen Parameter, wdidle3 /d "deaktiviert" das lästige Feature; durch ein proprietäres Kommando an die Firmware der Festplatte wird damit das IntelliPark-Intervall auf 3720 Sekunden (62 Minuten) gesetzt.

Hier die gekürzte SMART-Ausgabe für die Load_Cycle_Count-Werte um 18 Uhr:

23621
23771
748
1403
1371
1274
1555
1502
1538

Drei Stunden später (ohne smartdaemon) sieht die Ausgabe so aus:

23621
23771
749
1404
1372
1275
1556
1503
1539

Ich werde über die nächsten Tage per Cronjob die Werte täglich einmal auslesen und dann später berichten, wie sich die Werte bei aktiviertem und deaktiviertem smartdaemon verhalten.

Unser bisheriger Backup-Server im Datacenter war ein betagter Proliant DL380 G3 und sollte durch etwas aktuelleres ersetzt werden, vorzugsweise mit mehr Plattenplatz als nur 6x 300GB im RAID10.

Aus wirtschaftlichen Gründen (es ist "nur" ein Backupserver) haben wir uns gegen einen Server von HP entschieden, nicht zuletzt weil die 1TB SATA-Platten von HP mit 299€/Stück einfach jenseits von gut und böse liegen im Vergleich zu aktuellen Preisen für nicht-HP SATA-Platten im regulären Handel.

Bei der Wahl des Chassis hatten sich mein Azubi und ich relativ schnell für das Chieftec UNC-410F-B entschieden - 4U, 10 5,25"-Einschübe und damit genug Platz für Platten. Außen an das Gehäuse kommt eine Schiene RSR-260 zwecks Rackmontage und fertig ist das Chassis.

Den Saft für den Server liefert das redundant ausgelegte 500W-Netzteil MRG-6500P, das mit seinen 8 Molex- und 2 SATA-Steckern vorläufig genug Anschlüsse liefert.

Beim Mainboard haben wir uns an das von Kris verbaute Asus P5Q Premium gehalten, mussten aber leider während der Testphase feststellen, dass von den 10 SATA-Ports nur 8 sinnvoll nutzbar sind und haben deshalb auch noch eine Adaptec 1430SA nachgekauft.

Auf dem Mainboard findet anschließend eine Intel Core2Quad Q9550 Boxed (C1) CPU, 4x 2GB RAM und eine beliebige Grafikkarte Platz.

Bei der Suche nach passenden Backplanes wurden wir bereits auf der Zubehörseite des Chassis fündig: 3 Backplanes SST-2131SAS verstauen insgesamt 9 Western Digital Caviar WD15EARS.

2 Backplanes bilden mit ihren je 3 Platten ein Software-RAID5 auf dem dann LVM mit einem striped Logical Volume aufsetzt - quasi ein RAID50, durch LVM aber komfortabler zu managen.

Debian Lenny 64-bit ist per PXE-Boot, USB-Stick oder USB-CDROM innerhalb von 10 Minuten installiert, anschließend installieren wir BackupPC und übernehmen die Config-Files vom alten Server.

Beim Partitionieren der Platten sollte man die Sektorgröße von 4kB beachten - "normales" Partitionieren, so wie es der Linux-Sysadmin gewohnt ist, lässt die Schreibperformance auf diese Partitionen auf wenige MByte/s einbrechen.

Wie man es richtig macht findet man im Wiki von brain4free: WD "Advanced Format" HD mit LINUX.

Mittels pvs -o+pe_start stellt man sicher, dass die Nutzdaten des LVM-Layers auf einem Vielfachen der Chunksize des RAID5 beginnen:

PV         VG     Fmt  Attr PSize PFree 1st PE
/dev/md1   debian lvm2 a-   1.36T 1.36T 192.00K
/dev/md2   data   lvm2 a-   2.73T    0  192.00K
/dev/md3   data   lvm2 a-   2.73T    0  192.00K

Da meine Chunksize 64kB beträgt, passt der Beginn der Daten an Stelle 192kB also:

md2 : active raid5 sdd1[0] sdf1[2] sde1[1]
2930152704 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

md3 : active raid5 sdg1[0] sdi1[2] sdh1[1]
2930152704 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

lvs -o+stripes,stripesize,devices

LV       VG     Attr   LSize #Str Stripe Devices
backuppc data   -wi-ao 5.46T    2 64.00K /dev/md2(0),/dev/md3(0)

Wer an dieser Stelle stutzig wird, hat offenbar schon mehrfach mit Software-RAID zu tun gehabt:

Bei einem RAID5 aus 3 Platten mit einer Chunksize von 64kB müsste die optimale Stripesize für das darüberliegende Logical Volume 128kB sein. Verschiedene Benchmarks haben aber zu meiner Verwunderung ergeben, dass die Write-Performance mit der 64kB Stripesize um 10-15 MByte/s höher lag als bei der rechnerisch optimalen Stripesize von 128kB.

Das auf dem LV liegende ext3 FS sollte ebenfalls passend angelegt werden: Mit dem mkfs.ext3 RAID stride calculator ergibt sich bei einem RAID0 über 2 "Platten" mit einer Stripesize von 64kB und einer FS-Blocksize von 4kB folgendes mkfs-Command:

mkfs.ext3 -b 4096 -E stride=16,stripe-width=32 /dev/data/backuppc

Damit erfolgen Schreiboperationen auf das Dateisystem nun in optimaler Weise.

Weitere Stellschrauben:

• Passenden Scheduler zur Workload wählen, z.B: cfq
• stripe-cache-size optimieren

Das Optimieren der stripe-cache-size der 2 RAID5-Bricks von default 256kB auf 4096kB hat bei uns die lineare Writeperformance auf das LV von 180 MByte/s auf 300 MByte/s gesteigert; recht beachtlich, wie ich finde.

Update: ext3- und xfs-Benchmarks mit bonnie++ auf dem LV.

Update: Smart-Werte (sda+sdb = System, sdc = Spare, sdd-sdi = Daten)

Die IntelliAd Media GmbH sucht kurzfristig einen Server-Admin für ein Projekt im Raum München. Da dies für mich aktuell nicht in Frage kommt, dumpe ich hier nach Rücksprache deren Anfrage:

Für das Setup einer redundanten hochverfügbaren Serveraufstellung für ein Tracking System
suchen wir aktuell kurzfristig einen Experten, ggf. wäre das ja etwas für Sie?

Einsatzort München und remote
Einsatzzeit kurzfristig 3-5 Tage Vorort
langfristig 5-6 Tage Wartung / Monat remote

Erfahrungen in mehreren der folgenden Bereiche sollte vorhanden sein:
Storage (Dell equallogic),
Linux (debian/ubuntu),
Hochverfügbarkeit,
MySQL Replikation,
Load Balancing.

Interessenten wenden sich bitte per Email direkt an Herrn Rürup (mruerup[at]intelliad[dot]de) von IntelliAd.

Hier gibts die Schnellanleitung:

1. Man benötigt ein installiertes Windows XP/Vista/7 in der 32-bit Version, um das BIOS von Version 06LA (Auslieferungszustand) auf Version 09LA flashen zu können. Das BIOS gibts auf samsung.de im Download-Center
   
   hinter dem Karteireiter Firmware:
   
2. Das BIOS-Update ist wirklich ein Windows-Programm, das sich leider nicht in einer virtuellen Maschine entpacken lässt. Um ein installiertes 32-bit-Windows kommt man leider nicht herum.
3. Windows 7 64-bit installieren
4. Treiber für LAN, WLAN, Chipsatz, Grafik (1280x800), Sound, Bluetooth, Webcam etc. bringt Windows von Haus aus mit.
   Dennoch empfiehlt es sich, den passenden 64-bit Treiber für den verbauten NVIDIA GeForce 9600M-GT-Grafikchip zu installieren.
5. Damit man mit dem Synaptics-Touchpad Klicken und Scrollen kann, besorgt man sich auch hier den passenden Treiber in 64-bit.
6. Die noch fehlende Software Easy Battery Manager, Easy Display Manager (für Shortcuts mit Fn-Taste für Helligkeit, Sound, Standby, ...) und Easy SpeedUp Manager (Lüftersteuerung) gibt es von Samsung leider nicht als 64-bit-Version für das R560 - wohl aber für das neuere R620.
   Glücklicherweise hat sich zwischen R560 und R620 an der Hardware nicht zu viel geändert, so dass die Software-Pakete problemlos auch auf dem R560 laufen:

   

Viel Spaß mit dem 64-bit Windows auf dem Samsung R560.

SLB-ServerIron 4G#show reload
Reload will start 0 days 2 hours 27 minutes 25 seconds from now
at 04:04:04 GMT+01 Sat Dec 05 2009

Prost und gute Nacht!

Die folgende Anleitung wurde erfolgreich auf 3 Root-Servern bei 1&1 getestet (1&1 Root-Server S64 mit Athlon64 Single- oder Dual-Core-CPU, 1GB RAM, NVIDIA-Chipsatz (lspci.txt)).

Wie immer bei Anleitungen aus dem Internet gilt auch hier:

Verwendung der Anleitung auf eigene Gefahr. Zu Risiken und Nebenwirkungen fragen Sie Ihren kompetenten Systemadministrator!

Wir aktualisieren die lokale Datenbank des Paketmanagers und schauen uns an, wieviele Updates darauf warten, eingespielt zu werden:

zypper refresh && zypper patch-check

Die letzte Zeile der Ausgabe könnte z.B. so aussehen:

4 patches needed (2 security patches)

Das Release bzw. die Versionsnummer des aktuell laufenden Kernels lassen wir uns mit

uname -r

anzeigen:

2.6.27.31rootserver-20090819a

Durch den Zusatz "rootserver" können wir erkennen, dass hier der von 1&1 selbstgebackene Kernel läuft, den wir gerne ersetzen wollen.

Wir installieren den openSUSE-Standard-Kernel mittels

zypper install kernel-default

Wie ich durch eigene Tests herausgefunden habe, stört sich der SUSE-Kernel an dem Boot-Parameter ro (das Root-FS wird dadurch read-only gemountet, openSUSE mountet dies während der Boot-Phase offenbar selbst nicht read-write).

Ob wir davon betroffen sind, verrät uns

grep kernel /boot/grub/menu.lst

Die Ausgabe könnte z.B. so aussehen:

kernel /boot/vmlinuz-2.6.25.20-0.5-default root=/dev/md1 ro console=tty0 console=ttyS0,57600
kernel /boot/vmlinuz-2.6.25.20-0.5-default root=/dev/md1 showopts ide=nodma apm=off acpi=off noresume edd=off x11failsafe console=tty0 console=ttyS0,57600

Falls bei Euch das ro in der Zeile auftaucht, die mit kernel beginnt, solltest Du mit Deinem Lieblingseditor (z.B. vim oder nano) die Datei /boot/grub/menu.lst bearbeiten und das ro entfernen.

Die Angabe root=/dev/md1 ist darüber hinaus ein Indiz, dass im Server ein Software-RAID eingerichtet ist.

Überprüfen lässt sich das mit

cat /proc/mdstat

Tauchen hier ein oder mehrere md-Devices (md1, ...) auf, so ist ein Software-RAID eingerichtet.

Bei den von mir aktualisierten 1&1-Root-Servern war die Datei /etc/mdadm.conf nicht vorhanden.

Diese Datei sollte unbedingt vorhanden sein und die aktuellen RAID-Einstellungen widerspiegeln, wenn man den SUSE-Kernel booten will:

test -e /etc/mdadm.conf && mv /etc/mdadm.conf /etc/mdadm.conf.backup
mdadm --detail --scan > /etc/mdadm.conf

Wichtig: Das initrd-Image muss neu gebaut werden, damit dies die mdadm.conf enthält:

mkinitrd

Die Fehler bzgl. des 1&1 Kernels ignorieren wir.

Anschließend via

reboot

den Server rebooten.

An dieser Stelle empfiehlt es sich, sich zu Diagnose-Zwecken über den seriellen Konsolen-Server von 1&1 mit dem Server zu verbinden - damit ist man in der Lage, dem Kernel beim Booten zuzusehen und eventuelle Unregelmäßigkeiten zu erkennen. Die Zugangsdaten zum Konsolen-Server findest Du im 1&1 Control-Center unter dem Menüpunkt Server-Verwaltung/Serielle Konsole.

Sobald der Server wieder erreichbar und Du per SSH eingeloggt bist, kannst Du mit

uname -r

prüfen, dass nun der SUSE-Kernel geladen wurde. Der aktuelle SUSE-Kernel (Stand 26.11.2009) für openSUSE 11.0 ist:

2.6.25.20-0.5-default

Damit ist das Update des Kernels abgeschlossen.

Nachtrag: Schweinegrippe: Höchste Warnstufe

Nachtrag: Im Schweinsgalopp ins Impfchaos, Video H5N1 antwortet nicht

Die Kanzlei e|s|b hat mit Blick auf den Beginn des morgigen DE-Registrierungsverfahrens (vgl. Kanzlei.de-News vom 16.10.2009) für ihren Mandanten, Inhaber der Einbuchstabenmarken E, F, G und X, Y, Z, am 21.10.2009 eine einstweilige Verfügung gegen die DENIC eG erwirkt. Hierin untersagt das Landgericht Frankfurt (Az. 2-06 O 515/09) der DENIC eG bei Meidung der üblichen Ordnungsmittel (Ordnungsgeld bis zu 250.000 Euro, ersatzweise Ordnungshaft, oder Ordnungshaft bis zu 6 Monaten, zu vollstrecken an ihrem Vorstand), die Domains "e.de", "f.de", "g.de", "x.de", "y.de", "z.de" bis zu einer rechtskräftigen Entscheidung des Oberlandesgerichts Frankfurt in Sachen 11 U 36/09 für Dritte als Domaininhaber zu registrieren. - 22.10.2009

Quelle: kanzlei.de (via)

Bin gespannt was da morgen um 9 abgeht

Filesystem    Type    Inodes   IUsed   IFree IUse% Mounted on
/dev/sda4     ext3   145227776 66000722 79227054   46% /home

Update: Nach 131 Stunden war es endlich durch ... Hardware siehe Kommentare.

Beide Informationen erhält mal ab sofort nur noch über das Web-Formular der DENIC - und auch nur dann, wenn man sich durch Lösen eines nicht barrierefreien CAPTACHAs als Person aus Fleisch und Blut zu erkennen gibt:

Interessant ist der Absatz "Hintergrund" der Pressemitteilung der DENIC zum Thema:

Information über Netzwerkressourcen wie Internetnummern, AS Nummern aber auch Domains anzubieten, um Netzadministratoren und -betreibern die Zusammenarbeit in einem heterogenen Netz zu erleichtern. Auch heute betreibt die DENIC wie andere TLD-Der Informationsdienst whois wurde 1982/1985 in den Internetstandards RFC 812 bzw. RFC 954 spezifiziert und im Standard RFC 3912 weiterentwickelt. Absicht des Dienstes ist es, über einen TCP-basierten VerzeichnisdienstRegistrierungsstellen eigene whois-Server konform mit dem Standard RFC 3912 (WHOIS Protocol Specification:  tools.ietf.org/html/rfc3912) [sic!].

Ich habe mir erlaubt bei der DENIC nachzufragen, ob der Autor der Pressemeldung unter "dem Einfluss von bewusstseinssteigernden Substanzen" gestanden hat.

Ich werde berichten, sobald es eine Antwort gibt