Übersicht #

Ziel des folgenden Artikels ist es, einen architektonischen Überblick über RELIANOID Lastenausgleicher Software-Interna, die sich an Systemadministratoren und Softwareentwickler richten, die mehr darüber erfahren möchten, wie RELIANOID Die ADC-Software funktioniert. Alle diese Informationen können auch zur Konfiguration von Produktionssystemen oder zur Fehlerbehebung verwendet werden.

RELIANOID Architektur #

RELIANOID verwaltet Prozesse sowohl aus dem Benutzer- als auch aus dem Kernelbereich und ermöglicht so die Erzielung der größtmöglichen Leistung, aber auch die größtmögliche Flexibilität bei der Ausführung aller an den Application Delivery Controller delegierten Aufgaben wie Lastausgleich, Sicherheit und hohe Verfügbarkeit.

Das folgende Diagramm gibt einen globalen Überblick über die verschiedenen Komponenten, aus denen sich das RELIANOID System intern. Zusätzliche, weniger wichtige Teile wurden weggelassen, um eine einfachere und klarere Ansicht zu bieten.

In den folgenden Abschnitten werden die verschiedenen Teile und ihre Verbindung zueinander beschrieben.

RELIANOID Load Balancer im User Space #

Die im User Space verwendeten Subsysteme sind:

Web-GUI: Web-grafische Benutzeroberfläche, die von Benutzern zur Verwaltung der Konfiguration und Administration des gesamten Systems verwendet wird, wird von einem HTTPS-Webserver verwaltet, der die RELIANOID API für alle am Load Balancer ausgeführten Aktionen.

RELIANOID API: or RELIANOID Anwendungsprogrammschnittstelle, entwickelt nach dem REST und JSON Schnittstellen, die über HTTPS genutzt werden, werden von anderen Benutzeroberflächen aus der Sicht des Benutzers verwendet, wie zum Beispiel Web-GUI Schnittstelle oder ZCLI (RELIANOID Befehlszeilenschnittstelle). Dieses Tool prüft alle Aktionen im RBAC-Subsystem und wenn sie zulässig sind, wird die Aktion im RELIANOID Gerät. Die API kann jedes andere im Diagramm beschriebene Benutzerbereichssubsystem verbinden und verwalten.

RBAC ( Role-Based Access Control) ist ein Zugriffs- und Kontrollmechanismus, der auf Benutzern, Gruppen und Rollen basiert. Dieses Modul definiert die Aktionen, die ein Benutzer ausführen darf, und bietet umfangreiche Konfigurationsmöglichkeiten für Gruppen, Benutzer und Rollen. Es ist vollständig in die Web-GUI integriert und ermöglicht das Laden von Webansichten basierend auf der Benutzerrolle. Darüber hinaus kann dieses Subsystem über die API oder jedes andere Tool, das die API nutzt, verwendet werden.

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

GSLB: Das GSLB-Modul (Global Service Load Balancer), implementiert mit einer GSLB-Profilinstanz, wird im Benutzermodus von einem DNS-Serverprozess namens Gdnsd ausgeführt, der als erweiterter DNS-Nameserver mit Load-Balancing-Funktionen fungiert. Dieses Subsystem wird über die API konfiguriert und kann durch das IPDS-Subsystem (mittels Blacklists, DoS und RBL) geschützt werden.

Zustandsprüfungen: Dieses Subsystem wird über die API konfiguriert und von allen Load-Balancer-Modulen (LSLB, GSLB und DSLB) zur Überprüfung des Zustands der Backends verwendet. Es werden einfache und erweiterte Prüfungen durchgeführt. Schlägt eine Prüfung fehl, wird das Backend der jeweiligen Farm als ausgefallen markiert und kein weiterer Datenverkehr weitergeleitet, bis die Prüfung des Backends erfolgreich war. Der Farm Guardian ist für diese Prüfungen zuständig und zeichnet sich durch hohe Flexibilität und Konfigurierbarkeit aus.

Konfigurationsdateisystem: Dieses Verzeichnis dient zum Speichern von Konfigurationen. Änderungen in diesem Verzeichnis werden auf den Cluster repliziert, sofern dieser Dienst aktiviert ist.

Nftlb: Dieser Benutzerprozess wird vom API-Subsystem verwaltet und dient zwei Hauptzwecken: LSLB – L4XNAT -Management und Konfiguration des IPDS- Subsystemmoduls.

RELIANOID Load Balancer im Kernel-Space #

Die im Kernel Space verwendeten Subsysteme sind:

Netfilter-System LSLB L4xNAT: Das Netfilter-Subsystem wird von Nftlb für den Lastausgleich verwendet. Der Nftlb-Prozess lädt Netfilter-Regeln in den Kernel, um einen leistungsstarken L4-Loadbalancer aufzubauen . Nftlb lädt die Loadbalancer-Regeln effizient in den Kernel, um die Datenpakete optimal zu verwalten. Zusätzlich lädt Nftlb Netfilter-Regeln zur Verhinderung und zum Schutz vor Eindringlingen (Blacklists, RBL und DoS).

IPDS-Sperrlisten: Dieses Subsystem ist in das Netfilter-System integriert und wird von Nftlb verwaltet. Es besteht aus einer Gruppe von Regeln, die vor den Load-Balancer-Regeln konfiguriert werden, um Verbindungen von bestimmten Ursprungs-IPs zu blockieren . Intern erstellt es einen nach Kategorie, Land, Angreifertyp usw. geordneten und täglich aktualisierten Regelsatz.

IPDS RBL : Analog zum vorherigen Subsystem ist auch dieses in Netfilter integriert und wird von Nftlb verwaltet. Die Ursprungs-IP wird vor Verbindungsaufbau erfasst und die Client-IP anhand eines externen DNS-Dienstes validiert . Wird die IP aufgelöst, wird sie als schädlich markiert und die Verbindung getrennt.

IPDS DoS: Das gleiche Konfigurationssystem wie die beiden vorherigen Module, integriert in Netfilter und verwaltet von Nftlb. Es handelt sich um einen Regelsatz, der vor den Load-Balancing-Regeln konfiguriert wird und prüft, ob Pakete Teil eines Denial-of-Service-Angriffs sind . Einige Regeln werden auf den Paketfluss angewendet, um den Angriff abzufangen, bevor er ausgeführt werden kann.

Verbindungsüberwachungssystem: Dieses System wird vom Netfilter-Subsystem für die Verbindungsverwaltung, die Netzwerkübersetzung und das Statistikmodul sowie vom Integritätsprüfungssystem verwendet, um bei Erkennung eines Problems im Backend Verbindungsmaßnahmen zu erzwingen. Das Verbindungsüberwachungssystem wird außerdem vom Clustering-Dienst genutzt , um den Verbindungsstatus an den zweiten Knoten des Clusters weiterzuleiten. Fällt ein Cluster-Masterknoten aus, kann der zweite Knoten den Datenverkehr mit demselben Verbindungsstatus wie der vorherige Masterknoten weiterverarbeiten.

Routing-System und DSLB: Diese Subsysteme werden über die API verwaltet und im Kernel-Bereich konfiguriert. Das Routing-Subsystem basiert auf iproute2 , wodurch die Verwaltung mehrerer Routing-Tabellen ermöglicht wird und somit die Pflege komplexer Regelsätze für statisches Routing vermieden wird . Dank iproute2 wird außerdem das DSLB-Modul (Datalink Service Load Balancer) erstellt, das den Lastausgleich von Uplinks mit mehreren Gateways gewährleistet.

Im Moment des Schreibens dieses Artikels, RELIANOID 6 ist in Produktion, daher könnten diese Subsysteme in zukünftigen Versionen weiterentwickelt werden, um eine bessere Leistung oder mehr Funktionen zu bieten.

Zusätzliche Dokumentation #

RELIANOID zproxy-Benchmarks, LSLB-HTTP(S)-Profil
RELIANOID nftlb-Benchmarks, LSLB – L4xNAT-Profil