Ontwerpen voor herstel na noodgevallen met persoonlijke ExpressRoute-peering

  • Artikel

ExpressRoute is ontworpen voor een hoge beschikbaarheid om particuliere netwerkconnectiviteit op provider-niveau te bieden voor Microsoft-resources. Met andere woorden, er is geen single point of failure in het ExpressRoute-pad binnen het Microsoft-netwerk. Zie Ontwerpen voor hoge beschikbaarheid met ExpressRoute en Well-Architectured Framework voor ontwerpoverwegingen om de beschikbaarheid van een ExpressRoute-circuit te maximaliseren

Maar als er iets mis kan gaan, laten we ons in dit artikel richten op oplossingen die verder gaan dan fouten die kunnen worden aangepakt met één ExpressRoute-circuit. We bekijken overwegingen voor de netwerkarchitectuur voor het bouwen van een robuuste back-endnetwerkconnectiviteit voor herstel na noodgevallen met behulp van geografisch redundante ExpressRoute-circuits.

Notitie

De concepten die in dit artikel worden beschreven, zijn eveneens van toepassing wanneer een ExpressRoute-circuit wordt gemaakt onder Virtual WAN of buiten het circuit.

Behoefte aan redundante connectiviteitsoplossing

Er zijn mogelijkheden en exemplaren waarbij een ExpressRoute-peeringlocatie of een hele regionale service wordt gedegradeerd. De hoofdoorzaak voor een dergelijke regionale servicestoring omvat natuurlijke rampen. Daarom is het belangrijk om noodherstel te plannen voor bedrijfscontinuïteit en bedrijfskritieke toepassingen.

Notitie

Wanneer u een ontwerp voor herstel na noodgevallen in een tijdgevoelige situatie moet implementeren, zoals het handhaven van bedrijfscontinuïteit tijdens een natuurramp, moet u rekening houden met de volgende factoren:

  • Dit document bevat richtlijnen voor het implementeren van een robuust ontwerp voor herstel na noodgevallen voor meerdere ExpressRoute-circuits die zijn geconfigureerd via verschillende peeringlocaties. In dit scenario wordt ervan uitgegaan dat u voldoende tijd en resources hebt om de ExpressRoute-circuits in te stellen.
  • Als u snel een ontwerp voor herstel na noodgevallen wilt configureren voor één ExpressRoute-circuit dat niet geografisch redundant is, kunt u de volgende alternatieven gebruiken:

Ongeacht of u uw bedrijfskritieke toepassingen uitvoert in een Azure-regio of on-premises of ergens anders, u kunt een andere Azure-regio gebruiken als uw failoversite. De volgende artikelen hebben betrekking op herstel na noodgevallen vanuit toepassingen en perspectieven voor front-endtoegang:

Als u gebruikmaakt van ExpressRoute-connectiviteit tussen uw on-premises netwerk en Microsoft, moet u rekening houden met het volgende om herstel na noodgevallen via ExpressRoute te plannen:

Uitdagingen voor het gebruik van meerdere ExpressRoute-circuits

Wanneer u dezelfde set netwerken met meerdere verbindingen verbindt, introduceert u parallelle paden tussen de netwerken. Parallelle paden, wanneer ze niet goed zijn ontworpen, kunnen leiden tot asymmetrische routering. Als u stateful entiteiten hebt, bijvoorbeeld een NAT of firewall in het pad, kan asymmetrische routering de verkeersstroom blokkeren. Normaal gesproken komt u via het expressRoute-privépeeringspad niet over stateful entiteiten zoals NAT of firewalls. Daarom blokkeert asymmetrische routering via persoonlijke ExpressRoute-peering niet noodzakelijkerwijs de verkeersstroom.

Als u echter verkeer over geografisch redundante parallelle paden verdeelt, ongeacht of u stateful entiteiten hebt of niet, ondervindt u inconsistente netwerkprestaties. Deze geografisch redundante parallelle paden kunnen via dezelfde metro of andere metro worden gevonden op de providers op locatiepagina .

Redundantie met ExpressRoute-circuits in dezelfde metro

Veel metro's hebben twee ExpressRoute-locaties. Een voorbeeld hiervan is Amsterdam en Amsterdam2. Bij het ontwerpen van redundantie kunt u twee parallelle paden naar Azure bouwen met beide locaties in dezelfde metro. U kunt deze taak uitvoeren met dezelfde provider of ervoor kiezen om met een andere serviceprovider te werken om de tolerantie te verbeteren. Een ander voordeel van dit ontwerp is wanneer failover van toepassingen plaatsvindt, end-to-end latentie tussen uw on-premises toepassingen en Microsoft ongeveer hetzelfde blijft. Als er echter een natuurramp is, zoals een aardbeving, is de connectiviteit voor beide paden mogelijk niet meer beschikbaar.

Redundantie met ExpressRoute-circuits in verschillende metrolijnen

Wanneer u verschillende metro's gebruikt voor redundantie, moet u de secundaire locatie in dezelfde geografische regio selecteren. Als u een locatie buiten de geografische politieke regio wilt kiezen, moet u premium-SKU gebruiken voor beide circuits in de parallelle paden. Het voordeel van deze configuratie is de kans dat een natuurramp een storing aan beide koppelingen veroorzaakt, lager is, maar ten koste van een verhoogde latentie end-to-end.

Notitie

Het inschakelen van BFD op de ExpressRoute-circuits helpt bij snellere detectie van koppelingsfouten tussen Microsoft Enterprise Edge-apparaten (MSEE) en de Edge-routers van de klant/partner. De algehele failover en convergentie van redundante sites kunnen echter tot 180 seconden duren onder bepaalde storingsomstandigheden en u kunt gedurende deze tijd te maken hebben met een verhoogde latentie of prestatievermindering.

In dit artikel bespreken we hoe u uitdagingen kunt aanpakken waarmee u te maken krijgt bij het configureren van geografisch redundante paden.

Overwegingen voor kleine tot middelgrote on-premises netwerken

Laten we eens kijken naar het voorbeeldnetwerk dat in het volgende diagram wordt geïllustreerd. In het voorbeeld wordt geografisch redundante ExpressRoute-connectiviteit tot stand gebracht tussen de on-premises locatie van Contoso en het VNet van Contoso in een Azure-regio. In het diagram geeft een ononderbroken blauwe lijn het voorkeurspad aan (via ExpressRoute 1) en het gestippelde pad (via ExpressRoute 2).

Diagram of small to medium size on-premises network considerations.

Als u routes op dezelfde manier adverteert via alle ExpressRoute-paden, wordt on-premises verkeer in Azure verdeeld over alle ExpressRoute-paden met ECMP-routering (Equal Cost Multi-Path).

Met de geografisch redundante ExpressRoute-circuits moeten we echter rekening houden met verschillende netwerkprestaties met verschillende netwerkpaden (met name voor netwerklatentie). Als u consistentere netwerkprestaties wilt krijgen tijdens de normale werking, wilt u misschien de voorkeur geven aan het ExpressRoute-circuit dat de minimale latentie biedt.

U kunt azure beïnvloeden om de voorkeur te geven aan één ExpressRoute-circuit boven een van de volgende technieken (vermeld in de volgorde van effectiviteit):

  • meer specifieke route te adverteren via het voorkeurs-ExpressRoute-circuit vergeleken met andere ExpressRoute-circuits
  • een hoger Verbinding maken iongewicht configureren voor de verbinding die het virtuele netwerk koppelt aan het gewenste ExpressRoute-circuit
  • adverteren van de routes via minder voorkeur ExpressRoute-circuit met langer AS-pad (AS-padvoorpend)

Specifiekere route

Het volgende diagram illustreert het beïnvloeden van de selectie van ExpressRoute-paden met behulp van specifiekere routeadvertenties. In het geïllustreerde voorbeeld wordt het ip-adresbereik van Contoso on-premises /24 geadverteerd als twee /25-adresbereiken via het voorkeurspad (ExpressRoute 1) en als /24 via het standaardpad (ExpressRoute 2).

Diagram of influencing path selection using more specific routes.

Omdat /25 specifieker is in vergelijking met /24, stuurt Azure het verkeer dat is bestemd voor 10.1.11.0/24 via ExpressRoute 1 in de normale staat. Als beide verbindingen van ExpressRoute 1 omlaag gaan, ziet het VNet de advertentie 10.1.11.0/24 alleen via ExpressRoute 2; en daarom wordt het stand-bycircuit gebruikt in deze foutstatus.

Verbinding maken iongewicht

In de volgende schermopname ziet u hoe u het gewicht van een ExpressRoute-verbinding configureert via Azure Portal.

Screenshot of configuring connection weight via Azure portal.

Het volgende diagram illustreert het beïnvloeden van de selectie van ExpressRoute-paden met behulp van verbindingsgewicht. Het standaardgewicht van de verbinding is 0. In het volgende voorbeeld is het gewicht van de verbinding voor ExpressRoute 1 geconfigureerd als 100. Wanneer een VNet een routevoorvoegsel ontvangt dat wordt geadverteerd via meer dan één ExpressRoute-circuit, geeft het VNet de voorkeur aan de verbinding met het hoogste gewicht.

Diagram of influencing path selection using connection weight.

Als beide verbindingen van ExpressRoute 1 omlaag gaan, ziet het VNet de advertentie 10.1.11.0/24 alleen via ExpressRoute 2; en daarom wordt het stand-bycircuit gebruikt in deze foutstatus.

AS-pad vooraf

Het volgende diagram illustreert het beïnvloeden van de selectie van ExpressRoute-paden met behulp van as-padvoorverlenend. In het diagram geeft de routeaanwijzer via ExpressRoute 1 het standaardgedrag van eBGP aan. Op de routeaanwijzer via ExpressRoute 2 wordt de ASN van het on-premises netwerk verder voorbereid op het AS-pad van de route. Wanneer dezelfde route wordt ontvangen via meerdere ExpressRoute-circuits, geeft VNet de voorkeur aan de route met het kortste AS-pad, volgens het selectieproces van de eBGP-route.

Diagram of influencing path selection using AS path prepend.

Als beide verbindingen van ExpressRoute 1 omlaag gaan, ziet het VNet de advertentie 10.1.11.0/24 alleen via ExpressRoute 2. Hoe langer AS-pad daarom irrelevant zou worden. Daarom zou het stand-bycircuit worden gebruikt in deze foutstatus.

Als u de voorkeur geeft aan een van uw ExpressRoute-technieken, moet u er ook voor zorgen dat het on-premises netwerk hetzelfde ExpressRoute-pad voor Azure-gebonden verkeer gebruikt om asymmetrische stromen te voorkomen. Normaal gesproken wordt de lokale voorkeurswaarde gebruikt om het on-premises netwerk te beïnvloeden om de voorkeur te geven aan één ExpressRoute-circuit boven andere. Lokale voorkeur is een interne BGP -metrische waarde (iBGP). De BGP-route met de hoogste lokale voorkeurswaarde heeft de voorkeur.

Belangrijk

Wanneer u bepaalde ExpressRoute-circuits als stand-by gebruikt, moet u deze actief beheren en de failover-bewerking periodiek testen.

Groot gedistribueerd bedrijfsnetwerk

Wanneer u een groot gedistribueerd bedrijfsnetwerk hebt, hebt u waarschijnlijk meerdere ExpressRoute-circuits. In deze sectie bekijken we hoe u herstel na noodgevallen ontwerpt met behulp van de actief-actieve ExpressRoute-circuits, zonder dat u een andere stand-by-circuits nodig hebt.

Laten we eens kijken naar het voorbeeld in het volgende diagram. In het voorbeeld heeft Contoso twee on-premises locaties die zijn verbonden met twee Contoso IaaS-implementaties in twee verschillende Azure-regio's via ExpressRoute-circuits in twee verschillende peeringlocaties.

Diagram of large distributed on-premises network considerations.

Hoe we het herstel na noodgevallen ontwerpen, heeft een effect op hoe verkeer tussen regio's (regio1/regio2 naar locatie2/locatie1) wordt gerouteerd. Laten we eens kijken naar twee verschillende noodarchitecturen waarmee verkeer tussen regio's anders wordt gerouteerd.

Scenario 1

In het eerste scenario gaan we herstel na noodgevallen ontwerpen, zodat al het verkeer tussen een Azure-regio en een on-premises netwerk via het lokale ExpressRoute-circuit in de stabiele status stroomt. Als het lokale ExpressRoute-circuit mislukt, wordt het externe ExpressRoute-circuit gebruikt voor alle verkeersstromen tussen Azure en on-premises netwerk.

Scenario 1 wordt geïllustreerd in het volgende diagram. In het diagram geven groene lijnen paden aan voor de verkeersstroom tussen VNet1 en on-premises netwerken. De blauwe lijnen geven paden aan voor de verkeersstroom tussen VNet2 en on-premises netwerken. Ononderbroken lijnen geven het gewenste pad aan in de gestage toestand en de stippellijnen geven het verkeerspad aan bij het mislukken van het bijbehorende ExpressRoute-circuit dat een verkeersstroom met een stabiele status heeft.

Diagram of traffic flow for first scenario.

U kunt het scenario ontwerpen met behulp van verbindingsgewicht om VNets te beïnvloeden om de voorkeur te geven aan verbinding met lokale peeringlocatie ExpressRoute voor on-premises netwerkverkeer. Om de oplossing te voltooien, moet u zorgen voor symmetrische omgekeerde verkeersstroom. U kunt lokale voorkeur gebruiken voor de iBGP-sessie tussen uw BGP-routers (waarop ExpressRoute-circuits worden beëindigd aan de on-premises zijde) om de voorkeur te geven aan een ExpressRoute-circuit. De oplossing wordt geïllustreerd in het volgende diagram.

Diagram of active-active ExpressRoute circuits solution 1.

Scenario 2

Het scenario 2 wordt geïllustreerd in het volgende diagram. In het diagram geven groene lijnen paden aan voor de verkeersstroom tussen VNet1 en on-premises netwerken. De blauwe lijnen geven paden aan voor de verkeersstroom tussen VNet2 en on-premises netwerken. In de onveranderbare, ononderbroken lijnen in het diagram stromen al het verkeer tussen VNets en on-premises locaties normaal met behulp van de Microsoft-backbone en loopt de verbinding tussen on-premises locaties alleen in de foutstatus, stippellijnen in het diagram, van een ExpressRoute.

Diagram of traffic flow for second scenario.

De oplossing wordt geïllustreerd in het volgende diagram. Zoals geïllustreerd, kunt u het scenario ontwerpen met behulp van specifiekere route (optie 1) of AS-padvoorpend (optie 2) om de selectie van het VNet-pad te beïnvloeden. Als u de selectie van on-premises netwerkroute voor afhankelijk Azure-verkeer wilt beïnvloeden, moet u de verbinding tussen de on-premises locatie configureren als minder. Hoe u de koppeling naar voorkeur configureert, is afhankelijk van het routeringsprotocol dat in het on-premises netwerk wordt gebruikt. U kunt lokale voorkeur gebruiken met iBGP of metrische gegevens met IGP (OSPF of IS-IS).

Diagram of active-active ExpressRoute circuits solution 2.

Belangrijk

Wanneer een of meerdere ExpressRoute-circuits zijn verbonden met meerdere virtuele netwerken, kan het virtuele netwerk naar virtueel netwerkverkeer worden gerouteerd via ExpressRoute. Dit wordt echter niet aanbevolen. Als u een virtueel netwerk wilt inschakelen voor virtuele netwerkconnectiviteit, configureert u peering van virtuele netwerken.

Volgende stappen

In dit artikel hebben we besproken hoe u ontwerpt voor herstel na noodgevallen van een privépeeringsconnectiviteit voor een ExpressRoute-circuit. De volgende artikelen hebben betrekking op herstel na noodgevallen vanuit toepassingen en perspectieven voor front-endtoegang: