Routage anycast avec le Serveur de routes Azure
Vous pouvez déployer votre application entre des zones de disponibilité d’une même région Azure pour obtenir une plus grande disponibilité, il se peut que vous deviez déployer vos applications, soit pour obtenir une résilience accrue, de meilleures performances pour les utilisateurs du monde entier, soit pour permettre une meilleure continuité des activités. Il existe différentes approches qui peuvent être suivies pour diriger les utilisateurs vers l’un des emplacements où une application multi-régions est déployée : des approches basées sur DNS, telles qu’Azure Traffic Manager, des services basés sur le routage tels qu’Azure Front Door ou l’équilibreur de charge inter-régions Azure.
Les services Azure précédents sont recommandés pour permettre aux utilisateurs d’accéder à l’emplacement d’application optimal sur l’Internet public à l’aide de l’adressage IP public, mais ils ne prennent pas en charge les réseaux privés et les adresses IP. Cet article explore l’utilisation d’une approche basée sur les routes (anycast IP) pour fournir des déploiements d’applications en réseau privé et multi-régions.
L’IP anycast consiste essentiellement à publier exactement la même adresse IP à partir de plusieurs emplacements, afin que les paquets des utilisateurs de l’application soient routés vers la région la plus proche (en termes de routage). Le fait de disposer d’une accessibilité multi-régions sur anycast offre des avantages par rapport aux approches basées sur DNS, comme le fait de ne pas avoir à s’appuyer sur les clients qui ne mettent pas en cache leurs réponses DNS et de ne pas nécessiter la modification de la conception DNS pour l’application.
Topologie
Dans la conception de ce scénario, la même adresse IP est publiée à partir de réseaux virtuels de différentes régions Azure, où des appliances virtuelles réseau publient l’adresse IP de l’application via le Serveur de routes Azure. Le diagramme suivant illustre deux topologies hub-and-spoke simples, chacune dans une région Azure différente. Une appliance virtuelle réseau de chaque région publie la même route (a.b.c.d/32 dans cet exemple) à son serveur de routage Azure local (le préfixe de route ne doit pas chevaucher les réseaux Azure et locaux). Les routes sont propagées davantage vers le réseau local via ExpressRoute. Lorsque les utilisateurs d’applications veulent accéder à l’application à partir d’un emplacement local, l’infrastructure DNS (non couverte par ce document) résout le nom DNS de l’application en adresse IP anycast (a.b.c.d), que les appareils réseau locaux utilisent un routage vers l’une des deux régions.
Le choix de la sélection de la région disponible est entièrement basé sur les attributs de routage. Si les routes des deux régions sont identiques, le réseau local utilise généralement le routage Equal Cost MultiPathing (ECMP) pour envoyer chaque flux d’application à chaque région. Il est également possible de changer les publications générées par chaque NVA dans Azure afin d’enregistrer une des régions comme favorite. Par exemple, l’utilisation du chemin D’accès D’AS BGP est imminente pour établir un chemin déterministe de local à la charge de travail Azure.
Important
Les appliances virtuelles réseau qui publient les routes doivent inclure un mécanisme de contrôle d’intégrité pour arrêter la publication de la route lorsque l’application n’est pas disponible dans leurs régions respectives, afin d’éviter la perte de trafic.
Trafic retour
Lorsque le trafic de l’application à partir du client local arrive à l’une des appliances virtuelles réseau (NVA) dans Azure, la NVA effectue une connexion par proxy inverse ou une traduction d'adresse de réseau de destination (DNAT). Ensuite, il envoie les paquets à l’application réelle, qui réside généralement dans un réseau virtuel spoke appairé au réseau virtuel hub où l’appliance virtuelle réseau est déployée. Le trafic à partir de l’application revient via l’appliance virtuelle réseau, ce qui se produit naturellement si l’appliance virtuelle réseau effectue le proxy inverse de la connexion (ou exécute la traduction d’adresses réseau source en plus de la traduction d’adresses réseau de destination).
Dans le cas contraire, le trafic arrivant à l’application sera toujours issu de l’adresse IP du client local d’origine. Dans ce cas, les paquets peuvent être routés vers l’appliance virtuelle réseau avec des routes définies par l’utilisateur. Une attention particulière doit être prise s’il existe plusieurs instances d’appliances virtuelles réseau dans chaque région, car le trafic peut être asymétrique (le trafic entrant et sortant transitant par différentes instances d’appliances virtuelles réseau). Le trafic asymétrique n’est généralement pas un problème si les appliances virtuelles réseau sont sans état, mais il génère des erreurs si les appliances virtuelles réseau doivent effectuer le suivi des états de connexion, tels que les pare-feu.