Microsoft Azure: load-balancing de serveurs IIS

Nous allons voir dans cet article comment utiliser Azure Application Gateway sur un groupe de VMs Windows Server 2019 hébergeant des serveurs IIS.

Bien, comme dit en introduction nous allons donc voir comment utiliser une passerelle d’application (Application Gateway) de chez Azure pour réaliser du load-balancing de plusieurs machines virtuelles Windows, où tourneront un serveur web IIS. Pourquoi des VMs Windows avec des serveurs IIS et pas de bonnes vieilles VMs Debian avec NGINX ou Apache ? Simplement par curiosité :p

*Avant de commencer, il convient d’avoir un VPN P2S ou S2S configuré et fonctionnel, sinon vous ne pourrez pas vous connecter aux machines virtuelles que l’on s’apprête à créer. En effet, celles-ci auront des IP privées car elles se trouveront derrière notre load-balancer, et donc l’accès RDP se fera via un VPN. Si vous n’en avez pas, direction mon précédent article donc.

I) Création du groupe de sécurité réseau

Bien, la première étape est de créer un groupe de sécurité réseau qui permet d’autoriser/refuser certaines connexions sur certaines plages IP et certains ports. Ici nous allons en créer une nommée web_servers-01 où nous autoriserons simplement l’accès TCP sur le port 80 depuis Internet et à destination du réseau virtuel où se trouveront nos machines virtuelles :

Je ne vais pas détailler la procédure ici, nous en avions déjà parlé lors du précédent article et c’est assez trivial.

II) Création de l’adresse IP publique

Ici aussi rien de nouveau sous le soleil, nous allons simplement créer une nouvelle IPv4 publique que nous mettrons en front sur notre load-balancer.

III) Création de la passerelle d’applications

Il faut savoir que chez Azure, il y a deux types de Load-Balancer :

L’Application gateway, qui comme décrit sur le tableau ci-dessus est plutôt orienté trafic “web” dirons-nous, et l’Équilibreur de charge qui est quant à lui plutôt orienté “trafic général”, c’est-à-dire hors trafic web.

Je ne vais pas forcément rentrer plus que ça dans les détails, sachez simplement que ces deux services existent, et que lorsque l’on veut réaliser du “load-balancing de services web”, nous nous tournerons plutôt vers l’Application Gateway.

Mais du coup, c’est quoi au juste ?

Et bien ce service peut s’appuyer sur la couche 4 du modèle OSI (TCP/UDP) pour router certaines requêtes IP-Port vers certains pools (groupes de VMs), soit il peut s’appuyer sur sur la couche 7 (Applications) et permettre de prendre en compte les headers HTTP, par exemple si l’utilisateur se rend sur “contoso.com/images” comme sur le schéma ci-dessous, sa requête est redirigée sur le pool de serveurs nommé ImageServerPool. Facile !

Maintenant que l’on y voit on peu plus clair, il est temps de mettre tout ça en place.

Pour créer notre load-balancer on se rend donc sur le service Passerelle d’application et on clique sur Ajouter/Nouveau :

Ici rien de très compliqué, on choisi notre groupe de ressources, puis un nom pour la passerelle, la région, le niveau (Standard V2 convient amplement pour un lab), la mise à l’échelle automatique (permettant d’augmenter le niveau si besoin), le nombre d’instances, le nombre de zone de disponibilité, et enfin l’aspect réseau.

Ensuite on choisi l’adresse IP pour le Frontend (c’est-à-dire l’IP sur laquelle les visiteurs atterriront). On poursuit et on doit maintenant configurer le pool de serveurs backend, c’est-à-dire les serveurs où tourneront nos applications (ici nos serveurs IIS). Ici soit vous pouvez passer pour le moment et le rajouter plus tard, soit vous avez déjà créé votre groupe de machines virtuelles identiques et dans ce cas vous pouvez le sélectionner sur la droite :

Courage, c’est bientôt terminé, promis ! Ici on passe à la configuration pure et dure de notre load-balancer :

On peut donc voir le schéma de fonctionnement, et il nous faut cliquer sur Règles de routage pour configurer les derniers éléments requis :

Ici on créer donc un écouteur (ou plutôt Listener en anglais) qui va simplement permettre de spécifier sur quel port doit on écouter le trafic. Par exemple, ici on veut que notre service écoute sur le port 80.

Ensuite on s’occupe de la partie Cibles de back-end :

On sélectionne donc notre pool de serveurs backend, puis on clique sur Créer à côté de Paramètre HTTP, c’est la création de règle de redirection (dans le sens où : notre Listener catch le trafic à destination du port 80 sur notre IP publique, doit le renvoyer vers le pool de serveurs ok, mais doit-il faire d’autres modifications ?).

Ici vous pouvez donc spécifier des paramètres supplémentaires, comme par exemple l’option Remplacer le chemin backend, permettant de faire de la ré-écriture d’URL (si l’on se rend sur blog.notamax.be, nous sommes redirigé sur it-linux.com par exemple). Ici on se contente donc de donner un nom, spécifier le protocole HTTP avec le port 80, et le reste par défaut :

Vient ensuite l’étape des étiquettes puis de la vérification et création, vous commencez à connaître 😉

Voici ce que vous devriez obtenir une fois fini, si en plus vous avez déjà créé votre groupe de VMs :

IV) Création du groupe de machines virtuelles

Azure propose un service nommé “groupe de machines virtuelles identiques“, qui comme son nom l’indique, permet de créer un groupe de VMs identiques, ce qui permet par la suite de pouvoir ré-ajuster la taille de ce pool pour absorber des pics de charge ou autre. C’est exactement ce que nous allons utiliser !

On commence donc par nommer ce groupe (attention, ici les tirets et underscore ne sont pas autorisés, de même pour les espaces…), puis nous choisissons l’image, l’abonnement, le groupe de ressources, l’emplacement… bref du vu et revu :

Sauf peut être pour l’option Zone de disponibilité. Ici j’en ai choisi deux, et ce sont simplement des emplacements uniques et permettent donc, en choisissant le nombre de 2 pour l’exemple, de répartir nos futures machines virtuelles sur deux sites bien distincts, et garantissant donc un SLA extrêmement élevé. Voici un extrait de la documentation officielle si vous désirez en savoir un peu plus :

Les Zones de disponibilité sont des emplacements physiques uniques au sein d’une région Azure. Chaque zone de disponibilité est composée d’un ou de plusieurs centres de données équipés d’une alimentation, d’un système de refroidissement et d’un réseau indépendants. Pour garantir la résilience, il existe un minimum de trois zones distinctes dans toutes les régions activées. La séparation physique des Zones de disponibilité dans une région protège les applications et les données des défaillances dans le centre de données. 

https://docs.microsoft.com/fr-fr/azure/availability-zones/az-overview

Concernant l’option des disques managés, nous allons de nouveau nous tourner sur la doc :

Les disques managés Azure sont des volumes de stockage de niveau bloc qui sont gérés par Azure et utilisés avec des machines virtuelles Azure. Les disques managés sont comme un disque physique sur un serveur local, mais virtualisé. Avec les disques managés, il vous suffit de spécifier la taille de disque ainsi que le type de disque et de provisionner le disque. Une fois que vous avez provisionné le disque, Azure s’occupe du reste.

https://docs.microsoft.com/fr-fr/azure/virtual-machines/windows/managed-disks-overview

Vous l’aurez compris, ce sont de simples disques dur virtuels mais redondants, et étant donc obligatoire dès lors que l’on souhaite de la haute disponibilité. Bien, on continue !

Ici nous n’activons pas l’option de montée en charge, qui permet tout simplement de faire augmenter la configuration des machines virtuelles pour absorber un pic de charge. La raison ? Car cela fait changer le type d’abonnement de votre VM, entraînant donc un augmentation du coût sans oublier le fait qu’ici notre pic de charge se réparti sur différentes machines virtuelles, donc pas de soucis à se faire.

Concernant ensuite l’option d’équilibrage de charge, on choisi donc Application Gateway que l’on aura créé précédemment, puis nous choisissons aussi notre sous-réseau virtuel, et enfin nous décochons l’IP publique par instance.

On continue de scroll et on arrive aux derniers paramètres :

Ici concernant le groupe de sécurité réseau, j’en ai déjà défini un sur le sous-réseau lui-même, avec une simple règle autorisant le trafic Internet vers les machines virtuelles à destination du port 80. Pour le diagnostic de démarrage, on peut éventuelle le cocher, mais je préfère le désactiver étant donné que c’est un simple lab. On peut ensuite cliquer sur Créer !

Nos VMs démarrent directement, et tout semble correct !

VII) Installation du service IIS

On pourrait déployer le rôle IIS sur notre groupe de machines virtuelles via Powershell mais ici on va rester classique et on va déployer notre serveur web sur chaque VM une à une, cela nous permettra en même temps de vérifier que tout est correct.

Donc, comme pour n’importe quel autre rôle, on l’installe via le gestionnaire de serveur :

Ici on sélectionne donc le serveur web IIS, et au niveau d’éventuels ajouts on ne prends rien de plus. Ensuite c’est du traditionnel “suivant-suivant”.

Il ne nous reste plus qu’à patienter un peu…

Une fois notre serveur installé, il convient de réaliser la même manipulation sur les deux autres machines virtuelles, puis le tour est joué !

Une fois fait, on peut se rendre sur Tools, puis Internet Information Services (IIS) Manager pour afficher le panneau de configuration du service :

L’équivalent du /var/www/ se situe ici dans C:Windows\inetpub\wwwroot :

Il nous suffit donc d’éditer le fichier HTML par défaut et le remplacer par le nom de la VM en question, par exemple VM-1, VM-2, VM-3…

On arrive donc à la fin ! Il est temps de nous rendre sur notre IP publique Frontend pour vérifier si le tout fonctionne correctement. Si c’est bien le cas, nous devrions avoir successivement “Web-01 / Web-02 / Web-03” d’afficher sur notre page web.

Que demander d’autre ? Notre passerelle d’application fonctionne parfaitement ! Nous aurons donc pu voir dans cet article :

• La gestion de groupe de sécurité réseau ;
• La création d’IPv4 publique ;
• La création d’un groupe de machines virtuelles identiques ;
• L’installation de base du rôle IIS et la modification de la page web par défaut ;
• La création d’une passerelle d’application et sa liaison avec un pool de serveurs en backend ;

Pas mal tout de même ! A noter que bien entendu tout cela reste assez sommaire, nous n’avons pas fait d’HTTPS ou autre, mais vous aurez pu voir les différentes possibilités qui s’offrent à vous, il ne reste plus qu’à mettre les mains dedans et tester !

Une bonne journée/soirée à vous !