Équilibrage de charge
- 9 minutes
Effectuer un scale-out en mettant en ligne de nouvelles machines virtuelles quand le trafic augmente est une stratégie efficace de mise à l’échelle pour répondre à la demande. Le fait que les machines virtuelles puissent être provisionnées rapidement est essentiel pour obtenir l’élasticité. Toutefois, la mise en ligne de serveurs supplémentaires ne s’avère utile que si le trafic est réparti entre ces serveurs. Globalement, cela aide le système à gérer l’augmentation de la charge. C’est pourquoi l’équilibrage de charge est aussi critique pour l’élasticité que l’adaptation dynamique du nombre de ressources consacrées à une tâche.
La nécessité de l’équilibrage de charge est due à deux exigences de base. Tout d’abord, le débit est amélioré par le traitement en parallèle. Si un seul serveur peut gérer 5 000 demandes par unité de temps, 10 serveurs à charge parfaitement équilibrée peuvent traiter 50 000 demandes par unité de temps. Ensuite, les ressources à charge équilibrée offrent une plus haute disponibilité. Au lieu de transférer une demande à un serveur qui a déjà du mal à répondre, un équilibreur de charge peut diriger la demande vers un serveur dont la charge est plus légère. De plus, si un serveur est mis hors connexion et que l’équilibreur de charge le reconnaît, il peut diriger les demandes vers d’autres serveurs.
Qu’est-ce que l’équilibrage de charge ?
Une forme bien connue d’équilibrage de charge est le DNS de tourniquet, que de nombreux services web volumineux utilisent pour distribuer des requêtes entre plusieurs serveurs. Plus précisément, plusieurs serveurs front-end, chacun avec une adresse IP unique, partagent un nom DNS. Pour équilibrer le nombre de demandes sur chaque serveur web, les grandes entreprises telles que Google tiennent à jour et organisent un pool d’adresses IP pour chaque entrée DNS. Lorsqu’un client effectue une demande (par exemple, pour www.google.com), le DNS de Google sélectionne l’une des adresses disponibles du pool et l’envoie au client. La stratégie la plus simple permettant de distribuer des adresses IP consiste à utiliser une file d’attente de tourniquet (round robin) où, après chaque réponse DNS, la liste d’adresses est permutée.
Avant l’arrivée du cloud, l’équilibrage de charge DNS était un moyen simple de réduire la latence des connexions longue distance. Le répartiteur sur le serveur DNS a été programmé pour répondre avec l’adresse IP du serveur géographiquement le plus proche du client. Le moyen le plus simple de procéder consiste à répondre à l’adresse IP du pool qui était numériquement le plus proche de l’adresse IP du client. Cette méthode n’était pas fiable, car les adresses IP ne sont pas distribuées dans une hiérarchie globale. Les techniques actuelles sont plus sophistiquées et s’appuient sur un mappage logiciel d’adresses IP à des endroits basés sur des cartes physiques de fournisseurs de services Internet. Étant donné que ce mappage est implémenté en tant que recherche de logiciels coûteuse, cette méthode donne de meilleurs résultats, mais son calcul est coûteux. Toutefois, le coût d’une recherche lente est amorti car la recherche DNS se produit uniquement quand la première connexion à un serveur est effectuée par le client. Toutes les communications ultérieures se produisent directement entre le client et le serveur qui possède l’adresse IP distribuée. La figure 9 illustre un exemple de schéma d’équilibrage de charge DNS.
Figure 9 : Équilibrage de charge dans un environnement cloud.
L’inconvénient de cette méthode réside dans une défaillance du serveur. Le basculement vers une autre adresse IP dépend de la configuration de la durée de vie (TTL) du cache DNS. Les entrées DNS sont connues pour être à longue durée de vie et les mises à jour sont connues pour mettre une semaine à se propager. Cela signifie qu’il est difficile de « masquer » rapidement une défaillance de serveur pour le client. La réduction de la durée de validité (TTL) d’une adresse IP dans le cache améliore cette situation au détriment des performances et d’une augmentation du nombre de recherches.
L’équilibrage de charge moderne fait souvent référence à l’utilisation d’une instance dédiée (ou d’une paire d’instances) pour distribuer les demandes entrantes aux serveurs back-end. Pour chaque demande entrante sur un port spécifié, l’équilibreur de charge redirige le trafic vers l’un des serveurs back-end en fonction d’une stratégie de distribution. Ainsi, l’équilibreur de charge tient à jour les métadonnées des demandes, notamment des informations telles que les en-têtes de protocole d’application (par exemple, les en-têtes HTTP). Dans ce cas, les informations obsolètes ne sont pas un problème quand chaque demande passe par l’équilibreur de charge.
Bien que tous les types d’équilibreurs de charge réseau transfèrent les requêtes avec n’importe quel contexte aux serveurs principaux, lorsqu’il s’agit de servir la réponse au client, ils peuvent utiliser l’une des deux stratégies de base1 :
Utilisation de proxy : dans cette approche, l’équilibreur de charge reçoit la réponse du back-end et la retransmet au client. L’équilibreur de charge se comporte comme un proxy web standard et est impliqué dans les deux moitiés d’une transaction réseau, à savoir transférer la demande au client et renvoyer la réponse.
Transfert TCP : dans cette approche, la connexion TCP avec le client est transmise au serveur back-end et le serveur envoie la réponse directement au client, sans passer par l’équilibreur de charge.
La deuxième de ces stratégies est illustrée dans la figure 10.
Figure 10 : Mécanisme de transfert TCP du répartiteur vers le serveur principal.
Avantages de l’équilibrage de charge
L’un des avantages de l’équilibrage de charge est qu’il permet de masquer les défaillances d’un système. Tant que le client est exposé à un point de terminaison unique qui représente plusieurs ressources, les défaillances dans des ressources individuelles sont masquées pour le client en envoyant les demandes à l’aide d’autres ressources. Désormais, cependant, l’équilibreur de charge lui-même devient un point de défaillance unique. En cas d’échec pour une raison quelconque, même si tous les serveurs back-end continuent de fonctionner, aucune demande du client ne sera traitée. Par conséquent, pour obtenir une haute disponibilité, les équilibreurs de charge sont souvent implémentés par paires.
Plus important encore, l’équilibrage de charge améliore la réactivité en répartissant les charges de travail entre plusieurs ressources de calcul dans le cloud. Avoir une seule instance de calcul dans le cloud présente plusieurs limitations. Les modules précédents ont abordé la limitation physique applicable aux performances, où davantage de ressources sont nécessaires pour augmenter les charges de travail. En utilisant l’équilibrage de charge, les charges de travail plus importantes sont réparties entre plusieurs ressources afin que chaque ressource puisse traiter ses demandes indépendamment et en parallèle, ce qui améliore le débit de l’application. L’équilibrage de charge améliore également les temps de réponse moyens, car il y a plus de serveurs pour gérer la charge de travail.
Les contrôles d’intégrité sont essentiels pour implémenter des stratégies d’équilibrage de charge réussies. Un équilibreur de charge doit savoir quand une ressource devient indisponible, ce qui lui permet d’éviter de transférer le trafic vers cette ressource. La supervision Ping Echo, dans laquelle l’équilibreur de charge effectue un test « ping » sur des serveurs avec des demandes ICMP (Internet Control Message Protocol), est l’une des tactiques les plus populaires utilisées pour vérifier l’intégrité de ressources spécifiques. Outre la prise en considération de l’intégrité d’une ressource lors de la transmission du trafic vers celle-ci, certaines stratégies d’équilibrage de charge prend en compte d’autres métriques comme le débit, la latence et l’utilisation du processeur.
Les équilibreurs de charge doivent souvent garantir une haute disponibilité. La façon la plus simple de procéder consiste à créer plusieurs instances d’équilibrage de charge (chacune avec une adresse IP unique) et à les lier chacune à une seule adresse DNS. Chaque fois qu’un équilibreur de charge échoue pour une raison quelconque, il est remplacé par un nouveau, et tout le trafic est transmis à l’instance de basculement avec un impact minime sur les performances. Simultanément, une nouvelle instance d’équilibreur de charge peut être configurée pour remplacer celle ayant échoué, et les enregistrements DNS doivent être immédiatement mis à jour.
En plus de répartir les demandes entre les serveurs back-end, les équilibreurs de charge utilisent souvent des mécanismes permettant de réduire la charge sur les serveurs et d’améliorer le débit global. Ces mécanismes sont, entre autres, les suivants :
Déchargement SSL : les connexions HTTPS entraînent des coûts de performances supplémentaires, car le trafic sur ces derniers est chiffré. Au lieu de traiter toutes les demandes via le protocole SSL (Secure Sockets Layer), la connexion client à l’équilibreur de charge peut être établie via SSL, tandis que les demandes de redirection vers chaque serveur sont effectuées via le protocole HTTP non chiffré. Cette technique réduit considérablement la charge sur les serveurs. De plus, la sécurité est assurée tant que les demandes de redirection ne sont pas effectuées sur un réseau ouvert.
Mise en mémoire tampon TCP : stratégie visant à décharger les clients avec des connexions lentes vers l’équilibreur de charge afin de soulager les serveurs qui envoient des réponses à ces clients.
Mise en cache : dans certains scénarios, l’équilibreur de charge peut conserver un cache pour les requêtes les plus populaires (ou les requêtes qui peuvent être gérées sans accéder aux serveurs, comme le contenu statique) pour réduire la charge sur les serveurs.
Mise en forme du trafic : un équilibreur de charge peut utiliser cette technique pour retarder ou réorienter le flux de paquets afin d’optimiser le trafic pour la configuration du serveur. Cela affecte la qualité de service (QoS) pour certaines demandes, mais garantit que la charge entrante peut être traitée.
Il est important de retenir que l’équilibrage de charge ne fonctionne que si l’équilibreur de charge lui-même n’est pas soumis à une charge insurmontable. Dans le cas contraire, l’équilibreur de charge devient le goulot d’étranglement. Heureusement, les équilibreurs de charge ont tendance à effectuer un faible traitement sur les demandes qu’ils reçoivent, s’appuyant plutôt sur les serveurs back-end pour effectuer le travail réel que constitue la transformation des demandes en réponses.
Répartition équitable
Plusieurs stratégies d’équilibrage de charge sont utilisées dans le cloud. L’un des plus courants est la répartition équitable, qui utilise un algorithme de tourniquet simple pour distribuer le trafic uniformément entre tous les nœuds. Elle ne prend pas en compte l’utilisation de ressources individuelles dans le système, ni le temps d’exécution des demandes. Cette approche, qui est l’une des plus simples à implémenter, tente de maintenir chaque nœud du système occupé.
AWS l’utilise dans son offre Elastic Load Balancer (ELB). ELB provisionne des équilibreurs de charge qui équilibrent le trafic entre les instances EC2 attachées. Les équilibreurs de charge sont essentiellement des instances EC2 proprement dites avec un service spécifiquement destiné à acheminer le trafic. À mesure que les ressources situées derrière l’équilibreur de charge font l’objet d’un scale-out, les adresses IP des nouvelles ressources sont mises à jour sur l’enregistrement DNS de l’équilibreur de charge. Ce processus prend quelques minutes car il nécessite du temps pour la supervision et pour le provisionnement. Cette période de mise à l’échelle (le temps d’attente jusqu’à ce que l’équilibreur de charge soit prêt à gérer la charge la plus élevée) est appelée « préchauffage » de l’équilibreur de charge.
Les équilibreurs de charge AWS supervisent également les ressources qui leur sont attachées pour la distribution de la charge de travail afin de tenir à jour une vérification d’intégrité. Un mécanisme Ping Echo est utilisé pour garantir l’intégrité de toutes les ressources. Les utilisateurs ELB peuvent configurer les paramètres de la vérification d’intégrité en spécifiant les retards et le nombre de nouvelles tentatives.
Distribution basée sur le hachage
Cette approche tente de vérifier que les demandes émanant du même client pendant la durée d’une session sont dirigées à chaque fois vers le même serveur en hachant les métadonnées qui définissent chaque demande et en utilisant le hachage pour choisir un serveur. Si le hachage est effectué correctement, les demandes sont distribuées de manière relativement équitable entre les serveurs. Un avantage de cette approche est qu’elle se prête aux applications prenant en charge les sessions, lesquelles peuvent stocker des données de session en mémoire plutôt que de les écrire dans un magasin de données partagé comme base de données ou un cache Redis. L’un des inconvénients est que chaque demande doit être hachée, ce qui introduit une faible latence.
Azure Load Balancer utilise un mécanisme basé sur le hachage pour répartir les charges. Ce mécanisme crée un hachage pour chaque demande en fonction de l’adresse IP source, du port source, de l’adresse IP de destination, du port de destination et du type de protocole afin de garantir que, dans des circonstances ordinaires, chaque paquet de la même session atteint le même serveur back-end. La fonction de hachage est choisie afin que la répartition des connexions aux serveurs soit aléatoire.
Autres stratégies d’équilibrage de charge
Si un serveur particulier perd du temps à traiter une demande (ou un ensemble de demandes), les équilibreurs de charge qui utilisent des algorithmes de répétition alternée (round robin) ou basée sur le hachage lui transfèrent tout de même les demandes. Il existe d’autres stratégies plus sophistiquées pour équilibrer les charges entre plusieurs ressources qui prennent en compte la capacité. Deux des métriques les plus couramment utilisées pour évaluer la capacité sont les suivantes :
Temps d’exécution des requêtes : les stratégies basées sur cette métrique utilisent un algorithme de planification de priorité, dans lequel les temps d’exécution des requêtes sont utilisés pour choisir la destination pour les requêtes individuelles. Avec cette approche, le principal défi est d’évaluer avec précision les durées d’exécution. Un équilibreur de charge peut deviner les durées d’exécution en utilisant (et en mettant constamment à jour) une table en mémoire qui stocke les différences entre le moment où une demande est transférée à chaque serveur et le moment où elle obtient un retour.
Utilisation des ressources : les stratégies basées sur cette métrique utilisent l’utilisation du processeur pour équilibrer l’utilisation entre les nœuds. L’équilibreur de charge tient à jour une liste triée des ressources en fonction de leur utilisation et dirige chaque demande qu’il reçoit vers la ressource présentant la charge la moins importante.
L’équilibrage de charge est essentiel pour implémenter des services cloud scalables. Si vous ne disposez pas d’un moyen efficace pour répartir le trafic entre les ressources back-end, l’élasticité obtenue en créant des ressources quand elles sont nécessaires et en annulant leur provisionnement quand elles ne le sont pas est sérieusement limitée.
Références
- Aron, Mohit et Sanders, Darren et Druschel, Peter et Zwaenepoel, Willy (2000). "Scalable content-aware request distribution in cluster-based network servers", Actes de la 2000 Annual USENIX Technical Conference
Contrôle des connaissances
Commentaires
Cette page a-t-elle été utile ?
No
Vous avez besoin d’aide pour cette rubrique ?
Vous souhaitez essayer d’utiliser Ask Learn pour clarifier ou vous guider dans cette rubrique ?