Alta Disponibilidade com LVS

Neste artigo vamos dar um overview do Linux Virtual Server (LVS), que é largamente utilizado em sistemas que necessitam de alta disponibilidade, tolerância a falhas e balanceamento de carga.

[ Hits: 78.142 ]

Por: Alan Cota em 02/05/2005


O projeto LVS



O Linux Virtual Server - LVS, é um projeto open source que tem como principal objetivo a criação de clusters de alta disponibilidade para aplicações críticas de TI.

Dentre suas características, podemos mencionar sua performance e escalabilidade flexível. O LVS é um sistema de cluster totalmente transparente para seu usuário final, pois mesmo que você tenha 20 nós em seu cluster, seu usuário interagirá com apenas um endereço de entrada.


Como mostra a figura acima, em um cluster com LVS, nós temos de forma explícita 2 tipos de máquinas, que são importantes ao funcionamento. São elas:
  • Load Balancer: Este é o host responsável por receber as requisições vindas dos clientes (usuários finais) e transmití-las aos real servers do cluster. Lógico que este é o ponto fraco de seu cluster, pois você deve estar pensando: "Tudo bem, eu tenho 20 nós em meu cluster. Mais se meu ponto de entrada é apenas 1 máquina, eu tenho uma falha, pois se esta máquina cair, consecutivamente meu cluster cai também!" Realmente está correto! Porém nós vamos ver mais adiante que podemos usar ferramentas como o HeartBeat para monitorar e criar um "espelho" deste servidor de Load Balancer, para se caso ele falhar, a máquina espelhada assumir seu lugar automaticamente.
  • Real Servers: São os servidores do cluster que detêm os serviços oferecidos pelo cluster aos clientes. Para um cluster é necessário que exista no mínimo 2 real servers.

O LVS é implementado de 3 formas diferentes:
  • Virtual Server via NAT
  • Virtual Server via IP Tunneling
  • Virtual Server via Direct Routing

Vamos explicar cada uma delas:

Virtual Server via NAT


A vantagem do Virtual Server via NAT é que os real server podem executar qualquer sistema operacional que suporta TCP/IP com endereços IP privados e apenas 1 endereço IP é necessário para o Load Balancer.

A desvantagem desta modalidade do LVS é a limitação da escalabilidade, caso o número de real servers em seu cluster passe de 20 servidores. Caso este número seja ultrapassado, o load balancer será um gargalo em seu sistema LVS, pois todos os pacotes que passam pelo load balancer têm que ser reescritos para fazer o NAT. Isto é lógico, pois supondo que a média do tamanho dos pacotes TCP que irão trafegar por seu load balancer seja de 563 bytes, o tempo médio para reescrever este pacote é de 60us, em um processador Intel Pentium. O throughput (capacidade de processar e enviar pacotes) do load balancer será de 8.93 MBps.

Assumindo que o throughput dos real servers seja de 400Kbps, o load balancer poderá gerenciar até no máximo 22 real servers. Lógico que isso é baseado em suposições e projetado para ambientes realmente enormes, com mais de 20 nós de cluster.

Virtual server via IP tunneling


Nesta modalidade o load balancer ao invés de fazer a comunicação de entrada (request dos usuários) e saída (resposta dos real servers), ele faz apenas um scheduler dos requests, pois a resposta dos real servers é enviada diretamente ao usuário, sem passar pelo load balancer. Desta maneira, o load balancer pode administrar até 100 real servers, sem gerar gargalos no sistema.

Este tipo de LVS é excelente para implementação de sistemas de proxy para a internet altamente disponíveis. Pois o load balancer encaminha as requisições dos clientes para os servidores proxy (real servers) e estes respondem diretamente para os usuários.

Para que isso funcione, todos os servidores do cluster precisam ter o IP Tunneling (Encapsulamento IP) habilitado. E é aqui que "mora o problema", pois habilitar este IP Tunneling pode ser simples para o Linux, mas talvez não seja se você tiver real servers com Solaris, por exemplo. Isto dificulta a utilização de real serves com sistemas operacionais diferentes.

Virtual Server via Direct Routing


Como na modalidade de cluster anterior (Virtual Server via Tunneling), o Direct Routing só processa requisições de entrada, deixando os real servers responderem diretamente para os usuários, utilizando roteamento direto ao invés de IP Tunneling.

A única limitação para este tipo de LVS é que tanto o load balancer quanto os real servers precisam ter uma interface de rede que esteja no mesmo segmento da rede corporativa.

Página anterior     Próxima página

Páginas do artigo
   1. Uma breve introdução
   2. O projeto LVS
   3. LVS junto com outras ferramentas
   4. Final
Outros artigos deste autor

Certificações Novell para Linux

SuSE Linux Enterprise Desktop 10 - O novo desktop Linux da Novell

Controlando e interagindo remotamente com Elluminate

Administrando bancos MySQL com phpMyAdmin

Gerenciando regras de Iptables com Firewall Builder

Leitura recomendada

Mantendo seu Slackware atualizado com o slackcurrent

Instalação do Freeradius com suporte a EAP-TLS e PEAP-TTLS MSCHAPv2 no Ubuntu

Proxy reverso com ModSecurity no Debian Etch

Criptografia quântica

Snort + ACID + MySQL no Slackware

  
Comentários
[1] Comentário enviado por tucs em 02/05/2005 - 07:34h

LVS é um Linux Virtual Server, onde ele atua como um DIRECIONADOR ou seja imagine que se tenha 3 maquinas em um LVS e mais um DIRECIONADOR, quando um cliente pede uma requisição o DIRECIONADOR manda para uma maquina, e quando outro pedir ele manda para a segunda maquina, e assim por diante.

Existe o Cluster de HA (Alta Disponibilidade), geralmente usado o HeartBeat + DRBD, ai sim, quando uma maquina parar a outra assume o serviço, no Caso do LVS, se o Direcionador parar acabo o esquema de LVS.

O correto seria usar LVS com HA no DIRECIONADOR.

Pelo menos foi assim que montei em uma Provedora.

Abraços.

Eduardo Assis.

[2] Comentário enviado por shocker em 03/05/2005 - 12:54h

Opa! :)
Apesar de ser um direcionador, eu procurei englobar a utilização do LVS como um todo.

Mais obrigado pelo seu comentário.

[]'s
Alan Cota.

[3] Comentário enviado por agk em 06/05/2005 - 18:24h

Parabéns pelo artigo, LVS realmente é um conceito muito bom, para balancear os acessos e distribuir nos servidores do LVS. O problema consiste no distribuidor (balancer), que se entrar em pane para todo o serviço, mas isso também pode ser contornado usando-se um balancer de backup, onde ele assumiria o lugar do principal se este parasse de responder, deixando assim tempo para o administrador resolver o problema sem que os usuários perdessem o acesso.

[4] Comentário enviado por jalexandre em 19/12/2005 - 11:01h

http://www.austintek.com/LVS/LVS-HOWTO/mini-HOWTO/LVS-mini-HOWTO-pt.html
Um step-by-step pra configurar um LVS
Alan Cota -- Obrigado por este artigo! Me ajudou a dar um norte para meu projeto!

[5] Comentário enviado por osvalcde em 14/08/2007 - 20:05h

oi..

to trabalhando nom cluster trabanho da facultade..

to utilizando o manual de Ultramonkey http://www.ultramonkey.org/3/topologies/hc-ha-lb-e...
eu fiz todo perfeito, mais aparece um problema de conexao.. disculpa o meu portugueis

meu cluster consiste em 4 maquinas 2 Diretores un Ativo o outro backup e 2 Servidores Reais.. to trabalhando en Debian 3.1 com kernel 2.6

tris is my problem, only 1 conect
# ipvsadm -ln
IP Virtual Server version 1.2.0 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 172.18.200.33:21 rr
-> 172.18.200.31:21 Route 0 0 0
-> 172.18.200.32:21 Route 0 0 0
-> 127.0.0.1:21 Local 1 0 0
TCP 172.18.200.33:80 rr
-> 172.18.200.32:80 Route 0 0 0
-> 172.18.200.31:80 Route 1 0 0
TCP 172.18.200.33:443 rr
-> 172.18.200.32:443 Route 0 0 0
-> 172.18.200.31:443 Route 0 0 0
-> 127.0.0.1:443 Local 1 0 0
-----------------------------------------------------------------------------------------------------------

# ipvsadm -lcn
IPVS connection entries
pro expire state source virtual destination
TCP 00:40 SYN_RECV 172.18.200.39:2841 172.18.200.33:21 127.0.0.1:21
TCP 00:43 SYN_RECV 172.18.200.39:2852 172.18.200.33:21 127.0.0.1:21
TCP 00:46 SYN_RECV 172.18.200.39:2861 172.18.200.33:21 127.0.0.1:21
TCP 00:44 SYN_RECV 172.18.200.39:2855 172.18.200.33:21 127.0.0.1:21
TCP 00:47 SYN_RECV 172.18.200.39:2862 172.18.200.33:443 127.0.0.1:443
TCP 00:39 SYN_RECV 172.18.200.39:2838 172.18.200.33:21 127.0.0.1:21
TCP 00:38 SYN_RECV 172.18.200.39:2834 172.18.200.33:21 127.0.0.1:21
TCP 00:45 SYN_RECV 172.18.200.39:2858 172.18.200.33:21 127.0.0.1:21
TCP 00:42 SYN_RECV 172.18.200.39:2849 172.18.200.33:21 127.0.0.1:21
TCP 00:31 SYN_RECV 172.18.200.39:2828 172.18.200.33:21 127.0.0.1:21
TCP 00:41 SYN_RECV 172.18.200.39:2846 172.18.200.33:21 127.0.0.1:21

por favor algen pode me dar uma mao.. [email protected]

[6] Comentário enviado por leoreis em 23/05/2009 - 17:01h

Prezados,

a nossa aplicação web tem uma característica de que não apenas uma conexão https é estabelecida, durante o uso da mesma, outras conexões são estabelecidas.

Dúvida: quando chegar a segunda conexao https (do mesmo usuario), o LVS irá redirecionar a conexão para o tomcat correto? Imagina, tenho 3 tomcats, todas as requisicoes de um determinado usuario devem ir para o mesmo tomcat, pois se for para um tomcat errado, o usuário não estar logado (já estamos trabalhando em uma solucao para a sessão do usuário estar disponivel em todos os nós...).

Pode me ajudar? O LVS garante o envio para o tomcat correto?

Leo
Quem puder me ajudar , segue-se me email: [email protected]

[7] Comentário enviado por llbranco em 19/06/2012 - 18:47h

muitissimo interessante!!!

extremamente util e muito bem explicado, parabens


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner
Linux banner
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts