La haute disponibilité et l’équilibrage de charge de vos connecteurs et applications de réseau privé
Cet article explique comment fonctionne la distribution du trafic avec votre déploiement de proxy d’application. Découvrez-en davantage sur la façon dont le trafic est distribué entre les utilisateurs et les connecteurs, avec des conseils pour optimiser les performances du connecteur. Découvrez-en davantage sur la façon dont le trafic circule entre les connecteurs et les serveurs d’applications principaux, avec des recommandations pour l’équilibrage de charge entre plusieurs serveurs principaux.
Distribution du trafic entre les connecteurs
Les connecteurs établissent leurs connexions en fonction des principes de haute disponibilité. Il n’y a aucune garantie que le trafic soit réparti uniformément entre les connecteurs et qu’il n’y a pas d’affinité de session. Toutefois, l’utilisation varie et les requêtes sont envoyées de manière aléatoire aux instances du service de proxy d’application. Par conséquent, le trafic est généralement distribué presque uniformément entre les connecteurs. Le diagramme et les étapes ci-dessous illustrent la façon dont les connexions sont établies entre les utilisateurs et les connecteurs.
- Un utilisateur sur un appareil client tente d’accéder à une application locale publiée par le biais du proxy d’application.
- La requête passe par un équilibreur de charge Azure pour déterminer quelle instance de service de proxy d’application doit la prendre en charge. Il existe des dizaines d’instances disponibles pour accepter les demandes de tout le trafic dans la région. Cette méthode permet de répartir uniformément le trafic entre les instances de service.
- La requête est envoyée à Service Bus.
- Service Bus signale à un connecteur disponible. Le connecteur récupère ensuite la requête à partir de Service Bus.
- À l’étape 2, les requêtes sont dirigées vers différentes instances du service de proxy d’application, de sorte que les connexions sont plus susceptibles d’être établies avec différents connecteurs. Par conséquent, les connecteurs sont presque uniformément utilisés au sein du groupe.
- Le connecteur transmet la requête au serveur principal de l’application. L’application renvoie ensuite la réponse au connecteur.
- Le connecteur termine la réponse en ouvrant une connexion sortante vers l’instance de service à partir de laquelle la requête a été effectuée. Cette connexion est alors immédiatement fermée. Par défaut, chaque connecteur est limité à 200 connexions sortantes simultanées.
- La réponse est ensuite retransmise au client à partir de l’instance de service.
- Les requêtes suivantes émanant de la même connexion répètent les étapes.
Une application a souvent de nombreuses ressources et ouvre plusieurs connexions en cas de charge. Chaque connexion passe par les étapes à suivre pour être allouée à une instance de service. Si la connexion n’est pas associée à un connecteur, sélectionnez un nouveau connecteur disponible.
Meilleures pratiques pour la haute disponibilité des connecteurs
En raison de la façon dont le trafic est distribué entre les connecteurs pour la haute disponibilité, il est essentiel de toujours avoir au moins deux connecteurs dans un groupe de connecteurs. Trois connecteurs sont préférables pour fournir une mémoire tampon supplémentaire parmi les connecteurs. Pour déterminer le nombre correct de connecteurs dont vous avez besoin, suivez la documentation sur la planification de la capacité.
Placez les connecteurs sur des connexions sortantes différentes pour éviter un point de défaillance unique. Si les connecteurs utilisent la même connexion sortante, un problème réseau avec la connexion aura un impact sur tous les connecteurs qui l’utilisent.
Évitez de forcer le redémarrage des connecteurs quand ils sont connectés à des applications de production. Cela peut affecter de manière négative la distribution du trafic entre les connecteurs. Le redémarrage des connecteurs entraîne l’indisponibilité de connecteurs supplémentaires et force les connexions au connecteur restant disponible. Le résultat est une utilisation inégale des connecteurs initialement.
Évitez toute forme d’inspection inline sur les communications TLS sortantes établies entre les connecteurs et Azure. Ce type d’inspection inline entraîne une dégradation du flux de communication.
Veillez à ce que les mises à jour automatiques soient en cours d’exécution pour vos connecteurs. Si le service Updater de connecteur du réseau privé est en cours d’exécution, vos connecteurs se mettent à jour automatiquement et reçoivent la dernière mise à niveau. Si vous ne voyez pas le service Connector Updater sur votre serveur, vous devez réinstaller votre connecteur afin d’obtenir les mises à jour.
Flux de trafic entre les connecteurs et les serveurs d’applications principaux
Une autre zone clé dans laquelle la haute disponibilité est un facteur est la connexion entre les connecteurs et les serveurs principaux. Lorsqu’une application est publiée via le proxy d’application Microsoft Entra, le trafic des utilisateurs vers les applications circule via trois rebonds :
- L’utilisateur se connecte au point de terminaison public du service de proxy d'application Microsoft Entra sur Azure. La connexion est établie entre l’adresse IP cliente d’origine (publique) du client et l’adresse IP du point de terminaison du proxy d’application.
- Le connecteur de réseau privé extrait la requête HTTP du client à partir du service de proxy d’application.
- Le connecteur de réseau privé se connecte à l’application cible. Le connecteur utilise sa propre adresse IP pour établir la connexion.
Considérations liées au champ d’en-tête X-Forwarded-For
Dans certaines situations (telles que l’audit, l’équilibrage de charge, etc.), il est obligatoire de partager l’adresse IP d’origine du client externe avec l’environnement local. Pour répondre à cette exigence, le connecteur de réseau privé Microsoft Entra ajoute le champ d’en-tête X-Forwarded-For avec l’adresse IP (publique) du client d’origine à la requête HTTP. Le périphérique réseau approprié (équilibreur de charge, pare-feu) ou le serveur Web ou l’application principale peut ensuite lire et utiliser les informations.
Meilleures pratiques pour l’équilibrage de charge entre plusieurs serveurs d’applications
L’équilibrage de charge est important lorsque le groupe de connecteurs affecté à l’application proxy d’application dispose de deux connecteurs ou plus. L’équilibrage de charge est également important lorsque vous exécutez l’application web principale sur plusieurs serveurs.
Scénario 1 : l’application principale ne nécessite pas de persistance de session
Le scénario le plus simple est l’endroit où l’application Web principale ne nécessite pas d’adhérence de session (persistance de session). Une instance d’application principale gère les demandes des utilisateurs dans la batterie de serveurs. Vous pouvez utiliser un équilibreur de charge de couche 4 et le configurer sans affinité. Certaines options incluent l’équilibrage de charge réseau Microsoft et Azure Load Balancer ou un équilibrage de charge d’un autre fournisseur. Vous pouvez également configurer une stratégie DNS (Domain Name System) tourniquet (round robin).
Scénario 2 : L’application principale requiert une persistance de session
Dans ce scénario, l’application web principale requiert l’adhérence de session (persistance de session) au cours de la session authentifiée. L’instance d’application principale gère les demandes des utilisateurs. Les demandes d’exécution s’exécutent sur le même serveur dans la batterie de serveurs. Ce scénario peut être plus compliqué parce que le client établit généralement plusieurs connexions au service de proxy d’application. Les requêtes sur différentes connexions peuvent arriver sur des connecteurs et des serveurs différents dans la batterie. Étant donné que chaque connecteur utilise sa propre adresse IP pour cette communication, l’équilibreur de charge ne peut pas garantir l’adhérence de session en fonction de l’adresse IP des connecteurs. L’affinité IP source ne peut pas être utilisée non plus. Voici quelques options pour le scénario 2 :
Option 1 : Basez la persistance de session sur un cookie de session défini par l’équilibreur de charge. Cette option est recommandée car elle permet de répartir la charge de manière plus uniforme entre les serveurs principaux. Elle nécessite un équilibreur de charge de couche 7 avec cette fonctionnalité, capable de gérer le trafic HTTP et de mettre fin à la connexion TLS. Vous pouvez utiliser Azure Application Gateway (affinité de session) ou un équilibreur de charge d’un autre fournisseur.
Option n°2 : Basez la persistance de session sur le champ d’en-tête X-Forwarded-For. Elle nécessite un équilibreur de charge de couche 7 avec cette fonctionnalité, capable de gérer le trafic HTTP et de mettre fin à la connexion TLS.
Option 3 : Configurez l’application principale pour qu’elle ne nécessite pas de persistance de session.
Pour comprendre les exigences en matière d’équilibrage de charge de l’application principale, reportez-vous à la documentation de votre fournisseur de logiciels.