Freigeben über


Empfehlungen für die Verwendung von Verfügbarkeitszonen und Regionen

Gilt für diese Empfehlung für die Zuverlässigkeitsprüfliste des Azure Well-Architected Framework:

RE:05 Fügen Sie Redundanz auf verschiedenen Ebenen hinzu, insbesondere für kritische Flows. Wenden Sie Redundanz auf die Compute-, Daten-, Netzwerk- und anderen Infrastrukturebenen gemäß den identifizierten Zuverlässigkeitszielen an.

Verwandte Leitfäden: Hoch verfügbare multiregionale Designredundanz |

In diesem Handbuch werden die Empfehlungen beschrieben, um zu bestimmen, wann Workloads in Verfügbarkeitszonen oder Regionen bereitgestellt werden sollen.

Wenn Sie eine Lösung für Azure entwerfen, müssen Sie entscheiden, ob Sie in mehreren Verfügbarkeitszonen in einer Region oder in mehreren Regionen bereitstellen. Diese Entscheidung wirkt sich auf die Zuverlässigkeit, Kosten und Leistung Ihrer Lösung und die Fähigkeit Ihres Teams aus, die Lösung zu bedienen. Dieser Leitfaden enthält Informationen zu den wichtigsten Geschäftsanforderungen, die Ihre Entscheidung beeinflussen, die Ansätze, die Sie berücksichtigen können, die in den einzelnen Ansätzen einbezogenen Kompromisse und die Auswirkungen der einzelnen Ansätze auf die wichtigsten Säulen des Azure Well-Architected Framework.

Die Entscheidung über die besten Azure-Regionen, die für Ihre Lösung verwendet werden sollen, ist eine wichtige Wahl. Im Leitfaden " Azure-Regionen auswählen" wird beschrieben, wie Sie in mehreren geografischen Regionen auswählen und arbeiten. Ihre Wahl der Verwendung von Regionen und Verfügbarkeitszonen in Ihrer Lösung wirkt sich auch auf mehrere Säulen des Well-Architected Framework aus:

  • Zuverlässigkeit: Ihre Wahl des Bereitstellungsansatzes kann Ihnen helfen, verschiedene Arten von Risiken zu mindern. Im Allgemeinen können Sie durch die Verteilung Ihrer Arbeitsauslastung über einen geografisch verteilten Bereich eine höhere Resilienz erreichen.
  • Kostenoptimierung: Bei einigen Architekturansätzen müssen mehr Ressourcen bereitgestellt werden als andere, was ihre Ressourcenkosten erhöhen kann. Andere Ansätze umfassen das Senden von Daten über geografisch getrennte Verfügbarkeitszonen oder Regionen, was zu Netzwerkdatenverkehrsgebühren führen kann. Es ist auch wichtig, die laufenden Kosten für die Verwaltung Ihrer Ressourcen zu berücksichtigen, was in der Regel höher ist, wenn Sie über umfassende Geschäftliche Anforderungen verfügen.
  • Leistungseffizienz: Verfügbarkeitszonen werden über eine Netzwerkverbindung mit hoher Bandbreite und geringer Latenz verbunden, die für die meisten Workloads ausreicht, um synchrone Replikation und Kommunikation über die Zonen hinweg zu ermöglichen. Wenn Ihre Workload jedoch getestet wurde und für die Netzwerklatenz über Zonen hinweg vertraulich ist, müssen Sie möglicherweise in Betracht ziehen, die Komponenten Ihrer Workload in der Nähe zu finden, um die Latenz bei der Kommunikation zu minimieren.
  • Operational Excellence: Eine komplexe Architektur erfordert mehr Aufwand für die Bereitstellung, Konfiguration und Verwaltung. Darüber hinaus müssen Sie für eine hochverwendende Lösung möglicherweise planen, wie ein Failover zu einer sekundären Gruppe von Ressourcen ausgeführt werden kann. Failover, Failback und transparente Umleitung des Datenverkehrs können komplex sein, insbesondere, wenn manuelle Schritte erforderlich sind. Es empfiehlt sich, Ihre Bereitstellungs- und Verwaltungsprozesse zu automatisieren. Weitere Informationen finden Sie in den Leitfäden zur Operational Excellence-Säule, einschließlich OE:05 Infrastructure as Code, OE:09 Task Automation, OE:10 Automation Design und OE:11 Deployment Practices.

Sie entwerfen Ihre Lösung jedoch, gilt die Sicherheitssäule. In der Regel ändern Entscheidungen darüber, ob und wie Sie Verfügbarkeitszonen und Regionen verwenden, Ihren Sicherheitsstatus nicht. Azure wendet die gleiche Sicherheitsstufe auf jede Region und Verfügbarkeitszone an.

Tipp

Für viele Produktionsworkloads bietet eine zonenredundante Bereitstellung die beste Balance von Kompromissen. Sie können diesen Ansatz mit asynchroner Datensicherung auf eine andere Region erweitern. Wenn Sie nicht sicher sind, für welchen Ansatz Sie sich entscheiden sollen, beginnen Sie mit dieser Art von Bereitstellung.

Berücksichtigen Sie andere Arbeitsauslastungsansätze, wenn Sie die spezifischen Vorteile benötigen, die diese Ansätze bieten, beachten Sie jedoch die betreffenden Kompromisse.

Definitionen

Begriff Definition
Aktiv/Aktiv Eine Architektur, in der mehrere Instanzen einer Lösung aktiv Anforderungen gleichzeitig verarbeiten.
Aktiv/Passiv Eine Architektur, in der eine Instanz einer Lösung als primärer Datenverkehr festgelegt wird und eine oder mehrere sekundäre Instanzen bereitgestellt werden, um Datenverkehr zu verarbeiten, wenn die primäre Nicht verfügbar ist.
Asynchrone Replikation Ein Datenreplikationsansatz, bei dem Daten geschrieben und an einem Speicherort zugesichert werden. Zu einem späteren Zeitpunkt werden die Änderungen an einem anderen Speicherort repliziert.
Verfügbarkeitszone Eine getrennte Gruppe von Rechenzentren innerhalb einer Region. Jede Verfügbarkeitszone ist unabhängig von den anderen, mit eigener Energie-, Kühl- und Netzwerkinfrastruktur. Viele Regionen unterstützen Verfügbarkeitszonen.
Datacenter Eine Einrichtung mit Servern, Netzwerkgeräten und anderer Hardware zur Unterstützung von Azure-Ressourcen und -Workloads.
Lokal redundante Bereitstellung Ein Bereitstellungsmodell, in dem eine Ressource in einer einzelnen Region ohne Verweis auf eine Verfügbarkeitszone bereitgestellt wird. In einer Region, die Verfügbarkeitszonen unterstützt, kann die Ressource in einer der Verfügbarkeitszonen der Region bereitgestellt werden.
Bereitstellung in mehreren Regionen Ein Bereitstellungsmodell, in dem Ressourcen in mehreren Azure-Regionen bereitgestellt werden.
Regionspaare Eine Beziehung zwischen zwei Azure-Regionen. Einige Azure-Regionen sind mit einer anderen definierten Region verbunden, um bestimmte Arten von Multi-Region-Lösungen zu ermöglichen. Neuere Azure-Regionen sind nicht gekoppelt.
Region Ein geografischer Umkreis, der eine Reihe von Rechenzentren enthält.
Architektur der Region Die spezifische Konfiguration der Azure-Region, einschließlich der Anzahl der Verfügbarkeitszonen und der Kombination der Region mit einer anderen Region.
Synchrone Replikation Ein Datenreplikationsansatz, bei dem Daten geschrieben und an mehreren Standorten zugesichert werden. Jeder Speicherort muss den Abschluss des Schreibvorgangs bestätigen, bevor der gesamte Schreibvorgang als abgeschlossen betrachtet wird.
Zonal-Bereitstellung (angeheftet) Ein Bereitstellungsmodell, in dem eine Ressource in einer bestimmten Verfügbarkeitszone bereitgestellt wird.
Zonenredundante Bereitstellung Ein Bereitstellungsmodell, in dem eine Ressource in mehreren Verfügbarkeitszonen bereitgestellt wird. Microsoft verwaltet die Datensynchronisierung, die Datenverkehrsverteilung und das Failover, wenn eine Zone einen Ausfall erlebt.

Wichtige Entwurfsstrategien

Azure hat einen großen globalen Fußabdruck. Eine Azure-Region ist ein geografischer Umkreis, der eine Reihe von Rechenzentren enthält. Sie müssen über ein vollständiges Verständnis von Azure-Regionen und -Verfügbarkeitszonen verfügen.

Azure-Regionen verfügen über eine Vielzahl von Konfigurationen, die auch als Regionsarchitekturen bezeichnet werden.

Viele Azure-Regionen bieten Verfügbarkeitszonen, die getrennte Gruppen von Rechenzentren sind. Innerhalb einer Region sind Verfügbarkeitszonen nahe genug, um Verbindungen mit geringer Latenz mit anderen Verfügbarkeitszonen zu haben. Sie sind aber weit genug auseinander, um die Wahrscheinlichkeit zu verringern, dass mehrere von lokalen Ausfällen oder Wetterphänomenen betroffen ist. Verfügbarkeitszonen verfügen über eine unabhängige Strom-, Kühl- und Netzwerkinfrastruktur. Sie sind so konzipiert, dass im Falle eines Ausfalls einer Zone die regionalen Dienste, Kapazitäten und die hohe Verfügbarkeit von den übrigen Zonen unterstützt werden.

Die folgende Abbildung zeigt mehrere Beispiele für Azure-Regionen. Regionen 1 und 2 unterstützen Verfügbarkeitszonen.

Diagramm, das Rechenzentren, Verfügbarkeitszonen und Regionen zeigt.

Wenn Sie in einer Azure-Region bereitstellen, die Verfügbarkeitszonen enthält, können Sie mehrere Verfügbarkeitszonen gemeinsam verwenden. Mithilfe mehrerer Verfügbarkeitszonen können Sie separate Kopien Ihrer Anwendung und Daten innerhalb physisch separierter Rechenzentren in einem großen Ballungsbereich aufbewahren.

Es gibt zwei Möglichkeiten, Verfügbarkeitszonen in einer Lösung zu verwenden:

  • Zonale Ressourcen sind an eine bestimmte Verfügbarkeitszone gebunden. Sie können mehrere zonale Bereitstellungen über verschiedene Zonen hinweg kombinieren, um hohe Zuverlässigkeitsanforderungen zu erfüllen. Sie sind für die Verwaltung der Datenreplikation und die Verteilung der Anfragen auf die Zonen zuständig. Wenn ein Ausfall in einer einzelnen Verfügbarkeitszone auftritt, sind Sie für den Failover in eine andere Verfügbarkeitszone verantwortlich.
  • Zonenredundante Ressourcen sind über mehrere Verfügbarkeitszonen verteilt. Microsoft verwaltet die zonenübergreifende Verteilung von Anfragen und die zonenübergreifende Replikation von Daten. Wenn ein Ausfall in einer einzelnen Verfügbarkeitszone auftritt, verwaltet Microsoft das Failover automatisch.

Azure-Dienste unterstützen einen oder beide dieser Ansätze. Plattform-as-a-Service-Dienste (PaaS) unterstützen in der Regel zonenredundante Bereitstellungen. Infrastruktur-as-a-Service (IaaS)-Dienste unterstützen in der Regel zonale Bereitstellungen. Weitere Informationen zur Funktionsweise von Azure-Diensten mit Verfügbarkeitszonen finden Sie unter Azure-Dienste mit Unterstützung für Verfügbarkeitszonen.

Wenn Microsoft Updates für Dienste bereitstellt, versuchen wir, Ansätze zu verwenden, die für Sie am wenigsten störend sind. Wir wollen z. B. Aktualisierungen in einer einzelnen Verfügbarkeitszone gleichzeitig bereitstellen. Dieser Ansatz kann die Auswirkungen verringern, die updates möglicherweise auf eine aktive Workload haben, da die Workload weiterhin in anderen Zonen ausgeführt werden kann, während das Update ausgeführt wird. Letztendlich ist es jedoch die Verantwortung des Workloadteams, sicherzustellen, dass ihre Arbeitsauslastung während Plattformupgrades weiterhin funktioniert. Wenn Sie beispielsweise Skalierungssätze für virtuelle Computer mit dem flexiblen Orchestrierungsmodus oder den meisten Azure PaaS-Diensten verwenden, platziert Azure Ihre Ressourcen intelligent, um die Auswirkungen von Plattformupdates zu verringern. Darüber hinaus können Sie die Überprovisionierung – Bereitstellen weiterer Instanzen einer Ressource – in Betracht ziehen, sodass einige Instanzen verfügbar bleiben, während andere Instanzen aktualisiert werden. Weitere Informationen darüber, wie Azure Updates bereitstellt, finden Sie unter Weiterentwicklung sicherer Bereitstellungsmethoden.

Viele Regionen verfügen auch über eine gekoppelte Region. Gekoppelte Regionen unterstützen bestimmte Arten von Multi-Region-Bereitstellungsansätzen. Einige neuere Regionen verfügen über mehrere Verfügbarkeitszonen und haben keine gekoppelte Region. Sie können immer noch Lösungen für mehrere Regionen in diesen Regionen einsetzen, aber die Ansätze, die Sie verwenden, könnten anders sein.

Weitere Informationen dazu, wie Azure Regionen und Verfügbarkeitszonen verwendet, finden Sie unter Was sind Azure-Regionen und Verfügbarkeitszonen?

Grundlegendes zu geteilten Zuständigkeiten

Das Prinzip der gemeinsamen Verantwortung beschreibt, wie die Verantwortlichkeiten zwischen dem Cloudanbieter (Microsoft) und Ihnen aufgeteilt werden. Je nach Art der von Ihnen genutzten Dienste übernehmen Sie mehr oder weniger Verantwortung für den Betrieb des Dienstes.

Microsoft bietet Ihnen Verfügbarkeitszonen und Regionen, damit Sie Ihre Lösung flexibel gestalten können, um Ihren Anforderungen gerecht zu werden. Wenn Sie verwaltete Dienste in Anspruch nehmen, übernimmt Microsoft einen größeren Teil der Verwaltungsaufgaben für Ihre Ressourcen, die sogar Datenreplikation, Failover, Failback und andere Aufgaben im Zusammenhang mit dem Betrieb eines verteilten Systems umfassen können.

Ihr eigener Code muss bewährte Methoden und Entwurfsmuster für die ordnungsgemäße Behandlung von Fehlern empfehlen. Diese Methoden sind noch wichtiger bei Failovervorgängen, z. B. solche, die auftreten, wenn eine Verfügbarkeitszone oder ein Regionsfailover auftritt, da failover zwischen Zonen oder Regionen in der Regel erfordert, dass Ihre Anwendung Verbindungen mit Diensten erneut versucht.

Identifizieren wichtiger Geschäfts- und Workloadanforderungen

Um eine fundierte Entscheidung über die Verwendung von Verfügbarkeitszonen und Regionen in Ihrer Lösung zu treffen, müssen Sie Ihre Anforderungen verstehen. Diese Anforderungen sollten durch Diskussionen zwischen Lösungsdesignern und Geschäftsbeteiligten gesteuert werden.

Risikotoleranz

Unterschiedliche Organisationen haben unterschiedliche Risikotoleranz. Auch innerhalb einer Organisation unterscheidet sich die Risikotoleranz häufig für jede Arbeitsauslastung. Die meisten Workloads benötigen keine extrem hohe Verfügbarkeit. Einige Arbeitslasten sind jedoch so wichtig, dass es sich sogar lohnt, Risiken zu verringern, die unwahrscheinlich sind, wie große Naturkatastrophen, die sich auf ein breites geografisches Gebiet auswirken.

In dieser Tabelle sind einige der allgemeinen Risiken aufgeführt, die Sie in einer Cloudumgebung berücksichtigen sollten:

Risiko Beispiele Wahrscheinlichkeit
Hardwareausfall Problem mit Festplatten- oder Netzwerkgeräten.

Hostneustarts.
Hoch. Jede Resilienzstrategie sollte diese Risiken berücksichtigen.
Ausfall des Rechenzentrums Strom-, Kühl- oder Netzwerkausfall über ein gesamtes Rechenzentrum hinweg.

Naturkatastrophen in einem Teil einer Metropolregion.
Medium
Regionsausfall Große Naturkatastrophen, die sich auf ein breites geografisches Gebiet auswirken.

Netzwerk- oder Dienstproblem, das einen oder mehrere Azure-Dienste in einer gesamten Region nicht verfügbar macht.
Niedrig

Es wäre ideal, jedes mögliche Risiko für jede Workload abzumildern, aber es ist nicht praktisch oder kosteneffizient, dies zu tun. Es ist wichtig, eine offene Diskussion mit den Geschäftsbeteiligten zu führen, damit Sie fundierte Entscheidungen über die Risiken treffen können, die Sie mindern sollten.

Tipp

Unabhängig von Zuverlässigkeitszielen müssen alle Workloads eine Risikominderung für die Notfallwiederherstellung haben. Wenn Ihre Workload hohe Zuverlässigkeitsziele erfordert, sollten Ihre Risikominderungsstrategien umfassend sein, und Sie sollten das Risiko sogar von Ereignissen mit niedriger Wahrscheinlichkeit verringern. Treffen Sie für andere Workloads eine fundierte Entscheidung darüber, welche Risiken Sie akzeptieren möchten und welche Sie mindern müssen.

Resilienzanforderungen

Es ist wichtig, die Resilienzanforderungen für Ihre Workload zu verstehen, einschließlich des Wiederherstellungszeitziels (RTO) und des Wiederherstellungspunktziels (RPO). Diese Ziele helfen Ihnen zu entscheiden, welche Ansätze ausgeschlossen werden sollen. Wenn Sie keine klaren Anforderungen haben, können Sie keine fundierte Entscheidung darüber treffen, welchem Ansatz Sie folgen sollen. Weitere Informationen finden Sie unter Zielfunktions- und Nichtfunktionsanforderungen.

Servicelevel-Zielpunkte (SLO)

Sie sollten das erwartete Ziel der Betriebszeit-Service-Level (SLO) Ihrer Lösung verstehen. Sie können beispielsweise eine geschäftliche Anforderung haben, dass Ihre Lösung 99,9 % Uptime erfüllen muss.

Azure bietet Vereinbarungen zum Servicelevel (Service Level Agreements, SLAs) für jeden Dienst. Eine SLA gibt die Verfügbarkeitsebene an, die Sie von dem Dienst und den Bedingungen erwarten sollten, die Sie erfüllen müssen, um diese erwartete SLA zu erreichen. Denken Sie jedoch daran, dass die Art und Weise, wie eine Azure SLA angibt, die Verfügbarkeit des Diensts nicht immer mit der Art und Weise übereinstimmt, wie Sie die Integrität Ihrer Workload berücksichtigen.

Ihre Architekturentscheidungen wirken sich auf die zusammengesetzte SLO Ihrer Lösung aus. Je mehr Redundanz Sie in Ihre Lösung integrieren, desto höher ist Wahrscheinlichkeit, dass Ihr SLO höher ist. Viele Azure-Dienste bieten höhere SLAs, wenn Sie Dienste in einer zonenredundanten oder multiregionsübergreifenden Konfiguration bereitstellen. Überprüfen Sie die SLAs für jeden von Ihnen verwendeten Azure-Dienst, um sicherzustellen, dass Sie verstehen, wie Sie die Resilienz und SLA des Diensts maximieren.

Datenresidenz

Einige Organisationen setzen Einschränkungen für die physischen Speicherorte ein, in denen ihre Daten gespeichert und verarbeitet werden können. Manchmal basieren diese Anforderungen auf rechtlichen oder behördlichen Standards. In anderen Situationen kann sich eine Organisation entscheiden, eine Data Residency-Richtlinie zu übernehmen, um Kundenbedenken zu vermeiden. Wenn Sie strenge Anforderungen an die Datenhaltung haben, müssen Sie möglicherweise eine Bereitstellung mit einer Region oder eine Teilmenge von Azure-Regionen und -Diensten verwenden.

Hinweis

Vermeiden Sie es, unbegründete Annahmen über Ihre Datenhaltungsanforderungen zu treffen. Wenn Sie bestimmte behördliche Standards einhalten müssen, überprüfen Sie, was diese Standards tatsächlich angeben.

Benutzerlagerplatz

Indem Sie verstehen, wo sich Ihre Benutzer befinden, können Sie eine fundierte Entscheidung darüber treffen, wie Latenz und Zuverlässigkeit für Ihre Anforderungen optimiert werden. Azure bietet viele Optionen zur Unterstützung einer geografisch verteilten Benutzerbasis.

Wenn sich Ihre Benutzer auf einen Bereich konzentrieren, kann eine Bereitstellung mit einer regionspezifischen Bereitstellung Ihre betrieblichen Anforderungen vereinfachen und Ihre Kosten reduzieren. Sie müssen jedoch überlegen, ob eine Bereitstellung mit einer Region Ihre Zuverlässigkeitsanforderungen erfüllt. Bei unternehmenskritischen Anwendungen sollten Sie weiterhin eine Bereitstellung mit mehreren Regionen verwenden, auch wenn Ihre Benutzer kolociert sind.

Wenn Ihre Benutzer geografisch verteilt sind, kann es sinnvoll sein, Ihre Arbeitsauslastung in mehreren Regionen bereitzustellen. Azure-Dienste bieten unterschiedliche Funktionen zur Unterstützung einer Bereitstellung mit mehreren Regionen, und Sie können den globalen Standort von Azure verwenden, um Ihre Benutzererfahrung zu verbessern und Ihre Anwendungen näher zu Ihrer Benutzerbasis zu bringen. Sie können das Bereitstellungsstempelmuster oder das Geodes-Muster verwenden oder Ihre Ressourcen in mehreren Regionen replizieren.

Auch wenn sich Ihre Benutzer in verschiedenen geografischen Gebieten befinden, überlegen Sie, ob Sie eine Bereitstellung mit mehreren Regionen benötigen. Überlegen Sie, ob Sie Ihre Anforderungen innerhalb einer einzelnen Region erreichen können, indem Sie die globale Datenverkehrsbeschleunigung verwenden, z. B. die von Azure Front Door bereitgestellte Beschleunigung.

Budget

Wenn Sie unter einem eingeschränkten Budget arbeiten, ist es wichtig, die Kosten für die Bereitstellung redundanter Workload-Komponenten zu berücksichtigen. Diese Kosten können zusätzliche Ressourcengebühren, Netzwerkkosten und die Betriebskosten für die Verwaltung weiterer Ressourcen und eine komplexere Umgebung umfassen.

Komplexität

Es empfiehlt sich, unnötige Komplexität in Ihrer Lösungsarchitektur zu vermeiden. Je mehr Komplexität Sie einführen, desto schwieriger wird es, Entscheidungen über Ihre Architektur zu treffen. Komplexe Architekturen sind schwieriger zu bedienen, schwieriger zu sichern und oft weniger leistungsfähig. Folgen Sie dem Prinzip der Einfachheit.

Azure-Erleichterung

Durch die Bereitstellung von Regionen und Verfügbarkeitszonen können Sie einen Bereitstellungsansatz auswählen, der Ihren Anforderungen entspricht. Es gibt viele Ansätze, aus denen Sie wählen können, von denen jeder Vorteile bietet und Kosten verursacht.

Um die Bereitstellungsansätze zu veranschaulichen, die Sie verwenden können, betrachten Sie ein Beispielszenario. Angenommen, Sie denken daran, eine neue Lösung bereitzustellen, die eine Anwendung enthält, die Daten in eine Art Speicher schreibt:

Diagramm, das zeigt, dass ein Benutzer eine Verbindung mit einer Anwendung herstellt, die eine Verbindung mit dem Speicher herstellt.

Dieses Beispiel ist nicht spezifisch für bestimmte Azure-Dienste. Es soll ein einfaches Beispiel zur Veranschaulichung grundlegender Konzepte sein.

Es gibt mehrere Möglichkeiten, diese Lösung bereitzustellen. Jeder Ansatz bietet eine andere Reihe von Vorteilen und verursacht unterschiedliche Kosten. Auf hoher Ebene können Sie eine lokal redundante, zonal (angeheftete) bereitstellung, zonenredundant oder multiregionsübergreifende Bereitstellung in Betracht ziehen. In dieser Tabelle sind einige der Bedenken der Säule zusammengefasst:

Säule Lokal redundant Zonal (angeheftet) Zonenredundant Mehrere Regionen
Zuverlässigkeit Geringe Zuverlässigkeit Hängt vom Ansatz ab Hohe oder sehr hohe Zuverlässigkeit Hohe oder sehr hohe Zuverlässigkeit
Kostenoptimierung Niedrige Kosten Hängt vom Ansatz ab Moderate Kosten Hohe Kosten
Effiziente Leistung Akzeptable Leistung (für die meisten Workloads) Hohe Leistung Akzeptable Leistung (für die meisten Workloads) Hängt vom Ansatz ab
Optimaler Betrieb Niedrige betriebliche Anforderungen Hohe betriebliche Anforderungen Niedrige betriebliche Anforderungen Hohe betriebliche Anforderungen

In dieser Tabelle sind einige der Ansätze zusammengefasst, die Sie verwenden können und wie sie sich auf Ihre Architektur auswirken:

Architektonisches Anliegen Lokal redundant Zonal (angeheftet) Zonenredundant Mehrere Regionen
Einhaltung der Datenhaltung High High High Abhängig von Region
Regionale Verfügbarkeit Alle Regionen Regionen mit Verfügbarkeitszonen Regionen mit Verfügbarkeitszonen Abhängig von Region

Der Rest dieses Artikels beschreibt die einzelnen Ansätze, die in der vorherigen Tabelle aufgeführt sind. Die Liste der Ansätze ist nicht erschöpfend. Sie können mehrere Ansätze kombinieren oder unterschiedliche Ansätze in verschiedenen Teilen Ihrer Lösung verwenden.

Bereitstellungsansatz 1: Lokal redundante Bereitstellungen

Wenn Sie beim Bereitstellen Ihrer Ressourcen nicht mehrere Verfügbarkeitszonen oder Regionen angeben, garantiert Azure nicht, ob die Ressourcen in einem einzigen Rechenzentrum bereitgestellt oder auf mehrere Rechenzentren in der Region aufgeteilt werden. In einigen Situationen kann Azure Ihre Ressource auch zwischen Verfügbarkeitszonen verschieben.

Diagramm, das die in einem einzigen Rechenzentrum bereitgestellte Lösung in einer einzigen Verfügbarkeitszone zeigt.

Die meisten Azure-Ressourcen sind standardmäßig hoch verfügbar, mit hohen SLAs und integrierter Redundanz innerhalb eines Rechenzentrums, das von der Plattform verwaltet wird. Wenn jedoch ein Teil der Region einen Ausfall erlebt, besteht aus Zuverlässigkeitsperspektive die Möglichkeit, dass Ihre Arbeitsauslastung beeinträchtigt wird. Wenn dies der Grund ist, ist Ihre Lösung möglicherweise nicht verfügbar, oder Ihre Daten gehen verloren.

Bei hochwartensiblen Workloads kann dieser Ansatz auch zu einer geringeren Leistung führen. Ihre Workloadkomponenten werden möglicherweise nicht im selben Rechenzentrum verortet, sodass Sie möglicherweise eine Latenz für datenverkehrsinterne Regionen beobachten. Azure kann Ihre Dienstinstanzen auch transparent zwischen Verfügbarkeitszonen verschieben, was sich leicht auf die Leistung auswirken kann. Dies ist jedoch keine Sorge für die meisten Workloads.

In dieser Tabelle sind einige der Bedenken der Säule zusammengefasst:

Säule Auswirkung
Zuverlässigkeit Geringe Zuverlässigkeit. Dienste unterliegen Ausfallen, wenn ein Rechenzentrum fehlschlägt. Sie können jedoch eine Anwendung erstellen, die für andere Arten von Fehlern widerstandsfähig ist.
Kostenoptimierung Niedrigste Kosten. Sie müssen nur über eine einzelne Instanz jeder Ressource verfügen, und Es entstehen keine Kosten für die bandbreitenübergreifende Bandbreite.
Effiziente Leistung Für die meisten Workloads: Akzeptable Leistung. Dieser Ansatz wird wahrscheinlich zufriedenstellende Leistung bieten.

Bei hochwartensiblen Workloads: Geringe Leistung. Komponenten sind nicht garantiert, dass sie sich in derselben Verfügbarkeitszone befinden, daher wird möglicherweise eine niedrigere Leistung für hochlatenzempfindliche Komponenten angezeigt.
Optimaler Betrieb Hohe betriebliche Effizienz. Sie müssen nur eine einzelne Instanz jeder Ressource bereitstellen und verwalten.

In dieser Tabelle sind einige der Bedenken aus architektonischer Sicht zusammengefasst:

Architektonisches Anliegen Auswirkung
Einhaltung der Datenhaltung Hoch. Wenn Sie eine Lösung bereitstellen, die diesen Ansatz verwendet, werden Daten in der von Ihnen ausgewählten Azure-Region gespeichert.
Regionale Verfügbarkeit Hoch. Dieser Ansatz kann in einer beliebigen Azure-Region verwendet werden.

Lokal redundante Bereitstellungen mit Sicherung über Regionen hinweg

Sie können eine lokal redundante Bereitstellung erweitern, indem Sie regelmäßige Sicherungen Ihrer Infrastruktur und Ihrer Daten auf eine sekundäre Region durchführen. Dieser Ansatz fügt eine zusätzliche Schutzebene hinzu, um einen Ausfall in Ihrer primären Region abzumildern. Das Fenster sieht so aus:

Diagramm, das die in einem einzigen Rechenzentrum bereitgestellte Lösung mit Sicherungen in einer anderen Region zeigt.

Wenn Sie diesen Ansatz implementieren, müssen Sie Ihre RTO und RPO sorgfältig berücksichtigen:

  • Wiederherstellungszeit: Wenn ein regionaler Ausfall auftritt, müssen Sie Ihre Lösung möglicherweise in einer anderen Azure-Region neu erstellen, was sich auf Ihre Wiederherstellungszeit auswirkt. Erwägen Sie, Ihre Lösung mithilfe eines IaC-Ansatzes (Infrastructure-as-Code) zu erstellen, damit Sie schnell in einer anderen Region erneut bereitstellen können, wenn eine große Katastrophe auftritt. Stellen Sie sicher, dass Ihre Bereitstellungstools und -prozesse genauso robust sind wie Ihre Anwendungen, damit Sie sie verwenden können, um Ihre Lösung erneut bereitzustellen, auch wenn ein Ausfall vorhanden ist. Planen Und testen Sie die Schritte, die erforderlich sind, um Ihre Lösung wieder in einen Arbeitszustand zurückzusetzen.
  • Wiederherstellungspunkt: Ihre Sicherungshäufigkeit bestimmt die Menge des Datenverlusts, den Sie möglicherweise erleben (Ihren Wiederherstellungspunkt). In der Regel können Sie die Häufigkeit von Sicherungen steuern, damit Sie Ihr RPO erfüllen können.

In dieser Tabelle sind einige der Bedenken der Säule zusammengefasst:

Säule Auswirkung
Zuverlässigkeit Moderate Zuverlässigkeit. Dienste unterliegen Ausfallen, wenn ein Rechenzentrum fehlschlägt. Daten werden asynchron in einer geografisch getrennten Region gesichert, wodurch der Effekt eines vollständigen Regionsausfalls durch Minimierung des Datenverlusts reduziert wird. In einem vollständigen Regionsausfall können Sie Vorgänge manuell in eine andere Region wiederherstellen. Wiederherstellungsprozesse können jedoch komplex sein, und es kann zeitaufwendig sein, manuell in die andere Region wiederherzustellen.
Kostenoptimierung Niedrige Kosten. In der Regel kostet das Hinzufügen einer Sicherung zu einer anderen Region nur etwas mehr als die Bereitstellung einer lokal redundanten Ressource.
Effiziente Leistung Für die meisten Workloads: Akzeptable Leistung. Dieser Ansatz wird wahrscheinlich zufriedenstellende Leistung bieten.

Bei hochwartensiblen Workloads: Geringe Leistung. Komponenten sind nicht garantiert, dass sie sich in derselben Verfügbarkeitszone befinden, daher wird möglicherweise eine niedrigere Leistung für hochlatenzempfindliche Komponenten angezeigt.
Optimaler Betrieb Während eines Ausfalls innerhalb einer Region: Geringe betriebliche Effizienz. Failover liegt in Ihrer Verantwortung und erfordert möglicherweise manuelle Vorgänge und erneute Bereitstellungen.

In dieser Tabelle sind einige der Bedenken aus architektonischer Sicht zusammengefasst:

Architektonisches Anliegen Auswirkung
Einhaltung der Datenhaltung Hängt von der Bereichsauswahl ab. Daten werden in erster Linie in der von Ihnen angegebenen Azure-Region gespeichert. Sie müssen jedoch eine andere Region auswählen, um Ihre Sicherungen zu speichern. Daher ist es wichtig, dass Sie eine Region auswählen, die mit Ihren Anforderungen an die Datenhaltung kompatibel ist.
Regionale Verfügbarkeit Hoch. Sie können diesen Ansatz in einer beliebigen Azure-Region verwenden.

Bereitstellungsansatz 2: Zonal-Bereitstellungen (angeheftet)

In einer zonalen Bereitstellung geben Sie an, dass Ihre Ressourcen in einer bestimmten Verfügbarkeitszone bereitgestellt werden sollen. Dieser Ansatz wird manchmal als zonenanheftete Bereitstellung bezeichnet.

Diagramm, das die in einer bestimmten Verfügbarkeitszone bereitgestellte Lösung zeigt. Es wird ein  zonaler Bereitstellungsansatz verwendet.

Ein zonaler Ansatz reduziert die Latenz zwischen Ihren Komponenten. Die Resilienz Ihrer Lösung wird jedoch selbst nicht erhöht. Um Ihre Resilienz zu erhöhen, müssen Sie mehrere Instanzen Ihrer Komponenten in mehreren Verfügbarkeitszonen bereitstellen und entscheiden, wie der Datenverkehr zwischen den einzelnen Instanzen weitergeleitet werden soll. Dieses Beispiel zeigt einen passiven Datenverkehrsroutingansatz:

Diagramm, das die In mehreren Verfügbarkeitszonen bereitgestellte Lösung zeigt. Es wird ein passiver Datenverkehrsroutingansatz verwendet.

Im vorherigen Beispiel wird ein Lastenausgleich in mehreren Verfügbarkeitszonen bereitgestellt. Es ist wichtig zu berücksichtigen, wie Sie den Datenverkehr zwischen Instanzen in verschiedenen Verfügbarkeitszonen weiterleiten, da sich ein Zonenausfall auch auf die in dieser Zone bereitgestellten Netzwerkressourcen auswirken kann. Sie können auch einen globalen Lastenausgleich verwenden, z . B. Azure Front Door oder Azure Traffic Manager, der überhaupt nicht in einer Region bereitgestellt wird.

Wenn Sie ein zonales Bereitstellungsmodell verwenden, übernehmen Sie viele Aufgaben:

  • Sie müssen Ressourcen für jede Verfügbarkeitszone bereitstellen und diese Ressourcen einzeln konfigurieren und verwalten.
  • Sie müssen entscheiden, wie und wann Daten zwischen den Verfügbarkeitszonen repliziert werden sollen, und dann die Replikation konfigurieren und verwalten.
  • Sie sind dafür verantwortlich, die Anforderungen mithilfe eines Lastenausgleichs an die richtigen Ressourcen zu verteilen. Sie müssen sicherstellen, dass der Lastenausgleich Ihre Resilienzanforderungen erfüllt. Sie müssen auch entscheiden, ob sie ein aktives passives oder ein aktives Anforderungsverteilungsmodell verwenden möchten.
  • Wenn eine Verfügbarkeitszone einen Ausfall erlebt, müssen Sie das Failover behandeln, um Datenverkehr an Ressourcen in einer anderen Verfügbarkeitszone zu senden.

Eine aktiv-passive Bereitstellung über mehrere Verfügbarkeitszonen hinweg wird manchmal als In-Region-DR oder Metro-DR bezeichnet.

In dieser Tabelle sind einige der Bedenken der Säule zusammengefasst:

Säule Auswirkung
Zuverlässigkeit Wenn Sie in einer einzelnen Verfügbarkeitszone bereitgestellt werden: Niedrige Zuverlässigkeit. Eine Zonalbereitstellung bietet keine Resilienz für einen Ausfall in einem Rechenzentrum oder einer Verfügbarkeitszone. Sie müssen redundante Ressourcen in mehreren Verfügbarkeitszonen bereitstellen, um hohe Resilienz zu erzielen.

Wenn Sie in mehreren Verfügbarkeitszonen bereitgestellt werden: Hohe Zuverlässigkeit. Dienste können ausfallsicher für ein Rechenzentrum oder einen Ausfall der Verfügbarkeitszone gemacht werden.
Kostenoptimierung Wenn Sie in einer einzelnen Verfügbarkeitszone bereitgestellt werden: Niedrige Kosten. Für eine Bereitstellung mit einer Zone ist nur eine einzelne Instanz jeder Ressource erforderlich.

Wenn Sie in mehreren Verfügbarkeitszonen bereitgestellt werden: Hohe Kosten. Sie stellen mehrere Instanzen der Ressourcen bereit, von denen jede separat in Rechnung gestellt wird.
Effiziente Leistung Hohe Leistung. Die Latenz kann sehr niedrig sein, wenn sich die Komponenten, die eine Anforderung erfüllen, in derselben Verfügbarkeitszone befinden.
Optimaler Betrieb Geringe betriebliche Effizienz. Sie müssen mehrere Instanzen Ihres Diensts konfigurieren und verwalten. Sie müssen Daten zwischen Verfügbarkeitszonen replizieren. Während eines Ausfalls der Verfügbarkeitszone liegt das Failover in Ihrer Verantwortung.

In dieser Tabelle sind einige der Bedenken aus architektonischer Sicht zusammengefasst:

Architektonisches Anliegen Auswirkung
Einhaltung der Datenhaltung Hoch. Wenn Sie eine Lösung bereitstellen, die diesen Ansatz verwendet, werden Daten in der von Ihnen ausgewählten Azure-Region gespeichert.
Regionale Verfügbarkeit Regionen mit Verfügbarkeitszonen. Dieser Ansatz ist in jeder Region verfügbar, die Verfügbarkeitszonen unterstützt.

Dieser Ansatz wird in der Regel für Workloads verwendet, die auf virtuellen Computern basieren. Eine vollständige Liste der Dienste, die zonalbereitstellungen unterstützen, finden Sie unter Verfügbarkeitszonendienst und regionaler Support.

Stellen Sie beim Planen einer Zonalbereitstellung sicher, dass die von Ihnen verwendeten Azure-Dienste in den Verfügbarkeitszonen unterstützt werden, die Sie verwenden möchten. Wenn Sie beispielsweise auflisten möchten, welche SKUs für virtuelle Computer in jeder Verfügbarkeitszone verfügbar sind, lesen Sie die Verfügbarkeit der VM-SKU.

Tipp

Wenn Sie eine Ressource in einer bestimmten Verfügbarkeitszone bereitstellen, wählen Sie die Zonennummer aus. Die Reihenfolge der Zonennummern unterscheidet sich für jedes Azure-Abonnement. Wenn Sie Ressourcen in mehreren Azure-Abonnements bereitstellen, überprüfen Sie die Zonennummern, die Sie in jedem Abonnement verwenden sollten. Weitere Informationen finden Sie unter Physische und logische Verfügbarkeitszonen.

Bereitstellungsansatz 3: Zonenredundante Bereitstellungen

Wenn Sie diesen Ansatz verwenden, wird Ihre Anwendungsebene über mehrere Verfügbarkeitszonen verteilt. Wenn Anforderungen eingehen, verteilt ein lastenausgleichsmodul, der in den Dienst integriert ist (der sich selbst über Verfügbarkeitszonen erstreckt) die Anforderungen über die Instanzen in jeder Verfügbarkeitszone. Wenn eine Verfügbarkeitszone einen Ausfall aufweist, leitet der Lastenausgleichsmodul Datenverkehr an Instanzen in den fehlerfreien Verfügbarkeitszonen weiter.

Ihre Speicherebene ist auch über mehrere Verfügbarkeitszonen verteilt. Kopien der Anwendungsdaten werden über die synchrone Replikation über mehrere Verfügbarkeitszonen verteilt. Wenn die Anwendung änderungen an Daten vorlegt, schreibt der Speicherdienst die Änderung in mehrere Verfügbarkeitszonen, und die Transaktion gilt nur dann als abgeschlossen, wenn alle diese Änderungen abgeschlossen sind. Dieser Prozess stellt sicher, dass jede Verfügbarkeitszone immer über eine aktuelle Kopie der Daten verfügt. Wenn eine Verfügbarkeitszone einen Ausfall erlebt, kann eine andere Verfügbarkeitszone verwendet werden, um auf dieselben Daten zuzugreifen.

Diagramm, das die In mehreren Verfügbarkeitszonen bereitgestellte Lösung zeigt. Es wird ein zonenredundanter Bereitstellungsansatz verwendet.

Ein zonenredundanter Ansatz erhöht die Resilienz Ihrer Lösung auf Probleme wie Rechenzentrumsausfälle. Da Daten synchron repliziert werden, muss Ihre Anwendung jedoch warten, bis die Daten an mehreren separaten Standorten geschrieben werden, die sich möglicherweise in verschiedenen Teilen einer Metropolregion befinden. Bei den meisten Anwendungen ist die Latenz, die an der Kommunikation zwischen Zonen beteiligt ist, vernachlässigbar. Bei einigen stark latenzempfindlichen Workloads kann die synchrone Replikation über Verfügbarkeitszonen hinweg jedoch die Leistung der Anwendung beeinträchtigen.

In dieser Tabelle sind einige der Bedenken der Säule zusammengefasst:

Säule Auswirkung
Zuverlässigkeit Hohe Zuverlässigkeit. Dienste sind ausfallsicher für einen Ausfall eines Rechenzentrums oder einer Verfügbarkeitszone. Daten werden synchron über Verfügbarkeitszonen hinweg repliziert und ohne Verzögerung.
Kostenoptimierung Moderate Kosten. Je nachdem, welche Dienste Sie verwenden, fallen möglicherweise einige Kosten für höhere Dienstebenen an, um Zonenredundanz zu ermöglichen.
Effiziente Leistung Für die meisten Workloads: Akzeptable Leistung. Dieser Ansatz wird wahrscheinlich zufriedenstellende Leistung bieten.

Bei hochwartensiblen Workloads: Geringe Leistung. Einige Komponenten sind aufgrund des datenverkehrsübergreifenden Datenverkehrs oder der Datenreplikationszeit möglicherweise auf Latenz empfindlich.
Optimaler Betrieb Hohe betriebliche Effizienz. Normalerweise müssen Sie nur eine einzige logische Instanz jeder Ressource verwalten. Bei den meisten Diensten liegt das Failover während eines Ausfalls der Verfügbarkeitszone in der Verantwortung von Microsoft und erfolgt automatisch.

In dieser Tabelle sind einige der Bedenken aus architektonischer Sicht zusammengefasst:

Architektonisches Anliegen Auswirkung
Einhaltung der Datenhaltung Hoch. Wenn Sie eine Lösung bereitstellen, die diesen Ansatz verwendet, werden Daten in der von Ihnen ausgewählten Azure-Region gespeichert.
Regionale Verfügbarkeit Regionen mit Verfügbarkeitszonen. Dieser Ansatz ist in jeder Region verfügbar, die Verfügbarkeitszonen unterstützt.

Dieser Ansatz ist mit vielen Azure-Diensten möglich, einschließlich Azure Virtual Machine Scale Sets, Azure-App Service, Azure Functions, Azure Kubernetes Service, Azure Storage, Azure SQL, Azure Service Bus und vielen anderen. Eine vollständige Liste der Dienste, die Zonenredundanz unterstützen, finden Sie unter Verfügbarkeitszonendienst und regionaler Support.

Zonenredundante Bereitstellungen mit Sicherung in allen Regionen

Sie können eine zonenredundante Bereitstellung erweitern, indem Sie regelmäßige Sicherungen Ihrer Infrastruktur und Ihrer Daten auf eine sekundäre Region durchführen. Dieser Ansatz bietet Ihnen die Vorteile eines zonenredundanten Ansatzes und fügt eine Schutzebene hinzu, um das extrem unwahrscheinliche Ereignis eines vollständigen Regionsausfalls zu mindern.

Diagramm, das zeigt, dass die Lösung in mehreren Verfügbarkeitszonen in einer zonenredundanten Bereitstellung mit Sicherungen in einer anderen Region bereitgestellt wird.

Wenn Sie diesen Ansatz implementieren, müssen Sie Ihre RTO und RPO sorgfältig berücksichtigen:

  • Wiederherstellungszeit: Wenn ein regionaler Ausfall auftritt, müssen Sie Ihre Lösung möglicherweise in einer anderen Azure-Region neu erstellen, was sich auf Ihre Wiederherstellungszeit auswirkt. Erwägen Sie, Ihre Lösung mithilfe eines IaC-Ansatzes zu erstellen, damit Sie während einer großen Katastrophe schnell in eine andere Region erneut bereitstellen können. Stellen Sie sicher, dass Ihre Bereitstellungstools und -prozesse genauso robust sind wie Ihre Anwendungen, damit Sie sie verwenden können, um Ihre Lösung erneut bereitzustellen, auch wenn ein Ausfall auftritt. Planen Und testen Sie die Schritte, die erforderlich sind, um Ihre Lösung wieder in einen Arbeitszustand zurückzusetzen.

  • Wiederherstellungspunkt: Ihre Sicherungshäufigkeit bestimmt die Menge des Datenverlusts, den Sie möglicherweise erleben (Ihren Wiederherstellungspunkt). Normalerweise können Sie die Häufigkeit von Sicherungen steuern, um Ihr RPO zu erfüllen.

Tipp

Dieser Ansatz bietet häufig ein gutes Gleichgewicht für alle architektonischen Anliegen. Wenn Sie nicht sicher sind, welchen Ansatz Sie verwenden sollten, beginnen Sie mit dieser Art von Bereitstellung.

In dieser Tabelle sind einige der Bedenken der Säule zusammengefasst:

Säule Auswirkung
Zuverlässigkeit Sehr hohe Zuverlässigkeit. Dienste sind ausfallsicher für einen Ausfall eines Rechenzentrums oder einer Verfügbarkeitszone. Bei den meisten Diensten werden Daten automatisch und ohne Verzögerung über Zonen repliziert. Daten werden asynchron in einer geografisch getrennten Region gesichert. Diese Sicherung reduziert den Effekt eines vollständigen Regionsausfalls, indem der Datenverlust minimiert wird. Nach einem vollständigen Regionsausfall können Sie Vorgänge manuell in eine andere Region wiederherstellen. Wiederherstellungsprozesse können jedoch komplex sein, und es kann zeitaufwendig sein, manuell in die andere Region wiederherzustellen.
Kostenoptimierung Moderate Kosten. In der Regel kostet das Hinzufügen einer Sicherung zu einer anderen Region nur etwas mehr als die Implementierung von Zonenredundanz.
Effiziente Leistung Für die meisten Workloads: Akzeptable Leistung. Dieser Ansatz wird wahrscheinlich zufriedenstellende Leistung bieten.

Bei hochwartensiblen Workloads: Geringe Leistung. Einige Komponenten sind aufgrund des datenverkehrsübergreifenden Datenverkehrs oder der Datenreplikationszeit möglicherweise auf Latenz empfindlich.
Optimaler Betrieb Während eines Ausfalls der Verfügbarkeitszone: Hohe Betriebseffizienz. Failover liegt in der Verantwortung von Microsoft und erfolgt automatisch.

Während eines regionalen Ausfalls: Geringe betriebliche Effizienz. Failover liegt in Ihrer Verantwortung und erfordert möglicherweise manuelle Vorgänge und erneute Bereitstellungen.

In dieser Tabelle sind einige der Bedenken aus architektonischer Sicht zusammengefasst:

Architektonisches Anliegen Auswirkung
Einhaltung der Datenhaltung Hängt von der Bereichsauswahl ab. Daten werden in erster Linie in der von Ihnen angegebenen Azure-Region gespeichert, sie müssen jedoch eine andere Region auswählen, um Ihre Sicherungen zu speichern. Wählen Sie eine Region aus, die mit Ihren Datenhaltungsanforderungen kompatibel ist.
Regionale Verfügbarkeit Regionen mit Verfügbarkeitszonen. Dieser Ansatz ist in jeder Region verfügbar, die Verfügbarkeitszonen unterstützt.

Bereitstellungsansatz 4: Bereitstellungen mit mehreren Regionen

Sie können mehrere Azure-Regionen zusammen verwenden, um Ihre Lösung über einen breiten geografischen Bereich zu verteilen. Sie können diesen Multi-Region-Ansatz verwenden, um die Zuverlässigkeit Ihrer Lösung zu verbessern oder geografisch verteilte Benutzer zu unterstützen. Durch die Bereitstellung in mehreren Regionen verringern Sie auch das Risiko, dass in einer einzelnen Region eine temporäre Ressourcenkapazitätseinschränkung auftritt. Wenn die Datenhaltung ein wichtiges Anliegen für Ihre Lösung ist, überlegen Sie sorgfältig, welche Regionen Sie verwenden, um sicherzustellen, dass Ihre Daten nur an Standorten gespeichert werden, die Ihren Anforderungen entsprechen.

Aktive und passive Regionen

Multi-Region-Architekturen sind komplex, und es gibt viele Möglichkeiten, eine Multi-Region-Lösung zu entwerfen. Für einige Workloads ist es sinnvoll, mehrere Regionen aktiv verarbeitende Anforderungen gleichzeitig (aktiv-aktive Bereitstellungen) zu verwenden. Für andere Workloads ist es besser, eine primäre Region zu bestimmen und eine oder mehrere sekundäre Regionen für Failover zu verwenden (aktiv-passive Bereitstellungen). Dieser Abschnitt konzentriert sich auf das zweite Szenario, in dem eine Region aktiv ist und eine andere passiv ist. Informationen zu aktiven Multi-Region-Lösungen finden Sie unter Bereitstellungsstempelmuster und Geode-Muster.

Datenreplikation

Die Kommunikation zwischen Regionen ist viel langsamer als die Kommunikation innerhalb einer Region. Im Allgemeinen verursacht eine größere geografische Entfernung zwischen zwei Regionen aufgrund der längeren physischen Entfernung, die Daten reisen müssen, mehr Netzwerklatenz. Informationen zur erwarteten Netzwerklatenz beim Herstellen einer Verbindung zwischen zwei Regionen finden Sie in den Azure-Netzwerk-Roundtrip-Latenzstatistiken .

Die regionsübergreifende Netzwerklatenz kann sich erheblich auf den Lösungsentwurf auswirken, da Sie sorgfältig überlegen müssen, wie sich die zusätzliche Latenz auf die Datenreplikation und andere Transaktionen auswirkt. Für viele Lösungen erfordert eine regionsübergreifende Architektur eine asynchrone Replikation, um die Auswirkungen des regionsübergreifenden Datenverkehrs auf die Leistung zu minimieren.

Asynchrone Datenreplikation

Wenn Sie eine asynchrone Replikation über Regionen hinweg implementieren, wartet Ihre Anwendung nicht darauf, dass alle Regionen eine Änderung bestätigen. Nachdem die Änderung in der primären Region zugesichert wurde, wird die Transaktion als abgeschlossen betrachtet. Die Änderung wird zu einem späteren Zeitpunkt in die sekundären Regionen repliziert. Dieser Ansatz stellt sicher, dass sich die Verbindungslatenz zwischen Regionen nicht direkt auf die Anwendungsleistung auswirkt. Aufgrund der Verzögerung bei der Replikation kann ein regionsweiter Ausfall jedoch zu einem Datenverlust führen. Dieser Datenverlust kann auftreten, da eine Region möglicherweise einen Ausfall nach Abschluss eines Schreibvorgangs in der primären Region erlebt, aber bevor die Änderung in eine andere Region repliziert werden kann.

Diagramm, das die in mehreren Regionen bereitgestellte Lösung zeigt. Die Datenreplikation erfolgt asynchron.

In dieser Tabelle sind einige der Bedenken der Säule zusammengefasst:

Säule Auswirkung
Zuverlässigkeit Hohe Zuverlässigkeit. Die Lösung ist robust für einen Ausfall eines Rechenzentrums, einer Verfügbarkeitszone oder einer gesamten Region. Daten werden repliziert, sind aber möglicherweise nicht synchron, daher ist ein Datenverlust in einem Failoverszenario möglich.
Kostenoptimierung Hohe Kosten. Sie müssen separate Ressourcen in jeder Region bereitstellen, und jede Ressource verursacht Bereitstellungs- und Wartungskosten. Die Datenreplikation in allen Regionen kann auch erhebliche Kosten verursachen.
Effiziente Leistung Hohe Leistung. Anwendungsanforderungen erfordern keinen regionsübergreifenden Datenverkehr, sodass Datenverkehr in der Regel niedrige Latenz ist.
Optimaler Betrieb Geringe betriebliche Effizienz. Sie müssen Ressourcen in mehreren Regionen bereitstellen und verwalten. Sie sind auch für das Failover zwischen Regionen während eines regionalen Ausfalls verantwortlich.

In dieser Tabelle sind einige der Bedenken aus architektonischer Sicht zusammengefasst:

Architektonisches Anliegen Auswirkung
Einhaltung der Datenhaltung Hängt von der Bereichsauswahl ab. Bei diesem Ansatz müssen Sie mehrere Regionen auswählen, in denen Ihre Workload ausgeführt werden kann. Wählen Sie Regionen aus, die mit Ihren Datenhaltungsanforderungen kompatibel sind.
Regionale Verfügbarkeit Viele Azure-Regionen sind gekoppelt. Einige Azure-Dienste verwenden gekoppelte Regionen, um Daten automatisch zu replizieren. Wenn Sie Ihre Workload in einer Region ausführen, in der kein Paar vorhanden ist, müssen Sie möglicherweise einen anderen Ansatz verwenden, um Ihre Daten zu replizieren.
Synchrone Datenreplikation

Wenn Sie eine synchrone Multi-Region-Lösung implementieren, muss Ihre Anwendung warten, bis Schreibvorgänge in jeder Azure-Region abgeschlossen sind, bevor die Transaktion als abgeschlossen betrachtet wird. Die Wartezeit, die beim Warten auf Schreibvorgänge entsteht, hängt von der Entfernung zwischen den Regionen ab. Bei vielen Workloads kann die latenzübergreifende Latenz die synchrone Replikation zu langsam machen, um nützlich zu sein.

Diagramm, das die in mehreren Regionen bereitgestellte Lösung zeigt. Die Datenreplikation erfolgt synchron.

In dieser Tabelle sind einige der Bedenken der Säule zusammengefasst:

Säule Auswirkung
Zuverlässigkeit Sehr hohe Zuverlässigkeit. Die Lösung ist robust für einen Ausfall eines Rechenzentrums, einer Verfügbarkeitszone oder einer gesamten Region. Daten werden immer über Regionen hinweg synchronisiert, sodass Ihre Daten auch dann verfügbar sind, wenn ein vollständiger Regionsverlust auftritt, in einer anderen Region verfügbar und abgeschlossen ist.
Kostenoptimierung Hohe Kosten. Sie müssen separate Ressourcen in jeder Region bereitstellen, und jede Ressource verursacht Bereitstellungs- und Wartungskosten. Die Datenreplikation in allen Regionen kann auch erhebliche Kosten verursachen.
Effiziente Leistung Geringe Leistung. Anwendungsanforderungen erfordern regionsübergreifender Datenverkehr. Je nach Entfernung zwischen den Regionen kann die synchrone Replikation zu Anforderungen erhebliche Wartezeiten hinzufügen.
Optimaler Betrieb Geringe betriebliche Effizienz. Sie müssen Ressourcen in mehreren Regionen bereitstellen und verwalten. Sie sind auch für das Failover zwischen Regionen während eines regionalen Ausfalls verantwortlich.

In dieser Tabelle sind einige der Bedenken aus architektonischer Sicht zusammengefasst:

Architektonisches Anliegen Auswirkung
Einhaltung der Datenhaltung Hängt von der Bereichsauswahl ab. Bei diesem Ansatz müssen Sie mehrere Regionen auswählen, in denen Ihre Workload ausgeführt werden kann. Wählen Sie Regionen aus, die mit Ihren Datenhaltungsanforderungen kompatibel sind.
Regionale Verfügbarkeit Viele Azure-Regionen sind gekoppelt. Einige Azure-Dienste verwenden gekoppelte Regionen, um Daten automatisch zu replizieren. Wenn Sie Ihre Workload in einer Region ausführen, in der kein Paar vorhanden ist, müssen Sie möglicherweise einen anderen Ansatz verwenden, um Ihre Daten zu replizieren.

Regionsarchitekturen

Berücksichtigen Sie beim Entwerfen einer Multi-Region-Lösung, ob die azure-Regionen, die Sie verwenden möchten, gekoppelt sind.

Sie können auch dann eine Lösung mit mehreren Regionen erstellen, wenn die Regionen nicht gekoppelt sind. Die Ansätze, die Sie zum Implementieren einer Multiregionsarchitektur verwenden, können jedoch unterschiedlich sein. In Azure Storage können Sie z. B. georedundanten Speicher (GRS) mit gekoppelten Regionen verwenden. Wenn GRS nicht verfügbar ist, erwägen Sie die Verwendung von Features wie der Azure Storage-Objektreplikation, oder entwerfen Sie Ihre Anwendung so, dass sie in mehrere Regionen schreiben kann.

Kombinieren von Multizonen- und Multiregionenansätzen

Sie sollten Multizonen- und Multi-Region-Aussagen kombinieren, wenn Ihre Geschäftlichen Anforderungen eine solche Lösung erfordern. Sie können beispielsweise zonenredundante Komponenten in jeder Region bereitstellen und die Replikation zwischen den Regionen konfigurieren. Bei einigen Lösungen bietet dieser Ansatz ein sehr hohes Maß an Zuverlässigkeit. Die Konfiguration dieser Art von Ansatz kann jedoch kompliziert sein, und dieser Ansatz kann teuer sein.

Wichtig

Unternehmenskritische Workloads sollten sowohl mehrere Verfügbarkeitszonen als auch mehrere Regionen verwenden. Weitere Informationen zu den Überlegungen, die Sie beim Entwerfen von unternehmenskritischen Workloads geben sollten, finden Sie in der Dokumentation zu unternehmenskritischen Arbeitsauslastungen.

Vorgehensweisen zur Unterstützung der Bereitstellung von Azure-Diensten

Es ist wichtig, die spezifischen Details der von Ihnen verwendeten Azure-Dienste zu verstehen. Beispielsweise müssen einige Azure-Dienste ihre Verfügbarkeitszonenkonfiguration konfigurieren, wenn Sie die Ressource zum ersten Mal bereitstellen, während andere die Änderung des Bereitstellungsansatzes später unterstützen. Ebenso sind einige Dienstfeatures bei jedem Bereitstellungsansatz möglicherweise nicht verfügbar.

Weitere Informationen zu den spezifischen Bereitstellungsoptionen und -ansätzen für jeden Azure-Dienst finden Sie im Zuverlässigkeitshub.

Beispiele

In diesem Abschnitt werden einige häufige Anwendungsfälle und die wichtigsten Anforderungen beschrieben, die Sie in der Regel für jede Workload berücksichtigen müssen. Für jede Workload werden je nach anforderungen und Ansätzen, die in diesem Artikel beschrieben werden, mindestens ein vorgeschlagener Bereitstellungsansätze bereitgestellt.

Branchenanwendung für ein Unternehmen

Contoso, Ltd., ist ein großes Produktionsunternehmen. Das Unternehmen implementiert eine Branchenanwendung, um einige Komponenten seiner Finanzprozesse zu verwalten.

Geschäftsanforderungen: Die Vom System verwalteten Informationen sind schwer zu ersetzen, sodass Daten zuverlässig beibehalten werden müssen. Die Architekten sagen, dass das System so wenig Ausfallzeiten und so wenig Datenverlust wie möglich verursachen muss. Die Mitarbeiter von Contoso verwenden das System während des gesamten Arbeitstags, sodass hohe Leistung wichtig ist, um zu vermeiden, dass Teammitglieder warten. Die Kosten sind auch ein Anliegen, da das Finanzteam für die Lösung bezahlen muss.

Vorgeschlagener Ansatz: Zonenredundante Bereitstellung mit Sicherung in allen Regionen bietet mehrere Ebenen von Resilienz mit hoher Leistung.

Interne Anwendung

Fourth Coffee ist ein kleines Unternehmen. Das Unternehmen entwickelt eine neue interne Anwendung, mit der Mitarbeiter Arbeitszeittabellen übermitteln können.

Geschäftsanforderungen: Für diese Arbeitsauslastung ist die Kosteneffizienz ein hauptanliegend. Fourth Coffee bewertete die geschäftlichen Auswirkungen von Ausfallzeiten und entschied, dass die Anwendung keine Resilienz oder Leistung priorisieren muss. Das Unternehmen akzeptiert das Risiko, dass ein Ausfall in einer Azure-Verfügbarkeitszone oder -Region die Anwendung vorübergehend nicht verfügbar macht.

Vorgeschlagene Ansätze:

Legacyanwendungsmigration

Fabrikam, Inc., migriert eine ältere Anwendung von einem lokalen Rechenzentrum zu Azure. Die Implementierung verwendet einen IaaS-Ansatz, der auf virtuellen Computern basiert. Die Anwendung wurde nicht für eine Cloudumgebung entwickelt, und die Kommunikation zwischen der Anwendungsebene und der Datenbank ist sehr chatzig.

Geschäftsanforderungen: Die Leistung ist eine Priorität für diese Anwendung. Resilienz ist ebenfalls wichtig, und die Anwendung muss auch dann weiterhin funktionieren, wenn ein Azure-Rechenzentrum einen Ausfall erlebt.

Vorgeschlagene Vorgehensweise:

Anwendung für das Gesundheitswesen

Lamna Healthcare Company implementiert ein neues elektronisches Gesundheitsdatensatzsystem in Azure.

Geschäftsanforderungen: Aufgrund der Art der Daten, die diese Lösung speichert, ist die Datenspeicherung von entscheidender Bedeutung. Lamna arbeitet unter einem strengen Rechtsrahmen, der angibt, dass Daten an einem bestimmten Ort verbleiben müssen.

Vorgeschlagene Ansätze:

System für das Bankwesen

Die Woodgrove Bank führt ihre Kernbankgeschäfte aus einer großen Lösung aus, die in Azure bereitgestellt wird.

Geschäftsanforderungen: Dies ist ein unternehmenskritisches System. Alle Ausfälle können für Kunden erhebliche finanzielle Auswirkungen haben. Die Woodgrove Bank hat daher sehr geringe Risikotoleranz. Das System benötigt die größtmögliche Zuverlässigkeit, und die Architektur muss das Risiko von Fehlern verringern, die abgemildert werden können.

Vorgeschlagener Ansatz: Verwenden Sie für ein unternehmenskritisches System eine Mehrzonenbereitstellung mit mehreren Regionen. Stellen Sie sicher, dass die Regionen den Anforderungen der Datenhaltung des Unternehmens entsprechen.

Software-as-a-Service (SaaS)

Proseware, Inc., erstellt Software, die von Unternehmen auf der ganzen Welt verwendet wird. Die Benutzerbasis des Unternehmens ist geografisch weit verbreitet.

Geschäftsanforderungen: Proseware muss jedem seiner Kunden die Auswahl einer Bereitstellungsregion ermöglichen, die dem Kunden nahe kommt. Die Aktivierung dieser Wahl ist wichtig für die Latenz und für die Anforderungen der Kundendatenhaltung.

Vorgeschlagene Ansätze:

Im Folgenden sind einige Referenzarchitekturen und Beispielszenarien für Lösungen mit mehreren Zonen und Regionen aufgeführt:

Viele Azure-Dienste bieten Anleitungen zur Verwendung mehrerer Verfügbarkeitszonen, einschließlich der folgenden Beispiele:

Zuverlässigkeitsprüfliste

Lesen Sie den vollständigen Satz von Empfehlungen.