Il n'y a presque pas d'informations systématiques sur le NSX ALB en russe sur le réseau, seulement la documentation du fournisseur en anglais. Par conséquent, dans la première partie, j'ai résumé des sources éparses et fait un tour d'horizon du produit: j'ai parlé des fonctionnalités, de l'architecture et de la logique de travail, y compris pour les sites dispersés géographiquement. Dans la deuxième partie, je décrirai comment déployer et configurer le système. Espérons que les deux articles seront utiles pour ceux qui recherchent un équilibreur pour les environnements cloud et souhaitent évaluer rapidement les capacités de NSX ALB.
Fonctionnalités et capacités
NSX ALB est un équilibreur de charge défini par logiciel (SDLB) de niveau entreprise. Ce n'est pas typique pour les systèmes d'équilibrage de charge du type qui utilisent généralement des équilibreurs de charge matériels. Cette approche de la construction du système confère au NSX ALB une facilité de gestion et une évolutivité horizontale et verticale.
Quelles sont les fonctionnalités fournies par NSX ALB:
- Contrôle automatique de la puissance de l'équilibreur. Lorsque la charge de la part des clients augmente, la capacité est automatiquement augmentée, lorsque la charge diminue, elle est abandonnée.
- Équilibrage de charge sur des serveurs dispersés géographiquement. Un mécanisme GSLB (Global Server Load Balancing) distinct est responsable de cela.
- Équilibrage à l'un des niveaux: L4 (sur TCP / UDP) et L7 (sur HTTP / HTTPS).
- . NSX ALB ( VMware) on-premise :
- Intelligence applicative intégrée. Le système surveille les performances des applications et collecte des données: temps pour chaque étape du traitement de la connexion, évaluation de l'état de l'application et journaux de trafic en temps réel. En cas de problème, la surveillance peut rapidement dire où le rechercher.
Les données en temps réel sont collectées sur les connexions ouvertes simultanément, le temps d'aller-retour (RTT), le débit, les erreurs, les délais de réponse, les délais de négociation SSL, les types de réponse, etc. Toutes les informations en un seul endroit:
dans le bloc Log Analytics à droite, des statistiques sur les principaux paramètres de connexion sont collectées. Vous pouvez passer la souris sur la section souhaitée et vous familiariser rapidement.
De plus, NSX ALB a:
- Prise en charge de la multi-location pour différencier l'accès aux ressources.
- Health Monitor .
- Web Application Firewall (WAF).
- IPAM DNS.
- , . . IP-, . : Botnet, DoS, Mobile threats, Phishing, Proxy, Scanner, Spam source, Web attacks, Windows exploit .., – .
- Analyse des en-têtes HTTP des paquets qui passent. Vous pouvez utiliser des scripts (DataScript) basés sur le langage Lua et définir des actions Avi en fonction des valeurs de ces en-têtes: rediriger une requête, fermer ou réinitialiser une connexion, usurper des URI ou des valeurs dans un en-tête HTTP, sélectionner un pool de serveurs spécifique pour traiter une requête, travailler avec des cookies etc.
- Agissant en tant que contrôleur Ingress pour Kubernetes.
NSX ALB peut être géré via GUI, CLI et API REST.
Architecture et schéma de travail NSX ALB
NSX ALB fonctionne selon les principes standard de la plupart des SDLB. Les serveurs fournissant le service d'équilibrage sont regroupés en pools . Au-dessus des pools, l'administrateur système crée des services virtuels (VS) . Ils contiennent des paramètres du service en cours d'équilibrage, par exemple: type d'application, algorithme d'équilibrage, paramètres de connexion. VS fournit également aux clients une adresse IP virtuelle externe (IP virtuelle, VIP) pour accéder au service équilibré.
Regardons de plus près à quoi ressemble l'architecture: L'
élément clé du système est le contrôleur (Avi Controller)... Il est responsable de la montée en puissance automatique et contrôle centralement le VS. Vous pouvez déployer un contrôleur unique ou un cluster de basculement de contrôleurs dans votre infrastructure.
Dans la configuration de basculement, le cluster de contrôleurs se compose de 3 nœuds. L'un des nœuds devient le leader, le reste des suiveurs. Les 3 nœuds sont actifs et partagent la charge entre eux. Les principaux scénarios pour un cluster de contrôleurs:
- si un nœud échoue, cela n'affecte pas le fonctionnement du cluster;
- si le nœud principal échoue, ce rôle est transféré à l'un des autres;
- si 2 nœuds échouent, le service de contrôleur sur le nœud restant passe en mode lecture seule pour éviter un split-brain et attend qu'un autre nœud soit à nouveau disponible.
Après avoir déployé le contrôleur, l'ingénieur crée un VS et un pool de serveurs pour chaque VS. Pour les serveurs à l'intérieur du pool, vous pouvez choisir un algorithme d'équilibrage :
- Round Robin - la nouvelle connexion ira au serveur suivant dans le pool.
- Moins de connexions - la nouvelle connexion ira au serveur avec le moins de connexions simultanées.
- Moins de charge - la nouvelle connexion ira au serveur avec le moins de charge quel que soit le nombre de connexions.
- Hash cohérent - Les nouvelles connexions sont réparties sur les serveurs en fonction du hachage calculé. La clé de calcul du hachage est spécifiée dans un champ spécial ou dans une chaîne personnalisée. Pour chaque requête, un hachage est calculé à l'aide de cette clé. La connexion est envoyée au serveur correspondant au hachage calculé.
- Fastest Response – .
- Fewest Tasks – ( Avi CLI REST API.
- Fewest Servers – , .
Après avoir créé VS et le pool de serveurs, le contrôleur déploie lui-même des machines virtuelles de service, Service Engine (SE) , sur lesquelles se trouve le service équilibré. Chaque service (VS) est distribué sur plusieurs SE qui traitent les demandes des clients en parallèle. Cela garantit la résilience du service en cas de défaillance de la machine virtuelle.
Le contrôleur peut évaluer la charge et ajouter de nouveaux SE ou supprimer ceux qui ne sont pas chargés. Grâce à cette architecture, NSX ALB peut évoluer à la fois horizontalement - augmentant le nombre de SE et verticalement - augmentant la capacité de chaque SE.
Plus le SE équilibre de services, plus les interfaces réseau sont utilisées. Dans le schéma détaillé ci-dessous, nous voyons 2 types de réseaux:
- le réseau de contrôle et de transmission des informations de service forme le plan de contrôle ,
- les réseaux de données forment le plan de données .
Chaque SE dispose d'une interface réseau distincte sur le réseau de contrôle pour la communication avec le contrôleur. Le reste des interfaces est connecté au réseau externe et au réseau où se trouve le pool de serveurs pour l'équilibrage. Cette séparation de l'infrastructure réseau améliore la sécurité.
Pour chaque VS, vous devez définir les paramètres SE qui hébergeront le service. Ces paramètres sont définis dans le groupe SE (groupe SE) . Lors de la création de VS, nous sélectionnons le groupe SE: vous pouvez spécifier un groupe par défaut (Groupe par défaut) ou créer un nouveau groupe si VS a besoin de paramètres de machine virtuelle spéciaux.
Le groupe sélectionné déterminera comment le nouveau VS sera placé. Par exemple, si les SE du groupe par défaut sont déjà déployés dans le système et que ces SE ont toujours des ressources, le nouveau VS avec le groupe par défaut spécifié y sera situé. Si nous spécifions un nouveau groupe pour VS, de nouveaux SE avec des paramètres différents seront déployés en dessous.
Au niveau du groupe SE, définissez les paramètres de placement VS suivants:
- nombre maximum de SE dans un groupe,
- nombre maximum de VS par SE,
- une manière de placer VS sur SE: Compact, lorsque nous remplissons d'abord le premier SE le plus étroitement possible et passons au suivant, ou Distribué avec une distribution uniforme:
- Paramètres de la machine virtuelle SE: numéro de vCPU, mémoire et taille du disque,
Le débit pour 1 processeur virtuel est d'environ 40 000 connexions / s, avec une moyenne de 4 Go / s. Cet indicateur diffère selon les niveaux d'équilibrage et le protocole utilisé: il est plus sur L4, moins sur L7 en raison de la nécessité d'analyser le trafic, avec SSL c'est beaucoup moins en raison du besoin de cryptage.
- la durée de vie d'une SE inutilisée, après laquelle elle doit être supprimée,
- ressources pour héberger SE. Dans un environnement VMware, vous pouvez spécifier ou exclure un cluster ou des hôtes et une banque de données spécifiques à utiliser.
Passons à l'architecture et au flux de travail du service d'équilibrage global GSLB.
Architecture et workflow pour des serveurs dispersés géographiquement
Dans un service virtuel standard, nous pouvons ajouter des serveurs au pool à partir d'un seul cloud. Même si nous ajoutons plusieurs clouds sur le contrôleur en même temps, nous ne pourrons pas combiner des serveurs de différents clouds dans un seul VS. Le service d'équilibrage global GSLB résout ce problème. Il vous permet d'équilibrer les serveurs dispersés géographiquement situés dans différents nuages.
Au sein d'un service global, vous pouvez utiliser à la fois des clouds privés et publics. Voici les cas où vous pourriez avoir besoin d'un GSLB:
- haute disponibilité du service si tous les serveurs de l'un des clouds ne sont pas disponibles,
- la reprise après sinistre si un cloud est totalement inaccessible,
- , , . .
Examinons l'architecture de GSLB:
Le schéma de travail en un mot: l'équilibrage est effectué par le service DNS local déployé dans NSX ALB. Le client envoie une demande de connexion au service à l'aide du nom FQDN. DNS donne au client l'adresse IP virtuelle du VS local dans le cloud le plus optimal. Le service choisit le cloud le plus optimal en fonction de l'algorithme d'équilibrage, des données sur la disponibilité des VS locaux sur le moniteur de santé et de l'emplacement géographique du client. Vous pouvez définir différents algorithmes d'équilibrage - à la fois au niveau du service global et au niveau GSLB.
Comme vous pouvez le voir sur le diagramme GSLB, il est basé sur les éléments du diagramme précédent: les pools de serveurs, au-dessus d'eux se trouvent des services virtuels locaux (VS) avec une adresse IP virtuelle locale (VIP) et des machines virtuelles de service (SE). De nouveaux éléments apparaissent lors de la création du GSLB.
Service global (VS global) - un service équilibré entre des serveurs dispersés géographiquement ou des clouds privés et publics.
Un site GSLB comprend le contrôleur et les SE gérés par lui, situés dans le même cloud. Pour chaque site, vous pouvez définir la géolocalisation en latitude et longitude. Cela permettra à GSLB de sélectionner le pool de serveurs en fonction de la distance par rapport au client.
Les sites GSLB basés sur le système NSX ALB sont divisés en leaders (leaders) et suiveurs (suiveurs). Comme dans le cas des contrôleurs, ce schéma fournit une tolérance aux pannes pour le service GSLB.
Le site principal prend des décisions d'équilibrage, gère les connexions et surveille. Vous ne pouvez modifier la configuration GSLB qu'à partir du contrôleur de site maître.
Les sites esclaves peuvent être actifs ou passifs.
- Un site esclave passif gère uniquement les connexions client entrantes si le site maître choisit son VS local.
- Le site esclave actif reçoit sa configuration du site maître et, en cas de panne, peut prendre le rôle principal.
Les sites GSLB peuvent également être des sites externes, construits sur des équilibreurs de tiers.
Le pool global est différent du pool local, qui contient des serveurs locaux. Dans un pool global, vous pouvez combiner des services virtuels dispersés géographiquement à partir de différents sites. En d'autres termes, le pool global contient des VS locaux, qui sont établis au niveau des sites GSLB.
L'équilibrage des connexions entre les serveurs du pool global est effectué:
- par algorithme Round Robin,
- par géolocalisation du serveur,
- ,
- Consistent Hash.
Pour un service global, vous pouvez créer plusieurs pools globaux et inclure un ou plusieurs sites dans chaque VS local. Dans ce cas, les nouvelles connexions seront distribuées selon la géolocalisation ou selon des priorités spécifiées. Pour définir les priorités des serveurs du pool, vous pouvez définir un poids différent pour chacun.
Un exemple d'équilibrage entre les pools globaux . Voici comment le VS global distribuera les connexions dans ce schéma: Le
GslbPool_3 a une priorité de 10 et sera préféré pour les connexions client. Parmi ces connexions, 40% de la charge ira à VS-B3 et 60% à VS-B4. Si GslbPool_3 devient indisponible, toutes les connexions client iront complètement à GslbPool_2 et la charge entre VS-B3 et VS-B4 sera uniformément répartie.
DNS localcontiennent des enregistrements avec les noms FQDN des services qui y sont équilibrés.
GSLB DNS est le mode de fonctionnement DNS VS local, utilisé pour équilibrer les connexions entre les sites GSLB.
Le VS DNS local commence à agir comme DNS GSLB lorsque nous le sélectionnons comme service DNS pour un GSLB augmenté. Un tel DNS VS doit être déployé sur tous les sites inclus dans les pools globaux.
GSLB ajoute des enregistrements FQDN de service global à chaque DNS local. NSX ALB remplit cet enregistrement avec les adresses IP virtuelles du VS local de tous les sites inclus dans le pool VS global. Ces VIP supplémentaires sont ajoutés automatiquement avec de nouveaux VS locaux ajoutés au pool. Les données des enregistrements sont mises à jour au fur et à mesure que les informations sur la charge du service, la disponibilité des serveurs et l'éloignement des clients des sites sont accumulées. Lorsqu'un nouveau client se connecte à l'aide du FQDN, l'un des DNS locaux émet l'adresse VIP du VS local, en tenant compte de ces données réelles accumulées.
Comment déployer et configurer le système NSX ALB, ainsi que monter le service GSLB dans celui-ci, je décrirai dans la deuxième partie de cet article.