Azure Traffic Manager met Azure Site Recovery

Met Azure Traffic Manager kunt u de distributie van verkeer over uw toepassingseindpunten beheren. Een eindpunt is een internetgerichte service die binnen of buiten Azure wordt gehost.

Traffic Manager gebruikt het Domain Name System (DNS) om clientaanvragen door te sturen naar het meest geschikte eindpunt, op basis van een verkeersrouteringsmethode en de status van de eindpunten. Traffic Manager biedt een scala aan routeringsmethoden voor verkeer en opties voor eindpuntcontrole om verschillende toepassingsbehoeften en modellen voor automatische failover mogelijk te kunnen maken. Clients maken rechtstreeks verbinding met het geselecteerde eindpunt. Traffic Manager is geen proxy of gateway en ziet het verkeer tussen de client en de service niet.

In dit artikel wordt beschreven hoe u de intelligente routering van Azure Traffic Monitor kunt combineren met de krachtige mogelijkheden voor herstel na noodgevallen en migratie van Azure Site Recovery.

Failover van on-premises naar Azure

Voor het eerste scenario kunt u rekening houden met Bedrijf A met alle toepassingsinfrastructuur die wordt uitgevoerd in de on-premises omgeving. Om redenen van bedrijfscontinuïteit en naleving besluit bedrijf A azure Site Recovery te gebruiken om de toepassingen te beveiligen.

Bedrijf A voert toepassingen uit met openbare eindpunten en wil de mogelijkheid om verkeer naadloos om te leiden naar Azure in een noodgeval. Met de prioriteitsmethode voor verkeersroutering in Azure Traffic Manager kan bedrijf A dit failoverpatroon eenvoudig implementeren.

De installatie is als volgt:

• Bedrijf A maakt een Traffic Manager-profiel.
• Met behulp van de routeringsmethode Prioriteit maakt bedrijf A twee eindpunten: primair voor on-premises en failover voor Azure. Aan primair wordt prioriteit 1 toegewezen en aan failover wordt prioriteit 2 toegewezen.
• Omdat het primaire eindpunt buiten Azure wordt gehost, wordt het eindpunt gemaakt als een extern eindpunt.
• Met Azure Site Recovery heeft de Azure-site geen virtuele machines of toepassingen die vóór de failover worden uitgevoerd. Het failover-eindpunt wordt dus ook gemaakt als een extern eindpunt.
• Standaard wordt gebruikersverkeer omgeleid naar de on-premises toepassing, omdat aan dat eindpunt de hoogste prioriteit is gekoppeld. Er wordt geen verkeer omgeleid naar Azure als het primaire eindpunt in orde is.

In een noodgeval kan bedrijf A een failover naar Azure activeren en de toepassingen in Azure herstellen. Wanneer Azure Traffic Manager detecteert dat het primaire eindpunt niet meer in orde is, wordt automatisch het failover-eindpunt gebruikt in het DNS-antwoord en maken gebruikers verbinding met de toepassing die is hersteld in Azure.

Afhankelijk van de bedrijfsvereisten kan bedrijf A een hogere of lagere testfrequentie kiezen om in een noodgeval tussen on-premises naar Azure te schakelen en minimale downtime voor gebruikers te garanderen.

Wanneer het noodgeval is ingeperkt, kan bedrijf A een failback uitvoeren van Azure naar de on-premises omgeving (VMware of Hyper-V) met behulp van Azure Site Recovery. Wanneer Traffic Manager nu detecteert dat het primaire eindpunt weer in orde is, wordt het primaire eindpunt automatisch gebruikt in de DNS-antwoorden.

On-premises migratie naar Azure

Naast herstel na noodgevallen maakt Azure Site Recovery ook migraties naar Azure mogelijk. Met behulp van de krachtige testfailovermogelijkheden van Azure Site Recovery kunnen klanten de prestaties van toepassingen in Azure beoordelen zonder dat dit van invloed is op hun on-premises omgeving. En wanneer klanten klaar zijn om te migreren, kunnen ze ervoor kiezen om hele workloads samen te migreren of ervoor te kiezen om geleidelijk te migreren en te schalen.

De gewogen routeringsmethode van Azure Traffic Manager kan worden gebruikt om een deel van het binnenkomende verkeer naar Azure te leiden, terwijl het merendeel naar de on-premises omgeving wordt doorgestuurd. Deze benadering kan helpen bij het beoordelen van schaalprestaties, omdat u het gewicht dat aan Azure is toegewezen, kunt blijven verhogen naarmate u meer en meer van uw workloads naar Azure migreert.

Bedrijf B kiest er bijvoorbeeld voor om gefaseerd te migreren, waarbij een deel van de toepassingsomgeving wordt verplaatst met behoud van de rest on-premises. Tijdens de eerste fasen waarin het grootste deel van de omgeving on-premises is, wordt een groter gewicht toegewezen aan de on-premises omgeving. Traffic Manager retourneert een eindpunt op basis van gewichten die zijn toegewezen aan beschikbare eindpunten.

Tijdens de migratie zijn beide eindpunten actief en wordt het grootste deel van het verkeer omgeleid naar de on-premises omgeving. Naarmate de migratie wordt voortgezet, kan een groter gewicht worden toegewezen aan het eindpunt in Azure en ten slotte kan het on-premises eindpunt na de migratie worden gedeactiveerd.

Failover van Azure naar Azure

In dit voorbeeld kunt u het volgende doen: bedrijf C met alle toepassingsinfrastructuur waarop Azure wordt uitgevoerd. Om bedrijfscontinuïteit en nalevingsredenen besluit bedrijf C Azure Site Recovery te gebruiken om de toepassingen te beveiligen.

Bedrijf C voert toepassingen uit met openbare eindpunten en wil de mogelijkheid om verkeer naadloos om te leiden naar een andere Azure-regio in een noodgeval. Met de routeringsmethode Prioriteit voor verkeer kan bedrijf C dit failoverpatroon eenvoudig implementeren.

De installatie is als volgt:

• Bedrijf C maakt een Traffic Manager-profiel.
• Met behulp van de routeringsmethode Prioriteit maakt bedrijf C twee eindpunten: Primair voor de bronregio (Azure - Oost-Azië) en Failover voor de herstelregio (Azure - zuidoost Azië). Aan primair wordt prioriteit 1 toegewezen en aan failover wordt prioriteit 2 toegewezen.
• Omdat het primaire eindpunt wordt gehost in Azure, kan het eindpunt een Azure-eindpunt zijn.
• Met Azure Site Recovery heeft de Azure-herstelsite geen virtuele machines of toepassingen die vóór de failover worden uitgevoerd. Het failover-eindpunt kan dus worden gemaakt als een extern eindpunt.
• Gebruikersverkeer wordt standaard omgeleid naar de bronregiotoepassing (Oost-Azië), omdat aan dat eindpunt de hoogste prioriteit is gekoppeld. Er wordt geen verkeer omgeleid naar de herstelregio als het primaire eindpunt in orde is.

In een noodgeval kan bedrijf C een failover activeren en de toepassingen herstellen in de Azure-regio voor herstel. Wanneer Azure Traffic Manager detecteert dat het primaire eindpunt niet meer in orde is, wordt automatisch het failover-eindpunt in het DNS-antwoord gebruikt en maken gebruikers verbinding met de toepassing die is hersteld in de Azure-herstelregio (Azië - zuidoost).

Afhankelijk van de bedrijfsvereisten kan bedrijf C een hogere of lagere testfrequentie kiezen om te schakelen tussen bron- en herstelregio's en minimale downtime voor gebruikers te garanderen.

Wanneer het noodgeval is ingesloten, kan bedrijf C failback uitvoeren van de Herstel-Azure-regio naar de azure-bronregio met behulp van Azure Site Recovery. Wanneer Traffic Manager nu detecteert dat het primaire eindpunt weer in orde is, wordt het primaire eindpunt automatisch gebruikt in de DNS-antwoorden.

Bedrijfstoepassingen voor meerdere regio's beveiligen

Wereldwijde ondernemingen verbeteren de klantervaring vaak door hun toepassingen aan te passen aan regionale behoeften. Lokalisatie en latentievermindering kunnen leiden tot een splitsing van de toepassingsinfrastructuur tussen regio's. Ondernemingen zijn op bepaalde gebieden ook gebonden aan regionale gegevenswetten en kiezen ervoor om een deel van hun toepassingsinfrastructuur binnen regionale grenzen te isoleren.

Laten we eens kijken naar een voorbeeld waarin bedrijf D de toepassingseindpunten heeft gesplitst om Duitsland en de rest van de wereld afzonderlijk te bedienen. Bedrijf D maakt gebruik van de geografische routeringsmethode van Azure Traffic Manager om dit in te stellen. Al het verkeer dat afkomstig is uit Duitsland, wordt omgeleid naar Eindpunt 1 en al het verkeer dat afkomstig is van buiten Duitsland wordt omgeleid naar Eindpunt 2.

Het probleem met deze installatie is dat als eindpunt 1 om welke reden dan ook niet meer werkt, er geen omleiding van verkeer naar eindpunt 2 is. Verkeer dat afkomstig is uit Duitsland, wordt nog steeds omgeleid naar eindpunt 1 , ongeacht de status van het eindpunt, waardoor Duitse gebruikers geen toegang hebben tot de toepassing van bedrijf D. Als eindpunt 2 offline gaat, is er ook geen omleiding van verkeer naar eindpunt 1.

Bedrijf D gebruikt geneste Traffic Manager-profielen met Azure Site Recovery om dit probleem te voorkomen en toepassingstolerantie te garanderen. Bij het instellen van een genest profiel wordt verkeer niet omgeleid naar afzonderlijke eindpunten, maar naar andere Traffic Manager-profielen. Deze installatie werkt als volgt:

• In plaats van geografische routering met afzonderlijke eindpunten te gebruiken, gebruikt bedrijf D geografische routering met Traffic Manager-profielen.
• Elk onderliggend Traffic Manager-profiel maakt gebruik van Prioriteitsroutering met een primair en een hersteleindpunt, waardoor prioriteitsroutering binnen geografische routering wordt genest.
• Om toepassingstolerantie mogelijk te maken, maakt elke workloaddistributie gebruik van Azure Site Recovery voor failover naar een herstelregio in het geval van een noodgeval.
• Wanneer de bovenliggende Traffic Manager een DNS-query ontvangt, wordt deze omgeleid naar de relevante onderliggende Traffic Manager die op de query reageert met een beschikbaar eindpunt.

Als het eindpunt in Duitsland - centraal bijvoorbeeld mislukt, kan de toepassing snel worden hersteld naar Duitsland - noordoost. Het nieuwe eindpunt verwerkt verkeer uit Duitsland met minimale downtime voor gebruikers. Op dezelfde manier kan een eindpuntstoring in Europa - west worden verwerkt door de toepassingsworkload te herstellen naar Europa - noord, waarbij Azure Traffic Manager DNS-omleidingen naar het beschikbare eindpunt verwerkt.

De bovenstaande installatie kan worden uitgebreid met zoveel regio- en eindpuntcombinaties die nodig zijn. Traffic Manager staat maximaal 10 niveaus van geneste profielen toe en staat geen lussen binnen de geneste configuratie toe.

Overwegingen voor beoogde hersteltijd (RTO)

In de meeste organisaties wordt het toevoegen of wijzigen van DNS-records verwerkt door een afzonderlijk team of door iemand buiten de organisatie. Dit maakt het wijzigen van DNS-records zeer lastig. De tijd die nodig is om DNS-records bij te werken door andere teams of organisaties die de DNS-infrastructuur beheren, verschilt per organisatie en is van invloed op de RTO van de toepassing.

Door traffic manager te gebruiken, kunt u het werk dat nodig is voor DNS-updates frontloaden. Er is geen handmatige of gescripte actie vereist op het moment van de werkelijke failover. Deze aanpak helpt bij het snel schakelen (en dus het verlagen van de RTO) en het voorkomen van kostbare tijdrovende DNS-wijzigingsfouten in een noodgeval. Met Traffic Manager wordt zelfs de failbackstap geautomatiseerd, die anders afzonderlijk zou moeten worden beheerd.

Het instellen van het juiste testinterval via basis- of snelle intervalstatuscontroles kan de RTO tijdens failover aanzienlijk verlagen en downtime voor gebruikers verminderen.

U kunt ook de TTL-waarde (Time to Live) van DNS voor het Traffic Manager-profiel optimaliseren. TTL is de waarde waarvoor een DNS-vermelding door een client in de cache wordt opgeslagen. Voor een record wordt DNS niet tweemaal binnen de TTL-periode opgevraagd. Aan elke DNS-record is een TTL gekoppeld. Het verminderen van deze waarde resulteert in meer DNS-query's voor Traffic Manager, maar kan RTO verminderen door sneller storingen te detecteren.

De TTL die door de client wordt ervaren, neemt ook niet toe als het aantal DNS-resolvers tussen de client en de gezaghebbende DNS-server toeneemt. DNS-resolvers tellen de TTL af en geven alleen een TTL-waarde door die de verstreken tijd weergeeft sinds de record in de cache is opgeslagen. Dit zorgt ervoor dat de DNS-record wordt vernieuwd op de client na de TTL, ongeacht het aantal DNS-resolvers in de keten.

Volgende stappen

• Meer informatie over routeringsmethoden van Traffic Manager.
• Meer informatie over geneste Traffic Manager-profielen.
• Meer informatie over eindpuntbewaking.
• Meer informatie over herstelplannen voor het automatiseren van toepassingsfailover.