jtb.blog

Zwar sind die Putzarbeiten mittlerweile vorbei, aber die Konsequenzen halten uns weiter auf Trab.

Einer der wichtigen Server steigt nun mit einem Speicherfehler aus. Ob der Fehler mit dem Staubbefall zusammenhängt ist noch offen. Wieder einmal bin ich aber froh, über Redundanz zu verfügen. Alle virtuellen Maschinen wurden live migriert und liefen somit ohne Probleme weiter

Nachdem ich schon vor einigen Wochen über die Bauarbeiten berichtet habe, gibt es nun wieder neues zu dem Thema.

Am Donnerstag hat mich fast der Schlag getroffen als ich den Serverraum betreten habe.. Mein Kollege war schon sehr ruhig aber man konnte spüren, dass was nicht stimmt
Im Rahmen der Einbauarbeiten der Klimaanlage haben die Handwerker scheinbar nochmals den Mauerdurchbruch vergrößert. Natürlich ohne dabei eine Staubschutzwand aufzustellen oder irgendwie sonst auf die Server zu achten.
Da die Ziegel der Außenwand rot sind, kann man sehr schön erkennen, wo sich der Staub überall abgesetzt hat. Als die Bilder gemacht wurden, war der Boden des Raums schon gestaubsaugt.
Die folgenden Bilder sind nicht für Admins mit zarten Nerven







Viele weitere Bilder sind in der Gallery der Fachschaft zu den Bauarbeiten D10 ab Seite 36 zu finden.


Am Freitag war dann der Gutachter der Versicherung vor Ort und nächste Woche kommt das Reinigungsteam - wohlgemerkt eine Spezialreinigung für Server. Dann wird wohl jedes Gerät einmal dokumentiert (Kabelverbindungen etc), abgebaut, gereinigt und wieder eingebaut und angeschlossen. Danach darf wahrscheinlich ein Techniker der jeweiligen Firma (Dell, Cisco bzw Pandacom) die Geräte begutachten damit der Supportvertrag erhalten bleibt...

Redundanz klingt gut. Failover noch besser.
Aber egal was man macht oder testet - es gibt immer einen Fall den man nicht bedacht hat und der die schöne Verfügbarkeit kaputt macht.

Gestern nacht ist ein Server gestorben. Na ja, zur Hälfte - eine der beiden onboard Netzwerkkarten verweigerte ihren Dienst. Zuständig war dieser Server für DHCP (ca. 30 Subnets) und Radius. Während der DHCP-Dienst durch ein Failover-Setup weiterlief, verlief es mit dem Radius-Server nicht so gut. Auf der zweiten Netzwerkkarte lauschte immer noch der Freeradius-Daemon und wurde somit von den Switches im Gebäude erreicht. Allerdings kann Freeradius ohne Default-Gateway die LDAP-Server nicht erreichen. Ohne Benutzerdatenbank keine erfolgreiche Authentifikation - aber leider dennoch erreichbar. Somit kam es, dass kein Switch auf die anderen Fallback-Radiusserver umschwenkte. Ohne Radius kein 802.1x und somit stehende Rechner am Morgen


Dennoch gibt es ein paar Faktoren, die das Problem minimiert oder bei der Analyse geholfen haben:

• Örtliche Zuordnung - jedes Gebäude hat ihren eigenen Radius-Server mit der höchsten Priorität eingetragen. Somit war das Problem lokal begrenzt und legte nicht gleich mehrere Gebäude lahm.


• Überwachung - es war somit schnell klar, dass der Server nicht erreichbar ist und wann er ausgefallen war. Allerdings zeigte sich, dass nicht jeder die Mail erhalten hat und unser Nagios zur Zeit zuviele Warn-E-Mails schickt.


• Tools - ein Webinterface zum Abschalten der Authentifikation ist in solchen Fällen sehr hilfreich.


• Redundanz - immerhin hat es der DHCP-Dienst geschafft