Aperçu
nftlb peuplements pour équilibreur de charge nftables, le pare-feu Linux de nouvelle génération qui remplacera iptables est conçu pour se comporter comme un équilibreur de charge complet et un distributeur de trafic.
nftlb est un gestionnaire de règles nftables pour créer des services virtuels pour l'équilibrage de charge au niveau des couches 2, 3 et 4, en minimisant le nombre de règles et en utilisant des structures pour faire correspondre efficacement les paquets. Il est également fourni avec un service d'API JSON simple pour avoir la flexibilité d'interagir avec nftlb par programmation et de répondre à l'automatisation. Vous pouvez donc utiliser votre vérificateur de santé préféré pour être intégré très facilement à nftlb.
La philosophie de nftlb est de maintenir le chemin de données dans le noyau, afin d'obtenir le plus de performances possible, mais le plan de contrôle et de santé vérifient l'espace utilisateur pour avoir la possibilité de changer facilement le comportement, mais également d'être compatible avec le reste de la pile Linux .
Chez Zevenet, nous utilisons iptables et l'infrastructure netfilter depuis des années pour créer un équilibreur de charge complet, nous connaissons donc très bien les limites d'une telle approche avec laquelle nous économisons nftlb.
Pourquoi nftlb est-il nécessaire?
Le noyau Linux compte déjà un équilibreur de charge interne appelé IPVS, ou également appelé LVS (serveur virtuel Linux), un logiciel complet et très stable utilisé depuis des années. Mais un tel équilibreur de charge a certaines limites: le côté noyau est utilisé pour les tâches devant être exécutées par l’espace utilisateur, pour certaines fonctionnalités, il duplique l’infrastructure fournie par netfilter, et il repose sur iptables et d’autres logiciels, le cas échéant. plus complexe (type proxy transparent, multiport ou multiprotocole). Il fournit les topologies SNAT et DSR, mais pas DNAT.
Avec l’approche iptables, les principales limitations sont le nombre de règles à créer par le service virtuel et le nombre d’arrière-plans (minimum de ~ règles 2 par unité d’arrière avec plusieurs correspondances incluses), ainsi qu’une complexité linéaire croissante en fonction du nombre d’arrière-plans ajoutés. . Le traitement séquentiel des règles ralentit également les performances si trop de règles sont incluses, ce qui est encore pire en raison du problème de verrouillage classique d'iptables. Afin de fournir l'équilibrage de charge IPv6, il présente l'inconvénient d'utiliser une commande différente, ip6tables. De plus, cette approche est capable de fournir un équilibrage de charge DNAT (NAT de destination pour la transparence) et SNAT (NAT de source) mais ne peut pas fonctionner dans les topologies DSR (Direct Server Return).
Avec nftlb sur la base nftables nous sauvons tous ces problèmes:
Il peut construire toutes ces topologies et changer très facilement.
Il peut gérer nativement multiport et multiprotocole.
Il peut gérer le trafic IPv4 et IPv6 de manière transparente.
Il n'utilise qu'une seule interface pour fournir toutes les fonctionnalités requises pour l'équilibrage de charge.
nftables fournit un langage plus expressif afin que nous puissions utiliser les règles 2 pour créer un équilibreur de charge complet avec une complexité constante!
Les correspondances sont indexées par service virtuel, nous n'avons donc pas besoin de les traiter toutes de manière séquentielle.
Il est fourni par le sous-système RCU, il n’ya donc pas de problème de verrouillage lors de la mise à jour des règles.
Le chemin de données reste dans l’espace noyau mais offre la flexibilité de l’espace utilisateur pour le plan de contrôle.
Il a été prouvé que il peut exécuter 10x plus rapidement que LVS.
caractéristiques nftlb
À l’heure actuelle, nftlb fournit les fonctionnalités suivantes:
Topologies prises en charge: NAT de destination, NAT source, retour direct du serveur et DNAT sans état. Cela permet d'utiliser l'équilibreur de charge dans des architectures de réseau à une ou à deux armes.
Prise en charge des familles IPv4 et IPv6.
Equilibreur de charge multicouche: DSR dans la couche 2, équilibrage de la charge basé sur IP avec protocole indépendant pour la couche 3 et prise en charge de l'équilibrage de la charge des protocoles UDP, TCP et SCTP sur la couche 4.
Prise en charge multiport pour les plages et les listes de ports.
Prise en charge de plusieurs services virtuels (ou batteries).
Planificateurs disponibles: poids, cycle alternatif, hachage configurable (par IP, port, MAC ou combinaison des deux) et hachage symétrique.
Prise en charge de la persistance configurable ou de l’affinité client-backend avec un délai d’attente (par adresse IP, port, MAC ou une combinaison des deux).
Prise en charge des politiques de sécurité par service: listes blanches et noires (depuis l'entrée), filtre de files d'attente fictives, filtrage des trames TCP fictives, nombre maximal de connexions établies, limite TCP RST par seconde, limite de nouvelles connexions par seconde et plus.
Support prioritaire par backend.
Gestion en direct des services virtuels et des backends par programmation via une API JSON.
Authentification du service Web avec une clé de sécurité.
Banc d'essai automatisé inclus.
Dépôt git officiel: https://github.com/zevenet/nftlb
Changelog: https://www.zevenet.com/knowledge-base/nftlb/nftlb-changelog/