Vous avez choisi d'utiliser la mise en cluster pour concevoir ou modifier un niveau d'infrastructure, de manière à répondre aux impératifs de performances, tout en gardant une possibilité d'adaptation en fonction de l'évolution des demandes.

Problème

Comment concevoir un niveau d'infrastructure évolutif, qui tienne compte des variations de charge tout en offrant des performances acceptables ?

Facteurs à prendre en compte

Lorsque vous concevez un niveau d'infrastructure évolutif, vous devez prendre en compte les facteurs suivants :

• Chaque serveur pris individuellement possède, pour une application donnée, une capacité de charge maximale. Ainsi, si un seul serveur est chargé de fournir des pages Web dans le cadre d'une application Web et si le nombre d'utilisateurs ou la charge transactionnelle augmente au-delà de la capacité limite du serveur, l'application offrira des performances inférieures aux attentes ou, dans le pire des cas, deviendra indisponible.
• Chaque serveur est soumis à des limites physiques en termes de performances, qu'il s'agisse de la vitesse du bus, de la quantité de mémoire, du nombre de processeurs ou du nombre de périphériques qu'il peut exploiter. Par exemple, si le serveur ne peut accueillir que quatre processeurs, vous ne pouvez pas en ajouter un cinquième pour améliorer les performances.
• Certaines applications ne peuvent exploiter qu'un nombre limité de processeurs.
• Les serveurs, en tant qu'entités individuelles, constituent des points de défaillance uniques au sein d'une solution. Si un seul serveur est chargé de fournir les fonctionnalités d'un composant particulier d'une application, sa défaillance entraîne l'échec de l'application.
• L'ajout de serveurs, en revanche, rend plus complexe la gestion et la surveillance du matériel correspondant et du logiciel associé.

Solution

Installez votre application ou service sur plusieurs serveurs configurés pour se partager la charge de travail. Ce type de configuration est appelé Load-Balanced Cluster (cluster avec répartition de charge). La répartition de charge permet de faire évoluer les performances des programmes sur serveur (serveurs Web, par exemple), en répartissant les requêtes des clients sur plusieurs serveurs. Les répartiteurs de charge, terme couramment utilisé pour désigner les technologies de répartition de la charge, reçoivent les requêtes entrantes et les redirigent si nécessaire vers un hôte particulier. Les serveurs à répartition de charge répondent simultanément aux requêtes des différents clients, voire à plusieurs requêtes du même client. Ainsi, un navigateur Web peut obtenir les différentes images d'une même page Web à partir de différents hôtes du cluster. Une telle structure permet de répartir la charge, d'accélérer le traitement et de réduire les temps de réponse pour les clients.

Les répartiteurs de charge utilisent différents algorithmes pour gérer le trafic. Leur but est de répartir intelligemment la charge et/ou d'optimiser l'utilisation de l'ensemble des serveurs du cluster. Voici quelques exemples de ces algorithmes :

• Round-robin (répartition de charge équitable). Un algorithme Round-robin répartit équitablement la charge entre chaque serveur, quels que soient le nombre actuel de connexions ou les temps de réponse. Cet algorithme est adapté si les serveurs du cluster disposent des mêmes capacités de traitement ; sinon, certains serveurs risquent de recevoir plus de requêtes qu'ils ne peuvent en traiter tandis que d'autres n'utiliseront qu'une partie de leurs ressources.
• Weighted Round-robin (répartition de charge pondérée). Un algorithme Weighted Round-robin prend en compte la capacité de traitement de chaque serveur. Les administrateurs affectent manuellement un coefficient de performance à chaque serveur et une séquence d'ordonnancement est générée automatiquement en fonction de cette valeur. Les demandes sont ensuite affectées aux différents serveurs selon une séquence de répétition alternée.
• Least-connection (répartition de charge selon la moindre connexion). L'algorithme Least-connection envoie les demandes aux serveurs d'un cluster en fonction de celui qui sert actuellement le moins de connexions.
• Load-based (répartition basée sur la charge). Un algorithme Load-based envoie les demandes aux serveurs d'un cluster en fonction de celui dont la charge est actuellement la plus faible.

De plus, certains répartiteurs de charge intègrent une détection des défaillances. Le répartiteur de charge assure un suivi du serveur ou de l'application qui s'y exécute, et cesse de lui envoyer des requêtes en cas de défaillance. La figure 1 présente les éléments de base de la répartition de charge.

Figure 1 : Composants de la répartition de charge

Lorsque le répartiteur de charge reçoit une requête du client, l'un des serveurs du groupe la traite. Chaque serveur est capable de traiter cette requête de façon indépendante. Si un serveur est indisponible par suite d'une erreur ou d'une intervention de maintenance, les autres peuvent continuer à traiter les requêtes sans en être affectés. De ce fait, la disponibilité générale du service est bien meilleure que lorsqu'un seul serveur traite l'ensemble des demandes. Cependant, l'utilisation d'un seul répartiteur de charge physique ou d'un seul commutateur réseau devant un ensemble de serveurs employant un système logiciel de répartition de charge introduit un autre point de défaillance unique. Pour pallier ce risque, vous pouvez faire appel à des dispositifs de répartition de charge et/ou des commutateurs redondants.

Gestion d'état des sessions

Les applications ont souvent besoin, dans le cadre des différentes étapes d'un cas d'utilisation complexe, d'une interaction de l'utilisateur.Chaque réponse apportée par l'utilisateur pendant l'interaction affecte les choix qui lui sont proposés et l'état de l'application, au fur et à mesure qu'elle progresse vers les objectifs souhaités.Le terme état de session sert généralement à décrire cet état centré sur le cas d'utilisation.Une partie de l'état de session sert uniquement à suivre la progression dans la tâche ; ces informations sont supprimées une fois le cas d'utilisation terminé ; d'autres éléments de l'état de session sont enregistrés dans le stockage à long terme, dans la base de données, si le cas d'utilisation est mené à bien.Ainsi, il est rare que l'on demande à un client qui effectue des achats en ligne de fournir des informations de règlement ou de livraison avant qu'il ait sélectionné le bouton de validation, lequel n'est activé que si son panier contient au moins un article.

En règle générale, les applications distribuées appellent des composants logiciels situés sur des serveurs distants via une connexion réseau.L'application doit suivre les changements de l'état de session qui se produisent entre chaque étape, pour assurer une continuité entre ces étapes.Les concepteurs d'applications tiennent généralement à jour l'état de session dans l'un de ces trois emplacements :

• Client.L'état de session de chaque utilisateur est conservé sur l'ordinateur de ce dernier.
• Serveur Intermédiaire.L'état de session est stocké sur un ordinateur qui sert d'intermédiaire entre les ordinateurs clients et les serveurs de bases de données, où les informations de l'utilisateur sont conservées de façon permanente.
• Serveur de bases de données.L'état de session est stocké sur le serveur de bases de données, en même temps que d'autres données à long terme de l'application et de l'utilisateur.

Seule la solution avec serveur intermédiaire affecte ce modèle.Chacune de ces solutions, ses avantages et ses inconvénients sont décrits en détail dans le chapitre 2, « Designing for Scalability » de l'ouvrage « Designing for Scalability with Microsoft Windows DNA » (Conception axée sur l'évolutivité avec Microsoft Windows DNA) [Sundblad00].

Une solution simple, telle que celle de la figure 1, convient lorsque tous les serveurs sont sans état : une fois qu'un serveur a répondu à une requête, son état par défaut est rétabli.Un serveur peut être sans état dans deux cas de figure.Dans le premier, le client n'a pas besoin de session ; chaque demande étant une unité de travail isolée, aucune valeur temporaire ne persiste entre les sessions.Dans le second scénario, appelé gestion de session par le client, c'est le client lui-même qui conserve l'état d'une session et envoie les informations relatives à cet état dans la requête, de sorte que tout serveur peut la prendre en charge et poursuivre son traitement.

Dans les scénarios avec gestion de session par le serveur, c'est le serveur qui tient à jour l'état des sessions utilisateur.Avec la gestion de session par le serveur, le répartiteur de charge dirige toutes les requêtes envoyées par un client à partir de la même session utilisateur à la même instance de serveur.Ce mécanisme est généralement désigné sous le nom d'affinité de serveur.

L'une des difficultés propres à la gestion de session est que, si le serveur passe hors ligne par suite d'une erreur ou d'une intervention de maintenance, le client risque de perdre le travail effectué ; il est alors obligé de renvoyer toutes les requêtes transmises auparavant à partir de la session perdue.Dans certaines situations, la perte occasionnelle de sessions ne constitue pas un problème majeur pour l'utilisateur.Par exemple, dans une application de consultation de plans en ligne, si le serveur perd l'adresse que l'utilisateur vient de saisir, l'obligation pour ce dernier de ressaisir l'information ne prête pas réellement à conséquences.Dans d'autres situations, cependant, la perte de session peut s'avérer extrêmement gênante.Ainsi, dans une application de gestion de crédit bail utilisant un client sans état, l'utilisateur peut passer jusqu'à 10 minutes pour saisir les informations requises pour l'établissement du contrat.Il n'est certes pas souhaitable que l'utilisateur consacre à nouveau le même temps à ressaisir toutes les informations si l'un des serveurs du groupe de répartition de charge est déconnecté.Pour éviter toute perte de session due à une défaillance de serveur dans un groupe répartition de charge, deux solutions peuvent être envisagées :la gestion d'état centralisée et la gestion asynchrone d'état des sessions.La figure 2 illustre la gestion d'état centralisée.

Figure 2 : Répartition de charge et gestion d'état centralisée

Dans la méthode de gestion d'état centralisée, les informations d'état de la session sont stockées sur un serveur centralisé situé à un niveau différent des serveurs d'application.Chaque fois que le serveur d'application reçoit une requête faisant partie d'une session, il extrait l'état de cette dernière du serveur de gestion des sessions avant de la traiter.Le service de gestion des sessions peut être une base de données ou un autre type d'application qui s'exécute sur un serveur stockant des ressources partagées, configuré pour une haute fiabilité.Pour plus d'informations sur les méthodes permettant d'améliorer la tolérance de pannes, consultez le modèle Failover Cluster.

La figure 3 illustre la gestion asynchrone d'état des sessions.

Figure 3 : Répartition de charge et gestion asynchrone d'état des sessions

Dans le cas de la gestion asynchrone d'état des sessions, chaque serveur diffuse à tous les autres serveurs son état de session, dès que celui-ci change ; ainsi, chacun d’eux dispose des informations d’état de toutes les sessions et peut traiter une requête faisant partie d’une session.L’état des sessions persiste, même en cas de défaillance de serveurs individuels.Cette solution, plus économique du fait qu'elle n'impose pas l'acquisition de matériel supplémentaire, est plus complexe en termes de configuration et de maintenance car elle implique des appels asynchrones.De plus, le stockage de l’état de toutes les sessions sur chaque serveur peut s’avérer moins efficace.

Implémentation

L’implémentation de la répartition de charge prend principalement deux formes :

• Répartition de charge par logiciel.La répartition de charge par logiciel s’effectue au moyen d’un logiciel spécial installé sur les serveurs d’un cluster avec répartition de charge.Ce logiciel reçoit les requêtes des clients et les distribue aux serveurs en fonction de différents algorithmes.Il peut s’agir de simples algorithmes Round-robin (répartition de charge équitable) ou d’algorithmes bien plus complexes, qui tiennent compte de l’affinité des serveurs.Par exemple, Microsoft® NLB (Network Load Balancing, Équilibrage de la charge réseau) est un logiciel de répartition de charge destiné aux batteries de serveurs Web, tandis que Microsoft CLB (Component Load Balancing, Équilibrage de la charge des composants) est un logiciel de répartition de charge destiné aux batteries d’applications.
• Répartition de charge par matériel.La répartition de charge par matériel repose sur un commutateur ou un routeur spécialisé muni du logiciel qui lui procure les fonctionnalités de répartition de charge.Dans ce type de solution, les fonctions de commutation et de répartition de charge sont intégrées au sein d’un seul dispositif, ce qui limite le matériel nécessaire pour mettre en œuvre la répartition de charge.Toutefois, du fait que les deux fonctions sont associées, le dépannage du dispositif est plus complexe.

Exemple

Pour vous aider à comprendre comment optimiser l’évolutivité à l'aide de la répartition de charge, nous allons comparer une solution déjà en place, composée d'un système unique (point de défaillance unique) au niveau application et n’offrant pas de capacité de répartition de charge, et une solution très évolutive qui préserve les performances tout en renforçant la disponibilité.

Niveau sans répartition de charge

Au départ, une entreprise peut commencer avec une architecture telle que celle que présente la figure 4, susceptible de répondre à ses attentes initiales en matière de performances.Avec l’augmentation de la charge, cependant, le niveau applicatif doit s’adapter pour continuer à offrir des performances acceptables.

Figure 4 : Solution de base avec un seul serveur d’application

Dans la figure 4, le niveau application contient un seul serveur d’application (AppServer20), qui traite les demandes des clients.Si le serveur est surchargé, la solution passera en deçà du seuil de performances acceptable, ou deviendra indisponible.

Niveau avec répartition de charge

Pour rendre son infrastructure plus évolutive et préserver les performances, l’entreprise peut faire appel à un répartiteur de charge afin de renforcer le niveau application.Dans l’exemple suivant, illustré Figure 5, deux serveurs sont ajoutés au niveau application pour créer un cluster avec répartition de charge, qui accède aux informations stockées au niveau données et fournit, dans le niveau client, l’accès des postes clients aux applications.

Figure 5 : Solution avec un niveau application évolutif

Ce type de solution produit une architecture de répartition de charge standard.Un dispositif matériel ou un logiciel qui s’exécute sur les machines hôtes affecte un nom d’hôte virtuel (AppServer20) et une adresse IP à AppServer1, AppServer2, et AppServer3.Le cluster avec répartition de charge présente cette adresse IP virtuelle et ce nom d’hôte au réseau, et répartit équitablement la charge des requêtes entrantes entre les serveurs opérationnels du groupe.En cas de défaillance d’AppServer1, la requête est simplement redirigée vers AppServer2 ou AppServer3.Selon la technologie employée pour fournir ces fonctionnalités, il est possible d’ajouter des serveurs supplémentaires au cluster avec répartition de charge, de manière offrir une disponibilité maximale et anticiper l’augmentation de la demande.

Contexte final

Le modèle avec Load-Balanced Cluster présente les avantages et les inconvénients suivants :

Avantages

• Évolutivité renforcée.Un niveau de répartition de charge évolutif permet de conserver des performances acceptables et de renforcer la disponibilité.
• Disponibilité accrue.Dans un système avec répartition de charge, vous pouvez mettre hors ligne un serveur pour assurer sa maintenance, sans rendre des applications indisponibles.
• Économies potentielles.L’utilisation de plusieurs serveurs peu onéreux s’avère plus économique que le recours à des systèmes multiprocesseurs au coût élevé.

Inconvénients

• Complexité du développement.Dans les situations où il est nécessaire de conserver l’état pour chaque transaction ou chaque utilisateur, le développement d’une solution avec répartition de charge peut être complexe.
• Défaillances du réseau non prises en compte.En cas de défaillance d’un serveur ou du réseau pendant une session client, il peut être nécessaire de procéder à une nouvelle ouverture de session, afin d’authentifier à nouveau le client et de rétablir l’état de la session.

Modèles connexes

Pour obtenir davantage d'informations, reportez-vous aux modèles connexes suivants :

• Server Clustering .La mise en cluster de serveurs aborde l'utilisation de ressources informatiques virtuelles pour augmenter l'évolutivité et éliminer les points de défaillance uniques qui affectent la disponibilité.
• Failover Cluster .Les clusters de basculement permettent de doter l’infrastructure d’éléments redondants, et donc d’en accroître la disponibilité.

Dernière mise à jour le jeudi 27 novembre 2003