Betrouwbaarheid in Azure DNS

Dit artikel bevat gedetailleerde informatie over herstel na noodgevallen in meerdere regio's en ondersteuning voor bedrijfscontinuïteit voor Azure DNS.

Herstel na noodgevallen en bedrijfscontinuïteit tussen regio's

Herstel na noodgevallen (DR) gaat over het herstellen van gebeurtenissen met een hoge impact, zoals natuurrampen of mislukte implementaties die downtime en gegevensverlies tot gevolg hebben. Ongeacht de oorzaak is de beste oplossing voor een noodgeval een goed gedefinieerd en getest DR-plan en een toepassingsontwerp dat actief dr ondersteunt. Zie Aanbevelingen voordat u nadenkt over het maken van uw plan voor herstel na noodgevallen.

Als het gaat om herstel na noodgevallen, gebruikt Microsoft het model voor gedeelde verantwoordelijkheid. In een model voor gedeelde verantwoordelijkheid zorgt Microsoft ervoor dat de basisinfrastructuur en platformservices beschikbaar zijn. Tegelijkertijd repliceren veel Azure-services niet automatisch gegevens of vallen ze terug van een mislukte regio om kruislings te repliceren naar een andere ingeschakelde regio. Voor deze services bent u verantwoordelijk voor het instellen van een plan voor herstel na noodgevallen dat geschikt is voor uw workload. De meeste services die worden uitgevoerd op PaaS-aanbiedingen (Platform as a Service) van Azure bieden functies en richtlijnen ter ondersteuning van herstel na noodgeval en u kunt servicespecifieke functies gebruiken om snel herstel te ondersteunen om uw DR-plan te ontwikkelen.

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

Omdat de DNS-server zich buiten de failover- of noodzone bevindt, is deze geïsoleerd tegen downtime. U kunt een eenvoudig failoverscenario ontwerpen zolang de operator netwerkconnectiviteit heeft tijdens een noodgeval en deze kan spiegelen. Als de oplossing is gescript, moet u ervoor zorgen dat de server of service waarop het script wordt uitgevoerd, ook geïsoleerd is tegen het probleem dat van invloed is op de productieomgeving. Bovendien voorkomt een lage TTL voor de zone caching van resolvers gedurende lange tijd, zodat de klant toegang heeft tot de site binnen de RTO. Voor een koude stand-by- en pilotlicht, omdat sommige voorwarming en andere administratieve activiteit mogelijk vereist zijn, moet u ook voldoende tijd geven voordat u de flip maakt.

Notitie

De privé-DNS-zone van Azure ondersteunt DNS-omzetting tussen virtuele netwerken in Azure-regio's, zelfs zonder expliciet peering van de virtuele netwerken. Alle virtuele netwerken moeten echter worden gekoppeld aan de privé-DNS-zone.

Voor meer informatie over het maken van een privé-DNS-zone in Azure Portal raadpleegt u de quickstart: Een privé-DNS-zone van Azure maken met behulp van Azure Portal.

Als u een privé-resolver van Azure DNS wilt maken met behulp van Azure Portal, raadpleegt u de quickstart: Een privé-resolver voor Azure DNS maken met behulp van Azure Portal.

Herstel na noodgevallen in geografie in meerdere regio's

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-byomgevingen. Dit type noodherstel kan systeemeigen worden uitgevoerd viaAzure Site Recovery. Raadpleeg de Documentatie voor Azure Site Recovery via Microsoft Azure-partnerapparaten/-services zoals Veritas of NetApp.

• Het ontwikkelen van een oplossing voor het omleiden van netwerk-/webverkeer van de primaire site naar de stand-bysite. Dit type herstel na noodgevallen kan worden bereikt via Azure DNS, Azure Traffic Manager (DNS) of globale load balancers van derden.

Dit artikel is specifiek gericht op azure DNS-planning voor herstel na noodgevallen.

Herstel na noodgevallen en detectie van storingen instellen

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

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 in de organisatie is ingesteld. Als een onderneming bijvoorbeeld de RTO van de reactie op een noodgeval van de toepassing 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

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

   

   Afbeelding: een DNS-zone maken in Azure

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

   

   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 zoals Azure Monitor of Azure-app Insights gebruiken, of alle partnerbewakingsoplossingen zoals Dynatrace. U kunt zelfs zelf oplossingen gebruiken die fouten op toepassings- of virtuele infrastructuurniveau kunnen bewaken of detecteren.

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

   

   Afbeelding: de CNAME-record bijwerken in Azure

   Binnen 30 minuten, waarbij 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 tussenkomst nodig is. Automatisering kan worden gebouwd via Azure-functies of binnen een bewakingstoepassing van derden of zelfs vanuit on-premises.

Volgende stappen

• Betrouwbaarheid in Azure
• Meer informatie over Azure Traffic Manager.
• Meer informatie over Azure DNS.