Ausführen einer N-Ebene-Anwendung in mehreren Azure Stack Hub Regionen für hohe Verfügbarkeit

Diese Referenzarchitektur zeigt eine Reihe bewährter Methoden für die Ausführung einer N-Tier-Anwendung in mehreren Azure Stack Hub Regionen, um Verfügbarkeit und eine robuste Notfallwiederherstellungsinfrastruktur zu erreichen. In dieser Architektur wird Azure Traffic Manager verwendet, um hohe Verfügbarkeit zu erzielen. Wenn Traffic Manager jedoch keine bevorzugte Wahl in Ihrer Umgebung ist, können Sie ein Paar hoch verfügbarer Lastenausgleichsgeräte ersetzen.

Architecture

Diese Architektur basiert auf der in der N-Ebene-Anwendung mit SQL Server dargestellten Anwendung.

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

• Azure Traffic Manager. Der Datenverkehrs-Manager leitet eingehende Anforderungen an eine der Regionen weiter. Während normaler Vorgänge leitet sie Anforderungen an die primäre Region weiter. Wenn diese Region nicht verfügbar ist, schlägt der Datenverkehrs-Manager nicht in die sekundäre Region um. Weitere Informationen finden Sie im Abschnitt "Traffic Manager-Konfiguration".

• Ressourcengruppen. Erstellen Sie separate Ressourcengruppen für die primäre Region und die sekundäre Region. Dieser Ansatz bietet Ihnen die Flexibilität, jede Region als einzelne Sammlung von Ressourcen zu verwalten. Sie können beispielsweise eine Region erneut bereitstellen, ohne die andere Region zu nehmen. Verknüpfen Sie die Ressourcengruppen, damit Sie eine Abfrage ausführen können, um alle Ressourcen für die Anwendung auflisten zu können.

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

• SQL Server Always On Availability Group. Wenn Sie SQL Server verwenden, verwenden Sie SQL AlwaysOn-Verfügbarkeitsgruppen für hohe Verfügbarkeit. Erstellen Sie eine einzelne Verfügbarkeitsgruppe, die die SQL Server Instanzen in beiden Regionen enthält.

• VNET-zu-VNET-VPN-Verbindung. Da VNET-Peering noch nicht auf Azure Stack Hub verfügbar ist, verwenden Sie VNET-zu VNET-VPN-Verbindung, um die beiden VNETs zu verbinden. Weitere Informationen finden Sie unter VNET zu VNET in Azure Stack Hub.

Empfehlungen

Eine Architektur mit mehreren Regionen kann eine höhere Verfügbarkeit bieten als die Bereitstellung in einer einzelnen Region. Wenn sich ein regionaler Ausfall auf die primäre Region auswirkt, können Sie den Datenverkehrs-Manager verwenden, um zu der sekundären Region fehlzuschlagen. Diese Architektur kann auch hilfreich sein, wenn ein einzelnes Subsystem der Anwendung fehlschlägt.

Es gibt mehrere allgemeine Ansätze, um eine hohe Verfügbarkeit in allen Regionen zu erreichen:

• Aktiv/passiv mit Hot Standby. Der Datenverkehr wechselt zu einer Region, während der andere auf den heißen Standbymodus wartet. Hot Standby bedeutet, dass die virtuellen Computer in der sekundären Region jederzeit zugewiesen und ausgeführt werden.

• Aktiv/passiv mit kalter Standbymodus. Der Datenverkehr geht in eine Region, während der andere im Kalten Standby wartet. Kalter Standbymodus bedeutet, dass die virtuellen Computer in der sekundären Region erst zugewiesen werden, wenn sie für failover erforderlich sind. Dieser Ansatz kostet weniger Ausführung, dauert aber in der Regel länger, um während eines Fehlers online zu sein.

• Aktiv/aktiv. Beide Regionen sind aktiv, und Anforderungen werden zwischen ihnen lastenausgleichen. Wenn eine Region nicht verfügbar ist, wird sie aus der Drehung genommen.

Diese Referenzarchitektur konzentriert sich auf aktiv/passiv mit Hot Standby, wobei Traffic Manager für Failover verwendet wird. Sie können eine kleine Anzahl von virtuellen Computern für den Hot Standby bereitstellen und dann nach Bedarf skalieren.

Traffic-Manager-Konfiguration

Berücksichtigen Sie beim Konfigurieren von Traffic Manager die folgenden Punkte:

• Routing. Traffic Manager unterstützt mehrere Routingalgorithmen. Verwenden Sie für das in diesem Artikel beschriebene Szenario das Prioritätsrouting (früher als Failoverrouting bezeichnet). Mit dieser Einstellung sendet Traffic Manager alle Anforderungen an die primäre Region, es sei denn, die primäre Region ist nicht erreichbar. Zu diesem Zeitpunkt schlägt sie automatisch an die sekundäre Region fehl. Siehe Konfigurieren der Failoverroutingmethode.

• Integritätssonde. Der Datenverkehrs-Manager verwendet einen HTTP-Prüfpunkt (oder HTTPS), um die Verfügbarkeit der einzelnen Regionen zu überwachen. Der Test prüft auf eine HTTP 200-Antwort für einen angegebenen URL-Pfad. Erstellen Sie als bewährte Methode einen Endpunkt, der die allgemeine Integrität der Anwendung meldet, und verwenden Sie diesen Endpunkt für die Integritätssonde. Andernfalls meldet der Prüfpunkt möglicherweise einen fehlerfreien Endpunkt, wenn kritische Teile der Anwendung tatsächlich fehlschlagen. Weitere Informationen finden Sie im Health Endpoint Monitoring Pattern.

Wenn der Datenverkehrs-Manager einen Fehler überlässt, gibt es einen Zeitraum, in dem Clients die Anwendung nicht erreichen können. Die Dauer wird durch die folgenden Faktoren beeinflusst:

• Die Integritätssonde muss erkennen, dass die primäre Region nicht erreichbar ist.

• DNS-Server müssen die zwischengespeicherten DNS-Einträge für die IP-Adresse aktualisieren, was von der DNS-Time-to-Live (TTL) abhängt. Die Standardgültigkeitsdauer beträgt 300 Sekunden (5 Minuten), Sie können diesen Wert aber bei der Erstellung des Traffic Manager-Profils anpassen.

Ausführliche Informationen finden Sie unter "Über die Datenverkehrs-Manager-Überwachung".

Wenn der Datenverkehrs-Manager fehlschlägt, empfiehlt es sich, einen manuellen Failback durchzuführen, anstatt einen automatischen Failback zu implementieren. Andernfalls können Sie eine Situation erstellen, in der die Anwendung zwischen Regionen hin und her kippt. Stellen Sie sicher, dass alle Anwendungssubsysteme fehlerfrei sind, bevor ein Fehler auftritt.

Beachten Sie, dass Der Datenverkehrs-Manager standardmäßig automatisch fehlschlägt. Um dies zu verhindern, verringern Sie die Priorität der primären Region nach einem Failoverereignis manuell. Angenommen, die primäre Region ist Priorität 1, und die sekundäre ist Priorität 2. Legen Sie nach einem Failover den primären Bereich auf Priorität 3 fest, um automatische Failbacks zu verhindern. Wenn Sie bereit sind, um zu wechseln, aktualisieren Sie die Priorität auf 1.

Der folgende Azure CLI Befehl aktualisiert die Priorität:

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

Ein weiterer Ansatz besteht darin, den Endpunkt vorübergehend zu deaktivieren, bis Sie bereit sind, einen Failback zu unternehmen:

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

Je nach Ursache eines Failovers müssen Sie die Ressourcen in einer Region möglicherweise erneut bereitstellen. Bevor ein Fehler auftritt, führen Sie einen Betriebsbereitschaftstest aus. Der Test sollte Folgendes überprüfen:

• VMs sind ordnungsgemäß konfiguriert. (Alle erforderlichen Software ist installiert, IIS wird ausgeführt usw.)

• Anwendungssubsysteme sind fehlerfrei.

• Funktionale Tests. (Die Datenbankebene kann z. B. von der Webebene aus erreicht werden.)

Konfigurieren von SQL Server AlwaysOn-Verfügbarkeitsgruppen

Vor Windows Server 2016 benötigen SQL Server AlwaysOn-Verfügbarkeitsgruppen einen Domänencontroller, und alle Knoten in der Verfügbarkeitsgruppe müssen sich in derselben Active Directory (AD)-Domäne befinden.

So konfigurieren Sie die Verfügbarkeitsgruppe:

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

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

• Erstellen Sie VPN , um die Kommunikation zwischen zwei virtuellen Netzwerken zu ermöglichen.

• Fügen Sie für jedes virtuelle Netzwerk die IP-Adressen der Domänencontroller (aus beiden 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 Failoverclustering(WSFC)-Cluster, der die SQL Server Instanzen in beiden Regionen enthält.

• Erstellen Sie eine SQL Server AlwaysOn-Verfügbarkeitsgruppe, die die SQL Server Instanzen sowohl in den primären als auch in sekundären Regionen enthält. Die Schritte finden Sie unter Erweitern der AlwaysOn-Verfügbarkeitsgruppe auf Remote-Azure Datacenter (PowerShell).

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

  • Platzieren Sie ein oder mehrere sekundäre Replikate in der primären Region. Konfigurieren Sie diese so, dass synchroner Commit mit automatischem Failover verwendet wird.

  • Platzieren Sie mindestens ein sekundäres Replikat in der sekundären Region. Konfigurieren Sie diese für die Verwendung eines asynchronen Commits aus Leistungsgründen. (Andernfalls müssen alle T-SQL-Transaktionen auf einen Roundtrip über das Netzwerk in die sekundäre Region warten.)

Überlegungen zur Verfügbarkeit

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

Traffic Manager ist ein möglicher Fehlerpunkt im System. Wenn der Traffic Manager-Dienst fehlschlägt, können Clients während der Ausfallzeit nicht auf Ihre Anwendung zugreifen. Überprüfen Sie die SLA des Datenverkehrs-Managers, und ermitteln Sie, ob die Verwendung von Traffic Manager allein Ihre Geschäftlichen Anforderungen für hohe Verfügbarkeit erfüllt. Falls nicht, sollten Sie eine weitere Datenverkehrsverwaltungslösung als Failback hinzufügen. Wenn der Azure Traffic Manager Dienst fehlschlägt, ändern Sie Ihre CNAME-Einträge in DNS so, dass sie auf den anderen Datenverkehrsverwaltungsdienst verweisen. (Dieser Schritt muss manuell ausgeführt werden, und Ihre Anwendung ist erst verfügbar, wenn die DNS-Änderungen weitergegeben werden.)

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

• Alle SQL Server Datenbankreplikate in der primären Region schlagen fehl. Dieser Fehler kann z. B. während eines regionalen Ausfalls auftreten. In diesem Fall müssen Sie die Verfügbarkeitsgruppe manuell überschlagen, obwohl Traffic Manager automatisch auf dem Front-End fehlschlägt. Führen Sie die Schritte unter Ausführen eines erzwungenen manuellen Failovers einer SQL Server Verfügbarkeitsgruppe aus, die beschreibt, wie Sie ein erzwungenes Failover mithilfe von SQL Server Management Studio, Transact-SQL oder PowerShell in SQL Server 2016 ausführen.

  Warning

  Bei 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 finden.

• Der Datenverkehrs-Manager schlägt nicht in die sekundäre Region um, aber das primäre SQL Server Datenbankreplikat ist weiterhin verfügbar. Beispielsweise kann die Front-End-Ebene fehlschlagen, ohne dass sich dies auf die SQL Server VMs auswirkt. In diesem Fall wird der Internetdatenverkehr an die sekundäre Region weitergeleitet, und diese Region kann weiterhin eine Verbindung mit dem primären Replikat herstellen. Es gibt jedoch eine höhere Latenz, da die SQL Server Verbindungen über Regionen hinweg gehen. Führen Sie in diesem Fall ein manuelles Failover wie folgt aus:

  1. Vorübergehendes Wechseln eines SQL Server Datenbankreplikats im sekundären Bereich zum synchronen Commit. Diese Änderung stellt sicher, dass während des Failovers kein Datenverlust besteht.

  2. Dieses Replikat wird nicht übernommen.

  3. Wenn Sie den primären Bereich nicht aufrufen, stellen Sie die Einstellung für den asynchronen Commit wieder her.

Überlegungen zur Verwaltbarkeit

Wenn Sie Die Bereitstellung aktualisieren, aktualisieren Sie jeweils eine Region, um die Wahrscheinlichkeit eines globalen Fehlers aus einer falschen Konfiguration oder einem Fehler in der Anwendung zu verringern.

Testen Sie die Ausfallsicherheit des Systems auf Fehler. Im Folgenden finden Sie einige häufige Fehlerszenarien zum Testen:

• Herunterfahren von VM-Instanzen.

• Druckressourcen wie CPU und Arbeitsspeicher.

• Trennen oder Verzögern des Netzwerks

• Absturzprozesse.

• Ablaufen von Zertifikaten.

• Simulieren von Hardwarefehlern.

• Beenden Sie den DNS-Dienst auf den Domänencontrollern.

Messen Sie die Wiederherstellungszeiten, und überprüfen Sie, ob sie Ihren Geschäftlichen Anforderungen entsprechen. Testen Sie auch Kombinationen von Fehlermodi.

Nächste Schritte

• Weitere Informationen zu Azure Cloud Patterns finden Sie unter Cloud Design Patterns.