Interni dell'architettura Zevenet Load Balancer Enterprise Edition nello spazio utente e kernel

PUBBLICATO DA Zevenet 2 gennaio, 2020

Descrizione

Lo scopo di questo articolo è fornire una panoramica dell'architettura degli interni del software Zevenet indirizzata agli amministratori di sistema e agli sviluppatori di software con interessi a saperne di più su come funziona il software Zevenet ADC. Tutte queste informazioni potrebbero essere utilizzate anche per facilitare la configurazione dei sistemi di produzione o la risoluzione dei problemi.

Architettura Zevenet

Zevenet gestisce i processi dallo spazio utente e kernel consentendo di ottenere le massime prestazioni ma con la massima flessibilità e di eseguire tutte le attività delegate al controller di consegna delle applicazioni come bilanciamento del carico, sicurezza e disponibilità elevata.

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

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

Bilanciamento del carico Zevenet nello spazio utente

I sottosistemi utilizzati in User Space sono:

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

API Zevenet: o l'interfaccia del programma applicativo Zevenet, progettata in base a REST e JSON interfacce, consumate tramite HTTPS, sono utilizzate da altre interfacce utente diverse dal punto di vista dell'utente come GUI Web interfaccia o ZCLI (Interfaccia della riga di comando di Zevenet). Questo strumento controlla qualsiasi azione contro il sottosistema RBAC e se è consentito, l'azione viene eseguita nell'appliance Zevenet. L'API è in grado di connettersi e gestire qualsiasi altro sottosistema 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.

Bilanciamento del carico di Zevenet 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.

IPDS DoS: 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 della stesura di questo articolo, Zevenet 6 è in produzione, pertanto tali sottosistemi potrebbero evolversi nelle versioni future per offrire prestazioni migliori o più funzionalità.

Documentazione aggiuntiva

Zevenet benchmark zproxy, profilo LSLB -HTTP (S)
Benchmark Zevenet nftlb, profilo LSLB - L4xNAT

Condividere su:

Documentazione sotto i termini della GNU Free Documentation License.

questo articolo è stato utile?

Articoli Correlati