Ontwerpen voor hoge beschikbaarheid met ExpressRoute

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. Om de beschikbaarheid te maximaliseren, moeten de klant en het segment van de serviceprovider van uw ExpressRoute-circuit ook worden ontworpen voor hoge beschikbaarheid. In dit artikel gaan we eerst kijken naar overwegingen voor de netwerkarchitectuur voor het bouwen van robuuste netwerkconnectiviteit met behulp van een ExpressRoute. Laten we vervolgens kijken naar de verfijningsfuncties waarmee u de hoge beschikbaarheid van uw ExpressRoute-circuit kunt verbeteren.

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.

Overwegingen voor architectuur

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

Voor hoge beschikbaarheid is het essentieel om de redundantie van het ExpressRoute-circuit in het end-to-endnetwerk te behouden. Met andere woorden, u moet redundantie binnen uw on-premises netwerk behouden en mag geen inbreuk maken op redundantie binnen uw serviceprovidernetwerk. Het handhaven van redundantie op het minimum houdt in dat single point of network failures worden vermeden. Het gebruik van redundante voeding en koeling voor de netwerkapparaten verbetert 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 ExpressRoute-circuits op dezelfde CPE (Customer Premises Equipment) beëindigt, brengt u de hoge beschikbaarheid binnen uw on-premises netwerk in gevaar. Als u zowel de primaire als de secundaire verbindingen configureert met dezelfde poort van een CPE, dwingt u de partner ook tot een hoge beschikbaarheid op het netwerksegment. Deze gebeurtenis kan optreden door de twee verbindingen onder verschillende subinterfaces te beëindigen of door de twee verbindingen binnen het partnernetwerk samen te voegen. Dit compromis wordt geïllustreerd in de volgende afbeelding.

Als u daarentegen de primaire en secundaire verbindingen van een ExpressRoute-circuits op verschillende geografische locaties beëindigt, kunt u de netwerkprestaties van de connectiviteit in gevaar brengen. Als verkeer actief wordt verdeeld over de primaire en secundaire verbindingen die worden beëindigd op verschillende geografische locaties, zou het potentiële aanzienlijke verschil in netwerklatentie tussen de twee paden leiden tot suboptimale netwerkprestaties.

Zie Ontwerpen voor herstel na noodgevallen met ExpressRoute voor overwegingen bij geografisch redundant ontwerp.

Actief-actieve verbindingen

Het Microsoft-netwerk is geconfigureerd voor het laten functioneren van de primaire en secundaire verbindingen van ExpressRoute-circuits in de modus actief-actief. Via uw route-aankondigingen kunt u echter de redundante verbindingen van een ExpressRoute-circuit in de modus actief-passief laten werken. Het aankondigen van specifiekere routes en BGP AS-padtoevoeging zijn de gebruikelijke technieken waarmee het ene pad de voorkeur krijgt boven het andere.

Voor het verbeteren van hoge beschikbaarheid, is het raadzaam beide verbindingen van een ExpressRoute-circuit in de modus actief-actief te laten werken. Als u de verbindingen in de modus actief-actief laat werken, zorgt het Microsoft-netwerk per stroom voor een evenredige verdeling van het verkeer over de verbindingen.

Het uitvoeren van de primaire en secundaire verbindingen van een ExpressRoute-circuit in de actief-passieve modus loopt het risico dat beide verbindingen mislukken na een fout in het actieve pad. De veelvoorkomende oorzaken van een storing bij het overschakelen zijn gebrek aan actief beheer van de passieve verbinding en het adverteren van oude routes door passieve verbindingen.

U kunt ook de primaire en secundaire verbindingen van een ExpressRoute-circuit uitvoeren in de actief-actieve modus. Dit resulteert in ongeveer de helft van de stromen die mislukken en worden omgeleid. Daarom helpt een actief-actieve verbinding de MEAN Time To Recover (MTTR) aanzienlijk verbeteren.

Notitie

Tijdens een onderhoudsactiviteit of in het geval van niet-geplande gebeurtenissen die van invloed zijn op een van de verbindingen, geeft Microsoft de voorkeur aan AS-pad voor het leegmaken van verkeer naar de goede verbinding. U moet ervoor zorgen dat het verkeer via het gezonde pad kan worden gerouteerd wanneer het pad voorafgaat door Microsoft en de vereiste routeadvertenties op de juiste wijze worden geconfigureerd om serviceonderbrekingen te voorkomen.

NAT voor Microsoft-peering

Microsoft-peering is ontworpen voor communicatie tussen openbare eindpunten. On-premises privé-eindpunten zijn dus meestal Network Address Translated (NATed) met een openbaar IP-adres op het klant- of partnernetwerk voordat ze communiceren via Microsoft-peering. Ervan uitgaande dat u zowel de primaire als de secundaire verbindingen gebruikt in een actief-actief-installatie. Waar en hoe uw NAT van invloed is op hoe snel u herstelt na een fout in een van de ExpressRoute-verbindingen. In de volgende afbeelding ziet u twee verschillende NAT-opties:

Optie 1:

NAT wordt toegepast na het splitsen van het verkeer tussen de primaire en secundaire verbindingen van het ExpressRoute-circuit. Om te voldoen aan de stateful vereisten van NAT, worden onafhankelijke NAT-pools gebruikt voor de primaire en de secundaire apparaten. Het retourverkeer arriveert op hetzelfde edge-apparaat waarmee de stroom wordt verzonden.

Als de ExpressRoute-verbinding mislukt, wordt de mogelijkheid om de bijbehorende NAT-pool te bereiken verbroken. Daarom moeten alle verbroken netwerkstromen opnieuw worden ingesteld door TCP of door de toepassingslaag na de bijbehorende time-out voor vensters. Tijdens de fout kan Azure de on-premises servers niet bereiken met behulp van de bijbehorende NAT totdat de verbinding is hersteld voor de primaire of secundaire verbindingen van het ExpressRoute-circuit.

Optie 2:

Er wordt een algemene NAT-pool gebruikt voordat u het verkeer splitst tussen de primaire en secundaire verbindingen van het ExpressRoute-circuit. Het is belangrijk om het onderscheid te maken dat de algemene NAT-pool voordat u het verkeer splitst, niet betekent dat er een single point of failure wordt geïntroduceerd, zoals het in gevaar brengen van hoge beschikbaarheid.

De NAT-pool is bereikbaar, zelfs nadat de primaire of secundaire verbinding is mislukt. De netwerklaag zelf kan de pakketten dus omleiden en helpen sneller te herstellen na een fout.

Notitie

• Als u NAT-optie 1 (onafhankelijke NAT-pools voor primaire en secundaire ExpressRoute-verbindingen) gebruikt en een poort van een IP-adres van een van de NAT-pools toe wijzen aan een on-premises server, is de server niet bereikbaar via het ExpressRoute-circuit wanneer de bijbehorende verbinding mislukt.
• Het beëindigen van ExpressRoute BGP-verbindingen op stateful apparaten kan problemen met failover veroorzaken tijdens gepland of ongepland onderhoud door Microsoft of uw ExpressRoute-provider. U moet uw configuratie testen om ervoor te zorgen dat uw verkeer correct wordt uitgevoerd en, indien mogelijk, BGP-sessies op stateless apparaten beëindigen.

Functies voor het afstemmen van persoonlijke peering

In deze sectie bekijken we optioneel (afhankelijk van uw Azure-implementatie en hoe gevoelig u bent voor MTTR)-functies waarmee u de hoge beschikbaarheid van uw ExpressRoute-circuit kunt verbeteren. Laten we met name de zonebewuste implementatie van virtuele ExpressRoute-netwerkgateways en bidirectionele doorstuurdetectie (BFD) bekijken.

Beschikbaarheidszonebewuste virtuele ExpressRoute-netwerkgateways

Een beschikbaarheidszone in een Azure-regio is een combinatie van een foutdomein en een updatedomein. Als u de hoogste tolerantie en beschikbaarheid wilt bereiken, moet u een zone-redundante virtuele ExpressRoute-netwerkgateway configureren. 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

ExpressRoute ondersteunt BFD via privépeering. BFD vermindert de detectietijd van storingen via het Laag 2-netwerk tussen Microsoft Enterprise Edge (MSEEs) en hun BGP-buren aan de on-premises zijde van ongeveer 3 minuten (standaard) tot minder dan een seconde. Snelle tijd voor foutdetectie helpt het herstel van fouten te voltooien. Zie BFD configureren via ExpressRoute voor meer informatie.

Volgende stappen

In dit artikel hebben we besproken hoe u ontwerpt voor hoge beschikbaarheid van een ExpressRoute-circuitconnectiviteit. Een ExpressRoute-circuitpeeringspunt wordt vastgemaakt aan een geografische locatie en wordt daarom beïnvloed door een onherstelbare fout die van invloed is op de hele locatie.

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