Partager via

Mise en réseau à plusieurs régions avec le serveur de routes Azure

  • Article

Les applications avec des exigences élevées de haute disponibilité ou de récupération d’urgence nécessitent souvent un déploiement dans plusieurs régions Azure. Dans ce cas, les réseaux virtuels (VNet) spoke dans différentes régions doivent communiquer entre eux. Une façon d’activer cette communication consiste à appairer tous les réseaux virtuels (VNet) spoke requis entre eux. Toutefois, cette approche contourne toutes les appliances virtuelles réseau (NVA) centrales, telles que les pare-feu dans les hubs. Une autre solution consiste à utiliser des itinéraires définis par l’utilisateur (UDR) dans les sous-réseaux où les appliances virtuelles réseau hub sont déployées, mais la maintenance des itinéraires définis par l’utilisateur peut s’avérer difficile. Le Serveur de routes Azure offre une solution de remplacement dynamique qui s’adapte automatiquement aux modifications de topologie, sans nécessiter d’intervention manuelle.

Topologie

Le diagramme suivant illustre une architecture à deux régions, dans laquelle une topologie Hub-and-spoke existe dans chaque région, et les réseaux virtuels de hub sont appariés les uns aux autres via le peering mondial de réseaux virtuels :

Diagram showing multi-region design with Azure Route Server.

L’appliance virtuelle réseau de chaque région apprend les préfixes des réseaux virtuels hub-and-spoke locaux via le Serveur de routes Azure, puis les partage avec l’appliance virtuelle réseau dans l’autre région à l’aide du protocole BGP. Pour éviter les boucles de routage, il est essentiel d’établir cette communication entre les appliances virtuelles réseau à l’aide d’une technologie d’encapsulation comme IPsec ou Virtual eXtensible LAN (VXLAN).

Pour permettre au Serveur de routes Azure de publier les préfixes des réseaux virtuels spoke dans les appliances virtuelles réseau locales et de réinjecter les itinéraires appris dans les réseaux virtuels spoke, il est essentiel d’utiliser le paramètre Utiliser la passerelle ou le Serveur de routes du réseau virtuel distant pour le peering entre les réseaux virtuels spoke et le réseau virtuel hub.

Les appliances virtuelles virtuelles publient les itinéraires qu’elles apprennent de la région distante vers leur Serveur de routes local, qui les configure ensuite dans les réseaux virtuels spoke locaux, attirant ainsi le trafic. Dans les cas où plusieurs appliances virtuelles réseau existent dans la même région (le sServeur de routage prend en charge jusqu’à 8 homologues BGP), le préfixe de chemin d’accès AS permet de rendre l’une des appliances virtuelles réseau prioritaire par rapport aux autres, établissant réellement une topologie d’appliance virtuelle réseau active/de secours.

Important

Pour que le Serveur de routes local puisse apprendre les itinéraires publiés par l’appliance virtuelle réseau depuis la région distante, l’appliance virtuelle réseau doit supprimer le numéro de système autonome (ASN) 65515 du chemin d’accès AS des itinéraires. Cette technique est parfois appelée « remplacement AS » ou « réécriture de chemin d'accès AS » dans certaines plateformes BGP. Sinon, le mécanisme de prévention des boucles BGP empêche le Serveur de routes local d’apprendre ces routes, car il interdit l’apprentissage des itinéraires qui contiennent déjà le numéro ASN local.

ExpressRoute

Vous pouvez combiner la conception multirégion avec des passerelles ExpressRoute ou ExpressRouteVPN. Le diagramme suivant illustre une topologie incluant une passerelle ExpressRoute connectée à un réseau local dans l’une des régions Azure. Dans ce cas, un réseau de superposition sur le circuit ExpressRoute permet de simplifier le réseau, de sorte que les préfixes locaux s’affichent uniquement dans Azure comme annoncé par l’appliance virtuelle réseau (et non depuis la passerelle ExpressRoute).

Diagram showing multi-region design with Route Server and ExpressRoute.

Conception sans superposition

Les tunnels inter-régions entre les appliances virtuelles réseau sont nécessaires, car sinon, une boucle de routage est formée. Par exemple, en examinant l’appliance virtuelle réseau dans la région 1 :

  • L’appliance virtuelle réseau de la région 1 apprend les préfixes de la région 2, puis les publie sur le Serveur de routage dans la région 1.
  • Le Serveur de routes de la région 1 injecte des itinéraires pour ces préfixes dans tous les sous-réseaux de la région 1, avec l’appliance virtuelle réseau dans la région 1 comme tronçon suivant.
  • Pour le trafic de la région 1 à la région 2, lorsque l’appliance virtuelle réseau de la région 1 envoie le trafic à l’autre appliance virtuelle réseau, son propre sous-réseau hérite aussi des itinéraires programmés par le serveur de routage, qui pointent vers lui-même (l’appliance virtuelle réseau). Le paquet est donc renvoyé à l’appliance virtuelle réseau et une boucle de routage apparaît.

Si les itinéraires définis par l’utilisateur (UDR) constituent une option, vous pouvez désactiver la propagation d’itinéraires BGP dans les sous-réseaux des appliances virtuelles réseau, puis configurer des itinéraires définis par l’utilisateur statiques au lieu d’une superposition, pour qu’Azure puisse acheminer le trafic vers les réseaux virtuels spoke distants.

Contenu connexe