Conception pour une reprise d’activité avec le peering privé ExpressRoute
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 des considérations de conception visant à optimiser la disponibilité d’un circuit ExpressRoute, consultez Conception pour une haute disponibilité avec ExpressRoute et Well-Architectured Framework
Toutefois, prenant en considération l’adage populaire de Murphy, selon lequel si quelque chose peut mal tourner, c’est ce qui va arriver, nous nous concentrons dans cet article sur des solutions qui vont au-delà des défaillances qui peuvent être traitées à l’aide d’un simple circuit ExpressRoute. Nous nous intéressons à l’architecture des réseaux du point de vue de la création d’une connectivité réseau back-end robuste favorisant la reprise d’activité à l’aide de circuits ExpressRoute géoredondants.
Remarque
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.
Nécessité d’une solution de connectivité redondante
Certaines situations ou instances peuvent favoriser la dégradation d’emplacements de peering ExpressRoute ou d’un service régional entier. Une catastrophe naturelle peut-être la cause première de ce type d’interruption de service à l’échelle régionale. Il est donc essentiel de prévoir un service de reprise d’activité pour assurer une continuité des activités et préserver les applications stratégiques.
Remarque
Lorsque vous devez implémenter une conception d’un plan de reprise d’activité après sinistre dans une situation qui respecte le temps, par exemple pour maintenir la continuité de l’activité lors d’une catastrophe naturelle, vous devez considérer les facteurs suivants :
- Ce document fournit des conseils sur l’implémentation d’une robuste conception d’un plan de reprise d’activité après sinistre pour plusieurs circuits ExpressRoute configurés à travers plusieurs emplacements de Peering. Ce scénario suppose que vous disposez de suffisamment de temps et de ressources pour configurer les circuits ExpressRoute.
- S’il faut rapidement configurer une conception d’un plan de reprise d’activité après sinistre pour un unique et non-géoredondant circuit ExpressRoute, vous pouvez utiliser les alternatives suivantes :
- Utilisez un VPN site à site comme sauvegarde pour le trafic du Peering privé.
- Utilisez la connectivité Internet comme sauvegarde pour le trafic du Peering Microsoft.
Quoi qu’il en soit, que vous exécutiez vos applications stratégiques dans une région Azure, localement ou n’importe où ailleurs, vous pouvez utiliser une autre région Azure comme site de basculement. Les articles suivants abordent la reprise d’activité du point de vue des applications et de l’accès front-end :
- Reprise d’activité à l’échelle de l’entreprise
- Reprise d’activité des TPE/PME avec Azure Site Recovery
Si vous vous appuyez sur la connectivité ExpressRoute entre votre réseau local et Microsoft, vous devez prendre en compte les éléments suivants pour planifier la reprise d’activité par ExpressRoute :
- Utiliser des circuits ExpressRoute géoredondants
- Utiliser divers réseaux de fournisseur de service pour le circuit ExpressRoute différent
- Concevoir chaque circuit ExpressRoute pour la haute disponibilité
- Terminer le circuit ExpressRoute différent à un emplacement différent sur le réseau du client
- Utilisation de Passerelles de réseau virtuel ExpressRoute tenant compte de la zone de disponibilité
Défis liés à l’utilisation de plusieurs circuits ExpressRoute
Quand vous interconnectez le même ensemble de réseaux à l’aide de plusieurs connexions, vous introduisez des chemins parallèles entre les réseaux. Quand ils ne sont pas correctement conçus, les chemins parallèles peuvent engendrer un routage asymétrique. Si le chemin comporte des entités avec état (par exemple, NAT ou pare-feu), le routage asymétrique risque de bloquer le flux de trafic. En règle générale, sur le chemin de Peering privé ExpressRoute, vous ne rencontrez pas d’entités avec état, telles que NAT ou un pare-feu. Ainsi, le routage asymétrique sur le Peering privé ExpressRoute ne bloque pas nécessairement le flux de trafic.
Toutefois, si vous équilibrez la charge du trafic entre des chemins parallèles géoredondants, qu’il existe ou non des entités avec état, vous pouvez observer des performances réseau incohérentes. Ces chemins parallèles géoredondants peuvent être via le même métro ou le même métro que sur la page fournisseurs par emplacement.
Redondance avec des circuits ExpressRoute dans le même métro
De nombreux métros ont deux emplacements ExpressRoute. Par exemple, Amsterdam et Amsterdam2. Lors de la conception de la redondance, vous pouvez créer deux chemins d’accès parallèles à Azure avec les deux emplacements dans le même métro. Vous pouvez le faire avec le même fournisseur ou choisir de travailler avec un autre fournisseur de services pour améliorer la résilience. Un autre avantage de cette conception réside dans le fait que lorsque le basculement d’application se produit, une latence de bout en bout entre vos applications locales et Microsoft reste approximativement la même. Toutefois, en cas de catastrophe naturelle comme un tremblement de terre, la connectivité des deux chemins peut ne plus être disponible.
Redondance avec des circuits ExpressRoute dans des métros différents
Lorsque vous utilisez différents métros pour la redondance, vous devez sélectionner l’emplacement secondaire dans la même région géopolitique. Pour choisir un emplacement en dehors de la région géopolitique, vous devez utiliser la référence SKU Premium pour les deux circuits dans les chemins parallèles. L’avantage de cette configuration est que les chances d’une catastrophe naturelle entraînant une panne des deux liens sont inférieures, mais au détriment de la latence accrue de bout en bout.
Notes
L’activation de BFD sur les circuits ExpressRoute permet une détection plus rapide de la défaillance des liaisons entre les appareils Microsoft Enterprise Edge (MSEE) et les routeurs clients/de périphérie partenaire. Toutefois, le basculement global et la convergence vers un site redondant peuvent prendre jusqu’à 180 secondes dans certaines conditions d’échec et vous pouvez rencontrer une dégradation accrue des performances ou de la latence pendant ce temps.
Dans cet article, nous allons aborder la façon de résoudre les problèmes que vous pouvez rencontrer lors de la configuration de chemins géoredondants.
Considérations relatives aux réseaux locaux petits ou moyens
Penchons-nous sur l’exemple de réseau illustré dans le diagramme suivant. Dans l’exemple, une connectivité ExpressRoute géoredondante est établie entre un emplacement local de Contoso et un réseau virtuel de Contoso dans une région Azure. Dans le diagramme, la ligne bleue pleine indique le chemin privilégié (via ExpressRoute 1), tandis que la ligne en pointillés représente le chemin de secours (via ExpressRoute 2).
Par défaut, si vous publiez des routes identiques sur tous les chemins ExpressRoute, Azure équilibre la charge liée au trafic local entre tous les chemins ExpressRoute à l’aide du routage multichemin à coût égal (ECMP).
Toutefois, avec les circuits ExpressRoute géoredondants, nous devons tenir compte de la différence des performances réseau d’un chemin réseau à l’autre (en particulier du point de vue de la latence du réseau). Pour obtenir des performances réseau plus cohérentes pendant un fonctionnement normal, vous pouvez préférer le circuit ExpressRoute qui offre la latence minimale.
Vous pouvez influer sur Azure afin qu’il préfère un circuit ExpressRoute à un autre en utilisant l’une des techniques suivantes (listées par ordre d’efficacité) :
- Publier un itinéraire plus spécifique via le circuit ExpressRoute préféré par rapport aux autres circuits ExpressRoute
- Configurer une pondération de connexion supérieure sur la connexion qui relie le réseau virtuel au circuit ExpressRoute préféré
- Publier les routes via un circuit ExpressRoute moins préféré avec un chemin AS plus long (ajout au chemin AS)
Route plus spécifique
Le diagramme suivant montre comment influer sur la sélection d’un chemin ExpressRoute à l’aide d’une publication de route plus spécifique. Dans l’exemple illustré, la plage d’adresses IP /24 du réseau local Contoso est publiée sous la forme de deux plages d’adresses /25 via le chemin d’accès préféré (ExpressRoute 1) et d’une plage /24 via le chemin de secours (ExpressRoute 2).
/25 étant plus spécifique, par rapport à /24, Azure envoie le trafic destiné à 10.1.11.0/24 via ExpressRoute 1 dans un état normal. Si les deux connexions d’ExpressRoute 1 tombent en panne, le réseau virtuel voit la publication de l’itinéraire 10.1.11.0/24 uniquement via ExpressRoute 2 ; ainsi, le circuit de secours est utilisé dans cet état de défaillance.
Pondération de connexion
La capture d’écran suivante illustre la configuration de la pondération d’une connexion ExpressRoute via le portail Azure.
Le diagramme suivant montre comment influer sur la sélection d’un chemin ExpressRoute à l’aide de la pondération de connexion. La pondération de connexion par défaut est 0. Dans l’exemple suivant, la pondération de connexion pour ExpressRoute 1 est configurée sur la valeur 100. Quand un réseau virtuel reçoit un préfixe d’itinéraire publié par le biais de plusieurs circuits ExpressRoute, il privilégie la connexion ayant la pondération la plus élevée.
Si les deux connexions d’ExpressRoute 1 tombent en panne, le réseau virtuel voit la publication de l’itinéraire 10.1.11.0/24 uniquement via ExpressRoute 2 ; ainsi, le circuit de secours est utilisé dans cet état de défaillance.
Ajout au chemin AS
Le diagramme suivant montre comment influer sur la sélection d’un chemin ExpressRoute à l’aide d’un ajout au chemin AS. Dans le diagramme, la publication des routes via ExpressRoute 1 indique le comportement par défaut du mode eBGP. Sur la publication des routes via ExpressRoute 2, le numéro ASN du réseau local est ajouté au chemin AS de la route. Quand le même itinéraire est reçu via plusieurs circuits ExpressRoute, selon le processus de sélection d’itinéraire eBGP, le réseau virtuel préfère celui ayant le chemin AS le plus court.
Si les deux connexions d’ExpressRoute 1 tombent en panne, le réseau virtuel voit la publication de l’itinéraire 10.1.11.0/24 uniquement via ExpressRoute 2. Ainsi, le chemin AS plus long devient superflu. Le circuit de secours est donc utilisé dans cet état d’échec.
En utilisant l’une ou l’autre des techniques, si vous amenez Azure à préférer un de vos chemins ExpressRoute, vous devez vous assurer que le réseau local préfère également le même chemin ExpressRoute pour le trafic lié à Azure afin d’éviter les flux asymétriques. En règle générale, la valeur de préférence locale est utilisée pour amener le réseau local à préférer un circuit ExpressRoute. La préférence locale est une métrique iBGP (BGP interne). La route BGP ayant la valeur de préférence locale la plus élevée est préférée.
Important
Quand vous utilisez certains circuits ExpressRoute en guise de circuits de secours, vous devez les gérer activement et tester régulièrement l’opération de basculement.
Grand réseau d’entreprise distribué
Quand vous avez un grand réseau d’entreprise distribué, vous êtes susceptible d’avoir plusieurs circuits ExpressRoute. Dans cette section, nous allons voir comment concevoir la reprise d’activité à l’aide de circuits ExpressRoute en mode actif-actif, sans avoir besoin d’autres circuits de secours.
Penchons-nous sur l’exemple illustré dans le diagramme suivant. Dans l’exemple, Contoso dispose de deux emplacements locaux connectés à deux déploiements IaaS Contoso dans deux régions Azure différentes via des circuits ExpressRoute dans deux emplacements de peering différents.
La façon dont nous architecturons la reprise d’activité a un impact sur la façon dont est routé le trafic depuis les régions vers les emplacements (région 1/région 2 vers emplacement 2/emplacement1). Prenons l’exemple de deux architectures de reprise qui routent différemment le trafic depuis les régions vers les emplacements.
Scénario 1
Dans le premier scénario, nous concevons la reprise d’activité afin que tout le trafic entre une région Azure et un réseau local emprunte le circuit ExpressRoute local dans l’état stable. Si le circuit ExpressRoute local échoue, le circuit ExpressRoute distant est utilisé pour tous les flux de trafic entre Azure et le réseau local.
Le scénario 1 est illustré dans le diagramme suivant. Dans le diagramme, les lignes vertes indiquent les chemins pour le flux de trafic entre les réseaux VNet1 et locaux. Les lignes bleues indiquent les chemins pour le flux de trafic entre les réseaux VNet2 et locaux. Les lignes pleines indiquent le chemin souhaité dans l’état stable, tandis que les lignes en pointillés indiquent le chemin du trafic en cas de défaillance du circuit ExpressRoute correspondant par lequel transite le flux de trafic dans l’état stable.
Vous pouvez concevoir le scénario au moyen de la pondération de connexion afin que les réseaux virtuels préfèrent la connexion au circuit ExpressRoute de l’emplacement de peering local pour le trafic lié au réseau local. Pour compléter la solution, vous devez garantir un flux de trafic inverse symétrique. Vous pouvez utiliser la préférence locale sur la session iBGP entre vos routeurs BGP (sur lesquels les circuits ExpressRoute sont terminés du côté local) pour préférer un circuit ExpressRoute. La solution est illustrée dans le diagramme suivant.
Scénario 2
Le scénario 2 est illustré dans le diagramme suivant. Dans le diagramme, les lignes vertes indiquent les chemins pour le flux de trafic entre les réseaux VNet1 et locaux. Les lignes bleues indiquent les chemins pour le flux de trafic entre les réseaux VNet2 et locaux. Dans l’état stable (lignes pleines dans le diagramme), tout le trafic entre les réseaux virtuels et les emplacements locaux emprunte normalement l’infrastructure Microsoft dorsale, et ne transite par l’interconnexion entre les emplacements locaux que si un circuit ExpressRoute se trouve en état d’échec (lignes en pointillés dans le diagramme).
La solution est illustrée dans le diagramme suivant. Comme illustré, vous pouvez concevoir le scénario en utilisant un itinéraire plus spécifique (option 1) ou l’ajout au chemin AS (option 2) pour influer sur la sélection du chemin pour les réseaux virtuels. Pour influer sur la sélection des routes des réseaux locaux pour le trafic lié à Azure, vous devez configurer l’interconnexion entre l’emplacement local comme étant moins préférable. La façon dont vous configurez le lien d’interconnexion comme étant préférable varie selon le protocole de routage utilisé au sein du réseau local. Vous pouvez utiliser la préférence locale avec iBGP ou une métrique avec IGP (OSPF ou IS-IS).
Important
Lorsqu’un ou plusieurs circuits ExpressRoute sont connectés à plusieurs réseaux virtuels, le trafic de réseau virtuel à réseau virtuel peut être acheminé via ExpressRoute. Cela n’est cependant pas recommandé. Pour activer la connectivité de réseau virtuel à réseau virtuel, configurez l’appairage de réseaux virtuels.
Étapes suivantes
Dans cet article, nous avons abordé la conception de la reprise d’activité d’une connectivité de peering privé dans les circuits ExpressRoute. Les articles suivants abordent la reprise d’activité du point de vue des applications et de l’accès front-end :