Azure Site Recovery – Übersicht
Azure Site Recovery ist mehr als nur ein Tool, das Ihnen bei der Wiederherstellung nach Systemausfällen hilft. Azure Site Recovery repliziert Workloads zwischen einem primären und einem sekundären Standort. Site Recovery kann auch verwendet werden, um virtuelle Computer von einer lokalen Infrastruktur zu Azure zu migrieren.
Ihre erste Aufgabe beim Schützen Ihrer Workloads vor einem Erdbeben besteht z.B. darin, den aktuellen Plan für Geschäftskontinuität und Notfallwiederherstellung (BCDR, Business Continuity und Disaster Recovery) des Unternehmens zu überprüfen. Sie müssen die verschiedenen Ziele und den Umfang der Wiederherstellung für die Systeme ermitteln, die geschützt werden müssen.
In dieser Lerneinheit erfahren Sie, wie Azure Site Recovery Ihnen beim Erreichen dieser Ziele helfen und ein Failover sowie die Wiederherstellung von Ressourcen im Notfall ermöglichen kann.
Geschäftskontinuität und Notfallwiederherstellung (Business Continuity & Disaster Recovery, BCDR)
Der Verlust eines Diensts kann zu Unterbrechungen für Ihre Mitarbeiter und Benutzer führen. Jede Sekunde, in der Systeme nicht verfügbar sind, kann zu Umsatzverlusten für Ihr Unternehmen führen. Es kann auch zu Geldstrafen für Ihr Unternehmen kommen, wenn Vereinbarungen hinsichtlich der Verfügbarkeit der von Ihnen bereitgestellten Dienste nicht eingehalten werden.
BCDR-Pläne sind formelle Dokumente, die von Unternehmen erstellt werden und den Umfang und die Maßnahmen abdecken, die bei einem Notfall oder umfangreichen Ausfall ergriffen werden sollten. Jeder Ausfall wird nach seinem jeweiligen Ausmaß beurteilt. Ein BCDR-Plan (Business Continuity & Disaster Recovery) kommt beispielsweise zum Einsatz, wenn für ein ganzes Rechenzentrum der Strom ausfällt.
In diesem Beispielszenario wurden durch ein Erdbeben Kommunikationswege beschädigt, was dazu geführt hat, dass das Rechenzentrum repariert werden muss und vorerst nicht mehr verwendet werden kann. Bei einem Notfall dieser Größenordnung können Dienste nicht nur für Stunden, sondern tagelang ausfallen, sodass ein vollständiger BCDR-Plan in Kraft treten muss, um die Dienste wieder verfügbar zu machen.
Ermitteln Sie im Rahmen Ihres BCDR-Plans die Recovery Time Objectives (RTOs) und Recovery Point Objectives (RPOs) für Ihre Anwendungen. Die Kombination dieser beiden Zielsetzungen hilft Ihnen dabei, die maximale Anzahl von Stunden zu ermitteln, für die Ihr Unternehmen ohne bestimmte Dienste auskommt, und wie der Datenwiederherstellungsprozess aussehen sollte. Sehen wir uns diese einmal genauer an.
RTO (Recovery Time Objective)
RTO ist ein Maß für die maximale Zeitspanne, die Ihr Unternehmen nach einem Notfall verkraften kann, bevor der normale Betrieb wiederhergestellt werden muss, um nicht akzeptable Folgen im Zusammenhang mit einer Unterbrechung der Kontinuität zu vermeiden. Angenommen, Ihr RTO-Wert beträgt 12 Stunden. Das bedeutet, dass der Betrieb 12 Stunden lang fortgesetzt werden kann, ohne dass die Kerndienste des Unternehmens funktionieren. Geht die Downtime darüber hinaus, nimmt das Unternehmen ernsthaften Schaden.
RPO (Recovery Point Objective)
RPO ist ein Maß für den maximal akzeptablen Datenverlust nach einem Notfall. Ein Unternehmen kann üblicherweise alle 24 Stunden, 12 Stunden oder sogar in Echtzeit eine Sicherung erstellen. Bei einem Notfall kommt es jedoch immer zu Datenverlusten.
Wenn Ihre Sicherung beispielsweise alle 24 Stunden um Mitternacht erfolgt und um 9:00 Uhr ein Notfall eintritt, gehen die Daten von neun Stunden verloren. Wenn der RPO-Wert Ihres Unternehmens bei 12 Stunden liegt, ist dies in Ordnung, da nur neun Stunden vergangen sind. Wenn der RPO-Wert vier Stunden beträgt, gibt es ein Problem, und für das Unternehmen entsteht ein Schaden.
Was ist Azure Site Recovery?
Azure Site Recovery kann zu Ihrem BCDR-Plan beitragen, da hiermit Workloads von einem primären Standort an einen sekundären Standort repliziert werden können. Wenn am primären Standort ein Problem auftritt, kann Site Recovery automatisch aufgerufen werden, um die geschützten virtuellen Computer an einen anderen Standort zu replizieren. Das Failover kann vom lokalen Standort zu Azure oder aus einer Azure-Region in eine andere erfolgen.
Nachfolgend sind einige wichtige Features von Azure Site Recovery aufgeführt:
- Zentrale Verwaltung: Über das Azure-Portal kann die Replikation eingerichtet und verwaltet sowie ein Failover und Failback aufgerufen werden.
- Replikation lokaler virtueller Computer: Lokale virtuelle Computer können in Azure oder bei Bedarf in einem sekundären lokalen Rechenzentrum repliziert werden.
- Replikation virtueller Azure-Computer: Virtuelle Azure-Computer können aus einer Region in eine andere Region repliziert werden.
- App-Konsistenz während des Failovers: Mithilfe von Wiederherstellungspunkten und anwendungskonsistenten Momentaufnahmen werden VMs während der Replikation jederzeit in einem konsistenten Zustand gehalten.
- Flexibles Failover: Failover können bei Bedarf als Test ausgeführt oder während eines tatsächlichen Notfalls ausgelöst werden. Tests können ausgeführt werden, um ein Notfallwiederherstellungsszenario ohne Unterbrechung Ihres Live-Diensts zu simulieren.
- Netzwerkintegration: Site Recovery kann die Netzwerkverwaltung während eines Replikations-/Notfallwiederherstellungsszenarios verwalten. Reservierte IP-Adressen und Lastenausgleichsmodule sind dabei enthalten, sodass der virtuelle Computer am neuen Standort funktioniert.
Einrichten von Azure Site Recovery
Es müssen mehrere Komponenten zum Aktivieren von Azure Site Recovery eingerichtet werden:
- Netzwerk: Es ist ein gültiges virtuelles Azure-Netzwerk zur Verwendung für die replizierten virtuellen Computer erforderlich.
- Recovery Services-Tresor: Ein Tresor in Ihrem Azure-Abonnement speichert die migrierten virtuellen Computer bei einem Failover. Der Tresor enthält auch die Replikationsrichtlinie sowie die Quell-und Zielspeicherorte für Replikation und Failover.
- Anmeldeinformationen: Die Anmeldeinformationen, die Sie für Azure verwenden, müssen die Rollen Mitwirkender für virtuelle Computer und Site Recovery-Mitwirkender aufweisen, damit die Berechtigung zum Ändern des virtuellen Computers und des Speichers, mit dem Site Recovery verbunden ist, besteht.
- Konfigurationsserver: Ein lokaler VMware-Server erfüllt während des Failover- und Replikationsprozesses mehrere Rollen. Er wird für eine einfache Bereitstellung vom Azure-Portal als ein offener virtueller Computer (OVA) abgerufen. Der Konfigurationsserver umfasst Folgendes:
- Prozessserver: Dieser Server fungiert als Gateway für den Replikationsdatenverkehr. Der Datenverkehr wird zwischengespeichert, komprimiert und verschlüsselt, bevor er über das WAN an Azure gesendet wird. Der Prozessserver installiert auch den Mobilitätsdienst auf allen physischen und virtuellen Computern, die für Failover und Replikation vorgesehen sind.
- Masterzielserver: Dieser Computer übernimmt den Replikationsprozess während eines Failbacks von Azure.
Wichtig
Für ein Failback von Azure zu einer lokalen Umgebung muss VMware vCenter mit einem Konfigurationsserver auch dann verfügbar sein, wenn Sie nur physische Computer in Azure replizieren. Ein Failback zu physischen Servern ist nicht möglich.
Replikationsprozess
Nachdem Sie die erforderlichen Einrichtungsaufgaben ausgeführt haben, kann die Replikation der Computer beginnen. Diese werden gemäß der erstellten Replikationsrichtlinie repliziert. In der Anfangsphase der ersten Kopie werden die Serverdaten in Azure Storage repliziert. Nach Abschluss der ersten Replikation findet eine zweite Replikation statt. Diesmal werden die Deltaänderungen am virtuellen Computer in Azure repliziert.
Testen und Überwachen eines Failovers
Nachdem Sie Ihre Umgebung für die Notfallwiederherstellung eingerichtet haben, führen Sie einen Test aus, um sicherzustellen, dass sie ordnungsgemäß konfiguriert ist und alles erwartungsgemäß funktioniert. Testen Sie die Konfiguration, indem Sie ein Notfallwiederherstellungsverfahren auf einem isolierten virtuellen Computer durchführen. Es empfiehlt sich, ein isoliertes Netzwerk für den Test zu verwenden, damit keine Live-Dienste unterbrochen werden.
Die erste Aufgabe beim Versuch eines Wiederherstellungsverfahrens besteht darin, die Eigenschaften des virtuellen Testcomputers im Abschnitt Geschützte Elemente des Azure-Portals zu überprüfen. Die letzten Wiederherstellungspunkte werden im Bereich Repliziertes Element angezeigt. Im Abschnitt Compute und Netzwerk werden der Name des virtuellen Computers, die Ressourcengruppe, die Zielgröße, die Verfügbarkeitsgruppe und die Datenträgereinstellungen bei Bedarf angepasst.
Wiederherstellungsverfahren können über den Abschnitt Einstellungen>Replizierte Elemente des Azure-Portals gestartet werden. Wählen Sie den virtuellen Zielcomputer und anschließend das Menüelement Testfailover für den letzten verarbeiteten Wiederherstellungspunkt aus. Wählen Sie das Azure-Netzwerk in demselben Menü aus. Zum Starten des Wiederherstellungsauftrags wählen Sie auf dem Bildschirm für die Netzwerkauswahl die Option OK aus.
Der Status des Wiederherstellungsauftrags und des replizierten virtuellen Computers wird über den Abschnitt Übersicht des Recovery Services-Tresors abgerufen. Replizierte Elemente weisen folgende Status auf:
- Fehlerfrei: Die Replikation wird normal ausgeführt.
- Warnung: Es liegt ein Problem vor, das sich auf die Replikation auswirken könnte.
- Kritisch: Es wurde ein kritischer Replikationsfehler festgestellt.
Wenn alles problemlos verlaufen ist, wird der Status des replizierten Computers auf Erfolgreich ausgeführt gesetzt. Wenn noch kein Test ausgeführt wurde, wird der Status auf Test empfohlen gesetzt. Der virtuelle Computer wird auch dann auf Test empfohlen gesetzt, wenn seit dem letzten Test mehr als sechs Monate vergangen sind.