Conception d’une haute disponibilité avec Azure ExpressRoute

Azure ExpressRoute est conçu pour la haute disponibilité afin de fournir une connectivité de réseau privé de niveau opérateur aux ressources Microsoft. Cela signifie qu’il n’existe aucun point de défaillance unique dans le réseau Microsoft. Pour optimiser la disponibilité, le client et les segments de fournisseur de service de votre circuit Azure ExpressRoute doivent également être conçus pour la haute disponibilité. Cet article couvre les considérations relatives à l’architecture réseau pour la conception d’une connectivité robuste en utilisant Azure ExpressRoute et les fonctionnalités qui améliorent la haute disponibilité de votre circuit Azure ExpressRoute.

Remarque

Les concepts décrits dans cet article s’appliquent de la même manière, qu’un circuit Azure ExpressRoute soit créé sous Virtual WAN ou à l’extérieur de celui-ci.

Considérations relatives à l’architecture

Le schéma suivant montre la méthode de connexion recommandée en utilisant un circuit Azure ExpressRoute pour optimiser la disponibilité.

Pour la haute disponibilité, il est primordial de maintenir la redondance dans le réseau de bout en bout. Cela implique de maintenir la redondance au sein de votre réseau local et de ne pas compromettre la redondance au sein de votre fournisseur de services. Il s’agit, au minimum, d’éviter les points de défaillance uniques de réseau. Vous pouvez encore améliorer la haute disponibilité en disposant d’une alimentation et d’un refroidissement redondants pour vos appareils réseau.

Considérations relatives à la conception de couche physique pour le premier mile

Si vous arrêtez les connexions primaire et secondaire d’un circuit Azure ExpressRoute sur le même Équipement dans les locaux du client (CPE), vous compromettez la haute disponibilité au sein de votre réseau local. De plus, si vous configurez les deux connexions en utilisant le même port d’un CPE, vous forcez le partenaire à compromettre la haute disponibilité dans son segment de réseau. Cet événement peut se produire en arrêtant les deux connexions sous des sous-interfaces différentes ou en fusionnant les deux connexions au sein du réseau partenaire, comme illustré ci-dessous.

L’arrêt des connexions primaire et secondaire d’un circuit Azure ExpressRoute dans des emplacement géographiques différents peut compromettre les performances du réseau. Si le trafic est activement équilibré sur la charge des connexions arrêtées dans divers emplacements, des différences importantes de latence réseau entre les deux chemins d’accès peuvent entraîner des performances sous-optimales.

Pour découvrir les considérations relatives à la conception géoredondante, consultez Conception pour une reprise d’activité avec Azure ExpressRoute.

Connexions entre deux passerelles actives

Le réseau Microsoft opère les connexions primaires et secondaires des circuits Azure ExpressRoute en mode actif/actif. Toutefois, vous pouvez forcer les connexions redondantes pour un fonctionnement en mode actif-passif via vos publications de route. La publication de routes plus spécifiques et l’ajout du chemin du système autonome BGP sont des techniques courantes pour utiliser un chemin d’accès de préférence à un autre.

Pour améliorer la haute disponibilité, il est recommandé d’utiliser les deux connexions en mode actif/actif. Cela permet au réseau de Microsoft d’équilibrer la charge de trafic sur les connexions en fonction du flux.

L’exécution de connexions en mode actif/passif entraîne un risque d’échec des deux connexions en cas de défaillance du chemin d’accès actif. Les causes courantes d’échec incluent le manque de gestion active de la connexion passive et les routes obsolètes de publication de connexion passive.

Aussi, l’exécution des connexions en mode actif/actif entraîne l’échec et le reroutage d’environ la moitié des flux, ce qui améliore considérablement le Temps moyen de récupération (MTTR).

Remarque

Au cours d’une maintenance ou d’événements non planifiés affectant une connexion, Microsoft préfère utiliser l’ajout d’un chemin d’accès au système autonome pour purger le trafic vers la connexion saine. Vérifiez que le trafic peut router par le chemin d’accès sain lorsque l’ajout de chemin d’accès est configuré par Microsoft et que les publications de routes requises sont définies de manière appropriée afin d'éviter toute interruption de service.

NAT pour le peering Microsoft

Le Peering Microsoft est conçu pour la communication entre les points de terminaison publics. Les points de terminaison privés locaux deviennent généralement des NAT avec des IP publiques sur le réseau du client ou du partenaire avant qu’ils ne communiquent sur le Peering Microsoft. L’utilisation des connexions primaire et secondaire dans une configuration actif/actif affecte la vitesse à laquelle vous récupérez après un échec dans l’une des connexions. Deux options NAT différentes sont illustrées ci-dessous :

Option 1 :

NAT est appliqué après un fractionnement du trafic entre les connexions primaire et secondaire. Des pools NAT indépendants sont utilisés pour les appareils primaires et secondaires afin de répondre aux exigences NAT avec état. Le trafic de retour arrive sur le même appareil en périphérie par lequel le flux est sorti.

En cas d’échec d’une connexion Azure ExpressRoute, le pool NAT correspondant devient inaccessible, ce qui arrête ainsi tous les flux réseau. Ces flux doivent être rétablis par TCP ou la couche d’application après le délai d’expiration de la fenêtre. Pendant l’échec, Azure ne pourra pas atteindre les serveurs locaux en utilisant le NAT correspondant tant que la connectivité n’aura pas été restaurée.

Option 2 :

Un pool NAT commun est utilisé avant le fractionnement du trafic entre les connexions primaire et secondaire. Cette opération n’introduit pas de point de défaillance unique, ce qui maintient ainsi une haute disponibilité.

Le pool NAT reste accessible même si la connexion primaire ou secondaire échoue et permet à la couche réseau de router à nouveau les paquets et de récupérer plus rapidement.

Remarque

• Si vous utilisez l’option 1 NAT (des pools NAT indépendants pour les connexions primaire et secondaire), et que vous routez un port d’adresse IP de l’un des pools NAT vers un serveur local, le serveur n’est plus accessible via le circuit Azure ExpressRoute en cas d’échec de la connexion correspondante.
• L’arrêt des connexions BGP Azure ExpressRoute sur les appareils avec état peut entraîner des problèmes de basculement pendant les maintenances planifiées ou non planifiées par Microsoft ou votre fournisseur Azure ExpressRoute. Testez votre configuration pour veiller à un basculement approprié et, quand cela est possible, arrêter les sessions BGP sur les appareils sans état.

Réglage des fonctionnalités du peering privé

Cette section passe en revue les fonctionnalités facultatives qui permettent d’améliorer la haute disponibilité de votre circuit Azure ExpressRoute en fonction de votre déploiement Azure et de la sensibilité à MTTR. Plus précisément, elle couvre le déploiement tenant compte de la zone des passerelles de réseau virtuel Azure ExpressRoute et la détection de transfert bidirectionnel (BFD).

Passerelles de réseau virtuel Azure ExpressRoute tenant compte de la zone de disponibilité

Une zone de disponibilité au sein d’une région Azure combine un domaine d’erreur et un domaine de mise à jour. Pour obtenir la résilience et la disponibilité les plus élevées, configurez une passerelle de réseau virtuel Azure ExpressRoute redondante interzone. Pour découvrir plus d’informations, consultez À propos des passerelles de réseau virtuel redondantes interzone dans les Zones de disponibilité Azure. Pour configurer une passerelle de réseau virtuel redondante interzone, consultez Créer une passerelle de réseau virtuel redondante interzone dans les zones de disponibilité Azure.

Amélioration du temps de détection des défaillances

Azure ExpressRoute prend en charge BFD sur un Peering privé, ce qui réduit le temps de détection des défaillances sur le réseau de couche 2 entre Microsoft Enterprise Edge (MSEE) et leurs voisins BGP côté local d’environ 3 minutes à moins d’une seconde. La détection rapide d’échec permet d’accélérer la récupération. Pour découvrir plus d’informations, voir Configurer BFD sur Azure ExpressRoute.

Étapes suivantes

Cet article a abordé la conception pour la haute disponibilité d’un circuit Azure ExpressRoute. Un point de Peering de circuit Azure ExpressRoute est épinglé à un emplacement géographique et peut être affecté par des défaillances graves impactant l’emplacement complet.

Pour découvrir les considérations relatives à la conception de connectivité réseau géoredondante sur le réseau principal de Microsoft qui peut résister à des défaillances catastrophiques impactant une région entière, consultez Conception d’une récupération d’urgence avec le Peering privé Azure ExpressRoute.