Kapazitätsplanung mit Azure Site Recovery

Als Organisation ist es unerlässlich, eine BCDR-Strategie (Business Continuity und Disaster Recovery) zu implementieren, die Ihre Daten schützt, Anwendungen verfügbar hält und Workloads sowohl bei geplanten als auch ungeplanten Ausfällen online hält.

Durch die Replikation virtueller Computer -Workloads von einem primären Standort auf einen sekundären Standort bietet Azure Site Recovery auf Azure Stack Hub Dienste, die die Sicherheit von Organisationsdaten, Anwendungsverfügbarkeit und Workloads während Ausfällen unterstützen können. Wenn beispielsweise ein Ausfall an Ihrem primären Standort auftritt, wechseln Sie zu einem sekundären Standort, um auf Ihre Apps zuzugreifen. Sobald der primäre Standort wieder ausgeführt wird, können Sie zu ihm zurückkehren. Weitere Informationen finden Sie unter "Informationen zur Websitewiederherstellung".

Um die Replikation von VMs über zwei Azure Stack Hub-Stempel hinweg zu aktivieren, konfigurieren Sie zwei Umgebungen:

• Quellumgebung :
  • Der Azure Stack Hub, auf dem die Mandanten-VMs ausgeführt werden.
• Zielumgebung :
  • Der Ort, an dem der Azure Site Recovery Resource Provider ausgeführt wird.

Eine wesentliche Komponente für den Erfolg eines Geschäftskontinuitäts- und Notfallwiederherstellungsplans ist die Kapazitätsplanung. Bei der Kapazitätsplanung sind einige Faktoren zu berücksichtigen:

• Wiederherstellungszeitziele (RTO) und Wiederherstellungspunktziele (RPO) für die spezifischen Workloads, die Sie schützen möchten.

• Arbeitslasten 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 vieles mehr?

• VM-Größen, die Anzahl der Datenträger und wie jede VM mit anderen VMs verbunden ist.

  • Für Lösungen, die mehrere VMs erfordern, verstehen Sie, 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 umfassende Auswirkungen beim Erstellen eines BCDR-Plans.

In den folgenden Abschnitten werden die wichtigsten Punkte aufgeführt, die sie aus einer Azure Site Recovery-Perspektive berücksichtigen sollten. Jeder BCDR-Plan unterscheidet sich und basiert auf den Besonderheiten der Workloads, die Sie schützen möchten. Daher ist diese Liste nicht vollständig.

Überlegungen zur Quelle

In der Quellumgebung führt Azure Stack Hub die VM-Appliance azure Site Recovery aus. Der virtuelle Computer ist eine Standard_DS4_v2 (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:

• Kontingent:

  • Sie sollten über ein ausreichendes Kontingent zum Erstellen der VM-Appliance für Azure Site Recovery verfügen. Je nach Gesamtplan benötigen Sie einen oder mehrere.

• Speicher für die VM-Appliance für Azure Site Recovery:

  • Die VM-Appliance von Azure Site Recovery selbst verfügt über die Datenanforderungen, die von der VM-Größe definiert sind.

  • Stellen Sie bei der Kapazitätsplanung sicher, dass die VM der Appliance über genügend Speicherplatz verfügt, um die Failback- und Wieder-Schutzmechanismen auszuführen.

    Hinweis

    Wenn Speichereinschränkungen bestehen, können der Failback und der erneute Schutz mit einem Fehler fehlschlagen Ein interner Fehler ist aufgetreten. Benutzer sollten die Ereignisprotokolle in der Appliance ü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:

  • Die erste Replikation generiert eine hohe Bandbreitennutzung.
  • Änderungen auf jedem virtuellen Computer werden je nach Replikationsrichtlinien und jedem Anwendungstyp repliziert.

Überlegungen zum Ziel

In der Zielumgebung müssen zwei Aspekte für die Kapazitätsplanung berücksichtigt werden:

• Die Anforderungen des Azure Site Recovery-Diensts: Wie viel wird verwendet, um Azure Site Recovery auszuführen, ohne dass Arbeitslasten unbedingt geschützt werden.

• Die Anforderungen für geschützte Workloads.

Für die Zielumgebung muss ein Azure Site Recovery Vault für jede Site Recovery-Appliance erstellt werden, um VMs vor der Quelle (eine Appliance pro Tresor) zu schützen. Obwohl dies keine Einschränkung aus Kapazitätsperspektive ist, sollte sie bei der Planung des Entwurfs der Gesamtumgebung berücksichtigt werden.

Azure Site Recovery RP-Ressourcen

Die Installation von Azure Site Recovery auf Azure Stack Hub erfordert, dass Sie den Site Recovery Resource Provider (RP) installieren.

Hinweis

Bei Microsoft.SiteRecovery-1.2301.2216.2287 erfordert Azure Site Recovery auf 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, Speicher und haben bestimmte vCPUs zugewiesen:

Dienstleistung	Virtueller CPU-Kern	Gedächtnis	Datenträgergröße
Azure-Website-Wiederherstellung	18	64 GB	384 GB

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 Workloads

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 von Datenträgern, Datenträgergröße, IOPS, Datenumsatz und neu erzeugte Daten.

• Überlegungen zur Netzwerkbandbreite:

  • Die Netzwerkbandbreite, die für die Deltareplikation erforderlich ist.
  • Der Durchsatz in der Zielumgebung, den Azure Site Recovery aus der Quellumgebung abrufen kann.
  • Die Anzahl der VMs, die auf einmal gebatcht werden sollen. Diese Zahl basiert auf der geschätzten Bandbreite, um die anfängliche Replikation in einem bestimmten Zeitraum abzuschließen.
  • Das RPO, das für eine bestimmte Bandbreite erreicht werden kann.
  • Der Effekt auf das gewünschte RPO, wenn niedrigere Bandbreite bereitgestellt wird.

• Überlegungen zur Speicherung:

  • Wie viele Daten für die erste Replikation erforderlich sind.
  • Wie viele Wiederherstellungspunkte vorhanden sind und wie die Daten während dieser Intervalle für jede geschützte virtuelle Maschine zunehmen.
  • Wie viele Kontingente dem Azure Stack Hub-Zielbenutzerabonnement zugewiesen werden müssen, damit Benutzer über ausreichende Zuweisungen verfügen.
  • Das Cachespeicherkonto für die Replikation.

• Überlegungen zur Berechnung:

  • Beim Failover werden die VMs auf den Abonnements der Benutzer des Azure Stack Hubs gestartet. Genügend Kontingentzuweisung muss vorhanden sein, um diese VM-Ressourcen starten zu können.
  • Während des Schutzes des virtuellen Computers, wenn die geschützte VM in der Quellumgebung aktiv ist, werden keine VM-bezogenen Ressourcen wie vCPU, Arbeitsspeicher usw. in der Zielumgebung verwendet. Diese Ressourcen gewinnen nur während eines Failover-Prozesses an Bedeutung, wie einem Test-Failover.

Für den Umfang von Azure Site Recovery im Azure Stack Hub finden Sie hier einen Ausgangspunkt für Berechnungen, insbesondere für das verwendete Cachespeicherkonto:

1. Bei einem Failover während des normalen Vorgangs multiplizieren Sie die Anzahl der replizierten Datenträger mit dem durchschnittlichen RPO. Zum Beispiel könnten Sie (2 MB * 250 s) verwenden. Das Cachespeicherkonto beträgt normalerweise ein paar KB bis 500 MB pro Datenträger.

2. Wenn es zu einem Failover kommt, multiplizieren Sie im schlimmsten Fall die Anzahl der replizierten Datenträger mit dem durchschnittlichen RPO über einen ganzen Tag.

   Von Bedeutung

   Wenn einige Teile von Azure Site Recovery nicht funktionieren, andere aber arbeiten, kann es höchstens einen Tag des Difflogs im Speicherkonto geben, bevor Azure Site Recovery ein Timeout beschließt.

3. Failback auf die neue VM. Berechnen Sie die Summe der Datenträgergröße jedes Batches.

   • Der gesamte Datenträger muss in das Cache-Speicherkonto kopiert werden, um für den virtuellen Zielcomputer anzuwenden, da der Ziel-Datenträger leer ist.
   • Die zugehörigen Daten werden nach dem Kopieren gelöscht, aber es wird 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 ist ein Beispiel für Tests, die in unseren Umgebungen ausgeführt werden. Sie können diese Erkenntnis verwenden, um einen Basisplan für Ihre eigene Anwendung zu erhalten, aber jede Arbeitsauslastung 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	Gesamt-OPS	Bottleneck
68	136 MB/s	68	Speicher
60	120 MB/s	2048	Speicher
28	28 MB/s	3.584	CPU und Arbeitsspeicher für Azure Site Recovery
16	32 MB/s	4096

Hinweis

8 KB ist die kleinste Blockgröße von Daten, die Azure Site Recovery unterstützt. Alle Änderungen unter 8 KB werden als 8 Kb behandelt.

Um weiter zu testen, haben wir eine konsistente Art von Arbeitsauslastung generiert; Beispiel: konsistente Speicheränderungen in Blöcken von 8 KB, die bis zu 1 MB/s pro Datenträger betragen. Dieses Szenario ist bei einer realen Arbeitsauslastung unwahrscheinlich, da Änderungen zu unterschiedlichen Tageszeiten oder in Spitzen mit verschiedenen Größen auftreten können.

Um diese zufälligen Muster zu replizieren, haben wir auch Szenarien mit folgenden Tests getestet:

• 120 VMs (80 Windows, 40 Linux) durch dieselbe VM-Appliance für Azure Site Recovery geschützt.

  • Jede virtuelle Maschine generiert in zufälligen Intervallen, mindestens zweimal pro Stunde, zufällige Blöcke mit insgesamt 5 GB Daten über fünf Dateien.

  • Die Replikation war auf allen 120 VMs mit einer geringen bis mittleren Last für die Azure Site Recovery-Dienste erfolgreich.

    Hinweis

    Diese Zahlen sollten nur als Basisplan verwendet werden. Sie skalieren nicht unbedingt linear. Das Hinzufügen eines weiteren Batches derselben Anzahl von virtuellen Computern hat möglicherweise weniger Auswirkungen als die erste. Die Ergebnisse sind stark von der Art der verwendeten Workloads abhängig.

Wie sollten Sie planen und testen?

Anwendungen und Workloads haben bestimmte Anforderungen an das Recovery Time Objective (RTO) und Recovery Point Objective (RPO). Ein effektiver Geschäftskontinuitäts- und Notfallwiederherstellungsentwurf (BCDR) nutzt sowohl die Funktionen auf Plattformebene, die diesen Anforderungen entsprechen, als wir die lösungsspezifischen Mechanismen verwenden. Um BCDR-Funktionen zu entwerfen, erfassen Sie anforderungen der Plattform-Notfallwiederherstellung (DR), und berücksichtigen Sie alle diese Faktoren in Ihrem Design:

• Anforderungen an die Anwendungs- und Datenverfügbarkeit:

  • RTO- und RPO-Anforderungen für jede Arbeitslast
  • 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. Möglicherweise treten Anwendungsvorgänge mit eingeschränkter Funktionalität oder beeinträchtigter Leistung während eines Ausfalls auf.

  Hinweis

  Die Anwendung kann nativ auf Azure Stack Hub ausgeführt werden oder hat bestimmte Komponenten, die über mehrere Azure Stack Hub Umgebungen ausgeführt werden können. In diesem Fall können Sie Azure Site Recovery verwenden, um nur die virtuellen Computer mit den Komponenten zu replizieren, die nicht über diese Funktionalität verfügen. Beispielsweise eine Front-End- oder Back-End-Typlö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.

• Dimensionierung Ihrer Zielumgebungen:

  • Wenn Sie die Quelle und das Ziel auf 1:1-Weise verwenden, weisen Sie etwas mehr Speicher in Ihrer Zielumgebung zu. Dies ist auf die Art und Weise zurückzuführen, wie die Historie der Datenträger Bookmarks abläuft. Diese Zuweisung ist keine Erhöhung von 2x, da sie nur Änderungen an den Daten enthält. Je nach Art der Daten und der erwarteten Änderungen sorgen Replikations-Richtlinien mit 1,5- bis 2-mal mehr Speicherplatz auf dem Ziel dafür, dass Failover-Prozesse keine Probleme verursachen.
  • Möglicherweise sollten Sie die Azure Stack Hub-Zielumgebung als Ziel für mehrere Azure Stack Hub-Quellen verwenden. In diesem Fall senken Sie die Gesamtkosten, müssen aber planen, was passiert, wenn bestimmte Arbeitslasten sinken; Beispielsweise, welche Quelle priorisiert werden muss.
  • Wenn Ihre Zielumgebung für die Ausführung anderer Workloads verwendet wird, muss der BCDR-Plan das Verhalten dieser Workloads enthalten. Sie können z. B. die Dev/Test-VMs in der Zielumgebung ausführen und wenn ein Problem mit Ihrer Quellumgebung auftritt, können Sie alle virtuellen Computer auf dem Ziel deaktivieren, um sicherzustellen, dass ausreichende Ressourcen verfügbar sind, um die geschützten virtuellen Computer zu starten.

Sie sollten den BCDR testen und regelmäßig überprüfen. Dazu können Sie Failoverprozesse testen oder die gesamten Workloads verschieben, um die Flüsse end-to-End zu überprüfen.

Nächste Schritte

Azure Site Recovery auf Azure Stack Hub