Cluster de serveurs web

Posted Posted by Patrice Guay in Web hosting     Comments 1 comment
mars
23

Un cluster est un groupe de deux ou plusieurs serveurs indépendants fonctionnant comme un système unique. L’utilisation d’un cluster plutôt que d’un seul serveur plus puissant que la somme des serveurs indépendants offre des avantages :

  • Augmente la disponibilité
  • Permet l’évolutivité du système
  • Distribue la charge
  • Permet l’utilisation de serveurs abordables

Mise à l’échelle d’une solution avec serveur unique

La première étape recommandée lors de l’extension de votre solution est de placer votre site web et les services de base de données sur deux serveurs distincts. Le serveur web s’occupera de gérer les requêtes de vos clients et communiquera avec le serveur de base de données pour obtenir des données dynamiques. Une telle configuration est compatible avec les logiciels de panneau de contrôle disponibles sur le marché. Le panneau de contrôle est installé sur le serveur web et communique avec le serveur de base de données à distance. Vos pages web configurés via le panneau de contrôle auront alors la possibilité de communiquer avec votre serveur de base de données.

single servermove toindependent web and db servers

La séparation des services web et des services de base de données sur deux serveurs distincts a plusieurs avantages.

Premièrement, les deux services ont des exigences différentes en termes de sécurité et contrôle d’accès. Les mettre sur deux serveurs différents permet la création d’une architecture plus sûre pour votre solution web. Bien que le serveur web accepte toutes les connexions entrantes sur les ports HTTP et/ou HTTPS, le serveur de base de données ne devrait accepter les connexions sur le port SQL qu’en provenance du serveur web. L’utilisation d’un réseau privé (non représenté sur le schéma ci-dessus) fournit un canal de communication beaucoup plus sûr.

Deuxièmement, les besoins en terme d’allocation de ressources pour les serveurs web et les serveurs de base de données sont différents. Le serveur web doit avoir suffisamment d’espace pour stocker vos textes, images, fichiers audio et vidéo. Généralement, un seul disque SATA ou une configuration RAID 1 fournit suffisamment d’espace et de performances. En outre, un processeur multi-core avec une faible fréquence d’horloge devrait fournir suffisamment de puissance de calcul pour votre service web (apache, nginx, IIS, etc). D’autre part, votre serveur de base de données nécessitera probablement de meilleures performances disques et aura des besoins plus élevés en terme de processeur. L’utilisation de disques durs SAS ou SSD dans une configuration RAID 1 ou RAID 10 fournira un débit plus élevé. Un ou deux processeurs multi-core avec une vitesse d’horloge élevée offrira des performances de calcul supérieures pour votre service de base de données (MySQL, PostgreSQL, MSSQL, Oracle, etc).

Troisièmement, une séparation entre les services web et base de données simplifiera le passage vers une solution hautement disponible avec la mise en cluster du web et des base de données. La séparation de ces deux services à ce stade de l’évolution de votre solution web simplifiera la migration vers une configuration hautement disponible.

Cluster de serveurs web

Pour atteindre une haute disponibilité et accroître les performances de votre service web, vous aurez besoin d’une solution redondante d’équilibrage de charge et d’au moins deux serveurs web. Il y a deux principales méthodes pour l’équilibrage des connexions réseau :

  • Répartition de charge par proxy inverse (layer-7 : niveau applicatif)
  • Répartition de charge par routage de paquets IP (layer-4 : niveau transport)

Dans le schéma ci-dessous, le système d’équilibrage de charge est formé par une paire d’appareils actif / passif en configuration proxy inverse. Le trafic Internet est réparti sur les serveurs web back-end via le système d’équilibrage de charge. L’adresse IP associée au nom de domaine de votre service web est associée à l’appareil d’équilibrage de charge actif. Toutes les connexions entrantes à cette adresse IP sont traitées par l’appareil d’équilibrage de charge actif et transmises vers les serveurs Web par NAT (Network Address Translation). Les réponses des serveurs web sont retransmises vers les clients par l’appareil d’équilibrage de charge actif.

web cluster and a standalone database server

Avec une telle configuration, le système d’équilibrage de charge peut aussi fonctionner comme un dispositif pare-feu pour protéger vos serveurs web et base de données des tentatives d’intrusion hostiles. En outre, votre serveur de base de données est maintenant dans un endroit beaucoup plus sûr car il peut répondre aux requêtes SQL à partir du réseau privé et ignorer en toute sécurité les demandes en provenance du réseau public.

Algorithme d’équilibrage de charge

Différents algorithmes d’ordonnancement sont utilisés pour distribuer les demandes de connexion vers les serveurs back-end. Un algorithme simple peut consister en un choix aléatoire ou la technique « round-robin » où les demandes de connexion sont dirigées en ordre circulaire et à parts égales vers chacun des serveurs back-end. Certaines méthodes plus sophistiquées tiennent compte de facteurs supplémentaires tels que l’utilisation des ressources des serveurs back-end et leur temps de réponse. La disponibilité de ces méthodes dépend de votre choix de système d’équilibrage de charge.

Persistance des connexions

Le traitement de l’information devant être conservée entre les multiples requêtes d’un même client est un point important lorsque vous utilisez un appareil d’équilibrage de charge. Lorsque les informations relatives aux sessions des clients sont conservées localement sur chaque serveur, les multiples requêtes d’un même client doivent être envoyées vers un seul et unique serveur. Le stockage des données de session dans le navigateur du client plutôt que sur le serveur web permet de contourner ce problème car la persistance des connexions n’est plus nécessaire. Un algorithme simple tel que le « round-robin » peut alors être utilisé sur le système d’équilibrage de charge. Cependant, cette méthode de traitement des données de session n’est pas toujours possible ou souhaitable.

Une solution simple au problème de persistance des connexions est d’envoyer toutes les demandes d’une même session vers le même serveur back-end. Toutefois, si un serveur tombe en panne, les informations de session locales seront perdues et les sessions qui en dépendent doivent être réinitialisées. La persistance peut être établie en utilisant l’adresse IP du client ou par l’insertion d’un témoin (cookie) sur le navigateur web. Ce témoin contient alors les coordonnées du serveur back-end. Il est analysé par le système d’équilibrage de charge avant que celui-ci transmette la requête au serveur web back-end approprié.

Synchronisation des données

Les fichiers de configuration et les données doivent être synchronisées entre tous les serveurs d’un même cluster. Sous Linux, où la configuration est un ensemble de fichiers, la configuration du serveur web peut être copié à partir du premier serveur web vers les autres sur une base régulière à l’aide d’une tâche planifiée. Sous Microsoft Windows, la configuration de IIS n’est pas stockée directement sur un fichier et la configuration doit être reproduits manuellement sur chaque serveur web.

Les fichiers texte, image, musique et vidéo peuvent être copiés à partir du premier serveur web vers les autres sur une base régulière en utilisant une tâche planifiée sous Linux et Microsoft Windows. Toutefois, si vous avez besoin de maintenir une synchronisation continue des données entre les serveurs web, vous aurez très probablement besoin d’un stockage centralisé de type NAS (Network Attached Storage). Pour illustrer cette exigence, on peut imaginer deux clients surfant sur votre site web. Alors que le premier client est connecté au serveur web A, le second est connecté au serveur web B. Le premier client télécharge une image de lui-même sur votre site web. Sans synchronisation continue, l’image ne sera pas visible pour le second client jusqu’à ce que le script de synchronisation soit exécuté entre les serveurs A et B. Si votre site permet l’ajout de contenu directement par ses utilisateurs, vous aurez probablement besoin d’une synchronisation continue entre vos serveurs web.

Compatibilité avec les logiciels de panneau de contrôle

Un inconvénient majeur d’une architecture web en cluster est son incompatibilité avec la majorité des logiciels de panneau de contrôle. La synchronisation requise des fichiers du serveur web (configuration et données) est le principal obstacle à l’utilisation d’un panneau de contrôle sur une solution de cluster web.

Performance

En théorie, puisque de multiples serveur web sont en mesure de répondre aux demandes des clients, la performance d’un cluster web mesurée en termes de débit de données et de temps de réponse sera supérieure à la performance d’une solution dotée d’un seul serveur web. Toutefois, la performance peut ne pas suivre une loi d’échelle linéaire pour différentes raisons :

  • la base de données peut avoir des ressources insuffisantes pour répondre rapidement aux requêtes SQL des serveur web, le serveur de base de données devient alors le goulot d’étranglement de votre soution;
  • la bande passante du système d’équilibrage de charge vers l’Internet peut être saturée;
  • etc.

Jusqu’à présent, nous avons seulement discuté de la mise en cluster de serveurs web. Toutefois, pour parvenir à une véritable haute disponibilité, le service de base de données doit également être transformé en un cluster. Nous discutons de la façon de créer un cluster de base de données dans cet article.

1 Comment to “Cluster de serveurs web”

Post comment

Advertisements