Kapazitätsplanung mit Azure Site Recovery
Als organization ist es unerlässlich, eine BCDR-Strategie (Business Continuity and Disaster Recovery) einzuführen, die Ihre Daten sicher, Apps und Workloads online hält, während geplanter und ungeplanter Ausfälle.
Durch die Replikation von Workloads virtueller Computer (VMs) von einem primären Standort an einen sekundären Standort bietet Azure Site Recovery in Azure Stack Hub Dienste, die die Sicherheit von Organisationsdaten, Die Verfügbarkeit von Anwendungen und Workloads bei Ausfällen unterstützen können. Wenn beispielsweise an Ihrem primären Standort ein Ausfall auftritt, führen Sie ein Failover zu einem sekundären Standort aus, um auf Ihre Apps zuzugreifen. Sobald der primäre Standort wieder ausgeführt wird, können Sie einen Failover ausführen. Weitere Informationen finden Sie unter Informationen zu Azure Site Recovery.
Um die Replikation von VMs über zwei Azure Stack Hub-Stempel hinweg zu ermöglichen, konfigurieren Sie zwei Umgebungen:
-
Quellumgebung :
- Der Azure Stack Hub-Stempel, in dem Mandanten-VMs ausgeführt werden.
-
Zielumgebung :
- Hier wird der Azure Site Recovery-Ressourcenanbieter ausgeführt.
Eine wesentliche Komponente für den Erfolg eines Plans zur Geschäftskontinuität und Notfallwiederherstellung ist die Kapazitätsplanung. Bei der Kapazitätsplanung sind einige Faktoren zu berücksichtigen:
Wiederherstellungszeitziele (Recovery Time Objectives, RTO) und Wiederherstellungspunktziele (Recovery Point Objectives, RPO) für die spezifischen Workloads, die Sie schützen möchten.
Workloads und die Anwendungsmerkmale:
- Wie oft sich die Daten innerhalb der jeweiligen VM ändern.
- Wie viele Daten werden generiert oder entfernt?
- Wie sieht das Anwendungsdesign aus und mehr?
VM-Größen, die Anzahl der Datenträger und die Art, wie jede VM an andere VMs gebunden ist.
- Für Lösungen, die mehrere VMs erfordern, sollten Sie wissen, in welcher Reihenfolge diese VMs gestartet werden müssen.
Netzwerkbandbreite zwischen Quell- und Zielumgebungen. Diese Komponente kann sich auf RPOs auswirken.
Jeder dieser Punkte ist wichtig und hat weitreichende Auswirkungen beim Erstellen eines BCDR-Plans.
In den folgenden Abschnitten werden die Standard Punkte aufgeführt, die aus der Perspektive von Azure Site Recovery zu berücksichtigen sind. Jeder BCDR-Plan ist unterschiedlich und basiert auf den Besonderheiten der Workloads, die Sie schützen möchten. Daher ist diese Liste nicht umfassend.
Quellenüberlegungen
In der Quellumgebung führt Azure Stack Hub die Azure Site Recovery VM Anwendung aus. Die VM ist eine Standard_DS4_v2 -VM (8 vCPUs, 28 GB Arbeitsspeicher, 32 Datenträger), die im Azure Stack Hub-Benutzerabonnement ausgeführt wird.
Berücksichtigen Sie in der Quellumgebung die folgenden Bereiche:
Quota:
- Sie sollten über ein ausreichendes Kontingent zum Erstellen der Azure Site Recovery VM Anwendung verfügen. Je nach Gesamtplan benötigen Sie einen oder mehrere.
Speicher für die Azure Site Recovery-VM-Anwendung:
Die Azure Site Recovery VM Anwendung selbst verfügt über die Datenanforderungen, die durch die VM-Größe definiert sind.
Stellen Sie beim Planen der Kapazität sicher, dass die Anwendung VM über genügend Speicherplatz verfügt, um die Failback- und erneut schützenden Mechanismen auszuführen.
Hinweis
Wenn Speichereinschränkungen vorhanden sind, kann das Failback und der erneute Schutz mit der Fehlermeldung Ein interner Fehler aufgetreten fehlschlagen . Benutzer sollten die Ereignisprotokolle auf dem Anwendung überprüfen, um den tatsächlichen Azure Resource Manager-Fehler zu bestätigen. Weitere Informationen finden Sie unter Bekannte Probleme für Azure Site Recovery.
Bandbreite:
- Bei der ersten Replikation wird eine hohe Bandbreitennutzung generiert.
- Änderungen auf den einzelnen virtuellen Computern werden je nach Replikationsrichtlinien und Anwendungstyp repliziert.
Zielüberlegungen
In der Zielumgebung müssen zwei Elemente für die Kapazitätsplanung berücksichtigt werden:
Die Azure Site Recovery-Dienstanforderungen: Wie viel für die Ausführung von Azure Site Recovery verbraucht wird, ohne notwendigerweise Workloads zu schützen.
Die Anforderungen für geschützte Workloads.
Für die Zielumgebung muss für jeden Site Recovery Anwendung ein Azure Site Recovery-Tresor erstellt werden, um VMs vor der Quelle zu schützen (ein Anwendung pro Tresor). Obwohl dies aus Kapazitätssicht keine Einschränkung darstellt, sollte dies bei der Planung des Entwurfs der Gesamtumgebung berücksichtigt werden.
Azure Site Recovery RP-Ressourcen
Für die Installation von Azure Site Recovery in Azure Stack Hub müssen Sie den Site Recovery Resource Provider (RP) installieren.
Hinweis
Mit Microsoft.SiteRecovery-1.2301.2216.2287 erfordert Azure Site Recovery in Azure Stack Hub keine Event Hubs als Abhängigkeit.
Dieser Dienst wird im Azure Stack Hub-Administratorabonnement erstellt und von Azure Stack Hub selbst verwaltet, daher ist keine Konfiguration erforderlich. Wie bei jedem Dienst verbrauchen diese Ressourcen jedoch Arbeitsspeicher und Speicher und verfügen über bestimmte vCPUs:
| Dienst | Virtueller Kern | Arbeitsspeicher | Datenträgergröße |
|---|---|---|---|
| Azure Site Recovery | 12 | 42 GB | 1,4 TB |
Hinweis
Diese Ressourcen sind Azure Stack Hub-Dienste auf der Verwaltungsseite von Azure Stack Hub. Nach der Installation verwaltet die Plattform diese Ressourcen.
Geschützte Arbeitsauslastungen
Berücksichtigen Sie beim Erstellen des BCDR-Plans alle Aspekte der geschützten Workloads. Die folgende Liste ist nicht vollständig und sollte als Ausgangspunkt behandelt werden:
VM-Größe, Anzahl der Datenträger, Datenträgergröße, IOPS, Datenänderung und neu erstellte Daten.
Überlegungen zur Netzwerkbandbreite:
- Die Netzwerkbandbreite, die für die Deltareplikation erforderlich ist.
- Die Menge des Durchsatzes in der Zielumgebung, die Azure Site Recovery aus der Quellumgebung abrufen kann.
- Die Anzahl der VMs, die gleichzeitig als Batch zu verwenden sind. Diese Zahl basiert auf der geschätzten Bandbreite, um die erste Replikation in einem bestimmten Zeitraum abzuschließen.
- Der RPO, der für eine bestimmte Bandbreite erreicht werden kann.
- Die Auswirkung auf den gewünschten RPO, wenn eine geringere Bandbreite bereitgestellt wird.
Speicherüberlegungen:
- Wie viele Daten für die erste Replikation erforderlich sind.
- Wie viele Wiederherstellungspunkte gehalten werden und wie sich die Daten für jede geschützte VM in diesen Intervallen erhöhen.
- Wie viele Kontingente müssen den Azure Stack Hub-Zielbenutzerabonnements zugewiesen werden, damit Benutzer über eine ausreichende Zuordnung verfügen.
- Das Cachespeicherkonto für die Replikation.
Computeüberlegungen:
- Beim Failover werden die VMs für die Azure Stack Hub-Zielbenutzerabonnements gestartet. Es muss genügend Kontingentzuweisung vorhanden sein, um diese VM-Ressourcen starten zu können.
- Wenn der geschützte virtuelle Computer während des Schutzes der VM in der Quellumgebung aktiv ist, werden keine VM-bezogenen Ressourcen wie vCPU, Arbeitsspeicher usw. in der Zielumgebung verbraucht. Diese Ressourcen werden nur während eines Failoverprozesses wie testfailover relevant.
Für den Bereich von Azure Site Recovery in Azure Stack Hub ist hier ein Ausgangspunkt für Berechnungen, insbesondere für das verwendete Cachespeicherkonto:
Wenn ein Failover vorliegt, multiplizieren Sie während des normalen Betriebs die Anzahl der replizierten Datenträger mit dem durchschnittlichen RPO. Beispielsweise können Sie (2 MB * 250s) haben. Das Cachespeicherkonto beträgt normalerweise einige KB bis 500 MB pro Datenträger.
Wenn ein Failover vorliegt, multiplizieren Sie bei einem Worst-Case-Szenario die Anzahl der replizierten Datenträger mit dem durchschnittlichen RPO über einen ganzen Tag.
Wichtig
Wenn einige Teile von Azure Site Recovery nicht funktionieren, andere jedoch funktionieren, kann es höchstens einen Tag Difflog im Speicherkonto geben, bevor Azure Site Recovery sich für ein Timeout entscheidet.
Failback auf den neuen virtuellen Computer. Berechnen Sie die Summe der Datenträgergröße jedes Batches.
- Der gesamte Datenträger muss in das Cachespeicherkonto kopiert werden, damit die Ziel-VM angewendet werden kann, da das Ziel ein leerer Datenträger ist.
- Die zugeordneten Daten werden nach dem Kopieren gelöscht, es wird jedoch wahrscheinlich eine Spitzenauslastung mit der Summe aller Datenträgergrößen angezeigt.
Erstellen Sie den BDCR-Plan basierend auf den Besonderheiten der Lösung, die Sie schützen möchten.
Die folgende Tabelle enthält ein Beispiel für Tests, die in unseren Umgebungen ausgeführt werden. Sie können diese Erkenntnisse verwenden, um eine Baseline für Ihre eigene Anwendung zu erhalten, aber jede Workload unterscheidet sich:
Konfiguration
| Blockgröße | Durchsatz/Datenträger |
|---|---|
| 2 MB | 2 MB/s |
| 64 KB | 2 MB/s |
| 8 KB | 1 MB/s |
| 8 KB | 2 MB/s |
Ergebnis
| Anzahl der unterstützten Datenträger | Durchsatz gesamt | OPS insgesamt | Bottleneck |
|---|---|---|---|
| 68 | 136 MB/s | 68 | storage |
| 60 | 120 MB/s | 2048 | storage |
| 28 | 28 MB/s | 3.584 | Azure Site Recovery CPU und Arbeitsspeicher |
| 16 | 32 MB/s | 4096 |
Hinweis
8 KB ist die kleinste Blockgröße von Daten, die Azure Site Recovery unterstützt. Alle Änderungen, die kleiner als 8 KB sind, werden als 8 KB behandelt.
Um weitere Tests zu machen, haben wir eine konsistente Art von Workload generiert. beispielsweise konsistente Speicheränderungen in Blöcken von 8 KB, die sich auf bis zu 1 MB/s pro Datenträger summieren. Dieses Szenario ist in einer realen Workload wahrscheinlich nicht, da Änderungen zu verschiedenen Tageszeiten oder in Spitzen unterschiedlicher Größe auftreten können.
Um diese zufälligen Muster zu replizieren, haben wir auch Szenarien mit getestet:
- 120 VMs (80 Windows, 40 Linux) werden über dieselbe Azure Site Recovery VM Anwendung geschützt.
Jede VM generiert in zufälligen Intervallen, mindestens zweimal pro Stunde, zufällige Blöcke mit insgesamt 5 GB Daten in fünf Dateien.
Die Replikation auf allen 120 virtuellen Computern mit geringer bis mittlerer Auslastung der Azure-Site Recovery-Dienste ist erfolgreich.
Hinweis
Diese Zahlen sollten nur als Baseline verwendet werden. Sie skalieren nicht unbedingt linear. Das Hinzufügen eines weiteren Batches mit der gleichen Anzahl von VMs hat möglicherweise weniger Auswirkungen als der anfängliche Batch. Die Ergebnisse hängen stark vom Typ der verwendeten Workloads ab.
Planen und Testen
Für Anwendungen und Lösungsworkloads gelten bestimmte RTO-Anforderungen (Recovery Time Objective) und Recovery Point Objective (RPO). Ein effektiver Entwurf für Geschäftskontinuität und Notfallwiederherstellung (BCDR) nutzt beide Funktionen auf Plattformebene, die diese Anforderungen erfüllen, da wir die lösungsspezifischen Mechanismen verwenden. Um BCDR-Funktionen zu entwerfen, erfassen Sie die Anforderungen der Notfallwiederherstellung (Disaster Recovery, DR) der Plattform, und berücksichtigen Sie alle folgenden Faktoren in Ihrem Entwurf:
Anforderungen an die Anwendungs- und Datenverfügbarkeit:
- RTO- und RPO-Anforderungen für jede Workload
- Unterstützung für Aktiv/Aktiv- und Aktiv/Passiv-Verfügbarkeitsmuster
Unterstützung von Bereitstellungen in mehreren Regionen für Failover, wobei Komponenten für die Leistung nah beieinander platziert werden. Bei einem Ausfall können Anwendungsvorgänge mit eingeschränkter Funktionalität oder leistungseinbußen auftreten.
Hinweis
Die Anwendung kann nativ ausgeführt werden oder verfügt über bestimmte Komponenten, die in mehreren Azure Stack Hub-Umgebungen ausgeführt werden können. In diesem Fall können Sie Azure Site Recovery verwenden, um nur die VMs mit den Komponenten zu replizieren, die nicht über diese Funktionalität verfügen, z. B. eine Front-End- oder Back-End-Lösung, in der Sie die Front-Ends in Azure Stack Hub-Umgebungen bereitstellen können.
Vermeiden Sie Überschneidungen bei den IP-Adressbereichen in Produktions- und DR-Netzwerken.
- Produktions- und DR-Netzwerke mit überlappenden IP-Adressen erfordern einen Failoverprozess, der das Anwendungsfailover verkomplizieren und verzögern kann. Entwerfen Sie nach Möglichkeit eine BCDR-Netzwerkarchitektur, die eine gleichzeitige Konnektivität mit allen Standorten ermöglicht.
Größenanpassung Ihrer Zielumgebungen:
- Wenn Sie die Quelle und das Ziel 1:1 verwenden, weisen Sie ihrer Zielumgebung etwas mehr Speicher zu. Dies ist auf die Art und Weise zurückzuführen, wie der Verlauf der Datenträgermarken erfolgt. Diese Zuordnung ist keine 2-fache Erhöhung, da sie nur Änderungen an den Daten enthält. Abhängig vom Typ der Daten und den erwarteten Änderungen stellen Replikationsrichtlinien mit einem 1,5- bis 2-fachen mehr Speicher auf dem Ziel sicher, dass Failoverprozesse keine Probleme mit sich bringen.
- Sie könnten die Azure Stack Hub-Zielumgebung als Ziel für mehrere Azure Stack Hub-Quellen in Betracht ziehen. In diesem Fall senken Sie die Gesamtkosten, müssen aber planen, was passiert, wenn bestimmte Workloads ausfallen. z. B. welche Quelle priorisiert werden muss.
- Wenn Ihre Zielumgebung zum Ausführen anderer Workloads verwendet wird, muss der BCDR-Plan das Verhalten dieser Workloads enthalten. Beispielsweise können Sie die Dev/Test-VMs in der Zielumgebung ausführen, und wenn ein Problem mit Ihrer Quellumgebung auftritt, können Sie alle VMs auf dem Ziel deaktivieren, um sicherzustellen, dass genügend Ressourcen zum Starten der geschützten VMs verfügbar sind.
Sie sollten die BCDR testen und regelmäßig überprüfen. Dazu können Sie Testfailoverprozesse verwenden oder die gesamten Workloads verschieben, um die Flows end-to-end zu überprüfen.