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.

ditaa-Grafik

VM-Verteilung 02.11.15.

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.

ditaa-Grafik

VM-Verteilung 04.02.16.

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.

Erklärbar-Grafik

Setup Freifunk Kreis GT seit Ende 2015.

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.

ditaa-Grafik

VM-Verteilung am 22.02.16.

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 …

7 thoughts on “Hardware vs. Cloud

  1. moin

    ich bin bzw. war auch immer top zufrieden mit dem Hetzner Service.

    und Hetzner ist/bleibt in D
    (bis auf das neue RZ in Skandinavien)

    leider wird DF immer schlechter bzw. hat sein RZ nach Frankreich verlegt, mit Zwangsumzug der Kunden.

    tja da werd ich meine Domains wohl nach über 15j mal kündigen und zu Hetzner transferieren.

    ja bis auf Festplatte und event. Ram hatte ich auch noch keinen Hardwaredefekt.

    Gruß Ingo

  2. Hetzner hat allerdings IPv6 nicht verstanden und weist nur ein einzelnes /64 zu und gibt auch bei Einwurf weiteren Geldes keine weiteren IPv6-Netze dazu.

    Wie bringt Ihr IPv6 zu Euren VMs?

    Wie sieht es mit dem Reverse DNS aus? IPv4 vermutlich übers Webinterface, aber wie trägt man bei Hetzner IPv6 reverse ein?

    Grüße
    Marc, der auch über eine Serverbörsenkiste mit endlich genug Speicher nachdenkt

    • Naja, ‘verstanden’ ist imho relativ. Ich finde einige Dinge bei v6 krank, dazu gehört die minimale Netzgröße von /64. Anyway, ich habe eth0 mit ::2 (Host) als /128 definiert und Route das als /64 in br-hetzner. Default für die VMs ist ::2, VMs haben dann z. B. ::n:1/64 mit n als lfd. Nummer. Sehe ich nicht als Problem, auto will man bei Servern eh’ nicht … Reverse geht auch bei v6 via Web.

  3. Auto will man auch bei Servern, besonders wenn die Maschine keinen OOb-Zugang hat, um die Basiserreichbarkeit herzustellen. Die staitschen IPs für die Dienste kann man sich ja dazukonfigurieren.

    Und dass Du /64 als _einzige_ Netzgröße nicht akzeptierst, liegt nur daran dass Du ein in IPv4-Wegen festgewachsener alter Sack bist ;-)

    Magst Du mal das ip -6 a und ip -6 r vom Host und von einer VM posten oder mailen, damit ich daraus schlau werde was Du da geschrieben hast?

    Reverse DNS per Web ist nicht schön, aber akzeptabel. Strato delegiert die die ip6.arpa Zone, _so_ muss das.

    • Charmant wie immer isser ;) Ich meine halt, daß für P2P-Links /127 ausreichend ist und /64 dafür unsägliche Verschwendung. Aber egal.

      Da ich die MAC meiner Kisten/VMs nicht kenne, nützt mir die auto-IP aus einem /64 auch nix; außerdem hast Du lokal doch eh’ fe80?

      Anyway:

      […]
      3: br0:  mtu 1500 
          inet6 2a01:aaaa:bbbb:cccc::1:0/64 scope global 
             valid_lft forever preferred_lft forever
          inet6 2a01:aaaa:bbbb:cccc::2/128 scope global 
             valid_lft forever preferred_lft forever
      […]
      root@host:~# ip -6 r  | grep -v ^fe8
      2a01:aaaa:bbbb:cccc::2 dev br0  proto kernel  metric 256 
      2a01:aaaa:bbbb:cccc::/64 dev br0  proto kernel  metric 256 
      default via fe80::1 dev br0  metric 1024 
      
      […]
      2: eth0:  mtu 1500 qlen 1000
          inet6 2a01:aaaa:bbbb:cccc::1:b4/64 scope global 
             valid_lft forever preferred_lft forever
      […]
      root@bgp4:~# ip -6 r  | grep -v ^fe8 | grep -v icvpn
      2001:bf7:1310:30b::/64 dev ospf-gw01  proto kernel  metric 256 
      2001:bf7:1310:30d::/64 dev ospf-gw03  proto kernel  metric 256 
      2001:bf7:1310:30f::/64 dev ospf-gw05  proto kernel  metric 256 
      2001:bf7:1310:317::/64 dev ospf-bgp3  proto kernel  metric 256 
      2001:bf7:1310:318::/64 dev ospf-bgp1  proto kernel  metric 256 
      2001:bf7:1310:31a::/64 dev ospf-bgp2  proto kernel  metric 256 
      2001:bf7:1310:322::/64 dev ospf-s3  proto kernel  metric 256 
      2a01:aaaa:bbbb:cccc::/64 dev eth0  proto kernel  metric 256 
      default via 2a01:aaaa:bbbb:cccc::1:0 dev eth0  metric 1024

      Standard (Linux-)Routing halt. Da bei v6 geschätzt nur 1% der Adressen überhaupt Einträge bekämen, kann ich mit Reverse-per-Web leben; im Gegenteil, ich spare mir den ganzen ip6.arpa-Sermon.

  4. Dankeschön! Natürlich ist das Verschwendung, aber bei IPv6 ist Verschwendung in Ordnung, wir haben nicht genug Atome um den Adressraum auszuschöpfen, und nicht genug Energie im Universum dafür.

  5. Und, lokal habe ich auch “richtige” iPv6-Adressen, die aus dem Autoconfig rausfallen, wenn das Gateway den Prefix announced. Wenn das Gateway das nicht tut (was ich nach _der_ Vorgeschichte befürchte), hast Du natürlich Recht.

    Mit mehr als einem /64 könnte ich aber autoconfig zu den VMs hin machen, und die verwendeten IP-Adressen bekomme ich aus dem Neighborcache oder einem “all host” multicast ping.

Comments are closed.