Azure Traffic Manager med Azure Site Recovery

Med Azure Traffic Manager kan du styra distributionen av trafik över programslutpunkterna. En slutpunkt är en Internetansluten tjänst i eller utanför Azure.

Traffic Manager använder DNS (Domain Name System) för att dirigera klientbegäranden till den lämpligaste slutpunkten, baserat på en trafikroutningsmetod och slutpunkternas hälsotillstånd. 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. Klienterna ansluter direkt till den valda slutpunkten. Traffic Manager är inte en proxy eller gateway och ser inte trafiken som skickas mellan klienten och tjänsten.

Den här artikeln beskriver hur du kan kombinera Azure Traffic Monitors intelligenta routning med Azure Site Recoverys kraftfulla funktioner för haveriberedskap och migrering.

Redundansväxling lokalt till Azure

För det första scenariot bör du överväga företag A som har all sin programinfrastruktur som körs i den lokala miljön. Av affärskontinuitets- och efterlevnadsskäl bestämmer sig företag A för att använda Azure Site Recovery för att skydda sina program.

Företag A kör program med offentliga slutpunkter och vill kunna omdirigera trafik sömlöst till Azure i en katastrofhändelse. Med trafikdirigeringsmetoden Prioritet i Azure Traffic Manager kan företag A enkelt implementera det här redundansmönstret.

Konfigurationen är följande:

• Företag A skapar en Traffic Manager-profil.
• Med hjälp av metoden Prioritetsroutning skapar företag A två slutpunkter – Primär för lokal och redundans för Azure. Primärt tilldelas prioritet 1 och redundans tilldelas prioritet 2.
• Eftersom den primära slutpunkten finns utanför Azure skapas slutpunkten som en extern slutpunkt.
• Med Azure Site Recovery har Azure-webbplatsen inga virtuella datorer eller program som körs före redundansväxlingen. Därför skapas redundansslutpunkten också som en extern slutpunkt.
• Som standard dirigeras användartrafik till det lokala programmet eftersom slutpunkten har den högsta prioritet som är associerad med den. Ingen trafik dirigeras till Azure om den primära slutpunkten är felfri.

I en katastrofhändelse kan företag A utlösa en redundansväxling till Azure och återställa sina program i Azure. När Azure Traffic Manager upptäcker att den primära slutpunkten inte längre är felfri använder den automatiskt redundansslutpunkten i DNS-svaret och användarna ansluter till programmet som återställs i Azure.

Beroende på affärskrav kan företag A välja en högre eller lägre avsökningsfrekvens för att växla mellan lokalt till Azure i en katastrofhändelse och säkerställa minimal stilleståndstid för användare.

När katastrofen är innesluten kan företag A återställas från Azure till den lokala miljön (VMware eller Hyper-V) med hjälp av Azure Site Recovery. Nu, när Traffic Manager upptäcker att den primära slutpunkten är felfri igen, använder den automatiskt den primära slutpunkten i sina DNS-svar.

Lokal migrering till Azure

Utöver haveriberedskap möjliggör Azure Site Recovery även migreringar till Azure. Med hjälp av Azure Site Recoverys kraftfulla redundansfunktioner kan kunderna utvärdera programprestanda i Azure utan att påverka den lokala miljön. Och när kunderna är redo att migrera kan de välja att migrera hela arbetsbelastningar tillsammans eller välja att migrera och skala gradvis.

Azure Traffic Manager-metoden Viktad routning kan användas för att dirigera en del av inkommande trafik till Azure samtidigt som majoriteten dirigeras till den lokala miljön. Den här metoden kan hjälpa dig att utvärdera skalningsprestanda eftersom du kan fortsätta att öka den vikt som tilldelats Azure när du migrerar fler och fler av dina arbetsbelastningar till Azure.

Företag B väljer till exempel att migrera i faser, flytta en del av sin programmiljö samtidigt som resten bevaras lokalt. Under de inledande stegen när större delen av miljön är lokal tilldelas en större vikt till den lokala miljön. Traffic Manager returnerar en slutpunkt baserat på vikter som tilldelats till tillgängliga slutpunkter.

Under migreringen är båda slutpunkterna aktiva och merparten av trafiken dirigeras till den lokala miljön. När migreringen fortsätter kan en större vikt tilldelas till slutpunkten i Azure och slutligen kan den lokala slutpunkten inaktiveras efter migreringen.

Redundansväxling mellan Azure och Azure

I det här exemplet bör du överväga företag C som har all sin programinfrastruktur som kör Azure. Av affärskontinuitets- och efterlevnadsskäl bestämmer sig företag C för att använda Azure Site Recovery för att skydda sina program.

Företag C kör program med offentliga slutpunkter och vill kunna omdirigera trafik sömlöst till en annan Azure-region i en katastrofhändelse. Med trafikroutningsmetoden Prioritet kan företag C enkelt implementera det här redundansmönstret.

Konfigurationen är följande:

• Företag C skapar en Traffic Manager-profil.
• Med hjälp av metoden Prioritetsroutning skapar företag C två slutpunkter – Primär för källregionen (Azure East Asia) och redundans för återställningsregionen (Azure Sydostasien). Primärt tilldelas prioritet 1 och redundans tilldelas prioritet 2.
• Eftersom den primära slutpunkten finns i Azure kan slutpunkten vara som en Azure-slutpunkt .
• Med Azure Site Recovery har inte Återställningsplatsen några virtuella datorer eller program som körs före redundansväxlingen. Därför kan redundansslutpunkten skapas som en extern slutpunkt.
• Som standard dirigeras användartrafik till källregionen (Asien, östra) eftersom slutpunkten har den högsta prioritet som är associerad med den. Ingen trafik dirigeras till återställningsregionen om den primära slutpunkten är felfri.

I en katastrofhändelse kan företag C utlösa en redundansväxling och återställa sina program i Azure-återställningsregionen. När Azure Traffic Manager upptäcker att den primära slutpunkten inte längre är felfri använder den automatiskt redundansslutpunkten i DNS-svaret och användarna ansluter till programmet som återställs i återställningsregionen i Azure (Sydostasien).

Beroende på affärskrav kan företag C välja en högre eller lägre avsökningsfrekvens för att växla mellan käll- och återställningsregioner och säkerställa minimal stilleståndstid för användare.

När katastrofen är innesluten kan företag C återställa från återställningen av Azure-regionen till azure-källregionen med hjälp av Azure Site Recovery. Nu, när Traffic Manager upptäcker att den primära slutpunkten är felfri igen, använder den automatiskt den primära slutpunkten i sina DNS-svar.

Skydda företagsprogram i flera regioner

Globala företag förbättrar ofta kundupplevelsen genom att skräddarsy sina program för att tillgodose regionala behov. Lokalisering och svarstidsminskning kan leda till att programinfrastrukturen delas upp mellan regioner. Företag är också bundna av regionala datalagar inom vissa områden och väljer att isolera en del av sin programinfrastruktur inom regionala gränser.

Låt oss ta ett exempel där Företag D har delat upp sina programslutpunkter för att separat betjäna Tyskland och resten av världen. Företag D använder Azure Traffic Managers geografiska routningsmetod för att konfigurera detta. All trafik som kommer från Tyskland dirigeras till slutpunkt 1 och all trafik som kommer från utanför Tyskland dirigeras till Slutpunkt 2.

Problemet med den här konfigurationen är att om Slutpunkt 1 slutar fungera av någon anledning finns det ingen omdirigering av trafik till Slutpunkt 2. Trafik från Tyskland fortsätter att dirigeras till slutpunkt 1 oavsett slutpunktens hälsotillstånd, vilket ger tyska användare utan åtkomst till företag D:s program. På samma sätt finns det ingen omdirigering av trafik till slutpunkt 1 om Slutpunkt 2 kopplas från.

För att undvika att stöta på det här problemet och säkerställa programåterhämtning använder Företag D kapslade Traffic Manager-profiler med Azure Site Recovery. I en kapslad profilkonfiguration dirigeras inte trafik till enskilda slutpunkter, utan i stället till andra Traffic Manager-profiler. Så här fungerar den här konfigurationen:

• I stället för att använda geografisk routning med enskilda slutpunkter använder företag D geografisk routning med Traffic Manager-profiler.
• Varje underordnad Traffic Manager-profil använder Prioritetsroutning med en primär och en återställningsslutpunkt, vilket kapslar prioritetsroutning i geografisk routning.
• För att aktivera programåterhämtning använder varje arbetsbelastningsdistribution Azure Site Recovery för redundansväxling till en återställningsregion baserat i händelse av en katastrofhändelse.
• När den överordnade Traffic Manager tar emot en DNS-fråga dirigeras den till relevant underordnad Traffic Manager som svarar på frågan med en tillgänglig slutpunkt.

Om slutpunkten i Germany Central till exempel misslyckas kan programmet snabbt återställas till Tyskland nordost. Den nya slutpunkten hanterar trafik från Tyskland med minimal stilleståndstid för användare. På samma sätt kan ett slutpunktsfel i Europa, västra hanteras genom att återställa programarbetsbelastningen till Europa, norra, med Azure Traffic Manager som hanterar DNS-omdirigeringar till den tillgängliga slutpunkten.

Konfigurationen ovan kan utökas så att den innehåller så många kombinationer av regioner och slutpunkter som krävs. Traffic Manager tillåter upp till 10 nivåer av kapslade profiler och tillåter inte loopar i den kapslade konfigurationen.

Överväganden för mål för återställningstid (RTO)

I de flesta organisationer hanteras tillägg eller ändring av DNS-poster antingen av ett separat team eller av någon utanför organisationen. Detta gör uppgiften att ändra DNS-poster mycket utmanande. Den tid det tar att uppdatera DNS-poster av andra team eller organisationer som hanterar DNS-infrastruktur varierar från organisation till organisation och påverkar programmets RTO.

Genom att använda Traffic Manager kan du läsa in det arbete som krävs för DNS-uppdateringar. Ingen manuell eller skriptad åtgärd krävs vid tidpunkten för den faktiska redundansväxlingen. Med den här metoden kan du snabbt växla (och därmed sänka RTO) och undvika kostsamma tidskrävande DNS-ändringsfel i en katastrofhändelse. Med Traffic Manager automatiseras även återställningssteget, som annars måste hanteras separat.

Om du ställer in rätt avsökningsintervall genom grundläggande eller snabba hälsokontroller kan det avsevärt minska RTO under redundansväxlingen och minska stilleståndstiden för användarna.

Du kan dessutom optimera TTL-värdet (DNS Time to Live) för Traffic Manager-profilen. TTL är det värde för vilket en DNS-post cachelagras av en klient. För en post skulle DNS inte frågas två gånger inom intervallet för TTL. Varje DNS-post har en TTL associerad med den. Att minska det här värdet resulterar i fler DNS-frågor till Traffic Manager, men kan minska RTO genom att upptäcka avbrott snabbare.

Den TTL som klienten upplever ökar inte heller om antalet DNS-matchare mellan klienten och den auktoritativa DNS-servern ökar. DNS-matchare "räknar ned" TTL och skickar endast ett TTL-värde som återspeglar den förflutna tiden sedan posten cachelagrades. Detta säkerställer att DNS-posten uppdateras på klienten efter TTL,oavsett antalet DNS-matchare i kedjan.

Nästa steg

• Läs mer om Traffic Manager-routningsmetoder.
• Läs mer om kapslade Traffic Manager-profiler.
• Läs mer om slutpunktsövervakning.
• Läs mer om återställningsplaner för att automatisera programredundans.