La dernière fois, nous avons parlé des capacités de NSX Edge en termes de routage statique et dynamique, et aujourd'hui nous traiterons de l'équilibreur de charge.
Avant de commencer la mise en place, je voudrais vous rappeler brièvement les principaux types d'équilibrage.
Теория
Toutes les solutions d'équilibrage de charge utile actuelles sont le plus souvent divisées en deux catégories : l'équilibrage aux quatrième (transport) et septième (application) niveaux du modèle. . Le modèle OSI n’est pas le meilleur point de référence pour décrire les méthodes d’équilibrage. Par exemple, si un équilibreur L4 prend également en charge la terminaison TLS, devient-il alors un équilibreur L7 ? Mais c’est comme ça.
- Equilibreur L4 le plus souvent, il s'agit d'un proxy intermédiaire entre le client et un ensemble de backends disponibles, qui met fin aux connexions TCP (c'est-à-dire répond indépendamment à SYN), sélectionne un backend et initie une nouvelle session TCP dans sa direction, en envoyant indépendamment SYN. Ce type est l'un des principaux, d'autres options sont possibles.
- Equilibreur L7 distribue le trafic sur les backends disponibles « plus sophistiqués » que l’équilibreur L4. Il peut décider quel backend choisir en fonction, par exemple, du contenu du message HTTP (URL, cookie, etc.).
Quel que soit le type, l'équilibreur peut prendre en charge les fonctions suivantes :
- La découverte de services est le processus de détermination de l'ensemble des backends disponibles (Static, DNS, Consul, Etcd, etc.).
- Vérification de la fonctionnalité des backends détectés (« ping » actif du backend à l'aide d'une requête HTTP, détection passive de problèmes dans les connexions TCP, présence de plusieurs codes HTTP 503 dans les réponses, etc.).
- L'équilibrage lui-même (round robin, sélection aléatoire, hachage IP source, URI).
- Terminaison TLS et vérification du certificat.
- Options liées à la sécurité (authentification, prévention des attaques DoS, limitation de vitesse) et bien plus encore.
NSX Edge offre la prise en charge de deux modes de déploiement d'équilibreur de charge :
Mode proxy ou monobras. Dans ce mode, NSX Edge utilise son adresse IP comme adresse source lors de l'envoi d'une requête à l'un des backends. Ainsi, l'équilibreur remplit simultanément les fonctions de NAT source et de destination. Le backend voit tout le trafic envoyé par l’équilibreur et y répond directement. Dans un tel schéma, l'équilibreur doit se trouver dans le même segment de réseau que les serveurs internes.
Voici comment ça se passe:
1. L'utilisateur envoie une demande à l'adresse VIP (adresse de l'équilibreur) configurée sur Edge.
2. Edge sélectionne l'un des backends et effectue le NAT de destination, en remplaçant l'adresse VIP par l'adresse du backend sélectionné.
3. Edge effectue le NAT source, en remplaçant l'adresse de l'utilisateur qui a envoyé la demande par la sienne.
4. Le package est envoyé au backend sélectionné.
5. Le backend ne répond pas directement à l'utilisateur, mais au Edge, puisque l'adresse d'origine de l'utilisateur a été remplacée par l'adresse de l'équilibreur.
6. Edge transmet la réponse du serveur à l'utilisateur.
Le schéma est ci-dessous.
Mode transparent ou en ligne. Dans ce scénario, l'équilibreur dispose d'interfaces sur les réseaux internes et externes. Dans le même temps, il n'y a pas d'accès direct au réseau interne depuis le réseau externe. L'équilibreur de charge intégré agit comme une passerelle NAT pour les machines virtuelles sur le réseau interne.
Le mécanisme est le suivant :
1. L'utilisateur envoie une demande à l'adresse VIP (adresse de l'équilibreur) configurée sur Edge.
2. Edge sélectionne l'un des backends et effectue le NAT de destination, en remplaçant l'adresse VIP par l'adresse du backend sélectionné.
3. Le package est envoyé au backend sélectionné.
4. Le backend reçoit une requête avec l'adresse d'origine de l'utilisateur (le NAT source n'a pas été effectué) et y répond directement.
5. Le trafic est à nouveau accepté par l'équilibreur de charge, car dans un schéma en ligne, il agit généralement comme passerelle par défaut pour la batterie de serveurs.
6. Edge effectue un NAT source pour envoyer du trafic à l'utilisateur, en utilisant son VIP comme adresse IP source.
Le schéma est ci-dessous.
Pratique
Mon banc de test dispose de 3 serveurs exécutant Apache, configurés pour fonctionner via HTTPS. Edge effectuera un équilibrage circulaire des requêtes HTTPS, en transmettant chaque nouvelle requête à un nouveau serveur.
Commençons
Générer un certificat SSL qui sera utilisé par NSX Edge
Vous pouvez importer un certificat CA valide ou en utiliser un auto-signé. Pour ce test, j'utiliserai l'auto-signé.
- Dans l'interface de vCloud Director, accédez aux paramètres des services Edge.
- Accédez à l'onglet Certificats. Dans la liste des actions, sélectionnez l'ajout d'une nouvelle CSR.
- Remplissez les champs obligatoires et cliquez sur Conserver.
- Sélectionnez le CSR nouvellement créé et sélectionnez l'option CSR d'auto-signature.
- Sélectionnez la période de validité du certificat et cliquez sur Conserver
- Le certificat auto-signé apparaît dans la liste des certificats disponibles.
Configuration du profil d'application
Les profils d'application vous offrent un contrôle plus complet sur le trafic réseau et rendent sa gestion simple et efficace. Ils peuvent être utilisés pour définir le comportement de types de trafic spécifiques.
- Accédez à l’onglet Load Balancer et activez l’équilibreur. L'option Accélération activée ici permet à l'équilibreur d'utiliser un équilibrage L4 plus rapide au lieu de L7.
- Accédez à l’onglet Profil d’application pour définir le profil d’application. Cliquez sur +.
- Définissez le nom du profil et sélectionnez le type de trafic pour lequel le profil sera appliqué. Laissez-moi vous expliquer quelques paramètres.
Persistence – stocke et suit les données de session, par exemple : quel serveur spécifique du pool répond à la demande de l'utilisateur. Cela garantit que les demandes des utilisateurs sont acheminées vers le même membre du pool pendant toute la durée de vie de la session ou des sessions suivantes.
Activer le relais SSL – Lorsque cette option est sélectionnée, NSX Edge arrête de mettre fin à SSL. Au lieu de cela, la résiliation s'effectue directement sur les serveurs en cours d'équilibrage.
Insérer l'en-tête HTTP X-Forwarded-For – vous permet de déterminer l'adresse IP source du client se connectant au serveur Web via l'équilibreur de charge.
Activer SSL côté pool – permet de préciser que le pool sélectionné est constitué de serveurs HTTPS.
- Étant donné que je vais équilibrer le trafic HTTPS, je dois activer Pool Side SSL et sélectionner le certificat généré précédemment dans l'onglet Certificats de serveur virtuel -> Certificat de service.
- De même pour les certificats de pool -> Certificat de service.
Nous créons un pool de serveurs dont le trafic sera équilibré. Pools
- Accédez à l'onglet Pools. Cliquez sur +.
- Nous définissons le nom du pool, sélectionnons l'algorithme (j'utiliserai le round robin) et le type de surveillance pour le backend du contrôle de santé. L'option Transparent indique si les IP sources initiales des clients sont visibles pour les serveurs internes.
- Si l'option est désactivée, le trafic des serveurs internes provient de l'IP source de l'équilibreur.
- Si l'option est activée, les serveurs internes voient l'adresse IP source des clients. Dans cette configuration, NSX Edge doit agir comme passerelle par défaut pour garantir que les paquets renvoyés transitent par NSX Edge.
NSX prend en charge les algorithmes d'équilibrage suivants :
- IP_HASH – sélection du serveur basée sur les résultats d’une fonction de hachage pour l’IP source et destination de chaque paquet.
- LEASTCONN – équilibrage des connexions entrantes, en fonction du nombre déjà disponible sur un serveur particulier. Les nouvelles connexions seront dirigées vers le serveur avec le moins de connexions.
- ROUND_ROBIN – les nouvelles connexions sont envoyées tour à tour à chaque serveur, en fonction du poids qui lui est attribué.
- URI – la partie gauche de l’URI (avant le point d’interrogation) est hachée et divisée par le poids total des serveurs du pool. Le résultat indique quel serveur reçoit la requête, garantissant que la requête est toujours acheminée vers le même serveur, tant que tous les serveurs restent disponibles.
- EN-TÊTE HTTP – un équilibrage basé sur un en-tête HTTP spécifique, qui peut être spécifié en paramètre. Si l'en-tête est manquant ou n'a aucune valeur, l'algorithme ROUND_ROBIN est appliqué.
- URL – Chaque requête HTTP GET recherche le paramètre URL spécifié en argument. Si le paramètre est suivi d'un signe égal et d'une valeur, alors la valeur est hachée et divisée par le poids total des serveurs en cours d'exécution. Le résultat indique quel serveur reçoit la requête. Ce processus est utilisé pour garder une trace des ID utilisateur dans les requêtes et garantir que le même ID utilisateur est toujours envoyé au même serveur, tant que tous les serveurs restent disponibles.
- Dans le bloc Membres, cliquez sur + pour ajouter des serveurs au pool.
Ici, vous devez préciser :- nom du serveur;
- Adresse IP du serveur;
- le port sur lequel le serveur recevra le trafic ;
- port pour le contrôle de santé (Surveiller le contrôle de santé) ;
- poids – en utilisant ce paramètre, vous pouvez ajuster la quantité proportionnelle de trafic reçu pour un membre spécifique du pool ;
- Max Connections – nombre maximum de connexions au serveur ;
- Nombre minimum de connexions – nombre minimum de connexions que le serveur doit traiter avant que le trafic ne soit transmis au membre suivant du pool.
Voilà à quoi ressemble le pool final de trois serveurs.
Ajout d'un serveur virtuel
- Accédez à l'onglet Serveurs virtuels. Cliquez sur +.
- Nous activons le serveur virtuel en utilisant Enable Virtual Server.
Nous lui donnons un nom, sélectionnons le profil d'application, le pool précédemment créé et indiquons l'adresse IP à laquelle le serveur virtuel recevra les requêtes de l'extérieur. Nous précisons le protocole HTTPS et le port 443.
Paramètres facultatifs ici :
Limite de connexion – le nombre maximum de connexions simultanées que le serveur virtuel peut traiter ;
Limite de débit de connexion (CPS) – le nombre maximum de nouvelles requêtes entrantes par seconde.
Ceci termine la configuration de l'équilibreur, vous pouvez vérifier sa fonctionnalité. Les serveurs ont une configuration simple qui permet de comprendre quel serveur du pool a traité la requête. Lors de la configuration, nous avons choisi l'algorithme d'équilibrage Round Robin et le paramètre Weight pour chaque serveur est égal à un, de sorte que chaque requête suivante sera traitée par le serveur suivant du pool.
Nous entrons l'adresse externe de l'équilibreur dans le navigateur et voyons :
Après avoir rafraîchi la page, la requête sera traitée par le serveur suivant :
Et encore - pour vérifier le troisième serveur du pool :
Lors de la vérification, vous pouvez voir que le certificat qu'Edge nous envoie est le même que celui que nous avons généré au tout début.
Vérification de l'état de l'équilibreur à partir de la console de la passerelle Edge. Pour ce faire, entrez afficher le pool d'équilibrage de charge du service.
Configuration de Service Monitor pour vérifier l'état des serveurs dans le pool
En utilisant Service Monitor, nous pouvons surveiller l'état des serveurs dans le pool backend. Si la réponse à une requête n'est pas celle attendue, le serveur peut être retiré du pool afin qu'il ne reçoive aucune nouvelle requête.
Par défaut, trois méthodes de vérification sont configurées :
- Moniteur TCP,
- Moniteur HTTP,
- Moniteur HTTPS.
Créons-en un nouveau.
- Accédez à l'onglet Surveillance des services, cliquez sur +.
- Choisir:
- nom de la nouvelle méthode ;
- l'intervalle auquel les demandes seront envoyées,
- délai d'attente en attente d'une réponse,
- type de surveillance – requête HTTPS utilisant la méthode GET, code d'état attendu – 200 (OK) et URL de requête.
- Ceci termine la configuration du nouveau Service Monitor ; nous pouvons désormais l’utiliser lors de la création d’un pool.
Configuration des règles d'application
Les règles d'application sont un moyen de manipuler le trafic en fonction de certains déclencheurs. Avec cet outil, nous pouvons créer des règles avancées d'équilibrage de charge qui peuvent ne pas être possibles via les profils d'application ou d'autres services disponibles sur Edge Gateway.
- Pour créer une règle, rendez-vous dans l'onglet Règles d'application de l'équilibreur.
- Sélectionnez un nom, un script qui utilisera la règle, puis cliquez sur Conserver.
- Une fois la règle créée, nous devons modifier le serveur virtuel déjà configuré.
- Dans l'onglet Avancé, ajoutez la règle que nous avons créée.
Dans l'exemple ci-dessus, nous avons activé la prise en charge de tlsv1.
Quelques autres exemples :
Redirigez le trafic vers un autre pool.
Avec ce script, nous pouvons rediriger le trafic vers un autre pool d'équilibrage si le pool principal est en panne. Pour que la règle fonctionne, plusieurs pools doivent être configurés sur l'équilibreur et tous les membres du pool principal doivent être à l'état inactif. Vous devez spécifier le nom du pool, pas son ID.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Redirigez le trafic vers une ressource externe.
Ici, nous redirigeons le trafic vers le site Web externe si tous les membres du pool principal sont en panne.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Encore plus d'exemples .
C'est tout pour moi à propos de l'équilibreur. Si vous avez des questions, posez-les, je suis prêt à y répondre.
Source: habr.com