Notfallwiederherstellung für Azure Stack Hub-VMs

In diesem Artikel werden die Architektur- und Entwurfsüberlegungen für eine Lösung beschrieben, die einen optimierten Ansatz für die Notfallwiederherstellung von auf virtuellen Maschinen (VM) ausgeführten Workloads bietet, die auf Azure Stack Hub gehostet werden.

Aufbau

Laden Sie eine Visio-Datei dieser Architektur herunter.

Workflow

Die Cloudkomponenten der vorgeschlagenen Lösung umfassen die folgenden Dienste:

• Ein Azure-Abonnement, in dem alle Cloudressourcen gehostet werden, die zu dieser Lösung gehören.

• Ein Microsoft Entra ID-Mandant, der dem Azure-Abonnement zugeordnet ist und die Authentifizierung von Microsoft Entra-Sicherheitsprinzipalen bereitstellt, um den Zugriff auf Azure-Ressourcen zu autorisieren.

• Einen Azure Recovery Services-Tresor in der Azure-Region, die dem lokalen Rechenzentrum am nächsten ist, in dem die Azure Stack Hub-Bereitstellung gehostet wird.

  Hinweis

  Die Wahl der Azure-Region, die dem lokalen Rechenzentrum am nächsten liegt, gilt speziell für das Beispielszenario, das in diesem Artikel enthalten ist. Aus Sicht der Notfallwiederherstellung ist es besser, eine Azure-Region auszuwählen, die weiter von dem Standort entfernt ist, an dem die Produktionsumgebung gehostet wird. Die Entscheidung kann jedoch von zusätzlichen Faktoren abhängen, etwa der Notwendigkeit, die Latenzzeiten regionaler Datenfeeds zu minimieren oder Anforderungen hinsichtlich der Datenresidenz zu erfüllen.

• Eine Azure ExpressRoute-Verbindung, die die lokalen Rechenzentren mit der Azure-Region verbindet, in der der Azure Recovery Services-Tresor gehostet wird und die mit privatem Peering und Microsoft-Peering konfiguriert ist. Ersteres stellt sicher, dass die Latenzanforderungen nach einem Failover erfüllt werden. Der Zweck des Peerings besteht darin, die Zeit zu minimieren, die zum Replizieren von Änderungen zwischen den lokalen Workloads und dem Failoverstandort in Azure benötigt wird.

• Ein Azure Storage-Konto, das Blobs beinhaltet, die VHD-Dateien enthalten, die durch Replikation des Betriebssystems und der Datenvolumes geschützter Azure Stack Hub-VMs erstellt wurden. Diese VHD-Dateien dienen als Quelle für die verwalteten Datenträger von Azure-VMs, die nach einem Failover automatisch bereitgestellt werden.

• Ein virtuelles Azure-Netzwerk, in dem die Notfallwiederherstellungsumgebung gehostet wird. Das Netzwerk ist so konfiguriert, dass die Umgebung des virtuellen Netzwerks im Azure Stack Hub-System gespiegelt wird, das die Produktionsworkloads hostet, wozu Komponenten wie Lastenausgleichsmodule und Netzwerksicherheitsgruppen gehören. Dieses virtuelle Netzwerk ist normalerweise über eine ExpressRoute-Verbindung mit dem virtuellen Azure Stack Hub-Netzwerk verbunden, um die Wiederherstellung auf Workloadebene zu vereinfachen.

  Hinweis

  Manchmal ist eine Site-to-Site-VPN-Verbindung in Szenarios ausreichend, in denen Recovery Point Objective-Anforderungen (RPO-Anforderungen) weniger streng sind.

• Ein isoliertes virtuelles Azure-Netzwerk, das für Testfailover vorgesehen und so konfiguriert ist, dass die Umgebung des virtuellen Netzwerks im Azure Stack Hub-System gespiegelt wird, das die Produktionsworkloads hostet, wozu Komponenten wie Lastenausgleichsmodule und Netzwerksicherheitsgruppen gehören.

Die lokalen Komponenten der vorgeschlagenen Lösung umfassen die folgenden Dienste:

• Ein in Azure Stack Hub integriertes System im verbundenen Bereitstellungsmodell. Das System führt das aktuelle Update (2002 ab 9/20) aus und befindet sich im lokalen Rechenzentrum des Kunden.

• Ein Azure Stack Hub-Abonnement und ein virtuelles Netzwerk oder mehrere virtuelle Netzwerke mit Peering, in denen alle lokalen VMs für diese Lösung gehostet werden.

• Azure Site Recovery-Konfigurations- und -Prozessserver, die auf Azure Stack Hub-VMs unter Windows Server 2016 oder 2012 R2 ausgeführt werden. Die Server verwalten die Kommunikation mit dem Azure Recovery Services-Tresor sowie das Routing, die Optimierung und die Verschlüsselung des Replikationsdatenverkehrs.

  Hinweis

  Standardmäßig hostet ein Konfigurationsserver einen einzelnen Prozessserver. Sie können dedizierte Prozessserver bereitstellen, um eine größere Menge an Replikationsdatenverkehr zu bewältigen.

• Die zu schützenden Azure Stack Hub-VMs. Sie führen unterstützte Versionen der Betriebssysteme Windows Server, CentOS und Ubuntu aus.

• Den Site Recovery-Mobilitätsdienst (auch als Mobilitäts-Agent bezeichnet), der auf geschützten VMs ausgeführt wird. Der Dienst verfolgt Änderungen an lokalen Datenträgern nach, zeichnet die Änderungen in Replikationsprotokollen auf und repliziert die Protokolle auf dem Prozessserver. Der Prozessserver leitet sie an das Azure-Zielspeicherkonto weiter. Die Protokolle werden verwendet, um Wiederherstellungspunkte für verwaltete Datenträger zu erstellen, die mit BLOB-Dateien implementiert sind, die im von Ihnen angegebenen Azure Storage-Konto gespeichert sind.

Komponenten

• Microsoft Entra ID
• Azure Virtual Network
• Azure Recovery Services
• Azure ExpressRoute
• Azure Blob Storage
• Azure Stack Hub

Alternativen

Die in diesem Artikel beschriebene empfohlene Lösung ist nicht die einzige Möglichkeit, Notfallwiederherstellungsfunktionalität für Azure Stack Hub-VM-basierte Workloads bereitzustellen. Kunden haben weitere Optionen, zu denen die folgenden gehören:

• Ein Failover zu einem anderen Azure Stack Hub-Stempel. Benutzer, die sich vor einem Ausfall eines Rechenzentrums oder Standorts schützen müssen, können möglicherweise eine andere Azure Stack Hub-Bereitstellung verwenden, um Bereitstellungen zur Notfallwiederherstellung zu implementieren. Mit einem primären und sekundären Standort können Benutzer Anwendungen in einer Aktiv/Passiv-Konfiguration in zwei Umgebungen bereitstellen. Für weniger kritische Workloads kann es akzeptabel sein, ungenutzte Kapazitäten im sekundären Standort zu nutzen, um bedarfsgesteuerte Wiederherstellungen von Anwendungen aus einer Sicherung vorzunehmen. Sie können auch einen Wiederherstellungsstandort in einem anderen Rechenzentrum implementieren, in dem wiederum Site Recovery genutzt wird, um ein Replikat des Wiederherstellungsstandorts in Azure bereitzustellen. Mehrere Faktoren bestimmen, ob die Verwendung von Site Recovery mit Azure, das als Failoverstandort fungiert, eine geeignete Lösung ist. Zu diesen Faktoren zählen behördliche Vorschriften, Unternehmensrichtlinien und Latenzzeitanforderungen.

  Hinweis

  Seit Juli 2020 wird dieses Szenario nicht mehr von Site Recovery unterstützt, was bedeutet, dass die Implementierung auf einer Partnerlösung oder auf einer internen Lösung aufsetzen muss.

• Sichern und Wiederherstellen. Die Sicherung Ihrer Anwendungen und Datasets ermöglicht Ihnen schnelles Wiederherstellen nach einer Downtime infolge von Datenbeschädigung, versehentlichen Löschungen oder lokalisierten Ausfällen. Für Anwendungen auf Basis von Azure Stack Hub-VMs können Sie einen im Gastsystem enthaltenen Agent verwenden, um Anwendungsdaten, Betriebssystemkonfiguration und auf Volumes gespeicherte Daten zu schützen. Die Sicherung einer VM mithilfe eines Gastbetriebssystem-Agents beinhaltet in der Regel die Erfassung von Betriebssystemkonfigurationen, Dateien, Ordnern, Volumes, Anwendungsbinärdateien und Anwendungsdaten. Die Wiederherstellung einer Anwendung über einen Agent erfordert eine Neuerstellung der VM, wonach dann das Betriebssystem und der Gast-Agent installiert werden. An diesem Punkt können Sie Daten im Gastbetriebssystem wiederherstellen.

• Sichern von Datenträgermomentaufnahmen. Es ist möglich, Momentaufnahmen zu verwenden, um eine Azure Stack Hub-VM-Konfiguration und die Datenträger zu erfassen, die einer beendeten VM zugeordnet sind. Dieser Prozess erfordert Sicherungsprodukte, die in Azure Stack Hub-APIs eingebunden werden können, um die VM-Konfiguration zu erfassen und Datenträgermomentaufnahmen zu erstellen.

  Hinweis

  Seit Juli 2020 wird die Verwendung von Datenträgermomentaufnahmen für ausgeführte VMs nicht mehr unterstützt. Die Erstellung einer Momentaufnahme eines Datenträgers, der einer aktiven VM zugeordnet ist, kann die Leistung oder die Verfügbarkeit des Betriebssystems oder der Anwendung auf der VM beeinträchtigen.

• Sichern und Wiederherstellen von VMs mit einer externen Sicherungslösung im selben Rechenzentrum, gefolgt von der Replikation von Sicherungen an einem anderen Speicherort. Auf diese Weise können Sie Azure Stack Hub-VMs in derselben Azure Stack Hub-Instanz oder einer anderen Instanz oder in Azure wiederherstellen.

Szenariodetails

Azure Stack Hub bietet Selbstreparaturfunktionen, die automatische Wiederherstellung in einer Reihe von Szenarios ermöglichen, in denen lokale Ausfälle von Azure Stack Hub-Komponenten auftreten. Allerdings erfordern umfangreiche Ausfälle, so auch Ausfälle, die sich auf Serverracks auswirken, oder Ausfälle auf Standortebene, zusätzliche Überlegungen. Diese Überlegungen sollten Bestandteil der Business Continuity & Disaster Recovery-Strategie für VM-basierte Benutzerworkloads sein. In dieser Strategie muss auch die Wiederherstellung der Azure Stack-Infrastruktur berücksichtigt werden, die von der Workloadwiederherstellung getrennt ist.

Für herkömmliche lokale Workloadwiederherstellungslösungen gilt, dass sie komplex zu konfigurieren, teuer und arbeitsintensiv zu verwalten und herausfordernd zu automatisieren sind. Dies trifft insbesondere zu, wenn ein anderer lokaler Standort als Failoverstandort verwendet wird. Microsoft empfiehlt eine alternative Lösung, die auf einer Kombination von Cloud- und lokalen Komponenten basiert, die resiliente, leistungsbasierte, hochautomatisierte und unkomplizierte Möglichkeiten bietet, um eine kostengünstige Strategie für die Notfallwiederherstellung zu implementieren, abzusichern und zu verwalten. Das Kernelement dieser Lösung ist Site Recovery mit Failoverstandort in Azure.

Mögliche Anwendungsfälle

Site Recovery mit Azure als Failoverstandort beseitigt alle oben genannten Probleme. Sie können die Funktionen von Azure Site Recovery verwenden, um sowohl physische als auch virtuelle Server zu schützen, einschließlich derjenigen, die auf Microsoft Hyper-V- oder VMware ESXi-Virtualisierungsplattformen ausgeführt werden. Außerdem können Sie dieselben Funktionen nutzen, um die Wiederherstellung von Workloads zu vereinfachen, die auf Azure Stack Hub-VMs ausgeführt werden.

Kernfunktionalität

Site Recovery ist eine Notfallwiederherstellungslösung, die den Schutz von physischen und virtuellen Computern ermöglicht, indem in ihr zwei Funktionsgruppen bereitgestellt werden:

• Replikation von Änderungen an Computerdatenträgern zwischen dem Produktions- und dem Notfallwiederherstellungsstandort
• Orchestrierung des Failovers und Failbacks zwischen diesen beiden Standorten

Site Recovery bietet drei Failovertypen:

• Testfailover. Dieses Failover bietet Ihnen die Möglichkeit, Ihre Site Recovery-Konfiguration in einer isolierten Umgebung zu validieren, ohne Datenverluste oder Auswirkungen auf die Produktionsumgebung zu haben.
• Geplantes Failover. Dieses Failover bietet Ihnen die Möglichkeit, eine Notfallwiederherstellung ohne Datenverlust, in der Regel im Rahmen einer geplanten Downtime, zu initiieren.
• Nicht geplantes Failover. Dieses Failover fungiert als letztes Mittel im Fall eines ungeplanten Ausfalls, der die Verfügbarkeit des primären Standorts beeinträchtigt und möglicherweise zu Datenverlusten führt.

Site Recovery unterstützt verschiedene Szenarios, z. B. Failover und Failback zwischen zwei lokalen Standorten, Failover und Failback zwischen zwei Azure-Regionen und Migration aus Drittanbieterclouds. Im Zusammenhang mit diesem Artikel liegt der Fokus jedoch auf der Replikation von lokalen Datenträgern von Azure Stack Hub-VMs zu Azure Storage und auf VM-Failover und -Failback zwischen einem Azure Stack Hub-Stapel und einer Azure-Region.

Details zur Site Recovery-Architektur und deren Komponenten hängen von einer Reihe von Kriterien ab, zu denen die Folgenden gehören:

• Die Typen der zu schützenden Computer (physisch bzw. virtuell)
• Für virtualisierte Umgebungen der Typ des Hypervisors, der die zu schützenden virtuellen Computer (Hyper-V und VMware ESXi) hostet
• Für Hyper-V-Umgebungen die Nutzung von System Center Virtual Machine Manager (SCVMM), um Hyper-V-Hosts zu verwalten

Bei Azure Stack Hub entspricht die Architektur derjenigen, die für physische Computer geeignet ist. Dies ist nicht besonders überraschend, da Site Recovery in beiden Fällen nicht von direktem Zugriff auf einen Hypervisor profitieren kann. Stattdessen ist der Mechanismus, der Änderungen an lokalen Datenträgern nachverfolgt und repliziert, im geschützten Betriebssystem implementiert.

Damit dies erreicht wird, setzt Site Recovery auf dem Site Recovery-Mobilitätsdienst (auch als Mobilitäts-Agent bezeichnet) auf, der automatisch auf einzelnen virtuellen Computern (VMs) bereitgestellt wird, wenn Sie diese im Geltungsbereich des Site Recovery-basierten Schutzes registrieren. Auf jeder geschützten VM überwacht die lokal installierte Instanz des Mobilitäts-Agents ständig, ob Änderungen am Betriebssystem und den Datenträgern vorgenommen wurden, und leitet solche Änderungen an den Prozessserver weiter. Um den Fluss des Replikationsdatenverkehrs, der von geschützten VMs stammt, zu optimieren und zu verwalten, wird mit Site Recovery außerdem ein zusätzlicher Satz von Komponenten implementiert, die auf einer separaten VM ausgeführt werden, die als Konfigurationsserver bezeichnet wird.

Der Konfigurationsserver koordiniert die Kommunikation mit dem Site Recovery-Tresor und verwaltet die Datenreplikation. Außerdem hostet der Konfigurationsserver eine Komponente, die als Prozessserver bezeichnet wird. Dieser fungiert als Gateway, das die Replikationsdaten empfängt, diese Daten durch Zwischenspeichern und Komprimierung optimiert, die Daten verschlüsselt und sie schließlich an Azure Storage weiterleitet. Tatsächlich fungiert der Konfigurationsserver als Integrationspunkt zwischen Site Recovery und geschützten VMs, die auf Azure Stack Hub ausgeführt werden. Sie implementieren diese Integration, indem Sie den Konfigurationsserver bereitstellen und ihn im Azure Recovery Services-Tresor registrieren.

Im Rahmen der Site Recovery-Konfiguration definieren Sie die vorgesehene Notfallwiederherstellungsumgebung, einschließlich solcher Infrastrukturkomponenten wie virtuelle Netzwerke, Lastenausgleichsmodule oder Netzwerksicherheitsgruppen, in der Weise, die der Produktionsumgebung entspricht. Die Konfiguration umfasst auch eine Replikationsrichtlinie, die die Wiederherstellungsfunktionen bestimmt und aus den folgenden Parametern besteht:

• RPO-Schwellenwert. Diese Einstellung entspricht dem gewünschten Wiederherstellungspunktziel (Recovery Point Objective, RPO), das Sie implementieren möchten, und bestimmt die Häufigkeit, mit der Site Recovery absturzkonsistente Wiederherstellungspunkt-Momentaufnahmen erstellt. Der Wert der Einstellung wirkt sich nicht auf die Replikationshäufigkeit aus, da diese Replikation durchgängig erfolgt. Site Recovery generiert eine Warnung und optional eine E-Mail-Benachrichtigung, wenn das aktuell wirksame RPO, das von Site Recovery bereitgestellt wird, den von Ihnen angegebenen Schwellenwert überschreitet. Site Recovery erstellt alle fünf Minuten absturzkonsistente Wiederherstellungspunkt-Momentaufnahmen.

  Hinweis

  Eine absturzkonsistente Momentaufnahme erfasst Daten, die sich zum Zeitpunkt der Erstellung der Momentaufnahme auf dem Datenträger befunden haben. Sie enthält keinen Arbeitsspeicherinhalt. Tatsächlich garantiert eine absturzkonsistente Momentaufnahme keine Datenkonsistenz für das Betriebssystem oder lokal installierte Apps.

• Aufbewahrung des Wiederherstellungspunkts. Diese Einstellung entspricht (in Stunden) der Dauer des Aufbewahrungszeitfensters für jede Wiederherstellungspunkt-Momentaufnahme. Geschützte VMs können für jeden Wiederherstellungspunkt wiederhergestellt werden, der sich im entsprechenden Aufbewahrungszeitfenster befindet. Site Recovery unterstützt für VMs, die mit der Premium-Leistungsstufe in Azure Storage-Konten repliziert werden, eine Aufbewahrung bis zu 24 Stunden. Es gibt eine Aufbewahrungsgrenze von 72 Stunden, wenn Azure Storage-Konten mit der Standard-Leistungsstufe verwendet werden.

• App-konsistente Momentaufnahmenhäufigkeit. Diese Einstellung bestimmt die Häufigkeit (in Stunden), mit der Site Recovery anwendungskonsistente Momentaufnahmen generiert. Eine App-konsistente Momentaufnahme entspricht einer Zeitpunktmomentaufnahme (Point-in-Time-Momentaufnahme) der Anwendungen, die auf einer geschützten VM ausgeführt werden. Es gibt eine Beschränkung auf 12 App-konsistente Momentaufnahmen. Für VMs, auf denen Windows Server ausgeführt wird, nutzt Site Recovery den Volumeschattenkopie-Dienst (Volume Shadow Copy Service, VSS). Site Recovery unterstützt auch App-konsistente Momentaufnahmen für Linux. Dafür müssen jedoch benutzerdefinierter Skripts implementiert werden. Die Skripts werden vom Mobilitäts-Agent verwendet, wenn eine App-konsistente Momentaufnahme angewendet wird.

  Hinweis

  Ausführliche Informationen zum Implementieren von App-konsistenten Momentaufnahmen auf Azure Stack Hub-VMs, auf denen Linux ausgeführt wird, finden Sie unter Allgemeine Fragen zu Site Recovery.

Für jeden Datenträger einer geschützten Azure Stack Hub-VM, den Sie zuordnen, werden die Daten auf einem entsprechenden verwalteten Datenträger in Azure Storage repliziert. Auf dem Datenträger werden die Kopie des Quelldatenträgers und alle absturzkonsistenten und App-konsistenten Momentaufnahmen des Wiederherstellungspunkts gespeichert. Als Bestandteil eines Failovers wählen Sie für den Wiederherstellungspunkt eine absturzkonsistente oder App-konsistente Momentaufnahme aus, die verwendet werden soll, wenn der verwaltete Datenträger der Azure-VM zugeordnet wird, die als Replikat der geschützten Azure Stack Hub-VM fungiert.

Während normaler Geschäftsvorgänge werden geschützte Workloads auf Azure Stack Hub-VMS ausgeführt. Änderungen an deren Datenträgern werden kontinuierlich durch Interaktionen zwischen dem Mobilitäts-Agent, dem Prozessserver und dem Konfigurationsserver an das zugeordnete Azure Storage Konto repliziert. Wenn Sie ein Test-, geplantes oder ungeplantes Failover auslösen, verwendet Site Recovery die Replikate der Datenträger der entsprechenden Azure Stack Hub-VMs, um automatisch Azure-VMs bereitzustellen.

Sie können ein Failover orchestrieren, indem Sie Wiederherstellungspläne erstellen, die manuelle und automatisierte Schritte enthalten. Um Letzteres zu implementieren, können Sie Azure Automation-Runbooks nutzen, die aus benutzerdefinierten PowerShell-Skripts, PowerShell-Workflows oder Python 2-Skripts bestehen.

Nachdem der primäre Standort wieder verfügbar ist, unterstützt Site Recovery das Umkehren der Replikationsrichtung, sodass Sie ein Failback mit minimierter Ausfallzeit und ohne Datenverlust durchführen können. Mit Azure Stack Hub ist dieser Ansatz jedoch nicht verfügbar. Stattdessen ist es zum Ausführen eines Failbacks erforderlich, Azure-VM-Datenträgerdateien herunterzuladen, diese in Azure Stack Hub hochzuladen und sie vorhandenen oder neue VMs zuzuordnen.

Überlegungen

Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Zuverlässigkeit

Zuverlässigkeit stellt sicher, dass Ihre Anwendung Ihre Verpflichtungen gegenüber den Kunden erfüllen kann. Weitere Informationen finden Sie in der Überblick über die Säule „Zuverlässigkeit“.

Azure Stack Hub ermöglicht durch die in seiner Infrastruktur begründete Resilienz eine erhöhte Workloadverfügbarkeit. Diese Resilienz bietet Hochverfügbarkeit für Azure Stack Hub-VMs, die durch Site Recovery geschützt sind, und für wichtige Komponenten der lokalen Site Recovery-Infrastruktur, einschließlich der Konfigurations- und Prozessserver.

Dazu vergleichbar haben Sie die Möglichkeit, die Resilienz von cloudbasierten Komponenten der Site Recovery-Infrastruktur zu nutzen. Standardmäßig ist der Azure Recovery Services-Dienst georedundant, das heißt, dass seine Konfiguration automatisch an eine Azure-Region repliziert wird, die Bestandteil eines vordefinierten Regionspaars ist. Sie können die Replikationseinstellungen in lokal redundant ändern, wenn dies für Ihre Resilienzanforderungen genügt. Sie können diese Option allerdings nicht ändern, wenn der Tresor geschützte Elemente enthält. Die gleiche Resilienzoption ist für alle Azure Storage Konten mit der Standard-Leistungsstufe verfügbar, lässt sich aber jederzeit ändern.

Sie können das Maß dieser Resilienz weiter erhöhen, indem Sie Lösungen entwerfen und implementieren, die den Umfang des Workloadschutzes erweitern. Dies ist der Mehrwert, den Site Recovery bietet. Hinsichtlich des auf Azure Stack Hub ausgeführten Site Recovery-Diensts gibt es zwei Hauptaspekte zur Workloadverfügbarkeit, die ausführlicher untersucht werden müssen:

• Failover zu Azure
• Failback zu Azure Stack Hub

Sie müssen beide Aspekte berücksichtigen, wenn Sie eine Notfallwiederherstellungsstrategie entwickeln, die auf RPOs (Recovery Point Objectives) und RTOs (Recovery Time Objectives) aufsetzt. RTO und RPO stellen die Kontinuitätsanforderungen dar, die durch einzelne Geschäftsfunktionen innerhalb einer Organisation vorgegeben sind. RPO bestimmt einen Zeitraum, der den maximal zulässigen Datenverlust nach einem Vorfall darstellt, der die Verfügbarkeit dieser Daten beeinträchtigt hat. RTO bestimmt die maximal zulässige Zeitdauer, die bis zur Wiederherstellung von Geschäftsfunktionen nach einem Vorfall verstreichen darf, der die Verfügbarkeit dieser Funktionen beeinträchtigt hat.

Failover zu Azure

Failover zu Azure steht im Mittelpunkt der Verfügbarkeitsüberlegungen, die hinsichtlich des Site Recovery-basierten Schutzes von Azure Stack Hub-VMs anzustellen sind. Um die Workloadverfügbarkeit zu maximieren, sollten für die Failoverstrategie die beiden Notwendigkeiten berücksichtigt werden, sowohl mögliche Datenverluste (RPO) als auch die Failoverzeit (RTO) zu minimieren.

Um mögliche Datenverluste zu minimieren, sollten Sie Folgendes bedenken:

• Maximieren des Durchsatzes und Minimieren der Latenzzeit des Replikationsverkehrs durch Berücksichtigung von Skalierbarkeits- und Leistungsüberlegungen. Weitere Informationen finden Sie im nächsten Abschnitt dieses Artikels.
• Erhöhen der Häufigkeit von App-konsistenten Wiederherstellungspunkten für Datenbankworkloads (bis zum Maximum von einem Wiederherstellungspunkt pro Stunde). App-konsistente Wiederherstellungspunkte werden aus App-konsistenten Momentaufnahmen erstellt. In App-konsistenten Momentaufnahmen werden App-Daten auf Datenträgern und im Arbeitsspeicher erfasst. Während bei diesem Ansatz der mögliche Datenverlust minimiert wird, hat er einen großen Nachteil. App-konsistente Momentaufnahmen erfordern die Verwendung von Volumeschattenkopie-Dienst unter Windows oder benutzerdefinierten Skripts unter Linux, um lokal installierte Apps zu umgehen. Der Aufzeichnungsprozess kann sich negativ auf die Leistung auswirken, insbesondere, wenn die Ressourcennutzung hoch ist. Es ist nicht zu empfehlen, nur selten App-konsistente Momentaufnahmen für Nicht-Datenbankworkloads zu erstellen.

Die primäre Methode zum Minimieren der Failoverzeit besteht in der Verwendung von Site Recovery-Wiederherstellungsplänen. Ein Wiederherstellungsplan orchestriert ein Failover zwischen dem primären und dem sekundären Standort, und in ihm ist die Reihenfolge definiert, in der ein Failover für geschützte Server ausgeführt wird. Sie können einen Plan anpassen, indem Sie manuelle Anweisungen und automatisierte Aufgaben hinzufügen. Der Zweck eines Plans besteht darin, den Prozess konsistent, präzise, wiederholbar und automatisiert zu gestalten.

Wenn Sie einen Wiederherstellungsplan erstellen, weisen Sie den Wiederherstellungsgruppen geschützte Server zum Failover zu. Für die Server in jeder Gruppe wird ein gemeinsames Failover ausgeführt. Auf diese Weise können Sie den Failoverprozess in kleinere, einfacher zu verwaltende Einheiten aufteilen, die Servergruppen entsprechen, für die ein Failover ausgeführt werden kann, ohne dass externe Abhängigkeiten zu berücksichtigen sind.

Um die Failoverzeit zu minimieren, sollten Sie beim Erstellen eines Wiederherstellungsplans wie folgt vorgehen:

• Definieren Sie Gruppen mit Azure Stack Hub-VMs, für die ein gemeinsamer Failover ausgeführt werden soll.
• Definieren Sie Abhängigkeiten zwischen Gruppen mit Azure Stack Hub-VMs, um die optimale Reihenfolge eines Failovers zu bestimmen.
• Automatisieren Sie Failoveraufgaben nach Möglichkeit.
• Fügen Sie ggf. benutzerdefinierte manuelle Aktionen ein.

Sie können einen Wiederherstellungsplan definieren und Wiederherstellungsgruppen erstellen, um App-spezifische Eigenschaften zu erfassen. Als Beispiel dient hier eine herkömmliche dreischichtige Anwendung (App) mit einem SQL Server-basierten Back-End, einer Middleware-Komponente und einem Web-Front-End. Wenn Sie einen Wiederherstellungsplan erstellen, können Sie die Startreihenfolge der Server in jeder Schicht steuern, wobei die Server, auf denen SQL Server-Instanzen ausgeführt werden, zuerst online geschaltet werden, gefolgt von den Servern in der Middlewareschicht und danach von den Servern, auf denen das Web-Front-End gehostet wird. Mit dieser Startreihenfolge wird sichergestellt, dass die App ab dem Zeitpunkt funktioniert, zu dem der letzte Computer gestartet wird. Um dies zu implementieren, können Sie einfach einen Wiederherstellungsplan mit drei Wiederherstellungsgruppen erstellen, die Server in den entsprechenden Schichten enthalten.

Zusätzlich zum Steuern von Failover und Startreihenfolge können Sie einem Wiederherstellungsplan Aktionen hinzufügen. Grundsätzlich gibt es zwei Arten von Aktionen:

• Automatisierte Aktion. Eine solche Aktion basiert auf Azure Automation-Runbooks, wobei es um eine von zwei Arten von Aufgaben geht:
  • Bereitstellen und Konfigurieren von Azure-Ressourcen, wozu beispielsweise das Erstellen einer öffentlichen IP-Adresse und deren Zuweisung zu der Netzwerkschnittstelle gehört, die einer Azure-VM zugeordnet ist
  • Ändern der Konfiguration des Betriebssystems und der Anwendungen, die auf einer Azure-VM ausgeführt werden, die nach einem Failover bereitgestellt wurde
• Manuelle Aktion. Eine solche Aktion unterstützt keine Automatisierung und ist in einem Wiederherstellungsplan hauptsächlich zu Dokumentationszwecken enthalten.

Failback zu Azure Stack Hub

In Site Recovery-basierten Szenarios führt Failback, sofern es ordnungsgemäß implementiert ist, nicht zu Datenverlust. Dies bedeutet, dass der Fokus der Failoverstrategie darin besteht, die Failbackzeit (RTO) zu minimieren. Wie bereits erwähnt, können Sie jedoch, wenn Sie ein Failback zu Azure Stack Hub ausführen, nicht auf ihre Wiederherstellungspläne zurückgreifen. Stattdessen erfordert das Failback die folgenden Schritte in der vorliegenden Reihenfolge:

1. Beenden und Freigeben der Azure-VMs in der Notfallwiederherstellungsumgebung
2. Ermitteln der URI-Parameter von jedem der verwalteten Datenträger, die den VMs zugeordnet sind, die Sie herunterladen möchten
3. Herunterladen der VHD-Dateien, die durch die URI-Parameter bestimmt sind, die Sie im vorherigen Schritt ermittelt haben, in Ihre lokale Umgebung
4. Hochladen der VHD-Dateien in Azure Stack Hub
5. Zuordnen der hochgeladenen VHD-Dateien zu neuen oder vorhandenen Azure Stack Hub-VMs
6. Starten der Azure Stack Hub-VMs

Die optimale Vorgehensweise zum Minimieren der Failbackzeit besteht darin, sie zu automatisieren.

Workloadspezifische Überlegungen

Site Recovery ist auf Windows Server-basierte Apps und Rollen abgestimmt, einschließlich SharePoint, Exchange, SQL Server und Active Directory Domain Services (AD DS). Dies ermöglicht es Ihnen, die folgenden Funktionen zu nutzen, um Schutz und Wiederherstellung auf App-Ebene zu implementieren:

• Einbindung in Replikationstechnologien auf App-Ebene, z. B. SQL Server AlwaysOn-Verfügbarkeitsgruppen, Exchange Database Availability Groups (DAGs) und AD DS-Replikation
• App-konsistente Momentaufnahmen für ein- oder mehrschichtige Anwendungen
• Eine umfassende Automatisierungsbibliothek, in der einsatzbereite, anwendungsspezifische Skripts bereitgestellt werden, die heruntergeladen und in Wiederherstellungspläne integriert werden können

Alternativ können Sie workloadspezifische Replikationsmechanismen verwenden, um Resilienz auf Standortebene bereitzustellen. Dies ist eine häufig verwendete Option, wenn Notfallwiederherstellung für AD DS-Domänencontroller, SQL Server oder Exchange implementiert wird, die alle nativ Replikation unterstützen. Obwohl hierfür Azure-VMs bereitgestellt werden müssen, die diese Workloads in der Notfallwiederherstellungsumgebung hosten, wodurch die Kosten erhöht werden, bietet diese Vorgehensweise die folgenden Vorteile:

• Die für Failover und Failback benötigten Zeiten werden verringert.
• Failover auf Workloadebene wird vereinfacht, wodurch Szenarios berücksichtigt werden, in denen Failover auf Standortebene nicht erforderlich sind.

Sicherheit

Die Verwaltung der Notfallwiederherstellung von Benutzer-VM-basierten Workloads in Hybridszenarios erfordert weitere Sicherheitsüberlegungen. Diese Überlegungen können in die folgenden Kategorien unterteilt werden:

• Verschlüsselung während der Übertragung. Dies umfasst die Kommunikation zwischen geschützten Azure Stack Hub-VMs, lokalen Site Recovery-Komponenten und cloudbasierten Site Recovery-Komponenten:

  • Der auf den geschützten VMs installierte Mobilitäts-Agent kommuniziert immer über Transport Layer Security (TLS) 1.2 mit dem Prozessserver.
  • Für die Kommunikation zwischen dem Konfigurationsserver und Azure sowie dem Prozessserver und Azure kann TLS 1.1 oder 1.0 verwendet werden. Um die Sicherheitsstufe für Hybridkonnektivität zu erhöhen, sollten Sie die Verwendung von TLS 1.2 erzwingen.

  Hinweis

  Ausführliche Informationen zum Konfigurieren von TLS 1.2-basierter Verschlüsselung finden Sie unter Registrierungseinstellungen für Transport Layer Security (TLS) und Update zur Aktivierung von TLS 1.1 und TLS 1.2 als sichere Standardprotokolle in WinHTTP unter Windows.

• Verschlüsselung ruhender Daten. Dies umfasst Azure Storage und Azure-VMs am Notfallwiederherstellungsstandort.

  • Azure Storage wird im Ruhezustand für alle Speicherkonten mit 256-Bit-Verschlüsselung gemäß Advanced Encryption Standard verschlüsselt und ist konform zu Federal Information Processing Standard 140-2. Die Verschlüsselung wird automatisch aktiviert und kann nicht deaktiviert werden. Standardmäßig werden für die Verschlüsselung von Microsoft verwaltete Schlüssel verwendet, aber Kunden haben die Möglichkeit, ihre eigenen Schlüssel zu verwenden, die in einem Azure-Schlüsseltresor gespeichert sind.
  • Verwaltete Datenträger von Azure-VMs werden, ebenso wie deren Momentaufnahmen, automatisch verschlüsselt, indem serverseitige Verschlüsselung von verwalteten Azure-Datenträgern verwendet wird, wozu von der Plattform verwaltete Verschlüsselungsschlüssel verwendet werden.

Außerdem können Sie eingeschränkten Zugriff auf die Azure Storage-Konten erzwingen, die Inhalte von Datenträgern hosten, die über Site Recovery repliziert werden. Aktivieren Sie hierzu die verwaltete Identität für den Recovery Services-Tresor, und weisen Sie dieser verwalteten Identität die folgenden über Azure RBAC verwalteten Azure-Rollen auf Azure Storage-Kontoebene zu:

• Resource Manager-basierte Speicherkonten (Standard-Leistungsstufe):
  • Mitwirkender
  • Mitwirkender an Speicherblobdaten
• Resource Manager-basierte Speicherkonten (Premium-Leistungsstufe):
  • Mitwirkender
  • Besitzer von Speicherblobdaten

Der Azure Recovery Services-Tresor bietet Mechanismen, mit denen sein Inhalt zusätzlich geschützt wird. Dazu gehören die folgenden Schutzmaßnahmen:

• Azure RBAC. Diese ermöglicht die Delegierung und Trennung von Zuständigkeiten gemäß dem Prinzip der geringste Rechte. Es gibt drei Site Recovery-bezogene integrierte Rollen, mit denen der Zugriff auf Site Recovery-Vorgänge eingeschränkt werden kann:
  • Site Recovery-Mitwirkender. Diese Rolle hat alle erforderlichen Berechtigungen zum Verwalten von Site Recovery-Vorgängen in einem Azure Recovery Services-Tresor. Ein Benutzer mit dieser Rolle kann den Tresor jedoch nicht erstellen oder löschen und kann anderen Benutzern keine Zugriffsrechte zuweisen. Diese Rolle eignet sich optimal für Administratoren der Notfallwiederherstellung, die die Notfallwiederherstellung für einen Azure Stack Hub-Mandanten aktivieren und verwalten können.
  • Site Recovery-Operator. Diese Rolle hat Berechtigungen zum Ausführen und Verwalten von Failover- und Failbackvorgängen. Ein Benutzer, der über diese Rolle verfügt, kann die Replikation nicht aktivieren oder deaktivieren, keine Tresore erstellen oder löschen, keine neue Infrastruktur registrieren oder anderen Benutzern keine Zugriffsrechte zuweisen. Diese Rolle eignet sich optimal für einen Notfallwiederherstellung-Operator, der Failover für Azure Stack Hub-VM ausführen kann, wenn er dazu vom Besitzer der Anwendung oder IT-Administratoren in einem tatsächlichen oder simulierten Notfallszenario angewiesen wird.
  • Site Recovery-Leser. Diese Rolle hat Berechtigungen zum Nachverfolgen aller Site Recovery-Verwaltungsvorgänge. Diese Rolle eignet sich optimal für IT-Mitarbeiter, die für das Überwachen des Zustands geschützter Azure Stack Hub-VMs und ggf. das Auslösen von Supporttickets zuständig sind.
• Azure-Ressourcensperren. Sie haben die Möglichkeit, Schreibschutz- und Löschsperren für einen Site Recovery-Tresor zu erstellen und zuzuweisen, um das Risiko zu mindern, dass der Tresor versehentlich oder böswillig geändert oder gelöscht wird.
• Vorläufiges Löschen. Der Zweck von vorläufigem Löschen besteht darin, den Tresor und seine Daten vor versehentlichen oder schädlichen Löschvorgängen zu schützen. Bei Verwendung von vorläufigem Löschen werden alle gelöschten Inhalte 14 weitere Tage aufbewahrt, sodass sie während dieses Zeitraums abgerufen werden können. Die zusätzliche 14-tägige Aufbewahrung von Tresorinhalten verursacht keinerlei Kosten. Vorläufiges Löschen ist standardmäßig aktiviert.
• Schutz von sicherheitsrelevanten Vorgängen. Der Azure Recovery Services-Tresor ermöglicht es Ihnen, eine zusätzliche Authentifizierungsebene für den Fall zu aktivieren, dass ein sicherheitsbezogener Vorgang, z. B. Deaktivieren von Schutz, versucht wird. Mit dieser zusätzlichen Prüfung lässt sich sicherstellen, dass solche Vorgänge von autorisierten Benutzern ausgeführt werden.
• Überwachung von und Warnungen zu verdächtigen Aktivitäten. Azure Recovery Services bietet integrierte Überwachung von und Warnungen zu sicherheitsrelevanten Ereignissen, die Tresorvorgänge betreffen.

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

Hinsichtlich der Kosten der Site Recovery-basierten Notfallwiederherstellungslösung, die in diesem Artikel beschrieben ist, müssen Sie sowohl die lokalen als auch die cloudbasierten Komponenten berücksichtigen. Im Azure Stack Hub-Preismodell ist die Preisgestaltung für lokale Komponenten festgelegt. Wie bei Azure gibt es für Azure Stack Hub eine Vereinbarung zur nutzungsbasierten Abrechnung, die über Enterprise Agreement und das Cloud Solution Provider-Programm verfügbar ist. Diese Vereinbarung umfasst einen monatlichen Preis für jede Windows Server-VM. Wenn Sie die Möglichkeit haben, vorhandene Windows Server-Lizenzen zu nutzen, können Sie die Kosten erheblich auf den Preis einer Basis-VM verringern. Mit Site Recovery benötigen Sie allerdings in der Regel pro Mandant nur eine einzige Azure Stack Hub-VM, die dazu erforderlich ist, den mandantenspezifischen Konfigurationsserver zu implementieren.

Azure-bezogene Gebühren fallen an, wenn die folgenden Ressourcen verwendet werden:

• Azure Recovery Services. Die Preise richten sich nach der Anzahl der geschützten Instanzen. Zu Ihrem Vorteil gilt, dass für jede geschützte Instanz in den ersten 31 Tagen keine Site Recovery-Gebühren anfallen.

• Azure Storage. Die Preise ergeben sich aus der Kombination der folgenden Faktoren:

  • Leistungsstufe
  • Menge der gespeicherten Daten
  • Menge der übertragenen ausgehenden Daten
  • Menge und Typen der ausgeführten Vorgänge (nur für die Standard-Leistungsstufe)
  • Datenredundanz (nur für die Standard-Leistungsstufe)

• Azure ExpressRoute. Die Preise basieren auf einem von zwei Modellen:

  • Datenflatrate. Dieses Modell beinhaltet eine monatliche Gebühr, die alle Übertragungen von eingehenden und ausgehenden Daten umfasst.
  • Volumentarif. Dieses Modell beinhaltet eine monatliche Gebühr, bei der alle Übertragungen eingehender Daten kostenlos sind und Übertragungen ausgehender Daten pro GB abgerechnet werden.

  Hinweis

  In dieser Abschätzung sind keine Kosten physischer Verbindungen enthalten, die von anderen Verbindungsanbietern bereitgestellt werden.

• Azure-VMs. Die Preise für Azure-VMs ergeben sich als Kombination von zwei Komponenten:

  • Computekosten. Die Kosten werden durch die VM-Größe, die Betriebszeit der VM und das Lizenzierungsmodell des Betriebssystems bestimmt.
  • Kosten eines verwalteten Datenträgers. Die Datenträgergröße und die Leistungsstufe bestimmen die Kosten.

  Hinweis

  Beachtenswert ist, dass Hydration bewirkt, dass Azure-VMs nicht während normaler Geschäftsvorgänge ausgeführt werden müssen, bei denen Workloads auf Azure Stack Hub ausgeführt werden. Dadurch werden die Computekosten von Site Recovery-basierten Implementierungen erheblich verringert, insbesondere im Vergleich zu herkömmlichen Notfallwiederherstellungslösungen.

  Hinweis

  Die Preise für Ressourcen variieren zwischen Azure-Regionen.

  Hinweis

  Ausführliche Informationen zu den Preisen finden Sie unter Azure-Preise.

Optimaler Betrieb

Die Säule „Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie unter Übersicht über die Säule „Optimaler Betrieb“.

Zu den Hauptüberlegungen hinsichtlich der Verwaltbarkeit von Site Recovery-basierter Notfallwiederherstellung von Azure Stack Hub-VMs gehören:

• Implementierung von Site Recovery auf Azure Stack Hub
• Failover- und Failbackvorgänge
• Delegierung von Rollen und Zuständigkeiten
• DevOps

Implementierung von Site Recovery auf Azure Stack Hub

Wenn Sie Site Recovery auf Azure Stack Hub in einer kleinen oder mittelgroßen Einzelmandantenumgebung implementieren möchten, können Sie entsprechend dem manuellen Bereitstellungsprozess vorgehen, der in der grafischen Oberfläche des Recovery Services-Tresors im Azure-Portal angeboten wird. Für eine mehrinstanzenfähige Implementierung bietet es sich an, Teile des Implementierungsprozesses zu automatisieren, da Sie für jeden Mandanten (Instanz) in der Regel eine eigene Konfigurationsserver-VM und einen eigenen Recovery Services-Tresor einrichten müssen. Sie haben auch die Möglichkeit, die Bereitstellung des Mobilitäts-Agents zu automatisieren, indem Sie so vorgehen, wie dies unter Vorbereiten des Quellcomputers für die Pushinstallation des Mobilitäts-Agents beschrieben ist.

Failover- und Failbackvorgänge

Um die Verwaltung von Failover zu vereinfachen, bietet es sich an, Wiederherstellungspläne für alle geschützten Workloads zu implementieren. Weitere Informationen finden Sie im Abschnitt Zuverlässigkeit weiter oben in diesem Artikel. Sie finden auch Empfehlungen zum Optimieren der Verwaltung des Failbackverfahrens.

Delegierung von Rollen und Zuständigkeiten

Erfolgt das Planen für und Implementieren von Notfallwiederherstellung von Azure Stack Hub-VM-basierten Workloads über Site Recovery, bedeutet dies üblicherweise die Zusammenarbeit von Projektbeteiligten:

• Azure Stack Hub-Operatoren verwalten die Azure Stack Hub-Infrastruktur, wobei sie sicherstellen, dass ausreichend Compute-, Speicher- und Netzwerkressourcen verfügbar sind, um eine umfassende Notfallwiederherstellungslösung implementieren zu können, und diese Ressourcen für Mandanten verfügbar machen. Sie arbeiten außerdem mit Anwendungs- und Datenbesitzern zusammen, um mit ihnen die optimale Vorgehensweise zu ermitteln, wie deren Workloads auf Azure Stack Hub bereitgestellt werden können.
• Azure-Administratoren verwalten Azure-Ressourcen, die für die Implementierung von hybriden Notfallwiederherstellungslösungen erforderlich sind.
• Microsoft Entra-Administrator*innen verwalten Microsoft Entra-Ressourcen, einschließlich Benutzer- und Gruppenobjekten, die für das Bereitstellen, Konfigurieren und Verwalten von Azure-Ressourcen verwendet werden.
• IT-Personal eines Azure Stack Hub-Mandanten entwirft, implementiert und verwaltet Site Recovery-Implementierungen, einschließlich Failover und Failback.
• Azure Stack Hub-Benutzer müssen RPO- und RTO-Anforderungen bereitstellen sowie Anforderungen übermitteln, um eine Notfallwiederherstellung für ihre Workloads zu implementieren.

Sorgen Sie für Klarheit hinsichtlich der Rollen und Aufgaben von Anwendungsbesitzern und Operatoren in puncto Schutz und Wiederherstellung. Benutzer sind für den Schutz der virtuellen Computer zuständig. Operatoren sind für den Betriebszustand der Azure Stack Hub-Infrastruktur verantwortlich.

DevOps

Während für das Konfigurieren von Wiederherstellung auf VM-Ebene über Site Recovery hauptsächlich die jeweilige IT-Abteilung zuständig ist, gibt es einige DevOps-spezifische Überlegungen, die in einer umfassenden Strategie für die Notfallwiederherstellung berücksichtigt werden sollten. Azure Stack Hub unterstützt Implementieren von Infrastructure-as-Code (IaC), was die automatisierte Bereitstellung einer Vielzahl von Workloads umfasst, einschließlich VM-basierter Anwendungen und Dienste. Sie können diese Funktionalität nutzen, um die Bereitstellung von Site Recovery-basierten Notfallwiederherstellungsszenarios zu optimieren, wodurch die erste Einrichtung in Szenarios mit mehreren Mandanten vereinfacht wird.

Beispielsweise können Sie dieselben Azure Resource Manager-Vorlagen verwenden, um sämtliche Netzwerkressourcen, die für die Unterstützung von VM-basierten Workloads in einem Azure Stack Hub-Stempel für Ihre Anwendung erforderlich sind, in einem einzigen, koordinierten Vorgang bereitzustellen. Sie können dieselbe Vorlage verwenden, um einen passenden Satz von Ressourcen in Azure bereitzustellen, um einen Notfallwiederherstellungsstandort bereitzustellen. Um die Unterschiede zwischen den beiden Umgebungen zu berücksichtigen, können Sie für jeden Fall einfach unterschiedliche Werte für die Vorlagenparameter angeben.

Effiziente Leistung

Leistungseffizienz ist die Fähigkeit Ihrer Workload, auf effiziente Weise eine den Anforderungen der Benutzer entsprechende Skalierung auszuführen. Weitere Informationen finden Sie unter Übersicht über die Säule „Leistungseffizienz“.

Wenn Sie planen, Site Recovery auf Azure Stack Hub bereitzustellen, müssen Sie den Umfang der Verarbeitungs-, Speicher- und Netzwerkressourcen berücksichtigen, die den Konfigurations- und Prozessservern zugeordnet sind. Möglicherweise müssen Sie die geschätzte Größe der Azure Stack Hub-VM, die die Site Recovery-Komponenten hostet, nach der Bereitstellung anpassen, um Änderungen an den Verarbeitungs- oder Speicheranforderungen zu berücksichtigen. Sie haben drei grundlegende Optionen zum Anpassen der Größe:

• Implementieren von vertikaler Skalierung. Dies umfasst das Ändern von Umfang und Art der Prozessor-, Arbeitsspeicher- und Datenträgerressourcen der Azure Stack Hub-VM, die den Konfigurationsserver samt Prozessserver hostet. Um die Ressourcenanforderungen zu schätzen, können Sie die Informationen aus der folgenden Tabelle verwenden:

  Tabelle 1: Größenanforderungen für den Konfigurations- und den Prozessserver

  CPU	Arbeitsspeicher	Cachedatenträger	Datenänderungsrate	Geschützte Computer
  8 vCPUs 2 Sockets * 4 Kerne @ 2,5 GHz	16 GB	300 GB	500 GB oder weniger	< 100 Computer
  12 vCPUs 2 Sockets * 6 Kerne @ 2,5 GHz	18 GB	600 GB	500 GB bis 1 TB	100 bis 150 Computer
  16 vCPUs 2 Sockets * 8 Kerne @ 2,5 GHz	32 GB	1 TB	1 - 2 TB	150 - 200 Computer

• Implementieren von horizontaler Skalierung. Dies umfasst das Bereitstellen oder das Aufheben der Bereitstellung von Azure Stack Hub-VMs mit dem Prozessserver, der installiert wurde, um die Verarbeitungsanforderungen von geschützten Azure Stack Hub-VMs zu erfüllen. Allgemein gilt: Wenn Sie Ihre Bereitstellung auf mehr als 200 Quellcomputer hochskalieren müssen oder Ihre gesamte tägliche Änderungsrate zwei Terabyte (TB) übersteigt, benötigen Sie zusätzliche Prozessserver, um den Replikationsdatenverkehr bewältigen zu können. Informationen zum Schätzen von Anzahl und Konfiguration zusätzlicher Prozessserver finden Sie unter Empfohlene Größen für den Prozessserver.

• Ändern der Replikationsrichtlinien. Hierzu gehört das Ändern von Parametern der Replikationsrichtlinien, wobei der Fokus auf App-konsistenten Momentaufnahmen liegt.

Aus Sicht des Netzwerks gibt es verschiedene Methoden, um die Bandbreite anzupassen, die für den Replikationsdatenverkehr verfügbar ist:

• Ändern der VM-Größe. Die Größe der Azure Stack Hub-VMs bestimmt die maximale Netzwerkbandbreite. Es sei jedoch darauf hingewiesen, dass es keine Bandbreitengarantien gibt. Stattdessen können VMs die verfügbare Bandbreite bis zu dem Grenzwert nutzen, der durch ihre Größe bestimmt ist.

• Ersetzen von Uplinkswitches. Azure Stack Hub-Systeme unterstützen eine Reihe von Hardwareswitches, wodurch mehrere Uplinkgeschwindigkeiten zur Auswahl stehen. Jeder Azure Stack Hub-Clusterknoten hat zur Fehlertoleranz zwei Uplinks zur Oberseite von Rackswitches. Das System ordnet die Hälfte der Uplinkkapazität für die kritische Infrastruktur zu. Der Rest ist gemeinsam genutzte Kapazität für Azure Stack Hub-Dienste und den gesamten Benutzerdatenverkehr. Für Systeme, die mit höheren Geschwindigkeiten bereitgestellt werden, ist mehr Bandbreite für den Replikationsdatenverkehr verfügbar.

  Hinweis

  Obwohl es möglich ist, den Netzwerkdatenverkehr dadurch zu trennen, dass einem Server ein zweiter Netzwerkadapter zugeordnet wird, wird für Azure Stack Hub-VMs für den gesamten VM-Datenverkehr ins Internet derselbe Uplink verwendet. Ein zweiter virtueller Netzwerkadapter führt nicht dazu, dass Datenverkehr auf physischer Transportebene getrennt wird.

• Ändern des Durchsatzes der Netzwerkverbindung mit Azure. Um größere Mengen an Replikationsdatenverkehr zu verarbeiten, bietet es sich an, Azure ExpressRoute mit Microsoft-Peering für Verbindungen zwischen virtuellen Azure Stack Hub-Netzwerken und Azure Storage zu nutzen. Azure ExpressRoute erweitert lokale Netzwerke über eine von einem Konnektivitätsanbieter bereitgestellte private Verbindung in die Microsoft-Cloud. Sie können ExpressRoute-Verbindungen für ein breites Angebot von Bandbreiten von 50 Megabits pro Sekunde (MBit/s) bis 100 Gigabits pro Sekunde erwerben.

  Hinweis

  Ausführliche Informationen über das Implementieren von Azure ExpressRoute in Azure Stack Hub-Szenarios finden Sie unter Herstellen einer Verbindung von Azure Stack Hub mit Azure mithilfe von Azure ExpressRoute.

• Ändern der Drosselung des Replikationsdatenverkehrs auf dem Prozessserver. Sie können über die grafische Benutzeroberfläche des Microsoft Azure Recovery Services-Agents steuern, wie viel Bandbreite für den Replikationsdatenverkehr auf den VMs verwendet wird. Zu den unterstützten Funktionen gehört das Festlegen der Grenzwerte für Arbeitszeiten und arbeitsfreie Zeiten, wobei die Bandbreitenwerte zwischen 512 KBit/s und 1,023 MBit/s liegen. Alternativ können Sie dieselbe Konfiguration anwenden, indem Sie das PowerShell-Cmdlet Set-OBMachineSetting verwenden.

• Ändern der Netzwerkbandbreite, die pro geschützter VM zugewiesen ist, auf dem Prozessserver. Um dies zu erreichen, ändern Sie den Wert des Eintrags UploadThreadsPerVM im Schlüssel HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure Backup\Replication. Standardmäßig ist der Wert auf 4 festgelegt, aber Sie können ihn auf 32 erhöhen, wenn genügend Netzwerkbandbreite verfügbar ist.

Bereitstellen dieses Szenarios

Voraussetzungen

Eine Implementierung der empfohlenen Lösung ist nur möglich, wenn die folgenden Voraussetzungen erfüllt sind:

• Zugriff auf ein Azure-Abonnement, für das Berechtigungen vorliegen, die dazu ausreichen, alle Cloudkomponenten der Site Recovery Komponenten bereitzustellen und zu verwalten. Dazu gehören:

  • Der Azure Recovery Services-Tresor in der Azure-Region, die als Notfallwiederherstellungsstandort für die Azure Stack Hub-Produktionsumgebung zugeordnet ist
  • Ein Azure Storage-Konto, mit dem der Inhalt von replizierten Datenträgern von Azure Stack Hub-VMs gehostet wird
  • Ein virtuelles Azure-Netzwerk, das die Notfallwiederherstellungsumgebung darstellt, mit der über Hydration bereitgestellte Azure-VMs nach einem geplanten oder ungeplanten Failover verbunden werden
  • Ein isoliertes virtuelles Azure-Netzwerk, das die Testumgebung darstellt, mit der über Hydration bereitgestellte Azure-VMs nach einem Testfailover verbunden werden
  • Eine Azure ExpressRoute-basierte Konnektivität zwischen der lokalen Umgebung, virtuellen Azure-Netzwerken und dem Azure Storage-Konto, das zum Hosten von Kopien von VHD-Dateien mit Inhalten verwendet wird, die von Datenträgern geschützter Azure Stack Hub-VMs repliziert werden

• Ein Azure Stack Hub-Benutzerabonnement. Alle Azure Stack Hub-VMs, die durch einen einzelnen Site Recovery-Konfigurationsserver geschützt werden, müssen zum selben Azure Stack Hub-Benutzerabonnement gehören.

• Ein virtuelles Azure Stack Hub-Netzwerk. Alle geschützten VMs müssen eine direkte Verbindung mit den VMs haben, auf denen die Prozessserverkomponente gehostet wird (standardmäßig ist dies die Konfigurationsserver-VM).

• Eine Azure Stack Hub-VM mit Windows Server, auf der der Konfigurationsserver und ein Prozessserver gehostet werden. Die VM muss zum selben Abonnement gehören und demselben virtuellen Netzwerk zugeordnet sein wie die Azure Stack Hub-VMS, die geschützt werden müssen. Zusätzlich muss für die VM Folgendes zutreffen:

  • Sie muss den Software- und Hardwareanforderungen eines Site Recovery-Konfigurationsservers entsprechen.
  • Sie muss die Netzwerkanforderungen für externe Konnektivität erfüllen.

  Hinweis

  Weitere Speicher- und Leistungsüberlegungen für die Konfigurations- und Prozessserver sind weiter unten in diesem Architekturdokument ausführlicher beschrieben.

  • Sie muss Anforderungen hinsichtlich der internen Konnektivität erfüllen. Insbesondere müssen Azure Stack Hub-VMs, die Sie schützen möchten, mit folgenden Servern kommunizieren können:

    • Mit dem Konfigurationsserver über den TCP-Port 443 (HTTPS) eingehend zur Replikationsverwaltung
    • Mit dem Prozessserver über den TCP-Port 9443, um Replikationsdaten zu übermitteln.

    Hinweis

    Sie können den Port, der vom Prozessserver für externe und interne Konnektivität verwendet wird, bei dessen Konfiguration ändern, wenn Sie Site Recovery Unified Setup ausführen.

• Zu schützende Azure Stack Hub-VMs mit einem der unterstützten Betriebssysteme. Um Azure Stack Hub-VMs zu schützen, auf denen ein Windows Server-Betriebssystem ausgeführt wird, müssen Sie folgende Schritte ausführen:

  • Sie müssen ein Windows-Konto mit Administratorrechten erstellen. Sie können dieses Konto angeben, wenn Sie Site Recovery auf diesen VMs aktivieren. Der Prozessserver verwendet dieses Konto, um den Site Recovery-Mobilitätsdienst zu installieren. In einer Arbeitsgruppenumgebung müssen Sie die Remotebenutzer-Zugriffssteuerung in Windows Server-Zielbetriebssystemen deaktivieren, indem Sie den Wert des DWORD-Registrierungseintrags LocalAccountTokenFilterPolicy im Schlüssel HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System auf „1“ festlegen.
  • Sie müssen Regeln für „Datei- und Druckerfreigabe“ und „Windows-Verwaltungsinstrumentation“ in Microsoft Defender Firewall aktivieren.

• Um Azure Stack Hub-VMs zu schützen, auf denen Linux-Betriebssysteme ausgeführt werden, müssen Sie folgende Schritte ausführen:

  • Sie müssen ein Root-Benutzerkonto erstellen. Sie können dieses Konto angeben, wenn Sie Site Recovery auf diesen VMs aktivieren. Der Prozessserver verwendet dieses Konto, um den Site Recovery-Mobilitätsdienst zu installieren.
  • Sie müssen die neuesten openssh-, openssh-server- und openssl-Pakete installieren.
  • Sie müssen den Secure Shell-Port (SSH-Port) 22 aktivieren und ausführen.
  • Sie das Subsystem für sicheres FTP und die Kennwortauthentifizierung aktivieren.

Grundsätzliche Implementierungsschritte

Im Grundsatz besteht die Implementierung einer Site Recovery-basierten Notfallwiederherstellung auf Azure Stack Hub aus den folgenden Phasen:

1. Vorbereiten der Azure Stack Hub-VMs, die durch Site Recovery geschützt werden sollen. Stellen Sie sicher, dass die VMs die Site Recovery-Voraussetzungen erfüllen, die im vorherigen Abschnitt aufgeführt sind.

2. Erstellen und Konfigurieren eines Azure Recovery Services-Tresors. Richten Sie einen Azure Recovery Services-Tresor ein, und geben Sie an, was Sie replizieren möchten. Site Recovery-Komponenten und -Aktivitäten werden über den Tresor konfiguriert und verwaltet.

3. Einrichten der Quellreplikationsumgebung. Stellen Sie einen Site Recovery-Konfigurationsserver und -Prozessserver bereit, indem Sie die Site Recovery Unified Setup-Binärdateien installieren, und registrieren Sie den Server im Tresor.

   Hinweis

   Sie können Site Recovery Unified Setup erneut ausführen, um weitere Prozessserver auf Azure Stack Hub-VMs zu implementieren.

4. Einrichten der Replikationszielumgebung. Wählen Sie in der Azure-Region, in der der Notfallwiederherstellungsstandort gehostet wird, ein Azure Storage-Konto und ein virtuelles Azure-Netzwerk aus, oder erstellen Sie dort ein solches Konto und Netzwerk. Während der Replikation wird der Inhalt der Datenträger für die geschützten Azure Stack Hub-VMs in das Azure Storage Konto kopiert. Während eines Failovers stellt Site Recovery automatisch Azure-VMs bereit, die als Replikate geschützter Azure Stack Hub-VMs fungieren, und verbindet diese mit dem virtuellen Azure-Netzwerk.

5. Aktivieren der Replikation. Konfigurieren Sie Replikationseinstellungen, und aktivieren Sie die Replikation für Azure Stack Hub-VMs. Der Mobilitätsdienst wird automatisch auf jeder Azure Stack Hub-VM installiert, für die Replikation aktiviert ist. Site Recovery initiiert die Replikation jeder Azure Stack Hub-VM gemäß den von Ihnen definierten Richtlinieneinstellungen.

6. Ausführen eines Testfailovers. Sobald die Replikation eingerichtet ist, vergewissern Sie sich, dass das Failover erwartungsgemäß funktioniert. Dazu führen Sie ein Testfailover aus.

7. Ausführen eines geplanten oder ungeplanten Failovers. Nach einem erfolgreichen Testfailover können Sie entweder ein geplantes oder ungeplantes Failover zu Azure ausführen. Sie können bestimmen, welche Azure Stack Hub-VMs in das Failover einbezogen werden sollen.

8. Ausführen eines Failbacks. Wenn Sie ein Failback ausführen möchten, beenden Sie die Azure-VMs, die den Azure Stack Hub-VMs entsprechen, für die Sie das Failover ausgeführt haben, laden deren Datenträgerdateien in lokalen Speicher herunter, laden diese Dateien in Azure Stack Hub hoch und ordnen sie einer vorhandenen oder neuen VM zu.

Zusammenfassung

Zusammenfassend lässt sich sagen, dass der Azure Stack Hub ein einzigartiges Angebot ist, das sich in vielen Aspekten von anderen Virtualisierungsplattformen unterscheidet. Als solches rechtfertigt es spezielle Überlegungen hinsichtlich der Geschäftskontinuitätsstrategie für seine Workloads. Durch die Nutzung von Azure-Diensten können Sie das Entwerfen und Implementieren dieser Strategie vereinfachen. In diesem Architekturreferenzartikel wird erläutert, wie Microsoft Site Recovery verwendet werden kann, um Azure Stack Hub-VM-basierte Workloads im verbundenen Bereitstellungsmodell zu schützen. Diese Vorgehensweise ermöglicht es Kunden, von der Resilienz und Verwaltbarkeit von Azure Stack Hub und von der Hyperskalierung (Hyperscale) und globalen Präsenz der Azure-Cloud zu profitieren.

Es ist unbedingt zu beachten, dass die hier beschriebene Notfallwiederherstellungslösung ausschließlich auf VM-basierte Workloads von Azure Stack Hub ausgerichtet ist. Diese ist nur ein Bestandteil einer Gesamtstrategie für Geschäftskontinuität, für die andere Azure Stack Hub-Workloadtypen und -Szenarios berücksichtigt werden sollten, die sich auf ihre Verfügbarkeit auswirken.

Nächste Schritte

Produktdokumentation:

• Informationen zu Azure Site Recovery
• Übersicht über Azure Stack Hub
• Was ist Microsoft Entra ID?
• Was ist Azure-Blobspeicher?
• Was ist Azure ExpressRoute?
• Was ist Azure Virtual Network?

Microsoft Learn-Module:

• Azure Stack Hub
• Konfigurieren von Microsoft Entra ID
• Konfigurieren von Speicherkonten
• Konfigurieren virtueller Netzwerke
• Entwerfen und Implementieren von Azure ExpressRoute
• Entwerfen eine Sitewiederherstellungslösung in Azure

Zugehörige Ressourcen

• Entwurf einer Hybridarchitektur
• Sichern von Dateien und Anwendungen in Azure Stack Hub
• Hybridverbindungen
• Hybride Dateifreigabe mit Notfallwiederherstellung für Mitarbeiter an Remote- und lokalen Standorten