Was für ein Wochenende. Nicht nur, daß es mich hinraffte, nein, auch die Technik schien sich eher malade gefühlt zu haben.

Screenshot
Freifunk-Knoten träumen auch manchmal sehr intensiv …
Nachdem wir eine Woche zuvor schon sonderbare Probleme hatten mit einem Knoten, der augenscheinlich größenwahnsinnig geworden war und sich Clients erträumte und uns dabei gehörig auch die Statistiken verhagelte, waren es letztes Wochenende die Betriebssysteme, die sich nacheinander den Revolver zum Suizid in die Hand zu drücken schienen.

Was vor einer Woche genau passierte ist, lies sich nicht vollständig aufklären. Ein Knoten allerdings behauptete, mehrere hundert Clients zu haben — und das auch noch zu Zeiten, wo der normale Gütersloher schon längst zu Hause ist, kurzum: falsche Daten. Nach einem Neustart am nächsten Morgen war der Spuk vorbei, die Fehlersuche am Abend allerdings hatte die Knotenkarte an irgendeiner Stelle soweit verwirrt, daß sie wieder alle Knoten als Offline in die RRD-Grafiken zu malen begann :( Aber das war erst der Anfang …

Freitag

Angefangen hat das Malheur am Freitag gegen 19 Uhr, als nach einem Update auf eine neuere fastd-Version auf gw01 unsere Statistiken, die ›traditionell‹ ebenfalls (noch) auf dem Server generiert werden, nicht mehr richtig wollten.

Letzten Endes war mein Latein als auch das der Kollegen auf ent­sprech­en­den Mail­ing­lis­ten gegen 23:45 am Ende und ich rebootete … den 10 Jahre alten Server zwar nicht, aber ich stoppte alles, was Frei­funk betraf und startete es manuell wieder neu. Dies schien Alfred (A.L.F.R.E.D, ein super Akronym im Zusammenhang mit B.A.T.M.A.N. für die Internet-Suche) dann endlich zu besänftigen, und unsere Graphen und Statistiken waren wieder mit Daten gefüllt.

Samstag

Am Samstag Nachmittag aber hakte der Statistikkram wieder/noch immer etwas, und irgendwann hat sich dann der Server verabschiedet. Leider auch nur so halb, IP war tot, auf ARP wurde noch geantwortet.
Das 10 Jahre alte Schätzchen hat kein LOM (Lights-Out Management) — wie der Name schon sagt, kann man die Kiste also im Dunkel nicht administrieren … ;)
Gemeint ist hier allerdings ein nicht beleuchtetes Rechenzentrum, in dem man ja aus der Entfernung über’s Netz dennoch arbeiten kann — andere mögen die Technik als KVM-Switch/-Board (Keyboard-Video-Mouse) kennen, gemeint ist jedenfalls, daß man, auch ohne vor der Kiste zu hocken, was tun kann. Und das ist bei jener Maschine eben leider nicht (mehr) gegeben (es tat vor Jahren mal, hat dann aber den Dienst eingestellt und ist mangels Konfigurationsdatenträger auch nicht mehr wiederbelebbar. Nicht einmal die Herstellerfirma, Fujitsu-Siemens, existiert in der Form noch ;)). SLA für die Hard­ware­be­treu­ung ist 8×5, also nur werktags während der üblichen Bürozeiten. Tja, doof das; mehr als ein Ticket zu öffnen ging nicht. (Naja, gegen Einwurf kleiner Münzen, also mehrerer 200-Euro-Scheine, hätte man sicherlich was bewegen können, Sondereinnahmen für außervertragliche Bereitschaftseinsätze am Wochenende nimmt jeder Dienstleister gerne mit denke ich ;))

Aber sowas war prinzipiell eingeplant, daher läuft eine gemietete VM als gw04.gue­ters­loh.frei­funk.net in Bayern. In einer aufwändiger-als-geplanten Aktion wurden die Webserver aus einem zwei Wochen alten Backup auf eine neue VM kopiert, angepaßt und schlußendlich die Alfred-Geschichte auf gw04 lauffähig gemacht. Als es dann tat, graute dem Morgen, und mir war nach Bett. Das schöne war, daß das Netz dennoch in der ganzen Zeit funktioniert hatte (ich nutze es auch zuhause als primäres WLAN), nur jene, die mit gw01 verbunden waren, sollten den Ausfall gespürt haben (Reconnect und neue IP).

Sonntag

Screenshot
Crash am Sonntag um 10:23 aus Sicht der SSH-Session …
Wenige Stunden später allerdings hing sich gw04 mit einem Kernel-Panic auf, das Gütersloher Freifunk-Netz war abgeklemmt von der Außenwelt. Intern hielt gw03 zwar noch die Verbindungsfahne hoch, aber IPv4 und IPv6 nach außen waren nun weg :-( Und Murphy notierte »Treffer! Versenkt!« …

Screenshot
Erster Crash (So., 10:23) aus Sicht der Console.
Gegen 12:30 bemerkte ich, daß etwas nicht stimmte, sah die Meldung in der vom Vorabend noch offenen Shell und verband mich schließlich mit dem Fernwartungssystems des VM-Anbieters. Dort wurde dann schnell klar, daß es ein Kernel-Panic war, der die VM tötete, somit nichts mehr zu retten war — und ein hartes Aus- und Wiedereinschalten der schnellste Lösungsweg sein dürfte.

Gesagt, geklickt, und nach wenigen Minuten war die VM wieder up and running — ein großer Vorteil der Virtualisierung, denn heutige Serversysteme brauchen 5 bis 15 Minuten, bis sie alle Komponenten gründlich geprüft und initialisiert haben — nein, ich gebe es offen zu, was da so lange dauert weiß ich nicht, ich habe nicht den Hauch einer Ahnung. Speicher wird jedenfalls, bei 16 bis in die Hunterte von GBytes, schon länger nicht mehr einzeln durchgezählt ;)

Screenshot
Zweiter Crash, ca. 10 Minuten nach Reboot gegen 12:30.
Leider, lange währte der Friede nicht, noch vor dem Mittagessen hing die VM schon wieder, mit einer anderen Meldung zwar, aber eben auch nicht nach Stunden — sondern nicht mal einer halben. Das ist weder lustig noch nett, wenn einem die andere Hälfte der Infrastruktur schon abhanden gekommen ist … Und Murphy notierte wieder: »Treffer! Ver­senkt!« …

Gut, erneuter, virtueller, Power-Cycle der VM. Wieder war sie nach wenigen Sekunden wieder da, nochmal Konfiguration usw. überprüft, etwas gewartet, einen Speedtest durchgeführt, alles schien zu laufen. Ab dafür und insbesondere ab zum Essen fassen.

Screenshot
Dritter Crash, <20 Minuten nach Reboot.
Nun wäre Murphy nicht Murphy, wenn es nun auf einmal wieder stabil laufen sollte — und so fiel gw04 nochmals auf die Nase.

Höchste Zeit also, Änderungen zu rekapitulieren und Optionen zu eruieren.

Fakt ist: gw04 lief im Tandem mit gw01 (und gw03) lange Zeit stabil. Fakt ist ferner, daß gw04 erst dann zu zicken anfing, nachdem ich alfred und batadv-vis, zwei Tools für die Statistikseiten, aktivierte. Naheliegender Lösungsansatz: den Statistikkram ersteinmal Statistikkram sein zu lassen und dadurch hoffentlich das Netz wieder zu stabilisieren. Gesagt, getan, und schon hörten die Crashes von gw04 so plötzlich auf, wie sie anfingen.

In dem Status verblieb Freifunk Gütersloh dann auch bis Montag, denn ich war noch immer angeschlagen, und die Familie möchte mich am Wochenende auch mal sehen …

Montag

Gegen 10 Uhr wurde die Hardware, auf der auch gw01 läuft, rebootet, danach waren die meisten Webservices wieder verfügbar und eben auch das zweite Gateway. register.guetersloh.freifunk.net, sowieso auf der Abschußliste stehend, allerdings mochte nicht starten.

Zeitweise mochte auch der dnsmasq nicht so richtig, und nachdem die Hardware ja bei Kernel-Panic oder ähnlichem nicht wirklich wartbar ist, wurde kurzerhand ein sogenanter P2V-Prozeß gestartet, d. h. der komplette Server wurde in eine VM verwandelt. Dies erwies sich als weise, denn im letzten Schritt des Skriptes, bei dem bei weitgehend gestoppten Prozessen auf der Hardware letzte Dateiänderungen auf das virtuelle Abbild gespiegelt werden, hing sich der physikalische Server auf.

Kurzerhand wurde das virtuelle Abbild in Betrieb genommen, der physikalische Server wartet nun auf seinen Abbau.

Nächste Schritte

Vorweg: Freifunk Gütersloh läuft nun auf modernerer Hardware (ca. 4 Jahre alt), und diese hat zumindest zum Teil auch ein sog. LOM-Interface, über das man die Hardware per Webbrowser oder sogar SSH rekonfigurieren oder neu starten kann und auch auf die Console gucken — yeah! Wir setzen auf virtuelle Maschinen (VMs), die per KVM realisiert werden. Derzeit sind es Ralf und ich, die diese VMs von je einem unserer Server im RZ ›spendieren‹, und wir splitten die Dienste wo möglich zwischen den Serven, gw02-new läuft auf meiner Hardware, gw01-new auf Ralfs, entsprechend auch bgp1/2 … Wir haben erstmal rd. 32 offizielle IPv4-Adressen für FFGT-Services zur Verfügung sowie lokalen IPv4-Exit. Aber es ist noch einiges an Arbeit zu tun:

Grafik
Geplantes OSPF/BGP-Setup.

  • Umzug der Webseiten auf die schon kurzzeitig eingesetzte, dedizierte VM.
  • Inbetriebnahme von bgp1/2 und den neuen gw01/02 (als gw01-new und gw02), Deaktivierung BGP auf gw01 und gw04 (IC-VPN) und statt dessen temporäte Einbindung ins OSPF, Umzug aller Knoten auf gw01-new und gw02 und danach Deaktivierung von gw01 und gw04 für Gateway-/Routingzwecke.
  • Umzug mail.guetersloh.freifunk.net von gw04 auf Service-VM in GT.
  • Deaktivierung fastd auf gw03, Umbenennung in noc für entsprechende Dienste (laufen dort auch schon, Ralf hat unter noc.guetersloh.freifunk.net schon nette Reporting- und Testtools inkl. einer IP-Verwaltung aufgesetzt).
  • Schnitzen einer, DC-externen?, Nagios-VM (oder was grade en vogue ist an der Stelle), um zentrales Monitoring und Alerting zu realisieren.
  • Weitere Umsetzung des Netzwerk-Konzeptes (verschiedene Netze für verschiedene Städte).
  • Erweiterung der Firmware für variable SSIDs/automatischer Bau verschiedener Firmware aus einem Source (wie jetzt schon für GT und RHWD).
  • Tests mit und ggf. Umstellung auf fastd v16 mit UMAC (v15 war DOA).

Erklärbär-Grafik
Zieltopologie des Gü­ters­loher Frei­funks
Mit einigen dieser Schritte kommen wir einem sauberen Setup wieder näher, denn derzeit machen gw01 und gw04 zu viele Dinge, um alles einigermaßen fehlerfrei nebenbei zu administrieren. Das hat zwar nur bedingt was mit den Problemen vom Wochenende zu tun, verkomplizierte die Situation allerdings. Und, wie man bei gw04 sah, kann schon eine kleine zusätzliche Softwarekomponente durchschlagenden Mißerfolg bewirken …
Andere Schritte sind notwendig, um unser Netz entsprechend skalieren und z. B. durch Sponsoren avisierte Ausbauten abfedern zu können.

Aufruf

Aber, auch das hat das Wochenende als auch die nun sich schon etliche Wochen hinschleppende Aufbauphase von bgp1/2 und gw01-new/02 gezeigt: wir brauchen eine breitere Basis an System- und Network Engineers, die sich die Aufgaben teilen. Wir alle haben einen »Tagesjob« und zumeist auch noch ein Privatleben, auf Dauer wird das Projekt potentiell leiden, wenn wir nicht auch die Personalbasis verstärken.

Aus diesem Grunde möchte ich am Ende dieses Beitrags nochmals uns selbst zitieren:

Oder möchtest Du am Projekt aktiv mitarbeiten?

  • sei es als Programmierer/-in an der Firmware (basiert auf OpenWRT),
  • sei es bei der Betreuung der Technik (Linux-Systeme),
  • oder als Grafiker/-in oder Texter/-in bei unserer Öffentlichkeitsarbeit?

In dem Fall melde Dich bitte einfach per Mail bei uns, und wir werden sicherlich schnell handelseinig ;) Oder komme einfach zu einem unserer nächsten Treffen, um uns kennenzulernen.

Unser nächstes Treffen findet übrigens diesen Freitag statt:

Freifunk Gütersloh Treffen

Freitag, 21. November, 19:00 Uhr

Die Weberei
Bogenstraße 1-8
33330 Gütersloh

<blink> Na, sehen wir uns? ;) </blink>

Wenn ich diesen Murphy erwische …