Bearbeiten

Hochverfügbarkeits- und Notfallwiederherstellungsszenarios für IaaS-Apps

Azure Site Recovery
Azure Virtual Machines
Azure Disk Storage

Dieser Artikel enthält eine Entscheidungsstruktur und Beispiele für Optionen in Bezug auf die Hochverfügbarkeit (High Availability, HA) und Notfallwiederherstellung (Disaster Recovery, DR), wenn mehrschichtige IaaS-Apps (Infrastructure-as-a-Service) in Azure bereitgestellt werden.

Architektur

Dieses Diagramm veranschaulicht die Entscheidungsstruktur für Hochverfügbarkeit.

Workflow

Verfügbarkeitsgruppen sorgen in einem Rechenzentrum für VM-Redundanz und -Verfügbarkeit, indem VMs auf mehrere isolierte Hardwareknoten verteilt werden. Ein Teil der VMs wird während einer geplanten oder ungeplanten Ausfallzeit weiter ausgeführt, damit die gesamte App verfügbar und betriebsbereit bleibt.

Verfügbarkeitszonen (VZ) sind eindeutige physische Speicherorte in den Rechenzentren einer Azure-Region. Jede Verfügbarkeitszone greift auf mindestens ein Rechenzentrum mit unabhängigen Stromversorgungs-, Kühl- und Netzwerkeinrichtungen zu, und jede VZ-fähige Azure-Region weist mindestens drei separate Verfügbarkeitszonen auf. Durch die physische Trennung der Verfügbarkeitszonen einer Region werden bereitgestellte VMs vor Rechenzentrumsausfällen geschützt.

Im Entscheidungsflussdiagramm wird verdeutlicht, dass für Hochverfügbarkeits-Apps nach Möglichkeit Verfügbarkeitszonen genutzt werden sollten. Hochverfügbarkeit ist zonenübergreifend und daher auch rechenzentrumsübergreifend, und es wird ein Servicelevel mit einer Betriebszeit von > 99,99 % erzielt, weil die Resilienz gegen Ausfälle von Rechenzentren sichergestellt ist.

Bei Verfügbarkeitsgruppen und -zonen für unterschiedliche App-Ebenen ist nicht garantiert, dass sie sich in denselben Rechenzentren befinden. Falls die App-Latenz ein wichtiger Punkt ist, sollten Sie Dienste gemeinsam in einem Rechenzentrum anordnen, indem Sie Näherungsplatzierungsgruppen mit Verfügbarkeitszonen und -gruppen verwenden.

Komponenten

Alternativen

  • Wenn die App Daten nativ replizieren kann, können Sie als Alternative zur regionalen Notfallwiederherstellung mit Azure Site Recovery auch die Notfallwiederherstellung in mehreren Regionen mit heißen bzw. kalten Standbyservern implementieren, z. B. einem ausschließlich für die Notfallwiederherstellung bestimmten gestreckten Cluster. Diese Alternative ist in den Beispielen nicht gesondert veranschaulicht, aber sie kann allen Lösungen hinzugefügt werden. Beachten Sie, dass die Replikation zwischen Regionen asynchron ist und es zu Datenverlust kommen kann.

    Falls Sie über eine eigene Technologie zur Datenreplikation verfügen, können Sie sie alternativ zur Erstellung einer sekundären Zone für die Notfallwiederherstellung innerhalb der Region verwenden. Abhängig von der Region Ihrer Workloads können Sie möglicherweise auch Azure Site Recovery verwenden, um Elemente in eine alternative Zone zu replizieren. Weitere Informationen zur regionalen Verfügbarkeit und zu diesem Feature finden Sie unter Aktivieren der Notfallwiederherstellung zwischen Zonen für virtuelle Azure-Computer.

  • Hochverfügbarkeit für mehrere Regionen ist möglich, aber hierfür wird ein globales Lastenausgleichsmodul benötigt, z. B. Front Door oder Traffic Manager. Weitere Informationen finden Sie unter Ausführen einer n-schichtigen Anwendung in mehreren Azure-Regionen für Hochverfügbarkeit.

Szenariodetails

Mehrschichtige bzw. n-schichtige Architekturen werden häufig in herkömmlichen lokalen Apps verwendet. Sie stellen also eine natürliche Wahl für die Migration von lokalen Apps in die Cloud bzw. beim Entwickeln von Apps für die lokale Umgebung und die Cloud dar. Die Implementierung von n-schichtigen Architekturen erfolgt normalerweise in Form von IaaS-Apps mit einer Unterteilung in logische Ebenen und physische Schichten: eine obere Web- bzw. Darstellungsebene, eine mittlere Geschäftsebene und eine Datenschicht.

Bei einer n-schichtigen IaaS-App wird jede Ebene über eine separate Gruppe mit VMs ausgeführt. Die Web- und Geschäftsebenen sind zustandslos. Dies bedeutet, dass alle VMs der Ebene alle dafür anfallenden Anforderungen verarbeiten können. Bei der Datenschicht handelt es sich um eine replizierte Datenbank, einen Objektspeicher oder einen Dateispeicher. Mehrere VMs jeder Ebene sorgen für Resilienz für den Fall, dass eine VM ausfällt, und mit Lastenausgleichsmodulen werden die Anforderungen auf die VMs verteilt.

Sie können Ebenen aufskalieren, indem Sie den Pools weitere VMs hinzufügen, und VM-Skalierungsgruppen verwenden, um für identische VMs das automatische Aufskalieren durchzuführen. Da Sie Lastenausgleichsmodule nutzen, können Sie Ebenen aufskalieren, ohne dass sich dies auf die Betriebszeit der App auswirkt.

Wenn für die Vereinbarung zum Servicelevel (SLA) einer IaaS-App eine Verfügbarkeit von > 99 % benötigt wird, können Sie die VMs in Verfügbarkeitsgruppen, Verfügbarkeitszonen und Näherungsplatzierungsgruppen anordnen, um die Hochverfügbarkeit für die App zu konfigurieren. Die von Ihnen gewählten Lösungen für Hochverfügbarkeit und Notfallwiederherstellung richten sich nach den erforderlichen Anforderungen in Bezug auf SLA, Latenz und regionale Notfallwiederherstellung.

Mögliche Anwendungsfälle

  • Migrieren einer n-schichtigen App aus der lokalen Umgebung zur Cloud
  • Bereitstellen einer n-schichtigen App lokal und in der Cloud
  • Konfigurieren von Hochverfügbarkeit und Notfallwiederherstellung für eine IaaS-App

Diese Lösung kann für jede Branche verwendet werden, einschließlich der folgenden Szenarien:

  • Anwendungen im öffentlichen Bereich
  • Banken (Finanzbranche)
  • Gesundheitswesen

Überlegungen

  • Verfügbarkeitszonen sind nicht in allen Azure-Regionen verfügbar.

  • Treffen Sie vor Beginn der Lösungsentwicklung die Entscheidung, welche Bereitstellungsoption Sie verwenden möchten. Die Umstellung von einer Option auf die andere nach der Bereitstellung ist zwar möglich, aber dies ist nicht einfach. Sie müssen die VMs löschen und aus den zugrunde liegenden verwalteten Datenträgern neu erstellen. Dies ist ein aufwendiger Vorgang.

  • Stellen Sie sicher, dass Sie Ihre Anwendung der ausgewählten Lösung zuordnen können. Viele Resilienzmuster und -entwürfe von App-Ebenen liegen außerhalb des Umfangs dieser Entscheidungsstruktur.

  • Drei Szenarien können zu Neustarts von Azure-VMs führen: ungeplante Hardwarewartung, unerwartete Ausfallzeiten und geplante Wartung. Weitere Informationen zu diesen Ereignissen und bewährten Methoden für Hochverfügbarkeit mit dem Ziel, die Auswirkungen zu reduzieren, finden Sie im Abschnitt zu den Grundlagen von VM-Neustarts, Wartung und Ausfallzeit.

Einzelne VMs

Wenn für eine App keine Betriebszeit von > 99,9 % erforderlich ist, müssen Sie sie nicht für Hochverfügbarkeit konfigurieren und können einzelne VMs bereitstellen. Sie können VM-Skalierungsgruppen nutzen, um das automatische Aufskalieren von identischen VMs zu ermöglichen. Stellen Sie einzelne VMs bereit, ohne eine Zone anzugeben, damit sie in einer gesamten Region verteilt werden. Diese Apps verfügen über einen Servicelevel von 99,9 %, sofern Sie Azure SSD Premium-Datenträger verwenden.

Für einzelne VMs wird die Standardfunktion für die Dienstreparatur genutzt, die in alle Azure-Rechenzentren integriert ist. Für vorhersagbare Ausfälle wird bei dieser Funktion normalerweise die Livemigration verwendet, aber bei nicht vorhersagbaren Ereignissen werden VMs ggf. neu gestartet oder sind vorübergehend nicht verfügbar.

Hochverfügbarkeit

Wenn für die App ein Servicelevel von > 99,9 % benötigt wird, sollten Sie die App auf Hochverfügbarkeit auslegen. Verwenden Sie nach Möglichkeit Verfügbarkeitszonen, da diese über Fehlertoleranz für Rechenzentren verfügen. Sie können anstelle von Verfügbarkeitszonen auch Verfügbarkeitsgruppen verwenden, aber bei den Gruppen verringert sich die Verfügbarkeit von 99,99 % auf 99,95 %, weil Verfügbarkeitsgruppen keine Ausfälle von Rechenzentren tolerieren können.

Verfügbarkeitszonen sind für viele Szenarien mit gruppierten Apps geeignet, z. B. Always On-SQL-Cluster. Hierbei wird Aktiv/Aktiv, Aktiv/Passiv oder eine Kombination beider Hochverfügbarkeitslevel auf allen Ebenen mit schnellem Failover genutzt. Die synchrone Replikation ist aufgrund der niedrigen Latenz des zonenübergreifenden Netzwerks zwischen allen DBMS-Knoten (Datenbank-Manager) möglich. Sie können auch eine zonenübergreifende Konfiguration vom Typ Gestreckter Cluster durchführen. Hierbei ist die Latenz höher, und die asynchrone Replikation wird unterstützt.

Wenn Sie ein VM-basiertes Vermittlungsmodul für Cluster (Arbiter) nutzen möchten, z. B. einen Dateifreigabezeugen, sollten Sie es in der dritten Verfügbarkeitszone anordnen. So stellen Sie sicher, dass es nicht zu einem Quorumverlust kommt, falls eine Zone ausfällt. Alternativ können Sie ggf. auch einen cloudbasierten Zeugen in einer anderen Region verwenden.

Alle VMs in einer Verfügbarkeitszone sind in nur einer Fehlerdomäne (FD) und Updatedomäne (UD) angeordnet. Dies bedeutet, dass diese über eine gemeinsame Stromversorgung und einen gemeinsamen Netzwerkswitch verfügen und gleichzeitig neu gestartet werden können. Wenn Sie VMs in unterschiedlichen Verfügbarkeitszonen erstellen, sind Ihre VMs quasi auf unterschiedliche Fehler- und Updatedomänen verteilt, sodass sie nicht alle gemeinsam ausfallen oder neu gestartet werden. Falls Sie sowohl redundante auf Zonen begrenzte VMs als auch zonenübergreifende VMs nutzen möchten, sollten Sie Erstere in Verfügbarkeitsgruppen in Näherungsplatzierungsgruppen anordnen, um sicherzustellen, dass sie nicht alle auf einmal neu gestartet werden. Auch für Einzelinstanz-VM-Workloads, die derzeit noch nicht redundant sind, können Sie trotzdem optional Verfügbarkeitsgruppen in den Näherungsplatzierungsgruppen verwenden, um für zukünftiges Wachstum gerüstet zu sein und flexibel vorgehen zu können.

Erwägen Sie bei der Bereitstellung von VM-Skalierungsgruppen in Verfügbarkeitszonen die Verwendung des Orchestrierungsmodus (derzeit in der öffentlichen Vorschauphase), in dem Fehlerdomänen und Verfügbarkeitszonen kombiniert werden können.

Verfügbarkeitszonen mit zoneninternen Näherungsplatzierungsgruppen ermöglichen eine der niedrigsten Netzwerklatenzen in Azure und einen Servicelevel von mindestens 99,99 %, weil die Resilienz durch mehrere Rechenzentren sichergestellt wird. Verwenden Sie auf den VMs nach Möglichkeit den beschleunigten Netzwerkbetrieb.

Bei dieser Lösung kann es vorkommen, dass ein Dienst, der auf einer VM in einer Zone ausgeführt wird, mit einem Dienst in einer anderen Zone interagieren muss. Beispielsweise können zonenübergreifend eine Aktiv/Aktiv-Webebene und eine Aktiv/Passiv-Datenbankebene verwendet werden. Einige Anforderungen sind zonenübergreifend, und dies führt zu Latenz. Die zonenübergreifende Latenz ist zwar weiterhin sehr niedrig, aber wenn Sie die geringstmögliche Latenz erzielen möchten, sollten Sie die gesamte Netzwerkkommunikation zwischen den App-Ebenen auf eine Zone beschränken.

Latenzaspekte

Die Netzwerklatenz hängt u. a. von der physischen Entfernung zwischen bereitgestellten VMs ab. Falls für eine App eine sehr geringe Latenz zwischen Ebenen benötigt wird, können Sie sie ausschließlich in einem Rechenzentrum bereitstellen und eine Näherungsplatzierungsgruppe mit Verfügbarkeitsgruppen für jede Ebene verwenden. Verwenden Sie auf den VMs nach Möglichkeit den beschleunigten Netzwerkbetrieb. Dieses Szenario ermöglicht eine der niedrigsten Netzwerklatenzen in Azure und einen Servicelevel von 99,95 %.

Sie können die folgenden Tools verwenden, um einen besseren Einblick in die Latenzbedingungen für eine Vielzahl von Szenarien zu erhalten:

  • Informationen zum Testen der Latenz zwischen VMs finden Sie unter Testen der VM-Netzwerklatenz.
  • Verwenden Sie AvZone-Latency-Test zum Testen der Latenz zwischen Zonen. Mit diesem Test können Sie ermitteln, welche logischen Zonen über die geringste Latenz für Ihr Abonnement verfügen.
  • Nutzen Sie http://www.azurespeed.com/, um die Latenz zwischen Azure-Regionen zu testen. Dieses Tool wird regelmäßig aktualisiert und kann nützlich sein, wenn Sie die Nutzung der asynchronen Replikation zwischen Regionen erwägen.

Notfallwiederherstellung

Zu den wichtigen Aspekten der Notfallwiederherstellung gehören die Verfügbarkeit (unterbrechungsfreie Ausführung der App im fehlerfreien Zustand) und die Dauerhaftigkeit der Daten (sichere Speicherung der Daten im Notfall).

Failover zur Erzielung von Hochverfügbarkeit sollten schnell und ohne Datenverlust erfolgen und nur sehr geringe Auswirkungen auf den Dienst haben. Für ein herkömmliches Failover für die Notfallwiederherstellung gelten für Recovery Time Objective (RTO) und Recovery Point Objective (RPO) unter Umständen höhere Werte. Darüber hinaus ist der Vorgang asynchron, und es kann zu potenziellen Datenverlusten kommen.

Sie können die Verfügbarkeitszonen sowohl für hohe Verfügbarkeit als auch für die Notfallwiederherstellung nutzen, indem Sie eine andere Verfügbarkeitszone für Ihre Notfallwiederherstellungslösung verwenden. Verfügbarkeitszonen sind nahe genug, um Verbindungen mit geringer Latenz zu anderen Verfügbarkeitszonen herzustellen (Roundtrip-Latenz von weniger als 2 ms). Die Verfügbarkeitszonen sind jedoch weit genug voneinander entfernt, um die Wahrscheinlichkeit zu verringern, dass mehr als eine Verfügbarkeitszone von lokalen Ausfällen oder Wetterbedingungen betroffen ist. Bei unternehmenskritischen Workloads sollten Sie eine Lösung in Betracht ziehen, die zusätzlich zu mehreren Verfügbarkeitszonen mehrere Regionen verwendet.

Mit Azure Site Recovery können Sie VMs in einer anderen Azure-Region replizieren, um die regionale Notfallwiederherstellung und Geschäftskontinuität zu ermöglichen. Sie können Azure Site Recovery nutzen, um Ihre Apps bei Ausfällen der Quellregion wiederherzustellen oder regelmäßige Übungen zur Notfallwiederherstellung durchzuführen und so für die Erfüllung von Konformitätsanforderungen zu sorgen.

Wenn Azure Site Recovery von Ihrer App unterstützt wird, können Sie den Schutz mit einer regionalen Lösung für die Notfallwiederherstellung verbessern, sofern dies aufgrund der Kritikalität der App erforderlich ist. Zonen- und rechenzentrumsübergreifende Hochverfügbarkeit allein kann aber ggf. schon ein ausreichender Schutz sein. Der Grund ist, dass es nicht zu Ausfallzeiten oder Datenverlust kommen sollte, wenn eine App gegenüber Rechenzentrumsausfällen vollständig resilient ist.

Kostenoptimierung

Für VMs, die in Verfügbarkeitszonen bereitgestellt werden, fallen keine zusätzlichen Kosten an. Für die Datenübertragung zwischen VMs in unterschiedlichen Verfügbarkeitszonen fallen unter Umständen Gebühren an. Weitere Informationen finden Sie unter Bandbreite – Preisdetails.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

Nächste Schritte