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.