Ich habe ja schon erwähnt, dass dieser Blog jetzt auf meinem Mini-Server läuft. Der Aufbau des selbigen war nicht immer ganz einfach, weshalb ich das hier mal festhalten will.

Vorgeschichte
Wegen Problemen mit dem WebHoster war ich genötigt mir Alternativen zu suchen diesen Blog unterzubringen. Da ich wenig Geld ausgeben und trotzdem gerne einen kompletten Server haben wollte um mehr Freiheiten und Möglichkeiten zu haben, fiel mir die häusliche 16 MBit ADSL Leitung ein, die ständig mit dem Netz verbunden und quasi ungenutzt ist. Ein Test mit einer lokalen WordPress-Anwendung zeigte, dass mit dieser Upload-Leitung problemlos 2,5 (nicht gzip’pte) Seitenabrufe pro Sekunde drin waren, was für meine Ansprüche völlig genügt. Mit gzip sind es dann ca. 8 Seiten pro Sekunde.

Vorbereitung
Da der Server ständig vor meiner Nase steht, muss er klein und geräuschlos sein. Und wegen der Kosten preisgünstig in der Anschaffung und stromsparend. Ein gebrauchter Laptop war zu teuer und zu unflexibel, da die Hardware nicht groß angepasst werden kann und ein “normaler” Rechner braucht viel Strom und Platz. Also ging ich auf die Suche nach ThinClient-PCs.

Die meisten davon haben nur eine DiskOnChip-”Platte” (Flash), die absolut nicht ausreichen für einen Server, da sie meist unter 128MB groß sind. IDE und SATA Anschlüsse sind auch nicht überall dabei aber ein flotter USB-Anschluss mit externer Festplatte geht ja auch. Aber bei Nachfragen stellte sich heraus, dass die DiskOnChip-Teile oft auf einem IDE-Anschluss stecken und die Angabe bei der Beschreibung schlicht und einfach fehlte. Ich entschied mich für IDE und gegen USB weil es mit simpler erschien.

Die RAM-Ausstattung sieht bei gebrauchten ThinClients eher dürftig aus und hat in einigen dieser PCs Sonderformen, wie z.B. spezielle Laptop-RAM-Riegel. Die maximal verwaltbare RAM-Größe ist oft nicht wirklich hoch, aber auch sowas erfährt man erst nach gezielter Nachfrage. Meine Mindestanforderung lag bei 1GB RAM, was sich noch gerade so einrichten ließ.

Bei Festplatten hatte ich, durch Versuche am eigenen Rechner, herausgefunden, dass 3,5 Zoll Festplatten knapp 15 Watt verbrauchen und eben auch deutlich hörbar sind. Zumindest meine. Also hab ich gleich nach 2,5 Zoll Platten gesucht, die in so ein kleines Gehäuse auch viel besser rein passen.

Anschaffung
Den Rechner (CA 800 ThinClient, VIA) gabs gebraucht bei eBay für 60 Euro und 1 GB (SD)RAM, (2×512 Riegel) für 20 Euro. 2 x 30GB IDE Festplatten für je 20 Euro und 2 x 3,5-zu-2,5-Zoll IDE-Adaptern à 7 Euro mussten es dann auch noch sein, denn der IDE-Anschluss ist der normale für 3,5 Zoll Platten. Leider gibt es größere 2,5 Zoll IDE-Patten scheinbar nirgends mehr neu zu kaufen, was mich auf diese maximal 2 x 30GB festnagelte.

Ergibt also gesamt 134 Euro für alles.

Schön ist das Teil nicht besonders, aber das war ja eh keine Voraussetzung.

Ausstattung
Folgendes hatte ich damit am Start:

• Gehäuse mit 29 cm Breite, 23 cm Tiefe und 5,5 cm Höhe
• externes Netzteil
• 800 MHz VIA C3 Nehemiah Prozessor, 1 Kern
• 1 GB SD RAM (2 x 512 MB Riegel) .. das Limit dieses Rechners
• 100 MBit LAN
• 1 PCI + 1 ISA Steckplatz
• 1 IDE Anschluss für 2 Geräte
• 2 x 30 GB IDE Festplatten
• 2 x USB v1.0 Anschlüsse für externe Geräte. 100kb/s langsam
• Onboard-Sound
• Onboard Intel-Grafik mit VGA-Ausgang
• PS2 Anschlüsse für Maus und Tastatur
• Diverse Uralt-Schnittstellen wie Serielle Ports.

Die externen Schnittstellen des Servers:

Einbau der Festplatten

Im Gehäuse ist es sehr eng und trotzdem musste ich dort die 2 Platten verbauen. Da das vom Hersteller nicht vorgesehen war musste improvisiert werden.

Eine einfache und billige Lösung dafür ist, die Festplatten mit Abstandshaltern auf die Hauptplatine zu “legen” und dann mit dem Gehäusedeckel zu fixieren, so dass nichts verrutschen kann. Dazu braucht man nur ein Lineal, eine Schere und einen Schnellhefter aus relativ festem Plastik. Man schneidet ein Viereck aus dem Schnellhefter von der Größe der Grundfläche der Festplatte und lässt dabei rechts und links knapp 1cm Rand überstehen. Diese Ränder knickt man dann nicht ganz rechtwinklig nach unten ab und stellt dieses umgedrehte “U” dann auf die Ränder.

Die Ränder der Halterung sollten jeweils an der Außenseite von z.B. aufgelöteten Schnittstellen oder Jumper blockiert werden, so dass beim Druck von oben auf die Halterung die Konstruktion nicht einfach zusammenklappt, wegknickt oder verrutscht. Andere Bauteile, vor allem SMD-Teilchen, sollten nicht belastet werden, denn wenn die im Betrieb mal warm und dann durch die Halterung zur Seite gedrückt werden, lösen sie sich im schlimmsten Fall von der Platine und das Board ist im Eimer.

Auf dieses U kam bei mir dann die erste Festplatte welche dort mit Isolierklebeband einfach draufgeklebt wurde. Da drauf kam eine weitere Lage Plastik vom Schnellhefter, wobei das Lüftungsloch der Platte ausgespart wurde. Das wurde wiederim mit Isolierklebeband auf Platte 1 fixiert. Da drauf liegt dann ein IDE-Kabel und da drauf Festplatte 2, wiederum mit Isolierklebeband mit all dem verbunden.

Das Ganze ist jetzt schon relativ stabil, bleibt es aber nur so lange, wie man leicht von oben drauf drückt. Deswegen liegt das restliche IDE-Kabel, die Stromkapel der Platten und noch ein wenig als “S” gebogene Schnellhefter-Reste lose obendrauf und zwar so, dass beim Schließen des Gehäuses das ganze Konstrukt leicht auf die Hauptplatine gedrückt wird. Ich könnte das Ding jetzt sogar schütteln und es würde sich nichts bewegen.

Wärmeentwicklung
Da nach dieser Umbauaktion der Platz fas völlig ausgenutzt ist, ist Wärmestau natürlich ein Thema. Da das Ding aber so wenig Energie verbraucht, ist es doch erstaunlich kühl. Der Server läuft schon seit Monaten durch und die Festplatten-Temperatursensoren liefern mir 41°C und 37°C als Werte (gemessem mit hdparm -H /dev/sda). Wenn der Prozessor unter Vollast eine Weile läuft, schafft er 67°C, unter normalen Bedingungen sind es um die 40°C.

Ein Problem besteht allerdings bei der Gehäuseunterseite. Wenn ich den Server auf einen Holzuntergrund stelle erhöhen sich die genannten Temperaturen um gute 5°C. Deswegen liegt er jetzt plan auf dem Metallgehäuse meines “normalen” Rechners, so dass die Unterseite vollflächig aufliegt und nach unten ein bisschen Wärme abgegeben werden kann.

System einrichten
Bei der Installation des Betriebssystemes (Ubuntu) hab ich darauf Wert gelegt, dass das System wenig Resourcen verbraucht und einfach Wart- und Erweiterbar ist. Somit läuft auf der Kiste ein Ubuntu Desktop in der Minimalinstallation von rund 700MB Größe und knapp 120MB Ramverbrauch. Zum Vergleich: die Server-Version von Ubuntu braucht nur 80MB RAM als Minimalinstallation, aber leider läuft der Kernel nicht auf diesem System.

System optimieren
Der Server soll ja in 99% seiner Zeit nur Mails verwalten und Webseiten ausliefern. Alles keine Dinge wobei eine Festplatte wirklich gebraucht werden würde. Da eben diese ja somit unnötig Strom verbrauchen und genau so unnötig verschleißen, sollten sie in eben 99% der Zeit kompett abgeschalten sein. Das ist derzeit so gelöst, dass alle relevanten Daten für den Web-Server und alle anderen Dienste im RAM abgelegt sind. Die Daten werden täglich per rsync auf die Platte gesichert. Ansonsten war noch, wegen des miesen APM bei meinen Hitachi-Platten, ein eigenes APM nötig. Beides läuft schon seit einiger Zeit stabil und problemlos, wobei es Zwischenzeitlich bei MySQL sogar gravierende Probleme gab, die sich aber jetzt erledigt haben.

Natürlich gabs dann noch die unvermeidlichen Angriffe aus dem Netz, die sich allerdings mit einigen Firewall-Einstellungen gut eindämmen lassen.

Messdaten
In der Praxis ist ja immer alles ein wenig anders, deswegen mal ein paar gemessene Daten.

Prozessorleistung

16,8 Sekunden (Kleiner ist besser). Gemessen mit folgender Befehlszeile, die zwar nicht wirklich repräsentativ, aber einfach nachvollziehbar ist: time perl -e 'foreach(1..10_000_000) { my $a = ($_ % 2) }' Als Grundlage gilt die “user” Angabe.

Festplattendurchsatz

21.95 MB/sec. Gemessen per hdparm -t /dev/sda

Stromverbrauch

24 Watt im Leerlauf, 34 Watt unter Vollast. Wobei die Messung mit einem 08/15 Leistungsmesser für die Steckdose erfolgte. Ich vermute, wenn man die Blindleistung und Messfehler noch abzieht, liegt das Teil bei knapp 10 Watt im Leerlauf.

Netzwerkleistung

80 KB/s download, 250 KB/s upload. Er hängt halt an einer 16MBit-ADSL Leitung.

Blog-Geschwindigkeit (WordPress)

~8 Seiten pro Sekunde, allerdings nur mit (Hyper)Cache-Plugin. Dieser Blog läuft ja aktuell auf dem Mini-Server, es ist durchaus brauchbar.

RAM-Verbrauch

~180 MB, wobei 60MB für die RAM-Disk drauf gehen

Verbrauchter Plattenplatz

Mit allen Tools und weiterem Schnickschnack derzeit 1,2 GB

Zum Vergleich der Prozessorleistung ein paar Daten von Rechnern freiwilliger Testpersonen. Allesamt schneller als der Mini Die Prozessorangaben wurden per cat /proc/cpuinfo|grep "model name" ermitelt.

Intel(R) Xeon(R) CPU E5430 @ 2.66GHz / 8 Cores [ vserver / Gentoo ]

1,67s

Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz / 2 Cores[ Tobi ws / Ubuntu ]

1,78s

Intel(R) Core(TM)2 Duo 2.4 GHz / 2 Cores [ Jo / Mac ]

1,88s

Intel 2,16GHz 2,38 / 2 Cores [ Ben / Mac ]

2,30s

Intel(R) Pentium(R) D CPU 2.80GHz / 2 Cores [ Tobi old-ws / Ubuntu ]

2,52s

Intel(R) Pentium(R) 4 CPU 3.00GHz / 2 Cores [ Alex / Gentoo ]

2,88s

AMD Athlon(tm) 64 3500+ 2,2GHz / 1 Core [ Alex server / Gentoo ]

3,02s

AMD Athlon(tm) 64 Processor 3700+ / 1 Core [ Ben home / gentoo ]

3,39s

AMD Athlon(tm) 64 Processor 3000+ [ Tobi home / Ubuntu ]

4,23s

Intel(R) Atom(TM) CPU 230 @ 1.60GHz / 1 Core [ Jo server / Debian ]

6,29s

AMD Athlon XP 1200+ / 1 Core [ Alex home / Gentoo ]

6,36s

Fazit
Ich bin sehr zufrieden mit dem Mini-Server. Die Einrichtung war, aufgrund fehlenden Wissens und einiger technischer Stolpersteine schwer, aber lehrreich. Die Leistung übertrifft meine Erwartungen und es sind noch genügend Kapazitäten frei, um da noch einiges hinzuzufügen. Ich bereue nichts

Anwendungen einrichten und weiteres…
Eingerichtet ist, wie schon gesagt, derzeit dieser WordPress-Blog mit ein paar Anpassungen, dann noch ein FTP-Client, SSH und ein StreamingServer. Aber das ist eine andere Geschichte und die wird ein anderes mal erzählt.

Bei der Erstellung des Scripts zum Spiegeln von /var in eine RAM-Disk habe ich, aus Mangel an Wissen und Erfahrung, das HUP-Signal benutzt um alle Prozesse, die unterhalb von /var ein offenes Filehandle haben, neu zu starten, damit die Überlagerung keinen Datenmüll ergibt. Bei ein paar, z.B. den klogd, hat das von vornherein nicht funktioniert, weswegen die explizit über ihr Init-Script neu gestartet werden.

Bei MySQL hat es nur scheinbar funktioniert, denn der Grund für den Crash von MySQL war genau das nicht neustarten. Der MySQL-Server hatte noch offene Filehandles auf dem Festplatten-Verzeichnis, dann hat die RAM-Disk das Verzeichnis überlagert und alle dann geöffneten Filehandles zeigten auf die RAM-Disk. Das Resultat war, wie zu erwarten war, Datenmüll.

Bei dem Script für die RAM-Disk ist MySQL jetzt auch explizit per Init-Script neu gestartet und das Ganze wurde von mir ausgiebig getestet: seit dieser Änderung bestehen keine Probleme mehr.

Jetzt muss ich mir nur noch überlegen, wie ich alle laufenden Prozesse mit Filehandles in /var dazu bringen kann, sich komplett neu zu starten. Derzeit fällt mir, außer Signalen, nichts ein, denn automatisch auslesen kann ich nur die PID und die Namen der Prozesse.

Zuerst: endlich nach etlichen Stunden wieder online! *puh*

Kaum auf dem eigenen Server und schon gravierende Probleme. Die MySQL-Datenbank ist Gestern irgendwann im Laufe des Tages komplett drauf gegangen. Warscheinlich wegen apparmor und meinen Spielereien mit “mount -bind” und einer RAM-Disk.

Resultat war, dass die Datenbank irgend einen Zwischenstand erreichte, der komplett inkonsistent war. Die Post-Tabelle war auf dem Stand von vorige Woche und die Tabelle “wp_options” enthielt plötzlich Kommentardaten. Also ist ganz unten auf der Ebene des Dateisystemes was gewaltig in die Hose gegangen.

Ich habe die bisherigen Daten des Blogs nur retten können, da ich ein Backup von letzte Woche hatte und die fehlenden Posts einfach aus dem Browsercache per grep (und per Hand! *schwitz*) wieder raus gefriemelt habe.

Da ich die Idee, alle Daten die sich oft ändern in einer RAM-Disk zu halten, nicht aufgeben will und die Schuld nicht bei MySQL sondern bei Apparmor suche, habe ich das erst mal so gelassen. Aber ich habe das MySQL-Profil aus der apparmor-Konfig genommen. Mal sehen, was das bringt, ich werde weiter darüber berichten.

Ich mach jetzt jedenfalls öfter Backup der Datenbank und muss mein Auto-Backup-Vorhaben mal endlich in die Tat umsetzen.

Erste Erkentnis: es könnte daran liegen, dass das disk2ram-Script den MySQL-Server und Apparmor nur per HUP-Signal neustartet. Ich habe jetzt Apparmor wieder aktiviert und beim disk2ram die beiden Prozesse explizit neu gestartet. Mal sehen…

Wenn man, wie ich, beim Systemstart das komplette /var – Verzeichnis in einer RAM-Disk spiegelt, was die RAM-Disk per mount bind einfach über das Originalverzeichnis legt, kann bei MySQL Probleme bekommen.

Problem
Bei dem Befehl create database DATENBANKNAME; und anschließendem use DATENBANKNAME; wurde gemeldet, dass diese Datenbank, die ich ja gerade angelegt hatte, nicht existiert. Ein Blick in’s Dateisystem bestätigte das auch. Durch dummen Zufall schaute ich auch in’s überlagerte Festplatten-Verzeichnis und fand dort die eben angelegte Datenbank.

Außerdem fiel auf, dass sämtliche Änderungen in der mysql-Tabelle, also Benutzer anlegen, Rechte vergeben etc, keinerlei Wirkung hatten. Auch hier wurden alle Daten direkt in das überlagerte Verzeichnis geschrieben. Beim Lesen der Daten wiederum wurde die RAM-Disk verwendet.

D.h. sämtliche Änderungen wurden mit OK quitiert, aber geändert hat sich nichts, denn beim Auslesen wurden immer die Daten von der RAM-Disk genommen.

Bei der Änderung von normalen, schon bestehenden Datenbankdaten, z.B. beim anlegen von Tabelle oder ändern von Inhalten, funktionierte alles korrekt.

Ursache
Wie schon damals beim Umzug des MySQL-Datenverzeichnisses hatte ich meinen Freund apparmor in Verdacht. Ich weiß nicht genau, diese Anwendung arbeitet, aber in der Konfig.-Datei werden die Verzeichnisse angeben, in die die jeweilige Anwendung schreiben darf.

Ausgehend von meiner Konfiguration mit dem Überlagern mit der RAM-Disk müssen in die Datei /etc/apparmor.d/usr.sbin.mysqld folgende Zeilen zwischen die {} eingetragen werden.

/.disk2ram/var.volatile/lib/mysql/ r,
/.disk2ram/var.volatile/lib/mysql/** rwk,
/.disk2ram/var.state/lib/mysql/ r,
/.disk2ram/var.state/lib/mysql/** rwk,

Danach kann man MySQL auch wieder vernünftig verwenden, hoffentlich

Nachtrag: es gibt immer noch untragbare Probleme (z.B. einen Komplett-Crash von MySQL) in dieser Konfiguration. Ich bin noch an der Lösung dran…

Wenn man eine Festplatte dauerhaft oder zeitweise aus der Hand gibt, möchte man die darauf enthaltenen Daten ja nicht unbedingt immer mitliefern. Ein einfaches Löschen hat meistens nicht den Effekt, dass die Daten weg sind, sondern nur, dass der Eintrag im Dateisystem nicht mehr aufgelistet wird. Die Daten selber sind noch immer an Ort und Stelle.

Abhilfe schafft hier das kleine Werkzeug wipe. Ich weiß nicht mehr genau, in welchem Packet das enthalten war oder ob es ein eigenständiges ist, aber mit sudo apt-get wipe kriegt man im Zweifel gesagt, wo man es her bekommt. Folgendermaßen wird es verwendet:

wipe -q /dev/sdb

Hiermit wird die komplette Festplatte 4 mal überschrieben. Das dauerte bei meiner 80 GB SATA Platte schon geschlagene 2 Stunden. Ich finde, für den Normalfall sollte das genug sein. Wer wirklich sicher gehen will, sollte 30 bis 40 mal überschreiben, z.B. so:

wipe /dev/sdb

Damit werden, zumindest laut wipe-Doku, die Daten 34 mal überschrieben. Das dauert bei mir warscheinlich mehr als einen Tag, aber es ist (relativ) sicher, dass die Daten danach wirklich weg sind. per wipe -Q NUMMER /dev/sdb kann man die Anzahl der Durchgänge selbst festlegen, allerdings wird bei den 34 Durchgängen ein festgelegtes Muster benutzt, welches der Löschaktion sicherer macht. Von -Q ist also ab zu raten, da es im Zweifel nur mehr Zeit verbraucht.

Nebenbei: Die Meldung beim Start, ob die Spezialdatei überschrieben werden soll, muss einfach mit ja bestätigt werden. Das ist vielleicht etwas unglücklich ausgedrückt und meint eigentlich die Festplatte selber. Mich hat es im erstem Moment jedenfalls etwas verwirrt.
Und auch der Hinweis in der Doku zum Thema ganze Festplatte platt machen verwirrt etwas:

[...] this will destroy your master boot record. Bad idea.

Die Platte muss danach eben komplett neu partitioniert werden, da jedes Bit ein mal überschrieben wurde. Auch die Partitionsinfos. Aber mehr passiert da nicht.