Geekly articles weekly

VMware NSX pour les plus petits. Partie 5. Configuration de l'équilibreur de charge



Première partie Introduction
Deuxième partie Configurer le pare-feu et les règles NAT
Troisième partie. Configuration DHCP
Quatrième partie Configuration du routage

La dernière fois que nous avons parlé des capacités de NSX Edge en termes de routage statique et dynamique, nous traiterons aujourd'hui de l'équilibreur.

Avant de procéder à la configuration, je voudrais rappeler brièvement les principaux types d'équilibrage.

Théorie


Toutes les solutions d'équilibrage de la charge utile d'aujourd'hui sont le plus souvent divisées en deux catégories: l'équilibrage aux quatrième (transport) et septième (appliqué) niveaux du modèle OSI . 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 l'équilibreur L4 prend également en charge la terminaison TLS, devient-il alors un équilibreur L7? Mais c'est-à-dire.

  • L'équilibreur L4 est le plus souvent celui qui se trouve entre le client et l'ensemble des backends proxy intermédiaires disponibles, qui met fin aux connexions TCP (c'est-à-dire, répond indépendamment à SYN), sélectionne un backend et lance une nouvelle session TCP dans sa direction, envoyant SYN lui-même. Ce type est l'une des bases, d'autres options sont possibles.
  • L'équilibreur L7 distribue le trafic vers les backends disponibles «plus sophistiqués» que l'équilibreur L4. Il peut décider d'un backend basé, par exemple, sur le contenu d'un message HTTP (URL, cookie, etc.).

Quel que soit le type, l'équilibreur peut prendre en charge les fonctions suivantes:

  • La découverte de service est le processus de détermination de l'ensemble des backends disponibles (statique, DNS, Consul, Etcd, etc.).
  • Vérification de la santé 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 503 codes HTTP dans les réponses consécutives, etc.).
  • Équilibrage lui-même (round robin, sélection aléatoire, hachage IP source, URI).
  • Terminaison TLS et vérification de certificat.
  • Options liées à la sécurité (authentification, prévention des attaques DoS, limitation de vitesse) et bien plus encore.

NSX Edge prend en charge deux modes de déploiement d'équilibreur:

Mode proxy ou à un bras . Dans ce mode, lors de l'envoi d'une demande à l'un des backends, NSX Edge utilise son adresse IP comme adresse source. Ainsi, l'équilibreur exécute les fonctions NAT source et destination. Le backend voit tout le trafic envoyé par l'équilibreur et y répond directement. Dans ce schéma, l'équilibreur doit être dans le même segment de réseau avec les serveurs internes.

Voici comment ça se passe:

  1. L'utilisateur envoie une demande à l'adresse VIP (adresse d'équilibrage) 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 exécute le NAT source, en remplaçant l'adresse de l'utilisateur qui a 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, car l'adresse d'origine de l'utilisateur a été remplacée par l'adresse de l'équilibreur.
  6. Edge envoie la réponse du serveur à l'utilisateur.

Schéma ci-dessous.



Mode transparent ou en ligne. Dans ce scénario, l'équilibreur possède des interfaces dans le réseau interne et externe. Cependant, il n'y a pas d'accès direct au réseau interne depuis l'extérieur. 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 d'équilibrage) 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 paquet 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é exécuté) et y répond directement.
  5. Le trafic est à nouveau accepté par l'équilibreur de charge, car dans le schéma en ligne, il sert généralement de passerelle par défaut pour la batterie de serveurs.
  6. Edge exécute le NAT source pour envoyer du trafic à l'utilisateur, en utilisant son VIP comme adresse IP source.

Schéma ci-dessous.



Pratique


Sur mon banc d'essai, 3 serveurs avec Apache sont configurés, qui est configuré pour fonctionner sur HTTPS. Edge équilibrera les demandes HTTPS à l'aide de la méthode round robin, en procurant chaque nouvelle demande à un nouveau serveur.

Commençons.

Génération d'un certificat SSL qui utilisera NSX Edge


Vous pouvez importer un certificat CA valide ou utiliser un certificat auto-signé. Dans ce test, j'utiliserai l'auto-signature.

  1. Dans l'interface vCloud Director, accédez aux paramètres des services Edge.

  2. Accédez à l'onglet Certificats. Dans la liste des actions, sélectionnez l'ajout d'un nouveau CSR.

  3. Remplissez les champs obligatoires et cliquez sur Conserver.

  4. Sélectionnez le CSR nouvellement créé et sélectionnez l'option CSR auto-signée.

  5. Sélectionnez la période de validité du certificat et cliquez sur Conserver

  6. Un certificat auto-signé est apparu dans la liste des disponibles.


Configurer le profil d'application


Les profils d'application vous donnent plus de contrôle sur le trafic réseau et rendent sa gestion simple et efficace. Avec leur aide, vous pouvez déterminer le comportement de certains types de trafic.

  1. Accédez à l'onglet Load Balancer et activez l'équilibreur. L'option Accélération activée permet ici à l'équilibreur d'utiliser un équilibrage L4 plus rapide au lieu de L7.

  2. Accédez à l'onglet Profil d'application pour définir le profil d'application. Cliquez sur +.

  3. Définissez le nom du profil et sélectionnez le type de trafic auquel le profil sera appliqué. Je vais expliquer quelques paramètres.

    Persistance - enregistre et suit les données de session, par exemple: quel serveur spécifique du pool sert une demande utilisateur. Cela garantit que les demandes des utilisateurs sont envoyées au même membre du pool pendant toute la durée de la session ou des sessions suivantes.

    Activer le passthrough SSL - lorsque cette option est sélectionnée, NSX Edge arrête de terminer SSL. Au lieu de cela, l'arrêt se produit directement sur les serveurs pour lesquels l'équilibrage est effectué.

    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.

    Activer SSL côté pool - vous permet de spécifier que le pool sélectionné se compose de serveurs HTTPS.

  4. Étant donné que j'équilibrerai le trafic HTTPS, je dois activer SSL côté piscine et sélectionner le certificat généré précédemment dans l'onglet Certificats de serveur virtuel -> Certificat de service.

  5. De même pour les certificats de pool -> certificat de service.


Nous créons un pool de serveurs, le trafic sur lequel les pools seront équilibrés


  1. Accédez à l'onglet Pools. Cliquez sur +.

  2. Définissez le nom du pool, sélectionnez l'algorithme (j'utiliserai le round robin) et le type de surveillance pour le contrôle de santé du backend. L'option Transparent indique si les clients IP source d'origine sont visibles pour les serveurs internes.

    • Si cette option est désactivée, le trafic pour les serveurs internes provient de l'adresse IP source de l'équilibreur.
    • Si cette option est activée, les serveurs internes voient les clients IP source. Dans cette configuration, NSX Edge doit agir comme 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ée sur les résultats de la fonction de hachage pour l'IP source et de destination de chaque paquet.
    • LEASTCONN - équilibrage des connexions entrantes, en fonction du nombre de déjà disponibles sur un serveur particulier. Les nouvelles connexions seront dirigées vers le serveur avec le moins de connexions.
    • ROUND_ROBIN - de nouvelles connexions sont envoyées à tour de rôle à chaque serveur, conformément au poids spécifié.
    • 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 demande, garantissant que la demande est toujours acheminé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é en tant que paramètre. Si l'en-tête est manquant ou n'a aucune signification, l'algorithme ROUND_ROBIN est utilisé.
    • URL - chaque requête HTTP GET recherche le paramètre URL spécifié comme argument. Si le paramètre est suivi d'un signe et d'une valeur égaux, 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 demande. Ce processus est utilisé pour suivre les ID utilisateur dans les demandes et pour garantir que le même ID 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.



    Ici, vous devez spécifier:

    • nom du serveur
    • Adresse IP du serveur;
    • le port vers lequel le serveur recevra le trafic;
    • port pour contrôle de santé (Monitor healthcheck);
    • Poids - avec ce paramètre, vous pouvez régler la quantité proportionnelle de trafic reçu pour un membre spécifique du pool;
    • Max Connections - le nombre maximum de connexions au serveur;
    • Connexions minimales - le nombre minimum de connexions que le serveur doit traiter avant que le trafic ne soit redirigé vers le membre de pool suivant.



    Voici à quoi ressemble le pool final de trois serveurs.


Ajouter un serveur virtuel


  1. Accédez à l'onglet Serveurs virtuels. Cliquez sur +.

  2. Nous activons le serveur virtuel en utilisant Activer le serveur virtuel.

    Nous lui donnons un nom, sélectionnons le profil d'application créé précédemment, le pool et spécifions l'adresse IP à laquelle Virtual Server acceptera les demandes provenant de l'extérieur. Spécifiez le protocole HTTPS et le port 443.
    Paramètres facultatifs ici:

    Limite de connexion - le nombre maximal de connexions simultanées qu'un serveur virtuel peut gérer;
    Connection Rate Limit (CPS) - Le nombre maximum de nouvelles demandes entrantes par seconde.



Ceci termine la configuration de l'équilibreur, vous pouvez vérifier ses performances. Les serveurs ont la configuration la plus simple, ce qui vous permet de comprendre quel serveur du pool a traité la demande. Pendant la configuration, nous avons sélectionné l'algorithme d'équilibrage Round Robin, et le paramètre Weight pour chaque serveur est égal à un, donc chaque requête suivante sera traitée par le serveur suivant du pool.

Entrez l'adresse externe de l'équilibreur dans le navigateur et voyez:



Après l'actualisation de la page, la demande sera traitée par le serveur suivant:



Et encore - pour vérifier le troisième serveur de la piscine:



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

Vérifiez l'état de l'équilibreur à partir de la console de passerelle Edge. Pour ce faire, entrez show service loadbalancer pool .



Configurer Service Monitor pour vérifier l'état des serveurs dans le pool


À l'aide de Service Monitor, nous pouvons surveiller l'état des serveurs dans le pool principal. Si la réponse à la demande ne correspond pas à ce qui était attendu, le serveur peut être supprimé du pool afin qu'il ne reçoive aucune nouvelle demande.

Par défaut, trois méthodes de vérification sont configurées:

  • Moniteur TCP
  • Moniteur HTTP
  • Moniteur HTTPS.

Créez-en un nouveau.

  1. Accédez à l'onglet Surveillance du service, cliquez sur +.

  2. Choisissez:

    • nom de la nouvelle méthode;
    • intervalle auquel les demandes seront envoyées,
    • délai de réponse
    • le type de surveillance est une requête HTTPS utilisant la méthode GET, le code d'état attendu est 200 (OK) et l'URL de la requête.
  3. Ceci termine la configuration du nouveau Service Monitor, nous pouvons maintenant l'utiliser lors de la création d'un pool.


Configurer les règles d'application


Les règles d'application sont un moyen de manipuler le trafic en fonction de déclencheurs spécifiques. À l'aide de cet outil, nous pouvons créer des règles d'équilibrage de charge avancées, qui peuvent ne pas être configurables via des profils d'application ou en utilisant d'autres services disponibles sur Edge Gateway.

  1. Pour créer une règle, accédez à l'onglet Règles d'application de l'équilibreur.

  2. Choisissez un nom, un script qui utilisera la règle, puis cliquez sur Conserver.

  3. Une fois la règle créée, nous devons modifier le serveur virtuel déjà configuré.

  4. Dans l'onglet Avancé, ajoutez la règle que nous avons créée.



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

Quelques exemples supplémentaires:

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 ne fonctionne pas. Pour que la règle fonctionne, plusieurs pools doivent être configurés sur l'équilibreur et tous les membres du pool principal doivent être en état d'arrêt. Spécifiez 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 un 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

Plus d'exemples ici .

C'est tout sur l'équilibreur. Si vous avez des questions, demandez, je suis prêt à répondre.

Source: https://habr.com/ru/post/fr448540/

More articles:


All Articles