Entwerfen zuverlässiger Azure-Anwendungen

Die Erstellung einer zuverlässigen Anwendung in der Cloud unterscheidet sich von der herkömmlichen Anwendungsentwicklung. Früher haben Sie möglicherweise redundante, höherwertige Hardware erworben, um das Risiko des Ausfalls einer gesamten Anwendungsplattform zu minimieren. In der Cloud wird dagegen von vornherein mit Ausfällen gerechnet. Es geht nicht darum, Fehler vollständig zu verhindern, sondern darum, die Auswirkungen einer einzelnen fehlerhaften Komponente zu minimieren. Fehler, die Sie hier erwarten können, sind in stark verteilten Systemen angelegt, nicht in der Funktion von Azure.

Die wichtigsten Punkte

  • Verwenden Sie ggf. Verfügbarkeitszonen, um die Zuverlässigkeit zu steigern und Kosten zu optimieren.
  • Entwerfen Sie Anwendungen, die auch noch funktionieren, wenn Sie von Fehlern betroffen sind.
  • Verwenden Sie die nativen Resilienzfunktionen von PaaS, um die Zuverlässigkeit vn Anwendungen insgesamt zu unterstützen.
  • Richten Sie den Entwurf auf Aufskalierung aus.
  • Überprüfen Sie, ob die erforderliche Kapazität innerhalb der Skalierungsgrenzwerte und -kontingente des Azure-Diensts liegt.

Verwenden von Verfügbarkeitszonen in einer Region

Wenn Ihre Anforderungen eine noch stärkere Fehlerisolation erfordern, als sie Verfügbarkeitszonen alleine bieten können, sollten Sie die Bereitstellung in mehreren Regionen in Erwägung ziehen. Für Failoverzwecke sollten im Notfall mehrere Regionen verwendet werden. Dabei müssen zusätzliche Kosten berücksichtigt werden. Beispiele für Kostenanforderungen sind Daten und Netzwerke sowie Dienste wie Azure Site Recovery.

Entwerfen Sie Ihrer Anwendungsarchitektur so, dass sie Verfügbarkeitszonen innerhalb einer Region verwendet. Verfügbarkeitszonen können verwendet werden, um die Anwendungsverfügbarkeit innerhalb einer Region durch Bereitstellen von Fehlertoleranz auf Rechenzentrumsebene zu optimieren. Die Anwendungsarchitektur darf jedoch keine gemeinsamen Abhängigkeiten zwischen den Zonen aufweisen, um sie effektiv verwenden zu können.

Hinweis

Verfügbarkeitszonen können zu Leistungs- und Kostenüberlegungen für Anwendungen, die äußerst „geschwätzig“ zwischen Zonen sind, führen, angesichts der impliziten physischen Trennung zwischen den einzelnen Zonen und der zonenübergreifenden Bandbreitenkosten. Dies bedeutet auch, dass Verfügbarkeitszonen berücksichtigt werden können, um eine höhere SLA bei niedrigeren Kosten zu erzielen.

Bedenken Sie, ob die Nähe von Komponenten aus Gründen der Anwendungsleistung erforderlich ist. Wenn die gesamte oder Teile der Anwendung sehr empfindlich für Wartezeiten sind, kann dies vorgeben, dass die Komponenten eng benachbart am selben Ort sein müssen, was die Anwendbarkeit von Strategien mit mehreren Regionen und mehreren Zonen einschränken kann.

Reagieren auf Fehler

Das Vermeiden von Fehlern ist in der öffentliche Cloud unmöglich, und daraus resultiert, dass Anwendungen resilient sein müssen, um auf Ausfälle reagieren und Zuverlässigkeit gewährleisten zu können. Deshalb sollte die Anwendung so entworfen werden, dass sie auch dann funktioniert, wenn sie von Regions-, Zonen-, Dienst- oder Komponentenausfällen in kritischen Anwendungsszenarien und -funktionen betroffen ist. Bei Anwendungsvorgängen kann es zu verringerter Funktionalität oder Leistungseinbußen während eines Ausfalls kommen.

Definieren Sie eine Verfügbarkeitsstrategie, um aufzuzeichnen, wie die Anwendung verfügbar bleibt, wenn ein Fehlerzustand auftritt. Sie sollte für alle Anwendungskomponenten und den Anwendungsbereitstellungsstempel als Ganzes gelten, z. B. wie bei einem Bereitstellungsansatz mit multigeografischen Skalierungseinheiten. Dies hat auch Auswirkungen auf die Kosten: Mehr Ressourcen müssen im Voraus bereitgestellt werden, um Hochverfügbarkeit zu gewährleisten. Eine Aktiv/Aktiv-Einrichtung ist zwar teurer als eine einzelne Bereitstellung, kann die Kosten aber ausgleichen, indem die Auslastung eines Stempels gesenkt und die Gesamtmenge der benötigten Ressourcen verringert wird.

Definieren Sie zusätzlich zu einer Verfügbarkeitsstrategie eine BCDR-Strategie (Business Continuity & Disaster Recovery) für die Anwendung und/oder deren wichtigste Szenarien. Eine Notfallwiederherstellungsstrategie sollte erfassen, wie die Anwendung auf eine Notfallsituation reagiert, z. B. einen regionalen Ausfall oder den Verlust eines wichtigen Plattformdiensts, und dabei entweder eine erneute Bereitstellung, ein Warmspare (aktiv/passiv) oder ein Hostspare (aktiv/aktiv) verwenden.

Erwägen Sie zur Senkung der Kosten eine Aufteilung von Anwendungskomponenten und -daten in Gruppen. Beispiel:

  • Muss geschützt werden
  • Optional zu schützen
  • Kurzlebig/kann neu erstellt werden/verloren gehen, anstatt alle Daten mit derselben Richtlinie zu schützen

Überlegungen zur Verbesserung der Zuverlässigkeit

Wurde die Anwendung auf die Verwendung verwalteter Dienste ausgelegt?


Von Azure verwaltete Dienste bieten native Resilienzfunktionen zur Unterstützung der Anwendungszuverlässigkeit insgesamt. Platform-as-a-Service-Angebote (PaaS) sollten verwendet werden, um diese Funktionen nutzen zu können. PaaS-Optionen können einfacher konfiguriert und verwaltet werden. Sie müssen keine VMs bereitstellen, VNets einrichten oder Patches und Updates verwalten, und auch der restliche Mehraufwand für die Ausführung von Software auf einer VM fällt weg. Weitere Informationen finden Sie unter Verwenden verwalteter Dienste.

Wurde die Anwendung für Aufskalierung entworfen?


Azure bietet elastische Skalierbarkeit, und Sie sollten im Entwurf Aufskalierbarkeit berücksichtigen. Anwendungen müssen jedoch einen Ansatz mit Skalierungseinheiten verwenden, um Dienst- und Abonnementlimits zu berücksichtigen und so sicherzustellen, dass einzelne Komponenten sowie die Anwendung als Ganzes horizontal skaliert werden können. Vergessen Sie dabei nicht die Abskalierung, die für die Senkung der Kosten wichtig ist. Die Ab- und Aufskalierung für App Service erfolgt beispielsweise mittels Regeln. Kunden schreiben häufig Regeln für die Aufskalierung, aber nie für Abskalierung. Dadurch bleibt App Service teurer.

Ist die Anwendung über mehrere Azure-Abonnements hinweg bereitgestellt?


Das Verständnis der Abonnementlandschaft der Anwendung und wie Komponenten innerhalb oder zwischen Abonnements organisiert sind, ist wichtig, wenn Sie analysieren, ob relevante Abonnementlimits oder -kontingente erfüllt werden können. Überprüfen Sie die Grenzwerte für Azure-Abonnements und -Dienste, um sicherzustellen, dass die erforderliche Kapazität innerhalb der Skalierungslimits und -kontingente der Azure-Dienste liegt. Weitere Informationen finden Sie unter Grenzwerte für Azure-Abonnements und -Dienste.

Nächster Schritt

Zurück zum Hauptartikel: Design