Herstel na noodgevallen met Azure DNS en Traffic Manager

Herstel na noodgevallen is gericht op het herstellen van een ernstig verlies van de functionaliteit van de toepassing. Als u een oplossing voor herstel na noodgevallen wilt kiezen, moeten bedrijfs- en technologie-eigenaren eerst het vereiste functionaliteitsniveau bepalen tijdens een noodgeval, zoals - niet beschikbaar, gedeeltelijk beschikbaar via verminderde functionaliteit of vertraagde beschikbaarheid, of volledig beschikbaar. De meeste zakelijke klanten kiezen voor een architectuur met meerdere regio's voor tolerantie tegen failover op toepassings- of infrastructuurniveau. Klanten kunnen verschillende benaderingen kiezen in de zoektocht naar failover en hoge beschikbaarheid via redundante architectuur. Hier volgen enkele van de populaire benaderingen:

  • Actief-passief met koude stand-by: in deze failoveroplossing zijn de VM's en andere apparaten die worden uitgevoerd in de stand-byregio pas actief als er failover nodig is. De productieomgeving wordt echter gerepliceerd in de vorm van back-ups, VM-installatiekopieën of Resource Manager sjablonen naar een andere regio. Dit failovermechanisme is rendabel, maar het duurt langer om een volledige failover uit te voeren.

    Active/Passive with cold standby

    Afbeelding - Actief/passief met configuratie voor herstel na noodgeval met koude stand-by

  • Actief/passief met pilotlicht: In deze failover-oplossing wordt de stand-byomgeving ingesteld met een minimale configuratie. De installatie heeft alleen de benodigde services die worden uitgevoerd ter ondersteuning van slechts een minimale en kritieke set toepassingen. In de systeemeigen vorm kan dit scenario alleen minimale functionaliteit uitvoeren, maar kan meer services omhoog schalen en spawn om bulksgewijs de productiebelasting te nemen als er een failover optreedt.

    Active/Passive with pilot light

    Afbeelding: Actief/passief met configuratie voor noodherstel na noodgeval

  • Actief/passief met warme stand-by: in deze failover-oplossing wordt de stand-byregio vooraf opgewarmd en is deze klaar om de basisbelasting te nemen, wordt automatisch schalen ingeschakeld en worden alle exemplaren actief. Deze oplossing wordt niet geschaald om de volledige productiebelasting te nemen, maar is functioneel en alle services zijn actief. Deze oplossing is een uitgebreide versie van de pilot light-benadering.

    Active/Passive with warm standby

    Afbeelding: Actief/passief met configuratie voor warm stand-by-noodherstel

Zie Herstel na noodgevallen voor Azure-toepassingen voor meer informatie over failover en hoge beschikbaarheid.

Uw architectuur voor herstel na noodgevallen plannen

Er zijn twee technische aspecten voor het instellen van uw architectuur voor herstel na noodgevallen:

  • Met behulp van een implementatiemechanisme voor het repliceren van exemplaren, gegevens en configuraties tussen primaire en stand-by-omgevingen. Dit type noodherstel kan systeemeigen worden uitgevoerd via Azure Site-Recovery via Microsoft Azure partnerapparaten/-services zoals Veritas of NetApp.
  • Een oplossing ontwikkelen om netwerk-/webverkeer van de primaire site naar de stand-bysite te leiden. Dit type noodherstel kan worden bereikt via Azure DNS, Azure Traffic Manager(DNS) of wereldwijde load balancers van derden.

Dit artikel is beperkt tot benaderingen via netwerk- en webverkeersomleiding. Zie de documentatie voor Azure Site Recovery voor instructies voor het instellen van Azure Site Recovery. DNS is een van de meest efficiënte mechanismen voor het omleiden van netwerkverkeer, omdat DNS vaak globaal en extern is voor het datacenter en geïsoleerd is van eventuele regionale of beschikbaarheidszonefouten (AZ). U kunt een failovermechanisme op basis van DNS gebruiken en in Azure kunnen twee DNS-services op een bepaalde manier hetzelfde bereiken: Azure DNS (gezaghebbende DNS) en Azure Traffic Manager (op DNS gebaseerde slimme verkeersroutering).

Het is belangrijk om enkele concepten in DNS te begrijpen die uitgebreid worden gebruikt om de oplossingen in dit artikel te bespreken:

  • DNS A-record : A-records zijn aanwijzers die een domein naar een IPv4-adres wijzen.
  • CNAME- of Canonical-naam : dit recordtype wordt gebruikt om naar een andere DNS-record te verwijzen. CNAME reageert niet met een IP-adres, maar in plaats daarvan de aanwijzer op de record die het IP-adres bevat.
  • Gewogen routering : u kunt ervoor kiezen om een gewicht aan service-eindpunten te koppelen en vervolgens het verkeer te distribueren op basis van de toegewezen gewichten. Deze routeringsmethode is een van de vier mechanismen voor verkeersroutering die beschikbaar zijn in Traffic Manager. Zie Gewogen routeringsmethode voor meer informatie.
  • Prioriteitsroutering : prioriteitsroutering is gebaseerd op statuscontroles van eindpunten. Azure Traffic Manager verzendt standaard al het verkeer naar het eindpunt met de hoogste prioriteit en bij een storing of noodgeval Traffic Manager het verkeer doorstuurt naar het secundaire eindpunt. Zie prioriteitsrouteringsmethode voor meer informatie.

Handmatige failover met Behulp van Azure DNS

De handmatige failoveroplossing van Azure DNS voor herstel na noodgevallen maakt gebruik van het standaard-DNS-mechanisme om een failover naar de back-upsite uit te voeren. De handmatige optie via Azure DNS werkt het beste wanneer deze wordt gebruikt in combinatie met de koude stand-by of de pilotlichtbenadering.

Manual failover using Azure DNS

Afbeelding: handmatige failover met Behulp van Azure DNS

De veronderstellingen voor de oplossing zijn:

  • Zowel primaire als secundaire eindpunten hebben statische IP-adressen die niet vaak veranderen. Stel dat voor de primaire site het IP-adres 100.168.124.44 is en het IP-adres voor de secundaire site 100.168.124.43 is.
  • Er bestaat een Azure DNS-zone voor zowel de primaire als de secundaire site. Stel dat het eindpunt voor de primaire site prod.contoso.com is en dat voor de back-upsite dr.contoso.com. Er bestaat ook een DNS-record voor de hoofdtoepassing die bekend staat als www.contoso.com.
  • De TTL bevindt zich op of onder de RTO SLA die is ingesteld in de organisatie. Als een onderneming bijvoorbeeld de RTO van de reactie op de toepassingsramp instelt op 60 minuten, moet de TTL kleiner zijn dan 60 minuten, bij voorkeur hoe lager des te beter. U kunt Azure DNS als volgt instellen voor handmatige failover:
  • Een DNS-zone maken
  • DNS-zonerecords maken
  • CNAME-record bijwerken

Stap 1: een DNS maken

Maak een DNS-zone (bijvoorbeeld www.contoso.com), zoals hieronder wordt weergegeven:

Create a DNS zone in Azure

Afbeelding: een DNS-zone maken in Azure

Stap 2: DNS-zonerecords maken

Maak in deze zone drie records (bijvoorbeeld www.contoso.com, prod.contoso.com en dr.consoto.com) zoals hieronder wordt weergegeven.

Create DNS zone records

Afbeelding: DNS-zonerecords maken in Azure

In dit scenario heeft www.contoso.com een TTL van 30 minuten, die ruim onder de vermelde RTO ligt en verwijst naar de productiesite prod.contoso.com. Deze configuratie is tijdens normale bedrijfsactiviteiten. De TTL van prod.contoso.com en dr.contoso.com is ingesteld op 300 seconden of 5 minuten. U kunt een Azure-bewakingsservice gebruiken, zoals Azure Monitor of Azure-app Insights, of alle partnerbewakingsoplossingen, zoals Dynatrace. U kunt zelfs zelf oplossingen gebruiken die fouten op toepassings- of virtuele infrastructuurniveau kunnen bewaken of detecteren.

Stap 3: de CNAME-record bijwerken

Zodra de fout is gedetecteerd, wijzigt u de recordwaarde zodat deze verwijst naar dr.contoso.com zoals hieronder wordt weergegeven:

Update CNAME record

Afbeelding: de CNAME-record bijwerken in Azure

Binnen 30 minuten, waarin de meeste resolvers het zonebestand in de cache vernieuwen, wordt elke query naar www.contoso.com omgeleid naar dr.contoso.com. U kunt ook de volgende Azure CLI-opdracht uitvoeren om de CNAME-waarde te wijzigen:

  az network dns record-set cname set-record \
  --resource-group 123 \
  --zone-name contoso.com \
  --record-set-name www \
  --cname dr.contoso.com

Deze stap kan handmatig of via automatisering worden uitgevoerd. U kunt dit handmatig doen via de console of via de Azure CLI. De Azure SDK en API kunnen worden gebruikt om de CNAME-update te automatiseren, zodat er geen handmatige interventie is vereist. Automatisering kan worden gebouwd via Azure-functies of binnen een bewakingstoepassing van derden of zelfs vanuit on-premises.

Hoe handmatige failover werkt met Behulp van Azure DNS

Omdat de DNS-server zich buiten de failover- of noodzone bevindt, is deze geïsoleerd tegen downtime. Hierdoor kan de gebruiker een eenvoudig failoverscenario ontwerpen dat rendabel is en altijd werkt, ervan uitgaande dat de operator netwerkconnectiviteit heeft tijdens een noodgeval en de overstap kan maken. Als de oplossing is gescript, moet men ervoor zorgen dat de server of service waarop het script wordt uitgevoerd, moet worden geïsoleerd tegen het probleem dat van invloed is op de productieomgeving. Houd ook rekening met de lage TTL die is ingesteld op de zone, zodat er geen resolver over de hele wereld het eindpunt lang in de cache opgeslagen houdt en klanten toegang hebben tot de site binnen de RTO. Voor een koude stand-by- en pilotlicht, omdat sommige voorwarming en andere administratieve activiteit nodig zijn , moet men ook voldoende tijd geven voordat de flip wordt gemaakt.

Automatische failover met behulp van Azure Traffic Manager

Wanneer u complexe architecturen en meerdere sets resources hebt die dezelfde functie kunnen uitvoeren, kunt u Azure Traffic Manager (op basis van DNS) configureren om de status van uw resources te controleren en het verkeer van de niet-gezonde resource naar de gezonde resource te routeren. In het volgende voorbeeld hebben zowel de primaire regio als de secundaire regio een volledige implementatie. Deze implementatie omvat de cloudservices en een gesynchroniseerde database.

Automatic failover using Azure Traffic Manager

Afbeelding: automatische failover met behulp van Azure Traffic Manager

Alleen de primaire regio verwerkt echter actief netwerkaanvragen van de gebruikers. De secundaire regio wordt alleen actief wanneer de primaire regio een serviceonderbreking ondervindt. In dat geval worden alle nieuwe netwerkaanvragen doorgestuurd naar de secundaire regio. Omdat de back-up van de database bijna onmiddellijk is, hebben beide load balancers IP-adressen die kunnen worden gecontroleerd en de exemplaren altijd actief zijn, biedt deze topologie een optie voor een lage RTO en failover zonder handmatige tussenkomst. De secundaire failoverregio moet direct na het mislukken van de primaire regio gereed zijn om live te gaan. Dit scenario is ideaal voor het gebruik van Azure Traffic Manager met ingebouwde tests voor verschillende typen statuscontroles, waaronder http/https en TCP. Azure Traffic Manager heeft ook een regelengine die kan worden geconfigureerd om een failover uit te voeren wanneer er een fout optreedt, zoals hieronder wordt beschreven. Laten we eens kijken naar de volgende oplossing met behulp van Traffic Manager:

  • Klant heeft het eindpunt Regio #1 dat bekend staat als prod.contoso.com met een statisch IP-adres als 100.168.124.44 en een regio #2-eindpunt dat bekend staat als dr.contoso.com met een statisch IP-adres als 100.168.124.43.
  • Elk van deze omgevingen wordt voorgestemd via een openbare eigenschap, zoals een load balancer. De load balancer kan worden geconfigureerd voor een DNS-eindpunt of een FQDN (Fully Qualified Domain Name), zoals hierboven wordt weergegeven.
  • Alle exemplaren in Regio 2 bevinden zich in bijna realtime replicatie met Regio 1. Bovendien zijn de installatiekopieën van de machine up-to-date en worden alle software-/configuratiegegevens gepatcht en zijn ze in overeenstemming met Regio 1.
  • Automatisch schalen wordt vooraf geconfigureerd.

De stappen voor het configureren van de failover met Azure Traffic Manager zijn als volgt:

  1. Een nieuw Azure Traffic Manager-profiel maken
  2. Eindpunten maken in het Traffic Manager-profiel
  3. Statuscontrole en failoverconfiguratie instellen

Stap 1: Een nieuw Azure Traffic Manager-profiel maken

Maak een nieuw Azure Traffic Manager-profiel met de naam contoso123 en selecteer de routeringsmethode als prioriteit. Als u een bestaande resourcegroep hebt waaraan u wilt koppelen, kunt u een bestaande resourcegroep selecteren, anders maakt u een nieuwe resourcegroep.

Create Traffic Manager profile

Afbeelding: een Traffic Manager-profiel maken

Stap 2: Eindpunten maken in het Traffic Manager-profiel

In deze stap maakt u eindpunten die verwijzen naar de productie- en herstelsites na noodgevallen. Kies hier het type als een extern eindpunt, maar als de resource wordt gehost in Azure, kunt u ook Azure-eindpunt kiezen. Als u Azure-eindpunt kiest, selecteert u een doelresource die een App Service of een openbaar IP-adres is dat door Azure wordt toegewezen. De prioriteit wordt ingesteld als 1 omdat het de primaire service voor Regio 1 is. Maak ook het eindpunt voor herstel na noodgevallen binnen Traffic Manager.

Create disaster recovery endpoints

Afbeelding- Eindpunten voor herstel na noodgevallen maken

Stap 3: Statuscontrole en failoverconfiguratie instellen

In deze stap stelt u de DNS TTL in op 10 seconden, wat wordt gehonoreerd door de meeste recursieve resolvers op internet. Deze configuratie betekent dat er gedurende meer dan 10 seconden geen DNS-resolver in de cache wordt opgeslagen. Voor de instellingen van de eindpuntmonitor is het pad ingesteld op/of de hoofdmap, maar u kunt de eindpuntinstellingen aanpassen om een pad te evalueren, bijvoorbeeld prod.contoso.com/index. In het onderstaande voorbeeld ziet u de https als het testprotocol. U kunt echter ook http of tcp kiezen. De keuze van het protocol is afhankelijk van de eindtoepassing. Het testinterval is ingesteld op 10 seconden, waardoor snel testen mogelijk is en het opnieuw proberen is ingesteld op 3. Als gevolg hiervan zal Traffic Manager een failover uitvoeren naar het tweede eindpunt als er drie opeenvolgende intervallen een fout registreren. De volgende formule definieert de totale tijd voor een geautomatiseerde failover: Tijd voor failover = TTL + Opnieuw proberen * Probing interval. In dit geval is de waarde 10 + 3 * 10 = 40 seconden (Max). Als de nieuwe poging is ingesteld op 1 en TTL is ingesteld op 10 seconden, dan de tijd voor failover 10 + 1 * 10 = 20 seconden. Stel de nieuwe poging in op een waarde die groter is dan 1 om de kans op failovers te elimineren vanwege fout-positieven of kleine netwerklips.

Set up health check

Afbeelding: statuscontrole en failoverconfiguratie instellen

Hoe automatische failover werkt met behulp van Traffic Manager

Tijdens een noodgeval wordt het primaire eindpunt uitgetest en wordt de status gewijzigd in gedegradeerd en blijft de site voor herstel na noodgevallen online. Standaard verzendt Traffic Manager al het verkeer naar het primaire eindpunt (met de hoogste prioriteit). Als het primaire eindpunt gedegradeerd wordt weergegeven, stuurt Traffic Manager het verkeer naar het tweede eindpunt zolang het in orde blijft. U kunt meer eindpunten configureren binnen Traffic Manager die kunnen fungeren als extra failover-eindpunten, of als load balancers de belasting delen tussen eindpunten.

Volgende stappen