Ontwerpen voor hoge beschikbaarheid met Azure ExpressRoute

Azure ExpressRoute is ontworpen voor hoge beschikbaarheid en biedt connectiviteit van privénetwerken op providerniveau met Microsoft-resources. Dit betekent dat er geen single point of failure binnen het Microsoft-netwerk is. Om de beschikbaarheid te maximaliseren, moeten zowel de segmenten van klanten als serviceproviders van uw Azure ExpressRoute-circuit ook worden ontworpen voor hoge beschikbaarheid. In dit artikel worden overwegingen voor netwerkarchitectuur besproken voor het bouwen van robuuste connectiviteit met behulp van Azure ExpressRoute en het verfijnen van functies om de hoge beschikbaarheid van uw Azure ExpressRoute-circuit te verbeteren.

Notitie

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

Overwegingen voor architectuur

In de volgende afbeelding ziet u de aanbevolen manier om verbinding te maken met behulp van een Azure ExpressRoute-circuit om de beschikbaarheid te maximaliseren.

Voor hoge beschikbaarheid is het essentieel om redundantie te behouden in het end-to-end-netwerk. Dit betekent dat redundantie binnen uw on-premises netwerk behouden blijft en geen afbreuk doet aan redundantie binnen uw serviceprovidernetwerk. Dit omvat minimaal het vermijden van single points of network failure. Redundante voeding en koeling voor netwerkapparaten verbeteren de hoge beschikbaarheid verder.

Overwegingen bij het ontwerpen van fysieke lagen van de eerste mijl

Als u zowel de primaire als de secundaire verbindingen van een Azure ExpressRoute-circuit op dezelfde CPE (Customer Premises Equipment) beëindigt, kunt u hoge beschikbaarheid binnen uw on-premises netwerk in gevaar brengen. Bovendien zorgt het configureren van beide verbindingen met dezelfde poort van een CPE ervoor dat de partner een hoge beschikbaarheid in het netwerksegment in gevaar heeft gebracht. Dit kan gebeuren door de twee verbindingen onder verschillende subinterfaces te beëindigen of de twee verbindingen in het partnernetwerk samen te voegen, zoals hieronder wordt geïllustreerd.

Als u de primaire en secundaire verbindingen van een Azure ExpressRoute-circuit op verschillende geografische locaties beëindigt, kunnen de netwerkprestaties worden aangetast. Als verkeer actief wordt verdeeld over verbindingen die op verschillende locaties zijn beëindigd, kunnen aanzienlijke verschillen in netwerklatentie tussen de twee paden leiden tot suboptimale prestaties.

Zie Ontwerpen voor herstel na noodgevallen met Azure ExpressRoute voor geografisch redundante ontwerpoverwegingen.

Actief-actieve verbindingen

Het Microsoft-netwerk beheert de primaire en secundaire verbindingen van Azure ExpressRoute-circuits in de modus Actief-actief. U kunt echter afdwingen dat de redundante verbindingen worden uitgevoerd in de actief-passieve modus via uw routeadvertenties. Het adverteren van specifiekere routes en BGP AS-padvoorprepending zijn veelgebruikte technieken om de voorkeur te geven aan één pad boven het andere.

Om de hoge beschikbaarheid te verbeteren, is het raadzaam om beide verbindingen in de actief-actieve modus te gebruiken. Hierdoor kan het Microsoft-netwerk verkeer verdelen over de verbindingen per stroom.

Het uitvoeren van verbindingen in de actief-passieve modus riskeert dat beide verbindingen mislukken als het actieve pad mislukt. Veelvoorkomende oorzaken van fouten zijn onder meer gebrek aan actief beheer van de passieve verbinding en passieve verbindingsadvertentieroutes.

Het uitvoeren van verbindingen in de actief-actieve modus resulteert ook in slechts ongeveer de helft van de stromen die mislukken en worden omgeleid, waardoor de MEAN Time To Recover (MTTR) aanzienlijk wordt verbeterd.

Notitie

Tijdens onderhoud of ongeplande gebeurtenissen die van invloed zijn op één verbinding, gebruikt Microsoft AS-pad om verkeer naar de goede verbinding leeg te maken. Zorg ervoor dat verkeer via het gezonde pad kan worden gerouteerd wanneer padvoorverlening is geconfigureerd door Microsoft en dat vereiste routeadvertenties op de juiste wijze zijn ingesteld om serviceonderbreking te voorkomen.

NAT voor Microsoft-peering

Microsoft-peering is ontworpen voor communicatie tussen openbare eindpunten. On-premises privé-eindpunten zijn doorgaans Network Address Translated (NATed) met openbare IP-adressen op het klant- of partnernetwerk voordat ze via Microsoft-peering communiceren. Het gebruik van zowel primaire als secundaire verbindingen in een actief-actief-installatie is van invloed op hoe snel u herstelt na een fout in een van de verbindingen. Hieronder ziet u twee verschillende NAT-opties:

Optie 1:

NAT wordt toegepast na het splitsen van verkeer tussen de primaire en secundaire verbindingen. Onafhankelijke NAT-pools worden gebruikt voor de primaire en secundaire apparaten om te voldoen aan stateful NAT-vereisten. Retourverkeer arriveert op hetzelfde edge-apparaat waarmee de stroom wordt geretourneerd.

Als een Azure ExpressRoute-verbinding mislukt, wordt de bijbehorende NAT-pool onbereikbaar, zodat alle netwerkstromen worden onderbroken. Deze stromen moeten opnieuw worden ingesteld door TCP of de toepassingslaag na de time-out van het venster. Tijdens de fout kan Azure geen on-premises servers bereiken met behulp van de bijbehorende NAT totdat de verbinding is hersteld.

Optie 2:

Een algemene NAT-pool wordt gebruikt voordat u verkeer splitst tussen de primaire en secundaire verbindingen. Dit introduceert geen single point of failure, waardoor hoge beschikbaarheid behouden blijft.

De NAT-pool blijft bereikbaar, zelfs als de primaire of secundaire verbinding mislukt, waardoor de netwerklaag pakketten kan omleiden en sneller kan worden hersteld.

Notitie

• Als u NAT-optie 1 (onafhankelijke NAT-pools voor primaire en secundaire verbindingen) gebruikt en een poort van een IP-adres van één NAT-pool toe te voegen aan een on-premises server, is de server niet bereikbaar via het Azure ExpressRoute-circuit als de bijbehorende verbinding mislukt.
• Het beëindigen van Azure ExpressRoute BGP-verbindingen op stateful apparaten kan failoverproblemen veroorzaken tijdens gepland of ongepland onderhoud door Microsoft of uw Azure ExpressRoute-provider. Test uw installatie om de juiste failover te garanderen en indien mogelijk BGP-sessies op stateless apparaten te beëindigen.

Functies voor het afstemmen van persoonlijke peering

In deze sectie worden optionele functies besproken waarmee u de hoge beschikbaarheid van uw Azure ExpressRoute-circuit kunt verbeteren, afhankelijk van uw Azure-implementatie en gevoeligheid voor MTTR. Het gaat met name om zonebewuste implementatie van virtuele Azure ExpressRoute-netwerkgateways en BFD (Bidirectional Forwarding Detection).

Beschikbaarheidszonebewuste virtuele Azure ExpressRoute-netwerkgateways

Een beschikbaarheidszone in een Azure-regio combineert een foutdomein en een updatedomein. Als u de hoogste tolerantie en beschikbaarheid wilt bereiken, configureert u een zoneredundante virtuele Azure ExpressRoute-netwerkgateway. Zie Voor meer informatie over zone-redundante virtuele netwerkgateways in Azure Beschikbaarheidszones. Zie Een zone-redundante virtuele netwerkgateway maken in Azure Beschikbaarheidszones om een zone-redundante virtuele netwerkgateway te configureren.

Foutdetectietijd verbeteren

Azure ExpressRoute biedt ondersteuning voor BFD via privépeering, waardoor de tijd voor foutdetectie via het Laag 2-netwerk tussen Microsoft Enterprise Edge (MSEEs) en hun BGP-buren aan de on-premises kant van ongeveer 3 minuten (standaard) tot minder dan een seconde wordt beperkt. Snelle foutdetectie helpt herstel te fasigen. Zie BFD configureren via Azure ExpressRoute voor meer informatie.

Volgende stappen

In dit artikel is het ontwerpen voor hoge beschikbaarheid van een Azure ExpressRoute-circuit besproken. Een Azure ExpressRoute-circuitpeeringspunt wordt vastgemaakt aan een geografische locatie en kan worden beïnvloed door onherstelbare fouten die van invloed zijn op de hele locatie.

Voor ontwerpoverwegingen voor het bouwen van geografisch redundante netwerkconnectiviteit met de Microsoft-backbone die bestand zijn tegen onherstelbare fouten die van invloed zijn op een hele regio, raadpleegt u Ontwerpen voor herstel na noodgevallen met persoonlijke Azure ExpressRoute-peering.