Übersicht

Der folgende Artikel bietet einen Überblick über die Architektur von Zevenet-Software-Interna für Systemadministratoren und Software-Entwickler, die mehr über die Funktionsweise der Zevenet ADC-Software erfahren möchten. All diese Informationen können auch zur Konfiguration von Produktionssystemen oder zur Fehlerbehebung verwendet werden.

Zevenet-Architektur

Zevenet verwaltet Prozesse sowohl vom Benutzer- als auch vom Kernel-Bereich aus, um die höchste Leistung, aber auch die größte Flexibilität zu erzielen und alle an den Application Delivery Controller delegierten Aufgaben wie Lastausgleich, Sicherheit und Hochverfügbarkeit auszuführen.

Das folgende Diagramm gibt einen Überblick über die verschiedenen Komponenten, aus denen sich das Zevenet-System intern zusammensetzt. Zusätzliche weniger wichtige Elemente wurden übersehen, um eine einfachere und klarere Sicht zu ermöglichen.

In den folgenden Abschnitten werden die verschiedenen Teile beschrieben und wie sie miteinander verbunden sind.

Zevenet Load Balancer im User Space

Die im User Space verwendeten Subsysteme sind:

Web-GUI: Benutzeroberfläche mit Webgrafik, über die Benutzer die Konfiguration und Verwaltung des gesamten Systems verwalten. Sie wird von einem HTTPS-Webserver verwaltet, der die Zevenet-API für alle Aktionen verwendet, die am Load Balancer ausgeführt werden.

Zevenet-API: oder die Programmoberfläche von Zevenet Application, die nach dem REST und JSON Schnittstellen, die über HTTPS verwendet werden, werden von anderen Benutzerschnittstellen aus der Sicht des Benutzers verwendet, z Web-GUI Schnittstelle oder ZCLI (Zevenet-Befehlszeilenschnittstelle). Dieses Tool überprüft alle Aktionen mit dem RBAC-Subsystem. Wenn dies zulässig ist, werden die Aktionen in der Zevenet-Appliance ausgeführt. Die API ist in der Lage, jedes andere im Diagramm beschriebene Userspace-Subsystem zu verbinden und zu verwalten.

RBAC: Die rollenbasierte Zugriffssteuerung ist ein Zugriffs- und Kontrollmechanismus, der für Benutzer, Gruppen und Rollen definiert wird. Dieses Modul definiert, welche Aktionen ein Benutzer mit einem hohen Konfigurationsgrad zwischen Gruppen, Benutzern und Rollen ausführen darf. Es ist vollständig in die Web-GUI-Oberfläche integriert, mit der die Webansichten basierend auf der Benutzerrolle geladen werden können. Darüber hinaus wird dieses Subsystem über das konsumiert API oder ein anderes Tool, das die API.

LSLB - HTTP (S): Das durch das HTTP (S) -Profil erstellte LSLB-Modul (Local Service Load Balancer) wird im Benutzerbereich von einem Reverse-Proxy namens Zproxy ausgeführt, der in der Lage ist, Anwendungen mit hohem Durchsatz sehr effizient zu verwalten. Dieses Subsystem wird von der API konfiguriert und kann vom IPDS-Subsystem geschützt werden (mithilfe von BlackLists, DoS-Regeln, RBL- und WAF-Regelsätzen).

GSLB: Das mit einer GSLB-Profilinstanz implementierte GSLB-Modul (Global Service Load Balancer) wird im Benutzerbereich von einem DNS-Serverprozess namens Gdnsd ausgeführt, der als erweiterter DNS-Nameserver mit Lastenausgleichsfunktionen eingesetzt werden kann. Dieses Subsystem wird von der API konfiguriert und kann vom IPDS-Subsystem geschützt werden (mithilfe von BlackLists, DoS und RBL).

Gesundheitschecks: Dieses Subsystem wird von der API konfiguriert und von allen Load-Balancer-Modulen (LSLB, GSLB und DSLB) verwendet, um den Zustand der Backends zu überprüfen. Einfache und erweiterte Überprüfungen werden für das Backend ausgeführt. Wenn die Überprüfung fehlschlägt, wird das Backend für die angegebene Farm als inaktiv markiert und es wird kein Datenverkehr mehr weitergeleitet, bis die Überprüfung erneut für das Backend ausgeführt wird. Der Farm Guardian ist für diese Überprüfungen verantwortlich und bietet ein hohes Maß an Flexibilität und Konfigurierbarkeit.

Konfigurationsdateisystem: Dieses Verzeichnis wird zum Speichern der Konfiguration verwendet. Alle Änderungen in diesem Verzeichnis werden in den Cluster repliziert, sofern dieser Dienst aktiviert ist.

Nftlb: Dieser Userspace-Prozess wird vom API-Subsystem verwaltet und für zwei Hauptzwecke verwendet: LSLB - L4XNAT Verwaltung und Konfiguration der IPDS Subsystem-Modul.

Zevenet Load Balancer im Kernelraum

Die im Kernel Space verwendeten Subsysteme sind:

Netzfiltersystem LSLB L4xNAT: Das Netfilter-Subsystem wird von Nftlb zu Lastenausgleichszwecken verwendet. Netfilter-Regeln werden von diesem Nftlb-Prozess in den Kernel geladen, um Erstellen Sie einen leistungsstarken L4-Load-Balancer. Nftlb lädt die Load-Balancer-Regeln im Kernel auf effiziente Weise, um die Verkehrspakete so optimal wie möglich zu verwalten. Darüber hinaus lädt Nftlb Netfilter-Regeln zur Verhinderung und zum Schutz vor unbefugten Zugriffen (BlackLists, RBL und DoS).

IPDS-Blacklists: Dieses Subsystem ist in das Netfilter-System integriert und wird von Nftlb verwaltet. Es setzt sich aus einer Gruppe von Regeln zusammen, die vor den Load-Balancer-Regeln konfiguriert wurden, um Trennen Sie Verbindungen für die angegebenen Ursprungs-IPs. Intern werden Regeln erstellt, die nach Kategorie, Land, Angreifertyp usw. geordnet sind und täglich aktualisiert werden.

IPDS RBL: Analog zum Vorgänger ist auch dieses Subsystem in Netfilter integriert und wird von Nftlb verwaltet. Die Ursprungs-IP wird vor dem Verbindungsaufbau erfasst und die Client-IP wird mit validiert ein externer DNS-Dienst. Wenn die IP aufgelöst wird, wird die IP als bösartig markiert und die Verbindung wird getrennt.

IPDS-DoS: Dasselbe Konfigurationssystem wie die beiden vorherigen Module, in Netfilter integriert und von Nftlb verwaltet. Hierbei handelt es sich um eine Reihe von Regeln, die vor den Lastausgleichsregeln konfiguriert werden und prüfen, ob die Pakete Teil von a sind Denial-of-Service-Angriff. Einige Regeln werden auf den Paketfluss angewendet, um den Angriff abzufangen, bevor er ausgeführt wird.

Verbindungsverfolgungssystem: Dieses System wird vom Netfilter-Subsystem für Verbindungsverwaltungszwecke, für die Netzwerkübersetzung und für das Internet verwendet StatistikmodulSowie das Gesundheitscheck Subsystem, um Verbindungsaktionen zum Zeitpunkt eines Problems zu erzwingen, wird im Backend erkannt. Das Verbindungsverfolgungssystem wird auch von der verwendet Clustering-Dienst Um den Verbindungsstatus an den zweiten Knoten des Clusters weiterzuleiten. Fällt ein Cluster-Master-Knoten aus, kann der zweite Knoten den Datenverkehr im selben Verbindungsstatus wie der vorherige Master verwalten.

Routing System und DSLB: Diese Subsysteme werden von der API verwaltet und im Kernel-Space konfiguriert. Das Routing-Subsystem ist mit aufgebaut iproute2 Dies ermöglicht es uns, mehrere Routingtabellen der Reihe nach zu verwalten um zu vermeiden, dass ein komplexer Regelsatz für das statische Routing beibehalten wirdAußerdem wurde dank iproute2 das DSLB-Modul (Datalink Service Load Balancer) erstellt Load Balancing von Uplinks mit mehreren Gateways.

Zum Zeitpunkt des Schreibens dieses Artikels befindet sich Zevenet 6 in der Produktion, sodass diese Subsysteme in zukünftigen Versionen weiterentwickelt werden können, um eine bessere Leistung oder mehr Funktionen zu bieten.