Sortie de l'équilibreur de charge HTTP/TCP HAProxy 2.0

Publié lancement du répartiteur de charge avec le proxy des requêtes via TCP sur IPv4 et IPv6 ou sans proxy des connexions (pour l'envoi de requêtes de heartbeat de vérification confirmant le fonctionnement normal)., permettant de répartir le trafic HTTP et les requêtes TCP arbitraires entre un groupe de serveurs, en tenant compte de nombreux facteurs (par exemple, vérifie la disponibilité des serveurs, évalue le niveau de charge, dispose de moyens de lutte contre les attaques DDoS) et effectue un filtrage initial des données (comme la possibilité d'analyser les en-têtes HTTP, de filtrer la transmission de paramètres de requête incorrects, de bloquer l'injection SQL et les XSS, et de connecter des agents de traitement de contenu). HAProxy peut également s'appliquer pour coordonner l'interaction des composants dans les systèmes basés sur l'architecture des microservices. Le code du projet est écrit en langage C et est fourni sous licence GPLv2. Le projet est utilisé sur de nombreux grands sites, y compris Airbnb, Alibaba, GitHub, Imgur, Instagram, Reddit, StackOverflow, Tumblr, Twitter et Vimeo.

Fonctionnalités clés de la version :

• Nouveau API Data Plan, permettant de gérer dynamiquement les paramètres de HAProxy via REST Web API. Il est notamment possible d'ajouter et de supprimer dynamiquement des backends et des serveurs, de créer des ACL, de modifier le routage des requêtes, de changer les liaisons des gestionnaires aux IP ;
• Ajout de la directive nbthread, permettant de configurer le nombre de threads utilisés par HAProxy pour optimiser le fonctionnement sur les processeurs multicœurs. Par défaut, le nombre de threads de travail est choisi en fonction des cœurs de CPU disponibles dans l'environnement actuel, tandis que dans les environnements cloud, un seul thread est par défaut configuré. Pour définir des limites strictes, des options de compilation MAX_THREADS et MAX_PROCS ont été ajoutées, limitant le plafond sur le nombre de threads et de processus ;
• Simplification de l'utilisation de la directive bind pour lier les gestionnaires aux adresses réseau. Lors de la configuration, il n'est plus nécessaire de définir les paramètres du processus - par défaut, les connexions seront réparties sur les threads en fonction du nombre de connexions actives.
• Simplification de la configuration des journaux lors du démarrage dans des conteneurs isolés - le journal peut maintenant être dirigé vers stdout et stderr, ainsi que vers tout descripteur de fichier existant (comme «log fd@1 local0»);
• La prise en charge de HTX (Native HTTP Representation) est activée par défaut, permettant d'assurer la répartition de la charge lors de l'utilisation de fonctionnalités avancées telles que HTTP/2 de bout en bout, les tentatives de connexion de niveau 7 et gRPC. HTX ne remplace pas les en-têtes sur place, mais réduit l'opération de modification à la suppression et l'ajout d'un nouvel en-tête à la fin de la liste, ce qui permet de manipuler toutes les variantes avancées du protocole HTTP tout en préservant la sémantique d'origine des en-têtes et en atteignant une performance améliorée lors de la traduction de HTTP/2 vers HTTP/1.1 et vice versa;
• Ajout du support officiel du mode de bout en bout HTTP/2 (traitement de toutes les étapes en HTTP/2, y compris les appels au backend, et pas seulement l'interaction du proxy avec le client);
• Support complet du proxy bidirectionnel pour le protocole gRPC avec la capacité d'analyser des flux gRPC, en extrayant des messages distincts, en reflétant le trafic gRPC dans les logs et en filtrant les messages à l'aide d'un ACL. gRPC permet d'organiser le travail des microservices dans différents langages de programmation, qui interagissent entre eux via une API universelle. Les interactions réseau dans gRPC sont mises en œuvre sur le protocole HTTP/2 et reposent sur l'utilisation des Protocol Buffers pour la sérialisation des données.
• Ajout du soutien pour le mode « Layer 7 Retries », permettant d'envoyer des requêtes HTTP répétées en cas d'échecs logiciels non liés à des problèmes de connexion réseau (par exemple, en l'absence de réponse ou en cas de réponse vide à une requête POST). Pour désactiver ce mode, un flag « disable-l7-retry » a été ajouté à l'option « http-request », et pour un réglage fin, une option « retry-on » est désormais disponible dans les sections defaults, listen et backend. Les critères suivants sont disponibles pour la répétition : all-retryable-errors, none, conn-failure, empty-response, junk-response, response-timeout, 0rtt-rejected, ainsi que la liaison aux codes de statut retournés (404, etc.);
• Mise en œuvre d'un nouveau gestionnaire de processus (Process Manager), permettant de configurer l'appel de fichiers exécutables externes avec des gestionnaires pour HAProxy.
  Par exemple, un tel gestionnaire externe a été mis en œuvre sous la forme de l'API Data Plan (/usr/sbin/dataplaneapi), ainsi que divers moteurs de traitement hors charge;
• Pour .NET Core, Go, Lua et Python, des liaisons ont été ajoutées pour le développement d'extensions SPOE (Stream Processing Offload Engine) et SPOP (Stream Processing Offload Protocol). Auparavant, le développement d'extensions n'était pris en charge qu'en C;
• Un gestionnaire externe spoa-mirror ( /usr/sbin/spoa-mirror ) a été ajouté pour le mirroring des requêtes sur un serveur distinct (par exemple, pour copier une partie du trafic de travail pour tester un environnement expérimental sous une charge réelle);
• Présenté Contrôleur d'Ingress HAProxy pour Kubernetes pour assurer l'intégration avec la plateforme Kubernetes;
• Un support intégré pour l'exportation des statistiques vers un système de surveillance a été ajouté. Prometheus;
• Le protocole Peers Protocol, utilisé pour échanger des informations avec d'autres nœuds HAProxy, a été élargi. Cela inclut le support pour Heartbeat et la transmission de données chiffrées;
• Le paramètre «sample» a été ajouté à la directive «log», permettant de consigner uniquement une partie des requêtes, par exemple 1 sur 10, pour créer un échantillon analytique;
• Un mode de profilage automatique a été ajouté (directive profiling.tasks, qui peut prendre les valeurs auto, on et off). Le profilage automatique s'active si la latence moyenne dépasse 1000 ms. Pour visualiser les données de profilage via l'API Runtime, la commande «show profiling» a été ajoutée ou il est possible de réinitialiser les statistiques dans le journal;
• Un support pour l'accès aux serveurs backend utilisant le protocole SOCKS4 a été ajouté;
• Un support de bout en bout pour le mécanisme d'ouverture rapide des connexions TCP (TFO — TCP Fast Open, RFC 7413) a été ajouté, permettant de réduire le nombre d'étapes de la mise en place d'une connexion en combinant en une seule requête les première et deuxième étapes du classique processus d'établissement de connexion en 3 étapes, et permettant l'envoi de données au début de la mise en place de la connexion;
• Nouvelles actions ajoutées :
  • «http-request replace-uri» pour remplacer les URL en utilisant des expressions régulières;
  • «tcp-request content do-resolve» et «http-request do-resolve» pour résoudre les noms d'hôte;
  • «tcp-request content set-dst» et «tcp-request content set-dst-port» pour substituer l'adresse IP cible et le port.
• Nouveaux modules de conversion ajoutés :
  • aes_gcm_dev pour déchiffrer des flux utilisant les algorithmes AES128-GCM, AES192-GCM et AES256-GCM;
  • protobuf pour extraire les champs des messages Protocol Buffers;
  • ungrpc pour extraire les champs des messages gRPC.

  Source : opennet.ru