Einleitung
Was braucht man sinnigerweise für einen Server den man Schlafen legen will?
- Eine CPU/Board – Kombo die das unterstützt…
- Eine Netzwerkkarte die WakeUp-on-LAN unterstützt
- Alle Periferiere muss Suspend unterstützen (RAID Controler, etc…)
Primär spielt es keine Rolle welchen Suspend man anstrebt. Ob „Suspend to Ram“ (Suspend) oder „Suspend to Disk“(Hibernate) unterscheidet sich im Administrativen, wie man den Server dazu bekommt, nicht. Es muss einfach ein anderer Wert (Zahl) in /proc/acpi/sleep geschrieben werden…
In meinen Versuchen hat sich Suspend to RAM aber als sinnvoller erwiesen. Das Aufwachen nach einem Suspend ging (erwartungsgemäß) schneller. Aus einem Suspend kam der Server innerhalb von unter 2 Sek wieder zum laufen (laut Kernel – Syslog, zu messen war das kaum sinnvoll…) beim Hibernate benötigte es einen kompletten Boot… das dauerte bei mir ganze 5-7 Sekunden.
Die Einsparung an Energie gegenüber einem Suspend hielt sich in grenzen:
- Server (Boot): 75 Watt
- Server (Working): 20 Watt
- Server (Idle): 15 Watt
- Server (Suspend): 3 Watt
- Server (Hibernate): <1 Watt
Der geringe „Gewinn“ war es mir nicht wert meine Sicherheit und die Response-Zeit zu opfern… Man sollte immer bedenken, dass der Memory auf die Festplatte geschrieben wird…. und selbst wenn man den verschlüsselt, ein Angreifer den Server bewegen kann (da er keinen Strom braucht) und in seiner umgebung booten kann… Hat man hingegen ein verschlüsselte Boot-Partition (TrueCrypt etc) nutzt einem der Hibernate nicht viel, da der Server nicht „unbeobachtet“ wieder hoch kommt…
Vorbereitungen
Als erstes muss man die Netzwerkkarte testen bzw fit für WakeUp on Lan (WOL) machen. Wie das geht wird sehr gut hier beschrieben. Zu den einzelnen WOL-Modi:
- WOL-Packet: Das eigentlich aufwecken über ein WOL/Magic-Packet ist weniger Sinnvoll und erlaubt nur einen Betrieb eines File/Domain-Servers. Beim Booten müssen alle Clientes automatisiert das WOL-Packet lostrehten und der Server darf über die dauer der Session nicht runter Fahren.
- u/m/b/a: Das Aufwachen des Servers bei Broad/Multi/Uni-Cast ist die (imho) interessanteste Variante. Der Server wird in jedem Fall geweckt wenn er gebraucht wird. Fast alle heute verwendeten Protokolle arbeiten über IP. Dabei impliziert ist das beziehen einer Adresse (DHCP) und das Auflösen einer Adresse (ARP). Beide Protokolle beginnen den initialen Request über Broadcast. So kann man fast alles betreiben: DHCP, DNS, Webserver. Warum im Standart nochmals ein WakeUp on ARP(a) ausgewiesen wird, erschließt sich mir nicht…
- WakeUp on physikal activity: diesen Modus hab ich bei meinen getesteten Karten nicht zum laufen bekommen. Oder nicht so wie ich das wollte. Entweder wurde der Rechner sofort nach seinem suspend wieder geweckt oder er reagierte überhaupt nicht… wer denn Sinn dahinter versteht, möge es posten…
Shutdown
Ich habe lange gesucht (ok, nicht wirklich lange, aber schon länger… ;)) bis ich eine geeignete Methode gefunden hatte, bzw zu meiner ersten Idee zurück kam. Ich machs kurz: Sleepd und andere Methoden Interupts abzufragen (oder besser deren nichterscheinen) funktionierten nicht oder nur eingeschränkt… Die interessanten Interrupts ließen sich nicht abhören und so was wie Maus und Tastatur nutzt bei einem Server ohne selbige nichts.
Deswegen verwende ich einen Script der alle 5 Minuten via Cron ausgeführt wird. Dieser ist in seiner „Urform“ hier zu finden. Der Script als solches funktioniert prima, musste nur um zwei Funktionalitäten an meine Bedürfnisse angepasst werden.
- Wenn man den Server als zentralen FileServer für die Home-Dirs nutzt, sollte dieser tunlichst nicht runterfahren, solange ein User angemeldet ist. Das CIFS/Samba Protokoll und deren Implementierungen können das zwar ab, die Programme (KDE, OpenOffice, …) jedoch nicht. Stalled Lockfiles und andere „interessante“ Probleme sind die Folge… Aus diesem Grund habe ich den Script um eine Überprüfung erweitert, ob SMB-User angemeldet sind. Dies erfolgt über „smbstatus“.
- Des weiteren kam es immer wieder dazu, dass der Server nicht „richtig“ in den Suspend ging, oder nicht ordentlich aufwachte.Dies häufte sich besonders bei häufigen Suspends (ich hatte Testhalber die Überprüfung auf minütlich gesetzt). Nach einer weile /var/syslog-Studium fand ich den Übeltäter. Cron kann zuschlagen, während der Kernel noch am „aufwachen“ ist und im somit abermals einen Schlafbefehl verpassen. Das bringt den Kernel ein wenig aus dem Trab. Um das zu unterbinden hab ich zwei weitere Prüfungen eingebaut. Zum einen wird ein Lockfile angelegt, das erst nach dem beenden von des „echo“-Befehls gelöscht wird, eine Semaphore. Zum zweiten muss zwischen „Aufwachen“ und erneutem Suspend mindestens 30 Minuten liegen. Dies wird mit einem Datei geprüft die mittels „touch“ aktualisiert wird, bevor das Lockfile gelöscht wird. Danach einfach das Datediff abfragen…
Die von mir verwendete Version ist hier zu finden.
Fazit
Der Server steht mir nunmehr 24/7 zur Verfügung, spart sich jedoch Strom da nicht immer an… Zudem zühlt die Uptime auch hoch, obwohl der Server am „Schlafen“ ist, nennt man das cheaten? *G*
Einziges Manko: Aus Sicht der Festplatten handelt es sich um einen „Shutdown“. Zu mindestens wird der Motor komplett stromlos geschaltet. Das Wiederanfahren sowie justieren der Köpfe reduziert die Lebensdauer der Platten entsprechend. Bei guten (verlässlichen) RAIDs sollte das aber kein Problem darstellen.