Tillförlitlighet i Azure Traffic Manager

Den här artikeln innehåller stöd för haveriberedskap mellan regioner och stöd för affärskontinuitet för Azure Traffic Manager.

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 Traffic Manager är en DNS-baserad lastbalanserare för trafik som gör att du kan distribuera trafik till dina offentliga program i globala Azure-regioner. Traffic Manager ger även dina offentliga slutpunkter hög tillgänglighet och snabb svarstid.

Traffic Manager använder DNS för att dirigera klientbegäranden till lämplig tjänstslutpunkt baserat på en trafikroutningsmetod. Traffic Manager tillhandahåller även hälsoövervakning för varje slutpunkt. Slutpunkten kan vara valfri Internetuppkopplad tjänst som finns i eller utanför Azure. Traffic Manager tillhandahåller en uppsättning trafikdirigeringsmetoder och alternativ för slutpunktsövervakning som passar olika programbehov och modeller för automatisk redundansväxling. Traffic Manager har bra återhämtningsförmåga i händelse av fel, inklusive fel som påverkar en hel Azure-region.

Haveriberedskap i geografi för flera regioner

DNS är en av de mest effektiva mekanismerna för att omdirigera nätverkstrafik. DNS är effektivt eftersom DNS ofta är globalt och externt till datacentret. DNS är också isolerat från eventuella fel på regional nivå eller tillgänglighetsnivå (AZ).

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 Traffic Manager.

Identifiering, avisering och hantering av avbrott

Under en katastrof avsöks den primära slutpunkten och statusen ändras till degraderad och haveriberedskapsplatsen förblir Online. Som standard skickar Traffic Manager all trafik till den primära slutpunkten (högsta prioritet). Om den primära slutpunkten verkar degraderad dirigerar Traffic Manager trafiken till den andra slutpunkten så länge den förblir felfri. Man kan konfigurera fler slutpunkter i Traffic Manager som kan fungera som extra redundansslutpunkter, eller som lastbalanserare som delar belastningen mellan slutpunkter.

Konfigurera haveriberedskap och avbrottsidentifiering

När du har komplexa arkitekturer och flera uppsättningar resurser som kan utföra samma funktion kan du konfigurera Azure Traffic Manager (baserat på DNS) för att kontrollera hälsotillståndet för dina resurser och dirigera trafiken från den icke-felfria resursen till den felfria resursen.

I följande exempel har både den primära regionen och den sekundära regionen en fullständig distribution. Den här distributionen omfattar molntjänsterna och en synkroniserad databas.

Bild – Automatisk redundans med Azure Traffic Manager

Det är dock bara den primära regionen som aktivt hanterar nätverksbegäranden från användarna. Den sekundära regionen blir endast aktiv när den primära regionen upplever ett avbrott i tjänsten. I så fall dirigeras alla nya nätverksbegäranden till den sekundära regionen. Eftersom säkerhetskopieringen av databasen är nästan omedelbar, både lastbalanserarna har IP-adresser som kan hälsokontrolleras och instanserna alltid är igång, ger den här topologin ett alternativ för att gå in för en låg RTO och redundans utan manuella åtgärder. Den sekundära redundansregionen måste vara redo att aktiveras direkt efter fel i den primära regionen.

Det här scenariot är perfekt för användning av Azure Traffic Manager som har inbyggda avsökningar för olika typer av hälsokontroller, inklusive http/https och TCP. Azure Traffic Manager har också en regelmotor som kan konfigureras för redundansväxling när ett fel inträffar enligt beskrivningen nedan. Nu ska vi överväga följande lösning med Hjälp av Traffic Manager:

• Kunden har den region nr 1-slutpunkt som kallas prod.contoso.com med en statisk IP-adress som 100.168.124.44 och en region #2-slutpunkt som kallas dr.contoso.com med en statisk IP-adress som 100.168.124.43.
• Var och en av dessa miljöer frontas via en offentlig egenskap som en lastbalanserare. Lastbalanseraren kan konfigureras för att ha en DNS-baserad slutpunkt eller ett fullständigt domännamn (FQDN) enligt ovan.
• Alla instanser i region 2 är i nära realtidsreplikering med region 1. Dessutom är datorbilderna uppdaterade och alla programvaru-/konfigurationsdata korrigeras och är i linje med Region 1.
• Automatisk skalning förkonfigureras i förväg.

Så här konfigurerar du redundansväxlingen med Azure Traffic Manager:

1. Skapa en ny Azure Traffic Manager-profil Skapa en ny Azure Traffic Manager-profil med namnet contoso123 och välj routningsmetoden som Prioritet. Om du har en befintlig resursgrupp som du vill associera med kan du välja en befintlig resursgrupp, annars kan du skapa en ny resursgrupp.

   

   Bild – Skapa en Traffic Manager-profil

2. Skapa slutpunkter i Traffic Manager-profilen

   I det här steget skapar du slutpunkter som pekar på produktions- och haveriberedskapsplatserna. Här väljer du Typ som en extern slutpunkt, men om resursen finns i Azure kan du också välja Azure-slutpunkt . Om du väljer Azure-slutpunkt väljer du en målresurs som antingen är en App Service eller en offentlig IP-adress som allokeras av Azure. Prioriteten anges som 1 eftersom det är den primära tjänsten för region 1. På samma sätt skapar du även slutpunkten för haveriberedskap i Traffic Manager.

   

   Bild – Skapa slutpunkter för haveriberedskap

3. Konfigurera konfiguration av hälsokontroll och redundans

   I det här steget anger du DNS TTL till 10 sekunder, vilket respekteras av de flesta internetuppkopplade rekursiva matchare. Den här konfigurationen innebär att ingen DNS-matchare cachelagras i mer än 10 sekunder.

   För inställningarna för slutpunktsövervakaren är sökvägen aktuell inställd på/eller rot, men du kan anpassa slutpunktsinställningarna för att utvärdera en sökväg, till exempel prod.contoso.com/index.

   Exemplet nedan visar https som avsökningsprotokoll. Du kan dock även välja http eller tcp . Valet av protokoll beror på slutprogrammet. Avsökningsintervallet är inställt på 10 sekunder, vilket möjliggör snabb avsökning och återförsöket är inställt på 3. Därför redundansväxlar Traffic Manager till den andra slutpunkten om tre intervall i följd registrerar ett fel.

   Följande formel definierar den totala tiden för en automatiserad redundansväxling:

   Time for failover = TTL + Retry * Probing interval

   Och i det här fallet är värdet 10 + 3 * 10 = 40 sekunder (max).

   Om återförsöket är inställt på 1 och TTL är inställt på 10 sekunder, är tiden för redundansväxling 10 + 1 * 10 = 20 sekunder.

   Ange återförsöket till ett värde som är större än 1 för att eliminera risken för redundans på grund av falska positiva identifieringar eller några mindre nätverksblips.

   

   Bild – Konfigurera konfiguration av hälsokontroll och redundans

Nästa steg

• Tillförlitlighet i Azure

• Läs mer om Azure Traffic Manager.

• Läs mer om Azure DNS.