J’avais réalisé une série d’articles sur mon blog à propos de NSX de VMware (suite au salon VMworld), je vais parler maintenant de NSX-T et cela nous mènera vers l’offre VMware autour de Kubernetes dans le monde des containers et des PODs. De tout cela il a été question lors du Evolve 2018 à Paris.
NSX-T est en effet une série d’APIs permettant au logiciel de contrôler les réseaux (des couches 2 à 7 du modèle OSI). C’est à dire qu’il est possible de piloter par logiciel un switch virtuel, un routeur virtuel voire un répartiteur de charge, c’est ce dernier que nous allons voir dans cet article.
Actuellement (juin 2018) la version 2.2 qui est la version courante. On ne peut plus courante car je me base sur l’édition du 5 juin 2018 du guide d’installation. [NSX-T Installation Guide].
On notera que les besoins matériels sont de 4 CPU et 16GoRAM pour l’hyperviseur. Mais je vous laisse regarder les recommandations système dans la documentation VMware.
Dans NSX-T le répartiteur de charge s’appelle le ‘Logical Load Balancer’.
Ce répartiteur de charge a deux fonctions :
- Répartir une charge applicative entre plusieurs serveurs
- Assurer une haute disponibilité en cas de perte de serveurs
Les protocoles adressés par ce répartiteur de charge sont :
- couche 4 OSI :TCP, UDP
- couche 7 OSI :HTTP, HTTPS
Le répartiteur de charge est composé de serveurs virtuels, de groupe de serveurs et d’outils de surveillance d’état.
La surveillance d’état permet de savoir si un serveur est disponible, dans le cas contraire le répartiteur de charge peut supprimer le serveur du groupe des serveurs ‘up’. La surveillance est réalisée par un ‘moniteur actif’ (HTTP, HTTPS, TCP, UDP, ICMP et ‘moniteur passif’). Les requêtes HTTP peuvent être des requêtes complexes. La réponse du serveur testé doit arriver dans un temps donné et sans erreur. Il y a un outil de surveillance d’état par groupe de serveur ‘server pool’. L’ors d’une interrogation HTTP, les paramètres possibles sont les suivants :
- Méthode HTTP
- Paramètre URL d’une Requête
- Paramètre de la version d’une Requête
- Paramètre ‘body’ d’une Requête
- Paramètre ‘Code’ d’une Réponse (ce peut être les classiques 404,200 etc.)
- Paramètre ‘Body’ d’une Réponse
Il existe aussi la surveillance passive ‘Passive Health Monitor’ qui se fait lors des requêtes clients. Si la réponse n’est pas dans les temps ou avec une erreur, le serveur peut être marqué comme ‘hors service’.
Le répartiteur de charge peut être organisé en deux architectures :
Topologie ‘INLINE’
Le LoadBalancer se trouve sur le trajet entre le client et le serveur, c’est une topologie classique. Le client et le serveur n’ont pas besoin de se trouver sur le même routeur Tier-1. Et il n’y a pas besoin de serveur virtuel SNAT.
Topologie ‘One-ARM’
Dans ce mode le répartiteur de charge, ne se trouve pas entre le client et le serveur. Ils peuvent être n’importe où. Ce mode nécessite un serveur SNAT ‘Source NAT’ pour forcer le trafic retour vers le client par le chemin qu’il a utilisé à l’aller.
Une petite vidéo sur le concept SNAT ‘Source NAT’
Enfin une autre fonctionnalité qui permet de décharger le serveur des calculs de sécurité: les ‘profil SSL’. Cela permet d’avoir des profils SSL indépendants des applications. C’est typiquement le cas de l’architecture en ‘SSL offloading’ HTTPS du client vers le serveur virtuel du load balancer et http du serveur virtuel vers le serveur applicatif.
C’est différent dans l’architecture ‘end-to-end SSL’ ou la communication est HTTPS de bout en bout, c’est à dire client vers serveur applicatif.
Il faut noter que ‘SSL-terminate-mode’ et ‘SSL-proxy-mode’ ne sont pas supportés sur la version limitée à l’exportation de NSX-T 2.2.
Il peut y avoir deux type de serveur virtuel dans le load balancer :
- couche 4 OSI
- couche 7 OSI
Un serveur virtuel sert de relais entre le flux applicatif arrivant du client et ce même flux partant vers un serveur applicatif réel. Un serveur virtuel a une adresse IP, un port et un protocole de définis. Pour un serveur de niveau 4, un range d’adresses peut être défini ce qui est utile dans le cas de protocoles dynamiques dans l’attribution des numéros de port.
Un serveur virtuel doit être associé à un groupe de serveur.
Les serveurs de couche 7 OSI sont basés sur le protocole TCP / HTTP. Mais il y a des règles définissant le comportement de la répartition de charge. Dans ce cadre seront utilisées les expressions régulières.
