jtb.blog

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

"Wie installiere ich alle meine Rechner neu?" Diese oder ähnliche Fragen stellt sich jeder Administrator mal. Während bei kleinen Rechnerparks noch der Turnschuhadmin von Rechner zu Rechner rennt, ist ab einer gewissen Anzahl eine automatische Installation angebracht.
Je nach Betriebssystem gibt es diverse Namen für eigentlich immer ähnliche Techniken. Sei es nun FAI (Fully Automated Installation) oder WDS (Windows Deployment Services). Natürlich gibt es auch reine Image-Software wie z.B. Norton Ghost.
Alle Installationsarten haben eine Gemeinsamkeit: der Rechner kann vom Netzwerk booten und bekommt danach über das Netzwerk die Installationsdateien. Dieser Netzwerkboot per PXE hat den angenehmen Vorteil: man muss nicht von Rechner zu Rechner wandern sondern quasi auf Knopfdruck ein Image ausrollen. Sollte beispielsweise der Rechner gerade aus sein, kann man per Wake On Lan diesen booten.


Ob nun ein echtes Image oder die Installationsdateien verwendet werden - beides hat einen entscheidenen Nachteil: das Netzwerk wird belastet. Aus schlechten Erfahrungen in der Vergangenheit werden heutzutage nicht mehr alle Rechner in ein Netzwerk gesetzt sondern per Firewall sauber getrennt. Was Würmer an der Verbreitung hindert, hat aber Nachteile: oft ist die Firewall-Appliance nicht stark genug ausgelegt um eine gleichzeitige Installation dutzender von Rechnern zu verkraften.

Im folgenden möchte ich eine kleine Lösung für dieses Problem vorstellen. Die grundsätzliche Idee ist einfach: das Aufrüsten der Firewall ist zu kostspielig. Ein einfacher Linuxserver mit zwei Netzwerkkarten ist schnell genug, aber wir wollen und können damit nicht die Appliance mit den ganzen Funktionen ersetzen.
Also stellen wir neben die Firewall eine zweite die nur während des Deployment-Prozesses tätig ist.

Die eigentliche Aufgabe besteht nun darin eine Fallunterscheidung zu treffen. Während beim normalen Boot alles wie gewohnt ablaufen soll, muss beim Booten über's Netzwerk alles über den neuen Linux-Server laufen. Das ganze klappt wunderbar wenn ein paar Rahmenbedingungen erfüllt sind - am wichtigsten ist hierbei die Verwendung eines passenden DHCP-Servers.

Zuerst einmal brauchen wir ein neues IP-Segment für die Image-Verteilung. Da öffentliche Adressen Mangelware sind, begnügen wir hier uns mit einem privatem Segment. Da wie schon gesagt, mehrere Netzbereiche versorgt werden sollen, nehmen wir hier ein 10er Bereich und unterteilen ein /16 in 255 Segmente.



Durch die Allow-Zeile wird dieser DHCP-Pool nur verwendet wenn tatsächlich über das Netzwerk gebooted wird. Das Erkennen eines Netzwerkboots erfolgt über die Angabe des Herstellers im DHCP-Request. Neben dem "pxe-kernel" welches über den nicht dokumentierten Kernelparameter dhcpclass gesetzt wurde, forderte der Kernel trotzdem auch noch als "Linux ipconfig" eine IP an.


Der ping-check erwies sich als nötig, da der Linux-Kernel eine IP-Adresse anfragt und gleichzeitig die alte noch in Benutzung ist. Der DHCP-Server pingt also die alte Adresse an und stellt fest, dass er sie nicht vergeben kann, da sie scheinbar noch in Verwendung ist. Was also normalerweise das Netzwerk vor der doppelten Vergabe einer IP schützt, ist hier kontraproduktiv.

Nun fehlt nur noch ein DHCP-Relayagent auf dem Linux-Server und die Rechner bekommen eine DHCP-Adresse. Bleibt aber ein Problem: je nachdem welcher Agent schneller antwortet bekommt der Rechner eine Adresse aus dem regulärem Pool oder aus dem neuen Deployment Pool.
Hier hilft ein explizites Verbieten - leider können wir die Gruppendefinition nicht verwenden, wenn die Rechner per statischen Host-Eintrag mit einer festen IP-Adresse versorgt werden. Hier hilft folgende Zeile im alten Segment für das Netzwerk:


Wieder haben wir die oben schon verwendete Fallunterscheidung. Diesmal wird jedoch die grundsätzliche DHCP-Funktion ein- oder ausgeschaltet. Die Benennung des Parameters booting ist ein wenig unglücklich - hier ist nicht das Booten des Rechners gemeint sondern das Zuweisen einer Adresse per DHCP.


Jetzt fehlen nur noch ein paar Kleinigkeiten. Unter anderem müssen die DHCP-Server eine Rückroute zum 10.10.0.0/16 Segment haben. Auch die beim Deployment beteiligten Rechner brauchen eine solche Route. Damit nicht jeder Server angefasst werden muss, werden alle anderen Netzwerkzugriffe per NAT auf eine bekannte Adresse gemappt. Damit die neue Firewall kein Sicherheitsloch aufreisst, sorgen noch ein paar iptables-Regeln dafür, dass nur die benötigten Dienste erreichbar sind.

Das Ergebnis kann sich sehen lassen: die Installation mehrerer Rechner geschieht jetzt völlig unabhängig von der Firewall. Jetzt bremsen nur noch die Netzwerkanbindung vom Linux-Server sowie natürlich die Anbindung vom Deployment-Server und dessen Festplatten. Aber gerade die Netzwerkanbindung kann man leicht skalieren. Eine Server-Netzwerkkarte gibt es im unteren dreistelligen Bereich. Die Edge-Switche kann man durch einfache Portaggregation schneller an die Core-Switche anbinden. Erst wenn die Backbone aufgerüstet werden muss, wird es wiederrum teuer. Aber 10 Gigabit-Ethernet ist ja im kommen.

Seit fast 16 Monaten arbeite ich nun für die Hochschule Darmstadt am Fachbereich Informatik. Somit ist das Ende absehbar - die Stelle ist auf 2 Jahre befristet.

Die Frage, die sich nun stellt, ist einfach: was will ich danach machen. Hier geht es mehr darum was ich wirklich machen will und nicht was ich machen kann.

Immerhin gibt es ein paar Möglichkeiten. Zuerst einmal besteht die Option, dass die Stelle verlängert wird. Das ist aber abhängig von diversen Faktoren - insbesondere aber vom Sparzwang im Land Hessen. Das ist aber wiederrum kein Faktor ob ich das machen will. Ich weiß auf jeden Fall schon mal, dass ich auf Dauer nicht hier im öffentlichen Dienst glücklich werde. Momentan bin ich jedenfalls ein wenig gefrustet. Schon damals hat mir eine gute Freundin abgeraten in den öffentlichen Dienst zu gehen - mittlerweile weiß ich auch warum

Bei der Wahl einer anderen Anstellung besteht das Problem, dass ich weiterhin studieren werde. Zwar ist auch hier das Ende in Sicht, aber ich liege noch sehr gut in der Zeit. Durch das Teilzeitstudium bin ich im vierten Semester gerade erst bei Halbzeit. Je nachdem wie ich das Master Projektsystementwicklung absolvieren kann, wäre ich auch schon schneller fertig. Falls eine solche Anerkennung meiner Arbeit und den restlichen Scheinen funktioniert, kann ich mit Beendigung des Arbeitsverhältnisses auch gleich mit der Master-Arbeit anfangen. Hier liegt der nächste Knackpunkt: die Master-Arbeit ist in Vollzeit zu erstellen - also kein Teilzeitjob nebenbei wenn man sich auf die Arbeit konzentrieren will. Aus diesem Grund baue ich mir gerade ein kleines Finanzpolster auf.

Ich bin kein Fan von Twitter aber bei einigen Freunden habe ich per RSS-Feed mitgelesen. Allerdings finde ich zunehmend nur einen kleinen Teil der Posts wirklich interessant. Aus diesem Grund höre ich nun endgültig mit dem Lesen von Twitter-Nachrichten auf. Vielleicht kann ich ja die gewonnene Zeit dazu nutzen ein paar mehr Blogeinträge zu verfassen