Panoramica #

Lo scopo del seguente articolo è fornire una panoramica dell'architettura di RELIANOID Load Balancer interni di software rivolti ad amministratori di sistema e sviluppatori di software interessati a saperne di più su come RELIANOID Il software ADC funziona. Tutte queste informazioni potrebbero essere utilizzate anche per facilitare la configurazione dei sistemi di produzione o per la risoluzione dei problemi.

RELIANOID architettura #

RELIANOID gestisce i processi sia dallo spazio utente che da quello kernel consentendo di ottenere il massimo delle prestazioni ma con la massima flessibilità, nonché di eseguire tutte le attività delegate all'application delivery controller come bilanciamento del carico, sicurezza e alta disponibilità.

Il diagramma seguente offre una visione globale dei diversi componenti che compongono il RELIANOID sistema internamente. Ulteriori pezzi di minore importanza sono stati tralasciati per offrire una visione più semplice e chiara.

Nelle sezioni seguenti verranno descritti i diversi pezzi e come sono interconnessi.

RELIANOID Bilanciatore del carico nello spazio utente #

I sottosistemi utilizzati in User Space sono:

GUI Web: interfaccia grafica web utilizzata dagli utenti per gestire la configurazione e l'amministrazione dell'intero sistema, è gestita da un webserver HTTPS che consuma il RELIANOID API per tutte le azioni eseguite sul bilanciatore del carico.

RELIANOID API: or RELIANOID Interfaccia del programma applicativo, progettata seguendo il REST and JSON interfacce, consumate tramite HTTPS, sono utilizzate da altre interfacce utente diverse dal punto di vista dell'utente come GUI Web interfaccia o ZCL (RELIANOID interfaccia a riga di comando). Questo strumento controlla qualsiasi azione contro il sottosistema RBAC e, se è consentita, l'azione viene intrapresa nel file RELIANOID Apparecchio. L'API è in grado di connettere e gestire qualsiasi altro sottosistema dello spazio utente descritto nel diagramma.

RBAC: Il controllo degli accessi in base al ruolo è un meccanismo di controllo e accesso definito attorno a utenti, gruppi e ruoli. Questo modulo definisce le azioni che un utente può eseguire con un alto livello di configurazione tra gruppi, utenti e ruoli. È totalmente integrato nell'interfaccia della GUI Web che consente di caricare le visualizzazioni Web in base al ruolo dell'utente. Inoltre, questo sottosistema viene utilizzato tramite API o qualsiasi altro strumento che utilizza il API.

LSLB - HTTP (S): Il modulo LSLB (Local Service Load Balancer) composto dal profilo HTTP (S) viene eseguito nello spazio utente da un proxy inverso chiamato Zproxy che è in grado di gestire applicazioni ad alto rendimento in modo molto efficiente. Questo sottosistema è configurato dall'API e può essere protetto dal sottosistema IPDS (utilizzando BlackList, regole DoS, set di regole RBL e WAF).

GSLB: Il modulo GSLB (Global Service Load Balancer) implementato con un'istanza del profilo GSLB viene eseguito nello spazio utente da un processo del server DNS chiamato Gdnsd che è in grado di funzionare come Nameserver DNS avanzato con funzionalità di bilanciamento del carico. Questo sottosistema è configurato dall'API e può essere protetto dal sottosistema IPDS (utilizzando BlackList, DoS e RBL).

Controlli sanitari: Questo sottosistema è configurato dall'API e utilizzato da tutti i moduli di bilanciamento del carico (LSLB, GSLB e DSLB) per verificare lo stato dei backend. I controlli semplici e avanzati vengono eseguiti sul back-end e, in caso di esito negativo, il back-end per la farm specificata viene contrassegnato come inattivo e non viene più inoltrato traffico fino a quando il check non funziona nuovamente con il back-end. Farm Guardian è responsabile di questi controlli ed è progettato con un alto livello di flessibilità e configurabilità.

File system di configurazione: Questa directory viene utilizzata ai fini del salvataggio della configurazione, qualsiasi modifica in questa directory verrà replicata nel cluster, se tale servizio è abilitato.

Nftlb: Questo processo di spazio utente è gestito dal sottosistema API e utilizzato per due scopi principali: LSLB - L4XNAT gestione e configurazione del IPDS modulo del sottosistema.

RELIANOID Bilanciatore del carico nello spazio del kernel #

I sottosistemi utilizzati in Kernel Space sono:

Sistema Netfilter LSLB L4xNAT: Il sottosistema Netfilter viene utilizzato da Nftlb a fini di bilanciamento del carico. Le regole di Netfilter sono caricate nel kernel da questo processo di Nftlb al fine di costruire un bilanciamento del carico L4 ad alte prestazioni. Nftlb carica le regole di bilanciamento del carico nel kernel in modo efficiente per gestire i pacchetti di traffico nel modo più ottimale possibile. Inoltre, Nftlb caricherà le regole di Netfilter per la prevenzione e la protezione dalle intrusioni (BlackLists, RBL e DoS).

Blacklist IPDS: Questo sottosistema è integrato nel sistema Netfilter e gestito da Nftlb. È composto da un gruppo di regole configurate prima delle regole di bilanciamento del carico per eliminare le connessioni per gli IP di origine indicati. Internamente crea un insieme di regole ordinate per categoria, paese, tipi di attaccante, ecc. E aggiornate quotidianamente.

IPDS RBL: Analogamente al precedente, questo sottosistema è integrato anche in Netfilter e gestito da Nftlb. L'IP di origine viene acquisito prima dell'istituzione della connessione e l'IP client viene convalidato rispetto un servizio DNS esterno. Se l'IP viene risolto, l'IP viene contrassegnato come dannoso e la connessione verrà interrotta.

DoS IPDS: Lo stesso sistema di configurazione dei due moduli precedenti, integrato in Netfilter e gestito da Nftlb. È un insieme di regole configurate prima delle regole di bilanciamento del carico che verificano se i pacchetti fanno parte di a Attacco Denial of Service. Alcune regole vengono applicate al flusso di pacchetti per intercettare l'attacco prima di essere eseguito.

Sistema di tracciamento della connessione: Questo sistema viene utilizzato dal sottosistema Netfilter per scopi di gestione delle connessioni, traduzione di rete e per modulo statistico, Nonché controllo sanitario sottosistema per forzare le azioni di connessione nel momento in cui viene rilevato un problema nel back-end. Il sistema di tracciamento della connessione viene utilizzato anche da Servizio di clustering per inoltrare lo stato della connessione al secondo nodo del cluster, nel caso in cui un nodo principale del cluster fallisca, il secondo nodo è in grado di gestire il traffico nello stesso stato della connessione rispetto al master precedente.

Sistema di routing e DSLB: Questi sottosistemi sono gestiti dall'API e configurati nello spazio del kernel. Il sottosistema di routing è costruito con iproute2 che ci consente di gestire più tabelle di routing in ordine per evitare di mantenere un insieme di regole complesso per il routing staticoinoltre, grazie a iproute2, il modulo DSLB (Datalink Service Load Balancer) è stato creato per fornire bilanciamento del carico di uplink con più gateway.

Al momento di scrivere questo articolo, RELIANOID 6 è in produzione, quindi questi sottosistemi potrebbero evolversi nelle versioni future per offrire prestazioni migliori o più funzionalità.

Documentazione aggiuntiva #

RELIANOID benchmark zproxy, profilo LSLB -HTTP(S).
RELIANOID benchmark nftlb, profilo LSLB – L4xNAT