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

companheiros de todas as horas. irmãos.4 Dedico aos meus pais. esposa e amigos. .

pois sem o apoio deles não teria chegado até aqui.5 AGRADECIMENTOS Gostaria de agradecer aos meus pais e minha esposa que contribuíram na conclusão de mais uma jornada em minha vida. .

. você verá que é possível criar um ambiente com ótima redundância à falhas. All this transparently to network users. Nesta artigo será mostrado a instalação e configuração destas ferramentas em sistemas Debian e derivados.6 RESUMO Cluster pode ser definido como um sistema onde dois ou mais computadores trabalham de maneira conjunta para realizar grandes processamentos. These types of clusters are used in mission critical applications. you'll see that you can create an environment with optimal redundancy fault. ABSTRACT Cluster can be defined as a system where two or more computers work jointly to achieve large throughputs. que dentre eles. que são distribuído sob licença GPL (sem limitações). Heartbeat and Mon. 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. Cluster. os computadores dividem as tarefas de processamento e trabalham como se fossem um único computador. Heartbeat e o Mon. Mon. bem como os resultados obtidos na implementação de um estudo de caso onde será implantado Alta Disponibilidade em um servidor de arquivos samba. Cluster. This article will show the installation and configuration of these tools on Debian systems and derivatives. they usually have efficient means of protection and fault detection. talks about the time that a system remains active and in working condition. which among them are highlighted DRBD. Keywords: Drbd. Em outras palavras. which are distributed under GPL license (without limitation). Palavras-chave: Drbd. Alta Disponibilidade. In other words. Heartbeat. the computers share the processing tasks and work like a single computer. Quando se fala de Disponibilidade. High Availability refers to systems that almost do not stop working. destacam-se o Drbd. Usando o Linux a alguns software gratuitos. Using Linux to some free software. Tudo isso de forma transparente aos usuários da rede. Esses tipos de clusters são usados em aplicações de missão crítica. Heartbeat. as well as the results achieved in implementing a case study which will be deployed in a High Availability Samba file server. eles costumam ter meios eficientes de proteção e de detecção de falhas. When it comes to availability. High Availability. Mon.

......12 3 ALTA DISPOMIBILIDADE................................................14 3........1 Disponibilidade Básica.......................................................................................11 2...........................................13 3....................................31 6 TESTANDO A SOLUÇÃO...........23 5....14 3..................................................10 2 DEFINIÇÃO DE CLUSTER...11 2.................1 TIPOS DE CLUSTER SUAS APLICAÇÕES.....................................................................................…....................2 CONFIGURAÇÕES DOS SERVIDORES........1 Cluster de Alta Disponibilidade......15 4 FERRAMENTAS UTILIZADAS...........................................1...............................................................................4 Cluster de Processamento Paralelo..................................................................................1 HARDWARE NECESSÁRIO.........................A.........................................22 5..................35 REFERÊNCIAS............................................................................................................................................................................................................................................................................1...................................................................32 7 CONSIDEREÇÕES FINAIS...........................14 3............2 Alta Disponibilidade....................1 HEARTBEAT.........................3 Disponibilidade Continuada.....................16 4......................................................................2 Cluster de Balanceamento de Carga.........................................................................................................................................................................................30 5..17 4.....................................29 5..........20 5.........1 CONCEITOS............2........19 5...........................................................3 INSTALAÇÃO DOS SOFTWARE NECESSÁRIOS..........................7 CONFIGURANDO SAMBA..........16 4................................................................3 Combinação HA & Load Balancing............................................................12 2............4 CONFIGURANDO DRBD.............3 MON ….............6 CONFIGURANDO MON...............................1......2 DRBD....................................................5 CONFIGURANDO HERATBEAT......21 5.............................12 2...............................................2........1.........13 3......................................7 SUMÁRIO 1 INTRODUÇÃO......................................36 .................2...................2 TIPOS DE ALTA DISPONIBILIDADE...................................................................................19 5 ESTUDO DE CASO: CONFIGURAMDO UM SERVIDOR SAMBA COM H........11 2...................................................................................................

..............................18 Figura 4 Cluster de Alta disponibilidade..........................................................................11 Figura 2 Heratbeat.......................................................................................................21 ........8 LISTA DE FIGURAS Figura 1 Cluster de Computadores....................................................................................................................16 Figura 3 DRBD..........

..............33 ......................................................14 Tabela 2 Configuração dos hosts..................................9 LISTA DE TABELAS Tabela 1 Medindo a disponibilidade de um servidor...................

que distribuem o processamento entre várias CPUs). A esse tipo de agrupamento de computadores damos o nome de cluster de alta disponibilidade (não confunda com cluster de alto desempenho. o Heartbeat e o Mon. é necessário desmitificar as soluções de alta disponibilidade.10 1 INTRODUÇÃO O Atualmente as empresas precisam prover serviços ininterruptos. informações ao Heartbeat. replicação e monitoramento de serviços. quando foram desenvolvidas soluções de baixo custo que suprirão a necessidade do Linux preparando-o para tal. Mas antes de continuar. 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. caso configurado. Desta forma. O Drbd tem como principal finalidade a de estar replicando as informações de um servidor em outro. em caso de falhas. Porem essa situação se alterou. assume os serviços que ficaram indisponíveis. cada maquina monitora as demais e. há um tempo atrás. Alta disponibilidade é uma técnica que consiste na configuração de dois ou mais computadores para que eles passem a trabalhar em conjunto. O Heartbeat é responsável pela verificação e tomada de decisões. Podemos afirmar que os valores já foram extremamente altos. . o Heartbeat e o Mon. Grupos de desenvolvedores deram inicio a vários projetos open-source para pesquisarem tais soluções. utilizando como meio de transmissão a rede. como resultado disso. O Mon é responsável pelo monitoramento dos serviços e enviar. estar preparada para uma falha de hardware ou software inesperada. No que diz respeito a parte de software está artigo aborda os seguintes programas: o Drbd. dentre eles o Drbd. do tipo Beowulf. que tiveram a capacidade de solucionar problemas de disponibilidade de serviço. surgiram vários projetos. quando falava-se de um ambiente de alta disponibilidade já se pensava nos custos envolvidos para a construção desse ambiente.

A ideia geral é que se um nó do cluster vier a falhar (failover).tripod.1 TIPOS DE CLUSTER E SUAS APLICAÇÕES 2.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. criando assim uma ilusão de um recurso único (computador virtual). aplicações ou serviços possam estar disponíveis em outro nó.br.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. distribuição de carga e performance.1. Figura 01: Cluster de Computadores Fonte: http://rmagalhaess. Este conceito é denominado transparência do sistema. Estes tipos de cluster . Como características fundamentais para a construção destas plataformas inclui-se elevação da: confiança.com/ 2. de tal forma para que os usuários que os utilizam tenham a impressão que somente um único sistema responde para eles.

mail. particularmente as grandes tarefas computacionais. É comum associar este tipo de cluster ao projeto Beowulf da NASA. servidores de arquivos e aplicações. Uma grande tarefa computacional pode ser dividida em pequenas tarefas que são distribuídas ao redor das estações (nodos). Este tipo de configuração de cluster é bastante utilizado em servidores de web. Este tipo de solução é normalmente utilizado em fazendas de servidores de web (web farms).1. Se um nó falhar.12 são utilizados para base de dados de missões críticas. news ou ftp.1.4 Cluster de Processamento Paralelo Este modelo de cluster aumenta a disponibilidade e performance para as aplicações. Estes clusters são usados para computação cientifica ou análises financeiras. Todos os nodos estão responsáveis em controlar os pedidos. como se fosse um supercomputador massivamente paralelo.3 Combinação HA & Load Balancing Como o próprio nome diz combina as características dos dois tipos de cluster. correio. aumentando assim a disponibilidade e escalabilidade de serviços e recursos.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.1. . as requisições são redistribuídas entre os nós disponíveis no momento. 2. tarefas típicas para exigência de alto poder de processamento. 2. 2.

Então. cabos. mas sim toda uma estrutura que o suporte. maior será o custo para tal. TA = Total de horas por ano Ativo e TD = Total de horas por ano Desativado. quando se diz que um sistema é de alta disponibilidade. 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. então é importante sempre ter equipamentos em locais distinto. como no-break e até mesmo geradores. roubos e até mesmo ataques terroristas. deve ser levar em consideração os hubs. mas também à redes de computadores. conforme disse (GUNDA. 2001): TA − TD AD = TA Onde AD = Alta disponibilidade. roteadores e todos equipamento físico de uma rede. Um fator que deve ser levando em consideração em um sistema de alta disponibilidade é como medir a disponibilidade dos serviços. 2002) primeiramente.13 3 ALTA DISPONIBILIDADE 3. Lembrando que as falhas não são restritas somente aos hardwares. switchs. de forma que não pare o serviço. onde na falta de um o outro o supra. Pode ser visto que quanto maior o grau de disponibilidade. X100 . 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.1 CONCEITOS Segundo (FILHO. basta utilizar a seguinte fórmula. às redes elétricas e à localização dos recursos. TECHNOLOGIES. terremotos. No que diz respeito a redes de computadores. enchentes. 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. é necessário compreender que a redundância de recursos é um pré-requisito para se atingir um alto grau de disponibilidade. este sistema deve envolver não somente uma simples redundância de recursos. Para se calcular a disponibilidade de um sistemas.

9%.2. al. recuperação e mascaramento de falhas. de forma que este venha a se enquadrar na classe de alta disponibilidade.2. porém são aceitas como o senso comum na literatura da área (SZTOLTZ. 2001 3. que vise de alguma forma mascarar as eventuais falhas destas máquinas. pode-se aumentar a disponibilidade do sistema.2 TIPOS DE ALTA DISPONIBILIDADE 3. 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. .99% a 99. 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).2 Alta Disponibilidade Adicionando-se mecanismos especializados de detecção.999%. Tabela 1: Medindo a disponibilidade de um servidor Fonte: Russel et. em software ou hardware. 2001).1 Disponibilidade Básica A Disponibilidade básica é aquela encontrada em máquinas comuns..14 A tabela 1 é apresentada uma visão de classificação da disponibilidade segundo (RUSSEL et al. Costuma-se dizer que máquinas nesta classe apresentam uma disponibilidade de 99% a 99. Nesta classe as máquinas tipicamente apresentam disponibilidade na faixa de 99. 2003). sem nenhum mecanismo especial.. 3.

saber que serviços estão sendo prestado. o principal objetivo da alta disponibilidade é buscar uma forma de manter os serviços prestados por um sistema a outros elementos. o que significa que todas as paradas planejadas e não planejadas são mascaradas. Outra possibilidade importante da alta disponibilidade é fazer isto com computadores básicos. 2003). mesmo que o sistema em si venha a se modificar internamente por causa de uma falha.3 Disponibilidade Continuada Com a adição de noves se obtém uma disponibilidade cada vez mais próxima de 100%. que visa manter a disponibilidade dos serviços prestados por um sistema computacional. cada um monitorando os outros e assumindo seus serviços caso perceba que algum deles falhou.15 podendo ficar indisponíveis por um período de pouco mais de 5 minutos até uma hora em um ano de operação. 3. e o sistema está sempre disponível. através da redundância de hardware e reconfiguração de software. Esse é o conceito de mascaramento de falhas. quem os está prestando. o software de alta disponibilidade é quem se preocupa em monitorar outras máquinas de uma rede. através de redundância ou replicação. Um determinado serviço. é colocado por trás de uma camada de abstração. como centrais telefônicas (SZTOLTZ. 2003). Vários computadores juntos agindo como um só. A complexidade pode estar apenas no software. Este é o coração da alta disponibilidade. uma sub-área da tolerância a falhas. e o que fazer quando uma falha é percebida (SZTOLTZ. diminuindo o tempo de inoperância do sistema de forma que este venha a ser desprezível ou mesmo inexistente. Aqui se encaixam grande parte das aplicações comerciais de alta disponibilidade. que se quer altamente disponível. como os que se pode comprar até num supermercado. Mais fácil de desenvolver que o hardware. Como já pode ser percebido de sua definição. . Isso é a disponibilidade contínua.2. que permita mudanças em seus mecanismos internos mantendo intacta a interação com elementos externos.

se o servidor primário estiver ligado apenas ao servidor de backup.1 HEARTBEAT O programa Heartbeat é usado para construir cluster da altíssima disponibilidade. Este termo é usado para definir o pulso enviado entre duas máquinas. No entanto. evitar congestionamento da rede (TRIGO.  haresources: configura o endereço IP do cluster e o grupo de serviços que serão executados preferencialmente em cada um dos nodos. 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. por enviar um pacote único e. é aconselhável utilizar o unicast. estão funcionando e disponíveis para executarem tarefas. multcast ou unicast. A configuração do Heartbeat consiste em três arquivos:  ha. Se o Heartbeat falhar. Esta escolha depende da aplicação que será dada ao Heartbeat. ver figura abaixo Figura 02: Heartbeat Fonte: Autor A comunicação entre os servidores pode ser feita em broadcast.cf: configuração dos computadores envolvidos e o meio de comunicação utilizado entre os nodos.16 4 FERRAMENTAS UTILIZADAS 4.  authkeys: armazena a autenticação necessária entre os dois nodos. . 2007). assim. Heartbeat significa batimento cardíaco. 2007). indicando que estão “vivas” . ou seja.

quando pusermos o auto_failback a on. É possível configurar o tempo entre os Heartbeats. ele volta a tomar controle do cluster. 2008). A chamada conexão terminada acontece quando se decide desconectar ou quando a conexão é perdida (HEARTBEAT. começa o processo dos Heartbeats. este IP está associado a um domínio. A primeira hipótese é o caso da tentativa permitida e então pode acontecer que a conexão seja restabelecida ou perdida. só há uma saída que é a conexão perdida. O funcionamento do Heartbeat é apresentado na Figura 4.escreve no disco local e os envia para o outro computador. 2008). Uma vez a conexão estabelecida. Quando há um Heartbeat perdido. isto é. onde recebe os dados a serem gravados. vem juntamente com ele uma tentativa de reconexão. enquanto que em off o nodo primário é prevenido para readquirir o controle do cluster ( HEARTBEAT. a figura 2 ilustra o que é descrito acima: . fazendo o espelhamento ( mirroring) de um dispositivo de blocos através de uma conexão de rede dedicada. ou seja.17 O Heartbeat deverá ser instalado em ambos os servidores e todos os arquivos devem estar iguais nos dois nodos. o IP do cluster. o nodo secundário assume o IP virtual. dessa tentativa duas hipóteses é tomada em conta. Existe uma opção chamada auto _failback que nos permite escolher entre on e off. O Heartbeat utiliza a porta 694 para a comunicação bcast ou ucast. 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. onde os dados também são gravados no disco. quando o nodo primário voltar de uma falha qualquer. 2008). o tempo de alerta no caso do Heartbeat não chegar a tempo e o tempo em que se considera o nodo como morto. 4. O Heartbeat funciona através de um IP virtual que identifica o cluster. Ele pode ser entendido como um RAID 1 via rede. Quando o nodo primário falhar. A segunda hipótese é o caso da tentativa inválida e daí.2 DRBD O DRBD (Distributed Replicated Block Device) é o software que realiza a replicação de dados entre os nós do cluster.

Isto é feito em background. após configurado um dispositivo DRBD. ele se torna o secundário e tem que sincronizar seus dados com o primário. que pode ser primário ou secundário.zenoss. Quando é realizada uma operação de escrita. as alterações serão gravadas no disco local. Caso contrário. estará distribuído nos dois servidores que compõe o cluster. Para usar o DRBD. sem interrupção do serviço. Um cuidado que deve ser tomado é que.18 Fgura 03: DRBD Fonte: http://community. não se deve tentar montar diretamente nenhum dos discos aos quais ele faz . na verdade. é recomendável que o sistema de arquivos a ser utilizado tenha suporte a journaling. 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. Todo acesso ao disco passa a ser feito através deste dispositivo. Sempre que um nó gravar no dispositivo DRBD. As operações de leituras são semprerealizadas no nó principal. que neste caso. é o disco local do nó remoto. Cada dispositivo DRBD tem um estado. quando o nó primário estiver indisponível e houver o failover. o fsck deverá ser executado.png O DRBD cria um dispositivo de armazenamento que. O dispositivo primário fica no nó principal. e serão replicadas para o outro nó em tempo real. onde a aplicação está executando e tem acesso ao dispositivo DRBD (/dev/drbdX).org/servlet/JiveServlet/showImage/102-2485-2-64/image_preview. O dispositivo DRBD trabalha em uma camada superior aos dispositivos de bloco usados para armazenamento (disco local) dos computadores do cluster. Se o nó que falhou retornar.

serviços de arquivo.A O Samba é um software usado para integrar redes Linux e Windows. ele emitira um alerta por e-mail e também notificará o Heartbeat. caso contrário.19 referência. fazendo com que o outro servidor assuma o papel do que falhou. similarmente ao Nagios. Através do Samba. O acesso aos dados deve ser feito através do dispositivo DRBD. 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. e de autenticação em domínio. é possível acessar. corre-se o risco de haver corrupção dos dados e tornar todo o conteúdo do disco inacessível. Você pode montá-los em Perl ou shell script. de uma estação de trabalho com o sistema Linux. no nosso caso ele ficara responsável pelo monitoramento do serviço samba. 4.3 MON O Mon tem como principal finalidade a de ser um monitor do sistema. em caso de falha do serviço em algum dos servidores. Ele é uma implementação do protocolo CIFS3 que permite que sistemas Linux possam interagir com sistemas Windows em uma rede. impressão. 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 . O Mon possui vários scripts monitores e alerts. 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. 5 ESTUDO DE CASO: CONFIGURAMDO UM SERVIDOR SAMBA COM H. isto quer dizer: Ele levantará o serviço Samba na maquina secundária de forma transparente para o usuário. oferecidos por servidores Windows. 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.

Deve-se conectar o cabo null modem nas portas seriais dos dois computadores. Um cabo null modem permite que dois dispositivos seriais (RS-232) se comuniquem sem a necessidade de modems ou outros dispositivos entre eles. e outra através da interface Ethernet. Visando obter alta disponibilidade. para implementar a alta disponibilidade no servidor Samba. a figura a baixo mostra detalhadamente: . a ligação dos nós para formação do cluster deve ser redundante. demonstrando como esse arquitetura funciona. evitando assim. Assim como o cabo null modem.1 HARDWARE NECESSÁRIO Neste trabalho. 5. O interessante dessa demonstração é que a partir dela pode-se modificar sua estrutura adaptando a diversas necessidade que possa vir a existir. Para a interligação dos computadores entre si. e conectar o cabo Ethernet crossover em uma das interfaces de rede de cada computador. são usados dois computadores. Para isso serão usadas duas conexões: uma através da interface serial. deixando a outra interface de rede para conexão com a rede local que irá acessar serviços nestes servidores. um cabo Ethernet crossover é usado para conectar duas interfaces de rede Ethernet sem que sejam necessários switches ou outros dispositivos entre elas.20 com Samba. um ponto único de vulnerabilidade. são necessários um cabo serial null modem e um cabo Ethernet crossover CAT-5. Cada um destes deve estar equipado com 2 interfaces de rede e uma interface serial.

0.10 (H.1 (Lan) Eth1: 10. ./dev/sda2 .6.6 e Samba 3.0. DRBD 8./dev/sda3 Eth0: 192.0 – Lenny Hostname: host1 Kernel: 2.A.26-2-686 HD: 3 partições(hd de 20GB): * 10GB par:a a partição / .26-2-686 HD: 3 partições(hd de 20GB): * 10GB par:a a partição / .2 (Lan) Eth1: 10.partição a ser replicada * 1GB para swap .168.10 Serviços: Heartbeat-2.A.partição a ser replicada * 1GB para swap .0./dev/sda2 . Mon 0-99-2. Cabo crossover) ttys0: Porta Serial IP Virtual: 192.5 SERVIDOR SECUNDÁRIO SO: Debian GNU/Linux 5.0.0.2 CONFIGURAÇÕES DOS SERVIDORES SERVIDOR PRIMÁRIO SO: Debian GNU/Linux 5.20 (H.cabo crossover) ttys0: Porta Serial .Lenny hostname: host2 Kernel: 2./dev/sda1 * 10GB para a partição /sejus .0 .0.0./dev/sda1 * 10GB para a partição /sejus .168.21 Figura 4: Cluster de Alta disponibilidade Fonte: Autor 5.6.2.0./dev/sda3 Eth0: 192.168.

10 Serviços: Heartbeat-2.6.26-2-686 .1 host1.dominio.3 INSTALAÇÃO DOS SOFTWARE NECESSÁRIOS Host1: # apt-get install drbd8-utils drbd8-modules-2.dominio.1.1 localhost 127.168.0.br host1 Para verificar: Host1: # ping host2 Host2: # ping host1 5.com.com.1.0.6.0. DRBD 8.168.0.dominio.5 A partição que estou utilizando para montar o sistema de arquivos /dev/sda2 é /sejus em ambas.2 host2.0.dominio.br host1 192. Mon 0-99-2.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.1 host1. O primeiro passo é fazer com que as duas máquinas possam ser pingadas por nomes.2.6 e Samba 3.0.1 localhost 127.com.22 IP Virtual: 192.br host2 192. para isso altere o arquivo hosts: host1: # mcedit /etc/hosts Deixar como segue: 127.0.com.0.168.0.0.1 host2.br host2 host2: # mcedit /etc/hosts Deixar como segue: 127.

4 CONFIGURANDO DRBD Nem todas distribuições possuem os dispositivos do drbd1 criados em /dev ou o pacote correspondente cria na instalação. 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.conf Host2: # mcedit /etc/drbd. do mknod /dev/drbd$i b 147 $i. Verifique se eles existem Host1: # ls /dev/drbd* Host2: # ls /dev/drbd* Se não estiverem lá.done O próximo passo é configurar o arquivo /etc/drbd.23 # apt-get install heartbeat-2 # apt-get install samba # apt-get install mon # apt-get install mc #Editor de texto mcedit 5.conf nas duas máquinas (deixar o arquivo exatamente igual nas duas) Host1: # mcedit /etc/drbd.conf Adicione as linhas abaixo: ---------------------------------------------------------------------------------------------------------------global { usage-count yes.done Host2: # for i in $(seq 0 15) .

pri-lost-after-sb "echo o > /proc/sysrq-trigger . } disk { on-io-error detach. } } # Nome do resource em questão (sera utilizado como referencia nos comandos posteriores) resource dados { protocol C. drbdadm -. handlers { pri-on-incon-degr "echo o > /proc/sysrq-trigger .1 seconds) connect-int 10. # 10 seconds (unit = 1 second) ping-timeout 5. } startup { degr-wfc-timeout 120.1:7788.com". shared-secret "dfadspuy234523n". # novamente referente a transferência de rede al-extents 257.0. split-brain "echo split-brain. after-sb-1pri violently-as0p. local-io-error "echo o > /proc/sysrq-trigger .com".--discard-my-data connect / $DRBD_RESOURCE ? | mail -s 'DRBD Alert' pager@braslink.24 common { # Velocidade de transferência (utilize em torno de 40% a 60% da sua banda total) syncer { rate 100M. pri-lost "echo primary DRBD lost | mail -s 'DRBD Alert' email@dominio. #aqui será o endereço do dispositivo (disco) virtual do DRBD disk /dev/sda2. } net { sndbuf-size 512k. # 10 seconds (unit = 1 second) ping-int 10. # 2 minutes. halt -f". } on host1 { device /dev/drbd1. # esta chave é uma senha de conexão. rr-conflict disconnect. # 6 seconds (unit = 0. de qualquer valor after-sb-0pri discard-older-primary. } syncer { rate 100M. halt -f". #aqui será a partição do disco que será replicada address 192. halt -f".1 seconds) max-buffers 20480. after-sb-2pri disconnect. #onde será colocado o meta-disk do drbd (ficará junto com o resto do sistema) .168. timeout 60. cram-hmac-alg "sha1". #IP do host1 meta-disk internal. # 500 ms (unit = 0.

0. 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: .168. Desmontar as partições nas duas máquinas: Host1: # umount /sejus Host2: # umount /sejus Em seguida.25 } on host2 { device /dev/drbd1. #onde será colocado o meta-disk do drbd (ficará junto com o resto do sistema) } } Meta-disk . #aqui será a partição do disco que será replicada address 192. #IP do host2 meta-disk internal. #aqui será o endereço do dispositivo (disco) virtual do DRBD disk /dev/sda2.disco temporário utilizado pelo drbd para armazenamento.2:7788.

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 -.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.] sync'ed: 18...5% (3892/4769)M finish: 0:00:39 speed: 99...760 (99...--overwrite-data-of-peer primary dados Reiniciar o serviço nas duas máquinas: Host1: # /etc/init......0. 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 [==>.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.14 (api:86/proto:86) GIT-hash: bb447522fc9a87d0069b7e14f0234911ebdab0f7 build by phil@fat-tyre...d/drbd restart Host2: # /etc/init. verifique o resultado do comando novamente: ....

0.14 (api:86/proto:86) GIT-hash: bb447522fc9a87d0069b7e14f0234911ebdab0f7 build by phil@fat-tyre. 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 --------------------------------------------------------------------------------------------------------------- .ext3 /dev/drbd1 Caso precise alterar a máquina primária e secundária. 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.27 Host1: # cat /proc/drbd Verifique se o resultado está parecido com o apresentado abaixo: version: 8.

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 .

em segundos.: host1 .cf Host2: # vim /etc/ha.nome da máquina principal drbddisk .d/ha. ele reassuma os serviços Configurar o arquivo haresources nas duas máquinas Host1: # mcedit /etc/ha.168.5 CONFIGURANDO O HEARTBEAT.0. Host1: # mcedit /etc/ha.d/haresources Node2: # vim /etc/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.nome do local de montagem do disco do drbd ext3 .29 5.d/ha.nome do dispositivo do drbd (configurado no drbd.utilitário do heartbeat para gerenciar o drbd dados . 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.10 samba Obs.sistema de arquivos do disco do drbd .d/haresources Deixar como segue: ---------------------------------------------------------------------------------------------------------------host1 drbddisk::dados Filesystem::/dev/drbd1::/sejus::ext3 192.nome da unidade do drbd /sejus .conf) filesystem .utilitário para montagem de partição /dev/drbd1 . 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.

d/heartbeat restart Host2: # /etc/init.30 192.d/authkeys Host2: # chmod 600 /etc/ha.168.d para o samba) Configurar o arquivo authkeys nas duas máquinas (para efeito da autenticação da replicação): host1: # mcedit /etc/ha. obrigando assim a máquina slave assumir e irá disparar um e-mail através do script mail.d/authkeys Deixar como segue: ---------------------------------------------------------------------------------------------------------------auth 3 3 md5 digiteumafrase ---------------------------------------------------------------------------------------------------------------Mudar os atributos do arquivo authkeys Host1: # chmod 600 /etc/ha.d/authkeys host2: # mcedit /etc/ha.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.d/heartbeat restart 5.10 . responsável pela paralisação do heartbeat.IP virtual samba – serviço há ser levantado (script do init. ele irá executar o script "heartbeat.alert com o . Caso o mesmo apresenta falha de conexão na máquina local.d/authkeys Reinicie o serviço do heartbeat Host1: # /etc/init.alert".0.

alert poderá ser baixado aqui.com.conf Host2: # mcedit /etc/samba/smb.alert -S "Servidor Samba está parado" root@localhost upalert mail.alert -S "Servidor Samba está OK" root@localhost alertevery 1m 5.alert alert mail.d mondir = /usr/lib/mon/mon. já que o mesmo não vem instalado por default.cf Host2: # mcedit /etc/mon/mon. Host1: # mcedit /etc/mon/mon.7 CONFIGURANDO O SAMBA Host1: # mcedit /etc/samba/smb.d maxprocs = 20 histlength = 100 randstart = 60s hostgroup samba localhost watch samba service samba interval 10s monitor samba.conf ------------------------------------------------------------------------------------------------------------[global] workgroup = WORKGROUP # Ou seu dominio.31 assunto explícito em -S “ASSUNTO” para root@localhost O arquivo heartbeat.br .monitor allow_empty_group period wd {Sun-Sat} alert heartbeat.cf --------------------------------------------------------------------------------------------------------------alertdir = /usr/lib/mon/alert.

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 é: .

Continuando.alert) parasse o heartbeat. foi feito um novo acesso ao servidor Samba através do IP do cluster. e em seguida. constatando que foi enviado um e-mail para o usuário root notificando a parada e fazendo com que um alerta (heratbeat.33 Host 1 CPU MEMÓRIA DISCO INTEL CORE 2 DUO T5800 2. novamente usando o endereço IP do cluster. novamente foi feito um failover devolvendo o serviço para o servidor1.0 GHZ Host 2 INTEL CORE 2 DUO T5800 2.0. o que significa que o failover foi bem sucedido. paramos o Samba no Host1 com o comando: # /etc/init. para testar o failback. Após o término da cópia de arquivos foi feita uma conexão ssh para o endereço IP do cluster afim de identificar em qual máquina o Samba estava sendo executado. foram copiados vários arquivos para este compartilhamento. 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.d/samba stop. como o cluster estava configurado com a opção auto_ failback ativada. que neste momento respondia pelo cluster. Foi então parado o serviço Heartbeat no Host1 afim de provocar uma falha e verificar se o failover ocorreria com sucesso. foi reativado o serviço Heartbeat no Host1 e. e identificado que o servidor que estava respondendo era o Host2. para testar o monitoramento do serviço Samba pelo MON. e foi constatado que a máquina era o Host1.168. Para confirmar se o serviço estava executando no outro nó. Em seguida. Com o intuito de checar se houve a replicação de arquivos para o segundo nó. simulando algum problema de inicialização ou interrupção do serviço. Após aproximadamente 5 segundos o serviço Samba estava disponível novamente.10).0 GHZ 512 MB DDR 800 MHz SATA 20 GB Tabela 2: Configuração dos Host Fonte: Autor 512 MB DDR 800 MHz SATA 20 GB Para testar a solução. foi feita uma conexão ssh. e constatado que os arquivos copiados para o Host1 estavam disponíveis no Host2. 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. Após pouco mais de 5 segundos. ocorreu um failover provocado pelo componente MON. . por onde os clientes acessavam os serviços disponibilizados. para que os clientes pudessem acessar o serviço através do outro nó. foi desconectado o cabo de rede que ligava o Host1 a rede local.

está na sombra desse conceito dois maduros softwares livres que permitem preencher alguns requisitos de sua implementação: o Heartbeat e o DRBD. Banco de dados. que ocasionaram o failover e o failback com sucesso. como por exemplo: "Quanto tempo o servidor demora a voltar. que não é recente. Quando relacionamos alta disponibilidade com os sistemas Linux. e outras aplicações de missão crítica. A arquitetura configurada se mostrou tolerante a falha de hardware. Caso haja a necessidade de manutenção em ambos os nós. Ambos são parte integrante do conhecido projeto Linux-HA. ser uma novidade para os administradores de sistemas. principalmente quando o disco rígido do servidor queima. e não ter mais que escutar as famosas frases do chefe. está sendo amplamente disseminado. 5 minutos?" . ela pode ser feita de maneira alternada. desde que não seja simultaneamente. nada melhor que se ter um servidor de alta disponibilidade. abordamos um servidor de arquivo samba. Esse conceito. e nem pode. 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. mas podendo facilmente ser modificado para utilização em servidores Web.35 7 CONSIDERAÇÕES FINAIS O conceito de alta disponibilidade não deve. Este artigo mostrou como pode ser implementado um ambiente de alta disponibilidade através de software livre. O sistema permite paralisação para manutenção planejada de cada um de seus componentes. principalmente em ambientes computacionais onde a disponibilidade é uma característica crítica. que fizeram com que o outro nó assumisse os serviços e as solicitações dos clientes fosse atendida. E por fim. e ganha importância diretamente proporcional a influência que os sistemas de computação exercem nas empresas ou entidades que sustentam. também simulamos a falha de conectividade. no exemplo utilizado.

org/DRBD_2fQuickStart07. LEVITA. GRIFFITH. Construindo cluser beowulf com software livre . Http://ha. Dissertação (Mestrado) Universidade de São Paulo. Campinas.. [on-line].7. MARCO. FAUSTINO. A.org/heartbeat/. ed.linux-ha. 2006. A. 2003. TEIXEIRA. a.conectiva. N. L. Ramon. Artigo publicado pela Unicamp. d. 2000.guiadohardware. S.. NORTON. [on-line]. Acessado em 01 de Dezembro de 2010 FILHO. Linux. A. Manaus: Monografia apresentada na UNAMA.. High Availability Without Clustering .com. e. DOUGLAS. Computação de Alto Desempenho: Clusters .br/. E.com. HELTON MARTINS. ed. Arquivo capturado em 2 de abril de 2005. P. M. Rio de Janeiro: Brasport. 2002. BAIOCCO. SZTOLTZ. 2006. E. P. via :http://www. 1. 1. Computação em Cluster. Quick Start Guide For DRBD 0. Instalação do DRBD + Heartbeat + Samba. Http://www. Monografia defendida e aprovada na FAJ em 2008 . Disponivel na internet. PITANGA. março: IBM. Goiânia: Monografia apresentada no Cefet. Arquivo capturado em 2 de abril de 2005. R. F. 1. H. ROBERTSON. Guia completo do Linux. P. 2003. GARCIA. 2003..36 REFERÊNCIAS ELLENBERG. ABREU. 2004.linux-ha. Disponível na internet via http://www. Avaliação de Cluster de Alta Disponibilidade Baseado em Software Livre. a. Minas Gerais: Monografia apresentada na Universidade Federal de Lavras. Construindo supercomputadores com Linux . Alta Disponibilidade (High Availability) em sistemas GNU/LINUX . e. de O. BASSAN. S. L. 2001.underlinux. Entendendo o Conectiva Linux. Alta Disponibilidade como Alternativa ao Uso de Servidores BDC em Ambientes Samba. S. RUSSEL. L. São Paulo: Berkeley Brasil. ed. Clusters e Alta Disponibilidade. RIBEIRO. O.net/tutoriais/drbd-heartbeat-samba/ . et al. M.br. Disponível na internet via http://wiki. Heartbeat Home Page.