Schutz von in Azure Stack Hub bereitgestellten VMsProtect VMs deployed on Azure Stack Hub
Dieser Artikel unterstützt Sie bei der Entwicklung einer Datenschutz- und Notfallwiederherstellungsstrategie für virtuelle IaaS-Computer (virtual machines, VMs), die benutzerseitig in Azure Stack Hub bereitgestellt werden.
Zum Schutz vor Datenverlusten und längeren Ausfallzeiten empfiehlt es sich, einen Sicherungs- oder Notfallwiederherstellungsplan für Benutzeranwendungen und deren Daten zu implementieren. Hierfür müssen die einzelnen Anwendungen im Rahmen einer umfassenden BCDR-Strategie (Business Continuity & Disaster Recovery) Ihrer Organisation evaluiert werden.
Überlegungen zum Schutz virtueller IaaS-Computer
Rollen und Zuständigkeiten
Sorgen Sie zunächst 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 kümmern sich darum, dass Azure Stack Hub online ist und ordnungsgemäß funktioniert. Azure Stack Hub beinhaltet einen Dienst, der interne Dienstdaten von Infrastrukturdiensten sichert. Benutzerdaten wie benutzerseitig erstellte virtuelle Computer, Speicherkonten mit Benutzer- oder Anwendungsdaten sowie Benutzerdatenbanken werden dabei nicht gesichert.
| Anwendungsbesitzer/-architekten | Azure Stack Hub-Operator |
|---|---|
| – Richten Sie die Anwendungsarchitektur an den Prinzipien des Cloudentwurfs 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 von Anwendungsressourcen und Datenrepositorys, die geschützt werden müssen. – Implementieren Sie eine Daten- und Anwendungswiederherstellungsmethode, die am besten an der Anwendungsarchitektur und den Kundenanforderungen ausgerichtet ist. |
– Identifizieren der Geschäftskontinuitäts- und Notfallwiederherstellungsziele des organization– Stellen Sie genügend Azure Stack Hub-Instanzen bereit, um die BC/DR-Ziele der organization 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 den Anwendungsentwurf zu verstehen und Schutzstrategien zu empfehlen. – Aktivieren sie die Infrastruktursicherung für die Dienstreparatur und Cloudwiederherstellung. |
Quelle/Ziel-Kombinationen
Benutzer, die sich vor dem Ausfall eines Rechenzentrums oder Standorts schützen müssen, können eine weitere Azure Stack Hub-Instanz oder Azure verwenden, um Hochverfügbarkeit bereitzustellen oder eine schnelle Wiederherstellung zu ermöglichen. Mit einem primären und sekundären Standort können Benutzer Anwendungen in einer Aktiv/Aktiv- oder Aktiv/Passiv-Konfiguration in zwei Umgebungen bereitstellen. Für weniger kritische Workloads können Benutzer auf Kapazitäten des sekundären Standorts zurückgreifen, um Anwendungen nach Bedarf aus einer Sicherung wiederherzustellen.
In einem Rechenzentrum können einzelne oder mehrere Azure Stack Hub-Clouds bereitgestellt werden. Die Bereitstellung von mindestens einer Azure Stack Hub-Cloud in einem anderen Rechenzentrum ermöglicht im Notfall ein Failover für Workloads und trägt zur Minimierung ungeplanter Downtime bei. Sollten Sie nur über eine einzelne Azure Stack Hub-Instanz verfügen, empfiehlt es sich gegebenenfalls, die öffentliche Azure-Cloud als Wiederherstellungscloud zu verwenden. Die Entscheidung, wo Ihre Anwendung ausgeführt werden kann, hängt von behördlichen Vorgaben, Unternehmensrichtlinien und strengen Wartezeitanforderungen ab. Der passende Wiederherstellungsort kann flexibel pro Anwendung bestimmt werden. So ist es beispielsweise möglich, dass Anwendungen eines bestimmten Abonnements Daten in einem anderen Rechenzentrum sichern und Anwendungen eines anderen Abonnements Daten in der öffentlichen Azure-Cloud replizieren.
Ziele für die Anwendungswiederherstellung
Anwendungsbesitzer sind in erster Linie dafür zuständig, zu bestimmen, in welchem Umfang Ausfallzeiten und Datenverluste von der Anwendung und der Organisation toleriert werden können. Die Quantifizierung akzeptabler Ausfallzeiten und Datenverluste ermöglicht die Erstellung eines Wiederherstellungsplans, der die Auswirkungen einer Katastrophe für Ihre Organisation minimiert. Machen Sie sich für jede Anwendung Gedanken zu folgenden Aspekten:
-
Recovery Time Objective (RTO)
Die RTO ist der maximal zulässige Zeitraum, in dem eine App nach einem Vorfall nicht verfügbar sein darf. Ein RTO-Wert von 90 Minuten bedeutet beispielsweise, dass Sie in der Lage sein müssen, die App innerhalb von 90 Minuten nach Beginn eines Notfalls wieder in den Ausführungszustand zu versetzen. Falls für die RTO ein niedriger Wert angesetzt ist, führen Sie ggf. eine zweite Bereitstellung durchgehend im Standby aus, um vor einem regionalen Ausfall geschützt zu sein. -
Recovery Point Objective (RPO)
RPO ist der maximale Zeitraum bei einem Notfall, in dem ein Datenverlust zulässig ist. Wenn Sie Daten beispielsweise nur in einer Datenbank speichern, die nicht gesichert wird und auch keine Replikation in andere Datenbanken durchführt, können Daten von bis zu einer Stunde verloren gehen.
Eine weitere Metrik ist Mean Time to Recover (MTTR) – der durchschnittliche Zeitraum, der zur Wiederherstellung der Anwendung nach einem Ausfall erforderlich ist. MTTR ist ein empirischer Wert für ein System. Wenn der MTTR-Wert den RTO-Wert übersteigt, führt ein Ausfall des Systems zu einer nicht akzeptablen Störung des Geschäftsbetriebs, da das System nicht innerhalb des definierten RTO-Zeitraums wiederhergestellt werden kann.
Schutzoptionen
Sicherungswiederherstellung
Die Sicherung Ihrer Anwendungen und Datasets ermöglicht eine schnelle Erholung nach einem Ausfall infolge einer Katastrophe oder aufgrund von beschädigten Daten oder versehentlichen Löschungen. Bei Anwendungen, die auf IaaS-VMs basieren, können Anwendungsdaten, die Betriebssystemkonfiguration und auf Volumes gespeicherte Daten mithilfe eines gastinternen Agents geschützt werden.
Sichern mithilfe eines gastinternen Agents
Die Sicherung eines virtuellen Computers mithilfe eines Gastbetriebssystem-Agents beinhaltet in der Regel die Erfassung der Betriebssystemkonfiguration, Dateien/Ordner, Datenträger, Anwendungsbinärdateien oder Anwendungsdaten.
Wenn eine Anwendung aus einem Agent wiederhergestellt werden soll, muss der virtuelle Computer neu erstellt, das Betriebssystem installiert und der Gast-Agent installiert werden. An diesem Punkt können Daten im Gastbetriebssystem oder direkt in der Anwendung wiederhergestellt werden.
Sichern mithilfe einer Datenträgermomentaufnahme für beendete virtuelle Computer
Sicherungsprodukte können die Konfiguration virtueller IaaS-Computer sowie die Datenträger schützen, die an einen beendeten virtuellen Computer angefügt sind. Verwenden Sie Sicherungsprodukte mit Azure Stack Hub-API-Integration, um die VM-Konfiguration zu erfassen und Datenträgermomentaufnahmen zu erstellen. Sollte für die Anwendung geplante Ausfallzeit akzeptabel sein, vergewissern Sie sich vor dem Starten des Sicherungsworkflows, dass der virtuelle Computer beendet ist.
Sicherung mithilfe einer Datenträgermomentaufnahme für aktive VMs
Wichtig
Die Verwendung von Datenträgermomentaufnahmen aus dem Portal wird derzeit nicht für virtuelle Computer in einem ausgeführten Zustand unterstützt. Die Erstellung einer Momentaufnahme eines Datenträgers, der an einen aktiven virtuellen Computer angefügt ist, kann die Leistung oder die Verfügbarkeit des Betriebssystems oder der Anwendung auf dem virtuellen Computer beeinträchtigen. Die Empfehlung besteht darin, eine Sicherungsanbieterlösung zu verwenden, die in die inkrementelle Momentaufnahme Storage RP 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
Virtuelle Computer in einer Skalierungs- oder Verfügbarkeitsgruppe, die als kurzlebige Ressourcen gelten, sollten nicht auf der VM-Ebene gesichert werden. Das gilt insbesondere für zustandslose Anwendungen. Bei zustandsbehafteten Anwendungen in einer Skalierungs- oder Verfügbarkeitsgruppe sollten die Anwendungsdaten (beispielsweise eine Datenbank oder ein Volume in einem Speicherpool) ggf. geschützt werden.
Replikation und manuelles Failover
Bei Anwendungen, die minimale Datenverluste oder minimale Ausfallzeiten erfordern, kann die Datenreplikation auf der Gastbetriebssystem- oder Anwendungsebene aktiviert werden, um Daten an einem anderen Standort zu replizieren. Einige Anwendungen (etwa Microsoft SQL Server) unterstützen die Replikation nativ. Sollte die Anwendung keine Replikation unterstützen, können Sie Datenträger mithilfe von Software im Gastbetriebssystem replizieren oder eine Partnerlösung verwenden, die als Agent im Gastbetriebssystem installiert wird.
Bei diesem Ansatz wird die Anwendung in einer Cloud bereitgestellt, und die Daten werden in der anderen Cloud repliziert (lokal oder in Azure). Im Falle eines Failovers muss die Anwendung am Ziel gestartet und mit den replizierten Daten verknüpft werden, um Anforderungen verarbeiten zu können.
Hochverfügbarkeit und automatisches Failover
Bei zustandslosen Anwendungen, bei denen nur Ausfallzeiten von wenigen Sekunden oder Minuten akzeptabel sind, empfiehlt sich eine Hochverfügbarkeitskonfiguration. Hochverfügbare Anwendungen sind für die Bereitstellung an mehreren Standorten in einer Aktiv/Aktiv-Topologie konzipiert, in der alle Instanzen Anforderungen verarbeiten können. Bei lokalen Hardwareausfällen implementiert die Azure Stack Hub-Infrastruktur Hochverfügbarkeit im physischen Netzwerk mithilfe von zwei Top-of-Rack-Switches. Bei Ausfällen auf der Computeebene verwendet Azure Stack Hub mehrere Knoten in einer Skalierungseinheit und führt ein automatisches Failover für eine VM durch. Auf der VM-Ebene können Sie Skalierungsgruppen oder VM in Verfügbarkeitsgruppen verwenden, um sicherzustellen, dass Knotenausfälle nicht zum Ausfall Ihrer Anwendung führen. Hierzu muss die gleiche Anwendung an einem sekundären Standort in der gleichen Konfiguration bereitgestellt werden. Um eine Aktiv/Aktiv-Anwendung zu erhalten, können Anforderungen mithilfe eines Lastenausgleichs oder DNS an alle verfügbaren Instanzen weitergeleitet werden.
Keine Wiederherstellung
Einige Apps in Ihrer Umgebung erfordern keinen Schutz vor ungeplanten Ausfallzeiten oder Datenverlusten. Die für die Entwicklung und Tests verwendeten VMs beispielsweise müssen normalerweise nicht wiederhergestellt werden. Sie entscheiden selbst, ob Sie auf den Schutz einer Anwendung oder eines Datasets verzichten möchten.
Empfohlene Topologien
Wichtige Überlegungen zu Ihrer Azure Stack Hub-Bereitstellung:
| Empfehlung | Kommentare | |
|---|---|---|
| Sicherung bzw. Wiederherstellung von VMs in einem bereits im Rechenzentrum bereitgestellten externen Sicherungsziel | Empfohlen | Nutzen Sie die vorhandene Sicherungsinfrastruktur und Ressourcen Ihres Betriebs. Passen Sie die Größe der Sicherungsinfrastruktur an, damit diese für den Schutz weiterer VM-Instanzen bereit ist. Stellen Sie sicher, dass sich die Sicherungsinfrastruktur nicht in der Nähe Ihrer Quelle befindet. Sie können VMs in der Azure Stack Hub-Quellinstanz, in einer sekundären Azure Stack Hub-Instanz oder in Azure wiederherstellen. |
| Sicherung bzw. Wiederherstellung von VMs in einem für Azure Stack Hub dedizierten Sicherungsziel | Empfohlen | Sie können eine neue Sicherungsinfrastruktur erwerben oder eine dedizierte Sicherungsinfrastruktur für Azure Stack Hub bereitstellen. Stellen Sie sicher, dass sich die Sicherungsinfrastruktur nicht in der Nähe Ihrer Quelle befindet. Sie können VMs in der Azure Stack Hub-Quellinstanz, in einer sekundären Azure Stack Hub-Instanz oder in Azure wiederherstellen. |
| Direkte Sicherung bzw. Wiederherstellung von VMs in einer globalen Azure-Umgebung oder bei einem vertrauenswürdige Dienstanbieter | Empfohlen | Solange Sie Ihre Datenschutz- und behördlichen Anforderungen erfüllen können, können Sie Ihre Sicherungen in einer globalen Azure-Umgebung oder bei einem vertrauenswürdigen Dienstanbieter speichern. Im Idealfall führt der Dienstanbieter auch Azure Stack Hub aus. In diesem Fall profitieren Sie bei der Wiederherstellung von einer konsistenten Erfahrung hinsichtlich des Betriebs. |
| Replikation und Durchführung eines Failovers für VMs in einer separaten Azure Stack Hub-Instanz | Empfohlen | Bei einem Failover müssen Sie über eine zweite vollständig funktionsfähige Azure Stack Hub-Cloud verfügen, um längere App-Ausfallzeiten zu vermeiden. |
| Direkte Replikation und Durchführung eines Failovers für VMs in Azure oder bei einem vertrauenswürdige Dienstanbieter | Empfohlen | Solange Sie Ihre Datenschutz- und behördlichen Anforderungen erfüllen können, können Sie Ihre Daten in einer globalen Azure-Umgebung oder bei einem vertrauenswürdigen Dienstanbieter replizieren. Im Idealfall führt der Dienstanbieter auch Azure Stack Hub aus. In diesem Fall profitieren Sie nach einem Failover von einer konsistenten Erfahrung hinsichtlich des Betriebs. |
| Stellen Sie ein Sicherungsziel in der gleichen Azure Stack Hub-Instanz bereit, die auch als Host für die Anwendungen fungiert, die durch das gleiche Sicherungsziel geschützt werden. | Eigenständiges Ziel: Nicht empfohlen Ziel, das Sicherungsdaten extern repliziert: Empfohlen |
Wenn Sie eine Sicherungsappliance in Azure Stack Hub bereitstellen, um die Betriebswiederherstellung zu optimieren, müssen Sie sicherstellen, dass alle Daten kontinuierlich an einen externen Sicherungsspeicherort kopiert werden. |
| Bereitstellen einer physischen Sicherungsappliance im selben Rack, auf dem die Azure Stack Hub-Lösung installiert ist | Nicht unterstützt | Zurzeit können Sie keine anderen Geräte mit Top-of-Rack-Switches 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 diese aus der Sicherung wiederhergestellt haben. Dazu zählen unter anderem folgende Einstellungen:
-
MAC address (MAC-Adresse)
Der virtuelle Netzwerkadapter erhält eine neue MAC-Adresse. Es gibt keine Möglichkeit, die ursprüngliche MAC-Adresse beizubehalten. -
IP-Adresse
Wenn für Ihre VM intern eine statische IP-Adresse festgelegt ist, kann die interne IP-Adresse des virtuellen Netzwerkadapters auf die ursprüngliche IP-Adresse festgelegt werden. Sie müssen berücksichtigen, ob das VNet über eine S2S-VPN-Verbindung 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 (z. B. VMware vSphere) gesichert wurde, sind einige zusätzliche Schritte nötig, um alle nicht benötigten Artefakte aus der Quelle zu bereinigen.
Nächste Schritte
In diesem Artikel wurden allgemeine Richtlinien zum Schützen der virtuellen Computer von Benutzern beschrieben, die unter Azure Stack Hub bereitgestellt werden. Informationen zur Verwendung von Azure-Diensten zum Schutz von Benutzer-VMs finden Sie unter: