Mise à jour 5/11/2021

Le billet ci-dessous reste applicable pour toutes les versions de WEBDEV, en utilisant un système "load balancer" quelconque. Cependant à partir de la version 27 de WEBDEV, un proxy (image Doker ou VM) est proposé en standard afin de gérer un cluster de serveurs d'application WEBDEV.

Notre support est régulièrement interrogé sur les adaptations à faire dans un site WEBDEV qui doit être déployé sur plusieurs serveurs, et plus un seul. La question est souvent "est-ce que WEBDEV", ou "comment WEBDEV fait la répartition de charge sur les serveurs ?"

La gestion de la répartition de charge entre les serveurs vient en amont du serveur d'application de WEBDEV, et du serveur web qui l'héberge. Ça n'est donc pas directement WEBDEV qui gère la répartition, mais le système "load balancer" déployé sur les installations. C'est donc transparent pour WEBDEV et donc pour les sites et webservices hébergés.

La seule précaution à prendre : le système "load balancer" doit être configuré de façon à ce que les requêtes d'un utilisateur du site, soient toujours traitées par un même serveur web. Sauf si le site hébergé est statique ou sans aucune information de session mémorisée sur le serveur web. Dans ce cas uniquement les requêtes HTTPS vers le site peuvent être envoyées sur un serveur quelconque.

Le déploiement d'un site derrière un "load balancer" revient donc pratiquement à répéter plusieurs fois, le déploiement qui aurait été fait sur un serveur unique :

• installation d'une licence du serveur d'application de WEBDEV sur tous les serveurs web,
  
  
• déploiement du site sur chaque serveur. A l'étape "Paramètres de déploiement du site" de l'assistant, deux cas se présentent pour le domaine associé au site :
  
  
  • le site n'a pas besoin d'avoir un fichier SiteMap généré pour le référencement : dans ce cas on donne pour nom de domaine, le nom de la machine qui va héberger le site, et non pas le nom du domaine permettant d'accéder au "load balancer",
  • le site a besoin d'être référencé avec un SiteMap renseigné avec le domaine : dans ce cas on donne le nom de domaine permettant d'accéder au "load balencer". Mais une étape supplémentaire est nécessaire sur le serveur qui héberge le site :
    • lancer l'éditeur du registre REGEDIT,
    • accéder à la section du serveur d'application de WEBDEV :
      \HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\PC SOFT\WEBDEV\25.0
    • dérouler la clé \Applications\<NomSite>
    • indiquer pour la donnée de la valeur VIRTUALHOST (REG_SZ) le nom de la machine qui héberge le site.

• copie et/ou installation sur les différents serveurs de tout ce qui est utilisé par le site (client de base de données, données statiques, paramètres...),
  
  
• association du domaine d'accès au site non plus au serveur sur lequel le serveur est déployé, mais sur le serveur / proxy "load balancer",
  
  
• configuration du "load balancer" pour qu'il redirige les requêtes d'un internaute, toujours vers le même serveur web.

Le clonage d'une machine virtuelle "modèle" incluant le serveur d'application, les sites et webservices hébergés et leurs paramètres peut être utile voire obligatoire si le nombre de serveurs web est important. Dans ce cas, lorsqu'un serveur web est créé par copie intégrale d'un autre, il faudra sur chaque serveur corriger la valeur VIRTUALHOST du registre afin qu'elle désigne bien la bonne machine. Sans cela le nouveau serveur ne pourra pas utiliser les sessions pré-lancées ou exécuter les tâches planifiées.

Astuces / conseils :

• concernant le domaine, il existe une alternative pour éviter une configuration manuelle de la valeur de registre VIRTUALHOST de WEBDEV :
  • déployer tous les sites et webservices en donnant pour le domaine celui qui permet d'accéder au load "balancer" (de cette manière le SiteMap d'un site est toujours juste, tout comme le .wsdl d'un webservice),
  • modifier sur tous les serveurs installés le fichier host de Windows pour que le domaine désigne la machine locale 127.0.0.1 (de cette manière les requêtes HTTPS lancées par le serveur d'application de WEBDEV pour ses sessions pré-lancées ou tâches planifiées sont toujours sur le serveur lui-même). Cette solution s'applique si le site virtuel du serveur web répond aux appels qui proviennent de 127.0.0.1.
    Le fichier host de Windows est toujours dans %WinDir%\System32\Drivers\Etc\
• configurer les accès aux différents serveurs web afin qu'ils n'acceptent que les appels HTTPS provenant du "load balancer" : cela permet d'être certain d'avoir une erreur HTTP pour diagnostiquer tout cas de configuration erronée.

Concernant les données, il est possible de copier sur chaque serveur les données qui ne seront qu'en consultation. Pour toutes les données mises à jour, il est conseillé d'utiliser un serveur distinct qui hébergera le moteur HFSQL client/serveur. De cette manière tous les serveurs web derrière le "load balancer" se connectent (cf. HOuvreConnexion & HChangeConnexion) à un même et unique serveur HFSQL client/serveur. Pour les besoins les plus importants, le moteur HFSQL client/serveur est disponible en cluster. Il peut donc à son tour être multiplié afin de répartir les demandes des serveurs web, sur différents serveurs de données. Mais son équilibrage de charge intégré permet dans le cas général de conserver un serveur de données unique, complété par un serveur spare assurant la continuité de service en toute circonstance.

Ce schéma issu des concepts de WEBDEV illustre bien l'organisation :

Rappelons que l'équilibrage de charge avec un système "load balancer" n'est pas l'alternative unique pour gérer les pics d'activité d'un site. Les hébergements dans un CLOUD permettent un dimensionnement fin des ressources des serveurs, sans impact sur les sites et webservices déployées, ou les données. C'est par exemple le cas des sites déployés sur les plateformes d'exploitation de PCSCLOUD. Un même et unique déploiement sera fait sur un serveur aux capacités toujours adaptées pour une disponibilité maximale. Le serveur peut être configuré à tout moment pour avoir davantage de CPU/RAM/disque, afin de répondre à un pic d'activité, ou de s'adapter à un accroissement durable du nombre de connexions...