Hinter den Kulissen dieses Servers

Mit dieser Site möchte ich interessierten einen kleinen Einblick in die verschiedenen Seiten des Server-Betriebes geben, was meine Beweggründe dafür sind, was für Probleme und Herausforderungen sich stellen und natürlich alle möglichen technischen Details über die Büchse, die bei mir im Keller 24/7 läuft.
Wieso zum Geier ein eigener Server?
Kosten
Verwendete Hardware
Hardware-Setup
Verwendete Software
Software-Setup
Systemstabilität und Verfügbarkeit

Wieso zum Geier ein eigener Server?

Ich habe diverse schlechte Erfahrungen mit Gratis-Anbietern von Webspace gemacht, das kam für mich daher eigentlich nicht in Frage. Ausserdem ist dort der Platz limitiert, bei zuviel Traffic wird die Page gekickt, und PHP/MySQL gibts sowieso nicht. Ein bezahltes Angebot hingegen wollte ich auch nicht, einerseits weil die Platzlimitierung und das Traffic-Limit weiterhin bestehen und andererseits weil man dann mit dem Server ja doch nicht machen kann, was man will. Da ich sowieso einen Fileserver wollte, war es für mich auch kein grosses Problem, diesen dann gleich auch noch als Webserver auszulegen.

Kosten

Nun, glücklicherweise sind Heim-Server in Bezug auf die Hardware relativ genügsam (ein 500er P3 würde für meine Anwendungen durchaus reichen); für den Privatbetrieb muss es ja kein Hardware-RAID-10 mit 4 15'000er Seagate Cheetahs, Dual Xeon und 16GB ECC Ram sein (wobei, cool wäre das natürlich schon *träum* :D)
Wer die Ansprüche etwas senkt, kann sogar einen ausrangierten PII nehmen und ihn Festplattenmässig etwas aufrüsten.
In Sachen Internet-Verbindung ist IMO eine Leitung mit 128kbit Uplink durchaus Server-tauglich, da ja meistens nur ein Besucher gleichzeitig den Server besucht und dieser bekommt mit 10-16kb/s von mir aus gesehen eine recht anständige Performance (das reicht natürlich nicht, um grössere Downloads zu hosten).
Ein weiterer Kostenfaktor ist der Stromverbrauch. So ein Server braucht locker 30-150W, das kann bei 27/4-Betrieb jährlich immerhin etwa 50-250 SFr. ausmachen. Allerdings muss man das auch im Verhältnis sehen: Eine typische billige Stereoanlage oder ein Fernseher braucht im Standby auch bis zu 30W, und da hat man überhaupt nichts davon... (ganz abgesehen davon, dass der mit sehr viel Abstand grösste Kostenpunkt beim Stromverbrauch noch immer die Warmwasserproduktion ist).

Verwendete Hardware

Gehäuse:	Chieftec Big-Tower
Netzteil:	Enermax EG465AX-VE(G)
CPU:	AMD Duron 1100 MHz
Mainboard:	Gigabyte Sockel A
Chipsatz:	VIA KT133 (686A Southbridge)
RAM:	1.25 GB PC133 CL3 noname (2x512MB + 256MB)
Grafikkarte:	Matrox Millennium 2MB PCI
Netzwerkadapter:	DecChip 21140 Dual Channel 100MBit
IDE-Kontroller:	Promise FastTrack TX2
Harddisks:	2x Maxtor DiamondMax+ 80GB (7200) UDMA-133, Software-RAID-1 gespiegelt, angehängt an ersten und zweiten Kanal des Promise TX2 1x Western Digital 120GB (7200) UDMA-133 (@UDMA-66), erster Kanal der 686A als Master 1x Seagate 200GB 7200, UDMA-100 (@UDMA-66), erster Kanal der 686A als Slave (wird vom BIOS nicht korrekt erkannt, daher im BIOS deaktiviert, läuft unter Linux aber trotzdem einwandfrei) 1x Maxtor DiamondMax 120GB (5400) UDMA-133 (running on UDMA-66), zweiter Kanal der 646A als Slave
CD-Rom:	Mitsumi 8x, PIO3, zweiter Kanal der 686A als Master

Hardware-Setup

Die Hardware ist völlig unspektakulär in das Bigtower-Gehäuse eingebaut. Über dem Parallelport blasen zwei Papst 0.6W Lüfter die luft nach draussen; in den beiden Festplattenkäfigen saugen zwei weitere gleiche Lüfter die Luft an. Für die IDE-Verkabelung wurden 4 Rundkabel (schweineteuer) verbaut, weil die Rundkabel einfacher zu installieren sind, den Luftstrom weniger behindern und dank ihrer Ummantelung nicht so "allergisch" auf scharfe Gehäusekanten sind.

	2x 100MBit Ethernet, Monitor&Tastatur, Serielles Kabel zum Router und Strom, mehr braucht kein Mensch
Das Aristo-Mainboard eingebaut (inzwischen ersetzt, das Aristo AM-911 läuft jetzt im Desktop meiner Mutter)	Zuoberst die WD 120GB, dann die IBM 60GB, und zuunterst die beiden 80GB Maxtor

Ein leidiges Thema sind auch immer die Lüfter. Es sind umbedingt qualitativ einigermassen hochwertige Luftwirbler zu verwenden, ansonsten liegen die bald mal ab. Als Gehäuselüfter haben sich bei mir Sunon (nicht gerade leise) und natürlich Papst bewährt.
Erstaunlicherweise lebt der CPU-Lüfter noch, dieser scheint mir nicht gerade ein Qualitätsprodukt zu sein...
Temperaturmässig habe ich mit meinem Server eigentlich keine Probleme, u.a. weil die Duron-CPU nicht gerade viel Abwäme produziert und weil es in dem Kellerraum, wo der Server steht, auch im Sommer kühl ist.
Früher war im alten Gehäuse noch ein Luftfilter eingebaut; wieso zeigen am besten ein paar Bilder:

Das war mal weiss...	Der aussen drauf montierte Luftfilter (Bild noch vom alten Server-Gehäuse)

Spezielle Beachtung verdient IMHO auch das Netzteil. Hier macht es von mir aus gesehen keinen Sinn zu sparen, denn gerade bei vielen Festplatten kommt ein billiges Netzteil beim Systemstart schnell an seine Grenzen, und man will ja auch nicht, dass nach 20 Systemstarts das Netzteil abraucht... Ausserdem kann das System bei schwachen Netzteils instabil werden. Zu bedenken ist auch, dass 24/7-Dauerbetrieb andere Anforderungen stellt als ein üblicher Desktopbetrieb. Hilfreich sind auch starke Lüfter (ein Server muss ja nicht speziell leise sein), um die Systemtemperatur tief zu halten. Die Dinger von Enermax sind daher prädestiniert als HighEnd-Netzteile mit manuell regelbaren Lüftern und Drehzahlüberwachung sowie PFC für möglichst hohen Wirkungsgrad und vielen Laufwerkssteckern. Ein 350W Modell müsste eigentlich reichen, sofern nicht eine extrem stromfressende CPU verbaut ist (AMD XP, schnelle Palominos und P4). Ich bin bei mir mit der 460W Version auf Nummer sicher gegangen (der Wirkungsgrad ist idr. auch besser, wenn das Netzteil gewisse vorige Kapazitäten hat).

Verwendete Software

- Debian Woody 3.0
- Kernel 2.6.1 mit fest eingebautem RAID-1 und TX2-Treiber
- EXT3 als journalling-Filesystem
- Apache 1.3.26 (PHP4)
- MySQL als Datenbank
- Samba/NFS als File-Server (was soll ich sonst mit all dem Platz anfangen? ;))

Software-Setup

Auf die detailierte Konfiguration des Servers will ich hier nicht eingehen, das macht IMO einerseits keinen Sinn (weil es viel zu viele zu beachtende Details gibt) und andererseits soll es auch nicht ganz so einfach sein, meinen Server nach Konfigurationsfehlern auszuspähen. Wenn aber jemand eine konkrete Frage hat werde ich diese gerne per E-Mail beantworten.
Ein paar Punkte sollen aber doch hervorgehoben sein:

Software-RAID
Ich will hier kein How-To dazu schreiben, da gibts schon einige gute (z.B. mal auf http://tldp.org/ nach "RAID" suchen), aber das Konzept will ich doch noch erwähnen.
Bei RAID (Redundant Array of Inexpensive Disks) geht es darum, Datensicherheit und/oder Performance zu erhöhen (und im Falle LVM (=JBOD="just a bunch of disks") einfach das kombinieren vieler kleiner Platten), indem mehrere Festplatten zur einem RAID-Verbund kombiniert werden. Bei dem von mir gewählten RAID-1 wird der Inhalt des Filesystems jeweils auf zwei Platten geschrieben, damit beim Ausfall der einen das System ohne Datenverlust weiterlaufen kann. Idealerweise werden hierzu zwei identische Platten verwendet.
Das RAID kann nun klassisch über einen richtigen Kontroller betrieben werden; dabei gibt es echte Hardware-Kontroller (teuer, dafür niedrige CPU-Last) und pseudo-Hardware-Kontroller, die die eigentliche Arbeit der CPU überlassen und eigentlich nur einen BIOS-Hack darstellen. Letztere sind dafür sehr billig.
Da Linux letztere Kontroller nur experimentell unterstützt und ich schon in Besitz eines nicht-RAID UDMA133-Kontrollers war (Promise TX2), entschied ich mich für eine "billige" Lösung über das Software-RAID des Linux-Kernels. Nach einigen vorhergehenden Experimenten befand ich das System für tauglich; das Testsystem überlebte das ausstöpseln der 1. Platte im laufenden Betrieb und war auch von der 2. Platte noch bootfähig (ab lilo 22.0 mit spezieller Konfiguration). Wie sich herausstellte war das alles auch mit dem Promise-Kontroller kein Problem; dieser bootet dikussionslos von der Platte am 2. Kanal, wenn die am ersten nicht bootfähig oder garnicht vorhanden ist.
Zu beachten ist bei IDE-RAID-1 auch, dass beide Platten einen eigenen IDE-Kanal erhalten. Einerseits wären 2 Platten an einem Kanal tödlich für die Performance, und andererseits wäre das System bei defekter Master-Platte je nach BIOS und Defekt nicht mehr bootfähig.

Geschwindigkeitsmässig sieht es so aus, dass Schreibvorgänge bei RAID-1 etwas langsamer sind als bei nur einer Platte (bei mir ca. 36MB/s sequentiell laut Bonnie), Lesevorgänge dafür massiv schneller (ca. 55MB/s), wenn auch nicht so schnell wie bei RAID-0. Die CPU-Last ist IMHO vernachlässigbar.

Überlebt das RAID die "ausgefallene" Festplatte?	Dieses Netzteilchen hat mich 170 SFr. gekostet! Dafür hält es hoffentlich länger als das letzte :)

Traffic-Shaper
Über einen 256kbit-Link (früher 64kbit, später 128) einen Server zu bereiben ist mühsam, da jedesmal, wenn jemand den Server besucht, die Transferraten für unsere Computer im LAN in den Keller gehen. Dieses Problem löst ein Traffic Shaper elegant.
Dieser Traffic Shaper läuft auf dem Router und nicht auf dem Server, da er auch den Traffic, der direkt vom LAN kommt, berücksichtigen soll. Als Queuing-Discipline verwende ich HTB, das ab 2.4.20pre2 standardmässig dabei ist (eine modifizierte TC-binary muss allerdings u.U. noch eingespielt werden).
Das Funktionsprinzip ist - vereinfacht - folgendes: Bei einem Netzwerk-Link entstehen üblicherweise an der langsamsten Stelle des Netzes (im Modem oder beim Speed-Begrenzer - auch ein Traffic Shaper - der Providers) Warteschlangen. Wenn man nun dafür schaut, dass diese im eigenen Router entstehen (indem man den Uplink von 256kbit auf z.B. 240kbit reduziert), kann man nun den Linux-Kernel anweisen, gewisse Traffic-"Arten" (classes) zu bevorzugen (z.B. ACKs, SSH oder Online-Games) und alles andere hinten anstellen (z.B. HTTP). Genauer gesagt kann man Klassen anlegen, die jeweils eine minimale und eine maximale Bandbreite besitzen (wobei natürlich die Summe der minimalen nicht mehr als der gesamte Link sein sollte) und eine Priorität, nach der sie die Bandbreite, die andere Klassen vorig haben, bekommen. Möglich sind auch Bursts, so dass z.B. HTTP für eine kurze Zeit die gesamte Bandbreite zur verfügung haben kann.
Ein Problem ist dabei der Filter, der den Traffic in die Klassen sortiert. Da der Filter "zuäusserst" beim Internet-Interface "angehängt" wird, also NACH dem NAT, wird es fast unmöglich, den Traffic noch erfolgreich zu unterscheiden. Doch das kann man umgehen, indem man die Packete mit iptables z.B. in der FORWARD-queue markiert und dann anhand dieser Markierung (die das NAT überlebt) sortiert. Wenn die Markierung auch den Gang durch das Netzwerk übereben soll, kommt hingegen nur das TOS (Type of Service)-Feld in Frage; Traffic, der beim Shaper eine hohe Priorität erhalten soll, kann daher auch auf einem anderen Gerät z.B. mit dem TOS_minimize_delay-Flag ausgestattet werden (und muss natürlich dann beim Shaper anhand dieses Flags erkannt und in die richtige Klasse gefiltert werden).
Mehr Infos (u.a. über HTB und ein Dokument mit guten Beispielen) unter http://luxik.cdi.cz/~devik/qos/htb/.

DynDNS
Eine IP in der Adresszeile ist nicht gerade schön, und schon garnicht gut zu merken. Aber spätestens wenn der Server über eine DSL-Verbindung mit Zwangstrennung betrieben werden soll, wird es völlig unpraktikabel, da sich die IP dann alle 24h ändert.
Als Lösung bietet sich ein echter Domainname an (nicht zu verwechseln mit einem URL-Forwarder wie go.to, der die gestellte Aufgabe zwar idr. auch einigermassen erfüllen kann, aber längst nicht so eine schöne Variante darstellt). Hervorheben möchte ich hier die Dienste von DynDNS.org und CJB.NET, wobei mein Server, wie unschwer an der URL zu erkennen, über letzteres läuft. Beides sind allerdings keine beliebigen Domainnamen, sondern es sind immer Subdomains von .cjb.net oder .dyndns.org, dafür sind sie auch gratis. Beide bieten auch spezielle Tools an, mit denen sich die IP einfach updaten lässt; bei mir ist z.B. der CJB-Updater direkt im Packetfilter-Skript eingebaut und wird bei jedem Systemstart des Routers sowie bei einem Wechsel der IP ausgeführt. Einige Hardware-Router bieten auch direkt Support für dyndns.org, womit man sich dann solche Basteleien ersparen kann.
Dieser Domainname kann nun für alle Services, die auf dem Server laufen (bzw. auf dem Router geforwardet sind) eingesetzt werden, also auch für SSH, FTP etc (was mit einem URL-Forwarder nicht möglich ist).

Systemstabilität und Verfügbarkeit

Obwohl die Hardware billig ist, läuft das System sehr stabil. Ein Teil der Hardware läuft schon seit Anfang 2002, mit zwei Kernel-Lockups (eine Disc am Promise TX2 produzierte schlechte Sektoren, was dem 2.4.18er Kernel des SuSE 8.0, das damals installiert war, zum Verhängnis wurde). Dazu ist anzumerken, dass ich keine präventiven Reboots oder sowas mache; das System wird nur bei Hardwareänderungen runtergefahren. Ich erwähne an dieser Stelle gerne das Beispiel des typischen NT-Admins, der auf schweineteurer Hardware mit ECC-RAM und redundanter PSU Windows installiert *LOL*
Gröberes Kopfzerbrechen bereitet mir hingegen die Stabilität des örtlichen Stromnetzes. Deshalb habe ich mir Ende 2004 eine USV gekauft, genauer gesagt eine APC Smart-UPS 700. Dank der ETH zu einem vernünftigen Preis :)