n-schichtige Anwendung für mehrere Regionen

Monitor
Traffic Manager
SQL-Datenbank
Virtual Machines

Diese Referenzarchitektur zeigt eine Reihe bewährter Methoden zum Ausführen einer n-schichtigen Anwendung in mehreren Azure-Regionen, um Verfügbarkeit und eine stabile Infrastruktur für die Notfallwiederherstellung zu erzielen.

Aufbau

Highly available network architecture for Azure N-tier applications

Laden Sie eine Visio-Datei dieser Architektur herunter.

Workflow

Diese Architektur basiert auf der Architektur aus N-schichtige Anwendung mit SQL Server.

  • Primäre und sekundäre Regionen. Verwenden Sie zwei Regionen, um eine höhere Verfügbarkeit zu erreichen. Eine ist die primäre Region. Die andere Region ist für das Failover.

  • Azure Traffic Manager. Traffic Manager leitet eingehende Anforderungen an eine der Regionen weiter. Während des normalen Betriebs werden Anforderungen an die primäre Region weitergeleitet. Wenn diese Region nicht mehr verfügbar ist, führt Traffic Manager ein Failover zur sekundären Region aus. Weitere Informationen finden Sie im Abschnitt Traffic Manager-Konfiguration.

  • Ressourcengruppen: Erstellen Sie separate Ressourcengruppen für die primäre Region, die sekundäre Region und für Traffic Manager. Dies bietet Ihnen die Flexibilität, jede Region als eine einzelne Ressourcensammlung zu verwalten. Sie können beispielsweise eine Region erneut bereitstellen, ohne die andere außer Betrieb zu nehmen. Verknüpfen Sie die Ressourcengruppen, damit Sie eine Abfrage zum Auflisten aller Ressourcen für die Anwendung ausführen können.

  • Virtuelle Netzwerke. Erstellen Sie für jede Region ein separates virtuelles Netzwerk. Stellen Sie sicher, dass sich die Adressräume nicht überschneiden.

  • SQL Server Always On-Verfügbarkeitsgruppe. Bei Verwendung von SQL Server werden SQL Always On-Verfügbarkeitsgruppen empfohlen, um Hochverfügbarkeit zu erzielen. Erstellen Sie eine einzelne Verfügbarkeitsgruppe, die SQL Server-Instanzen in beiden Regionen enthält.

    Hinweis

    Ziehen Sie auch eine Azure SQL-Datenbank in Betracht, die eine relationale Datenbank als Clouddienst bereitstellt. Mit einer SQL-Datenbank müssen Sie weder eine Verfügbarkeitsgruppe konfigurieren noch das Failover verwalten.

  • Peering virtueller Netzwerke. Konfigurieren Sie ein Peering der zwei virtuellen Netzwerke, um eine Datenreplikation von der primären Region zur sekundären Region zuzulassen. Weitere Informationen finden Sie unter Peering in virtuellen Netzwerken.

Komponenten

  • Verfügbarkeitsgruppen sorgen dafür, dass die von Ihnen in Azure bereitgestellten virtuellen Computer auf mehrere isolierte Hardwareknoten in einem Cluster verteilt werden. Dadurch wirken sich Hardware- oder Softwarefehler in Azure nur auf einen Teil Ihrer virtuellen Computer aus, und Ihre Lösung bleibt insgesamt verfügbar und betriebsbereit.
  • Verfügbarkeitszonen schützen Ihre Anwendungen und Daten vor Datencenterausfällen. Bei Verfügbarkeitszonen handelt es sich um separate physische Standorte in einer Azure-Region. Jede Zone besteht aus mindestens einem Datencenter mit eigener Stromversorgung, Kühlung und Netzwerk.
  • Azure Traffic Manager ist ein DNS-basierter Lastenausgleich, der Datenverkehr optimal auf Dienste in den globalen Azure-Regionen verteilt und gleichzeitig für Hochverfügbarkeit und kurze Reaktionszeiten sorgt.
  • Azure Load Balancer verteilt eingehenden Datenverkehr auf der Grundlage von definierten Regeln und Integritätstests. Ein Load Balancer sorgt für kurze Wartezeiten und hohen Durchsatz und kann auf Millionen von Flows für alle TCP- und UDP-Anwendungen skalieren. In diesem Szenario wird ein öffentlicher Lastenausgleich verwendet, um eingehenden Clientdatenverkehr auf der Webebene zu verteilen. Außerdem wird in diesem Szenario ein interner Lastenausgleich verwendet, um Datenverkehr von der Geschäftsebene auf den SQL Server-Back-End-Cluster zu verteilen.
  • Azure Bastion bietet sichere RDP- und SSH-Verbindungen mit allen virtuellen Computern in dem virtuellen Netzwerk, in dem der Dienst bereitgestellt wird. Durch die Verwendung von Azure Bastion wird verhindert, dass Ihre virtuellen Computer RDP- und SSH-Ports öffentlich verfügbar machen. Gleichzeitig wir weiterhin der sichere Zugriff per RDP/SSH ermöglicht.

Empfehlungen

Eine Architektur mit mehreren Regionen kann eine höhere Verfügbarkeit als eine Bereitstellung in einer einzelnen Region bieten. Wenn ein regionaler Ausfall die primäre Region beeinträchtigt, können Sie mit Traffic Manager ein Failover zur sekundären Region ausführen. Diese Architektur kann auch hilfreich sein, wenn bei einem einzelnen Subsystem der Anwendung ein Fehler auftritt.

Es gibt mehrere allgemeine Vorgehensweisen für das Erreichen von Hochverfügbarkeit mit mehreren Regionen:

  • Aktiv/passiv mit Hot Standby. Der Datenverkehr wird an eine Region weitergeleitet, während die andere im Hot Standby wartet. Hot Standby (unmittelbar betriebsbereit) bedeutet, dass die virtuellen Computer in der sekundären Region jederzeit zugeordnet sind und ausgeführt werden.
  • Aktiv/passiv mit Cold Standby. Der Datenverkehr wird an eine Region weitergeleitet, während die andere im Cold Standby wartet. Cold Standby (verzögert betriebsbereit) bedeutet, dass die virtuellen Computer in der sekundären Region erst zugewiesen werden, wenn sie für das Failover benötigt werden. Dieser Ansatz erfordert weniger Ausführungszeit, es dauert aber im Allgemeinen länger, bis bei einem Ausfall alle Komponenten online geschaltet sind.
  • Aktiv/aktiv. Beide Regionen sind aktiv, und Anforderungen werden per Lastenausgleich zwischen ihnen verteilt. Wenn eine Region nicht verfügbar ist, wird sie aus der Rotation entfernt.

In dieser Referenzarchitektur liegt der Fokus auf aktiv/passiv mit Hot Standby, wobei Traffic Manager für das Failover verwendet wird. Beachten Sie, dass Sie eine kleine Anzahl virtueller Computer für Hot Standby bereitstellen und dann nach Bedarf aufskalieren können.

Regionspaare

Jede Azure-Region ist mit einer anderen Region innerhalb desselben Gebiets gepaart. Sie wählen im Allgemeinen Regionen aus dem gleichen Regionspaar aus (z.B. „USA, Osten 2“ und „USA, Mitte“). Das bietet die folgenden Vorteile:

  • Bei einem umfassenden Ausfall wird die Wiederherstellung mindestens einer Region aus jedem Paar priorisiert.
  • Geplante Azure-Systemupdates werden in Regionspaaren nacheinander ausgeführt, um mögliche Ausfallzeiten zu minimieren.
  • Regionspaare befinden sich innerhalb des gleichen geografischen Gebiets, um Anforderungen in Bezug auf den Datenspeicherort zu erfüllen.

Sie sollten allerdings sicherstellen, dass beide Regionen alle Azure-Dienste unterstützen, die für Ihre Anwendung erforderlich sind (siehe Dienste nach Region). Weitere Informationen zu Regionspaaren finden Sie unter Geschäftskontinuität und Notfallwiederherstellung: Azure-Regionspaare.

Traffic Manager-Konfiguration

Beachten Sie beim Konfigurieren von Traffic Manager die folgenden Punkte:

  • Routing: Traffic Manager unterstützt mehrere Routingalgorithmen. Verwenden Sie für das in diesem Artikel beschriebenen Szenario Routing nach Priorität (ehemals Routingmethode Failover). Bei dieser Einstellung sendet Traffic Manager alle Anforderungen an die primäre Region, bis die primäre Region nicht mehr erreichbar ist. Zu diesem Zeitpunkt wird automatisch ein Failover zur sekundären Region ausgeführt. Weitere Informationen finden Sie unter Konfigurieren der Routingmethode „Failover“.
  • Integritätstest: Traffic Manager verwendet einen HTTP- oder HTTPS-Test, um die Verfügbarkeit jeder Region zu überwachen. Der Test prüft auf eine HTTP 200-Antwort für einen angegebenen URL-Pfad. Es hat sich bewährt, einen Endpunkt zu erstellen, der die Gesamtintegrität der Anwendung meldet, und diesen Endpunkt für den Integritätstest zu verwenden. Andernfalls meldet der Test eventuell einen fehlerfreien Endpunkt, obwohl wichtige Teile der Anwendung fehlerhaft sind. Weitere Informationen finden Sie unter Überwachungsmuster für den Integritätsendpunkt.

Wenn Traffic Manager ein Failover ausführt, können die Clients die Anwendung für eine bestimmte Zeit nicht erreichen. Die Dauer wird durch folgende Faktoren beeinflusst:

  • Der Integritätstest muss erkennen, dass die primäre Region nicht erreichbar ist.
  • Die DNS-Server müssen die zwischengespeicherten DNS-Einträge für die IP-Adresse aktualisieren, die von der DNS-Gültigkeitsdauer (TTL) abhängig ist. Die Standardgültigkeitsdauer beträgt 300 Sekunden (5 Minuten), Sie können diesen Wert aber bei der Erstellung des Traffic Manager-Profils anpassen.

Weitere Informationen finden Sie unter Traffic Manager-Überwachung.

Bei Failovern durch Traffic Manager sollten Sie ein manuelles Failback ausführen, anstatt ein automatisches Failback zu implementieren. Andernfalls könnte eine Situation eintreten, bei der die Anwendung zwischen den Regionen hin und her wechselt. Überprüfen Sie vor einem Failback, ob alle Subsysteme der Anwendung fehlerfrei sind.

Beachten Sie, dass Traffic Manager in der Standardeinstellung automatisch Failbacks ausführt. Um dies zu verhindern, verringern Sie die Priorität der primären Region nach einem Failover manuell. Angenommen, die primäre Region hat die Priorität 1 und die sekundäre Datenbank die Priorität 2. Nach einem Failover legen Sie dann die Priorität der primären Region auf 3 fest, um ein automatisches Failback zu verhindern. Wenn Sie wieder zurück wechseln möchten, ändern Sie die Priorität wieder in 1.

Mit dem folgenden Befehl für die Azure-Befehlszeilenschnittstelle wird die Priorität aktualisiert:

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type azureEndpoints --priority 3

Ein anderer Ansatz besteht darin, den Endpunkt vorübergehend zu deaktivieren, bis Sie zum Ausführen eines Failbacks bereit sind:

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type azureEndpoints --endpoint-status Disabled

Je nach Ursache eines Failovers müssen Sie die Ressourcen innerhalb einer Region möglicherweise erneut bereitstellen. Testen Sie vor dem Failback die Betriebsbereitschaft. Beim Test sollten z.B. folgende Punkte geprüft werden:

  • Virtuelle Computer sind richtig konfiguriert. (Alle erforderliche Software ist installiert, IIS wird ausgeführt usw.)
  • Subsysteme der Anwendung sind fehlerfrei.
  • Funktionstests. (Beispielsweise, dass die Datenbankebene von der Webebene aus erreichbar ist.)

Konfigurieren von SQL Server Always On-Verfügbarkeitsgruppen

Bei früheren Versionen als Windows Server 2016 erfordern SQL Server Always On-Verfügbarkeitsgruppen einen Domänencontroller, und alle Knoten in der Verfügbarkeitsgruppe müssen sich in der gleichen Active Directory (AD)-Domäne befinden.

So konfigurieren Sie die Verfügbarkeitsgruppe:

  • Platzieren Sie mindestens zwei Domänencontroller in jeder Region.

  • Weisen Sie jedem Domänencontroller eine statische IP-Adresse zu.

  • Konfigurieren Sie ein Peering der zwei virtuellen Netzwerke, um eine Kommunikation zwischen ihnen zu ermöglichen.

  • Fügen Sie für jedes virtuelle Netzwerk die IP-Adressen der Domänencontroller (beider Regionen) zur DNS-Serverliste hinzu. Sie können den folgenden CLI-Befehl verwenden. Weitere Informationen finden Sie unter Ändern von DNS-Servern.

    az network vnet update --resource-group <resource-group> --name <vnet-name> --dns-servers "10.0.0.4,10.0.0.6,172.16.0.4,172.16.0.6"
    
  • Erstellen Sie einen Windows Server-Failovercluster (WSFC), der die SQL Server-Instanzen in beiden Regionen enthält.

  • Erstellen Sie eine SQL Server Always On-Verfügbarkeitsgruppe, die SQL Server-Instanzen sowohl in der primären als auch der sekundären Region enthält. Die Schritte finden Sie unter Erweitern der Always On-Verfügbarkeitsgruppe auf ein Azure-Remoterechenzentrum (PowerShell).

    • Legen Sie das primäre Replikat in der primären Region ab.

    • Legen Sie ein oder mehrere sekundäre Replikate in der primären Region ab. Konfigurieren Sie diese für die Verwendung synchroner Commits mit automatischem Failover.

    • Legen Sie ein oder mehrere sekundäre Replikate in der sekundären Region ab. Konfigurieren Sie diese aus Leistungsgründen für die Verwendung asynchroner Commits. (Andernfalls müssen alle T-SQL-Transaktionen auf einem Roundtrip über das Netzwerk zur sekundären Region warten.)

      Hinweis

      Replikate mit asynchronem Commit unterstützen kein automatisches Failover.

Überlegungen zur Verfügbarkeit

Bei einer komplexen n-schichtigen Anwendung müssen Sie möglicherweise nicht die gesamte Anwendung in der sekundären Region replizieren. Stattdessen replizieren Sie nur ein kritisches Subsystem, das zur Unterstützung der Geschäftskontinuität erforderlich ist.

Traffic Manager ist eine mögliche Schwachstelle im System. Wenn beim Traffic Manager-Dienst ein Fehler auftritt, können Clients während der Ausfallzeit nicht auf Ihre Anwendung zugreifen. In der Vereinbarung zum Servicelevel (SLA) für Traffic Manager erfahren Sie, ob Ihre geschäftlichen Anforderungen für Hochverfügbarkeit mit Traffic Manager allein erfüllt werden. Wenn dies nicht der Fall ist, erwägen Sie als Failback eine andere Verwaltungslösung für den Datenverkehr. Wenn der Azure Traffic Manager-Dienst fehlerhaft ist, ändern Sie die CNAME-Einträge im DNS so, dass diese auf die andere Verwaltungslösung für den Datenverkehr verweisen. (Dieser Schritt muss manuell durchgeführt werden. Bis die DNS-Änderungen weitergegeben wurden, ist die Anwendung nicht verfügbar.)

Für den SQL Server-Cluster sind zwei Failoverszenarien zu berücksichtigen:

  • Bei allen SQL Server-Datenbankreplikaten in der primären Region treten Fehler auf. Dies kann z. B. während eines regionalen Ausfalls vorkommen. In diesem Fall müssen Sie für die Verfügbarkeitsgruppe ein manuelles Failover ausführen, obwohl Traffic Manager automatisch ein Failover auf dem Front-End ausführt. Führen Sie die Schritte unter Ausführen eines erzwungenen manuellen Failovers einer SQL Server-Verfügbarkeitsgruppe aus, in denen beschrieben ist, wie ein erzwungenes Failover mithilfe von SQL Server Management Studio, Transact-SQL oder PowerShell in SQL Server 2016 ausgeführt wird.

    Warnung

    Bei einem erzwungenem Failover besteht das Risiko eines Datenverlusts. Sobald die primäre Region wieder online ist, erstellen Sie eine Momentaufnahme der Datenbank, und verwenden Sie tablediff, um die Unterschiede zu ermitteln.

  • Traffic Manager führt ein Failover zur sekundären Region aus, doch ist das primäre SQL Server-Datenbankreplikat weiterhin verfügbar. So kann beispielsweise die Front-End-Ebene fehlgeschlagen, ohne dass dies Auswirkungen auf die virtuellen SQL Server-Computer hat. In diesem Fall wird der Internetdatenverkehr an die sekundäre Region weitergeleitet, und diese Region kann immer noch eine Verbindung mit dem primären Replikat herstellen. Es kommt jedoch zu erhöhter Latenz, da die SQL Server-Verbindungen regionsübergreifend verlaufen. In dieser Situation sollten Sie auf folgende Weise ein manuelles Failover ausführen:

    1. Wechseln Sie bei einem SQL Server-Datenbankreplikat in der sekundären Region vorübergehend zu synchronen Commits. Dadurch wird sichergestellt, dass während des Failovers kein Datenverlust auftritt.
    2. Führen Sie ein Failover zu diesem Replikat aus.
    3. Wenn Sie ein Failback zur primären Region ausführen, ändern Sie die Einstellung wieder in asynchrone Commits.

Überlegungen zur Verwaltbarkeit

Beim Aktualisieren der Bereitstellung aktualisieren Sie immer jeweils eine Region, um die Möglichkeit eines globalen Fehlers aufgrund einer falschen Konfiguration oder eines Fehlers in der Anwendung zu reduzieren.

Testen Sie die Resilienz des Systems gegenüber Fehlern. Hier sind einige häufige Fehlerszenarien aufgeführt, die getestet werden können:

  • Herunterfahren von VM-Instanzen
  • Auslasten von Ressourcen, z.B. CPU und Speicher
  • Trennen/Verzögern des Netzwerks
  • Absturz von Prozessen
  • Ablauf von Zertifikaten
  • Simulieren von Hardwarefehlern
  • Herunterfahren des DNS-Diensts auf den Domänencontrollern

Messen Sie die Wiederherstellungszeiten, und stellen Sie sicher, dass diese Ihren geschäftlichen Anforderungen entsprechen. Testen Sie auch Kombinationen von Fehlermodi.

Kostenoptimierung

Verwenden Sie den Azure-Preisrechner, um die Kosten zu ermitteln. Hier finden Sie einige weitere Überlegungen dazu.

VM-Skalierungsgruppen

VM-Skalierungsgruppen sind für alle Windows-VM-Größen verfügbar. Ihnen werden nur die Azure-VMs in Rechnung gestellt, die Sie bereitstellen, sowie alle zusätzlichen zugrunde liegenden Infrastrukturressourcen, die Sie genutzt haben, etwa Speicher und Netzwerk. Für den VM-Skalierungsgruppendienst fallen keine inkrementellen Gebühren an.

Preisoptionen für einzelne VMS finden Sie unter Virtuelle Windows-Computer – Preise.

Datenbank importieren

Wenn Sie Azure SQL DBaas auswählen, können Sie Kosten sparen, da Sie keine Always On-Verfügbarkeitsgruppen und Domänencontrollercomputer konfigurieren müssen. Es gibt mehrere Bereitstellungsoptionen, beginnend mit einer einzelnen Datenbank bis hin zu einer verwalteten Instanz oder Pools für elastische Datenbanken. Weitere Informationen finden Sie in der Azure-Preisübersicht.

Die Preisoptionen für virtuelle SQL Server-Computer finden Sie unter Preisübersicht für SQL-VMs.

Load Balancer

Die Gebühren werden nur anhand der Anzahl von konfigurierten Lastenausgleichsregeln und Ausgangsregeln berechnet. Für NAT-Regeln für eingehenden Datenverkehr fallen keine Gebühren an. Für Load Balancer Standard fallen keine Kosten auf Stundenbasis an, wenn keine Regeln konfiguriert sind.

Traffic Manager – Preise

Die Abrechnung für Traffic Manager basiert auf der Anzahl von empfangenen DNS-Abfragen. Für Dienste, die über eine Milliarde Abfragen pro Monat empfangen, gibt es einen Rabatt. Ihnen werden auch alle überwachten Endpunkte in Rechnung gestellt.

Weitere Informationen finden Sie im Abschnitt zu Kosten im Microsoft Azure Well-Architected Framework.

Preise für VNET-Peering

Bei einer hochverfügbaren Bereitstellung mit mehreren Azure-Regionen wird VNET-Peering genutzt. Für VNET-Peering innerhalb der gleichen Region und für globales VNET-Peering fallen jeweils unterschiedliche Gebühren an.

Weitere Informationen finden Sie unter Virtual Network – Preise.

Überlegungen zu DevOps

Sie benötigen nur eine Azure Resource Manager-Vorlage, um die Azure-Ressourcen und die zugehörigen Abhängigkeiten bereitzustellen. Verwenden Sie dieselbe Vorlage, um die Ressourcen sowohl in der primären als auch in der sekundären Region bereitzustellen. Ordnen Sie alle Ressourcen in demselben virtuellen Netzwerk an, damit sie in derselben grundlegenden Workload isoliert sind. Dies vereinfacht die Zuordnung der spezifischen Ressourcen der Workload zu einem DevOps-Team, damit es alle Aspekte dieser Ressourcen separat verwalten kann. Diese Isolation ermöglicht DevOps-Teams und -Diensten die Durchführung von Continuous Integration- und Continuous Delivery-Vorgängen (CI/CD).

Außerdem können Sie verschiedene Azure Resource Manager-Vorlagen verwenden und in Azure DevOps Services integrieren, um in wenigen Minuten unterschiedliche Umgebungen bereitzustellen. Beispielsweise können Sie das Replizieren von produktionsähnlichen Szenarien oder das Laden von Testumgebungen nur bei Bedarf durchführen, um Kosten zu sparen.

Erwägen Sie die Nutzung von Azure Monitor, um die Leistung Ihrer Infrastruktur zu analysieren und zu optimieren, die Überwachung durchzuführen und Netzwerkprobleme zu diagnostizieren, ohne dass Sie sich bei Ihren virtuellen Computern anmelden müssen. Application Insights ist tatsächlich einer der Komponenten von Azure Monitor, die Ihnen umfassende Metriken und Protokolle zum Überprüfen des Status Ihrer gesamten Azure-Landschaft an die Hand gibt. Mit Azure Monitor können Sie den Status Ihrer Infrastruktur verfolgen.

Achten Sie darauf, nicht nur die Compute-Elemente zu überwachen, die Ihren Anwendungscode unterstützen, sondern auch Ihre Datenplattformen. Dies gilt vor allem für Ihre Datenbanken, da eine schlechte Leistung der Datenebene einer Anwendung schwerwiegende Folgen haben kann.

Um die Umgebung zu testen, in der die Anwendungen ausgeführt werden, sollte eine Versionskontrolle vorhanden sein, und für die Bereitstellung sollten die gleichen Mechanismen wie für den Anwendungscode verwendet werden. Dies ermöglicht es, die Umgebung ebenfalls anhand von DevOps-Testparadigmen zu testen und zu validieren.

Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework im Abschnitt mit den Informationen zum optimalen Betrieb.

Nächste Schritte

In der folgenden Architektur werden einige der gleichen Technologien verwendet: