VMware NSX pour les plus petits. Partie 5. Configuration du répartiteur de charge

Partie un. Introduction
Partie deux. Configuration des règles de Firewall et NAT
Partie trois. Configuration du DHCP
Partie quatre. Configuration du routage

La dernière fois, nous avons discuté des capacités de NSX Edge en matière de routage statique et dynamique, et aujourd'hui nous allons examiner le répartiteur de charge.
Avant de commencer la configuration, je voudrais rappeler brièvement les principaux types de répartition de charge.

Théorie

Les solutions de répartition de charge d'aujourd'hui sont généralement classées en deux catégories : la répartition de charge de niveau quatre (transport) et de niveau sept (application) du modèle OSI. Le modèle OSI n'est pas le meilleur point de référence pour décrire les méthodes de répartition de charge. Par exemple, si un répartiteur de charge L4 prend également en charge la terminaison TLS, devient-il alors un répartiteur de charge L7 ? Mais c'est ainsi.

• Répartiteur de charge L4 représente généralement un proxy intermédiaire entre le client et un ensemble de backends disponibles, qui termine les connexions TCP (c'est-à-dire qui répond à SYN), sélectionne un backend et initie une nouvelle session TCP en direction de celui-ci, en envoyant SYN de manière autonome. Ce type en est un des basiques, d'autres variantes sont possibles.
• Répartiteur de charge L7 répartit le trafic parmi les backends disponibles de manière plus « raffinée » que ne le fait le répartiteur de charge L4. Il peut prendre des décisions concernant le choix du backend en fonction, par exemple, du contenu du message HTTP (l'URL, le cookie, etc.).

Indépendamment du type, un répartiteur de charge peut prendre en charge les fonctionnalités suivantes :

• Détection des services – processus de détermination de l'ensemble des backends disponibles (Static, DNS, Consul, Etcd, etc.).
• Vérification de la disponibilité des backends détectés (ping actif du backend avec une requête HTTP, détection passive des problèmes dans les connexions TCP, présence de plusieurs codes HTTP 503 consécutifs dans les réponses, etc.).
• La répartition elle-même (round robin, sélection aléatoire, hachage de l'adresse IP source, URI).
• Terminaison TLS et vérification des certificats.
• Options liées à la sécurité (authentification, prévention des attaques par déni de service, limitation de la bande passante) et bien plus encore.

NSX Edge propose le support de deux modes de déploiement pour le répartiteur de charge :

Mode proxy, ou one-arm. Dans ce mode, NSX Edge utilise son adresse IP comme adresse source lors de l'envoi d'une demande à l'un des backends. Ainsi, le répartiteur de charge remplit simultanément les fonctions de NAT source et de NAT destination. Le backend voit tout le trafic comme étant envoyé par le répartiteur de charge et lui répond directement. Dans ce schéma, le répartiteur doit être sur le même segment réseau que les serveurs internes.

Voici comment cela se passe :
1.       L'utilisateur envoie une demande à l'adresse VIP (adresse du répartiteur de charge), qui est configurée sur Edge.
2.       Edge choisit l'un des backends et effectue un NAT destination, remplaçant l'adresse VIP par l'adresse du backend sélectionné.
3.       Edge effectue un NAT source, remplaçant l'adresse de l'utilisateur ayant envoyé la demande par la sienne.
4.       Le paquet est envoyé au backend sélectionné.
5.       Le backend ne répond pas directement à l'utilisateur, mais à Edge, puisque l'adresse initiale de l'utilisateur a été changée en l'adresse du répartiteur de charge.
6.       Edge transmet la réponse du serveur à l'utilisateur.
Le schéma ci-dessous.


Mode transparent, ou en ligne. Dans ce scénario, le répartiteur de charge a des interfaces à la fois sur le réseau interne et externe. Il n'y a pas d'accès direct au réseau interne depuis l'extérieur. Le répartiteur 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 du répartiteur de charge), qui est configurée sur Edge.
2.       Edge choisit l'un des backends et effectue un NAT destination, remplaçant l'adresse VIP par l'adresse du backend sélectionné.
3.       Le paquet est envoyé au backend sélectionné.
4.       Le backend reçoit la demande avec l'adresse initiale de l'utilisateur (le NAT source n'a pas été exécuté) et lui répond directement.
5.       Le trafic est à nouveau pris en charge par le répartiteur de charge, car dans le schéma en ligne, il agit généralement comme la passerelle par défaut pour la grappe de serveurs.
6.       Edge effectue un NAT source pour envoyer le trafic à l'utilisateur, en utilisant son VIP comme adresse IP source.
Le schéma ci-dessous.

Pratique

Sur mon banc d'essai, 3 serveurs avec Apache configuré pour fonctionner en HTTPS sont installés. Edge effectuera la répartition des requêtes HTTPS par la méthode du round robin, en proxy chaque nouvelle demande vers 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 utiliser un certificat auto-signé. Dans ce test, je vais utiliser un certificat auto-signé.

1. Dans l'interface de vCloud Director, accédez aux paramètres des services Edge.
   
2. Accédez à l'onglet Certificats. Dans la liste des actions, choisissez d'ajouter un nouveau CSR.
   
3. Remplissez les champs nécessaires et cliquez sur Keep.
   
4. Sélectionnez le CSR nouvellement créé et choisissez l'option self-sign CSR.
   
5. Choisissez la durée de validité du certificat et cliquez sur Keep.
   
6. Le certificat auto-signé est apparu dans la liste des certificats disponibles.
   

Configurez le Profil d'Application.
Les profils d'application offrent un contrôle plus complet sur le trafic réseau et facilitent sa gestion. Ils permettent de définir le comportement pour des types de trafic spécifiques.

1. Allez dans l'onglet Load Balancer et activez le répartiteur de charge. L'option Acceleration enabled permet ici au répartiteur d'utiliser un équilibrage L4 plus rapide au lieu de L7.
   
2. Accédez à l'onglet Profil d'application pour définir le profil de l'application. Cliquez sur +.
   
3. Donnez un nom au profil et choisissez le type de trafic pour lequel le profil sera appliqué. Voici quelques explications sur certains paramètres.
   Persistence – conserve et suit les données de session, par exemple : quel serveur spécifique du pool traite la demande de l'utilisateur. Cela garantit que les demandes de l'utilisateur sont dirigées vers le même membre du pool tout au long de la session ou des sessions suivantes.
   Enable SSL passthrough – en choisissant cette option, NSX Edge arrête de terminer le SSL. Au lieu de cela, la terminaison se produit directement sur les serveurs pour lesquels l'équilibrage est effectué.
   Insert X-Forwarded-For HTTP header – permet de déterminer l'adresse IP d'origine du client se connectant au serveur web via le répartiteur de charge.
   Enable Pool Side SSL – permet d'indiquer que le pool sélectionné est composé de serveurs HTTPS.
   
4. Puisque je vais équilibrer le trafic HTTPS, il est nécessaire d'activer le Pool Side SSL et de choisir le certificat généré précédemment dans l'onglet Virtual Server Certificates –> Service Certificate.
   
5. De même pour Pool Certificates –> Service Certificate.
   

Créons un pool de serveurs dont le trafic sera équilibré.

1. Accédez à l'onglet Pools. Cliquez sur +.
   
2. Donnez un nom au pool, choisissez l'algorithme (je vais utiliser round robin) et le type de surveillance pour le contrôle de santé du backend. L'option Transparent indique si les adresses IP d'origine des clients sont visibles par les serveurs internes.
   • Si l'option est désactivée, le trafic pour les serveurs internes provient de l'adresse IP du répartiteur.
   • Si l'option est activée, les serveurs internes voient les adresses IP des clients. Dans cette configuration, NSX Edge doit agir en tant que passerelle par défaut pour garantir que les paquets retournés passent par NSX Edge.

   NSX prend en charge les algorithmes d'équilibrage suivants :

   • IP_HASH – sélection du serveur basé sur les résultats d'une fonction de hachage pour l'adresse IP source et destination de chaque paquet.
   • LEASTCONN – équilibrage des connexions entrantes en fonction du nombre de connexions déjà établies sur un serveur spécifique. Les nouvelles connexions seront dirigées vers le serveur avec le moins de connexions.
   • ROUND_ROBIN – les nouvelles connexions sont envoyées à chaque serveur à tour de rôle, selon le poids qui leur 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 dans le pool. Le résultat indique quel serveur reçoit la requête, garantissant que la requête est toujours dirigée vers le même serveur tant que tous les serveurs restent disponibles.
   • HTTPHEADER – équilibrage basé sur un en-tête HTTP spécifique qui peut être spécifié comme paramètre. Si l'en-tête est absent ou ne contient aucune valeur, l'algorithme ROUND_ROBIN est appliqué.
   • URL – chaque requête HTTP GET recherche un paramètre d'URL spécifié comme 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 suivre les identifiants des utilisateurs dans les requêtes et s'assurer qu'un même identifiant utilisateur est toujours envoyé au même serveur tant que tous les serveurs restent disponibles.

   

3. Dans le bloc Membres, cliquez sur + pour ajouter des serveurs au pool.
   
   
   1. L'adresse du serveur Elasticsearch (définie lors de l'installation).
   • nom du serveur ;
   • adresse IP du serveur ;
   • port sur lequel le serveur recevra le trafic ;
   • port pour le contrôle de santé (Surveillance de santé) ;
   • poids (Weight) – ce paramètre permet de réguler la quantité proportionnelle de trafic reçue par un membre spécifique du pool ;
   • Max Connections – nombre maximal de connexions au serveur ;
   • Min Connections – nombre minimal de connexions que le serveur doit traiter avant que le trafic soit redirigé vers le prochain membre du pool.

   
   
   Voici à quoi ressemble le pool final composé de trois serveurs.
   

Ajoutons un Serveur Virtuel

1. Nous passons à l'onglet Serveurs Virtuels. Cliquez sur +.
   
2. Activez le serveur virtuel en utilisant Activer le Serveur Virtuel.
   Nous lui attribuons un nom, choisissons le Profil d'Application créé précédemment, sélectionnons le Pool et indiquons l'adresse IP sur laquelle le Serveur Virtuel recevra des requêtes externes. Nous spécifions le protocole HTTPS et le port 443.
   Les paramètres optionnels ici :
   Limite de connexion – le nombre maximum de connexions simultanées que le serveur virtuel peut traiter ;
   Limite de taux de connexion (CPS) – le nombre maximum de nouvelles requêtes entrantes par seconde.
   

La configuration de l'équilibreur de charge est maintenant terminée, nous pouvons vérifier son fonctionnement. Les serveurs ont une configuration simple, permettant de comprendre quel serveur du pool a traité la requête. Lors de la configuration, nous avons sélectionné l'algorithme de répartition Round Robin, et le paramètre Poids pour chaque serveur est égal à un, donc chaque requête suivante sera traitée par le serveur suivant du pool.
Nous saisissons l'adresse externe de l'équilibreur de charge dans le navigateur et voyons :


Après avoir rafraîchi la page, la requête sera traitée par le serveur suivant :


Et encore une fois - pour vérifier le troisième serveur du pool :


Lors de la vérification, nous pouvons voir que le certificat que nous envoie Edge est celui que nous avons généré au tout début.

Vérification de l'état de l'équilibreur de charge depuis la console Edge gateway. Pour cela, tapez show service loadbalancer pool.


Configurons le Service Monitor pour vérifier l'état des serveurs dans le pool.
Avec le Service Monitor, nous pouvons suivre l'état des serveurs dans le pool backend. Si la réponse à la requête ne correspond pas à ce qui est attendu, le serveur peut être retiré du pool pour ne recevoir aucune nouvelle requête.
Trois méthodes de vérification sont configurées par défaut :

• TCP-monitor,
• HTTP-monitor,
• HTTPS-monitor.

Créons un nouveau.

1. Nous allons dans l'onglet Service Monitoring, cliquons sur +.
   
2. Nous choisissons :
   • un nom pour la nouvelle méthode ;
   • un intervalle pour l'envoi des requêtes,
   • un délai d'attente pour la réponse,
   • le type de surveillance – requête HTTPS utilisant la méthode GET, le code d'état attendu – 200(OK) et l'URL de la requête.
3. La configuration du nouveau Service Monitor est maintenant terminée, nous pouvons l'utiliser lors de la création du pool.
   

Configurons les Règles d'Application.

Les Règles d'Application sont un moyen de manipuler le trafic basé sur des déclencheurs spécifiques. Avec cet outil, nous pouvons créer des règles avancées de répartition de charge, dont la configuration pourrait ne pas être possible via des profils d'application ou d'autres services disponibles sur Edge Gateway.

1. Pour créer une règle, nous allons dans l'onglet Règles d'application du répartiteur.
   
2. Nous sélectionnons le nom, le script qui utilisera la règle et cliquons sur Conserver.
   
3. Une fois la règle créée, nous devons modifier le Serveur virtuel déjà configuré.
   
4. Dans l'onglet Avancé, nous ajoutons la règle que nous avons créée.
   

Dans l'exemple ci-dessus, nous avons activé le support tlsv1.

Quelques exemples supplémentaires :

Rediriger le trafic vers un autre pool.
Avec ce script, nous pouvons rediriger le trafic vers un autre pool de répartition si le pool principal ne fonctionne pas. Pour que la règle fonctionne, plusieurs pools doivent être configurés sur le répartiteur et tous les membres du pool principal doivent être en état d'arrêt. Il faut indiquer le nom du pool, et non son ID.

acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME


Rediriger le trafic vers une ressource externe.
Ici, nous redirigeons le trafic vers un site web externe si tous les participants au pool principal sont en état d'arrêt.

acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down

Encore plus d'exemples ici.

C'est tout pour le répartiteur. Si vous avez des questions, n'hésitez pas à demander, je suis prêt à répondre.

Source : habr.com