Visão geral #

O objetivo do artigo a seguir é fornecer uma visão geral arquitetônica do RELIANOID Balanceador de carga internos de software direcionados a administradores de sistema e desenvolvedores de software com interesse em saber mais sobre como RELIANOID O software ADC funciona. Todas essas informações também podem ser usadas para ajudar na configuração de sistemas de produção ou para fins de solução de problemas.

RELIANOID arquitetura #

RELIANOID gerencia processos do espaço do usuário e do kernel, permitindo reunir o máximo desempenho, mas com maior flexibilidade, além de executar todas as tarefas delegadas ao controlador de entrega do aplicativo, como balanceamento de carga, segurança e alta disponibilidade.

O diagrama abaixo dá uma visão global dos diferentes componentes que compõem o RELIANOID sistema 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.

RELIANOID Balanceador de carga no espaço do usuário #

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

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

RELIANOID API: or RELIANOID Interface do programa aplicativo, projetada seguindo o 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 (RELIANOID interface da Linha de comando). Esta ferramenta verifica qualquer ação no subsistema RBAC e, se for permitida, a ação é executada no RELIANOID Utensílio. A API é capaz de conectar e gerenciar qualquer outro subsistema de espaço do usuário descrito no diagrama.

RBAC: O controle de acesso baseado em funções (Role-based Access Control) é 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 realizar, com um alto nível de configuração entre grupos, usuários e funções. Ele é totalmente integrado à interface gráfica do usuário (GUI) da web, permitindo o carregamento de visualizações da web com base na função do usuário. Além disso, este subsistema pode ser acessado por meio da API ou de qualquer outra ferramenta que utilize a 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 aplicações de alta taxa de transferência com muita eficiência. Este subsistema é configurado pela API e pode ser protegido pelo subsistema IPDS (utilizando listas negras, regras de DoS, listas negras de risco e conjuntos de regras 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 listas negras, DoS e RBL).

Verificações de integridade: Este subsistema é configurado pela API e usado por todos os módulos de balanceamento de carga (LSLB, GSLB e DSLB) para verificar a integridade dos servidores de backend. Verificações simples e avançadas são executadas no servidor de backend e, se a verificação falhar, o servidor de backend do farm em questão é marcado como inativo e nenhum tráfego adicional é encaminhado até que a verificação seja bem-sucedida novamente. 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 salvar configurações; qualquer alteração feita neste diretório será replicada para o cluster, caso esse serviço esteja habilitado.

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

RELIANOID Balanceador de carga no espaço do kernel #

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

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

Listas negras do IPDS: Este subsistema está integrado ao sistema Netfilter e é gerenciado pelo Nftlb. É composto por um grupo de regras configuradas antes das regras do balanceador de carga para bloquear conexões provenientes de determinados IPs de origem . Internamente, ele cria um conjunto de regras ordenadas por categoria, país, tipo de atacante, etc., e é atualizado diariamente.

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

IPDS DoS: O mesmo sistema de configuração dos dois módulos anteriores, integrado ao Netfilter e gerenciado pelo Nftlb. Trata-se de um conjunto de regras configuradas antes das regras de balanceamento de carga que verificam se os pacotes fazem parte de um ataque de negação de serviço (DoS) . Algumas regras são aplicadas ao fluxo de pacotes para interceptar o ataque antes que ele ocorra.

Sistema de rastreamento de conexões: Este sistema é utilizado pelo subsistema Netfilter para gerenciamento de conexões, tradução de rede e pelo módulo de estatísticas , bem como pelo subsistema de verificação de integridade, a fim de forçar ações de conexão no momento em que um problema é detectado no servidor. O sistema de rastreamento de conexões também é utilizado pelo serviço de Clustering para encaminhar o status da conexão para o segundo nó do cluster. Caso um nó mestre do cluster falhe, o segundo nó poderá gerenciar o tráfego com o mesmo status de conexão do 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 o iproute2 , que nos permite gerenciar múltiplas tabelas de roteamento para evitar a manutenção de um conjunto complexo de regras para roteamento estático . Além disso, graças ao iproute2, o módulo DSLB (Datalink Service Load Balancer) é criado para fornecer balanceamento de carga de uplinks com vários gateways.

No momento em que escrevo este artigo, RELIANOID 6 está em produção, portanto esses subsistemas poderão evoluir em versões futuras para oferecer melhor desempenho ou mais recursos.

Documentação adicional #

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