Busca


imprimir pdf

fedora cluster



Breve descrição


Este guia foi elaborado por pessoas com experiência, com conhecimentos de redes e na recompilação do kernel. Este guia terá por âmbito criar um cluster com um load balancer em fedoracore. (Este guia foio realizado com fedoracore 8).

Terá 4 etapas:
  • Compilação do kernel.
  • Instalação e configuração do load balancer (ipvsadm e ldirectord).
  • Configuração dos servidores reais.
  • Instalação e configuração do filer.


Compilação do kernel


Vá a pasta /usr/src/ e faça o download das fontes do kernel e o .config
exemplo:

cd /usr/src/
wget ftp://ftp.ovh.net/made-in-ovh/bzImage/linux-2.6.24.5-ovh.tar.bz2
tar -jxvf linux-2.6.24.5-ovh.tar.bz2
ln -s linux-2.6.24.5-ovh linux
wget ftp://ftp.ovh.net/made-in-ovh/bzImage/2.6-config-xxxx-std-ipv4-32
cp 2.6-config-xxxx-std-ipv4-32 linux/.config
cd linux


Configuração

Tem 3 possibilidades para reconfigurar um kernel:
  • make xconfig (gráfico) ou,
  • make menuconfig (modo texto com menus) ou ainda,
  • make config (modo texto integral).

Vamos utilizar:
make menuconfig


Depois, recompilamos o kernel com o suporte de lvs:

Activamos as seguintes opções:

Networking ---> * Networking support Networking options ---> IP: Virtual Server Configuration ---> IP virtual server support (EXPERIMENTAL) * IP virtual server debugging (20) IPVS connection table size (the Nth power of 2) --- IPVS transport protocol load balancing support * TCP load balancing support * UDP load balancing support * ESP load balancing support * AH load balancing support --- IPVS scheduler <*> round-robin scheduling <*> weighted round-robin scheduling <*> least-connection scheduling <*> weighted least-connection scheduling <*> locality-based least-connection scheduling <*> locality-based least-connection with replication scheduling <*> destination hashing scheduling <*> source hashing scheduling <*> shortest expected delay scheduling <*> never queue scheduling --- IPVS application helper <*> FTP protocol helper


Compilação

Verificamos as dependências:
make dep


Compilamos o kernel:
make bzImage


Instalação (as linhas seguintes são para adaptar a sua configuração, a versão do kernel...)

cp arch/x86/boot/bzImage /boot/bzImage-loadbalancer
cp System.map /boot/System.map-loadbalancer
ln -s /boot/System.map-loadbalancer System.map


depois, editamos o ficheiro /etc/lilo.conf.

nano /etc/lilo.conf


modifique a linha:
default=linux por default=loadbalancer

e adicione um parágrafo por exemplo:

image=/boot/bzImage-loadbalancer
label=loadbalancer
read-only
root=/dev/md1


root=/dev/md1 a substituir pelo valor da sua partição de boot.

voltamos a carregar a configuração pelo comando:
/sbin/lilo


depois, reiniciamos o servidor.
/sbin/reboot


o nosso servidor reinicia, passamos a instalação e a configuração do nosso balanceador de carga:


Instalação e configuração do balanceamento de carga


Aspectos Gerais

A seguir segue um exemplo de como vai ser mais ou menos o trajecto de um pedido para o balanceador de carga:

Vamos utilizar a arquitectura tunneling IP para este guia.

As arquitecturas LVS

  • NAT (Network Adress Translation): ou seja a tradução do endereço IP entre o balanceador de carga e os servidores reais.

  • O Direct Routing: o balanceador de carga e os servidores reais devem estar sobre o mesmo segmento de rede, os servidores reais respondem directamente ao cliente.

  • Tunneling IP: a ligação entre o balanceador de carga e os servidores reais é feita via um túnel IP, os servidores reais respondem directamente ao cliente.

Neste guia, desenvolveremos a última arquitectura LVS.

Os algoritmos LVS

É preciso escolher entre os diferentes algoritmos de balanceamento de acordo com as suas necessidades e os diferentes serviços geridos pelo balanceador de carga:

  • Round-robin Scheduling (rr): Nesta configuração, o balanceamento funciona de maneira cíclica, sem preocupação na carga dos servidores. O primeiro pedido será afectado ao primeiro servidor, o segundo ao segundo servidor, assim de seguida.

  • Weighted Round-robin Scheduling (wrr): Mesma técnica, mas os servidores reais podem ser afectados por pesos, para ter em conta diferentes capacidades de tratamento.

  • Least-connection Scheduling (lc): O balanceador de carga possui uma tabela de ligações activas. Ele enviará todos os novos pedidos ao servidor que tem o menos de ligações activas, dinamicamente.

  • Weighted Least-connection Scheduling (wlc): Mesma ideia que o algoritmo anterior, tendo a possibilidade de atribuir pesos aos servidores.

  • Locality-based Least-connection Scheduling (lblc) O load balancer escolhe um servidor real num grupo em função do endereço IP de destino. Ele é utilizado nos clusters de cache.

  • Locality-based Least-connection with Replication scheduling (lblcr): Idem que o anterior, com uma funcionalidade suplementar. Se todos os servidores do grupo estão sobrecarregados ou indisponíveis, ele escolhe um servidor noutro grupo para afecta-lo ao primeiro grupo de servidores.

  • Destination Hashing Scheduling (dh): Afecta o pedido que chega a um servidor de um grupo fixo dentro de uma tabela hash, em função do endereço IP de destino.

  • Source Hashing Scheduling (sh): Afecta o pedido a um servidor real em função do endereço de origem.


Instalação do balanceador de carga

Para gerir LVS que activamos no nosso kernel, instalamos ipvsadm.
Para comparar, ipvsadm é o que é iptable a netfilter.

Para instalar o ipvsadm utilize os comandos:

yum install ipvsadm


modifique o ficheiro /etc/sysctl.conf:

nano /etc/sysctl.conf


substituir:
net.ipv4.ip_forward = 0 por net.ipv4.ip_forward = 1

depois volta a carregar sysctl:

sysctl -p /etc/sysctl.conf


verificamos que ele está instalado correctamente:

ipvsadm -l
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn? InActConn?


Não há nenhuma mensagem de erro então continuamos.


Configuração do balanceamento de carga

Para o nosso balanceamento de carga vamos utilizar um ipfailover o que nos vai permitir além de fazer um balanceamento de backup em caso de problema, de passar o ip failover de um balanceador para outro.

Neste guia, vamos chamar o ip do nosso balanceador de carga: IPDIRECTOR
será então preciso substituir IPDIRECTOR pelo ip do balanceador de carga.

Para configurar o ip failover consulte este guias:
http://guias.ovh.pt/adicionaraliasip

Vamos pegar um exemplo de configuração para o servidor apache (porto 80)
teremos no exemplo 2 servidores reais com os IP: IPR1 e IPR2.

Escolhemos o algoritmo wrr e declaramos uma repartição para o porto 80 com o IP IPDIRECTOR:

ipvsadm -A -t IPDIRECTOR:80 -s wrr


verificamos que foi tomado em conta:

ipvsadm -l
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn? InActConn?
TCP reverse.IPDIRECTOR:http wrr


vemos que tomou em conta o IPDIRECTOR para o porto 80 e o algorithmo wrr.

Agora adicionamos e definimos os nossos servidores com pesos diferentes.
  • Servidor 1 terá o peso 2
  • Servidor 2 terá o peso 1

Temos um total de 3 para o conjunto dos pesos.
O servidor 1 terá 2/3 dos pedidos e o servidor 2 terá 1/3 dos pedidos.

ipvsadm -a -t IPDIRECTOR:80 -r IPR1:80 -i -w 2
ipvsadm -a -t IPDIRECTOR:80 -r IPR2:80 -i -w 1


Verificamos que os servidores foram bem tomados em conta assim que os pesos deles.

ipvsadm -l
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP gandalf.ovh.net:http wrr
-> reverse1:http Tunnel 2 0 0
-> reverse2:http Tunnel 1 0 0


Os nossos servidores estão no cluster.

Agora, é preciso configurar os nossos servidores reais para que possam aceitar os pacotes.


Configuração dos servidores reais


Para que o nosso servidor real aceite os pedidos enviados pelo balanceador de carga, o ip do nosso balanceador deve ser conhecido por cada máquina do cluster, adicionamos este ip desta maneira:
(manipulação a fazer sobre cada máquina do cluster)

ifconfig tunl0 0.0.0.0 up
ifconfig tunl0 IPDIRECTOR netmask 255.255.255.255 broadcast IPDIRECTOR


Cuidado em algumas distribuições o facto de realizar a configuração com ifconfig pode fazer com que a configuração desapareça com o reinicio do servidor.
Atenção: Neste caso, realiza a configura no seu ficheiro de configuração de rede ou cria um ficheiro que será executado no arranque do servidor com os dois comandos anteriores.

Depois, para que o router não receba mais pedidos arp indicando que o ip corresponde a este endereço mac do servidor, desactivamos o arp.

echo "1" > /proc/sys/net/ipv4/conf/all/hidden
echo "1" > /proc/sys/net/ipv4/conf/tunl0/hidden
echo "1" > /proc/sys/net/ipv4/conf/all/arp_ignore
echo "2" > /proc/sys/net/ipv4/conf/all/arp_announce
echo "1" > /proc/sys/net/ipv4/conf/tunl0/arp_ignore
echo "2" > /proc/sys/net/ipv4/conf/tunl0/arp_announce
echo "0" > /proc/sys/net/ipv4/conf/tunl0/rp_filter


Finalemente, activamos os reencaminhamentos ip:
echo "1" > /proc/sys/net/ipv4/ip_forward


Para os serviços geridos pelo balanceador não se esqueça de indicar-lhes de escutar este ip, no caso de uma virtualhost este deve estar declarado como ip IPDIRECTOR.

Para ter uma sincronização dos dados para os servidores no cluster, preconizamos de instalar um filer assim todos os servidores terão os mesmos dados instantaneamente.


Automatização do cluster


O nosso balanceamento de carga funciona mas se uma máquina do cluster vai abaixo, os clientes terão mensagens de erros indicando que o site não se encontra disponível, é precisor retira da pool de servidor. Podemos faze-lo com ldirectord.

Para instalar o ldirectord siga estas instrucções:

yum install ldirectord


depois os módulos seguintes podem pedir uma instalação em função da configuração com ldirectord.
Instalamos cpan para os diferentes módulos seguintes se necessario.

yum install cpan


para verificar o protocolo pop3

cpan install Mail::POP3Client


para verificar um protocolo utilizando o ssl

yum install perl-Net-SSLeay


para verificar o protocolo imap

cpan install Net::IMAP::Simple::SSL


Para verificar o serviço DNS

cpan install Net::DNS


Vamos agora criar um ficheiro de configuração para ldirectord

nano /etc/ha.d/ldirectord.cf


Terá duas grandes partes para o ficheiro de configuração:
  • uma parte global.
  • uma parte para cada serviço.

na parte global:

negotiatetimeout=10


é o prazo em segundos para negociar os controlos.

checktimeout=10


é o prazo em segundos para ligar-se, se o prazo é ultrapassado então o servidor real é declarado morto.

checkinterval=30


Define o número de segundos entre cada controlo por defeito ldirectord põe o valor 10s. No nosso guia, colocamos 30s.

checkcount=10


O número de vezes onde um controlo será atingido antes que ele seja considerado como falhado.

logfile="/var/log/ldirectord.log"


logfile = "/caminho/para/ficheirolog" senão será o ficheiro syslog.
Outro ficheiro log pode ser especificado. Se o ficheiro log não possui um chefe de fila '/', ele é suposto ser syslog.

emailalert="o seu email"


Endereço de e-mail válido para o envio das alertas sobre a mudança do estado de ligação a um servidor real no serviço virtual.

emailalertfreq=3600


Prazo em segundos entre as alertas por email, enquanto qualquer servidor real no serviço virtual está inacessivel. Um valor de zero segundos impede a repetição das alertas.

emailalertstatus=all


que tipo de alertas vamos seguir: aqui todas.

na parte por serviços:

  • o serviço ftp.

É um serviço particular, é perciso um persistência nas ligações para o servidor real.
Atenção: a tabulação é muito importante no ficheiro de configuração (não um espaço mas sim um avanço)

virtual=IPDIRECTOR:21
real=IPR1:21 ipip
real=IPR2:21 ipip
service=ftp
checkport=21
scheduler=lblcr

protocol=tcp
checktype=negotiate
login="cluster"
passwd="passwd"
request="welcome.msg"
receive="200"
checktype=negotiate


É preciso criar um ficheiro welcome.msg no directório do utilizador que se vai criar, especialemente para este teste, com o conteúdo 200. Ldirector vai fazer uma ligação ftp e vai verificar o conteúdo de welcome.msg e comparar-lo ao valor receive.


  • o serviço web

virtual=IPDIRECTOR:80
real=IPR1:80 ipip 1
real=IPR2:80 ipip 2
service=http
request="test.html"
receive="200"
scheduler=wrr
protocol=tcp
checktype=negotiate


virtual=IPDIRECTOR:443
real=IPR1:443 ipip 1
real=IPR2:443 ipip 2
service=https
request="test.html"
receive="200"
scheduler=wrr
#persistent=600
protocol=tcp
checktype=negotiate


O directório vai verificar via protocolo http que a página contem 200.
O ficheiro .html deverá estar no directório correspondente ao virtualhost do endereço do seu servidor.

  • o serviço de e-mail

Para testar este serviço, pode criar um endereço que será utilizado para o teste unicamente.
O exemplo abaixo é a titulo indicativo, a parametrizar conforme as suas necessidades.

virtual=IPDIRECTOR:25
real=IPR1:25 ipip 2
real=IPR2:25 ipip 1
service=smtp
scheduler=wrr
protocol=tcp
checktype=negotiate
checkport=25


virtual=IPDIRECTOR:110
real=IPR1:110 ipip
real=IPR2:110 ipip
service=pop
scheduler=wrr
protocol=tcp
checktype=negotiate
checkport=110
login="cluster@domaine.com"
passwd="passwd"


virtual=87.98.130.38:143
real=IPR1:143 ipip
real=IPR2:143 ipip
service=imap
scheduler=wlc
protocol=tcp
checktype=negotiate
checkport=143
login="cluster@domaine.com"
passwd="passwd"


Se pretender apenas fazer um ping do serviço pode faze-lo colocado de uma forma geral:

virtual=IPDIRECTOR:port
real=IPR1:port ipip
real=IPR2:port ipip
service="type service"
scheduler=wlc
protocol=tcp
checktype=ping
checkport=port


Substitua cada valor no exemplo acima.

Tem outras possibilidades para os serviços mas convidamos-o a verificar a documentação oficial de ldirectord.

Finalmente executamos ldirectord em modo debug para verificar que tudo está a correr bem:
/usr/sbin/ldirectord -d /etc/ha.d/ldirectord.cf start


Verá assim se há mensagens de erros.

depois, para executar ldirectord:
vamos modificar uma linha no ficheiro de arranque de ldirectord

nano /etc/init.d/ldirectord


e comente a linha seguinte pondo um # antes disto:

#. /etc/ha.d/shellfuncs


para arranca-lo utilize o comando:

/etc/init.d/ldirectord start


para pôr ldirectord ao iniciar:

chkconfig --level 35 ldirectord on


ara verificar o seu cluster em tempo real:

watch -n 5 ipvsadlm -l


e para as ligações:

watch -n 5 ipvsadlm -lnc