Azure Traffic Manager met Azure Site Recovery

Met Azure Traffic Manager kunt u de distributie van verkeer tussen 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 naar het meest geschikte eindpunt te leiden, 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 niet tussen de client en de service.

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.

On-premises naar Azure-failover

Overweeg voor het eerste scenario bedrijf A met alle toepassingsinfrastructuur die wordt uitgevoerd in de on-premises omgeving. Om bedrijfscontinuïteit en nalevingsredenen besluit bedrijf A Azure Site Recovery te gebruiken om de toepassingen te beveiligen.

Bedrijf A voert toepassingen uit met openbare eindpunten en wil het verkeer naadloos omleiden naar Azure in een noodgeval. Met de methode Prioriteit 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.
• Door gebruik te maken van de prioriteitsrouteringsmethode, maakt bedrijf A twee eindpunten: primair voor on-premises en failover voor Azure. Prioriteit 1 wordt toegewezen aan primaire prioriteit 1 en 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 beschikt de Azure-site niet over virtuele machines of toepassingen die vóór de failover worden uitgevoerd. Het failover-eindpunt wordt dus ook gemaakt als een extern eindpunt.
• Gebruikersverkeer wordt standaard 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 ervan herstellen in Azure. 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 Azure.

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

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

On-premises naar Azure-migratie

Naast herstel na noodgevallen maakt Azure Site Recovery ook migraties naar Azure mogelijk. Met behulp van de krachtige mogelijkheden voor testfailover 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 geleidelijk te migreren en te schalen.

De gewogen routeringsmethode van Azure Traffic Manager kan worden gebruikt om een deel van inkomend verkeer naar Azure te leiden terwijl het merendeel naar de on-premises omgeving wordt doorgestuurd. Deze aanpak 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 in fasen te migreren, waarbij een deel van de toepassingsomgeving wordt verplaatst terwijl de rest on-premises blijft. Tijdens de eerste fasen wanneer de meeste 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 kan het on-premises eindpunt na de migratie worden gedeactiveerd.

Failover van Azure naar Azure

Voor dit voorbeeld moet u bedrijf C overwegen 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 dat verkeer naadloos kan worden omgeleid naar een andere Azure-regio in een noodgeval. Met de methode Prioriteit voor verkeersroutering kan Bedrijf C dit failoverpatroon eenvoudig implementeren.

De installatie is als volgt:

• Bedrijf C maakt een Traffic Manager-profiel.
• Door gebruik te maken van de prioriteitsrouteringsmethode, maakt bedrijf C twee eindpunten: primair voor de bronregio (Azure Oost-Azië) en failover voor de herstelregio (Azure Zuidoost-Azië). Prioriteit 1 wordt toegewezen aan primaire prioriteit 1 en failover wordt Prioriteit 2 toegewezen.
• Omdat het primaire eindpunt wordt gehost in Azure, kan het eindpunt zich als een Azure-eindpunt bevinden.
• Met Azure Site Recovery beschikt de Azure-herstelsite niet over virtuele machines of toepassingen die vóór de failover worden uitgevoerd. Het failover-eindpunt kan dus worden gemaakt als een extern eindpunt.
• Standaard wordt gebruikersverkeer 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 bijbehorende toepassingen herstellen in de Azure-herstelregio. 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 Herstel-Azure-regio (Azië - zuidoost).

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

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

Bedrijfstoepassingen in meerdere regio's beveiligen

Wereldwijde ondernemingen verbeteren vaak de klantervaring door hun toepassingen aan te passen aan regionale behoeften. Lokalisatie en latentievermindering kan leiden tot een gesplitste toepassingsinfrastructuur tussen regio's. Ondernemingen zijn ook gebonden aan regionale gegevenswetten op bepaalde gebieden 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. Verkeer dat afkomstig is van Duitsland, wordt omgeleid naar Eindpunt 1 en 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 van Duitsland wordt nog steeds omgeleid naar Eindpunt 1 , ongeacht de status van het eindpunt, waardoor Duitse gebruikers zonder toegang tot de toepassing van bedrijf D worden verlaten. Als Eindpunt 2 offline gaat, is er ook geen omleiding van verkeer naar Eindpunt 1.

Om te voorkomen dat dit probleem optreedt en de tolerantie van toepassingen garandeert, gebruikt bedrijf D geneste Traffic Manager-profielen met Azure Site Recovery. In een geneste profielconfiguratie wordt verkeer niet omgeleid naar afzonderlijke eindpunten, maar naar andere Traffic Manager-profielen. Dit 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 om een failover uit te voeren naar een herstelregio die is gebaseerd op een noodgeval.
• Wanneer de bovenliggende Traffic Manager een DNS-query ontvangt, wordt deze omgeleid naar de relevante onderliggende Traffic Manager die reageert op de query met een beschikbaar eindpunt.

Als het eindpunt in Duitsland - centraal bijvoorbeeld mislukt, kan de toepassing snel worden hersteld naar het noordoosten van Duitsland. Het nieuwe eindpunt verwerkt verkeer dat afkomstig is van Duitsland met minimale downtime voor gebruikers. Op dezelfde manier kan een eindpuntstoring in Europa - west worden verwerkt door de workload van de toepassing 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 vereist 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 erg lastig om DNS-records te wijzigen. De tijd die nodig is om DNS-records bij te werken door andere teams of organisaties die DNS-infrastructuur beheren, varieert van organisatie tot organisatie en heeft invloed op de RTO van de toepassing.

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

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

U kunt ook de TTL-waarde (DNS Time to Live) optimaliseren voor het Traffic Manager-profiel. TTL is de waarde waarvoor een DNS-vermelding door een client in de cache wordt opgeslagen. Voor een record wordt DNS niet tweemaal binnen het bereik van TTL opgevraagd. Aan elke DNS-record is een TTL gekoppeld. Het verminderen van deze waarde resulteert in meer DNS-query's naar 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 overeenkomt met de verstreken tijd sinds de record in de cache is opgeslagen. Dit zorgt ervoor dat de DNS-record na de TTL wordt vernieuwd op de client, ongeacht het aantal DNS-resolvers in de keten.

Volgende stappen

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