Business Continuity und Disaster Recovery für Azure VMware Solution

Dieses Szenario im Unternehmensmaßstab trägt zur Verbesserung von Geschäftskontinuität und Notfallwiederherstellung (BCDR) bei. Azure VMware Solution bietet private Clouds mit VMware vSphere-Clustern, die auf dedizierter Bare-Metal-Azure-Infrastruktur basieren. Die Lösung umfasst mindestens drei ESXi-Hosts und maximal 16 Hosts pro Cluster. Alle bereitgestellten privaten Clouds verfügen über VMware vCenter Server, VMware vSAN, VMware vSphere und VMware NSX-T Data Center. Weitere Informationen zur SLA (Vereinbarung zum Servicelevel) für Azure VMware Solution finden Sie unter SLA für Azure VMware Solution.

Unabhängig davon, ob Sie eine lokale Lösung oder Azure VMware Solution verwenden, sollten Sie zur Vorbereitung auf einen Notfall verschiedene BCDR-Faktoren berücksichtigen. Ein robuster BCDR-Plan zielt darauf ab, ein Unternehmen im Fall von Störungen vor Datenverlusten, finanziellen Verlusten und Ausfallzeiten zu schützen. Die folgende Entscheidungsstruktur zeigt verschiedene BCDR-Optionen, die für Azure VMware Solution verfügbar sind.

Designüberlegungen für Geschäftskontinuität

• VMware vSAN-Speicherrichtlinien für Azure VMware Solution werden unter Berücksichtigung der Speicherverfügbarkeit implementiert. Wenn der Cluster zwischen drei und fünf Hosts umfasst, kann der Ausfall eines Hosts toleriert werden, ohne dass es zu Datenverlusten kommt. Wenn der Cluster zwischen 6 und 16 Hosts umfasst, können 2 Hostausfälle ohne Datenverlust toleriert werden. VMware vSAN-Speicherrichtlinien können auf VM-Basis angewendet werden. Diese Richtlinien stellen die Standardeinstellung dar, jedoch können Sie die Richtlinie an Ihre individuellen Anforderungen anpassen. Weitere Informationen finden Sie unter Speicherkonzepte von Azure VMware Solution.

• vSphere-Hochverfügbarkeit ist in Azure VMware Solution standardmäßig aktiviert. Die Zulässigkeitsrichtlinie für Hochverfügbarkeit reserviert Compute- und Speicherkapazität für einen einzelnen Knoten. Diese Reservierung sorgt für ausreichende Kapazität, um Workloads auf einem anderen Knoten in einem Azure VMware Solution-Cluster neu zu starten.

• Hochverfügbarkeit mit Streched Cluster: Bei Azure VMware Solution befinden sich ESXi-Hosts, die in einem vSphere-Standardcluster bereitgestellt werden, üblicherweise in einer einzelnen Azure-Verfügbarkeitszone und sind durch vSphere-Hochverfügbarkeit geschützt. Die Workloads sind jedoch nicht vor einem Ausfall der Verfügbarkeitszone geschützt. Zum Schutz vor einem Ausfall kann sich ein einzelner vSAN-Cluster über zwei separate Verfügbarkeitszonen erstrecken und einen sogenannten vSAN Stretched Cluster bilden. Weitere Informationen finden Sie unter Bereitstellen eines vSAN Stretched Clusters.

• Wählen Sie eine validierte Sicherungslösung für die virtuellen VMware vSphere-Computer (VMs), z. B. Microsoft Azure Backup Server oder eine Partnersicherungslösung aus.

• Informationen zu unterstützten Features in Partnersicherungslösungen finden Sie in der entsprechenden Partnerdokumentation.

  Hinweis

  Die Konfigurationen von Azure VMware Solution Private Cloud vCenter Server und HCX Manager (sofern aktiviert) werden täglich gesichert und die Konfiguration von NSX wird stündlich gesichert. Die Sicherungen werden mindestens drei Tage lang aufbewahrt.

• Komponenten von Azure VMware Solution wie vCenter Server, NSX-T Manager oder HCX Manager sind verwaltete Dienste, deren Sicherung von Azure verwaltet wird. Zum Wiederherstellen aus einer Sicherung erstellen Sie eine Azure-Supportanfrage.

Designempfehlungen für Geschäftskontinuität

• Verwenden Sie Azure Backup Server, um die private Azure VMware Solution-Cloud zu sichern. Weitere Informationen finden Sie unter Sichern von VMware vSphere-VMs mit Azure Backup. Zu den unterstützten Bereitstellungstopologien gehören MARS-Agent und Data Protection Manager. Jede Bereitstellungstopologie bietet eine eigene Unterstützungsmatrix und weist eigene Einschränkungen auf.

• Stellen Sie die Azure Backup Server-Instanz in derselben Azure-Region wieder her, in der sich auch die private Azure VMware Solution-Cloud befindet. Diese Bereitstellungsmethode reduziert die Datenverkehrskosten, vereinfacht die Verwaltung und behält die primäre/sekundäre Topologie bei. Best Practices zur Bereitstellung in Azure-Regionen finden Sie im Leitfaden zur Auswahl von Azure-Regionen.

• Azure Backup kann als Azure IaaS-VM (Infrastructure-as-a-Service) oder innerhalb der privaten Azure VMware Solution-Cloud bereitgestellt werden. Es wird dringend empfohlen, die Bereitstellung außerhalb der privaten Azure VMware Solution-Cloud durchzuführen. Stellen Sie Backup in einem virtuellen Azure-Netzwerk bereit, und stellen Sie sicher, dass dieses virtuelle Netzwerk mit derselben ExpressRoute verbunden ist, die mit der privaten Azure VMware Solution-Cloud verbunden ist. Das Ausführen von Backup Server außerhalb der privaten Azure VMware Solution-Cloud trägt dazu dabei, die vSAN-Nutzung zu reduzieren, da es sich bei vSAN um eine Ressource mit begrenzter Kapazität innerhalb der privaten Azure VMware Solution-Cloud handelt.

  Azure Backup Server, bereitgestellt als Azure IaaS-VM.

  

  Azure Backup Server, bereitgestellt als Azure VMware Solution-VM.

  

• Verwenden Sie die Prüfliste für die Anforderungen an die Anwendungsleistung, um die richtige Kapazität und den richtigen Datenträgertyp zu ermitteln, wie etwa HDD, SSD oder Ultra. Verwenden Sie die Azure IaaS-VM-SKU, die den Datenträgertyp und die Kapazität für Sicherungsvorgänge unterstützt.

• Verwenden Sie Azure Backup Server Capacity Planner, um die Anforderungen an die Serveranzahl, den Speicher und IOPS zu ermitteln. Wenn Sie den Wert „Gesamtgröße der Workload (GB)*“ im Kapazitätsplaner angeben, verwenden Sie den Medianwert aus „verwendeter Speicher“ und „zugeordnetem Speicher“ aller VMs in vCenter, die Sie sichern möchten.

• Verwenden Sie Speicherpools zusammen mit Azure Backup Server für mehr Datenträger-IOPS bzw. -durchsatz. Verwenden Sie mehrstufigen Speicher auf dem Backup Server für den erweiterten Betrieb. Legen Sie den Konfigurationswert DisableWriteAutoTiering auf dem MABS-Volume auf 1 fest, sodass die gesamte Leistungsstufe zum Speichern von ReFS-Metadaten verfügbar ist.

• Identifizieren Sie die Anzahl paralleler Sicherungsaufträge und Wiederherstellungsvorgänge, die in Azure Backup Server ausgeführt werden sollen. Derzeit werden acht parallele Sicherungsaufträge unterstützt. Messen Sie die Zeit, die für die Sicherung und Wiederherstellung unternehmenskritischer Workloads über mehrere Ausführungen hinweg erforderlich ist. Überprüfen Sie, ob die Sicherungs- und Wiederherstellungszeiten die RPO- und RTO-Anforderungen für Azure Backup Server erfüllen. Stellen Sie sicher, dass der AVS-vSAN-Datenspeicher über genügend Kapazität für die wiederhergestellten Sicherungen verfügt.

• Fügen Sie erforderliche Antivirusausnahmen für Azure Backup Server-Dateien und -Ordner hinzu, wie hier dokumentiert, wenn Antiviren-/Antischadsoftware in Azure Backup Server ausgeführt wird. Wenn Sie den DPM-Schutz-Agent auf einer beliebigen Azure VMware Solution-VM für die Anwendungssicherung (z. B. SQL, SharePoint usw.) verwenden, deaktivieren Sie die Echtzeitüberwachung von dpmra.exe.

• Konfigurieren Sie geeignete Netzwerksicherheitsgruppen-Regeln (NSG) für das Subnetz, das Azure Backup Server hostet, um die Netzwerkkommunikation vom DPM-Schutz-Agent zuzulassen, der auf einer geschützten VM in Azure VMware Solution ausgeführt wird. Der DPM-Schutz-Agent kommuniziert mit Azure Backup Server an einem beliebigen dynamischen Port zwischen 1024 und 65535.

• Aktuell unterstützt Azure Backup Server keine regionsübergreifende Wiederherstellung für private Azure VMware Solution-Clouds. Sollte regionsübergreifende Wiederherstellung mit Azure VMware Solution erforderlich sein, finden Sie Informationen dazu in den Abschnitten Partnersicherungslösungen und Notfallwiederherstellung.

Designüberlegungen zur Notfallwiederherstellung

• Richten Sie geschäftsspezifische Anforderungen an RTO (Recovery Time Objectives, Zielsetzungen für die Wiederherstellungszeit), Kapazität und RPO (Recovery Point Objectives) für Anwendungen aus. Planen und entwerfen Sie entsprechend, um diese Ziele mit der am besten geeigneten Replikationstechnologie zu erreichen. Beispielsweise können Sie SQL-Datenbanken nativ mithilfe einer SQL-Always On-Verfügbarkeitsgruppe replizieren oder ein Notfallwiederherstellungstool wie VMware Site Recovery Manager verwenden.

• Bestimmen Sie den Zielstandort für die Notfallwiederherstellung der geschützten privaten Azure VMware Solution-Cloud. Dieser Standort hat Einfluss darauf, welche Tools für die Notfallwiederherstellung für die jeweilige Umgebung geeignet sind. Wenn Sie beispielsweise Azure VMware Solution-Workloads auf nativen virtuellen Azure-IaaS-Computern wiederherstellen möchten, können Sie Azure Site Recovery oder Zerto verwenden.

• Bestimmen Sie, welche Teilmenge von Azure VMware Solution-Workloads in einem eventuellen Notfall geschützt werden muss. Erwägen Sie die Kategorisierung der Workloads nach Priorität: P0 für unternehmenskritische Workloads und P1, P2, P3 für andere Workloads, die wichtig, aber für den Betrieb des Unternehmens nicht gleichermaßen kritisch sind. Der Geschäftskontinuitätsplan des Kunden definiert die Prioritätsstufen, was die Kontrolle der Kosten im Zusammenhang mit der Implementierung der Notfallwiederherstellung erlaubt.

• In den meisten Fällen muss für Nicht-Produktionsumgebungen wie Entwicklung, Test oder UAT (Benutzerakzeptanztests) kein Failover an einen sekundären Standort durchgeführt werden. Sie sollten die Pilot Light-Umgebung am sekundären Standort mit reduzierter Kapazität für Produktions- und kritische Workloads ausführen, um Kosten zu sparen. Zum Erzielen von mehr Kapazität können Sie aufskalieren, um dem Cluster während des Notfallwiederherstellungsereignisses ESXi-Hosts hinzuzufügen.

• Stellen Sie insbesondere bei schlanken Pilotbereitstellungen sicher, dass Sie das gesamte Hostkontingent gesichert haben, das am sekundären Standort benötigt wird, damit Sie während der vollständigen Aufskalierung nicht auf die benötigte Kapazität warten müssen. Weitere Informationen finden Sie unter Anfordern des Hostkontingents für Azure VMware Solution.

• Richten Sie funktionale Domänenrollen wie Active Directory-Domänencontroller in der sekundären Umgebung ein.

• Lösungen von Partnern wie JetStream und Zerto sind allgemein verfügbar und für Azure VMware Solution validiert. Sie unterstützen die meisten Notfallwiederherstellungsszenarien und können eine schnellere Wiederherstellung mit RPO nahezu 0 (null) ermöglichen.

• Die Migration von Drittanbieterstandorten zu Azure VMware Solution wird von VMware Site Recovery Manager, Jetstream und Zerto unterstützt.

• VMware HCX ist ebenfalls eine kostengünstige Lösung für die Notfallwiederherstellung. Aufgrund der manuellen Orchestrierung wird sie jedoch für große Produktionsworkloads nicht empfohlen.

• Für Notfallwiederherstellung zwischen privaten Azure VMware Solution-Clouds in verschiedenen Azure-Regionen müssen Sie ExpressRoute Global Reach zwischen beiden Back-End-ExpressRoute-Leitungen aktivieren. Diese Leitungen sorgen für Konnektivität zwischen der primären und der sekundären privaten Cloud, wenn dies für Lösungen wie VMware SRM und VMware HCX erforderlich ist.

• Für die Notfallwiederherstellung zwischen privaten Azure VMware Solution-Clouds innerhalb derselben Azure-Region müssen Sie Azure VMware Solution Interconnect aktivieren. Dies stellt eine Routingverbindung zwischen den Verwaltungs- und Workloadnetzwerken der privaten Azure VMware Solution-Clouds für die Netzwerkkommunikation zwischen den Clouds her. Stellen Sie sicher, dass der Adressraum der gerouteten IP-Adressen in jeder privaten Cloud eindeutig ist und sich nicht überschneidet.

• Beim Einrichten der Notfallwiederherstellung können Sie denselben IP-Quelladressraum in der primären Azure-Region wie in der sekundären Azure-Region verwenden. Dafür sind jedoch zusätzliche Anstrengungen bei Entwurf und Engineering erforderlich.

  • Beibehalten der gleichen IP-Adressen: Die virtuellen Computer am sekundären Azure VMware Solution-Standort können mit derselben IP-Quelladresse wie am primären Standort wiederhergestellt werden. Erstellen Sie für diese Methode isolierte VLANs oder NSX-T-Segmente am sekundären Standort, und sorgen Sie dafür, dass keines dieser isolierten VLANs oder Segmente mit der Umgebung verbunden ist. Ändern Sie Ihre Notfallwiederherstellungsrouten so ab, dass sie die Verlagerung des Subnetzes an den sekundären Standort und die neuen IP-Adressen widerspiegeln. Diese Methode funktioniert zwar, führt aber ebenfalls zu technischem Mehraufwand, wenn eine vollständig automatische Notfallwiederherstellung angestrebt wird.

  • Verwendung anderer IP-Adressen: Sie können für wiederhergestellte VMs auch abweichende IP-Adressen verwenden. Wenn die VM an einen sekundären Standort verschoben wird, muss der Wiederherstellungsplan in VMware Site Recovery Manager die benutzerdefinierte IP-Adressenzuordnung im Detail enthalten. Wählen Sie diese Zuordnung für die Änderung der IP-Adresse aus. VMs werden in den neuen NSX-T-Segmenten in Betrieb genommen, und neue IP-Adressen werden zugewiesen. Die Tools können sich bei verschiedenen Lösungen für die Notfallwiederherstellung unterscheiden.

• Wichtige Faktoren für Szenarien der teilweisen und vollständigen Notfallwiederherstellung:

  • VMware Site Recovery Manager unterstützt die teilweise Wiederherstellung, bei der nur eine Teilmenge der virtuellen Computer wiederhergestellt wird, und die vollständige Notfallwiederherstellung. Zwischen zwei Azure VMware Solution-Standorten in Region 1 und Region 2 kann ein Failover aller oder nur einiger der VMs ausgeführt werden.

  • Die Anforderung der Beibehaltung der IP-Quelladresse für wiederhergestellte VMs bestimmt, ob eine teilweise oder vollständige Notfallwiederherstellung möglich ist.

  • Damit die IP-Quelladresse bei der teilweisen Notfallwiederherstellung in Site Recovery Manager beibehalten werden kann, muss das Subnetzgateway an den sekundären Standort verschoben werden.

  Hinweis

  Für die Notfallwiederherstellung im aktiven Standbymodus ist kein L2-Stretching erforderlich.

Designempfehlungen zur Notfallwiederherstellung

• Verwenden Sie VMware Site Recovery Manager, wenn Sie mit Azure VMware Solution sowohl an primären als auch an sekundären Standorten arbeiten. Primäre und sekundäre Standorte werden auch als geschützte bzw. Wiederherstellungsstandorte bezeichnet.

  Allgemeine Übersicht über die fortlaufende vSphere-Replikation.

  

  Detailliertes Beispiel für die fortlaufende vSphere-Replikation zwischen primären und sekundären Standorten.

  

• Für unternehmenskritische Anwendungen stehen Zerto und JetStream als Notfallwiederherstellungslösungen für private Azure VMware Solution-Clouds zur Verfügung. JetStream und Zerto sind auf der Grundlage von CDP (Continuous Data Protection) aufgebaut und verwenden das VMware vSphere-API für E/A-Filterung-Framework (VAIO), das minimalen oder nahezu keinen Datenverlust ermöglicht. Es ermöglicht darüber hinaus eine kostengünstige Notfallwiederherstellung durch minimalen Ressourceneinsatz.

• Verwenden Sie Azure Site Recovery oder Zerto, wenn Azure IaaS-VMs das Notfallwiederherstellungsziel für die private Azure VMware Solution-Cloud darstellen.

• Minimieren Sie den manuellen Aufwand durch die Verwendung automatisierter Wiederherstellungspläne in den jeweiligen Lösungen für die Notfallwiederherstellung. Diese Pläne sind beim Arbeiten mit VMware Site Recovery Manager oder Partnerlösungen nützlich. Ein Wiederherstellungsplan fasst Computer in Wiederherstellungsgruppen für das Failover zusammen. Sie unterstützen die Definition eines systematischen Wiederherstellungsprozesses, indem unabhängige Einheiten erstellt werden, für die ein Failover möglich ist.

• Richten Sie mindestens einmal im Jahr Buildüberprüfungstests oder Notfallwiederherstellungsübungen ein, um sicherzustellen, dass die Wiederherstellungspläne wie erwartet funktionieren. Die Orchestrierungsfunktionen des ausgewählten Notfallwiederherstellungstools bestimmen den Aufwand für die Ausführung dieser Übungen.

• Verwenden Sie geopolitische Regionspaare als sekundäre Notfallwiederherstellungsumgebung. Zu den Vorteilen von Regionspaaren gehören priorisierte Regionswiederherstellung, sequenzielle Updates, physische Isolation und Datenresidenz.

• Halten Sie die Adressräume unterschiedlich, um überlappende IP-Adressen zwischen den beiden Standorten zu vermeiden. Verwenden Sie zum Beispiel 192.168.0.0/16 für Region 1 und 10.0.0.0/16 für Region 2.

• Verwenden Sie ExpressRoute Global Reach-Konnektivität zwischen den primären und sekundären privaten Azure VMware Solution-Clouds in verschiedenen Regionen. Weitere Netzwerküberlegungen und -empfehlungen finden Sie im zugehörigen Designabschnitt.

Nächste Schritte

Informieren Sie sich hinsichtlich der Überlegungen und Empfehlungen für die erste Bereitstellung von Azure VMware Solution, und machen Sie sich mit Anleitungen für die Betriebsautomatisierung vertraut.