Een N-tier-toepassing in meerdere regio's

Monitor
Traffic Manager
SQL Database
Virtual Machines

Deze referentie-architectuur heeft in de praktijk bewezen geschikt te zijn voor het uitvoeren van een toepassing met n-aantal lagen in meerdere Azure-regio's en biedt een hoge mate van beschikbaarheid en een robuuste infrastructuur voor noodherstel.

Zeer beschikbare netwerkarchitectuur voor Azure N-tier-toepassingen

Een Visio-bestand van deze architectuur downloaden.

Architectuur

Deze architectuur is gebaseerd op de architectuur die wordt weergegeven in de N-tier-toepassing met SQL Server.

  • Primaire en secundaire regio. Gebruik twee regio's voor hogere beschikbaarheid. De ene regio is de primaire regio. De andere regio is voor failover.

  • Azure Traffic Manager. Met Traffic Manager worden binnenkomende aanvragen gerouteerd naar een van de regio's. Normaliter worden aanvragen gerouteerd naar de primaire regio. Als de primaire regio niet beschikbaar is, wordt in Traffic Manager een Failover-schakeling naar de secundaire regio uitgevoerd. Zie de sectie Configuratie van Traffic Manager voor meer informatie.

  • Resourcegroepen. Maak afzonderlijke resourcegroepen voor de primaire regio, de secundaire regio en Traffic Manager. Dit biedt u de flexibiliteit om elke regio te beheren als één verzameling resources. U kunt bijvoorbeeld één regio opnieuw implementeren zonder de andere regio offline te nemen. Koppel de resourcegroepen, zodat u een query voor het weergeven van alle resources voor de toepassing kunt uitvoeren.

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

  • SQL Server Always On-beschikbaarheidsgroep. Voor hoge beschikbaarheid van de SQL-server, raden we SQL AlwaysOn-beschikbaarheidsgroepen aan. Maak één beschikbaarheidsgroep met de SQL Server-exemplaren in beide regio's.

    Notitie

    Overweeg ook of u Azure SQL Database, een relationele database als een cloudservice, wilt gebruiken. Met SQL Database hoeft u geen beschikbaarheidsgroep te configureren of failover te beheren.

  • Peering voor virtuele netwerken. Peering van de twee virtuele netwerken om gegevensreplicatie van de primaire regio naar de secundaire regio toe te staan. Zie Peering voor virtuele netwerken voor meer informatie.

Aanbevelingen

Een architectuur met meerdere regio's kan zorgen voor een hogere beschikbaarheid dan een implementatie in één regio. Als een regionale storing van invloed is op de primaire regio, kunt u met Traffic Manager een Failover-schakeling naar de secundaire regio uitvoeren. Deze architectuur kan ook helpen als een afzonderlijk subsysteem van de toepassing uitvalt.

Er zijn verschillende algemene methoden voor het bereiken van maximale beschikbaarheid in regio's:

  • Actief/passief met hot stand-by. Het verkeer wordt gerouteerd naar één regio, terwijl de andere regio wacht in hot stand-by. Hot stand-by betekent dat de virtuele machines in de secundaire regio zijn toegewezen en te allen tijde worden uitgevoerd.
  • Actief/passief met koude stand-by. Het verkeer wordt gerouteerd naar de ene regio, terwijl de andere regio wacht in koude stand-by. Koude stand-by betekent dat de virtuele machines in de secundaire regio pas worden toegewezen wanneer dat nodig is voor failover. Deze methode is goedkoper qua uitvoering, maar het duurt langer om het systeem weer online te brengen na uitval.
  • Actief/actief. Beide regio's zijn actief en aanvragen worden gelijkmatig verdeeld tussen beide regio's. Als een regio niet beschikbaar is, wordt deze uit de roulatie gehaald.

Deze referentiearchitectuur is gericht op actief/passief met hot stand-by, en Traffic Manager voor failover. U kunt een klein aantal virtuele machines voor hot stand-by implementeren en vervolgens naar behoefte uitschalen.

Regioparen

Elke Azure-regio is gekoppeld aan een andere regio binnen dezelfde geografie. Over het algemeen kiest u regioparen uit dezelfde regio (bijvoorbeeld VS - oost 2 en VS - centraal). Voordelen hiervan zijn:

  • Bij een grootschalige storing wordt aan ten minste één regio van elk paar prioriteit gegeven.
  • Geplande Azure-systeemupdates worden na elkaar uitgerold voor gekoppelde regio's, om eventuele downtime tot een minimum te beperken.
  • Regioparen bevinden zich vaak binnen dezelfde geografie, om te voldoen aan gegevenslocatievereisten.

Controleer wel of alle Azure-services die nodig zijn voor uw toepassing in beide regio's worden ondersteund (zie Services per regio). Raadpleeg voor meer informatie over regioparen Bedrijfscontinuïteit en herstel na noodgevallen (BCDR): gekoppelde Azure-regio's voor meer informatie.

Configuratie van Traffic Manager

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

  • Routering. Traffic Manager biedt ondersteuning voor diverse routeringsalgoritmen. Voor het scenario dat in dit artikel wordt beschreven, gebruikt u routering voor prioriteit (voorheen routering voor failover). Bij deze instelling worden alle aanvragen door Traffic Manager verzonden naar de primaire regio, tenzij de primaire regio onbereikbaar wordt. Op dat moment wordt automatisch een Failover-schakeling naar de secundaire regio uitgevoerd. Zie Methode voor failover-routering configureren.
  • Statustest. Traffic Manager maakt gebruik van een HTTP- (of HTTPS-)test om de beschikbaarheid van elke regio te controleren. Met de test wordt gecontroleerd op een HTTP 200-respons van een opgegeven URL-pad. Maak, als een best practice, een eindpunt waarmee de algemene status van de toepassing wordt gerapporteerd en gebruik dit eindpunt voor de statustest. Anders wordt mogelijk een gezond eindpunt (testresultaat Geslaagd) gerapporteerd, terwijl essentiële onderdelen van de toepassing in werkelijkheid niet correct functioneren. Zie Health Endpoint Monitoring pattern (Patroon Status van eindpuntbewaking) voor meer informatie.

Tijdens het uitvoeren van deze Failover-overschakeling door Traffic Manager is de toepassing tijdelijk niet bereikbaar voor clients. Hoe lang dit duurt, is afhankelijk van de volgende factoren:

  • Met de statustest moet worden gedetecteerd dat de primaire regio onbereikbaar is geworden.
  • DNS-servers moeten de DNS-records voor het IP-adres in de cache bijwerken. Hoe lang dit duurt, is afhankelijk van de DNS TTL (Time To Live). Standaard is de TTL-waarde 300 seconden (5 minuten), maar u kunt deze waarde configureren wanneer u het Traffic Manager-profiel maakt.

Zie Traffic Manager-controle voor meer informatie.

Bij een failover van Traffic Manager raden wij u aan een handmatige failback uit te voeren in plaats van een automatische failback te implementeren. Anders ontstaat er een situatie waarin de toepassing steeds van de ene naar de andere regio wordt overgeschakeld. Voer een statuscontrole van alle subsystemen voor de toepassing uit voordat u een failback uitvoert.

Houd er rekening mee dat voor Traffic Manager failback automatisch wordt uitgevoerd. Om dit te voorkomen, verlaagt u handmatig de prioriteit van de primaire regio na een failover-gebeurtenis. Stel, de primaire regio heeft prioriteit 1 en de secundaire regio heeft prioriteit 2. Na een failover stelt u de primaire regio in op prioriteit 3, zodat er niet automatisch een failback wordt uitgevoerd. Wanneer u gereed bent om terug te schakelen, stelt u de prioriteit weer in op 1.

U wijzigt de prioriteit met de volgende Azure CLI-opdracht:

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

Een andere methode is het eindpunt tijdelijk uit te schakelen totdat u klaar bent voor het uitvoeren van een failback:

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type azureEndpoints --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. Tijdens de test moet onder meer het volgende worden gecontroleerd:

  • Virtuele machines zijn juist geconfigureerd. (Alle vereiste software is geïnstalleerd, IIS is actief, enzovoort.)
  • Subsystemen van de toepassing zijn in orde.
  • Functionele testen. (Bijvoorbeeld: de databaselaag is bereikbaar vanaf de weblaag.)

AlwaysOn-beschikbaarheidsgroepen in SQL Server configureren

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

De beschikbaarheidsgroep configureren:

  • Plaats ten minste twee domeincontrollers in elke regio.

  • Geef elke domeincontroller een statisch IP-adres.

  • Peering van de twee virtuele netwerken om communicatie tussen deze 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 hiervoor de volgende opdracht in de opdrachtregelinterface 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 WSFC-cluster (Windows Server-failoverclustering) met de SQL Server-exemplaren in beide regio's.

  • Maak een AlwaysOn-beschikbaarheidsgroep in SQL Server met de SQL Server-exemplaren in de primaire en secundaire regio's. Zie Extending Always On Availability Group to Remote Azure Datacenter (PowerShell) (AlwaysOn-beschikbaarheidsgroep uitbreiden naar extern Azure-datacenter) voor de benodigde 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 voor het gebruik van asynchrone doorvoer, voor betere prestaties. (Anders moeten alle T-SQL-transacties wachten op een retour via het netwerk naar de secundaire regio.)

      Notitie

      Automatische failover wordt niet ondersteund voor replica's met asynchrone doorvoer.

Beschikbaarheidsoverwegingen

Bij een complexe app met n-aantal lagen hoeft u wellicht niet hele toepassing in de secundaire regio te repliceren. In plaats daarvan kunt u ook alleen een kritiek subsysteem repliceren dat vereist is voor de bedrijfscontinuïteit.

Traffic Manager is een mogelijk punt van mislukken in het systeem. Als de Traffic Manager-service uitvalt, hebben clients geen toegang tot uw toepassing tijdens de downtime. Controleer de SLA voor Traffic Manager en bepaal of het gebruik van alleen Traffic Manager voldoet aan uw zakelijke vereisten voor hoge beschikbaarheid. Als dat niet het geval is, overweeg dan een andere oplossing voor het beheer van verkeer toe te voegen als failback. Als de service Azure Traffic Manager uitvalt, wijzigt u de CNAME-records in DNS zodanig dat ze verwijzen naar de andere service voor verkeerbeheer. (Deze stap moet handmatig worden uitgevoerd en uw toepassing pas weer beschikbaar als de DNS-wijzigingen zijn doorgegeven.)

Voor de SQL Server-cluster moet u rekening houden met twee failoverscenario's:

  • Alle SQL Server-databasereplica's in de primaire regio mislukken. Dit kan bijvoorbeeld gebeuren tijdens een regionale storing. In dat geval moet u handmatig een Failover-schakeling van de beschikbaarheidsgroep uitvoeren, ook al wordt automatisch een Failover-schakeling van Traffic Manager uitgevoerd op de front-end. Volg de stappen in Perform a Forced Manual Failover of a SQL Server Availability Group (Engelstalig) uit. Hierin wordt beschreven hoe u een geforceerde failover kunt uitvoeren met SQL Server Management Studio, Transact-SQL of PowerShell in SQL Server 2016.

    Waarschuwing

    Bij een geforceerde failover loopt u het risico dat er gegevens verloren gaan. Zodra de primaire regio weer online is, maakt u een momentopname van de database en gebruikt u tablediff om de verschillen te zoeken.

  • Er wordt een Failover-schakeling van Traffic Manager naar de secundaire regio uitgevoerd, maar de primaire replica van de SQL Server-database is nog steeds beschikbaar. De front-endlaag kan bijvoorbeeld mislukken, zonder de virtuele SQL Server-machines te beïnvloeden. In dat geval wordt het internetverkeer omgeleid naar de secundaire regio, en die regio kan nog steeds verbinding maken met de primaire replica. De latentie zal echter toenemen, vanwege de SQL Server-verbindingen tussen de verschillende regio's. In dit geval moet u als volgt een handmatige failover uitvoeren:

    1. Schakel een replica van de SQL Server-database in de secundaire regio tijdelijk over naar synchrone doorvoer. Dit zorgt ervoor dat er geen gegevens verloren gaan tijdens de failover.
    2. Voer een Failover-overschakeling naar die replica uit.
    3. Als u een failback naar de primaire regio uitvoert, herstelt u de instelling voor asynchrone doorvoer.

Beheerbaarheidsoverwegingen

Werk, als u de implementatie wilt bijwerken, slechts één regio tegelijk bij om de kans op algehele uitval wegens een onjuiste configuratie of een fout in de toepassing te verkleinen.

Test de fouttolerantie van het systeem. Hier volgen enkele veelvoorkomende foutscenario's die u kunt testen:

  • VM-exemplaren afsluiten.
  • CPU- en geheugenresources zwaar belasten.
  • Netwerkverbinding verbreken/vertragen.
  • Processen laten vastlopen.
  • Certificaten laten verlopen.
  • Hardwarefouten simuleren.
  • De DNS-service op de domeincontrollers afsluiten.

Meet de hersteltijden en controleer of deze voldoen aan de vereisten van uw bedrijf. Test ook combinaties van foutmodi.

Kostenoverwegingen

Gebruik de Azure-prijscalculator om een schatting te maken van de kosten. Hier zijn enkele andere overwegingen.

Virtuele-machineschaalsets

Virtuele-machineschaalsets zijn beschikbaar op Windows VM-grootten. Er worden alleen kosten in rekening gebracht voor de Azure-VM's die u implementeert en eventuele extra onderliggende infrastructuurbronnen die worden verbruikt, zoals opslag en netwerken. Er worden geen incrementele kosten in rekening gebracht voor de service Virtuele-machineschaalsets.

Zie prijzen voor enkele VM's Windows prijzen voor VM's.

SQL Server

Als u Azure SQL DPlatform, kunt u besparen op kosten omdat u geen Always On-beschikbaarheidsgroep en domeincontrollermachines hoeft te configureren. Er zijn verschillende implementatieopties, van individuele databases tot beheerde exemplaren of elastische pools. Zie Prijzen voor Azure SQL voor meer informatie.

Zie SQL prijzen voor VM's voor SQL server.

Load balancers

Er worden alleen kosten in rekening gebracht voor het aantal geconfigureerde taakverdelings- en uitgaande regels. Inkomende NAT-regels zijn gratis. Er worden geen uurkosten in rekening Standard Load Balancer wanneer er geen regels zijn geconfigureerd.

Traffic Manager prijzen

Traffic Manager facturering is gebaseerd op het aantal ontvangen DNS-query's, met korting voor services die meer dan 1 miljard maandelijkse query's ontvangen. Er worden ook kosten in rekening gebracht voor elk bewaakt eindpunt.

Raadpleeg de kostensectie in Microsoft Azure Well-Architected Framework voor meer informatie.

VNET-Peering prijzen

Een implementatie met hoge beschikbaarheid die gebruik maakt van meerdere Azure-regio's, maakt gebruik van VNET-peering. Er worden verschillende kosten in rekening gebracht VNET-Peering binnen dezelfde regio en voor wereldwijde VNET-peering.

Zie Prijzen voor Virtual Network voor meer informatie.

DevOps overwegingen

Gebruik één sjabloon Azure Resource Manager voor het inrichten van de Azure-resources en de afhankelijkheden ervan. Gebruik dezelfde sjabloon om de resources te implementeren in zowel primaire als secundaire regio's. Neem alle resources op in hetzelfde virtuele netwerk, zodat ze worden geïsoleerd in dezelfde basisworkload, waardoor het eenvoudiger is om de specifieke resources van de workload te koppelen aan een DevOps-team, zodat het team alle aspecten van deze resources onafhankelijk kan beheren. Door deze isolatie kunnen DevOps Team en Services continue integratie en continue levering (CI/CD) uitvoeren.

U kunt ook verschillende Azure Resource Manager-sjablonen gebruiken en deze integreren met Azure DevOps Services om binnen enkele minuten verschillende omgevingen in terichten, bijvoorbeeld om productie-, zoals scenario's of belastingstestomgevingen alleen te repliceren wanneer dat nodig is, wat kosten bespaart.

Overweeg het gebruik van de Azure Monitor voor het analyseren en optimaliseren van de prestaties van uw infrastructuur, het bewaken en diagnosticeren van netwerkproblemen zonder u aan te melden bij uw virtuele machines. Application Insights is in feite een van de onderdelen van Azure Monitor, die u uitgebreide metrische gegevens en logboeken biedt om de status van uw volledige Azure-landschap te controleren. Azure Monitor helpt u de status van uw infrastructuur te volgen.

Zorg ervoor dat u niet alleen uw rekenelementen bewaakt die uw toepassingscode ondersteunen, maar ook uw gegevensplatform, met name uw databases, omdat een lage prestaties van de gegevenslaag van een toepassing ernstige gevolgen kunnen hebben.

Als u de Azure-omgeving wilt testen waarin de toepassingen worden uitgevoerd, moet de versie worden beheerd en geïmplementeerd via dezelfde mechanismen als toepassingscode. Vervolgens kan deze ook worden getest en gevalideerd met behulp van DevOps-testparadigma's.

Zie de sectie Operational Excellence in Microsoft Azure Well-Architected Framework voor meer informatie.

In de volgende architectuur worden enkele van dezelfde technologieën gebruikt: