Als ich mir vor über einen Jahr das Energiemessgerät kaufte wusste ich nicht, welche langfristigen Konsequenzen das haben sollte. Mir wurde klar, das es so mit meinen Heim-Server nicht weitergehen konnte, 150W fürs nix tun sind einfach zu viel.

Zuerst versuchte ich den Server selbst zu optimieren. Ein AMD Geode Prozessor musste her und mit eigenen Kernel backen lag ich bei 71 Watt im Idle und 110 Watt unter Vollast. Ein kleiner Schritt, aber noch nicht das Wahre.

Als nächstes kam mir der Linksys WRT54GL mit OpenWRT ins Haus geflattert. Er brachte zwar adhoc keine Entlastung, sondern 13 Watt mehr auf den Stromzähler. Das macht aber auch nichts, denn er war Teil eines größeren Plans.

Schließlich die Linksys NSLU2. Mit Debian hatte ich sie recht schnell versorgt, ich wollte aber vor dem Umzug meine MP3s zu Ogg konvertiert haben und das dauerte etwas. Hat leider nicht funktioniert, weil die ID3-Tags zum Großteil zerstört wurden. Am Freitag war also der grosse Tag. Die Daten von /home, meinem allgemeinen Daten-Verzeichnis und Mail wurden vom alten Server transferiert. NFS-Server und Sendmail konfiguriert, Samba mit Windows-Domäne fertiggemacht, was zuerst einfacher ging als gedacht. Die Probleme mit den Profilen haben mich dann heute eingeholt.

Click to enlarge

Die 32 MB RAM der NSLU2 ist mit NFS, Mail, IMAP4, Samba, SSH und den anderen Systemteilen zur Hälfte ausgelastet. Später hinzukommen wird noch CUPS. Von der gefühlten Performance ist das System mehr als Ausreichend. Gut, man sollte es mit Verschlüsselung nicht übertreiben (scp frisst die CPU), aber es ist gut benutzbar.

Heute habe ich alles im Rack eingebaut und nochmal nachgemessen. Mein alter Server mit USV, DSL-Modem und 5 Port-Switch lag bei 125W im Idle. Nach dem Umbau und Abschalten lag die NSLU2 mit 2 USB-Festplatten (einmal System, einmal Backup) und obigen Foo bei 52 Watt. Rechnet man noch die 13 Watt des WRT54GL hinzu bin ich bei 65 Watt, also knapp die Hälfte. Das kann alles noch ein bischen nach oben und unten schwanken, da die Seagate-Festplatten sich im Idle selbsttätig herunterfahren (auch die Systemplatte obwohl da ständig Betrieb drauf ist).

Nun fehlen noch Kleinigkeiten. Die Systemplatte soll nachts auf die Backupplatte gesynced und CUPS muss konfiguriert werden. Vielleicht tausche ich noch Programme aus, also ein kleinerer MTA (sollte SMTP-AUTH können) und Dovecot statt UW-IMAP. NFSv4 soll auch noch kommen.

Click to enlarge

Was mir wirklich fehlt ist ein Tastatur- und Monitoranschluß an der NSLU2. Man kann wohl eine serielle Schnittstelle anlöten und könnte ein serielles Terminal anschließen, aber das wäre mir zuviel gebastel.

Nachtrag: Martin hat die Spassbremsen-Frage nach den Kosten der Aktion gestellt. Nun, bei 3,5KWh am Tag, wie in der Ausgangssituation, entstehen bei einen KWh Preis von 20 Cent jährliche Kosten von ca. 256 Euro (21 Euro im Monat). Der WRTG54GL-Router kostet 55 Euro, die NSLU2 75 Euro und die beiden Festplatten je 90 Euro macht 310 Euro. Also nach 1 Jahr und 3 Monaten rechnet sich soetwas. Bei den späteren 70 Watt sieht die Sache natürlich schon anders aus und man liegt bei über 2,5 Jahren.

Die letzten 24 Stunden verbrauchte die neue Lösung 1,6KWh, macht im Jahr 117 Euro oder 9,75 Euro im Monat.

Posted: April 7th, 2007 under Debian, Hardware, Linux, NSLU2.
Comments: 10

Gute Nachricht zuerst: Man muss die NSLU nicht mehr “übertakten“, denn seit längeren wird sie mit der vollen Taktfrequenz von 266Mhz ausgeliefert. Bevor es los geht, ein paar Überlegungen hinsichtlich der anzuschließenden Storage.

Die NSLU verfügt über zwei USB-Anschlüsse. Zuerst spielte ich mit dem Gedanken sie durch einen USB-Hub zu erweitern. Am ersten Anschluss wollte ich einen USB-Stick anschließen und am zweiten den Hub mit den beiden USB-Festplatten. Klar, USB-Sticks haben eine begrenzte Lebendauer was Lese- und Schreibzyklen angeht, aber das Risiko wollte ich eingehen, der Stromverbrauch ist einfach zu verlockend. Bei geschickter Partitionierung (/home und Datengrab auf den Platten, der Rest auf dem Stick) kann man nachts die Platten in den Sleep-Modus laufen lassen und dann liegt die NSLU bei 10 Watt. Allerdings war dafür der Stick, warum auch immer, viel zu langsam. Also doch eine Platte an den ersten und eine mit den Hub an den zweiten, so kann auch der Drucker angeschlossen werden. Beim USB-Hub muss man, wie bei jeden anderen Hub (Netzwerk- oder Storage-Hub), daran denken das der Datentransfer blockiert für andere Dinge ist, wenn bereits ein anderes Gerät Daten überträgt. Also zwei Festplatten zugleich ist keine gute Idee.

Aber nun zur Installation. Es gibt fertige Installations-Images für Debian, einmal das offizielle und ein Inoffizielles. Beim Original Debian Image muss man mit einer USB-Netzwerkkarte arbeiten, da die interne Netzwerkkarte nur mit einen propitären Treiber Module zur Arbeit zu bewegen ist. Diesen Umstand umgeht man mit dem inoffziellen Image, welches das richtige Module enthält. Ich beziehe mich im weiteren auf das inoffielle Image.

Bevor man Debian installiert, sollte man die NSLU vorher einmal in Betrieb nehmen. Also mit einer IP-Adresse, Gateway, Netzwerkmaske und Eintrag für den DNS-Server versorgen, denn drauf greift die Installation später zurück. Hat man das Image heruntergeladen und entpackt, kann es einfach via Web-Interface hochgeladen (Administration/Upgrade) werden, jedoch sollte man vorher alle Platten/USB-Sticks abgestecken. Das Hochladen dauert einen Moment, generell sollte man etwas Geduld mitbringen, denn alles dauert ein bischen länger als sonst. Wenn das Gerät dreimal gepiept hat ist es soweit, man kann es wieder aus machen und die Festplatte-/Sticks wie gewünscht anstöpseln und anschließend wieder einschalten.

Nun kann man sich via ssh installer@IP-Adresse (Passwort: install) einloggen und stößt dann auf einen normalen Debian-Installer den ich nicht weiter vorstellen möchte. Er kümmert sich um die Partitionierung, Installation der Software und dem bootfähig machen des Systems. Ist man soweit durch steht vor einen ein normales Debian-System.

Meine erste Installation dauerte ewig und lief mehrfach in einen ssh timeout. Sie war mit USB-Stick und Festplatten via Hub am ersten Anschluss aufgebaut und ich testete mit

dd if=/dev/zero of=test.dat bs=1M count=100

die Geschwindigkeit. Das ist sicher kein echter Benchmark, aber die Ergebnisse lassen sich schnell ermitteln und gut vergleichen, auch wenn sie anfangs sehr erschütternd waren. Gerade einmal 1.4MB/s standen auf den Tacho, sowohl beim Stick als auch bei der Platte. Ich richtete dann das mounten via UUID ein, um die Platte frei umherstecken zu können und siehe da: die Platte lag, wenn sie alleine angeschlossen war, bei 13.5MB/s. Der USB-Stick war also zu langsam, obwohl er mit USB2 arbeitete. Komischerweise liefert er bei meinen Desktop-PC die volle Leistung. Keine Ahnung warum.

Also neu installiert und die Firmware mit Upslug2 via Netzwerk eingespielt. Tolle Sache, denn so kann man im Prinzip die NSLU nicht zerflashen. Die Installation ging durch die am ersten Anschluss hängende Festplatte recht fix und auch das fertige System lag dann wieder bei 13.5MB/s Datentransfer im System.

Zeit sich mit der Netzwerkgeschwindigleit zu befassen. Beim normalen NFS-Mount lag sie bei 4.6MB/s, per FTP bei etwa 5.2MB/s. Der begrenzende Faktor war bei allen Messungen (welch Überraschung) die CPU. Mal NFSv4 probiert, welches von der Performance besser sein soll. Nunja, es lag mal etwas unter, mal etwas über NFSv3, insgesamt nichts nennenswertes. Spasseshalber hatte ich mein /home vom jetzigen Server (der etwa 8MB/s macht) auf die NSLU verlegt und es war ein ganz normales Arbeiten für mich möglich - Test also bestanden.

Was noch aussteht ist die Übernahme der Funktion des jetzigen Servers. Also NFS, SMB/CIFS, IMAP und SMTP. Ich bin mal gespannt wie ich mit den 32MB RAM hinkomme.

Posted: März 22nd, 2007 under Debian, Hardware, Linux, NSLU2.
Comments: 2

Gestern am späteren Abend bin ich dann endlich dazu gekommen den NSLU2 auszupacken und mal ein bischen mit dem Energie-Meßgerät rumzumessen. Der NSLU2 ist übrigends kaum größer als eine Bigbox Zigaretten-Schachtel und liegt bei etwa 18 Watt egal ob er idled oder was tut. Die Seagate USB-Platte liegt bei 13 Watt im Betrieb und 4 Watt wenn die Platte sich abgeschaltet hat. Dieser Umstand lässt mich nachdenklich werden. Würde ich das System im RAID1 betreiben läge das System bei 2*13+18 Watt = 44 Watt. Viel besser wäre es doch den NSLU2 mit einer Platte zu betreiben und Nachts einmal die zweite Platte zu syncen, da wäre ich bei 31 Watt - etwas weniger als die Hälfte der 70 Watt die mein jetziger Server im Idle zieht.

Da ich sowieso noch einen Drucker anschließen will, brauche ich zusätzlich einen USB-Hub. Dann könnte ich das Debian-System auf einen USB-Stick installieren und nur meine Daten auf die Platte auslagern. Die Idee mit dem Verschlüsseln der Daten habe ich aufgegeben, zwar hat das wohl schonmal jemand gemacht, lag aber bei etwa 1MB/Sek beim Schreiben - das ist mir dann doch zuwenig. Viel werde ich sowieso nicht erwarten, NFS-Server, Samba, SMTP/IMAP und Druck-Server, damit sollte das Ding gut zu tun haben.

Posted: Februar 22nd, 2007 under Hardware, WRT54GL.
Comments: 6

Früher war alles ganz einfach. Man baute eine Festplatte ein, startete den Rechner, sie war da und hatte ihren festen Devicepfad (/dev/sda1 oder /dev/hde3) und Einbindepunkt (/cdrom). Daran, das man sie im laufenden Betrieb einbinden oder entfernen wollte war nicht zu denken. Seitdem immer mehr Leute USB-Festplatten oder -Sticks benutzen und die Distributionen mehr und mehr auf udev setzn, umso überkommener ist es mit Device-Pfaden zu arbeiten, denn sie können sich sehr schnell ändern. Einige behelfen sich, indem sie ihre Festplatten oder USB-Sticks über udev feste Devices zuordnen, aber wirklich toll und einfach ist diese Lösung nicht. Hier bieten sich UUIDs an, da sie eine feste Zuordnung bieten auch wenn sie Device-Namen verschieben sollten, weil man USB-Stick und Festplatte gleichzeitig nutzt oder eine zweite Platte einsetzen möchte.

UUIDs sind schon da

Wer schonmal in seine /etc/fstab bei Ubuntu Edgy geschaut hat, wird feststellen das sie sich etwas verändert hat:

# /dev/sda4 -- converted during upgrade to edgy
UUID=7b848512-94bc-4e1e-ba2c-a74e664713bf / ext3 defaults 0 1

Der Device-Pfad wurde durch die UUID ersetzt und auch der Boot-Loader grub wurde entsprechend angepasst:

# kopt=root=UUID=7b848512-94bc-4e1e-ba2c-a74e664713bf ro

Dabei sind UUIDs keine Neuheit, sie gibt es mindestens seit 1999, daher verfügt quasi jedes in den letzten Jahren erzeugtes Linux-Filesystem über diese eindeutige Kennung und an sie rauzukommen ist sehr einfach:

tempel$ ls -lF /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 10 Jan 18 19:01 0EDCF622DCF6042D -> sda2
lrwxrwxrwx 1 root root 10 Jan 18 18:01 2e2480a4-a8fe-420a-835a-7f7e238cd717 -> sda6
lrwxrwxrwx 1 root root 10 Jan 18 19:01 563041da-94c3-4b27-bfcc-4aab83b4b7c3 -> sda5
lrwxrwxrwx 1 root root 10 Jan 18 19:01 7490B9EC90B9B548 -> sda1
lrwxrwxrwx 1 root root 10 Jan 18 19:01 7b848512-94bc-4e1e-ba2c-a74e664713bf -> sda4

Alle Linux-Dateisysteme unterstützen UUIDs, wobei die für Wanderer zwischen den Welten wichtigen VFAT und NTFS Dateisysteme sie eigentlich nicht unterstützen. Kein Grund zur Panik, denn die obigen sda1 und sda2 sind NTFS-Partitionen, Linux ist da also nicht so engstirnig. Bei VFAT kann es schon passieren, das keine ID angezeigt wird, dann hilft manchmal der Befehl blkid oder das neuformatieren unter Linux mit mkfs.msdos -F 32 /dev/foo. Ein fertiger Eintrag in die FSTAB sieht dann so aus:

UUID=45D8-AFA7  /media/seagate  vfat    utf8,umask=007,gid=550 0 1

Weitere Einsatzgebiete

Wie oben schon angesprochen gilt diese Vorgehensweise für alle Wechselmedien die ein Filesystem haben können, also USB-Sticks, CF- oder SD-Karten. Auch sind UUIDs eine gute Lösung wenn mehrere Zugriffs-Pfade zu einen Dateisystem bestehen, wie z.B. bei Software-Raid oder in einen Server mit redundanten SAN-Anschluss.

Referenzen: Sidux Manuals und Stable root device (AKA UUID)

Posted: Februar 18th, 2007 under Linux, Tips.
Comments: 8