linux lvs

2.296 visualizações

Publicada em

1 comentário
0 gostaram
Estatísticas
Notas
  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
2.296
No SlideShare
0
A partir de incorporações
0
Número de incorporações
54
Ações
Compartilhamentos
0
Downloads
108
Comentários
1
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

linux lvs

  1. 1. O que é LVS?
  2. 2. Apresentação       Henrique Haas - henriquehaas@gmail.com Novembro 2008
  3. 3. LVS   Linux Virtual Server    Servidor Virtual Linux  
  4. 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. 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. 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. 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. 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. 9. Arquiteturas para LVS • LVS-NAT (Network Address Translation)   • LVS-DR (Direct Routing)   • LVS-TUN (Tunneling - Encapsulamento IP-IP)
  10. 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. 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.
  12. 12. RFC 1918
  13. 13. 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;    
  14. 14. 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.   
  15. 15. 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;
  16. 16. 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.
  17. 17. 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.
  18. 18. 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
  19. 19. 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
  20. 20. Diagrama Usado em Laboratório
  21. 21. 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 
  22. 22. 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.
  23. 23. 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  
  24. 24. 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.
  25. 25. 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.
  26. 26. 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.
  27. 27. 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.
  28. 28. 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/
  29. 29. henriquehaas.com.br/blog/
  30. 30. Perguntas?

×