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).

[ Hits: 73.107 ]

Por: Smurf em 06/10/2009


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

    Próxima página

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

Instalação completa do CACIC no Slackware 12.2

Instalação do modem Netodragon no Conectiva 10

Fazendo RSH sem senha

VMware VCenter Converter - Convertendo Máquinas Físicas em Virtuais

Instalar o Slackware 14.1 em drive USB

  
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


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts