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: 72.945 ]

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

Stalonetray - Um system tray provisório para o Plasma 5

Ubuntu Multimídia com Studio

Como selecionar que processos serão iniciados ao boot - sysv-rc-conf

Integrando Nagios com Asterisk

CentOS - Pós-instalação básica

  
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