Nascido em 1988, o projeto open source Linux Virtual Server (LVS) teve como objetivo a construção de servidores de alta performace e disponibilidade para sistemas baseados em Linux.
O LVS possui alguns componentes em seu framework, dos quais se destacam três. O primeiro deles, chamado de Servidor Virtual de IP – do inglês
IP Virtual Server (IPVS), é um software de balanceamento de carga que é
inserido dentro do kernel do Linux. Assim como o IPVS, o KTCPVS também é inserido dentro do kernel e faz o balanceamento de carga a nível de aplicação. E o último, é denominado de Cluster Management usado para monitoramento e administração dos computadores que pertencem ao cluster. A Figura 19 mostra uma visão geral do framework.
Figura 19. Framework LVS
Fonte: Zhang. (2004)
Entre os objetivos desse framework estão a garantia de fornecer escalabilidade, confiabilidade e capacidade de manutenção, usando uma tecnologia de clustering. É importante apresentar alguns conceitos acerca do
LVS, como: Servidores Reais – do inglês Real Server (servidor que fornece o
serviço), Farm (conjunto de Real Servers que compõem o cluster), IP virtual (VIP), usado para o acesso das requisições do cliente, IP dos Real Servers (RIP) e Probe (Operação de monitoramento que verifica a sanidade dos componentes).
Existem três modos de tratamento de requisições usados no LVS. I. LVS VIA NAT
A técnica de NAT, como sabemos, consiste na tradução do endereço de rede, como a sigla auto se define. No método LVS via NAT, mostrado na Figura 20, acontece o mesmo. O balanceador de carga, que possui o IP Virtual, recebe as requisições do cliente, traduz o endereço de IP de destino para um dos endereços IP dos servidores reais e estes respondem ao balanceador, que
dessa vez, traduz o endereço de IP de origem como sendo o seu e, assim, responde às requisições dos clientes. É importante destacar que nesse método acontece a reescrita do pacote IP duas vezes. E o pacote passa pelo balanceador duas vezes para uma única requisição do cliente, isso requer um aumento no consumo de recursos computacionais, diferentemente dos métodos seguintes.
Figura 20. Método LVS via NAT
Fonte: Zhang. (2004, p. 3)
II. LVS VIA IP Tunneling
Neste método, realiza-se um túnel entre os servidores reais e o balanceador. Ele pode ser visto na Figura 21. Este túnel pode ser implementado em uma rede local ou não.
Toda requisição que passa pelo balanceador e é atribuída à algum serviço (do sistema), é encaminhada aos servidores de aplicação (através do encapsulamento do pacote IP e de acordo com a tabela de rotas do balanceador) que respondem à requisição diretamente ao cliente.
Figura 21. Método LVS via IP Tunneling
Fonte: Zhang. (2016, p. 4)
Perceba que há a manipulação do pacote, quando ele é encaminhado pelo balanceador ao realizar o encapsulamento. Isso retarda um pouco o processo, mas temos um ganho melhor de eficiência se comparado ao LVS Via
NAT.
III. LVS VIA Direct Routing
Similar ao LVS Via IP Tunneling, no LVS Via Direct Routing, exibido na Figura 22, as respostas às requisições (vindas do cliente e direcionadas pelo
servidor ao cluster) são feitas diretamente pelos servidores reais. Porém, temos aqui duas ressalvas. Pelo fato do RIP ser igual ao VIP, o Protocolo de Resolução de Endereços – do inglês Address Resolution Protocol (ARP) - deve estar desabilitado, tanto no cluster quanto no balanceador. O cluster de servidores tem que estar na mesma rede local que a do balanceador, pois no direcionamento feito pelo balanceador, há a reescrita do endereço MAC de destino (endereço do servidor real). Essa última característica diminui a sobrecarga do processo, uma vez que a reescrita do pacote acontece na camada de enlace.
Figura 22. Método LVS via Direct Routing
Fonte: Zhang (2004, p. 4)
O LVS implementa os seguintes algoritmos listados na seção 2.6.2: RR,
4 Implementação
de
um
Balanceador de Carga para uma
Aplicação Qualquer
Neste capítulo será apresentado de maneira genérica, a ideia geral de um balanceador de carga, que efetua o balanceamento da carga de trabalho para um cluster de aplicações quaisquer. Exibirá um esquema matemático para o entendimento da distribuição da carga e um modelo, enfatizando o funcionamento do balanceador.
4.1 Esquema Matemático
O intuito da apresentação desse esquema é descrever idealmente o funcionamento de um balanceador de carga genérico, sendo que, a disposição de seus componentes é baseada no escopo desse trabalho.
Nos objetivos citados neste documento, construímos a hipótese de que ao distribuirmos a carga de trabalho entre os nós, aumentamos o desempenho do processamento de cada carga, diminuindo a sobrecarga nos nós do cluster. Espera-se que o mesmo ocorra quando aumentarmos o número de nós. Para provarmos essa hipótese devemos nos aproximar do ideal. No capítulo 6 são apresentados os experimentos realizados a fim de validar essa ideia.
Nós já norteamos um pouco a ideia do trabalho, falando a respeito do “balanceador”, mas na verdade, o sistema de balanceamento discutido aqui consiste, principalmente, de dois balanceadores de carga. Um deles faz a interface entre a rede externa e o cluster de aplicação; o outro é o intermediário entre o cluster e a rede interna. Para visualizarmos melhor o fluxo dentre os balanceadores e o conjunto de aplicações, tomaremos como
referência o modelo de escalonamento em sistemas distribuídos proposto por (LOPES & MANASCÉ, 2015).
Como já apresentado, este modelo destaca três componentes básicos: carga de trabalho, recursos e requisitos. Sabemos que a carga de trabalho é responsável por consumir os recursos do sistema. Com isso, podemos definir a carga de trabalho como um conjunto do qual seus elementos podem ser associados à recursos, como tarefas a serem executadas por eles. Assim, considerando a Figura 23
Figura 23. Esquema matemático do balanceador de carga
Fonte: elaborado pelo autor
𝛽
0 e𝛽
1 representam os balanceadores de carga,𝛬
representa a cargade trabalho total (ou o conjunto total de conexões) a ser distribuída entre os recursos, que são representados através dos
𝜌
, podendo haver r destes. Cada𝜌
possui um𝜆
que indica a carga de trabalho a ser processada (ou𝜆 ⊆ 𝛬
). De maneira ideal, as𝛬
são iguais, as𝜆
, também e os𝜌
são idênticos entre si. Não há perda de carga de trabalho. As setas bidirecionais indicam, abstratamente, os links entre os balanceadores e os recursos. A distribuição da𝛬
se dá por meio de um valor h obtido de uma função hash genérica ideal que recebe como parâmetro a𝛬
. No esquema, r e k pertencem ao conjunto dos naturais sem o zero. É importante salientar que r e k são iguais. O valor htambém pertence aos naturais e é compreendido entre 1 <= h <= d, seja d = r
= k.
Para a ideia apresentada, é óbvio que
Perceba que, como
𝜆
i é subconjunto de𝛬
, ele não se refere à i-ésimaconexão e sim ao i-ésimo conjunto de conexões contidas em
𝛬
.Os balanceadores
𝛽
são compostos das funções hash que, ao receber o conjunto𝛬
, faz um cálculo com os elementos desse conjunto para a obtenção de h e , a partir daí, atribuir a𝜆
h ao recurso𝜌
h apropriado.Como foi falado, este esquema possui dois balanceadores. Claro que não é obrigado se ter os dois para se efetuar o balanceamento, porém isto é apenas uma característica peculiar. No caso, os
𝛽
devem produzir um mesmo h para garantir a transmissão do conjunto de conexões por um𝜌
único.4.2 Arquitetura
Na seção 3.1 foi apresentado o funcionamento do fluxo de atribuição de tarefas à recursos do sistema. Aproximando-se ainda mais do contexto desse trabalho.
Nesta seção será apresentado a ideia geral da arquitetura e o seu funcionamento, analisando o fluxo das requisições feitas por componentes de
uma rede de dispositivos (usuários, clientes, servidores, datacenter’s, aplicações) que “atravessam” o sistema de balanceamento em questão.
4.2.1
Ideia Geral
Para uma maior clareza da arquitetura observe a Figura 24. Nela, é possível ver duas setas bidirecionais. A primeira delas (mais à esquerda) representa as requisições dos serviços ou clientes externos, que passam pela infraestrutura da internet até chegar ao balanceador de carga mais externo. A segunda, demonstra de maneira análoga o fluxo de requisições dos clientes internos, passando pela infraestrutura interna da rede e chegando ao sistema de balanceamento. A parte central da figura corresponde ao sistema, propriamente dito, composto dos dois balanceadores - já discutidos – conectados aos servidores de aplicação do cluster. É importante enfatizar que as aplicações envolvidas podem ser de quaisquer naturezas (servidores IDS, servidores de email, firewalls, etc).
Figura 24. Arquitetura proposta do trabalho
Referente à taxonomia apresentada por Roman et al (2016, p. 446), o balanceamento dos servidores de aplicação na arquitetura descrita nesta seção é classificado como estático e não-colaborativo.
4.2.1.1 Algoritmo de hash
Como discutido na seção 2.6.3, cada balanceador de carga dessa arquitetura possui um módulo inserido em seu kernel. Cada módulo é composto por funções que permitem ao balanceador se comportar como tal. Uma dessa funções corresponde ao cáculo do valor de hash. Os algoritmos ou funções de hash, nos balanceadores, baseiam-se nos da plataforma da
Microsoft Azure, os quais ultilizam uma 5-tupla para geração do hash. Sua
principal diferença com o da arquitetura proposta é que consideram o protocolo envolvido na conexão, como algum dos parâmetros. Aliás, o algoritmo de hash da Azure é o único, dentre as soluções citadas, que utiliza essa quantidade de parâmetros para a geração do valor de hash. A ideia dessa abordagem, na arquitetura apresentada, é garantir o tráfego único (fluindo por um único servidor de aplicação) das conexões na parte central da arquitetura, tanto as que vem do balanceador externo quanto as do interno. A garantia disso possibilita aplicações, como IDS, analisarem uma determinada conexão, bem como mantém a persistência das conexões para aplicações que requerem o uso de cookies4.
Para que seja realizado o comportamento de um fluxo único entre os balanceadores, é preciso que os mesmos gerem um valor de hash igual. Para gerar o valor único para uma mesma conexão, utilizou-se uma combinação
4 Quite simply, a cookie is a small text file that is stored by a browser on the user’s machine.
Cookies are plain text; they contain no executable code. A web page or server instructs a browser to store this information and then send it back with each subsequent request based on a set of rules. Web servers can then use this information to identify individual users. Most sites requiring a login will typically set a cookie once your credentials have been verified, and you are then free to navigate to all parts of the site so long as that cookie is present and validated. Once again, the cookie just contains data and isn’t harmful in and of itself. (Zakas, 2009)
linear que é, basicamente, uma função no formato, por exemplo, ax+by, onde
a e b são constantes, com as variáveis x e y pertencentes ao conjunto dos
números reais. Para o contexto da arquitetura, essa combinação envolve 4 valores constantes e outro que possui 4 valores variáveis, que correspondem aos endereços IP de destino e origem, e portas de destino e origem.
O cálculo entre esses valores pode ser realizado da seguinte maneira:
Figura 25. Função Hash
Fonte: elaborado pelo autor.
Onde Valor_do_Hash é uma variável que recebe o hash calculado, quando seu valor é atualizado no passo (2) da equação. As letras gregas α, β, γ e θ, são as constantes. Os valores ipo, prto, ipd e prtd correspondem,
respectivamente ao endereço IP de origem, porta de origem, endereço IP de destino e porta de destino. O valor quant_servidores representa a quantidade total dos servidores de aplicação. A função resto(), calcula o resto da divisão passada por parâmetro e atualiza a variável Valor_do_Hash que tem o resultado limitado entre 0 e quant_servidores - 1 . As equações (1) e (2) fazem parte dos cálculos internos da função de hash.
Assim, para a primeira etapa de escolha de um servidor s, pertencente a uma conexão c para um fluxo de ida, considere uma função de hash chamada h inserida nos dois balanceadores. A invocação de h em um deles, pode ser feita da seguinte forma: h(ipo, prto, ipd, prtd). A função h retorna o
resultado de Valor_do_Hash, usado na escolha do servidor s e, desse modo, efetua o balanceamento.
A segunda etapa capaz de fazer com que o outro balanceador selecione o mesmo servidor s, pertencente a conexão c no fluxo de volta, deve invocar h da seguinte maneira: h(ipd, prtd, ipo, prto). A troca de parâmetros em h é
necessária, devido aos valores de IP e Porta de origem e destino serem invertidos no fluxo de retorno. Isso faz com que os balanceadores, selecionem o mesmo servidor, já que utilizam a mesma função h.
4.2.2
Funcionamento
Suponha que um cliente da rede interna abre uma conexão TCP com um servidor da internet. De forma geral, quando o primeiro pacote IP é recebido no balanceador interno, este invoca a função hash para calcular um valor associado a um endereço MAC de destino. Este endereço pertence a um dos servidores de aplicação. Assim, o balanceador interno encaminha o pacote para o servidor de destino que redireciona para o balanceador externo e este roteia o pacote para a internet. A resposta do servidor para o cliente acontece de forma análoga, porém seguindo o caminho inverso.
Para um fluxo ainda mais detalhado, considere a Figura 26. Ela especifica mais a ideia do fluxo e da arquitetura proposta.
Figura 26. Funcionamento da arquitetura proposta
Fonte: elaborado pelo autor
Neste modelo, cada balanceador de carga possui uma tabela que vincula uma chave a um valor. A chave corresponde a um identificador e o valor a um endereço MAC. Toda vez que um pacote passa por algum balanceador (b0 ou b1), dependendo do protocolo escolhido para fazer o balanceamento, é calculado o identificador vinculado ao endereço MAC de destino de algum dos servidores de aplicação (se a interface de saída corresponder à mesma rede conectada entre o balanceador e os servidores). O cálculo é realizado por meio da função hash que recebe por parâmetro os endereços de origem e destino referentes ao IP; e os valores das Portas, também de origem e destino. Sejam as Tabelas 3 e 4 responsáveis por armazenar os endereços MAC e identificadores cadastrados para os três servidores aplicação, temos
Tabela 3. Representa, em b1, a relação entre identificador e endereços MAC
Identificador Endereço MAC de destino das aplicações
1 MAC4
2 MAC6
3 MAC8
Fonte: elaborado pelo autor
Tabela 4. Representa, em b0, a relação entre identificador e endereços MAC
Identificador Endereço MAC de destino das aplicações
1 MAC3
2 MAC5
3 MAC7
Fonte: elaborado pelo autor
Suponha que a função a hash executada em b1 gere o valor 1 para um
pacote enviado pelo
cliente. Essa função hash, que é cadastrada no hook POSTROUTING do Netfilter, e é executada após a decisão de roteamento, utiliza como parâmetros: IP origem, Porta origem, IP destino, Porta destino. Uma vez que o identificador 1 (Tabela 3) está associado ao endereço MAC4, o endereço MAC de destino do quadro que será encaminhado é alterado para esse valor. Depois, segue-se o fluxo discutido anteriormente.
Para que b0 garanta que a resposta do servidor da internet volte pelo mesmo link, o qual desencadeou todo o processo de transmissão (conexão), é preciso que a função hash gere o mesmo valor. Intuitivamente poderíamos invocar a função com a seguinte ordem de parâmetros: IP origem, Porta origem,
IP destino, Porta destino. Porém, mais uma vez, devemos lembrar que no fluxo
de retorno o IP de origem é o endereço IP do servidor, não o do cliente. Isso já abriria a possibilidade de gerar um valor diferente. Dessa maneira, a ordem correta, no fluxo de retorno, para se invocar a função é, obviamente, hash(IP
destino, Porta destino, IP origem, Porta origem). Neste caso, o endereço MAC
5 Estudo de Caso
Este capítulo apresenta um estudo de caso utilizando o protocolo TCP. Discute sobre a topologia construída para a solução proposta e seu funcionamento quando há o encaminhamento de tráfego TCP.
5.1 Topologia
Para entendermos melhor os cenários apresentados nas seções seguintes, consideremos os balanceadores de carga como b0 e b1; as aplicações como os firewalls fw0, fw1 e fw2; o cliente c1 e o servidor serv1; e os switchs como s0, s1, s2 e s3. O cliente c1 pode ser entendido como uma abstração para uma subrede da rede interna e o servidor serv1, para a internet (vide Figura 27). Os módulos do kernel estão inseridos nos kernels de b0 e b1. Tais módulos serão responsáveis por analisar os pacotes e roteá-los (efetuar o balanceamento) para os firewalls de acordo com o cálculo de um
hash envolvendo IP e Porta, de origem e destino. O hash servirá para a escolha
do firewall e efetivar a distribuição uniforme da carga de dados, cada valor calculado é associado a um endereço MAC de algum firewall. Estes endereços estão armazenados em uma tabela em cada módulo nos balanceadores de carga.
Os casos de uso (no âmbito do protocolo IPv4) focam nos protocolos TCP,
UDP e o Protocolo de Mensagens de Controle de Internet – do inglês Internet Control Message Protocol (ICMP). Para ambos, é feito o cálculo do hash,
5.2 Encaminhamento de tráfego TCP
Considere uma situação onde um cliente quer baixar um arquivo da internet. A Figura 27 ilustra isso.
Figura 27. Arquitetura proposta do trabalho
Fonte: elaborado pelo autor
Seja o c1 este cliente, para realizar esta tarefa ele deve se comunicar com o roteador denominado aqui como b1 que por sua vez se comunica com um dos firewalls (fw0, fw1 e fw2) através do s2. Por meio do s1, os firewalls se comunicam com o roteador b0 que possui conexão com a internet. Este faz a requisição do arquivo para o próximo nó da rede, depois a informação é repassada para o c1, como resposta à requisição. O módulo de kernel inserido em b1 seleciona, através do algoritmo de balanceamento de carga, o firewall que vai receber, processar e encaminhar o pacote para b0, por meio da tabela de rotas. O mesmo acontece em b0. Tanto em b1 quanto em b0 a função (pertencente ao módulo) responsável por esse processo é registrada no hook POSTROUTING do Netfilter, portanto, após às decisões de roteamento.
Como foi dito, as aplicações devem possuir o mesmo IP, porém com os endereços MAC distintos. Isso pode ser visto na Figura 27. Essa necessidade serve para que, depois de tomada a decisão de roteamento, o pacote não seja descartado, pois a rota default (perceba que como a conexão está entre c1 e serv1, a rota não é direta, a partir de algum dos balanceadores), registrada nos balanceadores b0 e b1, aponta para os endereços IP 172.16.1.20 e 172.16.2.20, respectivamente (pertencente ao fw0). Dessa forma (e nessa etapa), o trabalho de seleção se concentra apenas em substituir no cabeçalho
Ethernet, o campo MAC de destino, nos quadros de saída. Isso nos poupa da
preocupação em verificar o checksum5, já que a alteração feita nos campos
dos endereços MAC não afeta a sanidade do pacote.
A consequência dessa abordagem é que precisa-se desabilitar o protocolo ARP nos balanceadores, já que os firewalls possuem o mesmo IP.
Ao enviar o pacote (através da função dev_queue_xmit()), a função pertencente ao módulo, registrada no POSTROUTING, tem que assumir a responsabilidade das manipulações realizadas no pacote. Isso pode ser feito retornando a macro NF_STOLEN para o framework Netfilter. A
dev_queue_xmit() recebe como parâmetro o ponteiro que representa a
estrutura sk_buff.
5 “A checksum is a small-sized datum derived from a block of digital data for the purpose of
6 Experimentos
Este capítulo apresentará os experimentos realizados na tentativa validar a hipótese: o balanceamento de carga pode implicar em um aumento de desempenho nos nós do cluster, diminuindo o nível de sobrecarga a que são submetidos pelo tráfego de rede e das próprias instruções do sistema operacional. As quatro seções subsequentes apresentam o cenário em que foram executados os testes, a forma como os testes foram estruturados, as análises dos resultados obtidos e os trabalhos futuros.
6.1 Cenário do experimento
Os testes foram executados em um ambiente construído pelo software
VMware. A topologia foi baseada na da Figura 27, discutida na seção 5.2. Todo
o esquema de integração da rede virtual foi criado usando as estruturas internas do VMware.
As sete máquinas possuem a seguinte configuração: Sistema Operacional Linux, distribuição Ubuntu, versão 4.4.0-87-generic do kernel, com Multiprocessamento Simétrico – do inglês Symmetric Multi-Processing (SMP), arquitetura x86_64 GNU/Linux, duas placas de rede 10Gbps de velocidade com controlador ethernet VMware VMXNET3 Ethernet Controller
(rev 01), 2GB de memória RAM com 1,7GB disponíveis e 1GB de memória swap, HD com capacidade de memória de 20GB e 1 processador Intel(R) Xeon(R) CPU X5650 com 2.67GHz de frequência, 2 núcleos e família 6.