Hardware vs. Cloud

Jüngst hatten wir beim Freifunk im Kreis Gütersloh ja ein paar technische Probleme …

Die Idee der (public) Cloud ist ja relativ charmant. Man bucht sich »passende« VMs, zahlt für die Nutzung und hat mit dem technischen Betrieb nichts am Hut. Nutzt man einen Datenspeicher in der Wolke des Anbieters, und nicht lokale Speichermedien der lokalen Hardware, wandert bei Hardwaredefekten die eigene VM, teils live, teils nach Reboot, einfach auf eine andere Hardware und außer der kurzen Downtime bekomme man davon nicht einmal etwas mit. Ggf. auch inklusive der (externen) IPv4-Adresse.

Die Kehrseite der Medaille ist dann allerdings, daß man i. d. R. diesen Komfort »irgendwie« auch bezahlt. So kostet die kleinste Amazon-Server-Instanz in Frankfurt zwar »nur« knapp 11 US-Dollar im Monat, also um und bei 10 EUR — sollte diese VM allerdings 10 TB externen Datenverkehr verursachen, kostet jenes System schlappe USD 898,65/Monat.
Zum Vergleich: Bei Hetzner, einem eher klassischen Rechenzentrum, kostete die vergleichbare Leistung (1 vCPU, 1 GB RAM) 4,64 EUR/Monat für die VM (ink. 2 TB Datentransfer) bzw. inkl. 10 TB nur 15,76 EUR/Monat. Hier wandert die IP allerdings nicht mit, neue VM bedeutet also zwingend auch neue externe IPv4-Adresse.

Eine potentielle Schattenseite der Virtualisierung sollte man stehts im Auge haben: je nach Konzept des Anbieters (wird die Hardware »überbucht«, also z. B. mehr vCPUs als reale CPU-Kerne vorhanden sind, vermietet oder nicht?) kann einem die sonstige Nutzung der geteilten Hardware interessante Streiche spielen. Bricht z. B. der Durchsatz auf dem VPN-Tunnel ein, ohne daß sich an den Lastwerten auf der VM etwas geändert hat, könnte ein Poweruser auf einer der anderen VMs des Hypervisors daran (mit) Schuld sein. Ohne Sicht auf die Werte des Hypervisors kann man da nur raten, und falls es einen trifft, auch nicht wirklich etwas tun, außer, eine andere VM zu nutzen.

Für Freifunk Gütersloh stand daher relativ früh fest, daß das Anmieten einzelner VMs keine wirkliche Lösung ist. Auch unter Kostengesichtspunkten nicht: in Hetzners Serverbörse kostet ein Server mit Intel Core i7-3770, 2 SATA-Platten im TB-Bereich und 16 GB Hauptspeicher inkl. 20 TB Traffic zwischen 35,– und 40,– EUR im Monat. Das sind 4 echte Kerne plus HT, damit ist die Kiste »gut« für 4-8 VMs und damit vergleichbar mit den Kosten von 8 kleinen (»CX10«) VMs. Im Gegenzug hat man das Blech unter seiner Kontrolle, sieht also auch, ob/wo es auf der Hardware eng wird.

Der Nachteil allerdings ist, daß man sich eben auch (wieder) mit Hardware herumschlagen muß. So hat ein bei xirra.net angemieteter Server kürzlich /dev/sda, also die erste Festplatte, verloren. Sowas kann ja mal passieren, dummerweise ist das System nicht so aufgesetzt gewesen, daß es auch von /dev/sdb booten konnte — Resultat ist also eine erweiterte Downtime, denn nun muß per Remote-Console oder Rescue-System die neue /dev/sda korrekt eingebunden werden und grub darauf installiert (und vorzugsweise auch auf /dev/sdb für’s nächste Mal).

Derlei Probleme hat man mit einem Hardware-RAID-Controller, wie wir ihn in unseren HP-Servern im Gütersloher Rechenzentrum haben, nicht; und dank HP iLO haben wir dort auch sogenannten »Lights Out«-Zugriff, d. h. auch wenn es im RZ dunkel ist (sprich: niemand vor Ort), können wir den Server restarten, BIOS-Optionen ändern, Consolen-Nachrichten einsehen …

Ähnliche Optionen bieten professionelle Rechenzentren wie xirra.net oder Hetzner für gemietete Server ebenfalls; bei Hetzner ist das Anschalten der Remote-Console für 3 Stunden z. B. kostenlos (danach 10,– EUR je 3 Stunden), bei xirra wird diese auf Anforderung bei Problemen ebenfalls kurzfristig bereitgestellt.

Was aber hat das mit den jüngsten Problemen beim Gütersloher Freifunk zu tun? Nun, am 07.02.16 begann unserer Hauptserver bei Hetzner, »carrot«, immer mal wieder stehen zu bleiben. Rebooten lies sich das System per Klick im Kundenbereich von Hetzner, aber lösen lies sich das Problem nicht. Wenige Minuten bis einige Stunden nach einem Reset war der Server wieder weg.
Nächster Schritt daher war die Eröffnung eines Support-Cases. Sehr löblich: bei Hetzner wird auch am Wochenende nicht nur die Supportqueue beantwortet, sondern es werden auch Arbeiten vorgenommen; so wurde am Sonntag um 21:39 das erste Mal die Remote-Console bereitgestellt. Blöderweise lief der Server die nächsten paar Stunden problemlos, sodaß auf der Console kein Grund für die Ausfälle gesehen werden konnte — nach drei Stunden wurde die Remote-Console wieder deaktiviert.

Nach mehreren Resets per Kundenbereich wurde dann am 09.02.16 erneut ein Ticket eröffnet; Hetzner schlug dann vor:

Wir würden Ihnen anbieten, den RAM auf Verdacht zu tauschen, das BIOS zu prüfen und ggf. upzudaten und die HDDs einem Kurztest zu unterziehen.

Doch auch der RAM-Tausch stellte die zufälligen Ausfälle nicht ab, sodaß am 13.02.15 die komplette Hardware, bis auf die beiden Festplatten, getauscht wurde. Der Server wurde im Rescue-System übergeben, da sonst wohl, durch die geänderte MAC-Adresse der Netzwerkkarte, jene als eth1 erkannt worden und kein Netzwerkzugriff möglich gewesen wäre. Hut ab, daran hätte ich wohl an der Stelle gar nicht gedacht.

Leider bleiben die sporadischen Ausfälle auch nach Kompletttausch der HW existent. Mittlerweile waren alle »relevanten« VMs, bis auf bgp3 und gw01, auf einen zweiten Server bei Hetzner umgezogen — »virsh migrate« 4TW! Aber, und da kommen wir wieder zum Thema Hardware vs. Cloud, während der Umzug auf KVM-Ebene simpel war (auch ohne shared storage zwischen den beiden HVs), da die IP-Adressen leider an der jeweiligen Hardware hängen, war für bgp4 und gw03 ein IP-Adresswechsel vorzunehmen. Heißt u. a., daß alle Tunnel zwischen unseren Systemen und bgp4 bzw. gw03 neu konfiguriert und gestartet werden mußten. Ein Glück, daß die Serverkonfiguration über puppet-Skripte erstellt wird; händisch wäre das eine Sisyphos-Aufgabe gewesen.

Nachdem »carrot« also nicht mehr soo kritisch war, sollte den Ausfällen, die einen HW-Tausch überlebten und damit eher nicht auf Hardware zurückzuführen sein dürfen, nun auf den Grund gegangen werden. Am 15.02.16 wurde erneut eine Remote-Console aktiviert; unter erschwerten Bedingungen, denn auf dem frisch installierten privaten Linux-Laptop war kein Java-Plugin installiert, und die Internetanbindung am Aufenthaltsort war mit max. 1 MBit/sec auch nicht grade gut (ja, Mobilfunk).
Aber, wie es der Zufall wollte, nachdem das Java-Problem zumindest partiell umschifft wurde, crashte »carrot« erneut. Ja, richtig: der Hypervisor crashte (Kernel panic), allem Anschein nach war (und ist) es ein reines Softwareproblem. Über die Remote-Console war der Grund zwar nicht ersichtlich, aber seit Installation von »[linux-]crashdump« bleibt der Server nicht mehr stehen, sondern rebootet und schreibt den Grund des Crashs auf die Festplatte:

root@carrot:~# grep BUG /var/crash/*/dmesg*
/var/crash/201602172304/dmesg.201602172304:[125463.008262] kernel BUG at /build/linux-lts-wily-Vv6Eyd/linux-lts-wily-4.2.0/net/core/skbuff.c:2097!
/var/crash/201602190602/dmesg.201602190602:[111290.121380] kernel BUG at /build/linux-lts-wily-Vv6Eyd/linux-lts-wily-4.2.0/net/core/skbuff.c:2097!
/var/crash/201602200743/dmesg.201602200743:[92305.114517] BUG: unable to handle kernel NULL pointer dereference at 0000000000000084
/var/crash/201602202304/dmesg.201602202304:[55184.695098] kernel BUG at /build/linux-lts-wily-Vv6Eyd/linux-lts-wily-4.2.0/net/core/skbuff.c:2097!
/var/crash/201602202341/dmesg.201602202341:[ 2126.863449] kernel BUG at /build/linux-lts-wily-Vv6Eyd/linux-lts-wily-4.2.0/net/core/skbuff.c:2097!
/var/crash/201602210736/dmesg.201602210736:[28419.985164] kernel BUG at /build/linux-lts-wily-Vv6Eyd/linux-lts-wily-4.2.0/net/core/skbuff.c:2097!

Ob dies noch das gleiche Problem wie initial ist, ist leider unklar; um allen Eventualitäten aus dem Weg zu gehen, wurde auf den neuesten LTS-Kernel aktualisiert, eben den 4.2.0 von Ubuntu Wily. Und genau zu dem Symptom gibt es auch einen Bugreport auf kernel.org; mittlerweile konnte das Problem auf die VM »bgp3« eingegrenzt werden, denn obige Abstürze geschahen nur, wenn »bgp3« aktive war (alleine oder zusammen mit »gw01«).

Lessons learned (einiges waren Wiederholungen ;)):

• Eine VM macht noch keine Cloud
• Virtualisierung schützt nicht vor Hypervisor-Crash
• Eine Remote-Console ist essentiell, ebenso wie das »crashdump«-Paket
• Hardware geht eigentlich nicht kaputt, Softwarefehler sind wahrscheinlicher
• Ein Hoster, der proaktiv Hardwareaustausch anbietet, ist sehr angenehm
• Neuer ist nicht zwingend besser; aber ggf. findet man leichter ähnliche Fehler­mel­dungen

Warum »bgp3«, was eigentlich nichts anders macht als »bgp1« und »bgp2« in Gütersloh, und sogar weniger IPv6-Gedöns mach als »bgp4« (dort läuft als Test ein IPv6-GRE-Tunnel für ein direktes Peering mit einer anderen Freifunk-Community, Versuchsballon für die Aufgabe/Einschränkung der IC-VPN-Präsenz), hier den Hypervisor zum Absturz bringt, ist noch ungeklärt. Erst einmal muß nun »gw03« noch aktualisiert werden (neue Tunnel zu allen FFGT-Systemen, s. o.), und dann wird »bgp3« wohl einfach neu aufgesetzt. Der letzte Absturz passierte während eines »apt-get dist-upgrade«-Laufs, und besser werden die Dateisysteme durch unsauberes Herunterfahren ja auch nicht …