Aperçu

L'objectif de l'article suivant est de fournir une vue d'ensemble architecturale des composants internes du logiciel Zevenet destinée aux administrateurs système et aux développeurs de logiciels souhaitant en savoir plus sur le fonctionnement du logiciel Zevenet ADC. Toutes ces informations pourraient également être utilisées pour aider à la configuration des systèmes de production ou à des fins de dépannage.

Architecture de Zevenet

Zevenet gère les processus à la fois dans l'espace utilisateur et dans le noyau, ce qui permet de rassembler le plus de performances mais avec le plus de flexibilité pour effectuer toutes les tâches déléguées au contrôleur de distribution d'applications telles que l'équilibrage de charge, la sécurité et la haute disponibilité.

Le diagramme ci-dessous donne une vue globale des différents composants qui composent le système Zevenet en interne. Des pièces supplémentaires de moindre importance ont été manquées pour offrir une vue plus simple et claire.

Les sections suivantes seront décrites les différentes pièces et comment elles sont interconnectées.

Équilibreur de charge Zevenet dans l'espace utilisateur

Les sous-systèmes utilisés dans l'espace utilisateur sont:

Interface graphique Web: Interface utilisateur graphique Web utilisée par les utilisateurs pour gérer la configuration et l'administration de l'ensemble du système, elle est gérée par un serveur Web HTTPS qui utilise l'API Zevenet pour toutes les actions effectuées sur l'équilibreur de charge.

API Zevenet: ou l'interface du programme d'application Zevenet, conçue en suivant les REST et JSON interfaces, consommé via HTTPS, il est utilisé par d'autres interfaces utilisateur différentes du point de vue de l'utilisateur tels que le interface graphique Web interface ou ZCLI (Interface de ligne de commande Zevenet). Cet outil vérifie toute action par rapport au sous-système RBAC et s'il est autorisé, l'action est effectuée dans Zevenet Appliance. L'API est capable de connecter et de gérer tout autre sous-système de l'espace utilisateur décrit dans le diagramme.

RBAC : Le contrôle d'accès basé sur les rôles est un mécanisme d'accès et de contrôle défini autour des utilisateurs, des groupes et des rôles. Ce module définit les actions qu'un utilisateur est autorisé à effectuer avec un haut niveau de configuration entre les groupes, les utilisateurs et les rôles. Il est totalement intégré à l'interface graphique Web qui permet de charger les vues Web en fonction du rôle d'utilisateur. De plus, ce sous-système est consommé via le API ou tout autre outil qui utilise le API.

LSLB - HTTP (S): Le module LSLB (Local Service Load Balancer) composé par le profil HTTP (S) est exécuté dans l'espace utilisateur par un proxy inverse appelé Zproxy qui est capable de gérer très efficacement les applications à haut débit. Ce sous-système est configuré par l'API et peut être protégé par le sous-système IPDS (à l'aide des listes noires, des règles DoS, des ensembles de règles RBL et WAF).

GSLB : Le module GSLB (Global Service Load Balancer) implémenté avec une instance de profil GSLB est exécuté dans l'espace utilisateur par un processus de serveur DNS appelé Gdnsd qui peut fonctionner comme un serveur de noms DNS avancé avec des fonctions d'équilibrage de charge. Ce sous-système est configuré par l'API et peut être protégé par le sous-système IPDS (à l'aide de BlackLists, DoS et RBL).

Contrôles de santé: Ce sous-système est configuré par l'API et utilisé par tous les modules d'équilibrage de charge (LSLB, GSLB et DSLB) pour vérifier la santé des backends. Des contrôles simples et avancés sont exécutés par rapport au backend, puis si le contrôle échoue, le backend pour la batterie donnée est marqué comme étant en baisse et aucun trafic n'est transmis jusqu'à ce que le contrôle fonctionne à nouveau contre le backend. Le Farm Guardian est responsable de ces contrôles et il est conçu avec un haut niveau de flexibilité et de configurabilité.

Système de fichiers de configuration: Ce répertoire est utilisé à des fins d'enregistrement de la configuration, toute modification de ce répertoire sera répliquée sur le cluster, si ce service est activé.

Nftlb : Ce processus de l'espace utilisateur est géré par le sous-système API et utilisé à deux fins principales: LSLB - L4XNAT gestion et configuration du IPDS module de sous-système.

Équilibreur de charge Zevenet dans l'espace du noyau

Les sous-systèmes utilisés dans Kernel Space sont:

Système Netfilter LSLB L4xNAT: Le sous-système Netfilter est utilisé par Nftlb à des fins d'équilibrage de charge. Les règles Netfilter sont chargées dans le noyau par ce processus Nftlb afin de construire un équilibreur de charge L4 haute performance. Nftlb charge les règles d'équilibrage de charge dans le noyau de manière efficace pour gérer les paquets de trafic de manière optimale. De plus, Nftlb chargera les règles Netfilter pour la prévention et la protection contre les intrusions (BlackLists, RBL et DoS).

Listes noires IPDS: Ce sous-système est intégré au système Netfilter et géré par Nftlb. Il est composé d'un groupe de règles configuré avant les règles d'équilibrage de charge afin de supprimer les connexions pour les IP d'origine données. En interne, il crée un ensemble de règles ordonnées par catégorie, pays, types d'attaquants, etc. et mises à jour quotidiennement.

IPDS RBL: Par analogie avec le précédent, ce sous-système est également intégré à Netfilter et géré par Nftlb. L'IP d'origine est capturée avant l'établissement de la connexion et l'IP client est validée par un service DNS externe. Si l'adresse IP est résolue, l'adresse IP est marquée comme malveillante et la connexion sera interrompue.

DoS IPDS : Le même système de configuration que les deux modules précédents, intégré à Netfilter et géré par Nftlb. Il s'agit d'un ensemble de règles configurées avant les règles d'équilibrage de charge qui vérifient si les paquets font partie d'un Attaque par déni de service. Certaines règles sont appliquées au flux de paquets pour intercepter l'attaque avant d'être effectuée.

Système de suivi des connexions: Ce système est utilisé par le sous-système Netfilter à des fins de gestion de connexion, de traduction réseau et pour la module de statistiques, ainsi quedes Bilan de santé sous-système afin de forcer les actions de connexion au moment d'un problème est détecté dans le backend. Le système de suivi des connexions est également utilisé par Service de clustering afin de transmettre l'état de la connexion au deuxième nœud du cluster, en cas de défaillance d'un nœud maître de cluster, le deuxième nœud est capable de gérer le trafic dans le même état de connexion que le maître précédent.

Système de routage et DSLB: Ces sous-systèmes sont gérés par l'API et configurés dans l'espace noyau. Le sous-système de routage est construit avec iproute2 ce qui nous permet de gérer plusieurs tables de routage afin pour éviter de maintenir un ensemble de règles complexe pour le routage statiqueDe plus, grâce à iproute2, le module DSLB (Datalink Service Load Balancer) est créé pour fournir équilibrage de charge des liaisons montantes avec plusieurs passerelles.

Au moment d'écrire cet article, Zevenet 6 est en production, donc ces sous-systèmes pourraient évoluer dans les futures versions pour offrir de meilleures performances ou plus de fonctionnalités.

Documentation complémentaire

Benchmarks Zevenet zproxy, profil LSLB -HTTP (S)
Benchmarks Zevenet NFTLB, profil LSLB - L4xNAT