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 Falha Possível Solução Rede Elétrica Queda Total ou Parcial da Energia Implementação de um UPS (Uninterruptible Power Supply) e geradores de energia Rede de Dados Inoperância de ativos de rede (placas de rede, switch) elétrica Redundância de placas de redes com uso de bonding e uso de switches com stacking e suporte a 802.3ad Hardware Problemas na fonte de Redundância de fonte alimentação (Hotswap) Hardware Falha no disco Utilziar RAID (nível de
software ou hardware) Software Falha de sistemas/apps Redundância de sistemas/app Software Corrupção no Sistema Redundância de Hardware/Software DataCenter Operacional Falha completa no servidor (memória, processador, discos, SO, etc) Desastres Naturais/ Incidentes criminosos 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) Editar o arquivo /etc/sysconfig/networkt-scripts/ifcfg-eth1, e deixar 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) Editar o arquivo /etc/sysconfig/networkt-scripts/ifcfg-eth1, e deixar 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 esperar por bits atrasados warntime 5
# 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 em: <http://www.vivaolinux.com.br/dica/heartbeat-web-server-com-alta- Disponibilidade-%28HA%29> Acesso em: 15 Agos. De 2011.