Partager via

Routage anycast avec le Serveur de routes Azure

Le routage Anycast vous permet de publier la même adresse IP à partir de plusieurs régions Azure, ce qui offre une meilleure disponibilité des applications, des performances et une résilience. Avec Azure Route Server, vous pouvez implémenter un routage anycast pour diriger automatiquement le trafic vers l’instance d’application la plus proche ou la plus optimale en fonction des métriques de routage.

Cet article explique comment implémenter le routage anycast avec Azure Route Server pour les déploiements d’applications multirégions sur des réseaux privés.

Qu’est-ce que le routage anycast ?

Le routage Anycast est une méthodologie d’adressage et de routage réseau où la même adresse IP est affectée à plusieurs serveurs ou instances d’application à différents emplacements. Lorsqu’un client envoie une requête à une adresse IP anycast, l’infrastructure réseau achemine automatiquement le trafic vers le serveur le plus proche ou le plus optimal en fonction des protocoles de routage et des métriques.

Avantages du routage anycast

Le routage Anycast offre plusieurs avantages pour les déploiements multirégions :

  • Amélioration des performances : le trafic est automatiquement routé vers l’instance d’application la plus proche, ce qui réduit la latence
  • Disponibilité améliorée : si une région devient indisponible, le trafic bascule automatiquement vers d’autres régions
  • Distribution de charge : le trafic peut être distribué dans plusieurs régions en fonction des métriques de routage
  • Configuration simplifiée du client : les clients se connectent à une seule adresse IP, quel que soit l’emplacement du serveur réel
  • Prise en charge du réseau privé : contrairement aux solutions DNS, anycast fonctionne avec des adresses IP privées et des réseaux

Anycast et autres approches multirégions

Bien qu’Azure offre plusieurs services pour les déploiements multirégions tels qu’Azure Traffic Manager, Azure Front Door et Azure Cross-Region Load Balancer, ces services sont conçus pour le trafic Internet public et l’adressage IP public.

Le routage Anycast avec Azure Route Server est conçu pour :

  • Scénarios de réseau privé : applications nécessitant une adressage IP privée
  • Connectivité hybride : scénarios impliquant des connexions ExpressRoute ou VPN à des réseaux locaux
  • Gestion du trafic basée sur le routage : où la mise en cache DNS ou le comportement du client peut interférer avec les solutions DNS

Implémentation anycast avec Azure Route Server

Azure Route Server active le routage anycast en facilitant la publication d’itinéraires identiques de plusieurs régions Azure vers des réseaux locaux via ExpressRoute ou des connexions VPN.

Vue d’ensemble de l’architecture

L’implémentation anycast utilise les composants suivants :

  • Plusieurs régions Azure : chaque région héberge une instance de votre application
  • Serveur de routage Azure : déployé dans chaque région pour gérer les publicités de routage
  • Appliances virtuelles réseau (NVA) : publiez l’adresse IP anycast dans chaque région
  • Topologie hub-and-spoke : fournit une connectivité entre le NVA (appliance virtuelle réseau) et les instances d’application
  • ExpressRoute ou VPN : connecte des régions Azure à des réseaux locaux

Topologie d’implémentation

Le diagramme suivant illustre une implémentation anycast classique avec deux régions Azure. Chaque région contient :

  • Un réseau virtuel hub avec une appliance virtuelle de réseau (NVA) et un serveur de routes Azure
  • Un réseau virtuel spoke hébergeant l’instance d’application
  • Connectivité ExpressRoute aux réseaux locaux

Diagramme montrant l’implémentation de routage anycast avec Azure Route Server entre deux régions, montrant comment la même adresse IP est annoncée à partir de plusieurs emplacements.

Fonctionnement du routage anycast

  1. Annonce de routage : les appliances réseau virtuelles de chaque région annoncent le même préfixe d’adresse IP (par exemple a.b.c.d/32) sur leur serveur de routage Azure local
  2. Propagation de l’itinéraire : Azure Route Server propage ces itinéraires vers des réseaux locaux par le biais de connexions ExpressRoute ou VPN
  3. Sélection de routage : les protocoles de routage locaux sélectionnent le meilleur chemin d’accès pour atteindre l’adresse IP anycast en fonction des métriques de routage
  4. Distribution du trafic : le trafic client est automatiquement acheminé vers la région optimale en fonction du chemin sélectionné

Sélection des itinéraires et équilibrage de charge

La sélection de la région qui reçoit le trafic dépend des attributs de routage :

  • Multi-chemin d’accès à coût égal (ECMP) : lorsque les itinéraires de plusieurs régions ont des métriques identiques, le trafic est distribué uniformément sur tous les chemins disponibles
  • Préférences de chemin BGP : vous pouvez influencer les décisions de routage en ajustant les attributs BGP tels que la longueur du chemin AS, la préférence locale ou les valeurs MED
  • Chemin AS prédéfini : allonger artificiellement le chemin d’accès AS pour des itinéraires spécifiques afin de les rendre moins préférés, en créant un scénario principal/de sauvegarde

Important

Les appliances virtuelles de réseau doivent implémenter des mécanismes de vérification d’intégrité pour arrêter les routes de publicité lorsque l’instance d’application locale devient indisponible. Cela empêche le routage du trafic vers des instances ayant échoué (blackholing).

Considérations relatives au trafic de retour

La gestion appropriée du trafic de retour est essentielle pour les implémentations réussies de anycast. La méthode dépend de la façon dont le NVA traite le trafic entrant.

Méthodes de traitement du trafic

  • Le mode de proxy inverse assure le flux de trafic le plus prévisible lorsque l'appliance réseau virtuelle fonctionne en tant que proxy inverse. Dans cette configuration, l'appliance réseau virtuelle (NVA) met fin à la connexion initiale du client et établit une nouvelle connexion à l'instance de l'application. Le trafic de retour revient naturellement via la même NVA, car la NVA gère les deux côtés de la connexion.

  • Le mode traduction d’adresses réseau (NAT) requiert des considérations différentes lorsque le NVA effectue la traduction d’adresses réseau de destination (DNAT). Le NVA traduit l'adresse IP de destination de l'adresse IP anycast à l'adresse IP réelle de l'application. Si l’appliance virtuelle réseau effectue également une traduction d'adresse de source (SNAT), le trafic de retour passera par la même appliance. Toutefois, si aucune SNAT n’est effectuée, une configuration supplémentaire est nécessaire pour garantir un routage approprié du trafic de retour.

Routage du trafic de retour

Lorsque l’application reçoit du trafic avec l’adresse IP d’origine du client (pas de SNAT), il faut s'assurer que le trafic de retour passe par la bonne appliance virtuelle de réseau (ou NVA). Les itinéraires définis par l’utilisateur peuvent être configurés dans le sous-réseau de l’application pour rediriger le trafic vers l’appliance de réseau virtuelle (NVA). Ces UDR doivent couvrir les plages d’adresses IP sur site et fonctionner correctement pour les déploiements uniques d’appliance virtuelle réseau.

Pour les déploiements avec plusieurs instances NVA par région, les considérations relatives au trafic asymétrique deviennent importantes. Les appliances virtuelles réseau sans état peuvent gérer le trafic asymétrique dans lequel les flux entrants et sortants passent par des instances différentes. Toutefois, les appliances réseau virtuelles (NVA) avec état nécessitent un flux de trafic symétrique afin de maintenir l’état de connexion. Les solutions pour les Appliances Virtuelles Réseau (AVR) avec état incluent l’utilisation de mécanismes d’affinité de connexion, l’implémentation du partage de session entre les instances AVR, ou la configuration d’équilibreurs de charge avec persistance de session.

Meilleures pratiques pour le flux de trafic

La surveillance de l’intégrité doit implémenter des contrôles d’intégrité robustes pour détecter rapidement les échecs des applications et des appliances virtuelles de réseau. La planification du basculement nécessite la configuration des minuteurs BGP appropriés afin de trouver un équilibre entre un basculement rapide et la stabilité. L’ingénierie du trafic peut utiliser des communautés BGP ou d’autres attributs pour implémenter des stratégies de trafic. La surveillance et les alertes complètes doivent suivre les annonces de routage et les modèles de trafic entre les régions pour garantir des performances optimales et une détection rapide des problèmes.

Considérations relatives à l’implémentation

Conditions préalables et conditions requises

Avant d’implémenter un routage anycast avec le serveur de routage Azure, vous devez planifier soigneusement votre allocation d’adresses IP pour vous assurer que l’adresse IP anycast n’est pas en conflit avec les réseaux Azure ou locaux existants. Une bonne compréhension des stratégies de routage BGP et de leur effet sur la distribution du trafic est essentielle pour le déploiement réussi. Votre architecture d’application doit être conçue pour gérer efficacement le trafic provenant de plusieurs régions, et vous devez implémenter une surveillance complète de l’intégrité pour les applications et les appliances virtuelles réseau pour garantir une opération fiable.

Bonnes pratiques de déploiement

Lors du déploiement d’un routage anycast, nous vous recommandons de commencer par un déploiement simple à deux régions avant de passer à d’autres régions. Les tests réguliers des scénarios de basculement permettent de s’assurer que le système répond à vos exigences de disponibilité et se comporte comme prévu pendant les pannes. La surveillance des métriques de performances telles que la latence et le débit provenant de différents emplacements locaux fournissent des insights précieux sur l’efficacité de votre configuration de routage. La maintenance d’une documentation claire de vos stratégies BGP et de leurs effets prévus est essentielle pour la gestion et la résolution des problèmes en cours.

Limitations et considérations

Plusieurs facteurs doivent être pris en compte lors de l’implémentation d’un routage anycast avec Azure Route Server. Les temps de convergence BGP peuvent introduire des retards pendant les événements de basculement, ce qui peut affecter les objectifs de temps de récupération. La complexité accrue du routage de la couche réseau par rapport aux solutions DNS nécessite une plus grande expertise et une planification minutieuse. La résolution des problèmes de routage de couche réseau peut être plus difficile que le diagnostic des problèmes de couche application, nécessitant des connaissances et des outils spécialisés. En outre, les coûts d’infrastructure augmentent en raison de la nécessité d’un plus grand nombre d’appliances virtuelles réseau et d’instances de serveur de routage dans plusieurs régions.

Étapes suivantes

  • Last updated on