Embed Size (px)
DESCRIPTION
Alta disponibilidade é uma técnica que consiste na configuração de dois ou mais computadores para que eles passem a trabalhar em conjunto. Desta forma, cada maquina monitora as demais e, em caso de falhas, assume os serviços que ficaram indisponíveis.
Citation preview
1
UNIRON – UNIÃO DAS ESCOLAS SUPERIORES DE RONDÔNIA
CÂMPUS III DE PORTO VELHO
PÓS-GRADUAÇÃO DE SEGURANÇA DE REDES E SISTEMAS COMPUTACIONAIS
JORGE WILLIANS DA SILVA BATISTA
CLUSTER DE ALTA DISPONIBILIDADE EM SISTEMAS LINUX COM AS FERRAMENTAS: DRBD, HEARTBEAT E MON
PORTO VELHO 2010
2
JORGE WILLIANS DA SILVA BATISTA
CLUSTER DE ALTA DISPONIBILIDADE EM SISTEMAS LINUX COM AS FERRAMENTAS: DRBD, HEARTBEAT E MON
Trabalho de Conclusão de apresentado ao Curso de Pós-Graduação em Segurança de Redes e Sistemas Computacionais da UNIRON – União das Escolas Superiores de Rondônia, como requisito à obtenção do título de Especialista.
Orientadora: Prof. Esp. Carilene Coelho de Souza Campos
PORTO VELHO
2010
3
JORGE WILLIANS DA SILVA BATISTA
CLUSTER DE ALTA DISPONIBILIDADE EM SISTEMAS LINUX COM AS
FERRAMENTAS: DRBD, HEARTBEAT E MON
Trabalho de Conclusão de apresentado ao Curso de Pós-Graduação em Segurança de Redes e Sistemas Computacionais da UNIRON – União das Escolas Superiores de Rondônia, como requisito à obtenção do título de Especialista.
_________________________________________________________________
Prof. Esp. Carilene Coelho de Souza Campos UNIRON – União das Escolas Superiores de Rondônia
PORTO VELHO 2010
4
Dedico aos meus pais,
irmãos, esposa e
amigos, companheiros
de todas as horas.
5
AGRADECIMENTOS
Gostaria de agradecer aos meus pais e minha esposa que contribuíram na conclusão de mais uma jornada em minha vida, pois sem o apoio deles não teria chegado até aqui.
6
RESUMO
Cluster pode ser definido como um sistema onde dois ou mais computadores trabalham de maneira conjunta para realizar grandes processamentos. Em outras palavras, os computadores dividem as tarefas de processamento e trabalham como se fossem um único computador; Quando se fala de Disponibilidade, fala-se do tempo em que determinado sistema permanece ativo e em condições de uso. A Alta Disponibilidade se refere a sistemas que praticamente não param de funcionar. Esses tipos de clusters são usados em aplicações de missão crítica, eles costumam ter meios eficientes de proteção e de detecção de falhas; Usando o Linux a alguns software gratuitos, que dentre eles, destacam-se o Drbd, Heartbeat e o Mon, que são distribuído sob licença GPL (sem limitações), você verá que é possível criar um ambiente com ótima redundância à falhas. Tudo isso de forma transparente aos usuários da rede. Nesta artigo será mostrado a instalação e configuração destas ferramentas em sistemas Debian e derivados, bem como os resultados obtidos na implementação de um estudo de caso onde será implantado Alta Disponibilidade em um servidor de arquivos samba.
Palavras-chave: Drbd. Heartbeat. Mon. Alta Disponibilidade. Cluster.
ABSTRACT
Cluster can be defined as a system where two or more computers work jointly to achieve large throughputs. In other words, the computers share the processing tasks and work like a single computer; When it comes to availability, talks about the time that a system remains active and in working condition. High Availability refers to systems that almost do not stop working. These types of clusters are used in mission critical applications, they usually have efficient means of protection and fault detection; Using Linux to some free software, which among them are highlighted DRBD, Heartbeat and Mon, which are distributed under GPL license (without limitation), you'll see that you can create an environment with optimal redundancy fault. All this transparently to network users. This article will show the installation and configuration of these tools on Debian systems and derivatives, as well as the results achieved in implementing a case study which will be deployed in a High Availability Samba file server.
Keywords: Drbd. Heartbeat. Mon. High Availability. Cluster.
7
SUMÁRIO
1 INTRODUÇÃO........................................................................................................10
2 DEFINIÇÃO DE CLUSTER.....................................................................................11
2.1 TIPOS DE CLUSTER SUAS APLICAÇÕES.........................................................11
2.1.1 Cluster de Alta Disponibilidade.....................................................................11
2.1.2 Cluster de Balanceamento de Carga............................................................12
2.1.3 Combinação HA & Load Balancing..............................................................12
2.1.4 Cluster de Processamento Paralelo.............................................................12
3 ALTA DISPOMIBILIDADE..................................................................................….13
3.1 CONCEITOS........................................................................................................13
3.2 TIPOS DE ALTA DISPONIBILIDADE....................................................................14
3.2.1 Disponibilidade Básica..................................................................................14
3.2.2 Alta Disponibilidade.......................................................................................14
3.2.3 Disponibilidade Continuada..........................................................................15
4 FERRAMENTAS UTILIZADAS...............................................................................16
4.1 HEARTBEAT........................................................................................................16
4.2 DRBD...................................................................................................................17
4.3 MON ….................................................................................................................19
5 ESTUDO DE CASO: CONFIGURAMDO UM SERVIDOR SAMBA COM H.A.......19
5.1 HARDWARE NECESSÁRIO.................................................................................20
5.2 CONFIGURAÇÕES DOS SERVIDORES.............................................................21
5.3 INSTALAÇÃO DOS SOFTWARE NECESSÁRIOS...............................................22
5.4 CONFIGURANDO DRBD......................................................................................23
5.5 CONFIGURANDO HERATBEAT...........................................................................29
5.6 CONFIGURANDO MON........................................................................................30
5.7 CONFIGURANDO SAMBA..................................................................................31
6 TESTANDO A SOLUÇÃO.......................................................................................32
7 CONSIDEREÇÕES FINAIS....................................................................................35
REFERÊNCIAS..........................................................................................................36
8
LISTA DE FIGURAS
Figura 1 Cluster de Computadores.........................................................................11
Figura 2 Heratbeat...................................................................................................16
Figura 3 DRBD.........................................................................................................18
Figura 4 Cluster de Alta disponibilidade...............................................................21
9
LISTA DE TABELAS
Tabela 1 Medindo a disponibilidade de um servidor.............................................14
Tabela 2 Configuração dos hosts...........................................................................33
10
1 INTRODUÇÃO
O Atualmente as empresas precisam prover serviços ininterruptos. Torna-se
vital para qualquer empresa que deseja manter-se competitiva no mercado possuir
uma estratégia envolvendo alta disponibilidade para os seus servidores de aplicação
e, estar preparada para uma falha de hardware ou software inesperada.
Alta disponibilidade é uma técnica que consiste na configuração de dois ou
mais computadores para que eles passem a trabalhar em conjunto. Desta forma,
cada maquina monitora as demais e, em caso de falhas, assume os serviços que
ficaram indisponíveis. A esse tipo de agrupamento de computadores damos o nome
de cluster de alta disponibilidade (não confunda com cluster de alto desempenho, do
tipo Beowulf, que distribuem o processamento entre várias CPUs).
Mas antes de continuar, é necessário desmitificar as soluções de alta
disponibilidade, há um tempo atrás, quando falava-se de um ambiente de alta
disponibilidade já se pensava nos custos envolvidos para a construção desse
ambiente. Podemos afirmar que os valores já foram extremamente altos, Porem
essa situação se alterou, quando foram desenvolvidas soluções de baixo custo que
suprirão a necessidade do Linux preparando-o para tal. Grupos de desenvolvedores
deram inicio a vários projetos open-source para pesquisarem tais soluções, como
resultado disso, surgiram vários projetos, dentre eles o Drbd, o Heartbeat e o Mon,
que tiveram a capacidade de solucionar problemas de disponibilidade de serviço,
replicação e monitoramento de serviços.
No que diz respeito a parte de software está artigo aborda os seguintes
programas: o Drbd, o Heartbeat e o Mon. O Drbd tem como principal finalidade a de
estar replicando as informações de um servidor em outro, utilizando como meio de
transmissão a rede. O Heartbeat é responsável pela verificação e tomada de
decisões. O Mon é responsável pelo monitoramento dos serviços e enviar, caso
configurado, informações ao Heartbeat.
11
2 DEFINIÇÃO DE CLUSTER
Na sua forma mais básica um cluster é um sistema que compreende dois ou
mais computadores ou sistemas (denominados nodos) na qual trabalham em
conjunto para executar aplicações ou realizar outras tarefas, de tal forma para que
os usuários que os utilizam tenham a impressão que somente um único sistema
responde para eles, criando assim uma ilusão de um recurso único (computador
virtual). Este conceito é denominado transparência do sistema. Como características
fundamentais para a construção destas plataformas inclui-se elevação da: confiança,
distribuição de carga e performance.
Figura 01: Cluster de Computadores
Fonte: http://rmagalhaess.br.tripod.com/
2.1 TIPOS DE CLUSTER E SUAS APLICAÇÕES
2.1.1 Cluster de Alta Disponibilidade
Estes modelos de clusters são construídos para prover uma disponibilidade
de serviços e recursos de forma ininterruptas através do uso da redundância
implícitas ao sistema. A ideia geral é que se um nó do cluster vier a falhar (failover),
aplicações ou serviços possam estar disponíveis em outro nó. Estes tipos de cluster
12
são utilizados para base de dados de missões críticas, correio, servidores de
arquivos e aplicações.
2.1.2 Cluster de Balanceamento de carga
Este modelo distribui o tráfego entrante ou requisições de recursos
provenientes dos nodos que executam os mesmos programas entre as máquinas
que compõem o cluster. Todos os nodos estão responsáveis em controlar os
pedidos. Se um nó falhar, as requisições são redistribuídas entre os nós disponíveis
no momento. Este tipo de solução é normalmente utilizado em fazendas de
servidores de web (web farms).
2.1.3 Combinação HA & Load Balancing
Como o próprio nome diz combina as características dos dois tipos de cluster,
aumentando assim a disponibilidade e escalabilidade de serviços e recursos. Este
tipo de configuração de cluster é bastante utilizado em servidores de web, mail,
news ou ftp.
2.1.4 Cluster de Processamento Paralelo
Este modelo de cluster aumenta a disponibilidade e performance para as
aplicações, particularmente as grandes tarefas computacionais. Uma grande tarefa
computacional pode ser dividida em pequenas tarefas que são distribuídas ao redor
das estações (nodos), como se fosse um supercomputador massivamente paralelo.
É comum associar este tipo de cluster ao projeto Beowulf da NASA. Estes clusters
são usados para computação cientifica ou análises financeiras, tarefas típicas para
exigência de alto poder de processamento.
13
3 ALTA DISPONIBILIDADE
3.1 CONCEITOS
Segundo (FILHO, 2002) primeiramente, é necessário compreender que a
redundância de recursos é um pré-requisito para se atingir um alto grau de
disponibilidade.
Lembrando que as falhas não são restritas somente aos hardwares, mas tam-
bém à redes de computadores, às redes elétricas e à localização dos recursos.
No que diz respeito a redes de computadores, deve ser levar em
consideração os hubs, switchs, cabos, roteadores e todos equipamento físico de
uma rede.
Já com relação as redes elétricas deve se entender que qualquer tipo de
oscilação ou indisponibilidade do serviço deve ser suprima por outra forma de
geração de energia, como no-break e até mesmo geradores.
E finalmente com relação a localização física do recursos deve-se sempre
lembrar que um local está propício a furacões, enchentes, terremotos, roubos e até
mesmo ataques terroristas, então é importante sempre ter equipamentos em locais
distinto, onde na falta de um o outro o supra, de forma que não pare o serviço.
Então, quando se diz que um sistema é de alta disponibilidade, este sistema
deve envolver não somente uma simples redundância de recursos, mas sim toda
uma estrutura que o suporte. Pode ser visto que quanto maior o grau de
disponibilidade, maior será o custo para tal.
Um fator que deve ser levando em consideração em um sistema de alta
disponibilidade é como medir a disponibilidade dos serviços. Para tal deve ser
levado em consideração o tempo em que o serviços ficam ativos e quanto tempo o
serviços ficam foram do ar.
Para se calcular a disponibilidade de um sistemas, basta utilizar a seguinte
fórmula, conforme disse (GUNDA; TECHNOLOGIES, 2001):
TA − TD
AD = X100
TA
Onde AD = Alta disponibilidade, TA = Total de horas por ano Ativo e TD = Total
de horas por ano Desativado.
14
A tabela 1 é apresentada uma visão de classificação da disponibilidade
segundo (RUSSEL et al., 2001).
Tabela 1: Medindo a disponibilidade de um servidor Fonte: Russel et. al., 2001
3.2 TIPOS DE ALTA DISPONIBILIDADE
3.2.1 Disponibilidade Básica
A Disponibilidade básica é aquela encontrada em máquinas comuns, sem
nenhum mecanismo especial, em software ou hardware, que vise de alguma forma
mascarar as eventuais falhas destas máquinas. Costuma-se dizer que máquinas
nesta classe apresentam uma disponibilidade de 99% a 99,9%. Isto equivale a dizer
que em um ano de operação a máquina pode ficar indisponível por um período de 9
horas a quatro dias. Estes dados são empíricos e os tempos não levam em
consideração a possibilidade de paradas planejadas (que serão abordadas mais
adiante), porém são aceitas como o senso comum na literatura da área (SZTOLTZ,
2003).
3.2.2 Alta Disponibilidade
Adicionando-se mecanismos especializados de detecção, recuperação e
mascaramento de falhas, pode-se aumentar a disponibilidade do sistema, de forma
que este venha a se enquadrar na classe de alta disponibilidade. Nesta classe as
máquinas tipicamente apresentam disponibilidade na faixa de 99,99% a 99,999%,
15
podendo ficar indisponíveis por um período de pouco mais de 5 minutos até uma
hora em um ano de operação. Aqui se encaixam grande parte das aplicações
comerciais de alta disponibilidade, como centrais telefônicas (SZTOLTZ, 2003).
3.2.3 Disponibilidade Continuada
Com a adição de noves se obtém uma disponibilidade cada vez mais próxima
de 100%, diminuindo o tempo de inoperância do sistema de forma que este venha a
ser desprezível ou mesmo inexistente. Isso é a disponibilidade contínua, o que
significa que todas as paradas planejadas e não planejadas são mascaradas, e o
sistema está sempre disponível.
Como já pode ser percebido de sua definição, o principal objetivo da alta
disponibilidade é buscar uma forma de manter os serviços prestados por um sistema
a outros elementos, mesmo que o sistema em si venha a se modificar internamente
por causa de uma falha; Esse é o conceito de mascaramento de falhas, através de
redundância ou replicação. Um determinado serviço, que se quer altamente
disponível, é colocado por trás de uma camada de abstração, que permita mudanças
em seus mecanismos internos mantendo intacta a interação com elementos
externos.
Este é o coração da alta disponibilidade, uma sub-área da tolerância a falhas,
que visa manter a disponibilidade dos serviços prestados por um sistema
computacional, através da redundância de hardware e reconfiguração de software.
Vários computadores juntos agindo como um só, cada um monitorando os outros e
assumindo seus serviços caso perceba que algum deles falhou.
Outra possibilidade importante da alta disponibilidade é fazer isto com
computadores básicos, como os que se pode comprar até num supermercado. A
complexidade pode estar apenas no software. Mais fácil de desenvolver que o
hardware, o software de alta disponibilidade é quem se preocupa em monitorar
outras máquinas de uma rede, saber que serviços estão sendo prestado, quem os
está prestando, e o que fazer quando uma falha é percebida (SZTOLTZ, 2003).
16
4 FERRAMENTAS UTILIZADAS
4.1 HEARTBEAT
O programa Heartbeat é usado para construir cluster da altíssima
disponibilidade; Heartbeat significa batimento cardíaco. Este termo é usado para
definir o pulso enviado entre duas máquinas, indicando que estão “vivas”, ou seja,
estão funcionando e disponíveis para executarem tarefas. Se o Heartbeat falhar, a
máquina secundária assumirá que a primária falhou e tomará para si os serviços que
estavam sendo executados na máquina primária (TRIGO, 2007); ver figura abaixo
Figura 02: Heartbeat Fonte: Autor
A comunicação entre os servidores pode ser feita em broadcast, multcast ou
unicast; Esta escolha depende da aplicação que será dada ao Heartbeat. No
entanto, se o servidor primário estiver ligado apenas ao servidor de backup, é
aconselhável utilizar o unicast, por enviar um pacote único e, assim, evitar
congestionamento da rede (TRIGO, 2007).
A configuração do Heartbeat consiste em três arquivos:
ha.cf: configuração dos computadores envolvidos e o meio de comunicação
utilizado entre os nodos.
haresources: configura o endereço IP do cluster e o grupo de serviços que
serão executados preferencialmente em cada um dos nodos.
authkeys: armazena a autenticação necessária entre os dois nodos.
17
O Heartbeat deverá ser instalado em ambos os servidores e todos os arquivos
devem estar iguais nos dois nodos; É possível configurar o tempo entre os
Heartbeats, o tempo de alerta no caso do Heartbeat não chegar a tempo e o tempo
em que se considera o nodo como morto;
O Heartbeat utiliza a porta 694 para a comunicação bcast ou ucast. Existe
uma opção chamada auto _failback que nos permite escolher entre on e off, isto é,
quando pusermos o auto_failback a on, quando o nodo primário voltar de uma falha
qualquer, ele volta a tomar controle do cluster, enquanto que em off o nodo primário
é prevenido para readquirir o controle do cluster (HEARTBEAT, 2008).
O Heartbeat funciona através de um IP virtual que identifica o cluster, este IP
está associado a um domínio. Quando o nodo primário falhar, o nodo secundário
assume o IP virtual, ou seja, o IP do cluster. Isso vai permitir continuar com o
funcionamento dos serviços que estavam a ser usados pelo nodo primário com o
mesmo domínio (HEARTBEAT, 2008).
O funcionamento do Heartbeat é apresentado na Figura 4. Uma vez a
conexão estabelecida, começa o processo dos Heartbeats. Quando há um Heartbeat
perdido, vem juntamente com ele uma tentativa de reconexão, dessa tentativa duas
hipóteses é tomada em conta. A primeira hipótese é o caso da tentativa permitida e
então pode acontecer que a conexão seja restabelecida ou perdida. A segunda
hipótese é o caso da tentativa inválida e daí, só há uma saída que é a conexão
perdida. A chamada conexão terminada acontece quando se decide desconectar ou
quando a conexão é perdida (HEARTBEAT, 2008).
4.2 DRBD
O DRBD (Distributed Replicated Block Device) é o software que realiza a
replicação de dados entre os nós do cluster, fazendo o espelhamento (mirroring) de
um dispositivo de blocos através de uma conexão de rede dedicada. Ele pode ser
entendido como um RAID 1 via rede, onde recebe os dados a serem
gravados,escreve no disco local e os envia para o outro computador, onde os dados
também são gravados no disco, a figura 2 ilustra o que é descrito acima:
18
Fgura 03: DRBD
Fonte: http://community.zenoss.org/servlet/JiveServlet/showImage/102-2485-2-64/image_preview.png
O DRBD cria um dispositivo de armazenamento que, na verdade, estará dis-
tribuído nos dois servidores que compõe o cluster. O dispositivo DRBD trabalha em
uma camada superior aos dispositivos de bloco usados para armazenamento (disco
local) dos computadores do cluster. Sempre que um nó gravar no dispositivo DRBD,
as alterações serão gravadas no disco local, e serão replicadas para o outro nó em
tempo real.
Cada dispositivo DRBD tem um estado, que pode ser primário ou secundário.
O dispositivo primário fica no nó principal, onde a aplicação está executando e tem
acesso ao dispositivo DRBD (/dev/drbdX). Todo acesso ao disco passa a ser feito
através deste dispositivo. Quando é realizada uma operação de escrita, os dados
são gravados no disco local e enviados para o nó com o dispositivo secundário. O
secundário simplesmente escreve o dado no dispositivo da camada inferior, que
neste caso, é o disco local do nó remoto. As operações de leituras são
semprerealizadas no nó principal.
Para usar o DRBD, é recomendável que o sistema de arquivos a ser utilizado
tenha suporte a journaling. Caso contrário, quando o nó primário estiver indisponível
e houver o failover, o fsck deverá ser executado.
Se o nó que falhou retornar, ele se torna o secundário e tem que sincronizar
seus dados com o primário. Isto é feito em background, sem interrupção do serviço.
Um cuidado que deve ser tomado é que, após configurado um dispositivo
DRBD, não se deve tentar montar diretamente nenhum dos discos aos quais ele faz
19
referência. O acesso aos dados deve ser feito através do dispositivo DRBD, caso
contrário, corre-se o risco de haver corrupção dos dados e tornar todo o conteúdo do
disco inacessível.
4.3 MON
O Mon tem como principal finalidade a de ser um monitor do sistema. Quando
ele detecta uma falha é possível enviar um e-mail e até mesmo fazer com que ele
acione o Heartbeat para que ele tome alguma decisão para a solução do problema.
O Mon possui vários scripts monitores e alerts. Você pode montá-los em Perl
ou shell script, similarmente ao Nagios; Os scripts podem ser complexos a ponto de
executarem queries pré-definidas em bancos de dados remotos ou também enviar
emails de alerta ao sysadmin, no nosso caso ele ficara responsável pelo
monitoramento do serviço samba, em caso de falha do serviço em algum dos
servidores, ele emitira um alerta por e-mail e também notificará o Heartbeat, fazendo
com que o outro servidor assuma o papel do que falhou, isto quer dizer: Ele
levantará o serviço Samba na maquina secundária de forma transparente para o
usuário.
5 ESTUDO DE CASO: CONFIGURAMDO UM SERVIDOR SAMBA COM H.A
O Samba é um software usado para integrar redes Linux e Windows. Ele é
uma implementação do protocolo CIFS3 que permite que sistemas Linux possam
interagir com sistemas Windows em uma rede.
Através do Samba, é possível acessar, de uma estação de trabalho com o
sistema Linux, serviços de arquivo, impressão, e de autenticação em domínio,
oferecidos por servidores Windows. Ele também permite que um servidor Linux
ofereça esses serviços de forma transparente para estações de trabalho rodando o
sistema Windows.
Neste estudo de caso será abordado a implementação de um simples sistema
de alta disponibilidade em um servidor de arquivo usando sistema operacional Linux
20
com Samba, demonstrando como esse arquitetura funciona; O interessante dessa
demonstração é que a partir dela pode-se modificar sua estrutura adaptando a
diversas necessidade que possa vir a existir.
5.1 HARDWARE NECESSÁRIO
Neste trabalho, para implementar a alta disponibilidade no servidor Samba,
são usados dois computadores. Cada um destes deve estar equipado com 2 interfa-
ces de rede e uma interface serial. Para a interligação dos computadores entre si,
são necessários um cabo serial null modem e um cabo Ethernet crossover CAT-5.
Um cabo null modem permite que dois dispositivos seriais (RS-232) se
comuniquem sem a necessidade de modems ou outros dispositivos entre eles.
Assim como o cabo null modem, um cabo Ethernet crossover é usado para
conectar duas interfaces de rede Ethernet sem que sejam necessários switches ou
outros dispositivos entre elas.
Visando obter alta disponibilidade, a ligação dos nós para formação do cluster
deve ser redundante, evitando assim, um ponto único de vulnerabilidade. Para isso
serão usadas duas conexões: uma através da interface serial, e outra através da
interface Ethernet. Deve-se conectar o cabo null modem nas portas seriais dos dois
computadores, e conectar o cabo Ethernet crossover em uma das interfaces de rede
de cada computador, deixando a outra interface de rede para conexão com a rede
local que irá acessar serviços nestes servidores, a figura a baixo mostra
detalhadamente:
21
Figura 4: Cluster de Alta disponibilidade Fonte: Autor
5.2 CONFIGURAÇÕES DOS SERVIDORES
SERVIDOR PRIMÁRIO
SO: Debian GNU/Linux 5.0 – Lenny Hostname: host1 Kernel: 2.6.26-2-686 HD: 3 partições(hd de 20GB):
* 10GB par:a a partição / - /dev/sda1 * 10GB para a partição /sejus - /dev/sda2 - partição a ser replicada * 1GB para swap - /dev/sda3
Eth0: 192.168.0.1 (Lan)
Eth1: 10.0.0.10 (H.A. Cabo crossover)
ttys0: Porta Serial
IP Virtual: 192.168.0.10
Serviços: Heartbeat-2, DRBD 8.0, Mon 0-99-2.6 e Samba 3.2.5 SERVIDOR SECUNDÁRIO SO: Debian GNU/Linux 5.0 - Lenny hostname: host2 Kernel: 2.6.26-2-686 HD: 3 partições(hd de 20GB): * 10GB par:a a partição / - /dev/sda1 * 10GB para a partição /sejus - /dev/sda2 - partição a ser replicada * 1GB para swap - /dev/sda3
Eth0: 192.168.0.2 (Lan)
Eth1: 10.0.0.20 (H.A. - cabo crossover)
ttys0: Porta Serial
22
IP Virtual: 192.168.0.10
Serviços: Heartbeat-2, DRBD 8.0, Mon 0-99-2.6 e Samba 3.2.5
A partição que estou utilizando para montar o sistema de arquivos /dev/sda2
é /sejus em ambas. O primeiro passo é fazer com que as duas máquinas possam
ser pingadas por nomes, para isso altere o arquivo hosts:
host1:
# mcedit /etc/hosts
Deixar como segue:
127.0.0.1 localhost 127.0.1.1 host1.dominio.com.br host1 192.168.0.2 host2.dominio.com.br host2
host2:
# mcedit /etc/hosts
Deixar como segue:
127.0.0.1 localhost 127.0.1.1 host2.dominio.com.br host2 192.168.0.1 host1.dominio.com.br host1 Para verificar:
Host1:
# ping host2
Host2:
# ping host1
5.3 INSTALAÇÃO DOS SOFTWARE NECESSÁRIOS
Host1:
# apt-get install drbd8-utils drbd8-modules-2.6.26-2-686
# apt-get install heartbeat-2 # apt-get install samba # apt-get install mon # apt-get install mc #Editor de texto mcedit
Host2:
# apt-get install drbd8-utils drbd8-modules-2.6.26-2-686
23
# apt-get install heartbeat-2 # apt-get install samba # apt-get install mon
# apt-get install mc #Editor de texto mcedit
5.4 CONFIGURANDO DRBD
Nem todas distribuições possuem os dispositivos do drbd1 criados em /dev ou o pacote
correspondente cria na instalação. Verifique se eles existem
Host1:
# ls /dev/drbd*
Host2:
# ls /dev/drbd*
Se não estiverem lá, crie com o comando a seguir (cria 15 dispositivos por padrão)
Host1:
# for i in $(seq 0 15) ; do mknod /dev/drbd$i b 147 $i;done
Host2:
# for i in $(seq 0 15) ; do mknod /dev/drbd$i b 147 $i;done
O próximo passo é configurar o arquivo /etc/drbd.conf nas duas máquinas (deixar o
arquivo exatamente igual nas duas)
Host1:
# mcedit /etc/drbd.conf
Host2:
# mcedit /etc/drbd.conf
Adicione as linhas abaixo:
---------------------------------------------------------------------------------------------------------------- global { usage-count yes; }
24
common { # Velocidade de transferência (utilize em torno de 40% a 60% da sua banda total) syncer { rate 100M; } } # Nome do resource em questão (sera utilizado como referencia nos comandos posteriores) resource dados { protocol C; handlers { pri-on-incon-degr "echo o > /proc/sysrq-trigger ; halt -f"; pri-lost-after-sb "echo o > /proc/sysrq-trigger ; halt -f"; local-io-error "echo o > /proc/sysrq-trigger ; halt -f"; pri-lost "echo primary DRBD lost | mail -s 'DRBD Alert' [email protected]"; split-brain "echo split-brain. drbdadm -- --discard-my-data connect / $DRBD_RESOURCE ? | mail -s 'DRBD Alert' [email protected]"; } startup { degr-wfc-timeout 120; # 2 minutes. } disk { on-io-error detach; } net { sndbuf-size 512k; timeout 60; # 6 seconds (unit = 0.1 seconds) connect-int 10; # 10 seconds (unit = 1 second) ping-int 10; # 10 seconds (unit = 1 second) ping-timeout 5; # 500 ms (unit = 0.1 seconds) max-buffers 20480; cram-hmac-alg "sha1"; shared-secret "dfadspuy234523n"; # esta chave é uma senha de conexão, de qualquer valor after-sb-0pri discard-older-primary; after-sb-1pri violently-as0p; after-sb-2pri disconnect; rr-conflict disconnect; } syncer { rate 100M; # novamente referente a transferência de rede al-extents 257; } on host1 { device /dev/drbd1; #aqui será o endereço do dispositivo (disco) virtual do DRBD disk /dev/sda2; #aqui será a partição do disco que será replicada address 192.168.0.1:7788; #IP do host1 meta-disk internal; #onde será colocado o meta-disk do drbd (ficará junto com o resto do sistema)
25
} on host2 { device /dev/drbd1; #aqui será o endereço do dispositivo (disco) virtual do DRBD disk /dev/sda2; #aqui será a partição do disco que será replicada address 192.168.0.2:7788; #IP do host2 meta-disk internal; #onde será colocado o meta-disk do drbd (ficará junto com o resto do sistema) } }
Meta-disk - disco temporário utilizado pelo drbd para armazenamento. Desmontar as partições nas duas máquinas:
Host1:
# umount /sejus
Host2:
# umount /sejus
Em seguida, retirare a entrada para a pasta do fstab das duas máquinas (ou comente com tralha):
Host1:
# mcedit /etc/fstab
Host2:
# mcedit /etc/fstab
É necessário zerar a partição que será replicada nas duas máquinas:
Host1:
# dd if=/dev/zero of=/dev/sda2 bs=1M count=128
Host2:
# dd if=/dev/zero of=/dev/sda2 bs=1M count=128
Criar o disco virtual:
Host1:
# drbdadm create-md dados
Host2:
# drbdadm create-md dados
Atar o disco nas duas máquinas:
26
Host1:
# drbdadm attach dados
Host2:
# drbdadm attach dados
Sincronizar:
Host1:
# drbdadm syncer dados
Host2:
# drbdadm syncer dados
Iniciar replicação no Host1:
Host1:
# drbdadm -- --overwrite-data-of-peer primary dados Reiniciar o serviço nas duas máquinas:
Host1:
# /etc/init.d/drbd restart
Host2:
# /etc/init.d/drbd restart
Verifique se a sincronização começou:
Host1:
# cat /proc/drbd
Verifique se o resultado está parecido com o apresentado abaixo:
version: 8.0.14 (api:86/proto:86) GIT-hash: bb447522fc9a87d0069b7e14f0234911ebdab0f7 build by phil@fat-tyre, 2008-11-12 16:40:33 0: cs:SyncSource st:Secondary/Secondary ds:UpToDate/Inconsistent C r--- ns:898320 nr:0 dw:0 dr:909728 al:0 bm:54 lo:0 pe:15 ua:357 ap:0 [==>.................] sync'ed: 18.5% (3892/4769)M finish: 0:00:39 speed: 99,760 (99,760) K/sec resync: used:2/61 hits:56431 misses:56 starving:0 dirty:0 changed:56 act_log: used:0/257 hits:0 misses:0 starving:0 dirty:0 changed:0
Após a sincronização ter terminado, verifique o resultado do comando novamente:
27
Host1:
# cat /proc/drbd
Verifique se o resultado está parecido com o apresentado abaixo:
version: 8.0.14 (api:86/proto:86) GIT-hash: bb447522fc9a87d0069b7e14f0234911ebdab0f7 build by phil@fat-tyre, 2008-11-12 16:40:33 0: cs:Connected st:Secondary/Secondary ds:UpToDate/UpToDate C r--- ns:4883572 nr:0 dw:0 dr:4883572 al:0 bm:299 lo:0 pe:0 ua:0 ap:0 resync: used:0/61 hits:304925 misses:299 starving:0 dirty:0 changed:299 act_log: used:0/257 hits:0 misses:0 starving:0 dirty:0 changed:0
Definindo máquina primária:
Host1:
# drbdadm primary all
Host2:
# drbdadm secondary all
Formate o disco virtual no Host1:
Host1:
# mkfs.ext3 /dev/drbd1
Caso precise alterar a máquina primária e secundária, use:
Host1:
# drbdadm secondary all
Host2:
# drbdadm primary all
Adicione no fstab das duas máquinas:
host1:
# mcedit /etc/fstab Adicione a linha:
---------------------------------------------------------------------------------------------------------------
/dev/drbd1 /sejus ext3 noauto 0 0
---------------------------------------------------------------------------------------------------------------
28
Host2:
# vim /etc/fstab
Adicione a linha:
/dev/drbd1 /sejus ext3 noauto 0 0
Realizando testes:
Monte a pasta no Host1:
Host1
# mount /sejus
Crie um pasta vazia na partição montada:
Host1
# cd /sejus # mkdir teste
Verifique se a pasta foi criado:
Host1
# ls /sejus
Desmonte a pasta:
Host1
# umount /sejus Defina o Host1 como secundário:
Host1
# drbdadm secondary all
Defina o Host2 como primário:
Host2
# drbdadm primary all
Monte a pasta no Host2:
Host2
# mount /sejus
Verifique se o arquivo foi criado:
Host2
# ls /sejus
29
5.5 CONFIGURANDO O HEARTBEAT.
Host1: # mcedit /etc/ha.d/ha.cf
Host2:
# vim /etc/ha.d/ha.cf
Deixar como segue:
#informe os nomes dos computadores que formam a replicação(deve ser igual a saída do comando "uname -n ----------------------------------------------------------------------------------- node host1 node host2 udp eth1 #qual a interface vai ser usada para comunicação serial /dev/ttys0 # indica a porta serial que vai ser usada para comunicação baud 19200 #Define a baud rate para as portas seriais. O valor padrão é 19200 debugfile /var/log/ha-debug #arquivos de log logfile /var/log/ha-log #arquivos de log keepalive 1 #freqüência, em segundos, da verificação das máquinas deadtime 5 #tempo mínimo para declarar a outra máquina como morta auto_failback on #Faz com que quando o servidor primário suba, ele reassuma os serviços
Configurar o arquivo haresources nas duas máquinas
Host1:
# mcedit /etc/ha.d/haresources
Node2:
# vim /etc/ha.d/haresources
Deixar como segue:
----------------------------------------------------------------------------------------------------------------
host1 drbddisk::dados Filesystem::/dev/drbd1::/sejus::ext3 192.168.0.10 samba
Obs.:
host1 - nome da máquina principal
drbddisk - utilitário do heartbeat para gerenciar o drbd
dados - nome do dispositivo do drbd (configurado no drbd.conf)
filesystem - utilitário para montagem de partição
/dev/drbd1 - nome da unidade do drbd
/sejus - nome do local de montagem do disco do drbd
ext3 - sistema de arquivos do disco do drbd
30
192.168.0.10 - IP virtual
samba – serviço há ser levantado (script do init.d para o samba)
Configurar o arquivo authkeys nas duas máquinas (para efeito da autenticação da
replicação):
host1:
# mcedit /etc/ha.d/authkeys host2:
# mcedit /etc/ha.d/authkeys
Deixar como segue:
---------------------------------------------------------------------------------------------------------------- auth 3 3 md5 digiteumafrase
----------------------------------------------------------------------------------------------------------------
Mudar os atributos do arquivo authkeys
Host1:
# chmod 600 /etc/ha.d/authkeys
Host2:
# chmod 600 /etc/ha.d/authkeys
Reinicie o serviço do heartbeat
Host1:
# /etc/init.d/heartbeat restart
Host2:
# /etc/init.d/heartbeat restart
5.6 CONFIGURANDO MON
Essa configuração monitorará o processo do Samba da seguinte maneira: ele
verificará de 10 em 10 segundos (interval) se o Samba está respondendo. Caso o
mesmo apresenta falha de conexão na máquina local, ele irá executar o script
"heartbeat.alert", responsável pela paralisação do heartbeat, obrigando assim a
máquina slave assumir e irá disparar um e-mail através do script mail.alert com o
31
assunto explícito em -S “ASSUNTO” para root@localhost O arquivo heartbeat.alert
poderá ser baixado aqui, já que o mesmo não vem instalado por default.
Host1:
# mcedit /etc/mon/mon.cf
Host2:
# mcedit /etc/mon/mon.cf
---------------------------------------------------------------------------------------------------------------
alertdir = /usr/lib/mon/alert.d
mondir = /usr/lib/mon/mon.d
maxprocs = 20
histlength = 100
randstart = 60s
hostgroup samba localhost
watch samba
service samba
interval 10s
monitor samba.monitor
allow_empty_group
period wd {Sun-Sat}
alert heartbeat.alert
alert mail.alert -S "Servidor Samba está parado" root@localhost
upalert mail.alert -S "Servidor Samba está OK" root@localhost
alertevery 1m
5.7 CONFIGURANDO O SAMBA
Host1:
# mcedit /etc/samba/smb.conf
Host2:
# mcedit /etc/samba/smb.conf
-------------------------------------------------------------------------------------------------------------
[global]
workgroup = WORKGROUP # Ou seu dominio.com.br
32
server string = Dados
netbios name = Dados
dns proxy = no
log file = /var/log/samba/%m.log
max log size = 500
debug level = 1
security = share
encrypt passwords = yes
smb passwd file = /etc/samba/smbpasswd
username map =/etc/samba/smbusers
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
unix charset = iso-8859-1
winbind uid = 10000-20000
winbind gid = 10000-20000
winbind enum users = yes
winbind enum groups = yes
template homedir = /dev/null
template shell = /dev/null
winbind use default domain = yes
passdb backend =smbpasswd
preferred master = no
wins support = yes
[SEJUS]
path = /sejus/
read only = No
create mask = 0777
force create mode = 0777
directory mask = 0777
force directory mode = 0777
guest ok = yes
6 TESTANDO A SOLUÇÃO
Os testes da solução apresentada foram realizados em ambiente virtualizado,
com uso do VirtualBox criando duas máquinas virtuais cuja configuração básica é:
33
Host 1 Host 2
CPU INTEL CORE 2 DUO T5800 2.0 GHZ INTEL CORE 2 DUO T5800 2.0 GHZ
MEMÓRIA 512 MB DDR 800 MHz 512 MB DDR 800 MHz
DISCO SATA 20 GB SATA 20 GB
Tabela 2: Configuração dos Host Fonte: Autor
Para testar a solução, com ambas as máquinas em funcionamento foi feito um
acesso a um dos compartilhamentos disponibilizados no servidor Samba usando o
endereço IP do cluster (192.168.0.10), e em seguida, foram copiados vários arquivos
para este compartilhamento.
Após o término da cópia de arquivos foi feita uma conexão ssh para o en-
dereço IP do cluster afim de identificar em qual máquina o Samba estava sendo
executado, e foi constatado que a máquina era o Host1.
Foi então parado o serviço Heartbeat no Host1 afim de provocar uma falha e
verificar se o failover ocorreria com sucesso. Após aproximadamente 5 segundos o
serviço Samba estava disponível novamente. Para confirmar se o serviço estava
executando no outro nó, foi feita uma conexão ssh, novamente usando o endereço
IP do cluster, e identificado que o servidor que estava respondendo era o Host2, o
que significa que o failover foi bem sucedido.
Com o intuito de checar se houve a replicação de arquivos para o segundo
nó, foi feito um novo acesso ao servidor Samba através do IP do cluster, e
constatado que os arquivos copiados para o Host1 estavam disponíveis no Host2,
que neste momento respondia pelo cluster.
Em seguida, para testar o failback, foi reativado o serviço Heartbeat no Host1
e, como o cluster estava configurado com a opção auto_failback ativada, novamente
foi feito um failover devolvendo o serviço para o servidor1.
Continuando, para testar o monitoramento do serviço Samba pelo MON,
paramos o Samba no Host1 com o comando: # /etc/init.d/samba stop, simulando
algum problema de inicialização ou interrupção do serviço, constatando que foi
enviado um e-mail para o usuário root notificando a parada e fazendo com que um
alerta (heratbeat.alert) parasse o heartbeat, ocasionando a elevação dos serviços no
Host2 em aproximadamente 5 segundos
34
Para finalizar os testes e verificar se a solução estava tolerante a falhas de
conectividade, foi desconectado o cabo de rede que ligava o Host1 a rede local, por
onde os clientes acessavam os serviços disponibilizados. Após pouco mais de 5
segundos, ocorreu um failover provocado pelo componente MON, para que os
clientes pudessem acessar o serviço através do outro nó.
35
7 CONSIDERAÇÕES FINAIS
O conceito de alta disponibilidade não deve, e nem pode, ser uma novidade
para os administradores de sistemas, principalmente em ambientes computacionais
onde a disponibilidade é uma característica crítica. Esse conceito, que não é
recente, está sendo amplamente disseminado, e ganha importância diretamente
proporcional a influência que os sistemas de computação exercem nas empresas ou
entidades que sustentam. Quando relacionamos alta disponibilidade com os
sistemas Linux, está na sombra desse conceito dois maduros softwares livres que
permitem preencher alguns requisitos de sua implementação: o Heartbeat e o
DRBD. Ambos são parte integrante do conhecido projeto Linux-HA.
Este artigo mostrou como pode ser implementado um ambiente de alta
disponibilidade através de software livre, no exemplo utilizado, abordamos um
servidor de arquivo samba, mas podendo facilmente ser modificado para utilização
em servidores Web, Banco de dados, e outras aplicações de missão crítica.
A arquitetura configurada se mostrou tolerante a falha de hardware,
que fizeram com que o outro nó assumisse os serviços e as solicitações dos clientes
fosse atendida, também simulamos a falha de conectividade, que ocasionaram o
failover e o failback com sucesso.
O sistema permite paralisação para manutenção planejada de cada um de
seus componentes, desde que não seja simultaneamente. Caso haja a necessidade
de manutenção em ambos os nós, ela pode ser feita de maneira alternada,
dessa forma é possível estar parando um servidor sem interromper os serviços
prestado e muito menos ter que fazer horas extras para não estar atrapalhando a
produtividade da empresa.
E por fim, nada melhor que se ter um servidor de alta disponibilidade,
principalmente quando o disco rígido do servidor queima, e não ter mais que escutar
as famosas frases do chefe, como por exemplo: "Quanto tempo o servidor demora a
voltar, 5 minutos?"
36
REFERÊNCIAS
ELLENBERG, L. Quick Start Guide For DRBD 0.7. [on-line]. Disponível na internet via http://wiki.linux-ha.org/DRBD_2fQuickStart07. Arquivo capturado em 2 de abril de 2005. ROBERTSON, A. Heartbeat Home Page. [on-line]. Disponível na internet via http://www.linux-ha.org/heartbeat/. Arquivo capturado em 2 de abril de 2005. BAIOCCO. DOUGLAS. Instalação do DRBD + Heartbeat + Samba. Disponivel na
internet, via :http://www.guiadohardware.net/tutoriais/drbd-heartbeat-samba/ . Acessado em 01 de Dezembro de 2010 FILHO, N. A. P. Linux, Clusters e Alta Disponibilidade. Dissertação (Mestrado)
Universidade de São Paulo, 2002. GARCIA, S. Alta Disponibilidade (High Availability) em sistemas GNU/LINUX. 2003. Http://ha.underlinux.com.br/. NORTON, P.; GRIFFITH, A. Guia completo do Linux. 1. ed. São Paulo: Berkeley
Brasil, 2000. PITANGA, M. Computação em Cluster. 1. ed. Rio de Janeiro: Brasport, 2003. RUSSEL, S. et al. High Availability Without Clustering. 1. ed. março: IBM, 2001. SZTOLTZ, L.; TEIXEIRA, R. S.; RIBEIRO., E. de O. F. Entendendo o Conectiva Linux. 2003. Http://www.conectiva.com.br.
MARCO, L. M. d. Computação de Alto Desempenho: Clusters. Artigo publicado
pela Unicamp, Campinas, 2006. FAUSTINO, E. P. e. a. Construindo supercomputadores com Linux. Goiânia: Monografia apresentada no Cefet, 2006. ABREU, H. O. e. a. Construindo cluser beowulf com software livre . Manaus:
Monografia apresentada na UNAMA, 2004. LEVITA, HELTON MARTINS. Alta Disponibilidade como Alternativa ao Uso de Servidores BDC em Ambientes Samba. Minas Gerais: Monografia apresentada na
Universidade Federal de Lavras. BASSAN, Ramon. Avaliação de Cluster de Alta Disponibilidade Baseado em Software Livre. Monografia defendida e aprovada na FAJ em 2008
