Anycast-routering met Azure Route Server
U kunt uw toepassing implementeren in Beschikbaarheidszones in één Azure-regio om een hogere beschikbaarheid te bereiken, maar soms moet u uw toepassingen mogelijk in meerdere regio's implementeren om een hogere tolerantie te bereiken, een betere prestaties voor gebruikers over de hele wereld of betere bedrijfscontinuïteit. Er zijn verschillende benaderingen die kunnen worden gebruikt om gebruikers naar een van de locaties te leiden waarop een toepassing met meerdere regio's wordt geïmplementeerd: OP DNS gebaseerde benaderingen zoals Azure Traffic Manager, op routering gebaseerde services zoals Azure Front Door of de Load Balancer voor meerdere regio's in Azure.
De vorige Azure-services worden aanbevolen om gebruikers naar de beste toepassingslocatie te krijgen via het openbare internet met behulp van openbare IP-adressering, maar ze bieden geen ondersteuning voor privénetwerken en IP-adressen. In dit artikel wordt het gebruik van een op route gebaseerde benadering (IP anycast) verkend om implementaties van toepassingen met meerdere regionale, privénetwerken te bieden.
IP anycast bestaat in wezen uit het adverteren van exact hetzelfde IP-adres vanaf meer dan één locatie, zodat pakketten van de toepassingsgebruikers worden gerouteerd naar de dichtstbijzijnde regio (wat betreft routering). Het bieden van bereik voor meerdere regio's via anycast biedt enkele voordelen ten opzichte van OP DNS gebaseerde benaderingen, zoals het niet hoeven vertrouwen op clients die hun DNS-antwoorden niet opslaan in de cache en het DNS-ontwerp voor de toepassing niet hoeven te wijzigen.
Topologie
In het ontwerp van dit scenario wordt hetzelfde IP-adres geadverteerd vanuit virtuele netwerken in verschillende Azure-regio's, waarbij virtuele netwerkapparaten (NVA's) het IP-adres van de toepassing adverteren via Azure Route Server. In het volgende diagram ziet u twee eenvoudige hub- en spoke-topologieën, elk in een andere Azure-regio. Een NVA in elke regio adverteert dezelfde route (a.b.c.d/32 in dit voorbeeld) naar de lokale Azure Route Server (het routevoorvoegsel mag niet overlappen met Azure- en on-premises netwerken). De routes worden verder doorgegeven aan het on-premises netwerk via ExpressRoute. Wanneer toepassingsgebruikers toegang willen krijgen tot de toepassing vanuit on-premises, wordt de DNS-infrastructuur (die niet wordt gedekt door dit document) omgezet in de DNS-naam van de toepassing naar het anycast-IP-adres (a.b.c.d), die de on-premises netwerkapparaten routeren naar een van de twee regio's.
De beslissing van welke van de beschikbare regio's is geselecteerd, is volledig gebaseerd op routeringskenmerken. Als de routes van beide regio's identiek zijn, gebruikt het on-premises netwerk doorgaans ecmp-routering (equal-cost multi-path) om elke toepassingsstroom naar elke regio te verzenden. Het is ook mogelijk om de advertenties te wijzigen die door elke NVA in Azure worden gegenereerd om een van de regio's de voorkeur te geven. Gebruik bijvoorbeeld BGP AS Path prepending om een deterministisch pad van on-premises naar de Azure-workload te maken.
Belangrijk
De NVA's die de routes adverteren, moeten een statuscontrolemechanisme bevatten om te stoppen met het adverteren van de route wanneer de toepassing niet beschikbaar is in hun respectieve regio's, om blackholing-verkeer te voorkomen.
Verkeer retourneren
Wanneer het toepassingsverkeer van de on-premises client binnenkomt bij een van de NVA's in Azure, voert de NVA verbinding reverse-proxy of Destination Network Address Translation (DNAT) uit. Vervolgens worden de pakketten verzonden naar de werkelijke toepassing, die zich meestal in een virtueel spoke-netwerk bevindt dat is gekoppeld aan het virtuele hubnetwerk waar de NVA is geïmplementeerd. Verkeer terug van de toepassing gaat terug via de NVA, wat natuurlijk zou gebeuren als de NVA de verbinding omgekeerd proxyt (of bron-NAT uitvoert naast Destination NAT).
Anders wordt verkeer dat naar de toepassing aankomt, nog steeds afkomstig van het oorspronkelijke IP-adres van de on-premises client. In dit geval kunnen pakketten worden doorgestuurd naar de NVA met door de gebruiker gedefinieerde routes (UDR's). Speciale zorg moet worden genomen als er meer dan één NVA-exemplaar in elke regio is, omdat verkeer asymmetrisch kan zijn (het inkomende en uitgaande verkeer dat door verschillende NVA-exemplaren gaat). Asymmetrisch verkeer is doorgaans geen probleem als NVA's staatloos zijn, maar leidt dit tot fouten als NVA's verbindingsstatussen bijhouden, zoals firewalls.