In sechs Schritten zum Netzwerk-Disaster-Recovery-Plan
Warten Sie nicht, bis der Notfall eingetreten ist, um sich mit Recovery-Optionen zu beschäftigen. Mit unseren Tipps erstellen Sie einen Netzwerk-Disaster-Recovery-Plan nach Maß.
Ein Datennetzwerk bildet die Grundlage jeder Unternehmensinfrastruktur. Daher ist es wichtig, einen DR-Plan (Disaster-Recovery) zu erstellen, der missionskritische Services innerhalb einer bestimmten Frist wieder online bringt.
Disaster-Recovery-Pläne gibt es seit vielen Jahrzehnten. Sie müssen aber sorgfältig entworfen werden, um sich an neue Architekturen und geschäftliche Anwendungsfälle anzupassen. Zu den modernen Entwicklungen gehören Cloud Computing, Remote-Arbeitskräfte und Software-defined Networking (SDN).
In diesem Artikel gehen wir näher auf sechs praktische Schritte ein, die Sie dabei unterstützen, einen erfolgreichen Disaster-Recovery-Plan für Ihr Netzwerk zu erstellen. Die Schritte lassen sich als Rahmen verwenden, um den Netzwerk-Disaster-Recovery-Plan zu erhalten, der zu Ihren spezifischen Recovery-Zielen optimal passt.
1. Missionskritische und nicht missionskritische Netzwerksegmente bestimmen
Automatisierte Redundanz und Resilienz in ein Netzwerk einzubauen, ist ein teurer, zeitaufwendiger und komplexer Prozess. Darum besteht der erste Schritt darin, Segmente des Netzwerks festzulegen, die als missionskritisch gelten. Für genau diese Teile Ihres Netzwerks können Sie die zusätzlichen Kosten und Komplexitäten rechtfertigen, die ein automatisiertes Failover nach sich zieht. Echte automatisierte Resilienz ist häufig in Bereichen wie Data Centern sowie bei WAN-Konnektivität und Netzwerkzugriff auf Cloud-Ressourcen anzutreffen.
Bereiche, in denen vollständige Resilienz im Allgemeinen nicht implementiert ist, sind unter anderem das WLAN und der Access Layer, wo sich die meisten Endnutzer verbinden. Für diese weniger kritischen Netzwerksegmente reicht in der Regel ein fertiger Recovery-Plan aus, um das Netzwerk mithilfe von Austauschhardware und Service Level Agreements (SLA), die bestimmte Reaktionszeiten vorsehen, manuell wieder online zu bringen.
2. Resilienz für missionskritische Netzwerksegmente
Nachdem Sie festgelegt haben, welche Netzwerksegmente als missionskritisch genug gelten, um die Kosten für vollständige Resilienz zu rechtfertigen, besteht der nächste Schritt darin, sie zu gestalten und aufzubauen. Das Netzwerksegment, an dem Sie arbeiten, bestimmt, welche Resilienzverfahren sich am besten eignen.
In den meisten Data Centern kommen dynamische Routing-Protokolle und Technologien für virtuelle Overlay-Netzwerke zum Einsatz, um einen Echtzeit-Failover über Hardware und Links zu ermöglichen. Alternativ wird WAN-Resilienz typischerweise durch SD-WAN-Technologien realisiert.
Schließlich lässt sich auch noch Cloud-Resilienz auf viele verschiedene Arten implementieren. Einige davon basieren auf Rapid-Failover-Technologien, für deren Gestaltung und Verwaltung Ihr Public-Cloud-Service-Provider verantwortlich ist. Ganz gleich, welche Variante zum Tragen kommt, es ist wichtig, alle Optionen zu prüfen, bevor Sie diejenige wählen, die zu Ihren Anforderungen passt.
3. Konfigurations-Backups
Während bei Netzwerken die hardwarezentrierte Infrastruktur immer mehr einer softwarezentrierten Infrastruktur weicht, wird das richtige Management der Netzwerkkonfiguration zunehmend wichtiger. Für Legacy-Netzwerke gehört zum Führen eines Konfigurationskatalogs häufig die Nutzung einer automatisierten Backup-Anwendung, die sich remote bei jeder Netzwerkkomponente anmeldet und die Konfigurationen per Copy and Paste in eine Textdatei schreibt. Diese Konfigurationsdateien lassen sich dann organisieren, speichern und, falls eine virtualisierte oder Hardwarekomponente sie verliert, wieder abrufen.
Neuere Netzwerkarchitekturen können auch das gesamte Netzwerk von einer zentralen Stelle aus konfigurieren. Diese zentrale Stelle kann sich entweder On-Premises oder in einer Public Cloud befinden. Wie auch immer, Backups von einem zentralen Ort aus zu erstellen und zu speichern wird deutlich einfacher, ist aber nicht minder wichtig.
4. Cold Spares, schneller Hardwareaustausch – oder beides
Was Austauschhardware für Notfälle angeht, so gibt es zwei Möglichkeiten. Erstens können Sie identische Hardwarekomponenten kaufen und sie für den Ernstfall ins Regal legen. Diese Komponenten werden auch als Cold Spares bezeichnet und eignen sich ideal, wenn es Ihnen auf eine niedrige Downtime des Netzwerks ankommt. Gleichzeitig ist dies die teuerste Option, weil Sie Equipment doppelt kaufen müssen.
Alternativ dazu können Sie mit dem Hersteller ein entsprechendes SLA für den Austausch der Hardware nach Ihren Anforderungen vereinbaren. In einigen Fällen gilt für die Hardware eine eingeschränkte Lebenszeitgarantie. Allerdings kann es bei dieser Option bis zu mehreren Wochen dauern, ehe die Austauschhardware eintrifft. Anders sieht es da schon bei kostenpflichtigen Austauschplänen aus. Sie enthalten üblicherweise Austauschfristen, die vom nächsten Geschäftstag bis zu zwei und vier Stunden rund um die Uhr reichen.
Wenn Sie Disaster-Recovery-Pläne erstellen, die flexibel sind, werden Sie dadurch langfristig sehr viel Zeit sparen.
Die meisten Organisationen entscheiden sich für den Kauf von Cold-Spare-Hardware für bestimmte Teile des Netzwerks, während sie für andere auf spezielle Verträge zum Austausch der Hardware setzen. Auch hier gilt: Welche Option sich für Ihr Netzwerk eignet, richtet sich danach, wie kritisch die Komponente ist und wie groß der Verlust der Geschäftsfunktionalität bei einem Ausfall.
5. Recovery-Erwartungen, Zuständigkeiten und Kommunikationskanäle festlegen
Nachdem die Pläne und der Prozess für einen Netzwerknotfall ausgearbeitet sind, gilt es im folgenden Schritt, die Recovery-Erwartungen, Zuständigkeiten und Kommunikationskanäle zu dokumentieren. Die Erwartungen drehen sich in der Regel um die Service-Recovery-Zeiten für jeden Teil des Netzwerks. Die Zuständigkeiten legen die Rolle jeder Person, jeder Abteilung oder von Dritten fest sowie detaillierte Aufgaben, für deren Durchführung sie verantwortlich sind.
Zu guter Letzt sollten in einem Dokument die Kommunikationskanäle festgehalten werden, damit die Kommunikation unter den Netzwerktechnikern, die sich um die Behebung des Problems kümmern, genauso reibungslos klappt wie die Information der restlichen Mitarbeiter über den Fortschritt der Arbeiten.
6. Root-Cause-Analyse nach der Wiederherstellung
Kein Netzwerk-Disaster-Recovery-Plan ist vollständig ohne einen Schritt, in dem untersucht wird, was passiert ist, warum es passiert ist und wie sich die Recovery-Abläufe beim nächsten Notfall verbessern lassen. An diesem Punkt wird die Performance des Teams im Detail besprochen, um sicherzustellen, dass alle Prozesse ordnungsgemäß befolgt wurden. Außerdem sollte man die Root-Cause-Analyse nutzen, um Prozesse zu verfeinern oder zu ändern, falls die Untersuchung zu dem Schluss kommt, dass die aktuellen Verfahren unvollständig oder unzulänglich sind.
Netzwerk-Disaster-Recovery-Plan: Flexibilität ist Trumpf
Ein letzter Tipp noch, wenn Sie einen Netzwerk-Disaster-Recovery-Plan erstellen: Gehen Sie davon aus, dass wichtige technologische und architektonische Änderungen eher früher als später stattfinden. Es ist deshalb erforderlich, Prozesse und Verfahren so zu gestalten, dass sie sich einfach anpassen und gegenüber den Stakeholdern kommunizieren lassen, ohne von Grund auf neu anfangen zu müssen. Wenn Sie Disaster-Recovery-Pläne erstellen, die flexibel sind, werden Sie dadurch langfristig sehr viel Zeit sparen.
