Clusters de alta disponibilidade (HA - High Availability)

Nesse artigo tratarei sobre a configuração de clusters de alta disponibilidade. Os computadores dessa classe possuem uma disponibilidade de 99,99% a 99,999%, isso significa que em um ano de operação o servidor ficará indisponível por um período de pouco mais de 5 minutos (se ficar).

smurf_o

Por Smurf em 06/10/2009

Hits: 74.373 Categoria: Linux Subcategoria: Configuração

Configurando um cluster de alta disponibilidade para servidor WWW

Essas configurações podem ser feitas facilmente e adaptadas para outros servidores como FTP, e-mail, Samba, banco de dados etc.

Instalações das placas de rede:

O procedimento de instalação de duas placas de rede, para os computadores ha-1.talmeida.com.br e ha-2.talmeida.com.br, que hospedam o cluster de alta disponibilidade. Instalamos duas placas de rede em cada um deles.

Configuração da rede cluster talmeida

As configurações para as placas de rede dos servidores ha-1.talmeida.com.br e ha-2.talmeida.com.br são:

Hostname: ha-1.talmeida.com.br
Endereço IP (eth0): 192.168.1.51
Máscara de rede (eth0): 255.255.255.0
Endereço da rede (eth0): 192.168.1.0
Endereço de broadcast (eth0): 192.168.1.255
Endereço IP (eth1): 10.0.0.1
Máscara de rede (eth1): 255.0.0.0.0
Endereço da rede (eth1): 10.0.0.0
Endereço de broadcast (eth1): 10.255.255.255
Gateway: 192.168.1.1
DNS primário: 192.168.1.2
DNS secundário: 192.168.1.3
Nome do domínio: talmeida.com.br
Hostname: ha-2.talmeida.com.br
Endereço IP (eth0): 192.168.1.52
Máscara de rede (eth0): 255.255.255.0
Endereço da rede (eth0): 192.168.1.0
Endereço de broadcast (eth0): 192.168.1.255
Endereço IP (eth1): 10.0.0.2
Máscara de rede (eth1): 255.0.0.0.0
Endereço da rede (eth1): 10.0.0.0
Endereço de broadcast (eth1): 10.255.255.255
Gateway: 192.168.1.1
DNS primário: 192.168.1.2
DNS secundário: 192.168.1.3
Nome do domínio: talmeida.com.br

Páginas do artigo

   1. Configurando um cluster de alta disponibilidade para servidor WWW
   2. DRBD (Data Replicator Block Device)
   3. Configurando o RSync
   4. Heartbeat

Outros artigos deste autor

Ferramentas de monitoria de tráfego

Leitura recomendada

Configurando DNS (bind9) no Debian Sarge

Emergindo grandes pacotes em hardwares fracos com o auxílio de outro computador no Gentoo Linux

ASP.NET no Linux

Instalação de configuração do RIS para gerenciamento de imagens Ghost no Windows

Apache + Virtual Host + DNS no Debian Lenny

Comentários

#1 Comentário enviado por cleysinhonv em 06/10/2009 - 15:36h

Olá talmeida,

Gostei do artigo, trata-se de um assunto que estamos debatendo aqui no trabalho. Parabéns.

#2 Comentário enviado por diegofsouza em 06/10/2009 - 20:15h

Ótimo artigo... é um assunto muito interessante.

#3 Comentário enviado por Wakky em 09/10/2009 - 09:09h

Cara...
bom artigo...
Tive pensando... a tempo, precisei de implementar uma solução de um servidor de correio, em que haviam 2 sites remotos em diferentes países.
o problema, é que quando o mail no server tentasse ser acedido por um user no SiteB (ligação 512KB partilhada), e se o mail fosse grandinho e a conexão desse um timeout, o cara da direção pegava logo no telefone e desancava aqui no pessoal...
Tive pensando num cluster, e cada mail era acedido localmente,ficando todo o "trabalho" para os servidores.

Penso que essa solução vai ajudar a resolver esse problema.

[]'s

Wakky

#4 Comentário enviado por removido em 18/10/2009 - 21:28h

Bem Explicado.
Continue Assim.

#5 Comentário enviado por removido em 20/10/2009 - 17:22h

O Artigo ficou bom.

Porém posso resaltar que ficaria melhor se fosse implementado o OCFS2 junto do DRBD, com isso poderia trabalhar no esquema master/master sem precisar ficar fazendo a sincronização por script.

O OCFS2 é um sistema de arquivos da Oracle para Cluster ele trabalha muito bem com o DRBD e o HeartBeat e é Livre.

Quando um dos servidores do DRBD parar tem que passar a função de master para o secundário no seu caso.

Se tiver o OCFS2 se um deles parar e o cluster do Heartbeat estiver utilizando o Stonith, o Stonith vai reiniciar o Nodo que estiver com problemas. E o nodo que estiver trabalhando não vai precisar receber a função de primário pois já vai ser.

Para aumentar ainda mais a disponibilidade poderia ser Utilizado o LVS para fazer o balanceamento da carga que serão entregues para os servidores.

E por fim utilizar o Monit para monitorar tudo e mais ele mesmo.

Quando se fala em disponibilidade.

HeartBeat+LVS+MONIT+DRBD+OCFS2

A Melhor solução com Software.

Douglas Q. dos Santos

#6 Comentário enviado por elsonjunior em 24/11/2009 - 09:22h

Opa,

Muito bom artigo.

Estou aprendendo a trabalhar com linux e estou de encarregado de fazer testes para montar um sistema de alta disponibilidade.

Fiquei com dúvida na hora de editar o arquivo /etc/drbd.conf, pois o arquivo é bem mais extenso.
Devo apagar as outras informações dele? Ou adicionar essas daí no final?

Desde já agradeço.

Abraço.

--
Elson Júnior

#7 Comentário enviado por jhugor em 03/05/2010 - 21:56h

caro talmeida

parabens pelo excelente post

nota 10

gostaria de te perguntar o seguinte:

tenho um micro com debian 5.04 e nele instalei o virtualbox, criei uma maquina virtual com 2003 server onde dentro vao softwares
de automacao comercial

as estacoes acessam via terminal service

gostaria de colocar uma segunda maquina com o debian tambem e nela o virtualbox com outro 2003 server dentro

a ideia era replicar os dados da maquina 1 para a 2

voce ve possibilidade

apreciaria muito tua ajuda parceiro!

outra coisa, nao precisa ser exatamente como eu disse, poderia haver no meio, se necessario uma intervencao tecnica, tipo, desligar
o primeiro que deu pau e mudar um ip no segundo, sei la, algo do tipo

agradeco novamente!

abaixo uma pergunta que fiz no forum, talvez eu tenha sido mais completo la!

http://www.vivaolinux.com.br/topico/Virtual-Box-1/Usando-VirtualBox-para-Servidor-e-Cluster-HA