Am 07.02.16 fiel ein Server in Falkenstein wiederholt aus, am 08.02.16 startete einer unserer Server von sich aus neu …

Tja. Während wir (Ove, Ralf, ich) in Herne was über das Routing im Internet lernten, legte sich einer der Server bei Hetzner (»carrot«) gegen 13 Uhr still ins Gehackte. Da wir das mit dem »Monitoring« bislang nicht hinbekommen haben, bliebt das unerkannt, bis Matthias von den Müritzer Freifunkern am späten Nachmittag anrief :-(

Gegen 21:15 crashte der Server erneut, reboot und gut ist bislang die Devise — Hetzner stellte zwar unaufgefordert flink eine Remote-Console bereit, allerdings läuft der Server seit jenem zweiten Reboot nun wieder durch — und die Remote-Console wurde wohl zwischenzeitlich einem anderen Kunden überstellt.

Der Ausfall von »carrot« ist für die Kollegen an der Müritz zur Zeit fatal, da unser gw05.4830.org – eine VM auf »carrot« – derzeit deren einziges »Tor zur Welt« ist. Das ehemals mit Gütersloh geteilte gw06.4830.org verläßt sich für Routing usw. auf die Existenz von gw05. Das zu lösen, indem Freifunk Müritz parallel zu Freifunk KreisGT an die zentralen BGP-Exit-Server gehängt wird, steht auf der ToDo-Liste; bislang lief es halt ›leider‹ zu gut im Status Quo.

Aber auch der Freifunk im Kreis GT bekam am Montag morgen einen Schlag in den Nacken: der bisher einzige FFGT-Server »conquest« rebootete gegen 03:47 aus unbekanntem Grund. Leider waren die 8 VMs nicht für den automatischen Start konfiguriert, und da wir ja kein Monitoring haben, dauerte es bis ca. 12:20, bis die Nachricht von Ralf S. zu einem Blick und einem Start (inkl. Rekonfiguration auf automatischen Start) der VMs führte …

Tja. Shit happens. Sowas liesse sich vermeiden, führte man extensive Reboot-Tests durch (neue VM: Hypervisor-Reboot nach beendeter VM-Konfiguration), aber das ist bei einem Projekt wie Freifunk dann doch eher jenseits von Gut und Böse. Was wir aber tun können – und hier hat sich mit Thomas B. dankenswerterweise jemand mit entsprechendem Know-How im Nachgang der heutigen Probleme gemeldet –, ist, unsere Systeme besser (um nicht zu sagen: überhaupt) zu überwachen. Außerdem hat sich Matthias B. von den Müritzer Freifunkern bereiterklärt, bei der Administration zu helfen. Mit einem initialen Monitoring und ein paar Paar helfender Hände mehr werden wir zumindest schneller akute Probleme per (VM-) Reboot »erschlagen« können.

rrd-Graph
Einbruch.
Was aktuell für den Kreis Gütersloh unklar ist: haben wir noch ein Problem?

Der Knotengraph zeigt signifikant weniger Clients als vor einer Woche; allerdings ist Montag auch schulfrei gewesen. Eigene Tests ergaben positive Werte, 10+ MBit/sec im Downstream und sofortige IPv4-Adressvergabe lassen nicht zwingend auf ein Problem schließen. In den sozialen Netzen gab es drei Meldungen (auf twitter, per Mail und als Blog-Kommentar) – von einer Person –, wonach Freifunk seit Wochen unbenutzbar sei. Da wir das so pauschal nicht bestätigen können, ist diese Aussage leider wertlos. Auf Nachfrage hingegen bestätigte jemand vom Kreis Gütersloh – welcher selbst etliche Knoten betreibt – am Nachmittag, daß die vormittags festgestellten und uns gemeldeten DHCP-Probleme behoben seien … Was stimmt jetzt?

Serverprobleme

2 Gedanken zu „Serverprobleme

  • 9. Februar 2016 um 08:33
    Permalink

    Guten Morgen,

    also in Rietberg bekammen wir einfach keine IP Adressen… die Netzwerk-Info APP zeigte im Freifunk WLAN immer die IP 0.0.0.0 … so das zwar ein verbdinden mit dem Freifunk möglich war aber mangels IP kein Datentransfer möglich war!

    Das letzte mal als ich das versucht hatte war am 08.02. um 21 Uhr bei uns 8 Kumpels war dies so, außer bei einem der hatte eine IP und es ging alles… ich vermute er hatte noch ein gülitges „altes“ DHCP-Lease

  • Pingback: Hardware vs. Cloud | blogdoch reloaded

Kommentare sind geschlossen.