Redundanz in der Praxis

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