Een N-tier-toepassing uitvoeren in meerdere Azure Stack Hub regio's voor hoge beschikbaarheid

Deze referentiearchitectuur toont een set bewezen procedures voor het uitvoeren van een N-tier-toepassing in meerdere Azure Stack Hub regio's om beschikbaarheid en een robuuste infrastructuur voor herstel na noodgevallen te realiseren. In deze architectuur wordt Azure Traffic Manager gebruikt om hoge beschikbaarheid te bereiken. Als Traffic Manager echter geen voorkeurskeuze is in uw omgeving, kunt u een paar maximaal beschikbare load balancers vervangen.

Architecture

Deze architectuur bouwt voort op de architectuur die wordt weergegeven in de N-laag-toepassing met SQL Server.

• Primaire en secundaire regio's. Gebruik twee regio's om een hogere beschikbaarheid te bereiken. Eén regio is de primaire regio. Gebruik de andere regio voor failover.

• Azure Traffic Manager. Traffic Manager stuurt binnenkomende aanvragen naar een van de regio's. Tijdens normale bewerkingen worden aanvragen gerouteerd naar de primaire regio. Als deze regio niet beschikbaar is, voert Traffic Manager een failover uit naar de secundaire regio. Zie de sectie Traffic Manager-configuratie voor meer informatie.

• Resourcegroepen. Maak afzonderlijke resourcegroepen voor de primaire regio en de secundaire regio. Deze benadering biedt u de flexibiliteit om elke regio te beheren als één verzameling resources. U kunt bijvoorbeeld één regio opnieuw implementeren zonder de andere regio uit te schakelen. Koppel de resourcegroepen, zodat u een query kunt uitvoeren om alle resources voor de toepassing weer te geven.

• Virtuele netwerken. Maak een afzonderlijk virtueel netwerk voor elke regio. Zorg ervoor dat de adresruimten niet overlappen.

• Sql Server AlwaysOn-beschikbaarheidsgroep. Als u SQL Server gebruikt, gebruikt u SQL AlwaysOn-beschikbaarheidsgroepen voor hoge beschikbaarheid. Maak één beschikbaarheidsgroep die de SQL Server exemplaren in beide regio's bevat.

• VNET naar VNET VPN-verbinding. Omdat VNET-peering nog niet beschikbaar is op Azure Stack Hub, gebruikt u VNET naar VNET VPN-verbinding om de twee VNET's te verbinden. Zie VNET naar VNET in Azure Stack Hub voor meer informatie.

Recommendations

Een architectuur met meerdere regio's kan een hogere beschikbaarheid bieden dan implementeren in één regio. Als een regionale storing van invloed is op de primaire regio, kunt u Traffic Manager gebruiken om een failover uit te voeren naar de secundaire regio. Deze architectuur kan ook helpen als een afzonderlijk subsysteem van de toepassing mislukt.

Er zijn verschillende algemene benaderingen voor het bereiken van hoge beschikbaarheid in verschillende regio's:

• Actief/passief met hot stand-by. Verkeer gaat naar de ene regio, terwijl de andere wacht op hot stand-by. Hot stand-by betekent dat de VM's in de secundaire regio altijd worden toegewezen en uitgevoerd.

• Actief/passief met koude stand-by. Verkeer gaat naar één regio, terwijl de andere wacht op koude stand-by. Koude stand-by betekent dat de VM's in de secundaire regio pas worden toegewezen als deze nodig zijn voor failover. Deze benadering kost minder om te worden uitgevoerd, maar duurt over het algemeen langer om online te komen tijdens een storing.

• Actief/actief. Beide regio's zijn actief en aanvragen worden verdeeld over de taken. Als één regio niet meer beschikbaar is, wordt deze uit de rotatie gehaald.

Deze referentiearchitectuur is gericht op actief/passief met hot stand-by, waarbij Traffic Manager wordt gebruikt voor failover. U kunt een klein aantal VM's implementeren voor hot stand-by en vervolgens naar behoefte uitschalen.

Traffic Manager-configuratie

Houd rekening met de volgende punten bij het configureren van Traffic Manager:

• Routering. Traffic Manager ondersteunt verschillende routeringsalgoritmen. Gebruik prioriteitsroutering (voorheen failoverroutering genoemd) voor het scenario dat in dit artikel wordt beschreven. Met deze instelling verzendt Traffic Manager alle aanvragen naar de primaire regio, tenzij de primaire regio onbereikbaar wordt. Op dat moment wordt automatisch een failover uitgevoerd naar de secundaire regio. Zie De routeringsmethode voor failover configureren.

• Statustest. Traffic Manager gebruikt een HTTP-test (of HTTPS) om de beschikbaarheid van elke regio te bewaken. Met de test wordt gecontroleerd op een HTTP 200-respons van een opgegeven URL-pad. Maak als best practice een eindpunt dat de algehele status van de toepassing rapporteert en gebruik dit eindpunt voor de statustest. Anders kan de test een goed eindpunt rapporteren wanneer kritieke onderdelen van de toepassing daadwerkelijk mislukken. Zie Gezondheidseindpuntbewakingspatroon voor meer informatie.

Wanneer traffic manager een failover-overschakeling uitvoert, is er een periode waarin clients de toepassing niet kunnen bereiken. De duur wordt beïnvloed door de volgende factoren:

• De statustest moet detecteren dat de primaire regio onbereikbaar is geworden.

• DNS-servers moeten de DNS-records in de cache bijwerken voor het IP-adres, die afhankelijk zijn van de TTL (Time-to-Live) van DNS. Standaard is de TTL-waarde 300 seconden (5 minuten), maar u kunt deze waarde configureren wanneer u het Traffic Manager-profiel maakt.

Zie Voor meer informatie over Traffic Manager-bewaking.

Als traffic manager een failover uitvoert, raden we u aan een handmatige failback uit te voeren in plaats van een automatische failback te implementeren. Anders kunt u een situatie maken waarin de toepassing heen en weer wordt gespiegeld tussen regio's. Controleer of alle toepassingssubsystemen in orde zijn voordat u een failback uitvoert.

Houd er rekening mee dat Traffic Manager standaard automatisch een failback uitvoert. Om dit te voorkomen, verlaagt u handmatig de prioriteit van de primaire regio na een failover-gebeurtenis. Stel dat de primaire regio prioriteit 1 heeft en dat de secundaire regio prioriteit 2 heeft. Stel na een failover de primaire regio in op prioriteit 3 om automatische failback te voorkomen. Wanneer u klaar bent om over te schakelen, werkt u de prioriteit bij naar 1.

Met de volgende Azure CLI opdracht wordt de prioriteit bijgewerkt:

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

Een andere methode is om het eindpunt tijdelijk uit te schakelen totdat u klaar bent om failback uit te voeren:

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

Afhankelijk van de oorzaak van een failover moet u de resources in een regio mogelijk opnieuw implementeren. Voordat u een failback uitvoert, moet u een operationele gereedheidstest uitvoeren. De test moet zaken controleren zoals:

• VM's zijn correct geconfigureerd. (Alle vereiste software is geïnstalleerd, IIS wordt uitgevoerd, enzovoort.)

• Toepassingssubsystemen zijn in orde.

• Functioneel testen. (De databaselaag is bijvoorbeeld bereikbaar vanuit de weblaag.)

AlwaysOn-beschikbaarheidsgroepen configureren SQL Server

Vóór Windows Server 2016 moet SQL Server AlwaysOn-beschikbaarheidsgroepen een domeincontroller vereisen en moeten alle knooppunten in de beschikbaarheidsgroep zich in hetzelfde Active Directory (AD)-domein bevinden.

De beschikbaarheidsgroep configureren:

• Plaats minimaal twee domeincontrollers in elke regio.

• Geef elke domeincontroller een statisch IP-adres.

• Maak VPN om communicatie tussen twee virtuele netwerken mogelijk te maken.

• Voeg voor elk virtueel netwerk de IP-adressen van de domeincontrollers (van beide regio's) toe aan de lijst met DNS-servers. U kunt de volgende CLI-opdracht gebruiken. Zie DNS-servers wijzigen voor meer informatie.

  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"
  

• Maak een Windows Server WSFC-cluster (Failover Clustering) dat de SQL Server exemplaren in beide regio's bevat.

• Maak een SQL Server AlwaysOn-beschikbaarheidsgroep met de SQL Server exemplaren in zowel de primaire als de secundaire regio's. Zie AlwaysOn-beschikbaarheidsgroep uitbreiden naar Extern Azure Datacenter (PowerShell) voor de stappen.

  • Plaats de primaire replica in de primaire regio.

  • Plaats een of meer secundaire replica's in de primaire regio. Configureer deze voor het gebruik van synchrone doorvoer met automatische failover.

  • Plaats een of meer secundaire replica's in de secundaire regio. Configureer deze om asynchrone doorvoer om prestatieredenen. (Anders moeten alle T-SQL-transacties wachten op een retour via het netwerk naar de secundaire regio.)

Overwegingen voor beschikbaarheid

Met een complexe N-tier-app hoeft u mogelijk niet de hele toepassing in de secundaire regio te repliceren. In plaats daarvan kunt u alleen een kritiek subsysteem repliceren dat nodig is om bedrijfscontinuïteit te ondersteunen.

Traffic Manager is een mogelijk storingspunt in het systeem. Als de Traffic Manager-service mislukt, hebben clients tijdens de downtime geen toegang tot uw toepassing. Controleer de SLA van Traffic Manager en bepaal of het gebruik van Traffic Manager alleen voldoet aan uw zakelijke vereisten voor hoge beschikbaarheid. Zo niet, overweeg dan een andere oplossing voor verkeersbeheer toe te voegen als failback. Als de Azure Traffic Manager-service mislukt, wijzigt u uw CNAME-records in DNS zodat deze verwijst naar de andere verkeersbeheerservice. (Deze stap moet handmatig worden uitgevoerd en uw toepassing is niet beschikbaar totdat de DNS-wijzigingen worden doorgegeven.)

Voor het SQL Server-cluster zijn er twee failoverscenario's om rekening mee te houden:

• Alle SQL Server databasereplica's in de primaire regio mislukken. Deze fout kan bijvoorbeeld optreden tijdens een regionale storing. In dat geval moet u handmatig een failover uitvoeren voor de beschikbaarheidsgroep, ook al voert Traffic Manager automatisch een failover uit op de front-end. Volg de stappen in Een geforceerde handmatige failover uitvoeren van een SQL Server beschikbaarheidsgroep, waarin wordt beschreven hoe u een geforceerde failover uitvoert met behulp van SQL Server Management Studio, Transact-SQL of PowerShell in SQL Server 2016.

  Warning

  Bij geforceerde failover bestaat er een risico op gegevensverlies. Zodra de primaire regio weer online is, maakt u een momentopname van de database en gebruikt u de ingediende regio om de verschillen te vinden.

• Traffic Manager voert een failover uit naar de secundaire regio, maar de primaire SQL Server databasereplica is nog steeds beschikbaar. De front-endlaag kan bijvoorbeeld mislukken zonder dat dit van invloed is op de SQL Server VM's. In dit geval wordt internetverkeer doorgestuurd naar de secundaire regio en kan die regio nog steeds verbinding maken met de primaire replica. Er is echter meer latentie, omdat de SQL Server verbindingen tussen regio's gaan. In dit geval voert u als volgt een handmatige failover uit:

  1. Schakel tijdelijk een SQL Server databasereplica in de secundaire regio over naar synchrone doorvoer. Deze wijziging zorgt ervoor dat er tijdens de failover geen gegevensverlies is.

  2. Voer een failover uit naar die replica.

  3. Wanneer u een failback naar de primaire regio uitvoert, herstelt u de asynchrone doorvoerinstelling.

Overwegingen voor beheerbaarheid

Wanneer u uw implementatie bijwerkt, moet u één regio tegelijk bijwerken om de kans op een globale fout te verminderen van een onjuiste configuratie of een fout in de toepassing.

Test de tolerantie van het systeem op fouten. Hier volgen enkele veelvoorkomende foutscenario's om te testen:

• VM-exemplaren afsluiten.

• Drukbronnen zoals CPU en geheugen.

• Verbreek de verbinding of vertraging van het netwerk.

• Crashprocessen.

• Certificaten laten verlopen.

• Hardwarefouten simuleren.

• Sluit de DNS-service op de domeincontrollers af.

Meet de hersteltijden en controleer of ze voldoen aan uw bedrijfsvereisten. Test ook combinaties van foutmodi.

Volgende stappen 

• Zie Cloudontwerppatronen voor meer informatie over Azure Cloud Patterns.