Server farm et Web farm

Cet article a été publié initialement sur mon ancien blog, qui était hébergé par blogspot.com.

Un dernier article de théorie qui présente une des étapes importantes à la base du "Cloud Computing". Je l’ai plus orienté sur "Web farm" que sur les "Serever farm", car l’objectif de mon mémoire est de construire un site Web 2.0 sur un "Cloud".

Historiquement, les fermes de serveurs et plus particulièrement les "Web farms" se sont développées au début des années 2000 [CT_01, WY_01] pour répondre aux besoins de la bulle internet. Ces "fermes" hébergent des centaines de serveurs montés en "Cluster". Le nom "farm" a été choisi par analogie avec les grandes granges américaines qui servent au stockage des céréales. Tout comme pour l’agriculture, ces fermes de serveurs sont installées en campagne ce qui permet aux exploitants de diminuer les coûts de stockage et de garantir un approvisionnement facilité en eau (nécessaire pour le refroidissement des machines) et en électricité.

Ces "fermes" de serveurs ont permis de répondre aux besoins de "haute disponibilité" (HA – "high availability" en Anglais) nécessaire à une grande majorité de services accessibles au travers de l’internet. La HA permet de garantir l’accomplissement des tâches même en cas de défaillance d’un des nœuds ("nodes" en Anglais) du "Cluster". Ce principe de "haute disponibilité" est réalisé grâce à la redondance des infrastructures physiques et logiques ainsi que la mise en place de mécanismes de reprise sur panne ("failover" en Anglais) et de répartition de charge ("load balancing" en Anglais). Malgré la HA l’utilisateur peut ressentir des baisses de performance, mais ne perdra pas complètement accès au service qu’il est entrain de consommer.

Pour répondre à ce besoin de "haute disponibilité" dans les "Web Farms" deux concepts sont primordiaux : celui de la "scalabilité" et celui de la "répartion de charge".

• La "scalabilité" permet de facilement augmenter la taille du "Cluster" en ajoutant des machines. Cette propriété permet de faciliter la montée en charge grâce à l’augmentation de la puissance de calcul et de la mémoire offerte dans la ferme. Ce concept permet aussi de garantir la "haute disponibilité" en permettant le remplacement d’une machine sans interruption de service.
• La répartition de charge en Anglais "load balancing" est un énorme challenge pour les ingénieurs et fait l’objet de nombreuses publications [BDH_03, CT_01, WY_01]. L’objectif de toutes les solutions proposées est de minimiser le temps de réponse moyen et éviter de surcharger une machine particulière. Pour atteindre ce but, les paramètres à prendre en compte sont divers et varient en fonction des projets.

La solution la plus simple, pour le "load balancing", est basée sur la répartition de charge au niveau du serveur DNS (Domain Name System). Cette première solution ne fait que convertir un nom de domaine en une IP. Cette solution est externe au "Cluster" et elle ne permet pas d'éviter de diriger l’utilisateur sur une machine surchargée ou qui ne répond plus.

La seconde solution consiste à utiliser un serveur frontal, appelé communément "dispatcheur", pour répartir la charge. Le "dispatcheur", pour faire son travail, prend en compte plusieurs paramètres tels que la nature du site (statique ou dynamique), l’URL demandé, les cookies ou la popularité momentanée du site. En fonction de la nature du site statique ou dynamique le "dispatcheur" mettra en œuvre un algorithme différent.

Des solutions peuvent aussi être développées pour répondre à des besoins spécifiques. Les ingénieurs de Google, dans l’article "Web Search for a Planet: The Google Cluster Architecture" [BDH_03], décrivent la solution mise en œuvre, par ce leader des moteurs de recherche, pour répondre aux requêtes faites sur son moteur de recherche. La solution consiste premièrement en une répartition de la charge au niveau du serveur DNS. Cette première étape dirige l’utilisateur sur le "Cluster" le plus proche de lui géographiquement. Dans une seconde phase, un serveur exécute la demande en interrogeant un serveur d’"index" et complète le contenu de la page de résultats en interrogeant un serveur dit de "documents" avant de la retourner à l’internaute.

Dans leur article "Load Balancing for Clustered Web Farms" [WY_01] Joel L. Wolf et Philip S. Yu, ingénieurs chez IBM, proposent d’héberger plusieurs sites web indépendants sur un nœud du "Cluster" et chacun de ces sites web est lui-même répliqué sur plusieurs nœuds du "Cluster". Ce chevauchement de sites sur plusieurs nœuds permet d’optimiser l’utilisation des ressources du serveur, car un site peut être temporairement fortement sollicité tandis que les autres sites hébergés sur le même serveur ne le sont pas. Cette solution, de partage des ressources physiques, pause toutefois un problème pour la confidentialité des données, car ces dernières sont toutes hébergées sur le même serveur. Un concurrent pourrait donc accéder aux données qui ne lui appartiennent pas.

Pour conclure cette section, je peux dire que les "Web Farm" ont permis et permettent toujours d’héberger des services accessibles sur l’internet nécessitant sur une très haute disponibilité. La principale difficulté, pour le développement des services hébergés dans ces fermes, est liée au fait que chaque machine reste indépendante, malgré qu’elles fassent toutes parties du même "Cluster". Il faut donc, tout comme pour le "Grid Computing" développer spécifiquement les applications, pour quelle fonctionne sur un "Cluster".

[BDH_03] Luiz André Barroso, Jeffrey Dean, Urs Hölzle, Web Search for a Planet: The Google Cluster Architecture, publié en 2003

[CT_01] Emiliano Casalicchio, Salvatore Tucci, Static and Dynamic Scheduling Algorithms for Scalable Web Server Farm, publié en 2001

[WY_01] Joel L. Wolf, Philip S. Yu, Load Balancing for Clustered Web Farms, publié en 2001