… sie kann auch tückisch sein. Und nicht selten ist Redundanz gar die Ursache von Systemausfällen. Oft ist die Redundanz auch nur scheinbar vorhanden, bei genauerer Analyse gibt es aber doch einen Single Point of Failure. In jedem Fall sollten als redundant ausgewiesene Systeme darauf getestet werden, ob sie wirklich das halten, was sie versprechen.

So ziemlich jedes technische System kann redundant ausgelegt werden. Festplatten werden zu RAID-Verbünden zusammengefasst, so dass beim Ausfall einer Platte die Daten nicht verloren sind und die Computer weiter laufen. In Servern schlummern mindestens zwei Netzteile, um den unterbrechungsfreien Betrieb zu gewährleisten. Diese hängen nach Möglichkeit an unterschiedlichen Stromnetzen, um selbst für einen möglichen Stromausfall gewappnet zu sein. Den schlimmsten aller Fälle – es gibt wirklich keinen Strom mehr – puffern USVs. An ihr hängende Server werden beim Stromausfall kontrolliert heruntergefahren.

Größere Firmen verfügen selbstverständlich über mehr als einen Internetanschluss, um bei Providerproblemen nicht von der Außenwelt abgeschnitten zu sein. In so genannten Clustern werden Systeme (z. B. Mail-Server oder Datenbank-Server) zu einem übergeordneten System zusammengefasst, das bei Ausfall des Hauptknotens durch ein automatisches Umschalten auf den Failoverknoten unterbrechungsfrei weiter läuft. SQL-Datenbanken lassen sich durch Spiegelung redundant auslegen – der Spiegelserver bekommt jede Änderung der Datenbank in Echtzeit mit und kann im Fehlerfalle einspringen, automatisch oder manuell. Im Citrix-Umfeld werden einfach viele gleichartige Server parallel betrieben, die sich die Last teilen.

Nicht nur bei Servern, auch im Netzwerk an sich ist die Redundanz ein großes Thema. Gebäude werden nicht nur über eine Leitung miteinander verbunden. Der Backup-Pfad ist ganz selbstverständlich. Und schließlich gibt es ganze Backup-Rechenzentren. Falls das Hauptrechenzentrum komplett ausfallen sollte, muss das Backup-Rechenzentrum die Aufgaben des Hauptrechenzentrums komplett übernehmen können.

Generell lassen sich zwei Arten von Redundanz feststellen:

1. Load Balancing: Hier teilen sich mehrere Systeme die Arbeit. Beim Ausfall eines Systems übernehmen die verbliebenen Systeme die Arbeit. Vorteil: Alle Systeme sind ständig in Benutzung, das Funktionieren der Redundanz ist somit automatisch gewährleistet. Nachteil: Bei einem Systemausfall steigt die Last für die verbliebenen Systeme, was sich auch für den User in schlechterer Performance bemerkbar macht. Beispiel: Citrix XenApp – Load Balancing, RAID1 (Spiegelung) bei Festplatten.

2. Failover: Hier gibt es ein Haupsystem, das in der Regel seine Arbeit verrichtet. Bei dessen Ausfall wird das Backup-System aktiv. Das Umschalten (Failover) wird von einem übergeordneten System durchgeführt. Vorteil: Wenn der Failover-Prozess reibungslos funktioniert, merkt der User in der Regel nichts davon, dass das Hauptsystem ausgefallen ist und verfügt weiterhin über volle Rechenleistung. Automatisierte Failover-Mechanismen können zudem schneller reagieren als jeder Admin. Nachteil: Durch die notwendigen Failover-Mechanismen steigt die Komplexität des Gesamtsystems. Da das Backup-System in der Regel nicht unter Last steht, ist auch die Wahrscheinlichkeit eines unerkannten Defekts des Backup-Systems höher.

Redundanz birgt Gefahren. Bei Failover-Systemen sind diese höher als bei Load-Balancing-Systemen. Ein Load-Balancing-System ist robust gegen Ausfälle einer Komponente (z. B. einer Festplatte im RAID). Nur durch konsequentes Monitoring der “Gesundheit” des redundanten Systems kann die Fehlertoleranz aufrecht erhalten werden (z. B. durch den Austausch einer defekten Festplatte). Failover-Systeme können es besonders in sich haben. Oftmals funktioniert der Failover-Mechanismus ganz hervorragend, es ist aber aus Sicherheitsgründen ein manuelles Failback notwendig. Wenn nun niemand überhaupt mitbekommen hat, dass ein automatisches Failover stattgefunden hat, ist das Gesamtsystem ab diesem Zeitpunkt nicht mehr redundant! Einen Fehler am Backup-System merkt der User nun sofort. Ebenfalls nicht redundant ist ein System dann, wenn aur irgend einem Grund der Failover-Mechanismus nicht funktioniert.

Die Redundanz ist ein wichtiges Verkaufsargument im IT-Bereich. Die Aussage: ”Das Backup-System übernimmt im Fehlerfalle automatisch die Funktion des Hauptsystems” ist allerdings eine sehr starke Vereinfachung. Mit der Redundanz kauft man sich die Pflicht, das Gesamtsystem im Auge zu behalten, sich bei Fehlern oder automatischen Failover-Aktionen alarmieren zu lassen und regelmäßig die Funktion der Redundanz praktisch zu testen.

Nicht zuletzt sollte auch gewissenhaft geprüft werden, ob nicht doch noch ein Single Point of Failure im Gesamtsystem vorhanden ist.  Mit der Redundanz steigt immer die Komplexität des Gesamtsystems. Diese gilt es zu beherrschen. Ein Troubleshooting einer defekten Komponente, während der IT-Betrieb weiterläuft, ist für den Admin aber auf jeden Fall die beste und stressärmste Situation. Er sollte deshalb stets dafür sorgen, dass Redundanz vorhanden ist und funktioniert.

Oft treten bei IT-Systemen Fehler nicht nur einmal, sondern immer wieder auf, und nach dem ersten Troubleshooting und der Fehlerdokumentation ist die Fehlerbehebung nur noch Routine. Bei einer großen Anzahl von verwalteten Systemen ist es zudem für den Systemadministrator schwierig, in kurzer Zeit zu beurteilen, ob sich sein Netzwerk in einem guten Zustand befindet. Netzwerkmonitoring-Tools wie Nagios oder der Hostmonitor helfen in beiden Fällen.

Das Prinzip der Monitoring-Tools ist einfach. Es handelt sich im Prinzip um ständig aktive Netzwerkagenten, die alle im Netzwerk befindlichen Systeme auf die unterschiedlichsten Arten ansprechen können. Der Hostmonitor beherrscht 62 Testmethoden wie Ping, Website-Erreichbarkeits-Check, DNS-Abfrage oder Prüfung des verfügbaren Speicherplatzes auf einer Netzwerkfreigabe. Bei erkannten Fehlern ist die Benachrichtigung des Admins per E-Mail oder SMS möglich.

Mit einem guten Testkonzept bekommt der Systemadministrator Fehler im Netzwerk schneller mit als jeder Benutzer und kann im Idealfall das Problem lösen, bevor der erste Anruf den Helpdesk erreicht.

Prinzipiell sollte jedes produktive System automatisiert getestet werden. Das mindeste bei einem Server ist ein regelmäßiger Ping-Test, der feststellt, ob der Server im Netzwerk erreichbar ist. Dieser Test kann alle 10 Minuten ausgeführt werden. Zudem ist es ein guter Gedanke, die wichtigsten Dienste kritischer Server testen zu lassen. Manche Dienste haben auch die Eigenheit, alle paar Tage ohne Vorwarnung auszufallen. Das Netzwerkmonitoring-Tool kann das nicht nur erkennen, sondern den Dienst auf Wunsch sogar automatisch neustarten.

Um zu gewährleisten, dass die Netzwerküberwachung zuverlässig funktioniert, sollte das Monitoring-Tool auf einer eigenständigen Hardware betrieben werden. Durch ein direkt am Monitoring-System angeschlossenes Handy, das SMS-Benachrichtigungen versendet, hat man die größtmögliche Unabhängigkeit von den Produktivsystemen (zum Beispiel einem SMTP-Relay-Server für E-Mail-Benachrichtigungen).

Mit einem Netzwerkmonitoring-Tool kann sich der Systemadministrator die Arbeit wesentlich erleichtern. Ein Blick auf einen grünen Überwachungsbildschirm wirkt immer beruhigend. Kenngrößen des Netzwerkes (wie freier Festplattenplatz) können zudem als Report ausgegeben werden.

Der Systemadministrator sollte sich nach jedem außerplanmäßigen Troubleshooting fragen, ob es für diese Situation nicht einen Test im Monitoring-Tool gibt. Oft genug ist das der Fall, und die Verfügbarkeit aller Systeme ist damit wieder ein Stückchen gestiegen.