Alta Disponibilidade na Prática utilizando servidores Linux
1. Programas Livres para a Alta
Disponibilidade em Servidores
Hugo
Roger
Cleber
Clauzio
Serviços em Redes de Computadores
Profº João Eriberto Mota Filho
2. Agenda
● Alta disponibilidade
– conceito
– calculo/medida da disponibilidade
– classificação
– ambiente HA
● Programas
– heartbeat
– drbd
– mon
– hapm
● Conclusão
3. Conceito
● HA não é apenas um produto ou
aplicação
● HA é uma característica de sistema
computacional
“A disponibilidade de um sistema
computacional, indicada por A(t), é a
probabilidade de que este sistema
esteja funcionando e pronto para uso
em um dado instante t.”
4. Calculo da disponibilidade
● Variáveis
– MTTF (Tempo médio até apresentar falha)
– MTTR (Tempo médio de reparo)
MTTF
A=
MTTFMTTR
6. Classificação
● A disponibilidade de um sistema
computacional pode ser dividida em
três classes:
– Disponibilidade básica
● 99%
– Alta disponibilidade
● 99,9%; 99,99%; 99,999%...
– Disponibilidade contínua
● 1
7. Ambiente HA
● Hardware: redundância de máquinas,
links, conexão dedicada e de alta
velocidade
● Espelhamento de dados: dados
espelhados em tempo real
● Controle de serviços: o sistema deve ser
autônomo e capaz de reconfigurar-se
● Monitoração: o sistema deve monitorar
seus serviços e disparar uma
reconfiguração em caso de defeitos
9. HeartBeat
● O Heartbeat é um dos componentes do
projeto Linux-HA (High-Availability Linux);
● Roda nas plataformas Linux, FreeBSD e
Solaris;
● Detecta a morte de um 'host' e gerência
cluster.
10. HeartBeat
● Cluster: Alta Disponibilidade;
● Cluster: Balanceamento de Carga;
● Cluster: Alta Performance;
11. HeartBeat
● Segmentos UDP são enviados
regulamente entre os hosts;
● Se o segmento não for recebido;
● Será detectado que um host está com
problema;
● E é tomada uma ação;
12. HeartBeat
● Quando o serviço HeartBeat é iniciado em um
host uma Interface Virtual sobe;
● Essa Interface Virtual será acessada pelos
clientes;
clientes
● Se esse host falhar, então será detectado e a
interface do outro host subirá como o mesmo
IP;
● Um ARP gratuito é enviado para todas
máquinas;
30. DRBD
● Trabalha com journaling file system (ext3, XFS, JFS,
etc...)
● Possui 3 protocolos de integridade dados
● Master/Slave, somente um sistema pode
lêr/escrever em um determinado tempo
● Quando o servidor master falha o servidor slave
assume
● Possui mecanismo de “resync” inteligente
● Necessário integração com Heartbeat
32. DRBD
● Instalação
tar -zxvf drbd-8.0.4.tar.gz
cd drbd-0.8.0.4/drbd
make clean all; make; make install
● Configuração
carrega módulo no kernel (modprobe drbd)
cria dispositivo drbd (mknod /dev/drbd0 b 147; mkfs.ext3 /dev/drbd0)
configura drbd.conf e inicia o serviço (init.d/drbd start)
configura servidor drbd primario no master (drbdadmin primary all)
sincroniza discos (drbdadmin –overwrite-data-of-peer primary all)
monta disco no servidor master (mount -t ext3 /dev/drbd0 /ha_backup)
33. DRBD
# drbd.conf (deve ser copiado nos 2 servidores)
resource drbd0 { #primeiro espelhamento
protocol=C #protocolo usado (A-B-C)
fsck-cmd=fsck.ext2 -p -y #se necessário
disk { #dados do disco
do-panic #se erro, um kernel panic para
maquina
disk-size=4096543 #se discos não iguais
}
on server1 { #primeiro nodo
device=/dev/drbd0 #dispositivo de drbd
disk=/dev/hda3 #dispositivo de bloco
address=192.168.1.2:7789 # endereço IP/porta
}
on server2 { #primeiro nodo
device=/dev/drbd0 #dispositivo de drbd
disk=/dev/hda3 #dispositivo de bloco
address=192.168.1.3:7789 #endereço IP/porta
}
34. DRBD
# haresources (arquivo de configuração do heartbeat)
server1 192.168.1.4 drbddisk Filesystem::/dev/drbd0::/ha_backup::ext3 servicos
onde:
server1 #servidor master
192.168.1.4 #ip virtual
drbddisk #torna o dispositivo como primário
Filesystem::/dev/drbd0::/ha_backup::ext3 #monta file system
servicos #inicia em ordem os servicos
que utilizam o file system
36. MON - ?
● É uma ferramenta para monitorar a
disponibilidade dos serviços e enviar alertas,
● Desenvolvido e mantido por Jim Trocki(Unisys)
● GNU GLP,
● Simples, contudo muito adaptável aos projetos,
● Simples de adicionar alertas e monitores,
● Quando um alerta é dado, os dados são
recolhidos para a da geração de relatório de
uso geral,
● Propósito Geral: se você pode testar com
software, você pode monitorá-lo.
37. MON - Características
● Portátil (escrito em Perl),
● Linux, Solaris, Cygwin (Windows),
● Pode monitorar vários servidores,
● Configurável, extensível, integra com outros
sistemas,
● Os arquivos de configuração são feitos de
acordo com as outras ferramentas que irá
intergrar.
41. MON - Funções
● Servidor
- Programação e execução dos
monitores(quando necessário),gerência
alertas(envia alertas durante períodos
específicos), logs, aceita traps remotos,
● Clientes
- Pergunta e controla o servidor, mostrar
relatórios
42. MON - Funções
● Monitores
- Testa a condição de um serviço
- Os testes são definidos pelos usuários,
- Possibilita teste em nível de aplicação,
- Comunica com os sistemas monitorados
através do HTTP, do SNMP, etc.
● Trap
- Emiti notificações para o servidor mon
ou para outras entidades externas,
43. MON - Funções
● Alertas
- Executar ações em casos de falhas, em
servidor de pagina, de email, na ação
corretiva (HA fail-over), etc.
- Chama processos separadamente,
- Simples de escrever,
45. MON - Comandos
● mon - monitorar os serviços para a
disponibilidade, emitindo alarmes em cima das
falhas.
● moncmd - emitir comandos ao daemon do mon
e mostrar os resultados.
● monshow - mostrar o status operacional do
usuário do mon.
47. HAPM
● Desenvolvido por Alexandre Antônio, João Eriberto e
Rosemeri Dantas
● Verifica status de portas TCP/UDP (nó Master)
● Trabalha com o daemon Heartbeat
48. HAPM
# hapm.conf
socket=127.0.0.1:25 # ip e porta do serviço a ser monitorado
socket=10.0.0.1:80
socket=10.0.0.1:22
time=1 # intervalo entre as checagens
heartbeat=/etc/init.d/heartbeat # daemon do heartbeat
49. CONCLUSÃO
Como pôde ser visto neste trabalho é possível ter um sistema de
alta disponibilidade baseado em ferramentas open-source, sem
gastar muito dinheiro no quesito software.
Um fator muito importante que se deve levar em consideração
durante a implantação de um servidor de alta disponibilidade é
justamente o custo x beneficio,
quando maior o grau de disponibilidade maior será o recurso
financeiro necessário para implementação de tal.