Dokumentation zur Zuverlässigkeit von Azure

  • Artikel

Zuverlässigkeit basiert auf zwei Prinzipien: Resilienz und Verfügbarkeit. Das Ziel der Resilienz besteht darin, Fehler zu vermeiden und bei wiederholtem Auftreten dieser Fehler die volle Funktionsfähigkeit Ihrer Anwendung wiederherzustellen. Das Ziel der Verfügbarkeit besteht darin, einen konsistenten Zugriff auf Ihre Anwendung oder Workload zu bieten. Es ist wichtig, eine proaktive Zuverlässigkeit auf der Basis Ihrer Anwendungsanforderungen zu planen.

Azure umfasst integrierte Zuverlässigkeitsdienste, die Sie basierend auf Ihren Geschäftsanforderungen nutzen und verwalten können. Azure bietet Lösungen, die die Zuverlässigkeit verbessern, unabhängig davon, ob es sich um den Ausfall eines einzelnen Hardwareknotens, einen Ausfall auf Rackebene, den Ausfall eines Rechenzentrums oder einen umfangreichen regionalen Ausfall handelt. Verfügbarkeitsgruppen sorgen beispielsweise dafür, dass die von Ihnen in Azure bereitgestellten virtuellen Computer auf mehrere isolierte Hardwareknoten in einem Cluster verteilt werden. Verfügbarkeitszonen schützen die Anwendungen und Daten der Kunden vor Ausfällen von Rechenzentren an mehreren physischen Standorten innerhalb einer Region. Regionen und Verfügbarkeitszonen sind für Ihren Anwendungsentwurf und Ihre Resilienzstrategie von zentraler Bedeutung und werden weiter unten in diesem Artikel ausführlicher erläutert.

Die Dokumentation zur Zuverlässigkeit in Azure enthält Leitfäden zur Zuverlässigkeit für Azure-Dienste. Dieser Leitfaden enthält Informationen zur Unterstützung von Verfügbarkeitszonen, Leitfäden zur Notfallwiederherstellung und Informationen zur Verfügbarkeit von Diensten.

Detaillierte Richtlinien zur dienstspezifischen Zuverlässigkeit, einschließlich der Verfügbarkeitszonen, Notfallwiederherstellung oder Hochverfügbarkeit, finden Sie unter Übersicht über den dienstspezifischen Leitfaden zur Zuverlässigkeit in Azure.

Informationen zu Zuverlässigkeits- und Zuverlässigkeitsprinzipien und zur Architektur in Microsoft Azure-Diensten finden Sie unter Microsoft Azure Well-Architected Framework: Zuverlässigkeit.

Zuverlässigkeitsanforderungen

Der für eine Azure-Lösung erforderliche Zuverlässigkeitsgrad hängt von mehreren Überlegungen ab. Verfügbarkeits- und Latenz-SLA und andere Geschäftsanforderungen steuern die Architekturoptionen und den Resilienzgrad und sollten zuerst berücksichtigt werden. Die Verfügbarkeitsanforderungen reichen von der für Ihr Unternehmen tolerierbaren Ausfallzeit und den damit verbundenen Kosten bis hin zu der Menge an Geld und Zeit, die Sie realistisch in die Hochverfügbarkeit einer Anwendung investieren können.

Das Erstellen zuverlässiger Systeme in Azure unterliegt einer gemeinsamen Verantwortung. Microsoft ist für die Zuverlässigkeit der Cloudplattform verantwortlich, einschließlich des globalen Netzwerks und der Rechenzentren. Azure-Kunden und -Partner sind für die Resilienz ihrer Cloudanwendungen und die Verwendung bewährter Architekturmethoden basierend auf den Anforderungen der einzelnen Workloads verantwortlich. Während Azure ständig nach größtmöglicher Resilienz in der SLA für die Cloudplattform strebt, müssen Sie für jede Workload in Ihrer Lösung eigene Ziel-SLAs definieren. Anhand einer Vereinbarung zum Servicelevel kann ausgewertet werden, ob die Architektur die geschäftlichen Anforderungen erfüllt. In dem Maße, wie Sie einen höheren Prozentsatz an garantierter SLA-Betriebszeit anstreben, steigen die Kosten und die Komplexität, um dieses Verfügbarkeitsniveau zu erreichen. Eine Betriebszeit von 99,99 % entspricht etwa fünf Minuten Gesamtausfallzeit pro Monat. Lohnt sich der höhere Aufwand und die Kosten, um diesen Prozentsatz zu erreichen? Die Antwort hängt von Ihren individuellen geschäftlichen Anforderungen ab. Während Sie Ihre endgültigen SLA-Verpflichtungen beschließen, machen Sie sich mit den von Microsoft unterstützten SLAs vertraut. Jeder Azure-Dienst verfügt über eine eigene SLA.

Diagram showing the shared responsibility model for Azure business continuity.

Bei traditionellen lokalen Modellen liegt die gesamte Verantwortung für die Verwaltung, die Compute-, Speicher- und Netzwerkhardware sowie für die Anwendung bei Ihnen. Sie müssen bei der Planung verschiedene Fehlertypen beachten und für das Auftreten dieser Fehler eine Notfallwiederherstellungsstrategie entwickeln. Bei einem IaaS-Modell (Infrastructure-as-a-Service) ist der Clouddienstanbieter für die Ausfallsicherheit der Kerninfrastruktur verantwortlich, einschließlich der Speicher-, Netzwerk- und Computeressourcen. Beim Wechsel von IaaS zu PaaS (Platform-as-a-Service) und schließlich zu SaaS (Software-as-a-Service) nimmt ihre Verantwortlichkeit immer weiter ab, während die des Cloudanbieters zunimmt.  

Weitere Informationen zu den Zuverlässigkeitsprinzipien finden Sie in der Dokumentation zu Well-Architected Framework: Zuverlässigkeit.  

Erstellen mit Blick auf Zuverlässigkeit

Sie sollten die Zuverlässigkeitsanforderungen Ihrer Anwendung zu Beginn der Planung definieren. Wenn Sie wissen, welche Anwendungen in bestimmten Zeiträumen keine hundertprozentige Hochverfügbarkeit benötigen, können Sie die Kosten während dieser nicht kritischen Zeiträume optimieren. Identifizieren Sie die Art der Fehler, die bei einer Anwendung auftreten können, und die potenziellen Auswirkungen der einzelnen Fehler. Ein Wiederherstellungsplan sollte alle kritischen Dienste abdecken, indem Sie die Wiederherstellungsstrategie auf Ebene der einzelnen Komponente sowie der gesamten Anwendung ausarbeiten. Entwerfen Sie Ihre Wiederherstellungsstrategie so, dass sie vor Ausfällen auf Zonen-, Regions- und Anwendungsebene schützt. Führen Sie Tests der vollumfassenden Anwendungsumgebung durch, um die Zuverlässigkeit und Wiederherstellung von Anwendungen bei unerwarteten Fehlern zu messen.

In der folgenden Prüfliste wird der Umfang der Zuverlässigkeitsplanung behandelt.

Zuverlässigkeitsplanung
Definieren Sie Verfügbarkeits- und Wiederherstellungsziele, um die geschäftlichen Anforderungen zu erfüllen.
Entwerfen Sie Zuverlässigkeitsfeatures für Ihre Anwendungen basierend auf den Verfügbarkeitsanforderungen.
Passen Sie Anwendungs- und Datenplattformen an Ihre Zuverlässigkeitsanforderungen an.
Konfigurieren Sie Verbindungspfade, um die Verfügbarkeit zu verbessern.
Verwenden Sie Verfügbarkeitszonen und Notfallwiederherstellungsplanung, wo erforderlich, um die Zuverlässigkeit zu steigern und Kosten zu optimieren.
Vergewissern Sie sich, dass Ihre Anwendungsarchitektur ausfallsicher ist.
Berücksichtigen Sie, was geschieht, wenn die SLA-Anforderungen nicht erfüllt werden.
Identifizieren Sie mögliche Fehlerpunkte im System. Der Anwendungsentwurf sollte Abhängigkeitsfehler tolerieren, indem Verbindungsunterbrechung bereitgestellt wird.
Erstellen Sie Anwendungen, die auch ohne ihre jeweiligen Abhängigkeiten in Betrieb bleiben.

RTO und RPO

Zwei wichtige Metriken, die berücksichtigt werden sollten, sind Recovery Time Objective (RTO) und Recovery Point Objective (RPO), da sie sich auf Notfallwiederherstellung beziehen.  Weitere Informationen zu funktionalen und nicht funktionalen Designanforderungen finden Sie unter Funktionale und nicht funktionale Anforderungen an Well-Architected Framework.

  • Recovery Time Objective (RTO) ist der maximal zulässige Zeitraum, in dem eine Anwendung nach einem Vorfall nicht verfügbar sein darf.

  • Recovery Point Objective (RPO) ist die maximale Dauer eines Datenverlusts, die während eines Notfalls zulässig ist.

RTO und RPO sind nicht funktionsbezogene Anforderungen eines Systems und sollten durch Geschäftsanforderungen vorgegeben werden. Um diese Werte abzuleiten empfiehlt es sich, eine Risikobewertung durchzuführen und sich der Kosten für Ausfallzeiten oder Datenverluste genau bewusst zu sein.  

Regionen und Verfügbarkeitszonen

Regionen und Verfügbarkeitszonen haben einen großen Einfluss auf die Zuverlässigkeit. Regionen haben mehrere, physisch getrennte Verfügbarkeitszonen. Diese Verfügbarkeitszonen sind durch ein Hochleistungsnetzwerk verbunden, das eine Wartezeit von weniger als 2 Millisekunden zwischen den physischen Zonen aufweist. Geringe Wartezeiten sorgen dafür, dass Ihre Daten synchronisiert und zugänglich bleiben, wenn Probleme auftreten. Sie können diese Infrastruktur strategisch nutzen, indem Sie Anwendungen und Dateninfrastrukturen entwickeln, die automatisch repliziert werden und unterbrechungsfreie Dienste zwischen Zonen und Regionen bereitstellen.

Microsoft Azure-Dienste unterstützen Verfügbarkeitszonen, bieten optimale Hochverfügbarkeit für Ihre Cloudvorgänge und unterstützen gleichzeitig Ihre Anforderungen an die regionsübergreifende Wiederherstellung und Business-Continuity-Strategie.

Bei der Notfallwiederherstellungsplanung bieten Regionen, die mit anderen Regionen gekoppelt sind, regionsübergreifende Replikation und Schutz durch das asynchrone Replizieren von Daten in anderen Azure-Regionen. Regionen ohne Gegenstück folgen den Richtlinien für die Datenresidenz und bieten Hochverfügbarkeit mit Verfügbarkeitszonen und lokal redundanten oder zonenredundanten Speicher. Kunden müssen die regionsübergreifende Notfallwiederherstellung basierend auf ihren RTO- und RPO-Anforderungen planen.

Wählen Sie die jeweils beste Region für Ihre Anforderungen basierend auf den technischen und gesetzlichen Aspekten aus – Dienstfunktionen, Datenresidenz, Complianceanforderungen, Wartezeit –, und beginnen Sie mit der Erweiterung Ihrer Zuverlässigkeitsstrategie. Weitere Informationen finden Sie unter Regionen und Verfügbarkeitszonen in Azure.

Azure-Dienstabhängigkeiten

Microsoft Azure-Dienste sind global verfügbar, um Ihre Cloudvorgänge optimal zu unterstützen.

In Azure-Regionen bereitgestellte Azure-Dienste sind auf der Seite Globale Azure-Infrastruktur/Produkte nach Region aufgeführt. Weitere Informationen zu Regionen und Verfügbarkeitszonen in Azure finden Sie in diesem Artikel.

Azure-Dienste sind auf Zuverlässigkeit ausgelegt, einschließlich Hochverfügbarkeit und Notfallwiederherstellung. Es gibt keine Dienste, die nur von einem logischen Rechenzentrum abhängig sind (um Single Points of Failure zu vermeiden). Nicht regionale Dienste, die auf der Seite Globale Azure-Infrastruktur/Produkte nach Region aufgeführt sind, sind Dienste, für die keine Abhängigkeit von einer bestimmten Azure-Region besteht. Nicht-regionale Dienste werden in zwei oder mehr Regionen bereitgestellt, und bei einem regionalen Ausfall wird der Dienst für die Kunden über eine Instanz in einer anderen Region weiterhin bereitgestellt. Bei bestimmten nicht regionalen Diensten können Kunden die Region angeben, in der der zugrunde liegende virtuelle Computer (VM), auf dem der Dienst ausgeführt wird, bereitgestellt werden soll. Bei Azure Virtual Desktop können Kunden beispielsweise den Regionsstandort für die VM angeben. Alle Azure-Dienste, bei denen Kundendaten gespeichert werden, ermöglichen dem Kunden das Angeben der jeweiligen Regionen, in denen seine Daten gespeichert werden sollen. Die Ausnahme stellt Microsoft Entra ID mit geografischer Platzierung (z. B. Europa oder Nordamerika) dar. Weitere Informationen zu den Orten der Datenspeicherung finden Sie auf der Karte zur Data Residency.

Falls Sie sich mit den Abhängigkeiten zwischen den Azure-Diensten vertraut machen möchten, um die Erstellung Ihrer Anwendungen und Dienste zu verbessern, können Sie die Dokumentation zu den Azure-Dienstabhängigkeiten anfordern. Wenden Sie sich hierfür an Ihren Microsoft-Vertriebs- bzw. -Kundenvertreter. In diesem Dokument sind die Abhängigkeiten für Azure-Dienste aufgeführt, z. B. Abhängigkeiten für alle häufigen wichtigen internen Dienste wie Steuerungsebenendienste. Um diese Dokumentation zu erhalten, müssen Sie Microsoft-Kunde sein und über eine entsprechende Vertraulichkeitsvereinbarung (Non-Disclosure Agreement, NDA) mit Microsoft verfügen.

Nächste Schritte