Arquitetura interna do Zevenet Load Balancer Enterprise Edition no espaço do usuário e do kernel

POSTADO POR Zevenet | 2 de janeiro de 2020

Visão geral

O objetivo do artigo a seguir é fornecer uma visão geral da arquitetura dos componentes internos do software Zevenet direcionados a administradores de sistemas e desenvolvedores de software com interesse em saber mais sobre como o software Zevenet ADC funciona. Todas essas informações podem ser usadas também para ajudar na configuração dos sistemas de produção ou na solução de problemas.

Arquitetura Zevenet

O Zevenet gerencia processos do espaço do usuário e do kernel, permitindo obter o máximo desempenho, mas com a maior flexibilidade possível para executar todas as tarefas delegadas ao controlador de entrega de aplicativos, como balanceamento de carga, segurança e alta disponibilidade.

O diagrama abaixo fornece uma visão global dos diferentes componentes que compõem o sistema Zevenet internamente. Peças adicionais de menor importância foram perdidas para oferecer uma visão mais simples e clara.

As seções a seguir descrevem as diferentes peças e como elas são interconectadas.

Balanceador de carga Zevenet no espaço do usuário

Os subsistemas usados ​​no Espaço do Usuário são:

GUI da Web: interface gráfica do usuário da web usada pelos usuários para gerenciar a configuração e administração de todo o sistema, é gerenciada por um servidor da web HTTPS que consome a API do Zevenet para todas as ações realizadas no balanceador de carga.

API do Zevenet: interface do programa Zevenet Application, projetada seguindo as DESCANSO e JSON interfaces consumidas por HTTPS, é usado por outras interfaces de usuário diferentes do ponto de vista do usuário, como o GUI da web interface ou ZCLI (Interface de linha de comando Zevenet). Essa ferramenta verifica qualquer ação no subsistema RBAC e, se for permitido, a ação é executada no Zevenet Appliance. A API é capaz de conectar e gerenciar qualquer outro subsistema de espaço de usuário descrito no diagrama.

RBAC: O controle de acesso baseado em função é um mecanismo de acesso e controle definido em torno de usuários, grupos e funções. Este módulo define quais ações um usuário pode executar com um alto nível de configuração entre grupos, usuários e funções. É totalmente integrado à interface GUI da web que permite carregar as visualizações da web com base na função do usuário. Além disso, esse subsistema é consumido através do API ou qualquer outra ferramenta que use o API.

LSLB - HTTP (S): O módulo LSLB (Local Service Load Balancer) composto pelo perfil HTTP (S) é executado no espaço do usuário por um proxy reverso chamado Zproxy, capaz de gerenciar aplicativos de alto rendimento com muita eficiência. Este subsistema é configurado pela API e pode ser protegido pelo subsistema IPDS (usando BlackLists, regras de DoS, conjuntos de regras RBL e WAF).

GSLB: O módulo GSLB (Global Service Load Balancer) implementado com uma instância de perfil GSLB é executado no espaço do usuário por um processo de servidor DNS chamado Gdnsd, capaz de funcionar como um servidor de nomes DNS avançado com recursos de balanceamento de carga. Este subsistema é configurado pela API e pode ser protegido pelo subsistema IPDS (usando BlackLists, DoS e RBL).

Verificações de saúde: Este subsistema é configurado pela API e usado por todos os módulos do balanceador de carga (LSLB, GSLB e DSLB) para verificar a integridade dos back-ends. Verificações simples e avançadas são executadas no back-end e, se a verificação falhar, o back-end do farm especificado é marcado como inativo e não há mais tráfego encaminhado até que a verificação funcione novamente no back-end. O Farm Guardian é responsável por essas verificações e foi projetado com um alto nível de flexibilidade e configurabilidade.

Sistema de arquivos de configuração: Este diretório é usado para fins de economia de configuração, qualquer alteração nesse diretório será replicada para o cluster, se esse serviço estiver ativado.

Nftlb: Esse processo do espaço do usuário é gerenciado pelo subsistema da API e usado para dois propósitos principais: LSLB - L4XNAT gerenciamento e configuração do IPDS módulo de subsistema.

Balanceador de carga Zevenet no espaço do kernel

Os subsistemas usados ​​no Kernel Space são:

Sistema Netfilter LSLB L4xNAT: O subsistema Netfilter é usado pelo Nftlb para fins de balanceamento de carga. As regras do Netfilter são carregadas no kernel por esse processo Nftlb para construir um balanceador de carga L4 de alto desempenho. O Nftlb carrega as regras do balanceador de carga no kernel de maneira eficiente para gerenciar os pacotes de tráfego da melhor maneira possível. Além disso, o Nftlb carregará as regras do Netfilter para prevenção e proteção contra intrusões (BlackLists, RBL e DoS).

Listas negras de IPDS: Esse subsistema é integrado ao sistema Netfilter e gerenciado pelo Nftlb. É composto por um grupo de regras configuradas antes das regras do balanceador de carga para descartar conexões para os IPs de origem fornecidos. Internamente, ele cria um conjunto de regras ordenadas por categoria, país, tipos de atacantes etc., e atualizadas diariamente.

IPDS RBL: Analogamente que o anterior, esse subsistema também é integrado ao Netfilter e gerenciado pelo Nftlb. O IP de origem é capturado antes do estabelecimento da conexão e o IP do cliente é validado contra um serviço DNS externo. Se o IP for resolvido, ele será marcado como malicioso e a conexão será eliminada.

IPDS DoS: O mesmo sistema de configuração que os dois módulos anteriores, integrados ao Netfilter e gerenciados pelo Nftlb. É um conjunto de regras configuradas antes das regras do balanceamento de carga que verificam se os pacotes fazem parte de um Ataque de negação de serviço. Algumas regras são aplicadas ao fluxo de pacotes para interceptar o ataque antes de ser feito.

Sistema de rastreamento de conexão: Este sistema é usado pelo subsistema Netfilter para fins de gerenciamento de conexão, conversão de rede e para o módulo de estatísticas, Bem como o exame de saúde O subsistema para forçar ações de conexão no momento de um problema é detectado no back-end. O sistema de rastreamento de conexão também é usado pelo Serviço de cluster para encaminhar o status da conexão para o segundo nó do cluster, caso um nó principal do cluster falhe, o segundo nó poderá gerenciar o tráfego no mesmo status de conexão que o mestre anterior.

Sistema de roteamento e DSLB: Esses subsistemas são gerenciados pela API e configurados no espaço do Kernel. O subsistema de roteamento é construído com iproute2 o que nos permite gerenciar várias tabelas de roteamento em ordem evitar a manutenção de um conjunto de regras complexo para roteamento estáticoAlém disso, graças ao iproute2, o módulo DSLB (Datalink Service Load Balancer) foi criado para fornecer balanceamento de carga de uplinks com vários gateways.

No momento da redação deste artigo, o Zevenet 6 está em produção, para que esses subsistemas possam evoluir em versões futuras para oferecer melhor desempenho ou mais recursos.

Documentação adicional

Zevenet zproxy benchmarks, perfil LSLB -HTTP (S)
Benchmarks Zevenet nftlb, perfil LSLB - L4xNAT

Compartilhar no:

Documentação sob os termos da Licença de Documentação Livre GNU.

Esse artigo foi útil?

Artigos Relacionados