meeveo.com

Die Mac OS X Snow Leopard Upgrade DVD ist pünktlich zum Wochenende eingetroffen. Als Erstes erstmal ein aktuelles Timemachine Backup erstellt und gleich losgelegt. DVD rein, Snow Leopard Installation gestartet und dann… fehlgeschlagen!

Mmmh… na okay, ich boote einfach mal von der DVD und probiere es so. Neugestartet, von der Snow Leopard Upgrade DVD gebootet, Installation hat angefangen und dann… fehlgeschlagen. Okay, ich lösche einfach mal die ganze Festplatte (Backup ist ja vorhanden) und installiere komplett neu. Also rein ins Festplattendienstprogramm, Festplatte neu formatieren und dann nochmal neustarten damit die Installtion sauber loslegen kann.

Nach dem Neustart – vor den Kopf hau! Die Installation benötigt ein installiertes Mac OS X Leopard (10.5) auf dem Rechner. Irgendwie auch logisch – ist ja die Upgrade DVD. Also, Mac OS X Leopard 10.5 neuinstalliert, neugestartet von der Snow Leopard DVD gestart und siehe da – endlich lief die Installation sauber durch.

Da Mac OS X 10.6 Snow Leopard auch keinen eigenen iSCSI Initiator mitbringt habe ich wieder den von GlobalSAN installiert. Nun konnte ich auf mein Timemachine Volume auf meinem NAS zugreifen und habe den Migrationsassistenen gebeten alles rüber zu schaufeln. Unspektakulär einfach flutscht alles rüber.

Flutscht ist die richtige Bezeichnung. Unter Mac OS X 10.5 Leopard habe ich mich schon gefreut via iSCSI 30 MB/s zu erzielen. Mac OS X 10.6 Snow Leopard erreichte bis zu 40 MB/s und das bei etwas gesunkener CPU Belastung. Bis auf das holprige Upgrade eine erfreudige Verbesserung.

Nun muss ich erstmal ein wenig damit arbeiten um weitere Ecken und Kanten zu finden bzw. die neuen Funktionen kennenzulernen.

Nach dem Domainumzug von 1blu zu Strato ist meeveo.com endlich wieder online! Leider hat sich der Umzug etwas verzögert, so dass mein Blog ein paar Wochen offline war. Jetzt geht’s aber weiter wie gewohnt! 1blu hat zwar soweit funktioniert aber war einfach nur lahm. Bei Strato läuft alles doch deutlich flotter.

Wer mal geschaut hat, was eine Steckdosenleiste mit LAN-Anschluss in der Regel so kostet, der wird sich vielleicht über diese Alternative freuen: Die 6-fach Steckdose Silvershield SIS-PMS über PC/USB programmierbar mit Überspannungsschutz der Firma Gembird. Der USB-Variante ersetzt zwar noch keinen LAN-Anschluss aber hängt man die Steckdosenleiste an einen OpenWrt Router mit USB-Port, kann man diese über diesen auch bequem schalten.

Es ist auch ein Modell mit Bluetooth-Schnittstelle verfügbar: Gembird SIS-PM-BT 6fach Steckdose mit Bluetooth-Schnittstelle. In vielen Foren wird über massive Probleme der Steckdosen geschrieben. Das war bei den ersten Versionen wohl auch sehr unzuverlässig. Mittlerweile arbeiten sie aber solide und ich habe absolut keine Probleme mit den Steckdosen.

Auf dem Router muss die USB Unterstützung installiert werden. Dazu sind auf z.B. einem ASUS WL-500g Premium folgende Module notwendig: kmod-usb-core, kmod-usb-uhci und kmod-usb2. Zum Schalten der Steckdose installiert man das Tool sispmctl, was ebenfalls noch libusb benötigt.

opkg install kmod-usb-core kmod-usb-uhci kmod-usb2
opkg install sispmctl libusb

Ich habe mir ein kleines CGI Script geschrieben, welches ich als Frontend für sispmctl nutze. So kann ich Drucker, Beamer, XBOX360 und diverse andere Geräte bequem über die Weboberfläche ein- und ausschalten. Als kleines Highlight habe ich für meinen Kyocera Laserdrucker eingerichtet. Dieser hat einen Netzwerkanschluss und ich frage via Cronjob alle 30 Minuten den Zustand des Druckers an. Ist dieser im Schlafmodus, wird der Drucker automatisch ausgeschaltet. Also nie wieder vergessen den Drucker angeschaltet zulassen.

Nach längerem Ausprobieren und Konfigurieren läuft es jetzt endlich im produktiven Einsatz – mein NAS. Folgende Komponenten habe ich dafür verbaut:

Gehäuse: Tyan Transport GX28 (B2881), 19″, 1HE
Board: Tyan Thunder K8SR(S2881) (2x 1GBit/s Ethernet on-board)
CPU: AMD Opteron 252 2,6 GHz
RAM: 2x 1GB DDR ECC RAM (2x 512MB sind auch völlig ausreichend)
Storage: 4x 1TB Western Digital WD10EADS, SATA, 32 MB Cache
Raid-Controller: LSI MegaRaid 150-6 SATA PCI-X
Wenn man sich diese Zusammenstellung so anschaut, geht es sicher auch noch stromsparender aber letztlich entscheidet auch was man gerade günstig bekommen kann oder vielleicht eh schon da hat, um einen bestimmten Budgetrahmen nicht zu sprengen.

Die Western Digital WD10EADS Festplatten sind wirklich spitze. Schnell, extrem leise und sie werden im Betrieb gerade mal handwarm. Als Raidlevel kommt wegen des guten Verhältnis zwischen Ausfallsicherheit und Performance Raid5 zum Einsatz. Wichtigste Erfahrung für mich: Wenn man die Entscheidung zwischen Software-Raid5 und Hardware-Raid5 treffen muss, würde ich immer wieder zu Hardware-Raid5 tendieren. Die Leistungsaufnahme des Raidcontrollers ist einfach deutlich niedriger als die einer parity-berechnenden AMD Opteron CPU. Auch die Handhabung im Fall eines Festplattenausfalls ist denkbar einfach. Alte Platte raus, neue Platte rein und der Rebuild beginnt. Begleitet wird das durch einen laut fiependen Lautsprecher auf dem Raid-Controller der einen darauf aufmerksam macht, dass eine Festplatte ausgefallen ist. Diese Form der Benachrichtigung beherrscht ein Software-Raid so nicht.

Die LSI Megaraid 150-6 sind schon ein bisschen älter und arbeiten im LBA 48Bit Modus. Deswegen lassen sich keine logischen Volumes größer 2TB anlegen. Konfiguriert man also die vier Festplatten im Raid5 Verbund, gibt es hinterher zwei LVs. Eins mit 2TB und eines mit ca. 0,8TB. Der Rest wird für die Paritätsdaten des Raid5 benutzt. In FreeNAS habe ich mir damit beholfen, das ich ein JBOD Verbund angelegt habe, der die zwei logischen Volumes wieder zu Einem mit einer Kapazität von 2,8TB zusammenführt.

Die zwei Broadcom BCM5704C Gigabit Ethernet Schnittstellen beherrschen Tcp Checksum offload in Hardware, so dass die CPU kaum Arbeit zu verrichten hat. Da hatte ich die Hoffung, dass dank AMD Cool’n'Quiet der Takt entsprechend runtergetaktet wird. Das erledigt in FreeNAS der powerd. Leider mit dem Ergebnis, dass das NAS sehr instabil läuft und der gesamte Rechner manchmal einfriert – also inakzeptabel.

Mittels sysctl dev.cpu.0.freq kann man sich anzeigen lassen, welche Frequenzschritte die CPU beherrscht. Nach etwas testen unter Last hatte ich festgestellt, dass sysctl dev.cpu.0.freq=497 ein guter Wert ist. Diesen Wert habe ich dann in der FreeNAS Konfiguration eingetragen. Das NAS wird also direkt nach dem booten auf 497 MHz heruntergetaktet. Bei dieser Frequenz hat die CPU noch genügend Spielraum nach oben auch wenn beide Gigabit Ethernet Schnittstellen voll ausgelastet sind.

Die eine Gigabit Ethernet Schnittstelle bedient das LAN, die Andere ist exklusiv mit einem Gigabit-Port eines VMware ESXi 3.5 Hosts verbunden. Diesem stellt das NAS via iSCSI und NFS Storage für mehrere Virtuelle Maschinen zur Verfügung.

Bislang läuft das System (mit dem Verzicht auf powerd und fest eingestellter Taktfrequenz) absolut stabil mit hervorragenden Übertragungswerten (~ 32 MB/s schreiben via iSCSI).

Da ich gerade versuche ein 4TB NAS zu bauen und ich auch mal ein wenig mit iSCSI herumspielen wollte, hat mich natürlich interessiert, wie man unter Mac OS X iSCSI nutzen kann. Neben diversen kostenpflichtigen iSCSI Initatoren gibt es einen Kostenlosen von globalSAN für Mac OS X. In der Vergangenheit muss dieser wohl noch eine Menge kleinerer Macken gehabt haben. Diesen Eindruck gewinnt man, wenn man diverse Foren zu dem Thema aufsucht. Die Artikel in den Foren sind jedoch oft schon ein paar Jahre alt und die Versionen sind mittlerweile weiter vorangeschritten. Meine bisherigen Erfahrungen mit dem globalSAN iSCSI Initiator sind durchweg positiv. Wenn das System aus der Bastelphase in den Produktivbetrieb geht werde ich meine Erfahrungen aber noch einmal dokumentieren.

Worauf ich sehr gespannt bin, ist das Time Machine Backup via iSCSI auf das NAS. Leider hat Apple die Möglichkeit ein Time Machine Backup auf Netzwerklaufwerke zu legen für seine eigenen Produkte vorbehalten. Via Terminal kann man sich jedoch diese Möglichkeit mit dem Befehl: defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1 freischalten. Da es in der Vergangenheit aber wohl noch hier und da zu Problem damit kam wäre iSCSI ein zweiter Weg.

Man müsste auf dem NAS nur ein iSCSI Target anlegen, dieses mittels globalSAN iSCSI Initiator mit seinem lokalen Mac verbinden und schon hat man ein neues Volume auf seinem Mac. Dieses muss vom Mac aus noch HFS+ formatiert werden und kann dann wie gewohnt in Time Machine als Backup-Volume ausgewählt werden.

Damit wäre ein automatisches Backup via Netzwerk bzw. W-LAN wie es Apples Time Capsule macht kein Problem mehr und diverse externe Festplatten können endlich vom Schreibtisch verschwinden. 

Nur wie spielt man das Backup im Fall eines Super-GAUs wieder ein? Da Mac OS X bisher iSCSI nicht nativ mitbringt, müsste man erst Mac OS X neu aufspielen, dann den globalSAN iSCSI Initiator installieren und mittels Migrationsassistenten auf das Time Machine Backup zugreifen. Das Einspielen des Backups direkt bei der Neuinstallation wird erst funktionieren, wenn Mac OS X endlich iSCSI Support von Hause aus mitbringt. Vielleicht ist es ja mit Snow Leopard endlich soweit.

Lang erwartet – endlich da. Die OpenWrt Kamikaze Version 8.09 als finales Release. Mit dem Release Candidate 1 und 2 habe ich ja schon ein bisschen herumexperimentiert.

Änderungen, die seit RC2 in die finale Version eingeflossen sind befinden sich in den Bereichen:

• Weboberfläche (LuCI)
• Kleiner Bugfix am madwifi Modul
• Firewall
• Toolchain für PowerPC
• Tx Sendeleistung verschiedener 802.11 Treiber

Werde ich ganz schnell mal ausprobieren. Gibt es eigentlich eine gute Dokumentation wie man einen bestehenden OpenWrt Router aktualisiert ohne sämtliche Einstellungen zu verlieren? Unter anderem deswegen hat man ja uci eingeführt.