Dela via

Tillförlitlighet i Azure DNS

  • Artikel

Den här artikeln innehåller detaljerad information om haveriberedskap mellan regioner och stöd för affärskontinuitet för Azure DNS.

Haveriberedskap och affärskontinuitet mellan regioner

Haveriberedskap handlar om att återställa från händelser med hög påverkan, till exempel naturkatastrofer eller misslyckade distributioner som resulterar i driftstopp och dataförlust. Oavsett orsak är den bästa lösningen för en katastrof en väldefinierad och testad DR-plan och en programdesign som aktivt stöder DR. Innan du börjar fundera på att skapa en haveriberedskapsplan kan du läsa Rekommendationer för att utforma en strategi för haveriberedskap.

När det gäller dr använder Microsoft modellen för delat ansvar. I en modell med delat ansvar ser Microsoft till att baslinjeinfrastrukturen och plattformstjänsterna är tillgängliga. Samtidigt replikerar många Azure-tjänster inte automatiskt data eller återgår från en misslyckad region för att korsreparera till en annan aktiverad region. För dessa tjänster ansvarar du för att konfigurera en haveriberedskapsplan som fungerar för din arbetsbelastning. De flesta tjänster som körs på PaaS-erbjudanden (Plattform som en tjänst) i Azure ger funktioner och vägledning för att stödja DR och du kan använda tjänstspecifika funktioner för att stödja snabb återställning för att utveckla din DR-plan.

Azure DNS-redundanslösningen för haveriberedskap använder standard-DNS-mekanismen för att redundansväxla till säkerhetskopieringsplatsen. Det manuella alternativet via Azure DNS fungerar bäst när det används tillsammans med kall vänteläge eller pilotljusmetoden.

Eftersom DNS-servern ligger utanför redundans- eller haverizonen isoleras den mot eventuella driftstopp. Du kan skapa ett enkelt redundansscenario så länge operatören har nätverksanslutning vid haveri och kan vända. Om lösningen är skriptad måste du se till att servern eller tjänsten som kör skriptet också är isolerad mot problemet som påverkar produktionsmiljön. Dessutom förhindrar en låg TTL för zonen cachelagring av lösare under långa tidsperioder, vilket gör det möjligt för kunden att komma åt webbplatsen inom RTO. För ett kallt vänteläge och pilotljus, eftersom viss förvärmande och annan administrativ aktivitet kan krävas, bör du också ge tillräckligt med tid innan du gör flip.

Kommentar

Azures privata DNS-zon stöder DNS-matchning mellan virtuella nätverk i Azure-regioner, även utan att uttryckligen peerkoppla de virtuella nätverken. Alla virtuella nätverk måste dock vara länkade till den privata DNS-zonen.

Mer information om hur du skapar en privat DNS-zon i Azure-portalen finns i Snabbstart: Skapa en privat DNS-zon i Azure med Hjälp av Azure-portalen.

Information om hur du skapar en privat Lösning för Azure DNS med Hjälp av Azure-portalen finns i Snabbstart: Skapa en privat Lösning för Azure DNS med hjälp av Azure-portalen.

Haveriberedskap i geografi för flera regioner

Det finns två tekniska aspekter för att konfigurera arkitekturen för haveriberedskap:

  • Använda en distributionsmekanism för att replikera instanser, data och konfigurationer mellan primära miljöer och väntelägesmiljöer. Den här typen av haveriberedskap kan utföras internt viaAzure Site Recovery, se Dokumentation om Azure Site Recovery via Microsoft Azure-partnerenheter/-tjänster som Veritas eller NetApp.

  • Utveckla en lösning för att omdirigera nätverks-/webbtrafik från den primära platsen till väntelägesplatsen. Den här typen av haveriberedskap kan uppnås via Azure DNS, Azure Traffic Manager (DNS) eller globala lastbalanserare från tredje part.

Den här artikeln fokuserar specifikt på planering av haveriberedskap i Azure DNS.

Konfigurera haveriberedskap och avbrottsidentifiering

Den manuella redundanslösningen i Azure DNS för haveriberedskap använder standard-DNS-mekanismen för redundansväxling till säkerhetskopieringsplatsen. Det manuella alternativet via Azure DNS fungerar bäst när det används tillsammans med kall vänteläge eller pilotljusmetoden.

Diagram of manual failover using Azure DNS.

Bild – Manuell redundansväxling med Hjälp av Azure DNS

Antagandena för lösningen är:

  • Både primära och sekundära slutpunkter har statiska IP-adresser som inte ändras ofta. Anta att IP-adressen för den primära platsen är 100.168.124.44 och IP-adressen för den sekundära platsen är 100.168.124.43.
  • Det finns en Azure DNS-zon för både den primära och den sekundära platsen. Anta att slutpunkten är prod.contoso.com för den primära platsen och att säkerhetskopieringsplatsen är dr.contoso.com. Det finns också en DNS-post för huvudprogrammet som kallas www.contoso.com.
  • TTL:t ligger på eller under rto-serviceavtalet som angetts i organisationen. Om ett företag till exempel anger RTO för programmets haveriberedskap till 60 minuter, bör TTL-värdet vara mindre än 60 minuter, helst ju lägre desto bättre. Du kan konfigurera Azure DNS för manuell redundans på följande sätt:
    • Skapa en DNS-zon
    • Skapa DNS-zonposter
    • Uppdatera CNAME-post

  1. Skapa en DNS-zon (till exempel www.contoso.com) enligt nedan:

    Screenshot of creating a DNS zone in Azure.

    Bild – Skapa en DNS-zon i Azure

  2. I den här zonen skapar du tre poster (till exempel www.contoso.com, prod.contoso.com och dr.consoto.com) som du ser nedan.

    Screenshot of creating DNS zone records.

    Bild – Skapa DNS-zonposter i Azure

    I det här scenariot har www.contoso.com en TTL på 30 minuter, vilket är långt under den angivna RTO:n och pekar på produktionsplatsen prod.contoso.com. Den här konfigurationen sker under normal verksamhet. TTL för prod.contoso.com och dr.contoso.com har angetts till 300 sekunder eller 5 minuter. Du kan använda en Azure-övervakningstjänst som Azure Monitor eller Azure App Insights, eller partnerövervakningslösningar som Dynatrace. Du kan till och med använda hemodlade lösningar som kan övervaka eller identifiera fel på program- eller virtuell infrastrukturnivå.

  3. När felet har identifierats ändrar du postvärdet så att det pekar på dr.contoso.com enligt nedan:

    Screenshot of updating CNAME record.

    Bild – Uppdatera CNAME-posten i Azure

    Inom 30 minuter, då de flesta matchare uppdaterar den cachelagrade zonfilen, omdirigeras alla frågor till www.contoso.com till dr.contoso.com. Du kan också köra följande Azure CLI-kommando för att ändra CNAME-värdet:

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

    Det här steget kan köras manuellt eller via automatisering. Det kan göras manuellt via -konsolen eller av Azure CLI. Azure SDK och API kan användas för att automatisera CNAME-uppdateringen så att inga manuella åtgärder krävs. Automatisering kan skapas via Azure-funktioner eller i ett övervakningsprogram från tredje part eller till och med lokalt.

Nästa steg