1. O que é LVS?

2. Apresentação
Henrique Haas - henriquehaas@gmail.com
Novembro 2008

3. LVS
Linux Virtual Server
Servidor Virtual Linux

4. Conceito Básico de Alta Disponibilidade
• Garantir um ambiente operacional resistente a falhas de
software e hardware, cujo objetivo é manter os serviços em
operação durante o tempo previsto no nível de
disponibilidade da empresa.

5. Conceito Básico de Balanceamento de
Carga
• O balanceamento de carga permite distribuir as
requisições aos serviços entre os vários equipamentos que
os atendem, permitindo uma melhor aproveitamento dos
recursos entre os mesmos.

6. O que é LVS?
• O Linux Virtual Server é um projeto Open Source iniciado
por Wensong Zhang em maio de 1998.
• É uma tecnologia totalmente escalável, construída sobre um
cluster de servidores, capaz de prover alta disponibilidade e
balanceamento de carga.
• A entrega do serviço é completamente transparente para o
usuário final ou seja eles interagem como se tratasse de um
único servidor virtual de alta performance.

7. Conceitos
LVS Master - Servidor LVS Principal (de maior peso).
LVS Slave - Servidor LVS Redundante (menor peso).
LVS Ativo - Servidor que no momento responde pelo
serviço (pode ser chamado de Director).

8. Conceitos
VIP - Virtual IP - Endereço IP válido no mundo que
será usado pelo LVS ativo para responder pelos serviços.
RIP - Real IP – Endereço IP da rede interna usado pelos
LVS e Servidores Reais para se comunicarem.
DIP - Director IP - Endereço IP de rede exclusiva para
comunicação entre LVS's.

9. Arquiteturas para LVS
• LVS-NAT (Network Address Translation)
• LVS-DR (Direct Routing)
• LVS-TUN (Tunneling - Encapsulamento IP-IP)

10. LVS-NAT
• Os Servidores Reais devem estar na mesma subrede do
Director(LVS);
• Os endereços dos Nós (Servidores Reais) normalmente
estão em conformidade com a RFC 1918;
• As conexões (de entrada e saída) passam todas pelo
Director;
• O Director deve ser o gateway padrão dos Servidores
Reais;

11. LVS-NAT
• O Director pode remapear números de portas, isto é, uma
requisição é recebida em uma porta dele e pode ser
redirecionada para uma porta diferente de um Servidor
Real;
• Qualquer sistema operacional pode ser usado nos
Servidores Reais;
• Desvantagem: O gargalo do ambiente pode ser um único
Director configurado para atender a demanda, embora uma
rede saturada normalmente seja o problema mais comum.

13. RFC 1918

14. LVS-DR
• Os Servidores Reais devem estar no mesmo barramento
que o Director;
• Os RIP não necessitam estar em conformidade com a RFC
1918;
• Somente as requisições passam pelo Director, as respostas
são enviadas diretamente aos clientes pelos Servidores
Reais;
• As portas não podem ser remapeadas no Director;

15. LVS-DR
• LVS-DR permite mais Servidores Reais que LVS-NAT;
• Não há sobrecarga no Director como no LVS-NAT;
• Só permite balanceamento de carga em um mesmo Data-
Center.

17. LVS-TUN
• Os Servidores Reais não necessitam estar no
mesmo barramento e rede que o Director;
• Os RIP não necessitam estar de acordo com a RFC 1918;
• O Director apenas recebe requisição dos clientes, as
respostas são enviadas diretamente dos Servidores Reais;

18. LVS-TUN
• O Director não pode remapear portas;
• Os sistemas operacionais dos Servidores Reais precisam
suportar IP tunneling;
• Permite o balanceamento de carga entre Data-Centers
diferentes.

20. Tunelamento IP
• É um termo técnico para designar o
encapsulamento de um pacote IP dentro de
outro, com o propósito de simular uma
conexão física ponto a ponto entre duas
redes remotas através de uma outra rede.

21. Passo a Passo
Cliente localiza o gateway de sua rede através do protocolo
ARP
 Cliente solicita a resolução de um endereço para o DNS
 Cliente solicita um serviço publicado no mundo através do
protocolo HTTP ou HTTPS

22. Passo a Passo
 O LVS recebe a solicitação, confere em sua tabela quem
fornece o serviço e encaminha a solicitação para o servidor
real ;
 O servidor recebe a solicitação do cliente, processa e
responde diretamente ao cliente usando o VIP no cabeçalho

25. Diagrama Usado em Laboratório

26. Adic. ou Rem. Serviços e Servidores dos LVS
vim /etc/ha.d/ldirectord.cf
checktimeout=2
checkinterval=2
autoreload=yes
quiescent=no
logfile="info"
#Serviço 1
virtual=172.30.1.9:80
real=192.168.0.100:80 gate 1 ".alive.html", "ok"
real=192.168.0.101:80 gate 2 ".alive.html", "ok"
real=192.168.0.102:80 gate 3 ".alive.html", "ok"
service=http
checkport=80
protocol=tcp
scheduler=wlc
checktype=negotiate
#Serviço 2
virtual=172.30.1.9:21
real=192.168.0.120:21 gate 1
real=192.168.0.121:21 gate 2
service=ftp
checkport=21
protocol=tcp
scheduler=wlc
#Serviço 3 ...
/etc/init.d/ldirectord restart

27. Como um serviço é Monitorado?
 O LVS possui uma lista de servidores e serviços. Ele
verifica a disponibilidade dos serviços periodicamente.
Se algum serviço estiver indisponível ele “sai da lista”.
O LVS continua monitorando, e assim que for
restabelecido o serviço, o LVS percebe e ele volta a
lista de serviços disponíveis.

28. Adaptações Necessárias nos Servidores
Reais
No Servidor Real é criado um script que é inicializado no
boot, e o prepara para trabalhar com o LVS-DR.
/etc/init.d/lvsdrrs
Quando executado ele:
• Ativa a interface lo;
• Configura o ARP para não se anunciar;
• Configura IP VIRTUAL para lo:0;
• Adiciona rota para o IP VIRTUAL acima
• Adiciona rota para rede 172.30.1.0 no dispositivo real
• Adiciona rota default para o roteador da rede 172

29. Justificativa para
ARP Non-Announce nos servidores.
 Para garantir um perfeito funcionamento desta
tecnologia, só o LVS pode responder pelos serviços.
Por isso na entrada ninguém chega aos servidores se
não pelo LVS.

30. Algoritmos de Balanceamento de Carga
rr (Round Robin): distribui as requisições igualmente entre
os servidores reais disponíveis. Este é o algoritmo de
agendamento mais simples.
wrr (Weighted Round Robin): similar ao anterior, utiliza,
entretanto um valor que determina o peso de cada servidor
real. Servidores reais com maior peso receberão mais
requisições que os de menor peso.

31. Algoritmos de Balanceamento de Carga
lc (Least-Connection): distribui requisições ao servidor com
menor quantidade de conexões no momento da escolha.
wlc (Weighted Least-Connection): distribui requisições ao
servidor com menor quantidade de conexões no momento
da escolha, levando em consideração também o peso
atribuído a cada servidor real. Este é o modo de
agendamento escolhido por padrão.

32. Persistência de Conexão
 A persistência garante que o cliente sempre será
direcionado a um mesmo servidor, mesmo em
diferentes conexões, possibilitando que ele mantenha
por exemplo um carrinho de compras ou um formulário
preenchido.
 Ela é útil quando o estado precisa ser mantido.
 Só é possível se a aplicação prover suporte a esta
funcionalidade.
 Também conhecida como afinidade de sessão.
 Pode ser custosa a sua implementação, pois será
necessária uma replicação de dados.
 No LVS é possível incluir um serviço com persistência.

33. Referências Bibliográficas
 LINUX ENTERPRISE CLUSTER – KARL KOPPER
 http://www.linux-ha.org/
 http://guialivre.governoeletronico.gov.br/
 http://wiki.sintectus.com/
 http://www.austintek.com/

34. henriquehaas.com.br/blog/

35. Perguntas?