Partager via

Conception pour une haute disponibilité avec ExpressRoute

  • Article

ExpressRoute est conçu pour la haute disponibilité afin de fournir à l’opérateur une connectivité de réseau privé de qualité aux ressources Microsoft. En d’autres termes, il n’existe aucun point de défaillance unique dans le chemin d’accès ExpressRoute au sein du réseau Microsoft. Pour optimiser la disponibilité, le client et le segment de fournisseur de service de votre circuit ExpressRoute doivent également être conçus pour la haute disponibilité. Dans cet article, nous allons tout d’abord passer en revue les considérations relatives à l’architecture réseau pour la conception d’une connectivité réseau robuste à l’aide d’ExpressRoute. Nous analyserons ensuite les fonctionnalités qui vous aident à améliorer la haute disponibilité de votre circuit ExpressRoute.

Notes

Les concepts décrits dans cet article s’appliquent tout autant lorsqu’un circuit ExpressRoute est 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 à l’aide d’un circuit ExpressRoute afin d’optimiser la disponibilité d’un circuit ExpressRoute.

1

Pour une haute disponibilité, il est primordial de maintenir la redondance du circuit ExpressRoute dans le réseau de bout en bout. En d’autres termes, vous devez conserver la redondance au sein de votre réseau local et ne devez pas la compromettre au sein de votre réseau de fournisseur de service. Pour conserver la redondance à son minimum, il faut éviter des points de défaillance réseau uniques. Vous pouvez davantage 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 primaires et secondaires d’un circuit ExpressRoute sur le même Customer Premises Equipment (CPE), vous compromettez la haute disponibilité au sein de votre réseau local. De plus, si vous configurez les connexions primaires et secondaires en utilisant le même port d’un CPE, vous forcez le partenaire à avoir une forte disponibilité dans son segment de réseau également. Cet événement peut se produire en mettant fin aux deux connexions sous des sous-interfaces différentes ou en fusionnant les deux connexions au sein du réseau partenaire. C’est ce qu’illustre le diagramme suivant.

2

En revanche, si vous arrêtez les connexions primaires et secondaires d’un circuit ExpressRoute dans différents emplacements géographiques, il se peut que vous compromettiez les performances réseau de la connectivité. Si le trafic est activement équilibré entre les connexions primaires et secondaires arrêtées dans différents emplacements géographiques, une différence potentielle considérable dans la latence du réseau entre les deux chemins entraînerait des sous-performances réseau.

Pour des considérations relatives à la conception de la géoredondance, consultez Conception pour une reprise d’activité après sinistre.

Connexions entre deux passerelles actives

Le réseau Microsoft est configuré pour opérer les connexions primaires et secondaires des circuits ExpressRoute en mode actif/actif. Toutefois, par vos annonces de routes, vous pouvez forcer les connexions redondantes d’un circuit ExpressRoute à opérer en mode actif/passif. L’annonce de routes plus spécifiques et l’ajout du chemin du système autonome BGP sont des techniques courantes utilisées pour préférer un chemin à un autre.

Pour améliorer la haute disponibilité, il est recommandé d’opérer les deux connexions d’un circuit ExpressRoute en mode actif/actif. Si vous autorisez les connexions à opérer en mode actif/actif, le réseau Microsoft équilibre les charges du trafic sur les connexions selon le flux.

L’exécution des connexions primaires et secondaires d’un circuit ExpressRoute en mode actif/passif risque de causer l’échec des deux connexions, après un autre échec dans le chemin actif. Les causes courantes d’échec sur le basculement sont le manque de gestion active de la connexion passive et les itinéraires obsolètes d’annonces de connexions passives.

Aussi, l’exécution des connexions primaires et secondaires d’un circuit ExpressRoute en mode actif/actif entraîne l’échec et le reroutage d’environ la moitié des flux. Par conséquent, une connexion active-active permet d’améliorer considérablement le temps moyen de récupération (MTTR).

Notes

Au cours d’une activité de maintenance ou en cas d’événements non planifiés ayant un impact sur l’une de ces connexions, Microsoft préfère utiliser l’ajout d’un préfixe au chemin AS pour purger le trafic vers la connexion saine. Vous devez vérifier que le trafic peut être acheminé sur le chemin sain quand l’ajout d’un préfixe au chemin est configuré par Microsoft et que les publications d’itinéraires nécessaires sont configurées de manière appropriée pour éviter toute interruption de service.

NAT pour le peering Microsoft

Le peering Microsoft est conçue pour la communication entre les points de terminaison publics. Souvent, les points de terminaison privés locaux deviennent des NAT avec une IP publique sur le réseau du client ou du partenaire avant qu’ils ne communiquent via le peering Microsoft. En supposant que vous utilisez les connexions primaire et secondaire dans une configuration active-active. Où et comment votre NAT prend effet sur à quelle vitesse vous récupérez après un échec dans une des connexions ExpressRoute. Deux options NAT sont illustrées dans la figure suivante :

3

Option 1 :

La traduction d’adresses réseau (NAT) est appliquée après avoir fractionné le trafic entre les connexions primaires et secondaires du circuit ExpressRoute. Pour répondre aux exigences avec état de la NAT, des pools NAT indépendants sont utilisés pour les appareils primaires et secondaires. Le trafic de retour arrive sur le même périphérique par lequel le flux est sorti.

Si la connexion ExpressRoute échoue, la capacité à atteindre le pool NAT correspondant est alors interrompue. C’est pourquoi tous les flux réseau interrompus doivent être rétablis soit par TCP, soit par la couche Application après le délai d’attente de la fenêtre correspondante. Pendant la défaillance, Azure ne peut pas atteindre les serveurs locaux à l’aide de la NAT correspondante jusqu’à ce que la connectivité soit restaurée pour les connexions primaires ou secondaires du circuit ExpressRoute.

Option n°2 :

Un pool NAT commun est utilisé avant de fractionner le trafic entre les connexions primaires et secondaires du circuit ExpressRoute. Il est important de préciser que l’utilisation d’un pool NAT commun avant fractionnement du trafic ne signifie pas qu’il y a un point de défaillance unique, ce qui compromettrait la haute disponibilité.

Le pool NAT est accessible même si la connexion primaire ou secondaire échoue. La couche réseau peut donc réacheminer elle-même les paquets et accélérer la récupération après une défaillance.

Notes

  • Si vous utilisez l’option NAT 1 (des pools NAT indépendants pour les connexions ExpressRoute primaires et secondaires), et que vous mappez un port d’une adresse IP d’un des pools NAT à un serveur local, le serveur n’est plus accessible via le circuit ExpressRoute en cas d’échec de la connexion correspondante.
  • Mettre fin à des connexions BGP 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 ExpressRoute. Vous devez tester votre configuration pour vérifier que votre trafic basculera correctement et, quand cela est possible, arrêter les sessions BGP sur les appareils sans état.

Réglage des fonctionnalités du peering privé

Dans cette section, nous allons passer en revue des fonctionnalités facultatives (selon votre déploiement Azure et votre susceptibilité au temps de récupération moyen) qui visent à améliorer la haute disponibilité de votre circuit ExpressRoute. Plus précisément, nous allons voir un déploiement de passerelles de réseau virtuel ExpressRoute tenant compte de la zone, et la détection d’envoi bidirectionnel (BFD).

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

Une zone de disponibilité dans une région Azure est une combinaison d’un domaine d’erreur et d’un domaine de mise à jour. Pour obtenir la résilience et la disponibilité les plus élevées, vous devez configurer une passerelle de réseau virtuel ExpressRoute redondante interzone. Pour en savoir plus, 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

ExpressRoute prend en charge la détection d’envoi bidirectionnel via le peering privé. La détection d’envoi bidirectionnel 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 en local de 3 minutes environ à moins d’une seconde. Un temps de détection des défaillances plus rapide aide à accélérer la récupération. Pour en savoir plus, consultez Configurer la détection d’envoi bidirectionnel sur ExpressRoute.

Étapes suivantes

Dans cet article, nous avons abordé la conception pour la haute disponibilité d’une connectivité de circuit ExpressRoute. Un point de peering du circuit ExpressRoute est épinglé à un emplacement géographique et par conséquent, peut être affecté par une défaillance grave affectant l’emplacement complet.

Pour des considérations relatives à la conception de connectivité de réseau géo-redondante de la dorsale principale de Microsoft qui peut résister à des défaillances catastrophiques, impactant une région entière, consultez Conception d’une récupération après sinistre avec le peering privé ExpressRoute.