Überprüfung der Redundanz

Mathias Hein, Consultant, Buchautor, Redakteur
Mathias Hein, Consultant, Buchautor, Redakteur

Woher wissen Sie, dass Ihr Netzwerk gegen Fehler abgesichert ist? Wenn Ihre geplante Ausfallsicherheit nicht getestet wird, müssen wir weiterhin mit Überraschungen rechnen.

In einem meiner früheren Artikel schrieb ich: „Die Fähigkeit, die Elastizität eines Unternehmens zu messen, variiert in Abhängigkeit von den zu erwarteten Situationen. In heutigen IT-Umgebungen liegt der Fokus auf einem oder mehreren gestörten Systemen oder Netzwerk-Ereignissen. Meist tritt ein unerwartetes Ereignis jedoch nicht in erwarteter Form (und auch immer zum falschen Zeitpunkt ) auf. Daher tragen diese Ereignisse immer den Mantel großer Ungewissheit.“

Die Essenz dieses Leitsatzes lautet: „Gute Planung braucht gute Tests, um die Umsetzung bzw. die Annahmen, die in der Entwurf und der Konfiguration zugrunde lagen, zu validieren.

Führen Sie Fehlertests und Analysen in Ihren Netzwerken- und UC-Infrastrukturen durch? Oder hat Ihr Unternehmen Angst vor einem Netzwerktest, weil etwas nicht funktionieren könnte? Unternehmen, die keine regelmäßigen Tests durchführen, erhoffen immer nur das Beste, denn die Verantwortlichen wissen nie, ob die Backup-Systeme auch wirklich so arbeiten, wie es einmal geplant wurde.

Viele Unternehmen verfügen inzwischen über eine redundante Infrastruktur – zwei WAN-Provider, redundante Core-Router und Switches, unterbrechungsfreie Stromversorgungen, Backup-Datenpfade und redundante IT-Services-Systeme. Ich kenne jedoch viele Unternehmen, die ihre redundante Infrastruktur noch nie einem geplanten Redundanztest unterzogen haben. Warum warten diese Unternehmen auf einen Notfall, um zu erfahren, dass etwas in ihrem Redundanzkonzept nicht funktioniert? Es wäre jedoch sinnvoller, ein geplantes Wartungsintervall zu nutzen, in dem ein kontrollierter Redundanztest durchgeführt werden würde.

Es ist sicherlich eine gute Idee, die Redundanz-Prozesse zu bewerten. Funktioniert das Failover so, wie Sie es sich vorgestellt hatten? Arbeiten die Redundanz-Prozesse schnell genug für die eingesetzten Anwendungen? Schaltet der Redundanz-Prozesse auch wieder automatisch zurück, wenn das ausgefallene Gerät wieder online geht? Durch die installierte Ausfallsicherheit kann eine Backup-Site über einen längeren Zeitraum zur primären Site werden. Können die Infrastrukturen und das Personal die Umleitung der IT-Dienste bewältigen, die durch eine Katastrophe am ursprünglichen Primärstandort entstehen? Denken Sie dabei an die Unternehmen, die von Überschwemmungen, Brände oder Erdbeben betroffen waren. Viele unzureichend vorbereitete Unternehmen verschwinden still und leise vom Markt, wenn ihr IT-Betrieb nicht schnell genug wieder aktiviert wird.

Externe Faktoren

Man muss immer damit rechnen, dass etwas Unerwartetes eintritt. Meist liegen die Störgrößen außerhalb der IT-Infrastruktur, aber sind der Grund für die Verursachung eines Problems. Ein Beispiel für einen solchen externen Störfaktoren ist eine IT-Infrastruktur mit zwei unterschiedlich großen Notstromaggregaten. Bei einem Stromausfall wurden beide Generatoren ordnungsgemäß gestartet, aber nach kurzer Zeit streikte der kleinere Generator. Leider erfolgte die Stromversorgung der Kühlung über den kleineren Generator. Der Ausfall des kleineren Generators sorgte dafür, dass automatisch die Lüftungsschlitze geschlossen wurden, wodurch der Hauptgenerator überhitzte und heruntergefahren werden musste. Im Nachhinein stellte sich heraus, dass bisher niemand die Generator-Redundanz getestet hatte.

Dynamische Netzwerke

Die Serverumgebungen werden heute in den Unternehmen dynamisch (auf Basis von VMs, Containern und der entsprechenden Anwendungsmobilität) realisiert. Dynamische Netzwerke sind daher nur der nächste logische Schritt. Die Netzwerke ändern sich, wenn sich die Arbeitslasten erhöhen oder verringern und die Prozesse zwischen den Hardwareplattformen innerhalb des Rechenzentrums verschoben werden.

Die Dynamik der Netzwerke wird jedoch durch statische Prüfpläne behindert. Sicherlich wird man auch in dynamischen Unternehmen noch Teile des Netzwerks vorfinden, die weiterhin statisch sind. Hierzu gehören beispielsweise die Verbindungen zu den ISPs. Aber die Anwendungen werden zukünftig immer mobiler und verändern ihren Umfang in Abhängigkeit davon, welche Module der Nutzer abruft. Die Subnetze werden sich innerhalb der Netzinfrastruktur frei bewegen. Die Aufgabenstellung lautet: Wenn bei einem ganzen Server-Rack der Strom ausfällt, kann die IT-Infrastruktur die Prozesse auf ein anderes Server-Rack verschieben und das Netzwerk innerhalb eines akzeptablen Zeitrahmens rekonfigurieren? Ist die Anwendung in der Lage, sich von einem temporären Verlust der Daten zu erholen?

Dynamische Prüfungen

Zukünftig werden dynamische Tests der IT-Infrastrukturen benötigt, da sich die Anwendungen innerhalb der jeweiligen Umgebung frei bewegen können muss. Bevor Arbeitslasten dynamisch verschoben werden können, müssen einige einfache Tests ausgeführt werden. Dabei wird überprüft, ob die neue Anwendungsinstanz korrekt konfiguriert und ordnungsgemäß ausgeführt wird. Dies führt zu einem so genannten „Anwendungs-Ping.“ Dabei handelt sich um eine Paketsequenz, die wie eine echte Client-Anforderung verarbeitet wird und zu einer Bestätigung führt, dass die Anwendung korrekt funktioniert. Ein einfaches Beispiel ist das Senden einer Test-E-Mail an einen E-Mail-Server. Der Test prüft, ob die E-Mail innerhalb eines festgelegten Zeitraums von einem Testkonto empfangen wurde.

Wo wird mit dem Testen begonnen?

Die Entwicklung guter Testpläne stellt eine extreme Herausforderung dar und erfordert, dass Sie die IT-Systeme und die voneinander abhängigen Komponenten verstehen. Um gute Testpläne zu entwickeln, benötigten Sie eine von Ihrer IT-Historie unabhängige Person. Diese Person betrachtet die vorhandenen Systeme vollkommen unabhängig und kann die Entwicklungsprozesse entscheidend beeinflussen.

Ein weiterer Lösungsansatz besteht darin, mit kleinen Teilen der IT-Infrastruktur zu beginnen und diese Lösungen zu erweitern, wenn Sie genügend Testerfahrungen gewonnen haben. Die statischen Teile der Infrastruktur (beispielsweise die ISP-Verbindungen oder die Umschaltung auf einen Backup-UC-Controller) lassen sich leicht testen. Dabei sollten Sie jedoch nicht die kleinen Dienste vergessen, die dafür sorgen, dass die Infrastruktur reibungslos arbeitet. Hierzu gehören beispielsweise die internen DNS-Server. Ich bin immer überrascht, dass in vielen Unternehmen sowohl die primären und die sekundären DNS-, NTP- und DHCP-Servern im gleichen Subnetz zu finden sind und diese darüber hinaus noch an die gleiche Stromversorgung angebunden sind. Schalten Sie den Switch aus, mit dem diese Server verbunden sind und Sie erkennen sofort, wie gut die IT-Systeme weiterhin funktionieren.

Bei der Definition der Tests sollten Sie nach Dingen bzw. Ereignissen suchen, die mit einer hohen Wahrscheinlichkeit ausfallen können. Hierzu gehören beispielsweise Fehler in den Verbindungen zu den ISPs oder Stromausfälle. Auch sollte man bestimmte Kleinigkeiten, wie den Ausfall von Netzteilen oder Lüftern in wichtigen Geräten nicht übersehen. Ausfälle dieser Art können zu Überhitzungen bzw. zum Herunterfahren der jeweiligen Komponenten führen.

Natürlich sollten Sie auch die UC-Infrastruktur in Ihre Testpläne aufnehmen. Glücklicherweise gehört die Telefoninfrastruktur zu den einfacheren Komponenten, die im gesamten Unternehmen zu überprüfen sind. Schalten die Telefone bei einem Failover-Prozess (wenn der primäre UC-Server ausgeschaltet oder vom Netzwerk getrennt wird) auf den sekundären UC-Server um? Funktionieren anschließend die Telefonnummern und die vorgegebenen Wahlvarianten noch? Gibt es irgendwelche Funktionen, die vom primären UC-Controller abhängig sind und auf den sekundären Controller migriert werden müssen?

Fazit

Die regelmäßigen Tests bieten zudem in anderen Bereichen noch einige Vorteile. Während der regelmäßigen Redundanztests lassen sich problemlos zusätzliche Upgrades der Infrastruktur vornehmen. Ist das Netzwerk in zwei Redundanzhälften aufgeteilt, dann kann die eine Hälfte der redundanten Infrastruktur problemlos für Servicezwecke und Upgrades außer Betrieb genommen werden.