Capítulo 9. Visão Geral do Servidor Virtual Linux

O clustering LVS do Red Hat Enterprise Linux usa uma máquina Linux chamada servidor ativo para enviar pedidos da Internet para um conjunto de servidores. Para realizar isso, os clusters LVS são compostos de dois tipos de máquinas básicas — os roteadores LVS (um ativo e um backup) e um conjunto de servidores reais que oferecem os serviços críticos.

O roteador ativo tem duas funções no cluster:

A função do roteador backup é monitorar o roteador ativo e assumir sua função no caso de falhas.

9.1. Uma Configuração LVS Básica

A Figura 9-1 mostra um cluster LVS simples com duas camadas. Na primeira camada há dois roteadores LVS — um ativo e um backup. Cada um dos roteadores LVS tem duas interfaces de rede, uma ligada à Internet e outra à rede privada, o que possibilita que ambos regulem o tráfego entre as duas redes. Neste exemplo, o roteador ativo está usando Tradução de Endereço de Rede (Network Address Translation) ou NAT para direcionar o tráfego da Internet a um número variável de servidores reais na segunda camada, que por sua vez oferecem os serviços necessários. Consequentemente, os servidores reais deste exemplo são conectados a um segmento da rede dedicada privada e passam todo o tráfego público para trás e adiante através do roteador LVS ativo. Para o mundo externo, o servidor cluster aparece como uma única entidade.

Figura 9-1. Uma Configuração LVS Básica

Os pedidos de serviço que chegam no cluster LVS são encaminhados para um endereço IP virtual ou VIP. Este é um endereço publicamente roteável que o administrador do site associa a um nome de domínio totalmente qualificado, como www.exemplo.com, que é atribuído a um ou mais servidores virtuais[1]. Note que o endereço VIP migra de um roteador LVS a outro durante a falha, portanto mantendo a presença neste endereço IP, também conhecido como endereço IP flutuante.

Os endereços VIP podem ser apelidados com o mesmo nome do dispositivo que conecta o roteador LVS à Internet. Por exemplo: se eth0 está conectada à Internet, então os múltiplos servidores virtuais podem ser apelidados como eth0:1. Alternativamente, cada servidor virtual pode ser associado a um dispositivo por serviço, separadamente. Por exemplo: o tráfego HTTP pode ser manipulado por eth0:1, e o tráfego FTP pode ser manipulado por eth0:2.

Somente um roteador LVS está ativo por vez. A função do roteador ativo é redirecionar os pedidos de serviço dos endereços IP virtuais para os servidores reais. O redirecionamento é baseado em um dos oito algoritmos de balanceamento de carga suportados, detalhadamente descritos na Seção 9.3.

O roteador ativo também monitora dinamicamente a saúde geral dos serviços específicos nos servidores reais através de scripts send/expect simples. Para auxiliar na detecção da saúde dos serviços que requerem dados dinâmicos, como HTTPS ou SSL, o administrador pode trazer executáveis externos. Se um serviço de um servidor real funcionar mal, o roteador ativo pára o envio de tarefas para este servidor até que retorne à operação normal.

O roteador backup executa a função de um sistema em standby. Periodicamente, os roteadores LVS trocam mensagens de heartbeat entre si através da inteface pública externa principal e, na ocaisão de falha, através da interface privada. Se o nódulo backup falhar em receber a mensagem de heartbeat em um intervalo esperado, inicia uma queda e assume a função do roteador ativo. Durante a queda, o roteador backup assume os endereços VIP servidos pelo roteador falho usando uma técnica conhecida como ARP spoofing — na qual o roteador LVS backup se auto-anuncia como o destino de pacotes IP endereçados ao nódulo falho. Quando o nódulo falho volta à ativa, o nódulo backup assume sua função backup novamente.

A simples configuração de duas camadas usada na Figura 9-1 é mais indicada para clusters servindo dados que não modificam com frequência — como páginas web estáticas — porque os servidores reais individuais não sincronizam automaticamente os dados entre cada nódulo.

9.1.1. Duplicação de Dados e Compartilhamento de Dados Entre Servidores Reais

Como não há um componente embutido no clustering LVS para compartilhar os mesmos dados entre servidores reais, o administrador tem duas opções:

  • Sincronizar os dados ao longo do conjunto de servidores reais

  • Adicionar uma terceira camada à topologia para acesso aos dados compartilhados

A primeira opção é mais indicada para servidores que não permitem a um grande número de usuários fazer upload ou alterar dados nos servidores reais. Se o cluster permite que um grande número de usuários altere os dados, como no caso de um site de comércio eletrônico, é preferível adicionar a terceira camada.

9.1.1.1. Configurando Servidores Reais para Sincronizar Dados

Um administrador pode escolher dentre diversas maneiras para sincronizar dados através de um conjunto de servidores reais. Por exemplo: os scripts de janelas de comandos podem ser empregados de modo que, se um engenheiro web atualiza uma página, esta página é postada a todos os servidores simultaneamente. Além disso, o administrador do cluster pode usar programas como o rsync para duplicar os dados alterados através de todos os nódulos em um determinado intervalo.

Entretanto, este tipo de sincronização de dados não funciona perfeitamente se o cluster está sobrecarregado de usuários fazendo upload de arquivos ou executando transações de bancos de dados constantemente. Para um cluster com carga alta, uma topologia de três camadas é a solução ideal.

Notas

[1]

Um servidor virtual é um serviço configurado para escutar um endereço virtual IP específico. Consulte a Seção 12.6 para saber mais sobre a configuração de um servidor virtual usando a Ferramenta de Configuração do Piranha.