HOWTO: Linux Virtual Server

De Wiki Hackstore

Introdução

O sistema Linux Virtual Server é uma funcionalidade do kernel do Linux que permite a criação de um load balancer usando Linux. O objetivo é balancear a carga de conexões chegando a uma porta específica por vários servidores. O resultado é um cluster dividindo a carga de processamento e resistente a falhas.

O servidor que faz o balanceamento de carga é chamado de Diretor e os que processam as requisições são chamados de servidores Reais. O IP que o cliente acessa é chamado de IP virtual ou VIP. O IP de cada servidor real é chamado de IP real ou RIP.

Existem três métodos de implementação do LVS: NAT, tunelling e direct routing. O último método é o mais indicado pois tem o menor custo de CPU e de overhead na rede.

Essa funcionalidade é utilizada no Yaxkin para balancear a carga dos protocolos SMTP, IMAP e POP3. O balanceamento de carga dos servidores Web funcionam de forma diferente.

Referência: http://www.linuxvirtualserver.org/whatis.html

Outra referência: http://www.austintek.com/LVS/LVS-HOWTO/mini-HOWTO/LVS-mini-HOWTO.html

Direct Routing

Para entender como o sistema 'Direct Routing' funciona visite http://www.linuxvirtualserver.org/VS-DRouting.html.

O importante é que, com o Direct Routing, o IP Virtual (VIP) é compartilhado por todos os servidores reais. Isso gera o problema de todas as máquinas responderem requisições ARP que procuram por máquinas com esse IP. Apenas o servidor Diretor pode responder por este IP. É necessário desabilitar este comportamento padrão nos servidores reais. A referência sobre como fazemos isso no Yaxkin está em: http://kb.linuxvirtualserver.org/wiki/Using_arp_announce/arp_ignore_to_disable_ARP.

Resumindo: primeiro é necessário colocar as seguintes configurações no /etc/sysctl.conf:

net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.eth0.arp_announce = 2

Para que a alteração acima se torne efetiva imediatamente, execute:

sysctl -p

Depois, editamos o /etc/conf.d/net e adicionamos a linha

config_lo=( "<VIP>/32" )

para que o servidor real também ache que tem este IP.

Importante: é necessário que o arquivo sysctl.conf seja processado antes do VIP ser levantado na loopback. Caso contrário pode haver uma requisição ARP que o servidor real responde pelo VIP gerando problema na rede.

Importante: é necessário que a netmask do VIP no servidor real seja 255.255.255.255 (32 bits)

Usando o ipvsadm

Criando o serviço:

ipvsadm -A -t <VIP>:<PORT> -s <SCHEDULER>

As opções válidas para scheduler, na prática, são: rr, wrr, lc e wlc. Na man page ipvsadm(8) estão explicadas estas opções. Por enquanto, utilizaremos a opção 'rr' pois todos os servidores tem capacidades iguais.

Para adicionar cada máquina no serviço o comando é:

ipvsadm -a -t <VIP>:<PORT> -r <RIP> -g -w <PESO>

A opção '-g' siginifica 'Direct Routing'. O peso importa apenas para os schedulers wrr e wlc, o valor usado por padrão é 10. Esse valor é analisado proporcionalmente em relação aos outros servidores reais. Se um servidor tem peso 20 e outro tem valor 10 então o primeiro recebe o dobro de conexões do segundo.

Ao mudar o peso de um servidor real para zero ele para de receber novas conexões (as atuais são mantidas). Isso deve ser feito sempre que algum servidor real for colocado em manutenção. O comando para fazer isso é:

ipvsadm -e -t <VIP>:<PORT> -r <RIP> -g -w 0

Alta disponibilidade com o keepalived

Como servidores reais podem falhar, é necessário ter um sistema que os monitora incluindo-os ou removendo-os do LVS sempre que necessário. Existe também o caso do servidor diretor falhar, sendo necessário um sistema que também o monitore que promova a alta disponibilidade do serviço.

Para tal fim nós usaremos o aplicativo keepalived. Para instalá-lo basta executar:

emerge sys-cluster/keepalived

O keepalived cuida de configurar e manter todo o sistema LVS, não sendo necessário utilizar o comando ipvsadm para configurar nada. Tudo é gerenciado por ele. O arquivo de configuração dele é o /etc/keepalived/keepalived.conf.

Referência: http://www.keepalived.org/pdf/UserGuide.pdf.

Referência: http://kb.linuxvirtualserver.org/wiki/Building_Two-Node_Directors/Real_Servers_using_LVS_and_Keepalived

A parte inicial do arquivo é:

global_defs {
   router_id 1
}

Esta parte inicial especifica o nome deste diretor (router_id) e também as parâmetros dos e-mails enviados quando problemas forem detectados.

Um exemplo de serviço é mostrado abaixo:

virtual_server 192.168.0.160 25 {
    delay_loop 10
    lb_algo wrr
    lb_kind DR
    protocol TCP

    real_server 192.168.0.100 25 {
        weight 10
        SMTP_CHECK {
                connect_timeout 30
                retry 3
                delay_before_retry 20
                helo_name "mail2.yaxkin.com.br"
        }
    }

    real_server 192.168.0.8 25 {
        weight 12
        SMTP_CHECK {
                connect_timeout 30
                retry 3
                delay_before_retry 20
                helo_name "mail.yaxkin.com.br"
        }
    }
}

O parâmetro delay_loop fala de quanto em quanto tempo cada servidor real deve ser testado. O parâmetro lb_algo especifica qual o scheduler a ser usado pelo LVS e o lb_kind especifica qual o método de LVS que será utilizado. No caso do Yaxkin o método é sempre o DR (Direct Routing).

Cada servidor real tem a sua entrada separada e também o seu método de teste separado. O parâmetro weight representa o peso daquele servidor.

A chave SMTP_CHECK configura os parâmetros do teste a ser feito no servidor. Além do teste SMTP_CHECK, também existem HTTP_GET, SSL_GET, MISC_CHECK e TCP_CHECK. O último é o recomendado para os protocolos IMAP e POP3.

O arquivo de configuração nos moldes atuais já possibilita a execução de um sistema LVS completo resistente a falhas dos servidores reais. Se um servidor real falhar então o keepalived vai detectar a falhar e removê-lo da lista de servidores virtuais. Falta agora configurar o keepalived para resolver também problemas de falhas dos diretores.

Para garantir a alta disponibilidade dos diretor é necessário ter dois diretores instados. Neste diretores são criadas instâncias do VRRP (sistema resposável pela alta disponibilidade) que movem de um diretor para outro no caso de falha. É possível ter duas instâncias sendo que, na situação padrão, elas estejam ativas cada uma em um diretor diferente. Com isso é possível ter o balanceamento da carga do diretor também.

Cada instância é responsável por um VIP próprio. Quando a instância é instalada no keepalived ela pode iniciar como MASTER ou BACKUP. Veja abaixo um exemplo de uma instância MASTER:

vrrp_instance VIP_1 {
   state MASTER
   interface eth0
   virtual_router_id 1
   priority 100
   advert_int 3
   authentication {
       auth_type PASS
       auth_pass 'SENHA'
   }
   virtual_ipaddress {
     192.168.0.160
  }
}

No caso do diretor que vai ter esta instância rodando como BACKUP o parâmetro priority deve ser menor e o parâmetro state deve ser BACKUP.

Instâncias diferentes deve ter o parâmetro virtual_router_id diferentes.

Importante: nunca use auth_type AH.

Quando o failover acontece, as conexões atuais são perdidas pois o diretor de backup não sabe para que servidor estão sendo enviados cada pacote das conexões atuais. Para resolver isso, execute:

  • No primeiro servidor:
ipvsadm --start-daemon master --mcast-interface eth0 --syncid 1
ipvsadm --start-daemon backup --mcast-interface eth0 --syncid 2
  • No segundo servidor:
ipvsadm --start-daemon master --mcast-interface eth0 --syncid 2
ipvsadm --start-daemon backup --mcast-interface eth0 --syncid 1

Preferencialmente, eth0 deve ser substituído por uma interface que esteja ligada entre os dois servidores por um cabo cross-over.