Freigeben über

Schützen von virtuellen Computern, die auf Azure Stack Hub bereitgestellt werden

Verwenden Sie diesen Artikel als Leitfaden, um Ihnen bei der Entwicklung einer Datenschutz- und Notfallwiederherstellungsstrategie für vom Benutzer bereitgestellte virtuelle IaaS-Computer (VMs) zu helfen, die auf Azure Stack Hub bereitgestellt werden.

Um vor Datenverlusten und erweiterten Ausfallzeiten zu schützen, implementieren Sie einen Plan zur Sicherung der Wiederherstellung oder Notfallwiederherstellung für Benutzeranwendungen und deren Daten. Jede Anwendung muss als Teil der umfassenden Strategie für Geschäftskontinuität und Notfallwiederherstellung (BC/DR) Ihrer Organisation ausgewertet werden.

Überlegungen zum Schutz von IaaS-VMs

Rollen und Zuständigkeiten

Stellen Sie zunächst sicher, dass es ein klares Verständnis der Rollen und Verantwortlichkeiten gibt, die Anwendungsbesitzern und -operatoren im Kontext des Schutzes und der Wiederherstellung zugeordnet sind.

Benutzer sind für den Schutz von VMs verantwortlich. Betreiber sind dafür verantwortlich, Azure Stack Hub online und fehlerfrei zu halten. Azure Stack Hub enthält einen Dienst, der interne Dienstdaten aus Infrastrukturdiensten sichert und keine Benutzerdaten enthält, einschließlich von Benutzern erstellten VMs, Speicherkonten mit Benutzer- oder Anwendungsdaten oder Benutzerdatenbanken.

Anwendungsbesitzer/Architekt Azure Stack Hub-Operator
– Richten Sie die Anwendungsarchitektur mit den Prinzipien des Clouddesigns aus.
– Modernisieren Sie herkömmliche Anwendungen nach Bedarf, um sie für die Cloudumgebung vorzubereiten.
– Definieren Sie akzeptable rTO und RPO für die Anwendung.
– Identifizieren Sie Anwendungsressourcen und Datenrepositorys, die geschützt werden müssen.
– Implementieren Sie eine Daten- und Anwendungswiederherstellungsmethode, die am besten an die Anwendungsarchitektur und die Kundenanforderungen ausgerichtet ist.		 – Identifizieren sie die Geschäftskontinuitäts- und Notfallwiederherstellungsziele der Organisation.
– Stellen Sie genügend Azure Stack Hub-Instanzen bereit, um die BC/DR-Ziele der Organisation zu erfüllen.
- Entwerfen und Betreiben der Anwendungs-/Datenschutzinfrastruktur.
– Bereitstellen von verwalteten Lösungen oder Self-Service-Zugriff auf Schutzdienste.
- Arbeiten Sie mit Anwendungsbesitzern/Architekten zusammen, um Anwendungsdesign zu verstehen und Schutzstrategien zu empfehlen.
– Aktivieren der Infrastruktursicherung für die Dienstheilung und Cloudwiederherstellung.

Quell-/Zielkombinationen

Benutzer, die vor einem Rechenzentrums- oder Standortausfall schützen müssen, können einen anderen Azure Stack Hub oder Azure verwenden, um hohe Verfügbarkeit oder schnelle Wiederherstellung bereitzustellen. Mit primärem und sekundären Standort können Benutzer Anwendungen in einer aktiven/aktiven oder aktiven/passiven Konfiguration in zwei Umgebungen bereitstellen. Bei weniger kritischen Arbeitslasten können Benutzer kapazität am sekundären Speicherort verwenden, um die Wiederherstellung von Anwendungen nach Bedarf aus der Sicherung durchzuführen.

Mindestens eine Azure Stack Hub-Cloud kann in einem Rechenzentrum bereitgestellt werden. Um eine katastrophale Katastrophe zu überleben, stellt die Bereitstellung mindestens einer Azure Stack Hub-Cloud in einem anderen Rechenzentrum sicher, dass Sie Arbeitslasten überschlagen und ungeplante Ausfallzeiten minimieren können. Wenn Sie nur über einen Azure Stack Hub verfügen, sollten Sie die öffentliche Azure-Cloud als Wiederherstellungscloud in Betracht ziehen. Die Bestimmung, wo Ihre Anwendung ausgeführt werden kann, hängt von behördlichen Vorschriften, Unternehmensrichtlinien und strengen Latenzanforderungen ab. Sie haben die Flexibilität, den geeigneten Wiederherstellungsspeicherort pro Anwendung zu ermitteln. Sie können beispielsweise Anwendungen in einem Abonnement haben, die Daten in einem anderen Rechenzentrum und in einem anderen Abonnement sichern und Daten in der öffentlichen Azure-Cloud replizieren.

Ziele für die Anwendungswiederherstellung

Anwendungsbesitzer sind in erster Linie dafür verantwortlich, die Menge an Ausfallzeiten und Datenverlusten zu bestimmen, die die Anwendung und die Organisation tolerieren können. Indem Sie akzeptable Ausfallzeiten und akzeptablen Datenverlust quantifizieren, können Sie einen Wiederherstellungsplan erstellen, der die Auswirkungen einer Katastrophe auf Ihre Organisation minimiert. Berücksichtigen Sie für jede Anwendung Folgendes:

  • Recovery Time Objective (RTO)
    RTO ist die maximal zulässige Zeit, die eine App nach einem Vorfall nicht verfügbar sein kann. Beispielsweise bedeutet ein RTO von 90 Minuten, dass Sie die App innerhalb von 90 Minuten ab dem Beginn eines Notfalls auf einen ausgeführten Zustand wiederherstellen können. Wenn Sie über ein niedriges RTO verfügen, können Sie eine zweite Bereitstellung kontinuierlich im Standbymodus ausführen, um vor einem regionalen Ausfall zu schützen.
  • Recovery Point Objective (RPO)
    RPO ist die maximale Dauer des Datenverlusts, der während eines Notfalls akzeptabel ist. Wenn Sie z. B. Daten in einer einzelnen Datenbank speichern, die stündlich gesichert ist und keine Replikation für andere Datenbanken aufweist, können Sie bis zu einer Stunde Daten verlieren.

Eine weitere Metrik ist Mean Time to Recover (MTTR). Dies ist die durchschnittliche Zeit, die zum Wiederherstellen der Anwendung nach einem Fehler benötigt wird. MTTR ist ein empirischer Wert für ein System. Wenn MTTR den RTO überschreitet, führt ein Fehler im System zu einer inakzeptablen Geschäftsunterbrechung, da es nicht möglich sein wird, das System innerhalb des definierten RTO wiederherzustellen.

Schutzoptionen

Sicherungswiederherstellung

Durch das Sichern Ihrer Anwendungen und Datasets können Sie aufgrund von Datenbeschädigungen, versehentlichen Löschungen oder Katastrophen schnell von Ausfallzeiten wiederherstellen. Für vmbasierte IaaS-Anwendungen können Sie einen In-Guest-Agent verwenden, um Anwendungsdaten, Betriebssystemkonfiguration und Daten zu schützen, die auf Volumes gespeichert sind.

Sicherung mit In-Guest-Agent

Das Sichern einer VM mit einem Gastbetriebssystem-Agent umfasst in der Regel das Erfassen der Betriebssystemkonfiguration, Dateien/Ordner, Datenträger, Anwendungsbinärdateien oder Anwendungsdaten.

Zum Wiederherstellen einer Anwendung von einem Agent muss der virtuelle Computer manuell neu erstellt, das Betriebssystem installiert und der Gast-Agent installiert werden. Zu diesem Zeitpunkt können Daten im Gastbetriebssystem oder direkt in der Anwendung wiederhergestellt werden.

Sicherung mithilfe der Datenträgermomentaufnahme für beendete VMs

Sicherungsprodukte können die IaaS-VM-Konfiguration und Datenträger schützen, die an eine angehaltene VM angefügt sind. Verwenden Sie Sicherungsprodukte, die in Azure Stack Hub-APIs integriert sind, um die VM-Konfiguration zu erfassen und Datenträgermomentaufnahmen zu erstellen. Wenn geplante Ausfallzeiten für die Anwendung möglich sind, stellen Sie sicher, dass sich die VM in einem angehaltenen Zustand befindet, bevor Sie den Sicherungsworkflow starten.

Sicherung mithilfe der Datenträgermomentaufnahme für die Ausführung von virtuellen Computern

Von Bedeutung

Die Verwendung von Datenträgermomentaufnahmen aus dem Portal wird derzeit für vm in einem ausgeführten Zustand nicht unterstützt. Das Erstellen einer Momentaufnahme eines Datenträgers, der an eine ausgeführte VM angefügt ist, kann die Leistung beeinträchtigen oder sich auf die Verfügbarkeit des Betriebssystems oder der Anwendung auf dem virtuellen Computer auswirken. Es empfiehlt sich, eine Lösung des Sicherungsanbieters zu verwenden, die in die inkrementelle Speicher-RP-Momentaufnahmefunktion integriert ist, oder einen In-Gast-Agent, um die Anwendung zu schützen, wenn geplante Ausfallzeiten keine Option sind.

Virtuelle Computer in einer Skalierungs- oder Verfügbarkeitsgruppe

VMs in einer Skalierungsgruppe oder Verfügbarkeitsgruppe, die als kurzlebige Ressourcen betrachtet werden, sollten nicht auf VM-Ebene gesichert werden, insbesondere, wenn die Anwendung zustandslos ist. Für zustandsbehaftete Anwendungen, die in einem Skalierungssatz oder verfügbarkeitssatz bereitgestellt werden, sollten Sie die Anwendungsdaten schützen (z. B. eine Datenbank oder ein Volume in einem Speicherpool).

Replikation/manuelles Failover

Für Anwendungen, die minimale Datenverluste oder minimale Ausfallzeiten erfordern, kann die Datenreplikation auf Gastbetriebssystem- oder Anwendungsebene aktiviert werden, um Daten an einen anderen Speicherort zu replizieren. Einige Anwendungen, z. B. Microsoft SQL Server, unterstützen die Replikation nativ. Wenn die Anwendung die Replikation nicht unterstützt, können Sie software im Gastbetriebssystem verwenden, um Datenträger zu replizieren, oder eine Partnerlösung, die als Agent im Gastbetriebssystem installiert wird.

Bei diesem Ansatz wird die Anwendung in einer Cloud bereitgestellt, und die Daten werden in die andere lokale Cloud oder in Azure repliziert. Wenn ein Failover ausgelöst wird, muss die Anwendung im Ziel gestartet und an die replizierten Daten angefügt werden, bevor sie Wartungsanforderungen starten kann.

Hohe Verfügbarkeit/automatisches Failover

Bei zustandslosen Anwendungen, die nur einige Sekunden oder Minuten Ausfallzeiten tolerieren können, sollten Sie eine Hochverfügbarkeitskonfiguration in Betracht ziehen. Hochverfügbarkeitsanwendungen sind so konzipiert, dass sie an mehreren Standorten in einer aktiven/aktiven Topologie bereitgestellt werden, in der alle Instanzen Dienstanforderungen stellen können. Bei lokalen Hardwarefehlern implementiert die Azure Stack Hub-Infrastruktur hohe Verfügbarkeit im physischen Netzwerk mithilfe von zwei Top-Rack-Switches. Bei Fehlern auf Computeebene verwendet Azure Stack Hub mehrere Knoten in einer Skalierungseinheit und führt automatisch ein Failover einer VM durch. Auf VM-Ebene können Sie Skalierungssätze oder VMs im Verfügbarkeitssatz verwenden, um sicherzustellen, dass Knotenfehler Ihre Anwendung nicht herunternehmen. Dieselbe Anwendung muss an einem sekundären Speicherort in derselben Konfiguration bereitgestellt werden. Um die Anwendung aktiv/aktiv zu machen, kann ein Lastenausgleichsmodul oder DNS verwendet werden, um Anforderungen an alle verfügbaren Instanzen zu leiten.

Keine Wiederherstellung

Einige Apps in Ihrer Umgebung benötigen möglicherweise keinen Schutz vor ungeplanten Ausfallzeiten oder Datenverlusten. Beispielsweise müssen virtuelle Computer, die für Die Entwicklung und Tests verwendet werden, in der Regel nicht wiederhergestellt werden. Es ist Ihre Entscheidung, ohne Schutz für eine Anwendung oder ein Dataset zu tun.

Wichtige Überlegungen für Ihre Azure Stack Hub-Bereitstellung:

Empfehlung Kommentare
Sichern/Wiederherstellen von virtuellen Computern in einem externen Sicherungsziel, das bereits in Ihrem Rechenzentrum bereitgestellt wurde Empfohlen Nutzen Sie vorhandene Backup-Infrastruktur und betriebliche Fähigkeiten. Stellen Sie sicher, dass Die Sicherungsinfrastruktur so groß ist, dass sie bereit ist, die zusätzlichen VM-Instanzen zu schützen. Stellen Sie sicher, dass sich die Sicherungsinfrastruktur nicht in unmittelbarer Nähe zu Ihrer Quelle befindet. Sie können virtuelle Computer auf dem Azure Stack Hub-Quellserver, in einer sekundären Azure Stack Hub-Instanz oder in Azure wiederherstellen.
Sichern/Wiederherstellen von virtuellen Computern in einem externen Sicherungsziel, das azure Stack Hub zugeordnet ist Empfohlen Sie können neue Sicherungsinfrastruktur erwerben oder dedizierte Sicherungsinfrastruktur für Azure Stack Hub bereitstellen. Stellen Sie sicher, dass sich die Sicherungsinfrastruktur nicht in unmittelbarer Nähe zu Ihrer Quelle befindet. Sie können virtuelle Computer auf dem Azure Stack Hub-Quellserver, in einer sekundären Azure Stack Hub-Instanz oder in Azure wiederherstellen.
Direktes Sichern/Wiederherstellen von virtuellen Computern in globalen Azure oder einem vertrauenswürdigen Dienstanbieter Empfohlen Solange Sie Ihre Datenschutz- und gesetzlichen Anforderungen erfüllen können, können Sie Ihre Sicherungen in globalen Azure oder einem vertrauenswürdigen Dienstanbieter speichern. Im Idealfall führt der Dienstanbieter auch Azure Stack Hub aus, sodass Sie beim Wiederherstellen Konsistenz bei der Betriebserfahrung erhalten.
Replizieren/Failover-VMs in eine separate Azure Stack Hub-Instanz Empfohlen Im Failoverfall müssen Sie eine zweite Azure Stack Hub-Cloud vollständig betriebsbereit haben, damit Sie erweiterte App-Ausfallzeiten vermeiden können.
Replizieren/Failover-VMs direkt an Azure oder einen vertrauenswürdigen Dienstanbieter Empfohlen Solange Sie Ihre Datenschutz- und gesetzlichen Anforderungen erfüllen können, können Sie Ihre Daten in globale Azure oder einen vertrauenswürdigen Dienstanbieter replizieren. Im Idealfall führt der Dienstanbieter auch Azure Stack Hub aus, sodass Sie nach dem Failover Konsistenz bei der Betriebserfahrung erhalten.
Stellen Sie ein Sicherungsziel auf demselben Azure Stack Hub bereit, der auch alle Anwendungen hosten, die durch dasselbe Sicherungsziel geschützt sind. Eigenständiges Ziel: Nicht empfohlenes
Ziel, das Sicherungsdaten extern repliziert: Empfohlen		 Wenn Sie eine Sicherungsanwendung im Azure Stack Hub bereitstellen (zum Zweck der Optimierung der betriebstechnischen Wiederherstellung), müssen Sie sicherstellen, dass alle Daten kontinuierlich an einen externen Sicherungsspeicherort kopiert werden.
Bereitstellen einer physischen Backup-Appliance im selben Rack, in dem die Azure Stack Hub-Lösung installiert ist Nicht unterstützt Derzeit können Sie keine anderen Geräte mit dem oberen Rand von Rackschaltern verbinden, die nicht Teil der ursprünglichen Lösung sind.

Überlegungen für eine wiederhergestellte IaaS-VM

Sie müssen einige Änderungen an Ihrer VM vornehmen, nachdem Sie den Computer aus der Sicherung wiederhergestellt haben. Dazu gehören:

  • MAC-Adresse
    Der virtuelle Netzwerkadapter erhält eine neue MAC-Adresse. Es gibt keine Methode zum Beibehalten der ursprünglichen MAC-Adresse.
  • IP-Adresse
    Wenn Ihre VM intern eine statische IP festgelegt hat, kann die interne IP auf dem virtuellen Netzwerkadapter so festgelegt werden, dass sie mit dem Original übereinstimmt. Möglicherweise müssen Sie berücksichtigen, ob das VNET über ein S2S-VPN zu einer externen Umgebung verfügt, in der die IP-Adresse möglicherweise verwendet wird.
  • Nicht benötigte Artefakte
    Wenn die VM auf einer anderen Plattform gesichert wurde, z. B. VMware vSphere, müssen Sie einige zusätzliche Schritte ausführen, um alle nicht benötigten Artefakte aus der Quelle zu bereinigen.

Nächste Schritte

Dieser Artikel enthält allgemeine Richtlinien zum Schutz von Benutzer-VMs, die auf Azure Stack Hub bereitgestellt werden. Informationen zur Verwendung von Azure-Diensten zum Schutz von Benutzer-VMs finden Sie unter:

  • Last updated on