20 Dinge, die Sie für eine IT-Notfallwiederherstellung planen sollten

Die Implementierung einer Notfallwiederherstellungslösung hängt von drei Faktoren ab — 1) Zeit 2) Ressourcen 3) Geldbetrag.

Die meisten Unternehmen denken nicht einmal an DR, wenn die IT-Infrastruktur und Anwendungen ohne Probleme laufen. Die meisten von ihnen denken nur dann an DR, wenn etwas kaputt geht, was erhebliche negative Auswirkungen auf das Geschäft hat.

Wenn Sie ein Systemadministrator oder jemand sind, der dafür verantwortlich ist, die IT am Laufen zu halten, sollten Sie ständig arbeiten auf Notfallwiederherstellung. Unabhängig davon, ob Ihr Unternehmen Zeit und Budget zugewiesen hat oder nicht, können Sie dennoch an einigen Aspekten von DR arbeiten.

Im Folgenden finden Sie eine Liste mit verschiedenen Punkten, die Sie bei der Planung einer Notfallwiederherstellung berücksichtigen sollten. Diese Liste ist keinesfalls vollständig, sollte Ihnen aber genügend Anregungen für den Einstieg in DR geben.

1. Zuverlässiges primäres Rechenzentrum. Bevor Sie ein sekundäres Remote-Rechenzentrum planen, sollten Sie sicherstellen, dass alle Komponenten in Ihrem primären Rechenzentrum hochredundant sind. Ihr Fokus sollte darauf liegen, Ihr primäres Rechenzentrum so widerstandsfähig wie möglich zu gestalten, damit Sie sich schnell von den meisten Katastrophen (außer Naturkatastrophen) erholen können, ohne jemals das sekundäre Remote-Rechenzentrum verwenden zu müssen. Lassen Sie beispielsweise für Ihre Produktionsdatenbank eine physische Standby-Datenbank im selben Rechenzentrum laufen, konfigurieren Sie zwei NIC-Karten und HBA-Karten auf allen Produktionsservern, konfigurieren Sie mehrere Webserver mit einem Load Balancer, verbinden Sie den Server über die Redundanz mit zwei Stromkreisen Stromversorgung der Server usw.
2. Sekundäres Remote-Rechenzentrum. Wenn Sie ein belastbares primäres Rechenzentrum implementieren, ist Ihr Ziel, ein redundantes Remote-Rechenzentrum zu verwenden, in erster Linie für Naturkatastrophen wie Erdbeben, Brände, Überschwemmungen usw. Obwohl dies sehr offensichtlich sein mag, ist es erwähnenswert, da ich nur wenige Unternehmen gesehen habe Wenn sie dies tun, haben sie sowohl das primäre als auch das sekundäre Rechenzentrum in derselben Stadt, was den Zweck von DR zunichte macht. Wenn sich Ihr primäres Rechenzentrum in Kalifornien befindet, richten Sie irgendwo an der Ostküste ein sekundäres Rechenzentrum ein.
3. Produktionskomponenten im DR-Rechenzentrum replizieren. Sie müssen nicht die gesamte Hardware und alle Anwendungen vom primären zum sekundären Rechenzentrum replizieren. Ein Systemadministrator oder eine andere technische Person kann schnell alle kritische Hardware und Software identifizieren, die am DR-Standort repliziert werden muss, aber Sie benötigen möglicherweise Hilfe von anderen Abteilungen, um die Anwendungen zu identifizieren, die für das Unternehmen kritisch sind. Sie müssen die kritischen Geschäftsfunktionen IT-Infrastrukturkomponenten zuordnen und sicherstellen, dass alle diese Infrastrukturkomponenten zusammen mit Anwendungen und Daten auf den DR-Standort repliziert werden.
4. Speicherplan. Wenn Sie über eine Art SAN-Speicher (oder NAS-Speicher) verfügen, der die kritische Anwendung in der primären DR unterstützt, müssen Sie auch an Ihrem DR-Standort über einen ähnlichen SAN-Speicher (oder NAS-Speicher) verfügen. Aus Leistungsgründen sollten die Produktivserver am DR-Standort die gleichen Spezifikationen wie die Produktivserver am primären Standort haben. Wenn Sie jedoch für Speicher einen High-End-SAN-Speicher eines großen Anbieters am primären Standort haben, sollten Sie die Implementierung eines ähnlichen High-End-SAN-Speichers eines kleinen Anbieters in Betracht ziehen, der Sie bei derselben Konfiguration und ähnlicher Leistung möglicherweise viel weniger Geld kostet .
5. Replizieren Sie Daten fortlaufend auf die DR-Site. Die Synchronisierung von Daten zwischen dem primären und dem Notfall-Rechenzentrum ist ein entscheidender Aspekt einer erfolgreichen DR-Implementierung. Nachdem Sie alle Anwendungen aufgelistet haben, die auf die DR-Site repliziert werden müssen, müssen Sie herausfinden, wie Sie die Daten zwischen diesen beiden Sites für all diese Anwendungen synchronisieren. Beispielsweise können Sie die Oracle-Datenbank mithilfe der von den Speicheranbietern bereitgestellten Replikationstechnologien auf Blockebene replizieren, oder Sie können Datagurad verwenden, um die Daten auf Oracle-Ebene zu replizieren. Beides hat seine eigenen Vor- und Nachteile. Sie müssen sie sorgfältig analysieren und diejenige auswählen, die zu Ihrem Budget und Umfang der Notfallwiederherstellung passt.
6. Anfangsdaten mit manueller Methode replizieren. Wenn Sie die DR-Site zum ersten Mal einrichten, müssen Sie entscheiden, wie Sie die anfängliche Datensynchronisierung durchführen. Wenn Sie beispielsweise eine riesige Data Warehouse-Datenbank replizieren, können Sie die anfängliche Sicherung der Datenbank nicht über das Netzwerk auf den Remote-Standort kopieren, da dies die Bandbreite in Anspruch nehmen könnte. Stattdessen können Sie im primären Rechenzentrum eine Bandsicherung erstellen und diese im sekundären Rechenzentrum verwenden, um die anfängliche Datenbank einzurichten. Sobald die Ersteinrichtung abgeschlossen ist, können Sie eine Form der automatischen inkrementellen Synchronisierung zwischen den Sites implementieren.
7. RTO steht für Recovery Time Objective. In Zusammenarbeit mit dem Managementteam identifizieren Sie die akzeptable RTO für das Unternehmen. Beispielsweise kann Ihre Organisation entscheiden, dass die akzeptable RTO 8 Stunden beträgt. d.h. nach einer Katastrophe sollten alle kritischen Anwendungen innerhalb von maximal 8 Stunden am DR-Standort voll funktionsfähig sein. RTO hat einen direkten Einfluss darauf, wie viel Geld für die Implementierung der DR-Lösung ausgegeben wird. Beispielsweise könnte eine RTO von 1 Stunde eine sehr ausgeklügelte DR-Lösung erfordern, die viel zu teuer ist als die RTO von 24 Stunden.
8. RPO steht für Recovery Point Objective. Genau wie bei RTO sollten Sie mit dem Management zusammenarbeiten, um ein akzeptables RPO für das Unternehmen festzulegen. Beispielsweise kann Ihre Organisation entscheiden, dass das akzeptable RPO 2 Stunden beträgt. d. h. nach einer Katastrophe, wenn Sie den Dienst auf eine sekundäre Notfallwiederherstellung umschalten, sind 2 Stunden Datenverlust für das Unternehmen akzeptabel. Wenn der Notfall beispielsweise um 15:00 Uhr eintritt, enthält es nach der Wiederherstellung des Systems am DR-Standort erst ab 13:00 Uhr Daten aus der Produktion. Sie haben also Daten von 13:00 bis 15:00 Uhr verloren. Einfach ausgedrückt:Wenn Ihr RPO 2 Stunden beträgt, sollte Ihr Unternehmen bereit sein, während eines Notfalls Daten im Wert von 2 Stunden zu verlieren.
9. Automatisches oder manuelles Failover? Sie haben die Wahl, ob Sie nach einem Notfall ein automatisches Failover oder ein manuelles Failover durchführen möchten. In den meisten Fällen ist ein manueller Eingriff akzeptabel, da Sie nicht aufgrund eines falschen Signals automatisch auf einen DR-Standort umschalten möchten. Denken Sie daran, dass es nach einem Failover viel Arbeit bedeutet, zum primären Rechenzentrum zurückzukehren.
10. Netzwerk-Failover. Ich habe DR-Pläne gesehen, die sich stark auf die Datenreplikation, aber weniger auf die Netzwerkaspekte der DR konzentrieren. In Zusammenarbeit mit Ihrem Netzwerkteam müssen Sie alle Netzwerkinfrastrukturen identifizieren, die repliziert werden müssen. Beispiel:DNA-Failover, um sicherzustellen, dass Ihre Produktions-URL nach dem Failover auf die DR-Site verweist. Wenn Sie VPN-Verbindungen für Ihre Kunden eingerichtet haben, finden Sie heraus, wie ein Failover für die VPN-Verbindungen durchgeführt werden kann. Wenn Sie Firewall-Regeln (oder andere sicherheitsrelevante) im primären Rechenzentrum erstellen/ändern, müssen Sie ermitteln, wie diese Sicherheitsrichtlinien fortlaufend auf den DR-Standort repliziert werden können.
11. Fernbedienung einrichten. Sie müssen über einen geeigneten Plan für den Zugriff auf das Remote-Rechenzentrum zum Debuggen von Problemen verfügen. Sie können KVM am DR-Standort einrichten, um von Ihrem Büro aus auf die Konsole der Hardware zuzugreifen, die sich am DR-Standort befindet. Oder Sie müssen eine Form von manuellen Remote-Hand-Diensten planen, bei denen jemand physisch zum DR-Standort gehen und Ihre Anweisungen ausführen kann.
12. Jährliche DR-Tests. Mehrere Organisationen investieren viel Zeit und Geld in die Einrichtung einer DR-Site, nur um herauszufinden, dass sie nicht wirklich wie erwartet funktioniert, wenn sie sich in einer echten DR-Situation befinden. Einmal im Jahr sollten Sie Ihre aktuellen DR-Konfigurationen validieren, um sicherzustellen, dass die DR-Site ordnungsgemäß funktioniert und das ursprüngliche Ziel erfüllt. Wenn alles richtig konfiguriert ist, sollten Sie in der Lage sein, ein manuelles Failover Ihrer kritischen Anwendungen vom primären Standort zum DR-Standort durchzuführen und sie dort einige Tage laufen zu lassen. Dies hilft Ihnen auch zu sehen, wie die DR-Site mit der Echtzeitbelastung umgeht.
13. DR-Site als QA-Plattform. Anstatt die DR-Site nur für Katastrophensituationen zu verwenden, können Sie sie als QA-Plattform verwenden, um Leistungs- und Lasttests Ihrer Anwendungen durchzuführen. Dies kann hilfreich sein, da Sie nicht in zusätzliche Testinfrastruktur im primären Rechenzentrum investieren müssen. Wenn Sie diesen Ansatz wählen, synchronisieren Sie weiterhin kontinuierlich Daten vom primären Standort mit dem DR-Standort. Wenn Sie jedoch einen Lasttest durchführen, müssen Sie eine zusätzliche Lösung implementieren, bei der Sie einen Checkpoint des aktuellen Status der DR-Site durchführen, Ihre QA-Tests durchführen und dann sofort zum vorherigen Checkpoint zurückkehren und mit der Synchronisierung der primären Site-Daten fortfahren von dort.
14. DR-Reaktionsplan. Sobald Sie die DR-Site implementiert haben, müssen Sie einen klaren DR-Plan haben, wie Sie und Ihr Team reagieren, wenn es zu einer echten Katastrophe kommt. Arbeiten Sie mit verschiedenen Abteilungen in Ihrer Organisation zusammen und identifizieren Sie die wichtigsten Ressourcen, die Teil des DR-Reaktionsteams sein werden, und identifizieren Sie ihre spezifische Rolle im DR-Reaktionsplan. Der DR-Reaktionsplan ist eine einfache Schritt-für-Schritt-Anleitung, was zu tun ist, wenn es einen DR gibt, wer diese Aufgaben ausführt und in welcher Reihenfolge diese Aufgaben ausgeführt werden.
15. Sie haben keine DR-Site? Viele Organisationen haben keine DR-Site. Wenn Sie für einen von ihnen arbeiten und für kritische Anwendungen und IT-Infrastruktur verantwortlich sind, liegt es in Ihrer Verantwortung, einen DR-Plan zu erstellen und Ihr Top-Management darüber aufzuklären, wie wichtig es ist, Zeit und Geld für DR aufzuwenden und zu bekommen ihre Zustimmung. Stellen Sie sich drei verschiedene DR-Pläne vor – einen, der $$$ kostet, einen, der $$ kostet, einen, der $ kostet. Wie wir bereits erklärt haben, kann der DR-Plan in Abhängigkeit von verschiedenen Faktoren variieren, und die Kosten sind einer davon. Nachdem Sie Ihrem Management Ihren detaillierten DR-Plan vorgelegt haben und es immer noch nicht zustimmt, fühlen Sie sich zumindest gut, dass Sie Ihr Bestes gegeben haben, um einen guten DR-Plan zu erstellen.
16. Wann ist eine Katastrophe auszurufen? Sie müssen dies im Voraus klar erkennen. Sie müssen ein sehr klares schriftliches Kriterium haben, wann Sie zur DR-Site wechseln. d. h. Welche Kriterien lösen die DR-Failover-Kriterien aus? Wann leiten Sie einen DR ein? An welchem ​​Punkt deklarieren Sie es als DR und beginnen mit der Arbeit am Failover zum DR-Standort? Die Antworten auf diese Fragen sollten klar definiert und von jeder Abteilung in Ihrer Organisation überprüft werden, und schließlich sollten diese Kriterien von der obersten Leitung genehmigt werden. Für einige, wenn die Produktion ausfällt, weil jemand versehentlich etwas in der Produktion gelöscht hat, wird möglicherweise kein DR ausgelöst. Für einige Organisationen ist es wahrscheinlich besser, die Daten aus der Sicherung am primären Standort selbst wiederherzustellen. Bei anderen Unternehmen kann das Unternehmen nicht warten, bis es aus dem Backup wiederhergestellt wird, und muss zur DR-Site wechseln.
17. Sicherung, Sicherung und nochmals Sicherung. Backups sind ein sehr wichtiger Faktor in einem DR-Plan. Wie bereits erwähnt, sollte es Ihr Ziel sein, die DR-Site niemals zu verwenden, es sei denn, es passiert eine echte Naturkatastrophe. Daher ist eine starke Backup-Strategie an Ihrem primären Standort sehr wichtig. Sie sollten alle Ihre kritischen Anwendungen sichern. Wenn Sie Ihre Datenbank sichern, speichern Sie die Sicherung an vier Orten. Sicherungen sind ziemlich nutzlos, wenn Sie sie nicht auf einem Testserver wiederherstellen, um zu überprüfen, ob sie kontinuierlich funktionieren.
18. Patches anwenden. Wenn Sie Betriebssystem-Patches anwenden, Firmware aktualisieren oder irgendeine Art von Konfigurationsmanagement auf die Hardware am primären Standort durchführen, müssen Sie eine Strategie haben, um diese am DR-Standort kontinuierlich durchzuführen. Sie möchten nicht in eine Situation geraten, in der sich die Betriebssystemkonfiguration auf Ihrer primären Site von der DR-Site unterscheidet.
19. Erfolgreiche DR hängt von vielen Faktoren ab. Segen des Top-Managements, angemessene Budgetzuweisung, Beteiligung aller Geschäftsbereiche, starker DR-Plan, starke technische Ressourcen, vollständig getestete DR-Implementierung. Am wichtigsten ist, dass ein gut definierter DR-Umfang, der mit den Geschäftszielen übereinstimmt, sehr entscheidend für eine erfolgreiche DR ist.
20. DR-Dokumentation. Für eine ordnungsgemäße DR-Planung müssen viele Prozesse eingerichtet werden. All diese Prozesse sollten ordnungsgemäß dokumentiert werden. Zum Beispiel ein Dokument, das den Eskalationsprozess erklärt, wenn ein DR zuschlägt. Eine technische Dokumentation, die erklärt, was getan werden muss, um das Failover zum DR-Standort durchzuführen. Ein Kommunikationsdokument, das alle an der DR beteiligten Teammitglieder auflistet, wofür sie verantwortlich sind und wie sie während der DR kontaktiert werden können. Ein Dokument für das Kundensupportteam, das weiß, was dem Kunden mitgeteilt werden muss und wie es Kunden im Katastrophenfall erreichen kann. Ein DR-Testdokument, das alles auflistet, was ein QA-Team testen muss, nachdem die DR-Site live gegangen ist usw.

Wir haben nur an der Oberfläche der Notfallwiederherstellung gekratzt. Es steckt viel mehr dahinter als die oben genannten Punkte. Wenn Sie ein Systemadministrator oder jemand sind, der für Ihre IT-Anwendungen und -Infrastruktur verantwortlich ist, und keinen DR-Plan haben, sollten Sie dies als Erinnerung betrachten, etwas für Ihre DR-Strategie in Angriff zu nehmen.