Delen via

Anycast-routering met Azure Route Server

Met Anycast-routering kunt u hetzelfde IP-adres uit meerdere Azure-regio's adverteren, waardoor de beschikbaarheid, prestaties en tolerantie van toepassingen worden verbeterd. Met Azure Route Server kunt u anycast-routering implementeren om verkeer automatisch naar het dichtstbijzijnde of meest optimale toepassingsexemplaren te leiden op basis van metrische routeringsgegevens.

In dit artikel wordt uitgelegd hoe u anycast-routering implementeert met Azure Route Server voor implementaties van toepassingen met meerdere regio's via privénetwerken.

Wat is anycast-routering?

Anycast-routering is een netwerkadresserings- en routeringsmethode waarbij hetzelfde IP-adres wordt toegewezen aan meerdere servers of toepassingsexemplaren op verschillende locaties. Wanneer een client een aanvraag naar een anycast-IP-adres verzendt, stuurt de netwerkinfrastructuur het verkeer automatisch naar de dichtstbijzijnde of meest optimale server op basis van routeringsprotocollen en metrische gegevens.

Voordelen van anycast-routering

Anycast-routering biedt verschillende voordelen voor implementaties in meerdere regio's:

  • Verbeterde prestaties: verkeer wordt automatisch doorgestuurd naar het dichtstbijzijnde toepassingsexemplaren, waardoor de latentie wordt verminderd
  • Verbeterde beschikbaarheid: als één regio niet beschikbaar is, wordt automatisch een failover uitgevoerd naar andere regio's
  • Verdeling van belasting: verkeer kan worden verdeeld over meerdere regio's op basis van metrische routeringsgegevens
  • Vereenvoudigde clientconfiguratie: Clients maken verbinding met één IP-adres, ongeacht de werkelijke serverlocatie
  • Ondersteuning voor privénetwerken: In tegenstelling tot DNS-oplossingen werkt anycast met privé-IP-adressen en netwerken

Anycast versus andere benaderingen voor meerdere regio's

Hoewel Azure verschillende services biedt voor implementaties met meerdere regio's, zoals Azure Traffic Manager, Azure Front Door en Azure Cross-Region Load Balancer, zijn deze services ontworpen voor openbaar internetverkeer en openbare IP-adressering.

Anycast-routering met Azure Route Server is ontworpen voor:

  • Scenario's voor privénetwerk: toepassingen waarvoor privé-IP-adressering is vereist
  • Hybride connectiviteit: Scenario's met ExpressRoute- of VPN-verbindingen met on-premises netwerken
  • Verkeersbeheer op basis van routering: waarbij DNS-caching of clientgedrag kan interfereren met DNS-oplossingen

Anycast-implementatie met Azure Route Server

Azure Route Server maakt anycast-routering mogelijk door de aankondiging van identieke routes van meerdere Azure-regio's naar on-premises netwerken via ExpressRoute- of VPN-verbindingen te vergemakkelijken.

Overzicht van architectuur

De anycast-implementatie maakt gebruik van de volgende onderdelen:

  • Meerdere Azure-regio's: elke regio host een exemplaar van uw toepassing
  • Azure Route Server: geïmplementeerd in elke regio om routeadvertenties te beheren
  • Virtuele netwerkapparaten (NVA's): het anycast-IP-adres in elke regio adverteren
  • Hub-and-spoke-topologie: biedt connectiviteit tussen de NVA- en toepassingsexemplaren
  • ExpressRoute of VPN: Azure-regio's verbinden met on-premises netwerken

Implementatietopologie

In het volgende diagram ziet u een typische anycast-implementatie met twee Azure-regio's. Elke regio bevat:

  • Een virtueel hubnetwerk met een NVA en Azure Route Server
  • Een virtueel spoke-netwerk waarvan de host de toepassingsinstantie is
  • ExpressRoute-connectiviteit met on-premises netwerken

Diagram van de implementatie van anycastroutering met Azure Route Server in twee regio's, waarmee wordt aangegeven hoe hetzelfde IP-adres vanaf meerdere locaties wordt geadverteerd.

Hoe anycast-routering werkt

  1. Routeadvertentie: NVA's in elke regio adverteren hetzelfde IP-adresvoorvoegsel (bijvoorbeeld a.b.c.d/32) naar hun lokale Azure Route Server
  2. Routedoorgifte: Azure Route Server geeft deze routes door aan on-premises netwerken via ExpressRoute- of VPN-verbindingen
  3. Routeselectie: On-premises routeringsprotocollen selecteren het beste pad om het anycast-IP-adres te bereiken op basis van metrische routeringsgegevens
  4. Verkeersdistributie: Clientverkeer wordt automatisch gerouteerd naar de optimale regio op basis van het geselecteerde pad

Routeselectie en taakverdeling

De selectie van welke regio verkeer ontvangt, is afhankelijk van routeringskenmerken:

  • ECMP (Equal-Cost Multi-Path): wanneer routes uit meerdere regio's identieke metrische gegevens hebben, wordt verkeer gelijkmatig verdeeld over alle beschikbare paden
  • Voorkeuren voor BGP-pad: U kunt routeringsbeslissingen beïnvloeden door BGP-kenmerken zoals AS-padlengte, lokale voorkeur of MED-waarden aan te passen
  • AS-pad vooraf: het AS-pad kunstmatig langer maken voor specifieke routes om ze minder voorkeur te geven, waardoor een primair/back-upscenario wordt gemaakt

Belangrijk

NVA's moeten mechanismen voor gezondheidscontrole implementeren om advertentieroutes te stoppen wanneer de lokale toepassingsexemplaar niet meer beschikbaar is. Dit voorkomt dat verkeer wordt gerouteerd naar uitgevallen instanties (blackholing).

Aandachtspunten voor retourverkeer

De juiste verwerking van retourverkeer is van cruciaal belang voor succesvolle anycast-implementaties. De methode is afhankelijk van hoe het NVA inkomend verkeer verwerkt.

Verkeersverwerkingsmethoden

  • Reverse proxymodus biedt de meest voorspelbare verkeersstroom wanneer de NVA werkt als een omgekeerde proxy. In deze configuratie beëindigt de NVA de oorspronkelijke verbinding van de client en brengt een nieuwe verbinding tot stand met het toepassingsexemplaar. Retourverkeer stroomt natuurlijk terug via dezelfde NVA omdat de NVA beide zijden van de verbinding beheert.

  • De NAT-modus (Network Address Translation) vereist verschillende overwegingen wanneer de NVA DNAT (Destination Network Address Translation) uitvoert. De NVA vertaalt het doel-IP-adres van het anycast-IP-adres naar het werkelijke IP-adres van de toepassing. Als de NVA ook Bron-NAT (SNAT) uitvoert, stroomt het retourverkeer terug via dezelfde NVA. Als er echter geen SNAT wordt uitgevoerd, is er extra configuratie vereist om de juiste routering van het retourverkeer te garanderen.

Verkeersroutering retourneren

Wanneer de toepassing verkeer ontvangt met het oorspronkelijke IP-adres van de client (geen SNAT), moet u ervoor zorgen dat verkeer wordt geretourneerd via de juiste NVA. Door de gebruiker gedefinieerde routes (UDR's) kunnen worden geconfigureerd in het subnet van de toepassing om verkeer terug te leiden naar de NVA. Deze UDR's moeten de on-premises IP-adresbereiken dekken en goed werken voor enkele NVA-implementaties.

Voor implementaties met meerdere NVA-exemplaren per regio worden asymmetrische verkeersoverwegingen belangrijk. Staatloze NVAs kunnen asymmetrisch verkeer verwerken, waarbij de binnenkomende en uitgaande stromen door verschillende exemplaren gaan. Stateful NVA's vereisen echter een symmetrische verkeersstroom om de verbindingsstatus te behouden. Oplossingen voor stateful NVA's zijn onder andere het gebruik van verbindingsaffiniteitsmechanismen, het implementeren van sessiedeling tussen NVA-exemplaren of het configureren van load balancers met sessiepersistentie.

Aanbevolen procedures voor verkeersstroom

Gezondheidsbewaking moet robuuste gezondheidstests implementeren om applicatie- en NVA-fouten snel te detecteren. Voor de timing van failover is het configureren van de juiste BGP-timers vereist om te balanceren tussen snelle failover en stabiliteit. Traffic engineering kan BGP communities of andere kenmerken gebruiken om verkeersbeleid te implementeren. Uitgebreide bewaking en waarschuwingen moeten routeadvertenties en verkeerspatronen in verschillende regio's volgen om optimale prestaties en snelle detectie van problemen te garanderen.

Implementatieoverwegingen

Voorwaarden en vereisten

Voordat u anycast-routering implementeert met Azure Route Server, moet u zorgvuldig uw IP-adrestoewijzing plannen om ervoor te zorgen dat het anycast-IP-adres geen conflict veroorzaakt met bestaande Azure- of on-premises netwerken. Een solide kennis van BGP-routeringsbeleid en hun effect op de distributie van verkeer is essentieel voor een succesvolle implementatie. Uw toepassingsarchitectuur moet zijn ontworpen om verkeer van meerdere regio's effectief te verwerken en u moet uitgebreide statuscontrole implementeren voor zowel toepassingen als virtuele netwerkapparaten om een betrouwbare werking te garanderen.

Best practices voor implementatie

Bij het implementeren van anycast-routering raden we u aan te beginnen met een eenvoudige implementatie van twee regio's voordat u naar andere regio's uitbreidt. Regelmatige tests van failoverscenario's zorgen ervoor dat het systeem voldoet aan uw beschikbaarheidsvereisten en zich gedraagt zoals verwacht tijdens storingen. Het bewaken van metrische gegevens over prestaties, zoals latentie en doorvoer van verschillende on-premises locaties, biedt waardevolle inzichten in de effectiviteit van uw routeringsconfiguratie. Het onderhouden van duidelijke documentatie van uw BGP-beleid en de beoogde effecten is van cruciaal belang voor doorlopend beheer en probleemoplossing.

Beperkingen en overwegingen

Er moeten verschillende factoren worden overwogen bij het implementeren van anycast-routering met Azure Route Server. BGP-convergentietijden kunnen vertragingen veroorzaken tijdens failover-gebeurtenissen, die mogelijk van invloed zijn op de beoogde hersteltijd. De extra complexiteit van netwerklaagroutering vergeleken met OP DNS gebaseerde oplossingen vereist meer expertise en zorgvuldige planning. Het oplossen van routeringsproblemen met netwerklagen kan lastiger zijn dan het diagnosticeren van toepassingslaagproblemen, waarvoor gespecialiseerde kennis en hulpprogramma's nodig zijn. Bovendien nemen de infrastructuurkosten toe vanwege de behoefte aan meer virtuele netwerkapparaten en Route Server-exemplaren in meerdere regio's.

Volgende stappen

  • Last updated on