Cluster Balanceamento Carga

1 Cluster de Balanceamento de Carga Luiz Arthur

A Internet esta se tornado mais e mais importante a cada dia, com isto o trafego
de dados na Internet tem aumentado drásticamente (~100% ao ano).

A carga de trabalho dos servidores na Internet tem de aumentar na mesma
proporção caso contrário os usuário da Internet ficariam insatisfeitos com tais
serviços, o que poderia trazer prejuízos para várias empresas.

Para tentar resolver este problema existem basicamente duas soluções:

● Uma é à evolução dos servidores, sendo que, a medida que cresce a
demanda pelo servidor, o mesmo deve “crescer” (evoluir tecnologicamente)
na mesma proporção em termos de hardware, fornecendo alta performance
para os usuários, porém este crescimento de hardware é muito complexo e
pior pode ainda tornar-se impossível.

● Outra, solução é a medida que for crescendo a demanda por serviços,
usarmos a técnica de cluster, fazendo a adição de mais servidores, incluindo
mais e mais máquinas para prover um dado serviço, tornando o sistema
escalável e menos suscetível a falhas.


Um Cluster de Balanceamento de Carga é um conjunto de máquinas (duas
ou mais) nas quais estão sendo executadas aplicações requerida por um número
muito grande pessoas.

Um bom Cluster de Balanceamento de Carga deve ter a capacidade de receber os
pedidos de requisição de serviço de vários clientes e distribuir (balancear a
carga de trabalho) tais serviços às máquinas que constituem o cluster de forma
que nenhuma máquina fique sobrecarregada e/ou ociosa.

Assim, este tipo de Cluster distribui o tráfego entrante ou requisições de recursos
provenientes para os nós (máquinas que compõe o cluster) que executam os
mesmos programa entre as máquinas que compõem o cluster.

O balanceamento de carga entre servidores faz parte de uma solução
abrangente em uma explosiva e crescente utilização da rede e da Internet.
Provendo um aumento na capacidade da rede, melhorando a performance de
sistemas da Internet.

Um consistente balanceamento de carga mostra-se hoje, como parte integrante
de todo o projeto de Web Hosting e comércio eletrônico. Mas não podemos ficar
com a idéia presa de que isso é só para provedores de Internet, devemos
aproveitar as características desses clusters em empresas comuns e desse
modo usar a tecnologia para atendermos os clientes internos das empresas.


Os sistemas de Cluster baseado em Balanceamento de Carga integram/agrupam
as máquinas que compõem o cluster, de forma que as requisições provenientes
dos clientes sejam distribuídas de maneira equilibrada entre os tais nós.

Os sistemas baseados em cluster de balanceamento de carga não trabalham
junto em um único processo, mas redirecionando as requisições dos
clientes de forma independente assim que chegam baseados em um
escalonador e um algoritmo próprio.

Este tipo de cluster é especialmente utilizado em serviços de comércio eletrônico
e provedores de Internet que necessitam de resolver diferenças de carga
provenientes de múltiplas requisições de entrada em tempo real.

Quando não se faz balanceamento de carga entre servidores que possuem a
mesma capacidade de resposta a um cliente, começamos a ter problemas, pois
um ou mais servidores podem responder a requisição feita e a comunicação fica
prejudicada. Por isso devemos colocar um elemento que fará o
balanceamento entre os servidores, os usuários e configurá-lo para isso,
entretanto podemos colocar múltiplos servidores de um lado que, para os
clientes, eles parecerão ser somente um endereço.


Existem alguns pontos críticos que devem ser observados na implementação de
um bom cluster de balanceamento de carga, são os que seguem:

● O algoritmo usado para o balanceamento de carga, levando-se em
consideração como é feito o balanceamento entre os servidores e quando um
cliente fizer uma requisição para o endereço virtual, todo o processo de escolha
do servidor e resposta do servidor deve ocorrer de modo transparente e
imperceptível para o usuário como se não existisse o balanceamento.

●Utilizar métodos para checar se os servidores/nós que compõem o cluster
estão ativos e funcionando. Isto é vital para que a comunicação não seja
redirecionada para um servidor que acabou de ter uma falha.

●Balanceamento de carga é mais que um simples redirecionamento do tráfego
dos clientes para outros servidores. Para implementação correta, o equipamento
que fará o balanceamento precisa ter características como verificação
permanente da comunicação, checagem dos servidores e redundância.

Todos esses ítens são necessários para que suporte à escalabilidade do volume de
tráfego das redes sem vir a se tornar um gargalo ou um ponto único de falha.


Algoritmos de Balanceamento de Carga

Existem algoritmos que ajudam a prover balanceamento de carga, eles
basicamente são técnicas especificas de distribuição de carga dentre os
nós que constituem o cluster. Cada algoritmo tem a sua peculiaridade, tal
como, a forma que estes fazer a distribuição de tarefa, qual o critério de atribuir
ou não o serviço a um nó do cluster que já tem vários serviços sendo executado,
etc. Veremos a seguir alguns algoritmos que ajudam na tarefa de fazer um bom
balanceamento de carga, é claro que cada algoritmo se aplica melhor em
determinadas situações.

Round Robin

O Round Robin funciona da seguinte forma. Uma pequena unidade de tempo,
denominada timeslice ou quantum, é definida. Todos os processos são
armazenados em uma fila circular. O escalonador da CPU percorre a fila,
alocando a CPU para cada processo durante um quantum (previamente definido).
Mais precisamente, o escalonador retira o primeiro processo da fila e procede à
sua execução. Se o processo não termina após um quantum, ocorre uma
preempção, e o processo é inserido no fim da fila. Se o processo termina antes de
um quantum, a CPU é liberada para a execução de novos processos. Em ambos os
casos, após a liberação da CPU, um novo processo é escolhido na fila. Novos
processos são inseridos no fim da fila. Quando um processo é retirado da fila para
a CPU, ocorre uma troca de contexto, o que resulta em um tempo adicional na
execução do processo.


Round Robin Ponderado

Este algoritmo é igual ao anterior, porém atribui a cada servidor um peso. Esse
peso é um inteiro que indica a capacidade de processamento do nó, de maneira
que o algoritmo Round Robin se modificará para que os nós com maior
capacidade de processamento recebam mais requisições (ao menos mais
que os demais de menor capacidade de processamento).

Semelhante a uma política FIFO (First In Fisrt Out - o primeiro que entra é o
primeiro que sai), porém com pesos. Neste caso o servidor vai entrar na fila
proporcionalmente ao seu peso. Assim, se as máquinas m1, m2, m3 e m4 tiverem
o mesmo poder computacional e a máquina m5 tiver o dobro, seria uma boa idéia
colocar peso 1 para as máquinas m1, m2, m3 e m4 e peso 2 para a máquina m5.
Um possível escalonamento de tarefas, neste caso seria m1, m2, m5, m3, m4, m5,
m1, m2, m5, m3, m4, m5.

Least Connection

Esse algoritmo re-orienta as conexões para o servidor que está com o menor
número de conexões ativas. Porém, número de conexões ativas não é
diretamente proporcional à utilização dos recursos computacionais, no entanto
este algoritmo é uma aproximação desta situação, uma vez que a
heterogeneidade das conexões tende a desaparecer quando o número de
requisições cresce. Este algoritmo de distribuição consulta os nós a cada
momento para ver quantas conexões abertas cada um tem com os clientes, e
envia a requisição ao servidor que possui menos conexões no momento.


Weighted Least Connection

Similar ao Least Connection, só que com pesos. O número de conexões ativas
é ponderadas pelo peso antes de se decidir para qual servidor/nó a requisição vai
ser encaminhada. Por exemplo, em um ambiente com as máquinas m1 e m2 com
peso 1 e a máquina m3 com peso 2. Se o número de requisições ativas for,
respectivamente 50, 60 e 70, o número de conexões efetivas é igual a
Número_de_conexões/Peso, ou seja, 50, 60 e 35. A próxima requisição vai para a
máquina m3 pois esta máquina apresenta a menor relação número de requisições
por peso de processamento.

Locality Based Least Connection

Este algoritmo atribui os trabalhos com o mesmo endereço de origem sempre
ao mesmo servidor a menos que ele esteja sobrecarregado ou indisponível no
momento. No caso de sobrecarga o trabalho é atribuído a outro servidor com
menos conexões.

Locality Based Least Connection with Replication

Atribui o trabalho ao servidor que tem o menor número de conexões dentre o
conjunto que está lidando com certo endereço de destino. Caso todos estejam
superlotados, um nó com menos trabalhos é escolhido e adicionado ao conjunto.
Se o servidor não foi modificado em um determinado período de tempo o nó mais
ocupado é removido do conjunto para evitar um alto grau de replicação.


Mas como distribuir carga entre servidores de rede?

Existem várias formas de montar um cluster e distribuir a carga entre os nós.

O método mais simples é mediante um DNS Round-Robin. Para se obter um
balanceamento de carga com DNS faz-se necessário definir várias entradas tipo A
no arquivo de configuração do domínio em questão.

@ IN SOA dns1.exemplo.com.br. email.exemplo.com.br. (
01 ; serial
03H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum

IN NS dns1
IN NS dns2
IN MX 10 mail

dns1 IN A 1.2.3.41
dns2 IN A 1.2.3.42
mail IN A 1.2.3.50
www IN A 1.2.3.1 # Servidor 1
IN A 1.2.3.2 # Servidor 2
ftp IN A 1.2.3.1 # Servidor 1


Para cada requisição de resolução de nomes para www.exemplo.com.br ou
ftp.exemplo.com.br, o servidor em princípio devolverá um IP distinto. Porém,
essa facilidade aparente encontra um inconveniente, o cache de DNS.

Os servidores DNS possuem cache com as últimas requisições realizadas visando
agilizar o processo de resolução. Isso pode ser um problema porque o
balanceamento não seria feito de forma justa para todos os servidores WWW
ou FTP.

Uma "solução" que apenas ameniza o problema é a diminuição do TTL (time to
live), que é o tempo de vida de um registro em uma cache de DNS em segundos.
Então com um TTL baixo faz-se com que os outros servidores DNS não
mantenham por muito tempo o registro em seus caches.

Este método encontra também o problema de não levar em conta a carga
real de cada nó, sendo possível que todas as requisições sejam passadas sempre
para o mesmo nó o que acabaria por saturá-lo, mesmo que os demais estivessem
servindo requisições triviais.

Uma solução melhor estará em utilizar um balanceador de carga para
distribuir as conexões entre os servidores. Com esta solução pode-se aumentar a
noção de "unidade" do cluster, pois para o usuário existirá um único
endereço IP para o qual serão dirigidas todas as requisições.


A granularidade da distribuição pode se dar por conexão (cada requisição de
cliente se dirige ao nó que melhor tenha condição de atender) ou por sessões
(armazena-se em uma tabela qual nó recebe a conexão do cliente e as envia ao
mesmo nó enquanto permanecer ativa a sessão).

Quando algum nó falha, é mais fácil mascarar o erro, tendo nesse caso o
balanceador de carga mecanismos necessários para detectar a falha do nó e
eliminá-lo da sua lista, de forma a não encaminhar nenhuma requisição. Por
esse mesmo motivo, a administração do cluster se torna simplificada, pode-se
retirar a qualquer momento qualquer dos nós para realizar tarefas de
manutenção sem que sejam provocadas interrupções de serviços.

O balanceamento de carga pode ser feito em dois níveis: a nível de conexão e
IP e a nível de protocolo.

Para o balanceamento de carga em nível de protocolo o balanceador seria uma
espécie de proxy, o qual seria programando para receber conexões em uma
determinada porta, podendo inspecionar o pacote para ver se trata do protocolo
correto ou extrair algum tipo de dado do protocolo, podendo ainda filtrar
requisições incorretas e encaminhar as conexões para um dos nós do cluster. O
problema com essa aproximação com proxy é a necessidade de se analisar o
protocolo em todas a conexões entrantes, o programa balanceador é muito
complexo e poderia causar um gargalo na entrada do cluster (estima-se que o
número de nós para servir sem problemas de congestionamento seria em torno
de 4 a 6).


O balanceamento a nível de conexão IP, é muito mais eficiente já que o
processo a ser realizado é muito mais simples. Quando chega uma requisição ao
balanceador ele somente aceita a conexão e encaminha para um dos nós. Nesse
nível, o número de nós atrás do balanceador pode oscilar entre 25 e 100
observando-se é claro a potência dos equipamentos.


Linux Virtual Server

Linux Virtual Server ou simplesmente LVS uma solução de balanceamento de
carga baseado em cluster, o LVS é executado no sistema operacional Linux, e
prove alta disponibilidade e escalabilidade a servidores de redes.

O LVS é uma avançada solução de balanceamento de carga que pode ser
utilizada para fornece serviços críticos de rede, que necessitam de um alto grau
de disponibilidade e escalabilidade, tal como, serviços da web, mail, mídia, VoIP,
etc.

A arquitetura do cluster de balanceamento de carga do LVS é completamente
transparente para usuários finais, sendo que os usuários interagem com o
computador que faz o papel de servidor virtual, este servidor virtual é
responsável por receber os pedidos dos usuários e repassar para algum servidor
real (que compõe o cluster).

Os servidores reais e o servidor LVS (responsável pelo balanceamento de carga)
podem estar interconectados por uma rede local (LAN) ou por uma rede
geograficamente distribuída (WAN, Internet, etc).


O servidor de balanceamento de carga LVS pode despachar os pedidos de vários
clientes para diferentes servidores reais de forma que pareça que o servidor
virtual (que tem um endereço IP fixo) pareça estar fazendo inúmeros serviços em
paralelo ou simultaneamente, mas no entanto quem está atendendo este pedido
são os servidores reais do cluster.

O LVS é escalavel e transparente aos erros dos servidores reais, ou seja o LVS
torna possível retirar ou acrescentar servidores reais no cluster, sem que os
clientes sintam ou saibam que isto está ocorrendo. Isto possibilita também que
caso haja alguma falha em um servidor real, este seja retirado para reparo, sem
que os clientes sintam tal falha, e assim que o servidor real for reparado este
pode ser adicionado ao cluster, isto fornece disponibilidade de serviços ao
cluster.

Cliente

LAN/WAN

Internet/
Intranet Servidores
Servidor de Reais
Balanceamento
de Carga


Então um LVS é um grupo de servidores com um computador chamado de
direcionador que faz com que o Cluster LVS pareça para o mundo de fora (um
servidor na Internet, por exemplo) como se fosse apenas uma única máquina, mas
na verdade são um conjunto que computadores.

O LVS pode oferecer mais serviços, com maior capacidade e desempenho, ou
serviços redundantes em relação aos serviços disponíveis em servidores únicos. O
serviço é tratado aqui como uma conexão para uma porta de rede simples,
como por exemplo: telnet, HTTP, NFS, SSH, SMTP, POP, banco de dados, etc.

No LVS a semântica padrão do cliente-servidor continua preservada. Cada cliente
pensa que está diretamente conectado ao servidor real. Cada servidor real pensa
que está conectado diretamente ao cliente. Ou seja, nem o cliente nem o servidor
sabem que as conexões sofrem a intervenção do computador direcionador.

Um LVS não é um beowulf, já que um beowulf é um grupo de máquinas onde
cada uma calcula uma pequena porção de um problema grande (distribuindo
tarefas/processos). No LVS, o servidor real não coopera (como no beowulf), os
servidores reais não sabe sequer da existência de outros servidores reais no LVS.
Tudo que os servidores reais sabem é que eles recebem conexões de clientes.

Existe nessa configuração um ponto de falha que é o próprio balanceador de
carga. Mas é possível utilizar mais de um equipamento para fazer o
balanceamento de carga (mais de um nó direcionador), dessa forma aumentando
o grau de disponibilidade.


O computador direcionador de carga pode utilizar um abordagem de
escalonamento diversificada, na qual o software pode decidir de maneira distinta
como distribuir a carga entre os servidores reais.

Existem diferentes formas de configuração do algoritmo de escalonamento. Os
modos de envio de requisições são: LVS-NAT, LVS-DR e LVS-Tun.

Modos de Balancear a Carga com LVS:

Balanceamento por NAT (VS-NAT)

Este tipo de balanceamento aproveita a possibilidade do kernel do Linux
funcionar como um roteador com NAT (Network Address Translation). A única
rota padrão do cluster será o computador balanceador. Então quando um pacote
externo chega, o nó balanceador modificará sua rota para que chegue a um dos
nós (servidores reais) do cluster e, a de origem para que seja devolvido a ele e
reenviado ao cliente que iniciou a conexão.

Então o LVS-NAT funciona da seguinte forma:

1. O Cliente faz uma requisição de serviço ao balanceador de carga executando
o LVS;

2. O Balanceador decide à que nó vai enviar a requisição, reescreve o cabeçalho
do datagrama TCP/IP e envia ao nó correspondente;


3. O nó recebe a requisição de serviço, processa, gera a resposta e envia ao
balanceador de carga;

4. O balanceador reescreve novamente o cabeçalho TCP/IP do datagrama e envia
de volta ao cliente como se ele próprio tivesse gerado a resposta.

A grande vantagem do VS-NAT reside no fato de que os nós que compõem o
cluster poderiam executar qualquer sistema operacional que suporte TCP/IP,
sendo que toda manipulação de endereços e gestão do cluster é feito pelo nó
balanceador de carga.

Entretanto este método faz o balanceamento em nível de protocolo (neste caso no
protocolo IP) o que ocasiona uma grande desvantagem, que é a de tornar o nó
balanceador um grande gargalo, pois este nó tem uma tarefa árdua que é a de
receber todos os pacotes dos clientes ler os pacotes, alterar estes pacotes para
enviar para os servidores reais, ler os pacotes dos servidores reais e alterá-los
para reenviar para os clientes, ou seja, todo o serviço de comunicação entre
clientes e servidores fica a cargo do nó direcionador, tornando este um ponto de
falha além de um gargalo.


IP. 10.0.0.2
IP. 200.0.0.126
IP. 10.0.0.1
Servidores
Internet/ Reais
Intranet

Cliente
Nó direcionador LVS IP. 10.0.0.3
IP. 200.0.0.1

Figura do esquema físico do LVS-NAT

Balanceamento por Encapsulamento IP (VS-Tun)

Este método permite escalar um número maior de nós, 100 ou mais, porém todos
deverão ser capazes de trabalhar com encapsulamento IP (IP Tunneling).

O encapsulamento IP consiste em se fazer trafegar um datagrama TCP/IP, com
seus endereços de origem e destino, dentro de um outro datagrama com origem e
destino distintos e, quando esse datagrama chegar ao seu destino, seja
desencapsulado o datagrama original para ser reroteado a partir dali.


O VS-Tun é uma forma de se utilizar um roteamento alternativo, por exemplo
uma rede A para uma rede B passando por uma rede C. O problema deste método
é que nem todos os sistemas operacionais suportam o encapsulamento, sendo
normalmente este método exclusivo do Linux.

Com a utilização deste método de balanceamento, todos os nós do cluster
precisam ter configurada em alguma interface um endereço IP publico se os nós
estão distribuídos em uma WAN. O ponto de entrada do cluster é o balanceador
de carga, porém uma vez que o tráfego chega a um dos nós, este roteará as
respostas diretamente ao cliente sem passar pelo nó balanceador.

Servidor responde diretamente ao Cliente

Túnel IP

Servidores
Internet/ Reais
Intranet
Cliente Túnel IP
Nó balanceador


Figura do esquema físico do LVS-TUN


No método VS-Tun todos os nós do cluster precisam ter IPs públicos, podendo se
tornar um ponto negativo. Entretanto têm-se uma grande vantagem, os nós
podem estas dispersos em uma área muito ampla. Ao separarmos
geograficamente os servidores agregamos mais um ponto que é a alta
disponibilidade, visto, que é muito mais difícil a ocorrência de problemas em
todas as localizações dos nós.

Balanceamento por Roteamento Direto (VS-DR)

Este método requer que todos os nós do cluster tenham um IP público
compartilhados virtualmente com o balanceador de carga e, que se encontrem na
mesma rede física (mesmo segmento) do balanceador de carga.

A carga imposta ao balanceador de carga será menor, visto que não será
necessário distribuir os pacotes (como no caso do NAT) e nem encapsular (no
caso do Encapsulamento IP).

O balanceador nesse caso não será um gargalo para o tráfego. O trafego
unicamente passará pelo balanceador e será roteado diretamente ao nó e, este
roteará a resposta diretamente ao cliente. O balanceador de carga, como sempre
será o ponto de entrada para o cluster.

Entretanto as interfaces dos nós deverão estar configuradas para não responder
a comandos ARP para não interferir com outros protocolos (todos os
equipamentos respondem pelo mesmo endereço IP com MACs distintos).


Quando uma requisição chega ao balanceador, este decide para qual nó será
enviada tal requisição e assim envia o pacote a nível de enlace para o endereço
MAC do nó eleito.

Quando o pacote chega ao nó com a MAC destino, tal pacote é analisado em nível
de rede (TCP/IP), como o nó também tem o endereço IP público do cluster ele
aceita o pacote, processa e envia a resposta diretamente ao cliente.


Segmento físico
Servidores
Internet/ Reais
Intranet
Cliente
Nó balanceador


Figura do esquema físico do LVS-DR


Os problemas desse método são:

1. Nem todos os sistemas operacionais permitem configurar um IP ou um
dispositivo de modo a não responder a comandos ARP;

2. Todos os nós devem estar no mesmo segmento físico para poder encaminhar
os datagramas a nível de enlace para os endereços MAC, perdendo assim a
possibilidade de dispersar geograficamente o cluster como no método anterior.

Após apresentar os métodos de se fazer o balanceamento, os principais atributos
de cada um são:

➢VS-DR padrão, possui alto desempenho e pode ser configurado na maioria dos
sistemas operacionais. Os servidores Reais precisam estar na mesma rede do nós
direcionador (o servidor real e o direcionador podem requisitar o ARP um do
outro);

➢VS-NAT, menor desempenho, alta latência. O Servidor real só precisa da pilha
TCP/IP (exemplo, qualquer sistema operacional e até mesmo uma impressora da
rede) funciona para múltiplas instâncias de serviços (exemplo, múltiplas cópias
de um serviço rodando em portas diferentes).

➢VS-Tun, Servidores Reais apenas em Linux. Possui o mesmo desempenho do VS-
DR. Necessário se o servidor real estiver em uma rede diferente do nó
direcionador (exemplo, na Internet).


Instalando e configurando o LVS no Slackware Linux

Todas as edições do LVS estão disponíveis em www.linuxvirtualserver.org.

Geralmente cada edição do LVS é feita de duas maneiras.

● Um pacote tar o qual você pode usar para compilar o LVS tanto fora como
dentro dos diretórios do Kernel.

● Ou, um patch para ser usando somente para compilar o LVS dentro da árvore
de diretórios do Kernel.

A não ser que tenha-se uma bom motivo para usar um Kernel antigo, use o 2.4.23
(ou superior) cujo código do LVS já está incluso. Desta forma na maioria das
implementações de um Cluster LVS não faz necessário adicionar nem configurar
nenhum parâmetro diretamente no Kernel.

Fora possíveis configurações do Kernel, um utilitário requerido é o ipvsadm em
http://www.linuxvirtualserver.org/software/ipvs.html. Diferentes versões de
Kernel (2.2.x, 2.4.x, 2.6.x) requerem diferentes versões do ipvsadm. Se você
simplesmente obter a última versão do ipvsadm, este não funcionará com os
Kernel's 2.4.x, então esteja certo de ter pego a versão correta do ipvsadm para
série do seu Kernel.


Configurando o LVS usando o encaminhamento VS-NAT

O encaminhamento VS-NAT foi o primeiro método criado para fazer um LVS.
Para os kernels 2.2.x no nó direcionador, o VS-NAT fornece pouco desempenho
se comparado com os métodos VS-DR e VS-Tun, devido ao demasiado uso da CPU
em reescrever as regras dos pacotes, mas mesmo assim o VS-NAT ainda é útil em
várias circunstâncias. No Kernel 2.4.x a performance do LVS-NAT teve melhoras
de desempenho.

Cliente Servidor Real
IP. 192.168.2.254 IP. 192.168.1.1124
HUB

Servidores
Reais

Nó Direcionador
IP. 192.168.2.11024 (eth0:110) Servidor Real
IP. 192.168.1.924 (eth0) IP. 192.168.1.1224

O alias da placa de rede (eth0:110) no nó direcionador é configurado pelo script de
configuração (apresentado a seguir), então, não adicione este IP. Não deve haver nenhuma
rota padrão, e todas as interfaces na rede 192.168.1.0/24 devem ser capazes de pingar umas
as outras. O Cliente não deve ser capaz de acessar nada até que o IP alias esteja habilitado no
Direcionador. Para o teste, não tenha nenhum outro IP nos computadores.


No nó direcionador, iremos criar um script (vamos chamá-lo de rc.diretor) que
habilitará a máquina para fazer o balanceamento de carga do cluster (ver script
no slide a seguir).

Basicamente o script executa as seguintes tarefas:

1 – Habilita o nó direcionador para que este funcione como um roteador/gateway
(forward) entre os servidores reais e os clientes. Desabilita, pedidos ICMP entre
as redes internas e externas.

2- Configura um IP alias (virtual) para que o nó direcionador se comunique tanto
com a rede externa. Neste caso estamos configurando uma interface virtual por
que estamos utilizando apenas uma única placa de rede, em caso de duas placas
de rede, uma para a rede interna e outra para a rede externa, iriamos configurar
a placa de rede com comunicação a rede externa.

3 – Finalmente no passo três o script habilita através do ipvsadm o uso do telnet
como serviço a ser balanceado entre os servidores reais (192.168.1.11 e
192.168.1.12), ou seja, quando o cliente externo tentar utilizar o telnet no
endereço 192.168.2.110 quem responderá não será o nó direcionador mas sim
um dos servidores reais.

#!/bin/sh
#Configurando o forward no vs-nat (1 on, 0 off). 1
cat /proc/sys/net/ipv4/ip_forward
echo "1" >/proc/sys/net/ipv4/ip_forward
#o nó diretor é o gateway para os servidores reais
#turn OFF icmp redirects (1 on, 0 off)
echo "0" >/proc/sys/net/ipv4/conf/all/send_redirects
cat /proc/sys/net/ipv4/conf/all/send_redirects
echo "0" >/proc/sys/net/ipv4/conf/default/send_redirects
cat /proc/sys/net/ipv4/conf/default/send_redirects
echo "0" >/proc/sys/net/ipv4/conf/eth0/send_redirects
cat /proc/sys/net/ipv4/conf/eth0/send_redirects
#Configurando o IP alias do nó direcionador 2
/sbin/ifconfig eth0:110 192.168.2.110 broadcast 192.168.2.255 netmask 255.255.255.0
#Configurando o nó diretor como gateway
/sbin/route add default gw 192.168.2.254 netmask 0.0.0.0 metric 1
#Limpando a tabela ipvsadm tables
/sbin/ipvsadm -C
#Instalando serviços no LVS com ipvsadm 3
#Adicionando o telnet com o escalonador round robing
/sbin/ipvsadm -A -t 192.168.2.110:telnet -s rr
#Redirecionando telnet para 192.168.1.11 usando VS-NAT (-m), com peso=1
/sbin/ipvsadm -a -t 192.168.2.110:telnet -r 192.168.1.11:telnet -m -w 1
#Checando se o servidor real está ativo!
ping -c 1 192.168.1.11
#Redirecionando telnet para 192168.1.12 usando LVS-NAT, com peso = 1
/sbin/ipvsadm -a -t 192.168.2.110:telnet -r 192.168.1.12:telnet -m -w 1
#Checando se o servidor real está ativo!
ping -c 1 192.168.1.12
#Lista a tabela de serviços do LVS.
/sbin/ipvsadm


Os servidores reais também precisam executar um pequeno script para iniciarem
suas funções. Observe abaixo o script (iremos chamá-lo de rc.lvsreal) dos
servidores reais:

#!/bin/sh
#Script dos Servidores Reais
#configurando como gateway padrão o nó direcionador
/sbin/route add default gw 192.168.1.9
#Mostrando a rota padrão
/bin/netstat -rn
#Verificando se o gateway está ativo
ping -c 1 192.168.1.9
#Checando o IP alias
ping -c 1 192.168.2.110

#Desabilita a capacidade dos servidores reais de
#roteamento.
echo "0" >/proc/sys/net/ipv4/ip_forward
cat /proc/sys/net/ipv4/ip_forward

Estás configurações são básicas e podem ser configuradas sem script, a parte
fundamental deste é a adição do nó direcionador como gateway padrão.

Testando o funcionamento do VS-NAT

Para saber se o Cluster de Balanceamanto de Carga LVS está funcionando
corretamente, podemos ir no nó direcionador, executar o comando ipvsadm. Tal,
comando apresentará a seguinte saída:

# ipvsadm
IP Virtual Server version 0.9.14 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.2.110:telnet rr
-> 192.168.1.11:telnet Masq 1 0 0
-> 192.168.1.12:telnet Masq 1 0 0

Agora, faça um telnet de um cliente para 192.168.2.110. Você terá o prompt de
login de um dos servidores reais (perceba qual). Então no nó direcionador,
execute o ipvsadm novamente:

# ipvsadm
-> 192.168.1.11:telnet Masq 1 1 0
-> 192.168.1.12:telnet Masq 1 0 0

Perceba que o contador do ActiveConn foi incrementado.


Abra outra janela no cliente e faça um telnet para 192.168.2.110. Você receberá
o prompt de login do outro servidor real. Agora execute novamente o ipvsadm.

# ipvsadm
-> 192.168.1.11:telnet Masq 1 1 0
-> 192.168.1.12:telnet Masq 1 1 0

Agora existem duas conexões ativas. Você está então conectado nos servidores
reais por meio do telnet.

Configurando o VS-NAT para o serviço HTTP

Nos slides anteriores configuramos o serviço telnet, tal serviço, e comumente
utilizado para testar o LVS, mas tal serviço não é muito útil em um cluster então
vamos configurar um serviço muito utilizado em um cluster o HTTP.
Primeiramente esteja certo de que os servidores reais estão com o serviço HTTP
habilitados na porta 80. Tenha as páginas web um pouco diferentes umas das
outras para que você perceba em qual servidor estará se conectando (apenas
para teste). Para fazer esta configuração manualmente, substitua o telnet pelo
HTTP no script do direcionador e execute o script no nó direcionador novamente.


fim

Cluster Balanceamento Carga

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Cluster Balanceamento Carga

Similar a Cluster Balanceamento Carga (20)

Más de Luiz Arthur

Más de Luiz Arthur (20)

Cluster Balanceamento Carga