Ontwerpen voor hoge beschikbaarheid met ExpressRoute
ExpressRoute is ontworpen voor hoge beschikbaarheid om particuliere netwerkconnectiviteit op providerkwaliteit met Microsoft-resources te bieden. 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 serviceprovidersegment van uw ExpressRoute-circuit ook worden ontworpen voor hoge beschikbaarheid. In dit artikel kijken we eerst naar overwegingen voor de netwerkarchitectuur voor het bouwen van robuuste netwerkconnectiviteit met behulp van een ExpressRoute. Vervolgens gaan we kijken naar de afstemmingsfuncties die u helpen de hoge beschikbaarheid van uw ExpressRoute-circuit te verbeteren.
Notitie
De concepten die in dit artikel worden beschreven, zijn ook van toepassing wanneer een ExpressRoute-circuit wordt gemaakt onder Virtual WAN of daarbuiten.
Architectuuroverwegingen
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.
[![1]][1]
Voor hoge beschikbaarheid is het essentieel om de redundantie van het ExpressRoute-circuit in het end-to-end-netwerk te behouden. Met andere woorden, u moet redundantie binnen uw on-premises netwerk behouden en mag geen redundantie binnen het netwerk van uw serviceprovider in gevaar brengen. Het zo min mogelijk behouden van redundantie impliceert het voorkomen van single point of network failures. 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 secundaire verbindingen van een ExpressRoute-circuits op dezelfde Customer Premises Equipment (CPE) beëindigt, maakt u de hoge beschikbaarheid in uw on-premises netwerk in gevaar. Als u bovendien zowel de primaire als secundaire verbindingen configureert via dezelfde poort van een CPE (door de twee verbindingen onder verschillende subinterfaces te beëindigen of door de twee verbindingen binnen het partnernetwerk samen te voegen), dwingt u de partner ook om hoge beschikbaarheid in het netwerksegment in gevaar te brengen. 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, kan dit 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 een mogelijk aanzienlijk verschil in netwerklatentie tussen de twee paden leiden tot suboptimale netwerkprestaties.
Zie Ontwerpen voor herstel na noodherstel met ExpressRoute voor overwegingen bij het ontwerpen van geografisch redundante ontwerp.
Actief-actief-verbindingen
Het Microsoft-netwerk is geconfigureerd voor het gebruik 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 dwingen om in de actief-passieve modus te werken. Het adverteren van specifiekere routes en BGP AS-paden vooraf zijn de gebruikelijke technieken die worden gebruikt om het ene pad de voorkeur te bieden boven het andere.
Om hoge beschikbaarheid te verbeteren, is het raadzaam om beide verbindingen van een ExpressRoute-circuit in de modus actief-actief te gebruiken. Als u de verbindingen in de modus actief-actief laat werken, wordt het verkeer in het Microsoft-netwerk per stroom verdeeld over de verbindingen.
Bij het uitvoeren van de primaire en secundaire verbindingen van een ExpressRoute-circuit in de actief-passieve modus bestaat het risico dat beide verbindingen mislukken na een fout in het actieve pad. De meest voorkomende oorzaken voor storingen bij het overschakelen zijn een gebrek aan actief beheer van de passieve verbinding en passieve verbindingen die verouderde routes adverteren.
Als u de primaire en secundaire verbindingen van een ExpressRoute-circuit in de modus Actief-actief gebruikt, resulteert dit er ook in dat slechts de helft van de stromen mislukt en opnieuw wordt gerouteerd na een ExpressRoute-verbindingsfout. De modus actief-actief helpt dus aanzienlijk bij het verbeteren van de Gemiddelde tijd om te herstellen (MTTR).
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 een AS-pad dat vooraf gaat om verkeer over te brengen naar een goede verbinding. U moet ervoor zorgen dat het verkeer kan worden gerouteerd via het pad dat in orde is wanneer de padvoorbereiding is geconfigureerd vanuit Microsoft en de vereiste route-aankondigingen 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 in het klant- of partnernetwerk voordat ze communiceren via Microsoft-peering. Ervan uitgaande dat u zowel de primaire als secundaire verbindingen in de modus actief-actief gebruikt, waarbij en hoe uw NAT invloed heeft 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 secundaire apparaten. Het retourverkeer komt aan op hetzelfde edge-apparaat waarmee de stroom is uitgegaan.
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 het venster. 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 gemeenschappelijke 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 gemeenschappelijke NAT-pool voordat het verkeer wordt gesplitst, niet betekent dat er een single point of failure wordt veroorzaakt, wat betekent dat de hoge beschikbaarheid in gevaar komt.
De NAT-pool is zelfs bereikbaar nadat de primaire of secundaire verbinding is mislukt. Daarom kan de netwerklaag zelf de pakketten omleiden en sneller herstellen na een storing.
Notitie
- Als u NAT-optie 1 (onafhankelijke NAT-pools voor primaire en secundaire ExpressRoute-verbindingen) gebruikt en een poort van een IP-adres uit een van de NAT-pool toekent 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 veroorzaken met failover tijdens gepland of ongepland onderhoud door Microsoft of uw ExpressRoute-provider. U moet uw set-up testen om ervoor te zorgen dat uw verkeer een goede failover zal uitvoeren en, indien mogelijk, BGP-sessies op staatloze apparaten te beëindigen.
Functies voor persoonlijke peering afstemmen
In deze sectie bekijken we optionele functies (afhankelijk van uw Azure-implementatie en hoe gevoelig u bent voor MTTR) om de hoge beschikbaarheid van uw ExpressRoute-circuit te verbeteren. Laten we met name de zonebewuste implementatie van virtuele ExpressRoute-netwerkgateways en Bidirectional Forwarding Detection (BFD) bekijken.
Beschikbaarheidszonebewuste virtuele ExpressRoute-netwerkgateways
Een beschikbaarheidszone in een Azure-regio is een combinatie van een foutdomein en een updatedomein. Als u kiest voor zone-redundante Azure IaaS-implementatie, kunt u ook zone-redundante virtuele netwerkgateways configureren die persoonlijke ExpressRoute-peering beëindigen. Zie Over zone-redundante virtuele netwerkgateways inAzure-beschikbaarheidszones. Zie Een zone-redundante virtuele netwerkgateway maken in Azure-beschikbaarheidszones om een zone-redundante virtuele netwerkgateway te Azure-beschikbaarheidszones.
Foutdetectietijd verbeteren
ExpressRoute ondersteunt BFD via privé-peering. BFD vermindert de detectietijd van fouten via het Layer 2-netwerk tussen Microsoft Enterprise Edge (MSEE's) en hun BGP-buren aan de on-premises zijde van ongeveer 3 minuten (standaard) tot minder dan een seconde. Snelle detectietijd van fouten helpt het herstel van fouten te bevorderen. 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-circuit-peeringpunt is vastgemaakt aan een geografische locatie en kan daarom worden beïnvloed door een onherstelbare fout die van invloed is op de hele locatie.
Zie Ontwerpen voor herstel na noodherstel met ExpressRoute-privé-peeringvoor ontwerpoverwegingen voor het bouwen van geografisch redundante netwerkconnectiviteit met Microsoft-backbone die bestand is tegen onherstelbare storingen, die invloed hebben op een hele regio.