Lucas de Stefano Shida - R.A: 723517-8
Lilian Medeiros - R.A: 666993-0
Rafael Torato Rocha - 612395-3
Renata Ferro – R.A: 775438-8
Ronaldo A. Barbosa - R.A: 772272-9
Clusters de Alta Disponibilidade
CAMPINAS – 2011
RESUMO
Viemos com esse trabalho passar uma noção melhor do que é um
cluster (principalmente clusters de alta disponibilidade), como é seu
funcionamento, implementação utilizando o HeartBeat.
Palavras-Chaves: Cluster, Alta Disponibilidade, HeartBeat
1. INTRODUÇÃO
Devido a grande necessidade de se manter os serviços sempre ativos,
sem falhas e no ar durante a maior parte do tempo é necessário a
implementação de um serviço que garante essa possibilidade, então, surgemse os Clusters de Alta Disponibilidade, que é o nosso foco nesse trabalho. Este
trabalho baseia-se no artigo Cluster de Alta Disponibilidade [1] e quando
houver outras citações as mesmas estarão devidamente referenciadas.
2. O QUE SÃO CLUSTERS?
Podemos definir cluster como um sistema que compreende dois ou mais
computadores ou sistemas, denominados nós, que trabalham em conjunto para
realizar as tarefas, dando assim, a impressão de ser um só equipamento.
2.1 Para que se utilizar um Cluster?
Os clusters são utilizados quando se há a necessidade de processar
dados críticos e/ou a disponibilização de serviços/recursos durante a maior
parte do tempo.
3. TIPOS DE CLUSTER
Existem
basicamente
quatro
tipos
de
cluster,
que
são:
Alta
disponibilidade (High Availability ou HA and Failover), Balanceamento de Carga
(Load Balance), Combinação Alta disponibilidade e Balanceamento de carga
(HA & Load Balance) e Processamento distribuído ou Processamento Paralelo
(HPC).
3.1 Clusters de Alta Disponibilidade
Os clusters de alta disponibilidade são construídos para prover grande
disponibilidade de serviços e recursos de maneira interrupta. Se um nó do
cluster falhar, os serviços, dados, aplicações, etc., estarão disponíveis no outro
nó.
3.2 Balanceamentos de Carga
Os clusters de balanceamento de carga distribuem o tráfego ou
requisições
de
recursos
entre
os
nós
que
executam
os
mesmos
programas/serviços e caso haja falha de um nó, é feita a redistribuição de
carga.
3.3 Combinação Alta disponibilidade e Balanceamento de Carga
Combina os dois tipos de clusters apresentados acima, aumentando a
disponibilidade e escalabilidade dos serviços e recursos.
3.4 Processamento distribuído ou Processamento Paralelo
Utilizados em computação cientifica ou analise financeira, onde tarefas
típicas exigem um alto poder de processamento, uma grande tarefa pode ser
dividida em pequenas tarefas que são distribuídas entre os nós, aumentando
assim a disponibilidade e o desempenho, um exemplo é o projeto Beowulf da
NASA.
4. CLUSTERS DE ALTA DISPONIBILIDADE
Conforme vimos anteriormente os clusters de alta disponibilidade são
construídos para prover grande disponibilidade de serviços e recursos de
maneira interrupta. A Alta Disponibilidade se da a diversos fatores que
garantem tal fato, onde é empregada a seguinte fórmula:
Disponibilidade = Tempo médio entre falhas / (Tempo médio entre
falhas + tempo médio para realização do reparo)
4.1 Funcionamento e Implementação
Como funciona um cluster? Como é feito o failover (a virada dos
recursos/tarefa)? Para isso utilizamos no Linux um sistema chamado Heartbeat
que é o responsável pela parada e o inicio de serviços nos nós do cluster, e o
DRBD, que fica responsável em manter os HDs dos servidores sincronizados,
como uma espécie de RAID 1 via rede. Quando o servidor 1 para, o hd do
servidor 2 assume o papel de hd primário e quando o servidor 1 volta, o mesmo
volta a ser o hd secundário, lembrando que, toda essa mudança de serviços
tem que ser transparente para o usuário.
Na questão de hardware. Todos servidores devem ter no mínimo 2
placas de rede, uma que estará ligada através de um switch para acesso a
rede/internet e outra que estará ligada diretamente ao outro nó do cluster
através de um cabo de rede crossover, que é essa a interface que será
monitorada pelo HeartBeat. Logo a frente, explicaremos como é feita a
configuração do HeartBeat em um servidor Linux.
Agora vamos lá, o que levaria um nó do cluster a parar? Há vários
motivos como, por exemplo, os descritos na tabela abaixo.
Tipo de Falha
Rede Elétrica
Falha Possível
Queda Total ou Parcial
da Energia
Rede de Dados
Inoperância de ativos de
rede (placas de rede,
switch)
Hardware
Problemas na fonte de
alimentação
Falha no disco
Hardware
Solução
Implementação de um
UPS (Uninterruptible
Power Supply) e
geradores de energia
elétrica
Redundância de placas
de redes com uso de
bonding e uso de
switches com stacking e
suporte a 802.3ad
Redundância de fonte
(Hotswap)
Utilziar RAID (nível de
Software
Falha de sistemas/apps
Software
Corrupção no Sistema
Operacional
Falha completa no
servidor (memória,
processador, discos,
SO, etc)
Desastres Naturais/
Incidentes criminosos
Hardware/Software
DataCenter
software ou hardware)
Redundância de
sistemas/app
Redundância de
servidores
Redundância de
servidores
Redundância de
DataCenters
5. HEARTBEAT
Como dito anteriormente, o HeartBeat é uma daemon que monitora o
status dos servidores através da emissão de um “pulso” que avisa ao nó
secundário que o primário está ativo.
Mostraremos a seguir (em texto e na Figura 1), como se deve configurar
os 2 servidores (ambos utilizando Linux, no caso do exemplo, CentOS 5.5) e
terem a MESMA configuração. [2]
•
Primeiramente, devemos instalar o pacote:
$yum
install
heartbeat
(Yum
=
gerenciador
de
instalação/atualização/remoção de pacotes em distribuições
baseadas em RedHat) pois estamos usando o CentOS).
•
Configuração da Rede no servidor master:
Interface
de
LAN
(eth0)
–
Editar
o
arquivo
/etc/sysconfig/network-scripts/ifcfg-eth0, e deixar conforme o
abaixo (logico que, as regras de IP atribuem-se somente o
exemplo, devendo-se utilizar a configuração de ips de acordo com
a sua rede).
$ vi /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=static
IPADDR=192.168.10.100
NETMASK=255.255.255.0
ONBOOT=yes
Interface
do
Heartbeat
(eth1)
–
/etc/sysconfig/networkt-scripts/ifcfg-eth1,
Editar
e
o
deixar
arquivo
conforme
abaixo:
$ vi /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
BOOTPROTO=static
IPADDR=10.0.0.1
NETMASK=255.0.0.0
ONBOOT=yes
•
Configuração de rede no servidor slave.
Interface
de
LAN
(eth0)
–
Editar
o
arquivo
/etc/sysconfig/network-scripts/ifcfg-eth0, e deixar conforme o
abaixo (logico que, as regras de IP atribuem-se somente o
exemplo, devendo-se utilizar a configuração de ips de acordo com
a sua rede).
$ vi /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=static
IPADDR=192.168.10.101
NETMASK=255.255.255.0
ONBOOT=yes
Interface
do
Heartbeat
(eth1)
–
/etc/sysconfig/networkt-scripts/ifcfg-eth1,
Editar
e
deixar
o
arquivo
conforme
abaixo:
•
$ vi /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
BOOTPROTO=static
IPADDR=10.0.0.2
NETMASK=255.0.0.0
ONBOOT=yes
Depois de ter instalado o HeartBeat, será criado o diretório /etc/ha.d/,
que é o diretório de configuração do heartbeat. Dentro desse diretório há o
arquivo ha.cf (caso não tenha, deve ser criado), pois é o arquivo onde são
definidas todas as configurações do heartbeat
Exemplo de um arquivo de configuração ha.cf
# Arquivo de log de Debug:
debugfile /var/log/ha-debug
# Arquivo de Log
logfile /var/log/ha-log
# Usa o próprio heartbeat como daemon de log
logfacility daemon
# Frequência em segundo(s) de batimentos cardíacos
keepalive 1
#Tempo mínimo para declarar o outro servidor como morto
deadtime 10
# Quanto tempo o heartbeat deve
warntime 5
esperar por bits atrasados
# Tempo máximo para declarar o outro servidor como morto
initdead 120
# Porta de sincronia do heartbeat
udpport 694
# Endereço de broadcast da rede - usada para setar o endereço primário
do servidor
bcast eth2
# Determina se o serviço volta para o master caso ele volte a responder.
auto_failback on
# Nós do cluster devem ser escritos conforme a saída do comando
#uname –n
node webserver1
node webserver2
# Endereço ip em comum para testes de conectividade
ping (ex. router do servidor web)
# Plugin que auxilia no monitoramento de conexões entre a rede
respawn hacluster /usr/lib/heartbeat/ipfail
# Se usa o syslog ou não
use_logd off
# Compactação de dados
compression bz2
# Compactação de dados
compression_threshold 2
Depois de configurar o arquivo, ha.cf deve-se criar um arquivo
(haresources) onde conterá o hostname do servidor master, seu ip e o serviço
monitorado pelo mesmo, conforme exemplificado abaixo (o script para
monitoramento do apache fica em /etc/ha.d/resource.d/):
webserver1
10.0.0.1 apache
Ao concluir a configuração, deve-se criar o arquivo de autenticação dos
dois nós (edite o arquivo /etc/ha.d/authkeys)
auth 1
1 md5 <coloque a senha aqui>
Pronto, seu HeartBeat está configurado.
6. CONSIDERAÇÕES FINAIS
Esperamos que com esse artigo, possamos esclarecer as duvidas
referentes a clusters, de como funcionava, de como tudo era migrado para o
outro nó, que aplicativo usar para isso,etc.
7. REFERÊNCIAS BIBLIOGRÁFICAS
[1] REIS, Adrieli Cristiane de Freitas et al. CLUSTER DE ALTA
DISPONIBILIDADE .
Guaratinguetá.
Disponível
em:
<http://www.4learn.pro.br/guarino/sd/HA.pdf> Acesso em: 15 Agos. De 2011.
[2] PEREIRA, Michel. HEARTBEAT – WEB SERVER COM ALTA
DISPONIBILDIADE
(HA).
Goiânia:
2009.
Disponivel
<http://www.vivaolinux.com.br/dica/HeartBeat-Web-server-com-AltaDisponibilidade-%28HA%29> Acesso em: 15 Agos. De 2011.
em: