Fonctionnalités avancées
3.5.1. Fonctionnalités avancées : Gestion
HAProxy est conçu pour rester extrêmement stable et sécurisé à gérer dans un environnement de production classique. Il est fourni sous forme d’un seul fichier exécutable ne nécessitant aucun processus d’installation. Plusieurs versions peuvent coexister facilement, ce qui permet (et est recommandé) de mettre à jour les instances progressivement, par ordre de priorité, plutôt que de les migrer toutes en même temps. Les fichiers de configuration sont facilement versionnés. La vérification de configuration se fait hors ligne, sans nécessiter de redémarrer un service susceptible de échouer. Pendant la vérification de configuration, un certain nombre d’erreurs avancées peuvent être détectées (par exemple, une règle masquant une autre, ou une persistance qui ne fonctionnera pas), et des avertissements détaillés ainsi que des suggestions de configuration sont proposés pour les corriger. La compatibilité des fichiers de configuration avec les versions antérieures s’étend très loin dans le temps : la version 1.5 supporte encore entièrement les configurations écrites pour les versions 1.1, il y a 13 ans, et la version 1.6 n’a abandonné le support que pour des mots-clés presque inutilisés et obsolètes, pouvant être remplacés autrement. Le mécanisme de mise à jour de la configuration et du logiciel est fluide et non disruptif, car il permet à des processus anciens et nouveaux de coexister sur le système, chacun gérant ses propres connexions. L’état du système, les options de compilation et la compatibilité des bibliothèques sont rapportés au démarrage.
Certaines fonctionnalités avancées permettent à un administrateur d’application d’arrêter un serveur de manière fluide, de détecter lorsqu’il n’y a plus d’activité dessus, puis de le retirer du service, de l’arrêter, de le mettre à jour, et de s’assurer qu’il ne reçoit aucune requête pendant la mise à jour, puis de le tester à nouveau via le chemin normal sans le rendre accessible au public, et tout cela sans modifier HAProxy. Cela garantit que même des opérations de production complexes peuvent être effectuées pendant les heures d’ouverture, avec l’ensemble des ressources techniques disponibles.
Le processus tente de préserver au maximum les ressources, utilise des pools de mémoire pour réduire le temps d’allocation et limiter la fragmentation mémoire, libère les tampons de charge utile dès que leurs contenus ont été envoyés, et prend en charge l’application de limites mémoire strictes, au-delà desquelles les connexions doivent attendre qu’un tampon devienne disponible au lieu d’allouer davantage de mémoire. Ce système permet de garantir l’utilisation mémoire dans certains environnements stricts.
Une interface en ligne de commande (CLI) est disponible sous forme de socket UNIX ou TCP, afin d’effectuer diverses opérations et de récupérer des informations utiles au dépannage. Toutes les actions effectuées sur cette socket ne nécessitent pas de modification de configuration, aussi est-elle principalement utilisée pour des changements temporaires. Grâce à cette interface, il est possible de modifier l’adresse, le poids et l’état d’un serveur, de consulter les statistiques et de réinitialiser les compteurs, de sauvegarder et vider les tables de persistance, éventuellement de manière sélective selon des critères clés, de sauvegarder et interrompre les connexions côté client ou côté serveur, de sauvegarder les erreurs capturées avec une analyse détaillée de la cause exacte et de l’emplacement de l’erreur, de sauvegarder, ajouter ou supprimer des entrées dans les listes ACL et les cartes, de mettre à jour les secrets TLS partagés, d’appliquer des limites de connexion et de débit en temps réel sur des frontaux arbitraires (utile dans les environnements d’hébergement partagé), et de désactiver un frontend spécifique afin de libérer un port d’écoute (utile lorsque les opérations diurnes sont interdites et qu’une correction s’impose tout de même). Il est permis de mettre à jour les certificats et leur configuration en temps réel, ainsi que d’activer et de consulter les traces de chaque étape du traitement du trafic.
Dans les environnements où SNMP est obligatoire, il existe au moins deux agents. L’un est fourni avec les sources HAProxy et repose sur le module Perl Net-SNMP. L’autre accompagne les paquets commerciaux et ne requiert pas Perl. Ils offrent une couverture globalement équivalente.
Il est souvent recommandé d’installer les quatre utilitaires suivants sur la machine où HAProxy est déployé :
socat (afin de se connecter à l’interface CLI, bien que certaines variantes de netcat puissent également le faire dans une certaine mesure) ;
halog depuis la dernière version d’HAProxy : il s’agit d’un outil d’analyse de journaux, qui analyse très rapidement les journaux TCP et HTTP natifs (de 1 à 2 Go par seconde) et extrait des informations et statistiques utiles, telles que le nombre de requêtes par URL, par adresse source, les URLs triées par temps de réponse ou taux d’erreur, les codes de terminaison, etc. Il a été conçu pour être déployé sur les serveurs de production afin d’aider au dépannage des problèmes en temps réel, il doit donc être présent et prêt à être utilisé ;
tcpdump : il est fortement recommandé d’utiliser tcpdump pour capturer les traces réseau nécessaires au dépannage d’un problème apparu dans les journaux. Il arrive un moment où l’analyse effectuée par l’application et celle effectuée par HAProxy divergent, et les traces réseau sont la seule manière de déterminer qui a raison et qui a tort. Il est également fréquent de détecter des bugs dans les piles réseau ou les hyperviseurs grâce à tcpdump.
strace : il est le complément de tcpdump. Il indique ce que HAProxy voit réellement et permet de distinguer les problèmes liés au système d’exploitation de ceux liés à HAProxy. strace est souvent demandé lorsqu’un bug dans HAProxy est suspecté ;
3.5.2. Fonctionnalités avancées : Capacités spécifiques au système
Selon le système d’exploitation sur lequel HAProxy est déployé, certaines fonctionnalités supplémentaires peuvent être disponibles ou nécessaires. Bien qu’il soit pris en charge sur plusieurs plates-formes, HAProxy est principalement développé sous Linux, ce qui explique pourquoi certaines fonctionnalités ne sont disponibles que sur cette plate-forme.
Les fonctionnalités de liaison transparente et de connexion, le support de la liaison des connexions à une interface réseau spécifique, ainsi que la possibilité de lier plusieurs processus au même adresse IP et ports ne sont disponibles que sur les systèmes Linux et BSD, bien que seul Linux effectue une répartition de charge côté noyau des requêtes entrantes entre les processus disponibles.
Sur Linux, plusieurs fonctionnalités et optimisations supplémentaires sont disponibles, notamment le support des espaces de noms réseau (également appelés « conteneurs »), permettant à HAProxy d’agir comme passerelle entre tous les conteneurs, la possibilité de définir la taille maximale de segment (MSS), les marques Netfilter et le champ IP TOS sur la connexion côté client, le support du TCP FastOpen côté écoute, les délais d’expiration utilisateur TCP pour permettre au noyau de tuer rapidement les connexions lorsque le client disparaît avant l’expiration configurée, le découpage TCP pour permettre au noyau de transférer les données entre les deux extrémités d’une connexion, évitant ainsi plusieurs copies en mémoire, la possibilité d’activer l’option bind « defer-accept » afin de ne recevoir une notification d’une connexion entrante qu’une fois que des données sont disponibles dans les tampons du noyau, ainsi que la possibilité d’envoyer la requête avec l’ACK confirmant la connexion (parfois appelé « piggy-back »), activée par l’option « tcp-smart-connect ». Sur Linux, HAProxy prend également grand soin à manipuler les accusés de réception différés TCP afin de réduire au maximum le nombre de paquets sur le réseau.
Certains systèmes disposent d’une horloge peu fiable, qui saute indéfiniment dans le passé et dans le futur. Cela se produisait autrefois sur certains systèmes NUMA où plusieurs processeurs ne voyaient pas exactement la même heure, et cela devient désormais plus fréquent dans les environnements virtualisés, où l’horloge virtuelle n’a aucune relation avec l’horloge réelle, entraînant des sauts temporels importants (des sauts de jusqu’à 30 secondes ont été observés). Cela pose de nombreux problèmes en ce qui concerne l’application des délais d’expiration en général. En raison de cette imperfection de ces systèmes, HAProxy maintient sa propre horloge monotone, basée sur l’horloge système mais où le dérive est mesuré et compensé. Cela garantit que, même avec une horloge système très défaillante, les temporisateurs restent raisonnablement précis et que les délais d’expiration continuent de fonctionner. Notez que ce problème affecte tous les logiciels s’exécutant sur de tels systèmes et n’est pas spécifique à HAProxy. Les effets courants sont des délais d’expiration erronés ou des blocages d’applications. Par conséquent, si ce comportement est détecté sur un système, il doit être corrigé, quelle que soit la protection offerte par HAProxy.
Sous Linux, un nouveau processus de démarrage peut communiquer avec l’ancien afin de réutiliser ses descripteurs de fichiers d’écoute, de sorte que les sockets d’écoute ne soient jamais interrompus pendant le remplacement du processus.
3.5.3. Fonctionnalités avancées : Scripting
HAProxy peut être compilé avec prise en charge du langage embarqué Lua, ce qui ouvre un large éventail de possibilités liées à la manipulation complexe des requêtes ou des réponses, aux décisions de routage, au traitement des statistiques, etc. En utilisant Lua, il est même possible d’établir des connexions parallèles avec d’autres serveurs afin d’échanger des informations. Ainsi, il devient possible (bien que complexe) de développer un système d’authentification, par exemple. Pour en savoir plus sur l’utilisation de Lua, reportez-vous à la documentation disponible dans le fichier “doc/lua-api/index.rst”.
3.5.4. Fonctionnalités avancées : Suivi
À tout moment, un administrateur peut se connecter via l’interface CLI et activer le traçage dans divers sous-systèmes internes. Des niveaux de détail variés sont fournis par défaut, de sorte qu’en pratique, on puisse récupérer entre une ligne par requête et 500 lignes par requête. Des filtres ainsi qu’un mécanisme automatique d’activation/désactivation/pause de la capture sont disponibles, permettant ainsi réellement d’attendre un événement spécifique et de l’observer en détail. Cela est extrêmement pratique pour diagnostiquer des violations de protocole provenant de serveurs ou de clients défaillants, ou des attaques par déni de service.