Introduction à HAProxy et aux concepts d’équilibrage de charge

Introduction

HAProxy, qui signifie Proxy Haute Disponibilité, est un logiciel open source populaire de répartition de charge TCP/HTTP et de solution de proxy qui peut être exécuté sur Linux, macOS et FreeBSD. Son utilisation la plus courante est d’améliorer les performances et la fiabilité d’un environnement de serveur en répartissant la charge de travail sur plusieurs serveurs (par exemple, web, application, base de données). Il est utilisé dans de nombreux environnements de grande envergure, notamment : GitHub, Imgur, Instagram et Twitter.

Dans ce guide, vous obtiendrez un aperçu général de ce qu’est HAProxy, passerez en revue la terminologie de la répartition de charge et des exemples de la manière dont il pourrait être utilisé pour améliorer les performances et la fiabilité de votre propre environnement de serveur.

Terminologie HAProxy

Il existe de nombreux termes et concepts importants lorsqu’il s’agit de répartition de charge et de proxy. Vous passerez en revue les termes couramment utilisés dans les sous-sections suivantes.

Avant d’aborder les types de base de répartition de charge, vous devriez commencer par passer en revue les ACL, les arrières-plans et les avant-plans.

Liste de Contrôle d’Accès (ACL)

En ce qui concerne l’équilibrage de charge, les ACL sont utilisées pour tester une condition et effectuer une action (par exemple, sélectionner un serveur ou bloquer une demande) en fonction du résultat du test. L’utilisation des ACL permet un transfert flexible du trafic réseau basé sur divers facteurs tels que la correspondance de motifs et le nombre de connexions à un backend, par exemple.

Exemple d’une ACL :

acl url_blog path_beg /blog

Cette ACL est vérifiée si le chemin de la demande d’un utilisateur commence par /blog. Cela correspondrait à une demande de http://votredomaine.com/blog/article-de-blog-1, par exemple.

Pour un guide détaillé sur l’utilisation des ACL, consultez le Manuel de Configuration HAProxy.

Backend

A backend is a set of servers that receives forwarded requests. Backends are defined in the backend section of the HAProxy configuration. In its most basic form, a backend can be defined by:

• quel algorithme d’équilibrage de charge utiliser
• a list of servers and ports

A backend can contain one or many servers in it. Generally speaking, adding more servers to your backend will increase your potential load capacity by spreading the load over multiple servers. Increased reliability is also achieved through this manner, in case some of your backend servers become unavailable.

Voici un exemple de configuration à deux backends, web-backend et blog-backend avec deux serveurs web chacun, écoutant sur le port 80 :

backend web-backend
   balance roundrobin
   server web1 web1.yourdomain.com:80 check
   server web2 web2.yourdomain.com:80 check
   
backend blog-backend
   balance roundrobin
   mode http
   server blog1 blog1.yourdomain.com:80 check
   server blog1 blog1.yourdomain.com:80 check

La ligne balance roundrobin spécifie l’algorithme d’équilibrage de charge, qui est détaillé dans la section Algorithmes d’Équilibrage de Charge.

mode http spécifie que le proxy de couche 7 sera utilisé, ce qui est expliqué dans la section Types de répartition de charge.

L’option check à la fin des directives server spécifie que des vérifications d’état de santé doivent être effectuées sur ces serveurs backends.

Frontend

A frontend defines how requests should be forwarded to backends. Frontends are defined in the frontend section of the HAProxy configuration. Their definitions are composed of the following components:

• a set of IP addresses and a port (e.g. 10.1.1.7:80, *:443, etc.)
• ACLs
• Règles use_backend, qui définissent quels backends utiliser en fonction des conditions ACL correspondantes, et/ou une règle default_backend qui gère tous les autres cas

A frontend can be configured to various types of network traffic, as explained in the next section.

Types de répartition de charge

Maintenant que vous avez compris les composants de base utilisés dans la répartition de charge, vous pouvez passer aux types de répartition de charge de base.

Aucune répartition de charge

A simple web application environment with no load balancing might look like the following:

Dans cet exemple, l’utilisateur se connecte directement à votre serveur web, à yourdomain.com et il n’y a pas de répartition de charge. Si votre serveur web unique tombe en panne, l’utilisateur ne pourra plus accéder à votre serveur web. De plus, si de nombreux utilisateurs essaient d’accéder à votre serveur simultanément et qu’il est incapable de gérer la charge, ils peuvent avoir une expérience lente ou ne pas pouvoir se connecter du tout.

Équilibrage de charge de couche 4

La façon la plus simple d’équilibrer la charge du trafic réseau vers plusieurs serveurs est d’utiliser l’équilibrage de charge de couche 4 (couche de transport). Équilibrer la charge de cette manière va rediriger le trafic utilisateur en fonction de la plage d’adresses IP et du port (c’est-à-dire que si une demande arrive pour http://yourdomain.com/anything, le trafic sera redirigé vers le serveur qui gère toutes les demandes pour yourdomain.com sur le port 80). Pour plus de détails sur la couche 4, consultez la sous-section TCP de notre Introduction aux Réseaux.

Voici un schéma d’un exemple simple d’équilibrage de charge de couche 4 :

L’utilisateur accède au répartiteur de charge, qui redirige la demande de l’utilisateur vers le groupe de serveurs backend web-backend. Le serveur backend sélectionné répondra directement à la demande de l’utilisateur. En général, tous les serveurs du web-backend devraient servir un contenu identique, sinon l’utilisateur pourrait recevoir un contenu incohérent. Notez que les deux serveurs web se connectent au même serveur de base de données.

Équilibrage de charge de couche 7

Une autre manière, plus complexe, d’équilibrer le trafic réseau est d’utiliser l’équilibrage de charge de la couche 7 (couche d’application). En utilisant la couche 7, le répartiteur de charge peut transférer les demandes vers différents serveurs backend en fonction du contenu de la demande de l’utilisateur. Ce mode d’équilibrage de charge vous permet d’exécuter plusieurs serveurs d’application web sous le même domaine et le même port. Pour plus de détails sur la couche 7, consultez la sous-section HTTP de notre Introduction aux Réseaux.

Voici un diagramme d’un exemple simple d’équilibrage de charge de la couche 7:

Dans cet exemple, si un utilisateur demande votredomaine.com/blog, il est redirigé vers le backend blog, qui est un ensemble de serveurs exécutant une application de blog. Les autres demandes sont redirigées vers web-backend, qui pourrait exécuter une autre application. Les deux backends utilisent le même serveur de base de données, dans cet exemple.

A snippet of the example frontend configuration would look like this:

frontend http
  bind *:80
  mode http

  acl url_blog path_beg /blog
  use_backend blog-backend if url_blog
 
  default_backend web-backend

Cela configure un frontend nommé http, qui gère tout le trafic entrant sur le port 80.

acl url_blog path_beg /blog correspond à une demande si le chemin de la demande de l’utilisateur commence par /blog.

use_backend blog-backend if url_blog utilise la liste de contrôle d’accès (ACL) pour acheminer le trafic vers blog-backend.

default_backend web-backend spécifie que tout autre trafic sera redirigé vers web-backend.

Algorithmes d’équilibrage de charge

L’algorithme d’équilibrage de charge utilisé détermine le serveur qui sera sélectionné dans un backend lors de l’équilibrage de charge. HAProxy propose plusieurs options d’algorithmes. En plus de l’algorithme d’équilibrage de charge, les serveurs peuvent se voir attribuer un paramètre de poids pour manipuler leur fréquence de sélection par rapport aux autres serveurs.

A few of the commonly used algorithms are as follows:

roundrobin

Round Robin sélectionne les serveurs à tour de rôle. C’est l’algorithme par défaut.

leastconn

Sélectionne le serveur avec le moins de connexions. Ceci est recommandé pour des sessions plus longues. Les serveurs dans le même groupe sont également tournés de manière circulaire.

source

Cela sélectionne quel serveur utiliser en fonction d’un hachage de l’adresse IP source à partir de laquelle les utilisateurs font des requêtes. Cette méthode garantit que les mêmes utilisateurs se connecteront aux mêmes serveurs.

Sessions persistantes

Certaines applications nécessitent qu’un utilisateur continue à se connecter au même serveur de backend. Cela peut être réalisé grâce à des sessions persistantes, en utilisant le paramètre appsession dans le backend qui en a besoin.

Vérification de l’état de santé

HAProxy utilise des vérifications de santé pour déterminer si un serveur de backend est disponible pour traiter les requêtes. Cela évite de devoir retirer manuellement un serveur du backend s’il devient indisponible. La vérification de santé par défaut consiste à essayer d’établir une connexion TCP avec le serveur.

Si un serveur échoue à une vérification de santé et est donc incapable de répondre aux demandes, il est automatiquement désactivé dans le backend et le trafic ne lui sera pas transmis jusqu’à ce qu’il redevienne sain. Si tous les serveurs d’un backend échouent, le service deviendra indisponible jusqu’à ce qu’au moins l’un de ces serveurs backend redevienne sain.

Pour certains types de backends, comme les serveurs de base de données, la vérification de santé par défaut ne vise pas nécessairement à déterminer si un serveur est toujours sain.

Le serveur web Nginx peut également être utilisé en tant que serveur proxy autonome ou répartiteur de charge, et est souvent utilisé en conjonction avec HAProxy pour ses capacités de mise en cache et de compression.

Haute Disponibilité

Les configurations d’équilibrage de charge de niveau 4 et 7 décrites dans ce tutoriel utilisent toutes deux un répartiteur de charge pour diriger le trafic vers l’un des nombreux serveurs backend. Cependant, votre répartiteur de charge est un point de défaillance unique dans ces configurations ; s’il tombe en panne ou est submergé par les demandes, cela peut entraîner une latence élevée ou une interruption de service pour votre service.

A high availability (HA) setup is broadly defined as infrastructure without a single point of failure. It prevents a single server failure from being a downtime event by adding redundancy to every layer of your architecture. A load balancer facilitates redundancy for the backend layer (web/app servers), but for a true high availability setup, you need to have redundant load balancers as well.

Voici un schéma d’une configuration de haute disponibilité :

Dans cet exemple, vous avez plusieurs équilibreurs de charge (un actif et un ou plusieurs passifs) derrière une adresse IP statique qui peut être remappée d’un serveur à un autre. Lorsqu’un utilisateur accède à votre site web, la demande passe par l’adresse IP externe jusqu’à l’équilibreur de charge actif. Si cet équilibreur de charge échoue, votre mécanisme de basculement détectera automatiquement le problème et réaffectera l’adresse IP à l’un des serveurs passifs. Il existe plusieurs façons différentes de mettre en œuvre une configuration HA active/passive. Pour en savoir plus, lisez Comment Utiliser les Adresses IP Réservées.

Conclusion

Maintenant que vous avez compris le fonctionnement de l’équilibrage de charge et que vous savez comment utiliser HAProxy, vous disposez d’une base solide pour commencer à améliorer les performances et la fiabilité de votre propre environnement serveur.

Si vous êtes intéressé par la sauvegarde de la sortie de HAProxy pour une consultation ultérieure, consultez Comment Configurer le Journalisation de HAProxy avec Rsyslog sur CentOS 8 [Démarrage Rapide].

Si vous cherchez à résoudre un problème, consultez les Erreurs courantes d’HAProxy. Si un dépannage plus approfondi est nécessaire, jetez un œil à Comment dépanner les erreurs courantes d’HAProxy.