Editions ENI Livres | Vidéos | e-Formations
Équilibreurs de charge
Les services d’équilibrage de charge Azure
Microsoft Azure propose de multiples services d’équilibrage de charge permettant d’assurer la haute disponibilité, la performance et la sécurité des accès aux applications déployés dans le cloud. Pour répondre à ces enjeux, différents services cloud sont à disposition. Il est important d’étudier leur fonctionnement et de voir comment, suivant vos besoins, ils s’intègrent les uns aux autres.
Quel que soit votre déploiement, différents paramètres sont à prendre en compte au moment de sélectionner une ou plusieurs solutions d’équilibrage de charge. Ce chapitre a pour but d’étudier chacun de ces services afin de revenir sur leur fonctionnement, leurs spécificités ou encore leur coût. Des exemples seront présentés et le cas concret de la Dream Company sera complété de plusieurs services d’équilibrage de charge.
Les services abordés lors de ce chapitre sont les suivants :
-
L’Azure Load Balancer (interne et externe).
-
L’Azure Application Gateway et le WAF (Web Application Firewall).
-
L’Azure Front Door (pouvant inclure le WAF et le Content Delivery Network).
-
L’Azure Traffic Manager.
Ces services peuvent être regroupés selon deux grands critères :...
Azure Load Balancer
1. Principe et description de l’Azure Load Balancer
L’équilibreur de charge Azure est un service régional qui a pour but de distribuer le trafic réseau de couche 4 sur un ensemble de ressources (par exemple, des machines virtuelles). L’équilibreur de charge se place en amont des ressources et permet un point de connectivité unique (une seule adresse IP) hautement redondé sur lequel l’ensemble des requêtes sont concentrées, puis redistribuées.
L’adresse IP portée par l’équilibreur de charge est appelée la frontend IP. Cette dernière peut être publique ou privée. Lorsque l’IP de frontend est une adresse IP privée (RFC1918), on parle d’équilibreur de charge interne. Inversement, si on lui applique une IP publique, on parle alors d’équilibreur de charge externe. Il n’est pas possible de mélanger les deux besoins et d’avoir un équilibreur de charge assurant à la fois des accès internes et externes.
Il est très courant de déployer les équilibreurs de charge dans des applications multitiers. Dès lors, un équilibreur de charge public est utilisé en amont de votre application et un ou plusieurs équilibreurs de charge internes pour les échanges internes à vos applicatifs.
Qu’ils soient internes ou externes, les équilibreurs de charge ont deux SKU différents. Ce choix de SKU impact de manière générale les fonctionnalités, les coûts et l’adaptabilité de la solution. Voici quelques exemples sur lesquels nous reviendrons dans ce chapitre :
|
Standard |
Basic |
|
|
Taille du Pool Backend |
Jusqu’à 1000 |
Jusqu’à 300 |
|
Ressources Backend |
Toute machine virtuelle ou machine virtuelle dans un Scale Set |
Machine virtuelle dans un seul Availability Set ou Scale Set |
|
Sonde d’intégrité |
TCP, HTTP, HTTPS |
TCP, HTTP |
|
Sécurisé par défaut |
Oui, par des NSG |
Non, ouvert par défaut |
|
Multiples frontend |
Entrantes et sortantes |
Entrantes uniquement |
|
SLA |
99,99 % |
Non disponible |
Microsoft recommande l’utilisation de load balancer standard. Ces derniers sont plus adaptés à des environnements de production et permettent plus de contrôle...
Cas concret - Partie 12
Après avoir hybridé et sécurisé son déploiement, la Dream Company souhaite déployer de nouveaux serveurs Windows. Ces derniers devront supporter la mise à l’échelle automatique en cas de charge. De même, une solution d’équilibrage de charge doit être déployée en amont des serveurs et accessible par les utilisateurs locaux.
Afin de respecter ces exigences, et puisqu’il s’agit d’accès privés, un équilibreur de charge interne standard va être déployé dans un nouveau réseau virtuel spoke nommé vNet_SpokeC. Cet équilibreur de charge sera positionné en amont d’un groupe de machines virtuelles identiques (VSS/Virtual Machine Scale Set), dans un sous-réseau nommé Subnet_VSS. L’équilibreur de charge sera accessible depuis les réseaux on-premise et VPN uniquement et, pour les tests, exposera simplement des machines virtuelles Windows en RDP (TCP/3389). Ces accès seront utilisés pour vérifier l’équilibrage de charge sur les différents serveurs.
Finalement, la Dream Company souhaite que les serveurs en question puissent sortir sur Internet depuis leur réseau virtuel. Afin d’assurer une connectivité internet aux machines virtuelles, une passerelle NAT (NAT Gateway) sera donc déployée dans le réseau virtuel vNet_SpokeC.
La création du réseau virtuel (vNet_SpokeC) et du sous-réseau (Subnet_1C) ne sera pas étudiée en détail ici, leur création étant similaire aux réseaux et sous-réseaux précédents. Toutefois, les configurations suivantes sont nécessaires et étudiées durant ce cas concret :
-
Création d’un équilibreur de charge interne standard SKU v2.
-
Création d’un groupe de machines virtuelles identiques (VSS) Windows.
-
Configuration de l’équilibreur de charge (pool principaux, sonde d’intégrité, règle d’équilibrage de charge…).
-
Configuration du NSG associé au sous-réseau Subnet_1C.
-
Configuration du pare-feu Azure.
-
Configuration du peering entre le vNet_SpokeC et le vNet_Hub.
-
Configuration d’un nouvel itinéraire...
Azure Application Gateway et WAF
1. Principe et description de l’Azure Application Gateway
Contrairement aux équilibreurs de charge classiques, les équilibreurs de charge de type Application Gateway sont utilisés pour gérer le trafic web à destination de vos applications. Les requêtes ne sont donc plus uniquement réparties par rapport à une combinaison d’IP sources, de ports et de destinations, mais également suivant des paramètres plus spécifiques présents dans les requêtes HTTP(S), tels que les URL ou en-tête par exemple. On parle alors d’équilibreur de charge de la couche d’application, couche 7 du modèle OSI, et non plus de la couche 4 comme pour les équilibreurs de charge classiques (internes et externes).
Abordons à présent les concepts clés communs aux équilibreurs de charge classiques et aux Application Gateway.
De la même manière que pour les équilibreurs de charge classiques, l’Application Gateway va ici représenter le point d’entrée unique à destination de vos pool backend applicatifs. Celui-ci est à nouveau représenté par une IP virtuelle frontend portée par la passerelle. À noter cependant que contrairement aux équilibreurs de charge classiques, une même Application Gateway peut, cette fois, supporter une adresse IP publique, une adresse IP privée, ou les deux.
Les pools backend, eux, peuvent se trouver en dehors du réseau virtuel dans lequel la passerelle se trouve, voire en dehors d’Azure tant qu’une connectivité réseau est possible. Ils peuvent être constitués de machines virtuelles, de VSS, de compte de stockage blob ou encore d’App Services par exemple.
Finalement, les sondes d’intégrité fonctionnent globalement de la même manière et dans le même but que pour les équilibreurs de charge classiques.
Néanmoins, et bien que les concepts de frontend, de backend et de sondes d’intégrité soient relativement équivalents, les règles créées sur une Application Gateway sont, elles, bien différentes. Trois éléments clés sont à étudier afin de bien appréhender le fonctionnement...
Cas concret - Partie 13
La Dream Company, toujours dans sa démarche de migration vers le cloud, souhaite disposer d’un nouveau service de site web statique hébergé dans Azure. Ce déploiement devra être redondé et sécurisé de bout en bout. Les accès devront bien sûr être sécurisés face aux attaques web communes. Il faudra également limiter les accès depuis plusieurs pays.
Pour cela, une Application Gateway (SKU v2) sera déployée dans un nouveau réseau virtuel spoke. L’objectif de cette passerelle sera de distribuer les flux provenant d’Internet à destination de deux pages web statiques du site de la Dream Company. Suivant l’URL de la requête, les flux seront acheminés vers différents pools de ressources. De plus, afin de pouvoir accéder au site web de manière sécurisée, un chiffrement TLS de bout en bout sera mis en place et les accès directs autres que par l’Application Gateway seront bloqués.
Pour terminer, et pour répondre aux enjeux de sécurité exposés par la Dream Company, les fonctionnalités de WAF seront activées avec les règles de base ainsi qu’une nouvelle règle personnalisée de filtrage géographique, incluse dans une stratégie WAF.
La cible du déploiement est la suivante :
À nouveau, les étapes de création du réseau virtuel (vNet_SpokeD) et du sous-réseau (Subnet_1D) ne seront pas étudiées en détail, car similaires aux déploiements précédents. Cependant, l’ensemble des points suivants seront abordés :
-
Création de deux comptes de stockage avec conteneurs blob Azure hébergeant le site web statique.
-
Création d’une Application Gateway SKU v2.
-
Configuration de l’Application Gateway :
-
Création de deux pools de serveurs principaux.
-
Création d’un écouteur sur le port 443 et intégration d’un certificat SSL.
-
Mise en place des paramètres HTTPS afin d’assurer le chiffrement de bout en bout.
-
Création d’une sonde d’intégrité.
-
Mise en place d’une règle d’équilibrage de charge basée sur le chemin...
Azure Front Door
1. Principe et description de l’Azure Front Door
L’Azure Front Door est un service d’équilibrage de charge de niveau 7 (HTTP/HTTPS) offrant un point d’entrée globalement accessible et hautement redondant pour vos applications web, les rendant dès lors plus performantes, résilientes et sécurisées, quelle que soit la localisation de vos utilisateurs. Ce service est, littéralement, la "porte d’entrée" de vos applications globales.
L’Azure Front Door s’appuie sur le réseau global de Microsoft (constitué de plus de 160 points de présence distribués au travers de 82 pays dans le monde) pour déployer ses points d’entrées autour du globe, traitant ainsi les requêtes au plus proche de l’utilisateur, le plus rapidement possible. Un ensemble de fonctionnalités spécifiques sont mises en place afin d’assurer ce processus et seront étudiées dans ce chapitre, pour chacun des SKU associés.
Lorsqu’un point de présence Front Door reçoit des requêtes, il les transmet aux backend les plus rapidement accessibles. Deux éléments importants sont à noter sur la nature des backend :
-
Contrairement à l’Application Gateway, les backend peuvent être déployés dans différentes régions Azure, rendant le service global.
-
Contrairement à l’Application Gateway, les serveurs backend ne sont pas nécessairement hébergés dans Azure. Ils peuvent être hébergés on-premise ou chez un autre fournisseur de cloud par exemple. La seule condition est l’exposition de cette ressource sur Internet afin qu’elle soit accessible depuis l’Azure Front Door.
L’Azure Front Door peut être couplé à des déploiements de type Application Gateway. C’est notamment ce qui sera déployé lors du cas concret.
Finalement, l’Azure Front Door est disponible dans trois SKU différents :
-
L’Azure Front Door.
-
L’Azure Front Door Standard.
-
L’Azure Front Door Premium.
Bien que l’objectif global de la solution soit le même sur les trois niveaux de SKU, les fonctionnalités apportées ainsi que la gestion associée à...
Cas concret - Partie 14
La Dream Company ambitionne de s’exporter aux États-Unis et souhaite optimiser l’accès aux applications hébergées dans Azure, quelle que soit la position géographique de l’utilisateur. Pour répondre à ces enjeux de performance, une Azure Front Door sera déployée à destination de deux backend de type Application Gateway. La première, déployée lors du cas concret précédent, est située en Europe occidentale. La seconde Application Gateway, déployée pour l’occasion, se situera en USA Ouest. L’objectif est de rendre disponible le domaine personnalisé app.dreamcompany.fr au travers de l’Azure Front Door et non plus directement sur l’Application Gateway, afin d’assurer un équilibrage global.
À noter qu’il n’est pas obligatoire de conserver les Application Gateway et qu’il est également possible d’exposer directement les comptes de stockage derrière l’Azure Front Door. Il s’agit ici d’une volonté de capitaliser sur l’existant et de venir compléter un déploiement fonctionnel. De même, cette architecture possède d’autres avantages comme la capacité à assurer 100 % de déchargement SSL et de n’avoir que du trafic HTTP en interne ou encore de maintenir une affinité de session de l’utilisateur jusqu’au serveur d’un même backend.
Concernant la sécurité, la Dream Company souhaite déporter les fonctionnalités de WAF sur l’Azure Front Door. C’est pourquoi l’Application Gateway déployée aux États-Unis sera en Standard v2 uniquement. Au vu des besoins de distribution de contenu et de sécurisation, l’Azure Front Door sera déployée en SKU Premium.
Il n’est pas possible de supprimer une stratégie WAF appliquée à une Application Gateway. Lorsqu’une première association est réalisée, l’Application Gateway ne peut plus se retrouver sans stratégie associée. C’est pourquoi il est uniquement possible de la modifier ou d’en associer une autre.
Lorsqu’une Front Door est déployée devant un service Application...
Azure Traffic Manager
1. Principe et description de l’Azure Traffic Manager
Traffic Manager est un équilibreur de charge global de couche 7 basé sur le DNS. À l’image des autres services d’équilibrage de charge, l’objectif du Traffic Manager est de distribuer le trafic à destination de vos ressources de manière optimale et redondante. Toutefois, Traffic Manager, lui, ne joue pas le rôle de "proxy" par rapport aux flux de données. Seule la requête DNS est utilisée pour retourner l’adresse IP du point de terminaison considéré comme optimal. Le reste des échanges de données se font alors directement entre le client et le point de terminaison.
L’Azure Traffic Manager n’est ensuite plus contacté et n’intervient plus dans les échanges, limitant ainsi tout impact sur les flux. Traffic Manager utilise des mécanismes identiques à ceux de l’Azure Front Door pour optimiser ses temps de réponse. Parmi ces mécanismes, on retrouve l’utilisation de l’anycast sur le réseau global Microsoft ou encore la mise en cache des réponses DNS.
Une instance Traffic Manager est appelée un profil. Derrière chaque profil Traffic Manager se trouve un ensemble de points de terminaison sur lesquels les requêtes peuvent être redirigées. Comme pour l’Azure...
Cas concret - Partie 15
La Dream Company souhaite à présent déployer une solution de SFTP hautement redondée, performante et économique. L’objectif est d’avoir un serveur SFTP pouvant être activé à la demande et pour lequel les coûts peuvent être limités lors de la non-utilisation.
Premièrement, puisqu’il s’agit d’un déploiement global basé sur du SFTP (TCP/22), l’équilibrage de charge ne peut être effectué au travers de services tels qu’Azure Application Gateway ou Azure Front Door. Pour rappel, le premier n’est pas un service global à lui seul et, comme pour le second, ne supporte que les flux HTTP/HTTPS.
L’Azure Traffic Manager peut, lui, supporter les quatre prérequis associés à ce déploiement, c’est-à-dire offrir à la fois la redondance globale, l’optimisation des performances, la gestion des flux SFTP et le tout à moindre coût.
Techniquement, ce type de déploiement peut également être assuré par un Azure Global Load Balancer par exemple. Cependant, plusieurs différences sont à noter, comme le coût global de la solution ou encore le passage en direct ou non des flux de l’utilisateur vers la ressource par exemple. Il est donc important de toujours prendre en compte l’ensemble du besoin et des enjeux associés pour définir la solution la plus adaptée.
Pour ce cas d’usage, l’Azure Traffic Manager est donc sélectionné pour sa simplicité de mise en place et les faibles coûts associés. Les coûts étant calculés par millions de requêtes DNS, si la solution n’est pas utilisée, le tarif global de la solution sera forcément moindre. À l’inverse, un équilibreur de charge global sera de base facturé à l’heure par exemple, sans compter le surcoût associé aux flux.
Le Traffic Manager...
