tópicos - cluster de balanceamento de carga

Cluster de Balanceamento de Carga1 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çãoabrangente 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 maneiraque 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 Ano arquivo de configuração do domínio em questão.

@ IN SOA dns1.exemplo.com.br. email.exemplo.com.br. (01 ; serial03H ; refresh15M ; retry1W ; expiry1D ) ; minimum

IN NS dns1IN NS dns2IN MX 10 mail

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

IN A 1.2.3.2 # Servidor 2IN A 1.2.3.3 # Servidor 3IN A 1.2.3.4 # Servidor 4

ftp IN A 1.2.3.1 # Servidor 1IN A 1.2.3.2 # Servidor 2IN A 1.2.3.3 # Servidor 3IN A 1.2.3.4 # Servidor 4


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 aomesmo 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.

LAN/WAN

Internet/Intranet

Cliente

Servidor de Balanceamento

de Carga

ServidoresReais


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. Oserviç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 executandoo 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.


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 todosdeverã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.

Internet/Intranet

IP. 200.0.0.126

ClienteNó direcionador LVS

IP. 200.0.0.1

IP. 10.0.0.1

IP. 10.0.0.2

IP. 10.0.0.3

ServidoresReais


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.

Internet/Intranet

ClienteNó balanceador

ServidoresReais

Figura do esquema físico do LVS-TUN

Servidor responde diretamente ao Cliente


Túnel IP

Túnel IP


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.

Internet/Intranet

ClienteNó balanceador

ServidoresReais

Figura do esquema físico do LVS-DR



Segmento físico


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 encaminharos 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.

ServidoresReais

ClienteIP. 192.168.2.254

Servidor RealIP. 192.168.1.11\24

Servidor RealIP. 192.168.1.12\24

Nó DirecionadorIP. 192.168.2.110\24 (eth0:110)IP. 192.168.1.9\24 (eth0)

HUB

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.

Cluster de Balanceamento de Carga25 Luiz Arthur#!/bin/sh#Configurando o forward no vs-nat (1 on, 0 off). 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 /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#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

1

2

3


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:

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.

#!/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


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:

# ipvsadmIP Virtual Server version 0.9.14 (size=4096)Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConnTCP 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:


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.


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

tópicos - cluster de balanceamento de carga

Documents