Azure Traffic Manager med Azure Site Recovery

Med Azure Traffic Manager kan du styra distributionen av trafik mellan 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 passerar mellan klienten och tjänsten.

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

Redundansväxling lokalt till Azure

I 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 trafikroutningsmetoden 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 routningsmetoden Prioritet skapar företag A två slutpunkter – Primär för lokal och redundans för Azure. Primär 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älla från Azure till sin lokala miljö (VMware eller Hyper-V) med hjälp av Azure Site Recovery. När Traffic Manager nu 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

Förutom haveriberedskap möjliggör Azure Site Recovery även migreringar till Azure. Med hjälp av Azure Site Recovery kraftfulla redundanstestfunktioner 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 Till 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 första 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. Allt eftersom 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 routningsmetoden Prioritet skapar företag C två slutpunkter – Primär för källregionen (Azure, östra Asien) och redundans för återställningsregionen (Azure Sydostasien). Primär 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 återställningsplatsen inga 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ällts i azure-återställningsregionen (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ändarna.

När katastrofen är innesluten kan företag C återställa från återställningsregionen i Azure till azure-källregionen med hjälp av Azure Site Recovery. När Traffic Manager nu 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 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 gör att tyska användare inte har åtkomst till företag D:s program. På samma sätt sker 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 Dkapslade Traffic Manager-profiler med Azure Site Recovery. I en kapslad profilkonfiguration dirigeras inte trafiken till enskilda slutpunkter, utan 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 slutpunkt och en återställningsslutpunkt, vilket innebär att prioritetsroutning kapslas 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 vid 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, nordöstra tyskland. 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 programarbetsbelastningen återställs till Europa, norra, med Azure Traffic Manager som hanterar DNS-omdirigeringar till den tillgängliga slutpunkten.

Ovanstående konfiguration 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-infrastrukturen 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 i förväg. 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 för intervall kan rto avsevärt minskas 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 associerad TTL. 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.

TTL-värdet som klienten upplever ökar inte heller om antalet DNS-matchare mellan klienten och den auktoritativa DNS-servern ökar. DNS-matcharna "räknar ned" TTL-värdet och skickar bara 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-värdet, 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.