haproxy configuration

Regardez notre webinaire à la demande « Introduction à HAProxy » pour en savoir plus sur les fondamentaux de la répartition de charge avec HAProxy.

Un fichier de configuration HAProxy guide le comportement de votre répartiteur de charge HAProxy. Cet article de blog vous présente ses quatre sections les plus essentielles.

Un fichier de configuration HAProxy comprend quatre sections essentielles. Elles sont global, defaults, frontend et backend. Ces quatre sections définissent comment le serveur doit fonctionner dans son ensemble, ses paramètres par défaut et comment HAProxy doit recevoir et acheminer les requêtes des clients vers les serveurs en backend.

Si vous comparez le monde des proxies inversés à une course de relais olympique, les coureurs vedettes seraient les sections global, defaults, frontend et backend. Chacune joue un rôle essentiel, passant le témoin au suivant. Comme une équipe de relais, la puissance et les performances d’un répartiteur de charge HAProxy sont obtenues en combinant les attributs uniques de chaque section. Rencontrons-les et voyons comment elles s’associent.

Le format

Si vous utilisez les fonctionnalités avancées de HAProxy Enterprise, vous trouverez le fichier de configuration ici : /etc/hapee-1.8/hapee-lb.cfg. Si vous utilisez l’édition Community, c’est ici : /etc/haproxy/haproxy.cfg. Vous pouvez tester vos modifications de configuration avec l’exécutable haproxy avec le paramètre -c, tel que :

La structure de ce fichier est la suivante:

Une section commence lorsque HAProxy rencontre un mot-clé comme global ou defaults et comprend toutes les lignes qui suivent jusqu’à ce qu’elle atteigne un autre mot-clé pour une nouvelle section. Les lignes vides et l’indentation sont ignorées. Ainsi, la section global continue jusqu’à ce que vous arrivez, par exemple, à un mot-clé defaults sur sa propre ligne.

Imaginons que vous avez un seul site Web que vous mettez à la disposition des clients, tel que www.mysite.com. Votre réseau privé inclue deux serveurs Web (à des fins de démonstration) qui hébergent les fichiers de ce site. Vous répartissez la charge de ces deux serveurs, afin qu’ils se relaient pour recevoir et répondre aux requêtes. HAProxy est un proxy inversé qui se positionne devant les deux serveurs Web et achemine les requêtes vers eux.

Au fur et à mesure, vous en saurez plus sur les paramètres de configuration en lisant la documentation officielle. Voyons quelques directives importantes pour chaque section.

Global

En haut de votre fichier de configuration HAProxy se trouve la section global, identifiée par le mot global sur sa propre ligne. Les paramètres se trouvant sous global définissent les réglages de sécurité et de performances à l’échelle du processus qui affectent HAProxy à bas niveau.

Prenons l’exemple suivant:

Voyons comment chacun de ces paramètres fonctionne.

maxconn

Le paramètre maxconn limite le nombre maximum de connexions acceptées par HAProxy. Son objectif est de protéger votre répartiteur de charge contre le manque de mémoire. À vous de déterminer la meilleure valeur pour votre environnement selon le guide de dimensionnement pour les besoins en mémoire.

LE SAVIEZ-VOUS ? En plus de celle consommée par le traitement des connexions, de la mémoire supplémentaire est utilisée par les tables de persistance, les fichiers map et les fichiers ACL.

log

Le paramètre log garantit que les avertissements émis au démarrage et les problèmes lors de l’exécution sont consignés dans Syslog. Il enregistre également les requêtes au fur et à mesure qu’elles arrivent. Vous pouvez cibler le socket UNIX habituel où Syslog ou journald écoutent, /dev/log, ou spécifier un serveur rsyslog distant pour conserver les données de journal en externe de votre serveur de répartition de charge. Définissez une fonction Syslog, local0, une fonction classée pour une utilisation personnalisée. Notez que pour lire les journaux, il faudrait configurer l’un des démons syslog, ou journald, pour les écrire dans un fichier.

user / group

Les lignes user et group indiquent à HAProxy qu’il faut supprimer les privilèges après l’initialisation. Linux nécessite que les processus soient root pour écouter sur les ports inférieurs à 1024. De façon générale, faites de sorte que vos clés privées TLS ne soient lisibles que par root. Sans un utilisateur et un groupe pour continuer le processus, HAProxy conservera les privilèges root, ce qui est une mauvaise pratique. Sachez que HAProxy lui-même ne crée pas l’utilisateur et le groupe et vous devez donc les créer au préalable.

stats socket

La ligne stats socket active l’API Runtime utilisée pour désactiver dynamiquement les serveurs et les vérifications d’état, modifier les poids de répartition de charge des serveurs et exploiter d’autres leviers utiles. Pour en savoir plus, lisez notre article de blog Configuration dynamique avec l’API HAProxy Runtime.

nbproc / nbthread

Les paramètres nbproc et nbthread spécifient le nombre de processus et de threads, respectivement, que HAProxy doit initier au démarrage pour augmenter l’efficacité de votre répartiteur de charge. Cependant, chaque processus créé par nbproc a ses propres statistiques, tables de persistance, bilans de vitalité, etc. Les threads créés avec nbthread, par contre, partagent ces éléments. C’est possible d’utiliser l’un ou l’autre ou les deux paramètres. HAProxy peut fonctionner avec un seul processus et un seul thread, sauf si vous effectuez de nombreuses terminaisons TLS ; dans ce cas, profitez de l’utilisation de plusieurs cœurs de processeur. Lisez notre article de blog Read our blog post Multithreading dans HAProxy pour en savoir plus.

LE SAVIEZ-VOUS ? Lors de la définition de l’un de ces paramètres, vous devriez également définir cpu-map pour que les processus soient épinglés à un noyau spécifique pour des performances maximales.

ssl-default-bind-ciphers

Le paramètre ssl-default-bind-ciphers énumère les chiffrements SSL et TLS que chaque directive bind utilisera par défaut. Vous pouvez le remplacer par un paramètre plus spécifique en ajoutant le paramètre ciphers de la directive bind. Il prend une liste de suites de cipher par ordre de préférence. HAProxy sélectionne le premier listé que le client prend également en charge, sauf si l’option prefer-client-ciphers est activée. Essayez le test du serveur SSL Qualys pour voir la puissance de vos chiffrements et les navigateurs que vous pouvez prendre en charge.

ssl-default-bind-options

Le paramètre ssl-default-bind-options configure les options SSL / TLS telles que ssl-min-ver pour ne plus prendre en charge des protocoles plus anciens. Par exemple, vous pouvez accepter uniquement les connexions qui utilisent une version TLS de 1.2 ou plus récente.

Defaults

Au fur et à mesure que votre configuration évolue, l’utilisation d’une section defaults (valeurs par défaut) réduit la duplication. Ses paramètres s’appliquent à toutes les sections frontend et backend qui viennent par la suite. Vous pouvez toujours remplacer ces paramètres dans les sections spécifiques.

Vous n’êtes pas limité à une seule section defaults. Les sections defaults qui suivent remplacent celles qui les précèdent et réinitialisent toutes les options à leurs valeurs par défaut.

Ainsi, vous pouvez configurer une section defaults qui contient tous vos paramètres TCP, puis placer vos sections frontend et backend uniquement TCP après elle. Ensuite, placez tous vos paramètres HTTP dans une autre section defaults et suivez-la avec vos sections frontend et backend HTTP.

Prenons cet exemple:

Discutons de la signification de chacun de ces paramètres.

timeout connect / timeout client / timeout server

Le paramètre timeout connect configure le temps que HAProxy doit attendre qu’une connexion TCP à un serveur principal soit établie. Le suffixe «s» désigne les secondes. Sans suffixe, le temps est supposé être en millisecondes. Le paramètre timeout client mesure l’inactivité pendant les périodes où le client devrait parler, ou envoyer des segments TCP. Le paramètre timeout server mesure l’inactivité lorsque le serveur backend devrait répondre. Lorsqu’un délai est passé, la connexion est fermée. Le fait d’avoir des délais d’expiration raisonnables réduit le risque que des processus arrêtés bloquent les connexions qui pourraient être ré-utilisées par ailleurs.

Lorsque HAProxy est en mode TCP (défini avec mode tcp), le timeout server doit être le même que le timeout client. En effet, HAProxy ne peut pas savoir si c’est le serveur ou le client qui parle ; et comme les deux s’appliquent tout le temps, des valeurs différentes pourraient prêter à confusion.

log global

Le paramètre log global indique à chaque frontend qui suit d’utiliser le paramètre log défini dans la section global. Cela n’est pas nécessaire pour la journalisation, car vous pouvez ajouter de nouvelles lignes log ici ou dans chaque frontend. Cependant c’est courant dans des cas où un seul serveur syslog est utilisé.

mode

Le paramètre mode définit si HAProxy doit fonctionner comme un simple proxy TCP ou s’il doit inspecter les messages HTTP de niveau supérieur du trafic d’entrée. L’alternative du mode http est le mode tcp, qui est plus rapide, mais moins conscient. Si la plupart de vos sections frontend et backend utilisent le même mode, il serait logique de le spécifier dans la section defaults pour éviter les répétitions.

maxconn

Le paramètre maxconn limite le nombre de connexions acceptées par chaque frontend qui est défini à 2000 par défaut. Pour autoriser plus de connexions, vous augmentez le nombre jusqu’à votre maxconn global. D’un autre côté, vous pourrez utiliser un nombre qui donne à chaque frontend une part équitable des connexions globales.

option httplog

Le paramètre option httplog, ou plus rarement option tcplog, indique à HAProxy d’utiliser un format de journal plus détaillé lors de l’envoi de messages à Syslog. Vous utiliserez plutôt option httplog que option tcplog dans votre section defaults, de sorte que lorsque HAProxy rencontre un frontend qui utilise le mode tcp, il émet un avertissement et le rétrograde à option tcplog dans tous les cas.

Si aucun n’est spécifié, HAProxy utilise le format de journal de connexion, qui contient très peu de détails autres que les adresses IP et les ports du client et du backend. Une autre option consiste à définir un format de journal personnalisé avec le log-format, auquel cas option httplog et option tcplog ne sont pas nécessaires.

Frontend

Lorsque vous placez HAProxy en tant que proxy inverse devant vos serveurs backend, une section frontend définit les adresses IP et les ports auxquels les clients peuvent se connecter. Vous pouvez ajouter autant de sections frontend que nécessaire pour exposer divers sites Web à Internet. Chaque mot-clé frontend est suivi d’un libellé, tel que www.mysite.com, pour le différencier des autres.

Prenons cet exemple :

Voyons ce que signifient ces lignes.

bind

Le paramètre bind affecte un listener à une adresse IP et port donnés. L’IP peut être omis pour se lier à toutes les adresses IP du serveur. Un port peut être un port unique, une plage ou une liste délimitée par des virgules. Vous utiliserez souvent les arguments ssl et crt pour demander à HAProxy de gérer les terminaisons SSL / TLS plutôt que de le faire faire par vos serveurs Web.

LE SAVIEZ-VOUS ? Si vous avez activé HAProxy pour utiliser plusieurs processus via nbproc, vous pouvez indiquer à chaque directive de bind quel processus utiliser avec le paramètre process. Par exemple, la définition process 1 lierait le listener au premier processus.

http-request redirect

Le paramètre http-request redirect redirect répond au client qu’il doit essayer une autre URL. Dans notre exemple, les clients qui demandent votre site Web via HTTP non chiffré sont redirigés vers la version HTTPS du site.

use_backend

Le paramètre use_backend choisit un pool de serveurs backend pour répondre aux requêtes d’entrée si une condition donnée est vraie. Il est suivi d’une instruction ACL, telle que if path_beg/ api /, qui permet à HAProxy de sélectionner un backend spécifique en fonction de certains critères, comme par exemple vérifier si le chemin commence par / api /. Pour en savoir plus sur les ACL, lisez notre article de blog Introduction aux ACL HAProxy. Ces lignes ne sont pas obligatoires et de nombreuses sections frontend ne disposent qu’une ligne default_backend sans aucune règle de sélection particulière.

default_backend

Le paramètre default_backend se trouve dans presque tous les paramètres frontend et indique le nom d’un backend auquel envoyer le trafic à moins qu’une règle use_backend ne l’envoie pas ailleurs auparavant. Si une requête n’est pas acheminée par une directive use_backend ou default_backend, HAProxy renverra une erreur 503 Service indisponible.

Backend

Une section backend désigne un groupe de serveurs pour l’équilibrage de charge et affectés pour gérer les requêtes. Vous pouvez ajouter un libellé de votre choix à chaque backend, tel que web_servers. C’est généralement assez simple et vous n’aurez pas besoin de nombreux paramètres.

Prenons cet exemple :

Examinons quelques paramètres que vous trouverez dans une section backend.

Le paramètre balance contrôle la manière dont HAProxy sélectionne un serveur pour répondre à la requête si aucune méthode de persistance ne remplace cette sélection. Une méthode de persistance peut demander à HAProxy de toujours envoyer un client particulier vers le même serveur en fonction d’un cookie. Les valeurs d’équilibrage de charge courantes incluent roundrobin, qui choisit simplement un serveur en suivant une liste de haut en bas en boucle, et leastconn, où HAProxy sélectionne le serveur avec le moins de sessions actives .

cookie

Le paramètre cookie déclenche la persistance basée sur les cookies. Il demande à HAProxy d’envoyer un cookie nommé SERVERUSED au client et de l’associer avec le nom du serveur qui a donné la réponse initiale. Cela amène le client à continuer à échanger avec ce même serveur pendant la durée de sa session. Notez que le nom du serveur est défini avec un argument cookie sur la ligne server.

option httpchk

Le paramètre option httpchk entraîne des vérifications de l’état de santé de la couche 7 (HTTP) au lieu de la couche 4 (TCP) sur vos serveurs backend. Les serveurs qui ne répondent à ces vérifications pas ne reçoivent plus de requêtes. Alors que les vérifications TCP sont considérées comme réussies si elles sont en mesure d’établir une connexion à l’IP et au port du serveur backend, les vérifications d’intégrité HTTP s’attendent à recevoir une réponse HTTP réussie. Des vérifications intelligentes sont essentielles pour supprimer les serveurs qui ne répondent pas, même s’il ne s’agit qu’une mauvaise réponse HTTP telle que 500 Server Error.

Par défaut, une vérification de l’état HTTP envoie une requête vers le chemin root, /, à l’aide du verbe OPTIONS. Cependant, vous pouvez personnaliser ce processus en utilisant les arguments spécifiés ici. HAProxy traitera toute vérification ayant un code de réponse 2xx ou 3xx comme étant réussie, mais vous pouvez également la personnaliser en utilisant la ligne http-check. L’option httpchk n’est pas limitée aux backends qui utilisent le mode http; par conséquent, les serveurs qui communiquent via HTTP peuvent être vérifiés quel que soit le mode proxy.

default-server

Le paramètre default-server configure les valeurs par défaut pour toutes les lignes server qui le suivent, telles que l’activation des vérifications de l’état, la définition du nombre maximal de connexions, etc. Vous pouvez également spécifier ces arguments sur chaque server.

server

Le paramètre server est au cœur du backend. Son premier argument est un nom, suivi de l’adresse IP et du port du serveur backend. Vous pouvez spécifier un nom de domaine au lieu d’une adresse IP. Dans ce cas, il sera résolu au démarrage ou, si vous ajoutez un argument resolvers, il sera mis à jour pendant l’exécution. Si l’entrée DNS contient un enregistrement SRV, le port et le poids seront également renseignés à partir de celui-ci. Si le port n’est pas spécifié, HAProxy utilisera le même port que celui sur lequel le client s’est connecté, ce qui est utile pour les ports utilisés de manière aléatoire, comme pour le FTP en mode actif.

Bien que nous ayons ajouté l ‘option httpchk pour configurer la vérification de l’état de nos serveurs basée sur HTTP, chaque serveur doit accepter les vérifications de l’état en ajoutant un argument check. Cela peut être défini sur la ligne server ou, comme nous l’avons fait dans cet exemple, sur la ligne default-server.

Chaque ligne server doit avoir un paramètre maxconn qui limite le nombre maximum de requêtes simultanées que le serveur pourra recevoir. Même si ce n’est qu’une supposition, le fait de définir une valeur ici vous permet d’éviter de saturer vos serveurs de requêtes et vous donne une base de référence que vous pourrez ajuster par la suite. Dans cet exemple, nous avons défini le paramètre maxconn sur la ligne default-server.

LE SAVIEZ-VOUS ? Nous avons introduit un nouveau paramètre « server-template » qui peut être utilisé pour créer des serveurs en place reservée pour qu’un outil de découverte de services puisse ensuite compléter avec les bonnes adresses et ports . Lisez à ce sujet dans notre article de blog Nouveautés de HAProxy 1.8

.

Qu’en est-il du listen?

Comme vous l’avez vu, les sections frontend et backend reçoivent le trafic et l’envoient à un pool de serveurs. Vous pouvez également utiliser les sections listen pour faire la même chose. Elles combinent essentiellement les fonctionnalités des sections frontend et backend en une seule. Vous pouvez opter pour la lisibilité obtenue avec plusieurs sections distinctes frontend et backend, en particulier lorsque vous utilisez le mode HTTP avec ses nombreuses options, ou bien vous pouvez choisir une configuration plus concise avec l’approche de la section listen. Dans les deux cas, vous avez toute la puissance d’HAProxy à portée de main!

Voici un exemple simple de listen utilisé pour diffuser la page de statistiques HAProxy:

Conclusion

Nous vous avons présenté les sections les plus importantes du fichier de configuration HAProxy: global, defaults, frontend et backend. Cela vous mènera assez loin. Une fois que vous êtes à l’aise avec la mise en œuvre des bases, essayez de configurer la résolution DNS avec une section resolvers ou bien de configurer des notifications par e-mail avec une section mailers. Essayez également de configurer deux instances de HAProxy et découvrir comment une section peers les maintient synchronisées.

Cet article vous a été utile? Qu’aimeriez-vous savoir d’autre? Laissez-nous un commentaire ici ou suivez-nous sur Twitter. Voulez-vous découvrir d’autres fonctionnalités avancées dans HAProxy Enterprise? Inscrivez-vous pour un essai gratuit ou contactez-nous pour en savoir plus.

SHARE THIS ARTICLE