ARTIGO CLUSTER DE ALTA DISPONIBILIDADE EM SISTEMAS LINUX

5,468 views
5,309 views

Published on

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.

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,468
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
352
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

ARTIGO CLUSTER DE ALTA DISPONIBILIDADE EM SISTEMAS LINUX

  1. 1. 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 BATISTACLUSTER DE ALTA DISPONIBILIDADE EM SISTEMAS LINUX COM AS FERRAMENTAS: DRBD, HEARTBEAT E MON PORTO VELHO 2010
  2. 2. 2 JORGE WILLIANS DA SILVA BATISTACLUSTER 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. 3. 3 JORGE WILLIANS DA SILVA BATISTA CLUSTER DE ALTA DISPONIBILIDADE EM SISTEMAS LINUX COM AS FERRAMENTAS: DRBD, HEARTBEAT E MONTrabalho de Conclusão de apresentado ao Curso de Pós-Graduação em Segurançade Redes e Sistemas Computacionais da UNIRON – União das Escolas Superioresde 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. 4. 4Dedico aos meus pais, irmãos, esposa eamigos, companheiros de todas as horas.
  5. 5. 5 AGRADECIMENTOSGostaria de agradecer aos meus pais e minha esposa que contribuíram naconclusão de mais uma jornada em minha vida, pois sem o apoio deles não teriachegado até aqui.
  6. 6. 6 RESUMOCluster pode ser definido como um sistema onde dois ou mais computadorestrabalham de maneira conjunta para realizar grandes processamentos. Em outraspalavras, os computadores dividem as tarefas de processamento e trabalham comose fossem um único computador; Quando se fala de Disponibilidade, fala-se dotempo em que determinado sistema permanece ativo e em condições de uso. A AltaDisponibilidade 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 costumamter meios eficientes de proteção e de detecção de falhas; Usando o Linux a algunssoftware gratuitos, que dentre eles, destacam-se o Drbd, Heartbeat e o Mon, quesão distribuído sob licença GPL (sem limitações), você verá que é possível criar umambiente com ótima redundância à falhas. Tudo isso de forma transparente aosusuários da rede. Nesta artigo será mostrado a instalação e configuração destasferramentas em sistemas Debian e derivados, bem como os resultados obtidos naimplementação de um estudo de caso onde será implantado Alta Disponibilidade emum servidor de arquivos samba.Palavras-chave: Drbd. Heartbeat. Mon. Alta Disponibilidade. Cluster. ABSTRACTCluster can be defined as a system where two or more computers work jointly toachieve large throughputs. In other words, the computers share the processing tasksand work like a single computer; When it comes to availability, talks about the timethat a system remains active and in working condition. High Availability refers tosystems that almost do not stop working. These types of clusters are used in missioncritical applications, they usually have efficient means of protection and faultdetection; Using Linux to some free software, which among them are highlightedDRBD, Heartbeat and Mon, which are distributed under GPL license (withoutlimitation), youll see that you can create an environment with optimal redundancyfault. All this transparently to network users. This article will show the installation andconfiguration of these tools on Debian systems and derivatives, as well as the resultsachieved in implementing a case study which will be deployed in a High AvailabilitySamba file server.Keywords: Drbd. Heartbeat. Mon. High Availability. Cluster.
  7. 7. 7 SUMÁRIO1 INTRODUÇÃO........................................................................................................102 DEFINIÇÃO DE CLUSTER.....................................................................................112.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.............................................................123 ALTA DISPOMIBILIDADE..................................................................................….133.1 CONCEITOS........................................................................................................133.2 TIPOS DE ALTA DISPONIBILIDADE....................................................................14 3.2.1 Disponibilidade Básica..................................................................................14 3.2.2 Alta Disponibilidade.......................................................................................14 3.2.3 Disponibilidade Continuada..........................................................................154 FERRAMENTAS UTILIZADAS...............................................................................164.1 HEARTBEAT........................................................................................................164.2 DRBD...................................................................................................................174.3 MON ….................................................................................................................195 ESTUDO DE CASO: CONFIGURAMDO UM SERVIDOR SAMBA COM H.A.......195.1 HARDWARE NECESSÁRIO.................................................................................205.2 CONFIGURAÇÕES DOS SERVIDORES.............................................................215.3 INSTALAÇÃO DOS SOFTWARE NECESSÁRIOS...............................................225.4 CONFIGURANDO DRBD......................................................................................235.5 CONFIGURANDO HERATBEAT...........................................................................295.6 CONFIGURANDO MON........................................................................................305.7 CONFIGURANDO SAMBA..................................................................................316 TESTANDO A SOLUÇÃO.......................................................................................327 CONSIDEREÇÕES FINAIS....................................................................................35REFERÊNCIAS..........................................................................................................36
  8. 8. 8 LISTA DE FIGURASFigura 1 Cluster de Computadores.........................................................................11Figura 2 Heratbeat...................................................................................................16Figura 3 DRBD.........................................................................................................18Figura 4 Cluster de Alta disponibilidade...............................................................21
  9. 9. 9 LISTA DE TABELASTabela 1 Medindo a disponibilidade de um servidor.............................................14Tabela 2 Configuração dos hosts...........................................................................33
  10. 10. 101 INTRODUÇÃO O Atualmente as empresas precisam prover serviços ininterruptos. Torna-sevital para qualquer empresa que deseja manter-se competitiva no mercado possuiruma estratégia envolvendo alta disponibilidade para os seus servidores de aplicaçãoe, estar preparada para uma falha de hardware ou software inesperada. Alta disponibilidade é uma técnica que consiste na configuração de dois oumais 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 queficaram indisponíveis. A esse tipo de agrupamento de computadores damos o nomede cluster de alta disponibilidade (não confunda com cluster de alto desempenho, dotipo Beowulf, que distribuem o processamento entre várias CPUs). Mas antes de continuar, é necessário desmitificar as soluções de altadisponibilidade, há um tempo atrás, quando falava-se de um ambiente de altadisponibilidade já se pensava nos custos envolvidos para a construção desseambiente. Podemos afirmar que os valores já foram extremamente altos, Poremessa situação se alterou, quando foram desenvolvidas soluções de baixo custo quesuprirão a necessidade do Linux preparando-o para tal. Grupos de desenvolvedoresderam inicio a vários projetos open-source para pesquisarem tais soluções, comoresultado 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 seguintesprogramas: o Drbd, o Heartbeat e o Mon. O Drbd tem como principal finalidade a deestar replicando as informações de um servidor em outro, utilizando como meio detransmissão a rede. O Heartbeat é responsável pela verificação e tomada dedecisões. O Mon é responsável pelo monitoramento dos serviços e enviar, casoconfigurado, informações ao Heartbeat.
  11. 11. 112 DEFINIÇÃO DE CLUSTER Na sua forma mais básica um cluster é um sistema que compreende dois oumais computadores ou sistemas (denominados nodos) na qual trabalham emconjunto para executar aplicações ou realizar outras tarefas, de tal forma para queos usuários que os utilizam tenham a impressão que somente um único sistemaresponde para eles, criando assim uma ilusão de um recurso único (computadorvirtual). Este conceito é denominado transparência do sistema. Como característicasfundamentais 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ÇÕES2.1.1 Cluster de Alta Disponibilidade Estes modelos de clusters são construídos para prover uma disponibilidadede serviços e recursos de forma ininterruptas através do uso da redundânciaimplí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. 12. 12são utilizados para base de dados de missões críticas, correio, servidores dearquivos e aplicações.2.1.2 Cluster de Balanceamento de carga Este modelo distribui o tráfego entrante ou requisições de recursosprovenientes dos nodos que executam os mesmos programas entre as máquinasque compõem o cluster. Todos os nodos estão responsáveis em controlar ospedidos. Se um nó falhar, as requisições são redistribuídas entre os nós disponíveisno momento. Este tipo de solução é normalmente utilizado em fazendas deservidores 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. Estetipo 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 asaplicações, particularmente as grandes tarefas computacionais. Uma grande tarefacomputacional pode ser dividida em pequenas tarefas que são distribuídas ao redordas estações (nodos), como se fosse um supercomputador massivamente paralelo.É comum associar este tipo de cluster ao projeto Beowulf da NASA. Estes clusterssão usados para computação cientifica ou análises financeiras, tarefas típicas paraexigência de alto poder de processamento.
  13. 13. 133 ALTA DISPONIBILIDADE3.1 CONCEITOS Segundo (FILHO, 2002) primeiramente, é necessário compreender que aredundância de recursos é um pré-requisito para se atingir um alto grau dedisponibilidade. 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 emconsideração os hubs, switchs, cabos, roteadores e todos equipamento físico deuma rede. Já com relação as redes elétricas deve se entender que qualquer tipo deoscilação ou indisponibilidade do serviço deve ser suprima por outra forma degeração de energia, como no-break e até mesmo geradores. E finalmente com relação a localização física do recursos deve-se semprelembrar que um local está propício a furacões, enchentes, terremotos, roubos e atémesmo ataques terroristas, então é importante sempre ter equipamentos em locaisdistinto, 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 sistemadeve envolver não somente uma simples redundância de recursos, mas sim todauma estrutura que o suporte. Pode ser visto que quanto maior o grau dedisponibilidade, maior será o custo para tal. Um fator que deve ser levando em consideração em um sistema de altadisponibilidade é como medir a disponibilidade dos serviços. Para tal deve serlevado em consideração o tempo em que o serviços ficam ativos e quanto tempo oserviços ficam foram do ar. Para se calcular a disponibilidade de um sistemas, basta utilizar a seguintefórmula, conforme disse (GUNDA; TECHNOLOGIES, 2001): TA − TD AD = X100 TA Onde AD = Alta disponibilidade, TA = Total de horas por ano Ativo e TD = Totalde horas por ano Desativado.
  14. 14. 14 A tabela 1 é apresentada uma visão de classificação da disponibilidadesegundo (RUSSEL et al., 2001). Tabela 1: Medindo a disponibilidade de um servidor Fonte: Russel et. al., 20013.2 TIPOS DE ALTA DISPONIBILIDADE3.2.1 Disponibilidade Básica A Disponibilidade básica é aquela encontrada em máquinas comuns, semnenhum mecanismo especial, em software ou hardware, que vise de alguma formamascarar as eventuais falhas destas máquinas. Costuma-se dizer que máquinasnesta classe apresentam uma disponibilidade de 99% a 99,9%. Isto equivale a dizerque em um ano de operação a máquina pode ficar indisponível por um período de 9horas a quatro dias. Estes dados são empíricos e os tempos não levam emconsideração a possibilidade de paradas planejadas (que serão abordadas maisadiante), 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 emascaramento de falhas, pode-se aumentar a disponibilidade do sistema, de formaque este venha a se enquadrar na classe de alta disponibilidade. Nesta classe asmáquinas tipicamente apresentam disponibilidade na faixa de 99,99% a 99,999%,
  15. 15. 15podendo ficar indisponíveis por um período de pouco mais de 5 minutos até umahora em um ano de operação. Aqui se encaixam grande parte das aplicaçõescomerciais 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óximade 100%, diminuindo o tempo de inoperância do sistema de forma que este venha aser desprezível ou mesmo inexistente. Isso é a disponibilidade contínua, o quesignifica que todas as paradas planejadas e não planejadas são mascaradas, e osistema está sempre disponível. Como já pode ser percebido de sua definição, o principal objetivo da altadisponibilidade é buscar uma forma de manter os serviços prestados por um sistemaa outros elementos, mesmo que o sistema em si venha a se modificar internamentepor causa de uma falha; Esse é o conceito de mascaramento de falhas, através deredundância ou replicação. Um determinado serviço, que se quer altamentedisponível, é colocado por trás de uma camada de abstração, que permita mudançasem seus mecanismos internos mantendo intacta a interação com elementosexternos. 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 sistemacomputacional, 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 eassumindo seus serviços caso perceba que algum deles falhou. Outra possibilidade importante da alta disponibilidade é fazer isto comcomputadores básicos, como os que se pode comprar até num supermercado. Acomplexidade pode estar apenas no software. Mais fácil de desenvolver que ohardware, o software de alta disponibilidade é quem se preocupa em monitoraroutras máquinas de uma rede, saber que serviços estão sendo prestado, quem osestá prestando, e o que fazer quando uma falha é percebida (SZTOLTZ, 2003).
  16. 16. 164 FERRAMENTAS UTILIZADAS4.1 HEARTBEAT O programa Heartbeat é usado para construir cluster da altíssimadisponibilidade; Heartbeat significa batimento cardíaco. Este termo é usado paradefinir 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, amáquina secundária assumirá que a primária falhou e tomará para si os serviços queestavam 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 ouunicast; Esta escolha depende da aplicação que será dada ao Heartbeat. Noentanto, se o servidor primário estiver ligado apenas ao servidor de backup, éaconselhável utilizar o unicast, por enviar um pacote único e, assim, evitarcongestionamento 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. 17. 17 O Heartbeat deverá ser instalado em ambos os servidores e todos os arquivosdevem estar iguais nos dois nodos; É possível configurar o tempo entre osHeartbeats, o tempo de alerta no caso do Heartbeat não chegar a tempo e o tempoem que se considera o nodo como morto; O Heartbeat utiliza a porta 694 para a comunicação bcast ou ucast. Existeuma 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 falhaqualquer, 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 IPestá associado a um domínio. Quando o nodo primário falhar, o nodo secundárioassume o IP virtual, ou seja, o IP do cluster. Isso vai permitir continuar com ofuncionamento dos serviços que estavam a ser usados pelo nodo primário com omesmo domínio (HEARTBEAT, 2008). O funcionamento do Heartbeat é apresentado na Figura 4. Uma vez aconexão estabelecida, começa o processo dos Heartbeats. Quando há um Heartbeatperdido, vem juntamente com ele uma tentativa de reconexão, dessa tentativa duashipóteses é tomada em conta. A primeira hipótese é o caso da tentativa permitida eentão pode acontecer que a conexão seja restabelecida ou perdida. A segundahipótese é o caso da tentativa inválida e daí, só há uma saída que é a conexãoperdida. A chamada conexão terminada acontece quando se decide desconectar ouquando a conexão é perdida (HEARTBEAT, 2008).4.2 DRBD O DRBD (Distributed Replicated Block Device) é o software que realiza areplicação de dados entre os nós do cluster, fazendo o espelhamento (mirroring) deum dispositivo de blocos através de uma conexão de rede dedicada. Ele pode serentendido como um RAID 1 via rede, onde recebe os dados a seremgravados,escreve no disco local e os envia para o outro computador, onde os dadostambém são gravados no disco, a figura 2 ilustra o que é descrito acima:
  18. 18. 18 Fgura 03: DRBDFonte: 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 emuma camada superior aos dispositivos de bloco usados para armazenamento (discolocal) 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ó emtempo 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 temacesso ao dispositivo DRBD (/dev/drbdX). Todo acesso ao disco passa a ser feitoatravés deste dispositivo. Quando é realizada uma operação de escrita, os dadossão gravados no disco local e enviados para o nó com o dispositivo secundário. Osecundário simplesmente escreve o dado no dispositivo da camada inferior, queneste caso, é o disco local do nó remoto. As operações de leituras sãosemprerealizadas no nó principal. Para usar o DRBD, é recomendável que o sistema de arquivos a ser utilizadotenha suporte a journaling. Caso contrário, quando o nó primário estiver indisponívele houver o failover, o fsck deverá ser executado. Se o nó que falhou retornar, ele se torna o secundário e tem que sincronizarseus 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 dispositivoDRBD, não se deve tentar montar diretamente nenhum dos discos aos quais ele faz
  19. 19. 19referência. O acesso aos dados deve ser feito através do dispositivo DRBD, casocontrário, corre-se o risco de haver corrupção dos dados e tornar todo o conteúdo dodisco inacessível.4.3 MON O Mon tem como principal finalidade a de ser um monitor do sistema. Quandoele detecta uma falha é possível enviar um e-mail e até mesmo fazer com que eleacione 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 Perlou shell script, similarmente ao Nagios; Os scripts podem ser complexos a ponto deexecutarem queries pré-definidas em bancos de dados remotos ou também enviaremails de alerta ao sysadmin, no nosso caso ele ficara responsável pelomonitoramento do serviço samba, em caso de falha do serviço em algum dosservidores, ele emitira um alerta por e-mail e também notificará o Heartbeat, fazendocom que o outro servidor assuma o papel do que falhou, isto quer dizer: Elelevantará o serviço Samba na maquina secundária de forma transparente para ousuá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 possaminteragir com sistemas Windows em uma rede. Através do Samba, é possível acessar, de uma estação de trabalho com osistema 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 Linuxofereça esses serviços de forma transparente para estações de trabalho rodando osistema Windows. Neste estudo de caso será abordado a implementação de um simples sistemade alta disponibilidade em um servidor de arquivo usando sistema operacional Linux
  20. 20. 20com Samba, demonstrando como esse arquitetura funciona; O interessante dessademonstração é que a partir dela pode-se modificar sua estrutura adaptando adiversas 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) secomuniquem sem a necessidade de modems ou outros dispositivos entre eles. Assim como o cabo null modem, um cabo Ethernet crossover é usado paraconectar duas interfaces de rede Ethernet sem que sejam necessários switches ououtros dispositivos entre elas. Visando obter alta disponibilidade, a ligação dos nós para formação do clusterdeve ser redundante, evitando assim, um ponto único de vulnerabilidade. Para issoserão usadas duas conexões: uma através da interface serial, e outra através dainterface Ethernet. Deve-se conectar o cabo null modem nas portas seriais dos doiscomputadores, e conectar o cabo Ethernet crossover em uma das interfaces de redede cada computador, deixando a outra interface de rede para conexão com a redelocal que irá acessar serviços nestes servidores, a figura a baixo mostradetalhadamente:
  21. 21. 21 Figura 4: Cluster de Alta disponibilidade Fonte: Autor5.2 CONFIGURAÇÕES DOS SERVIDORESSERVIDOR PRIMÁRIOSO: Debian GNU/Linux 5.0 – LennyHostname: host1Kernel: 2.6.26-2-686HD: 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/sda3Eth0: 192.168.0.1 (Lan)Eth1: 10.0.0.10 (H.A. Cabo crossover)ttys0: Porta SerialIP Virtual: 192.168.0.10Serviços: Heartbeat-2, DRBD 8.0, Mon 0-99-2.6 e Samba 3.2.5SERVIDOR SECUNDÁRIOSO: Debian GNU/Linux 5.0 - Lennyhostname: host2Kernel: 2.6.26-2-686HD: 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/sda3Eth0: 192.168.0.2 (Lan)Eth1: 10.0.0.20 (H.A. - cabo crossover)ttys0: Porta Serial
  22. 22. 22IP Virtual: 192.168.0.10Serviç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 possamser pingadas por nomes, para isso altere o arquivo hosts:host1:# mcedit /etc/hostsDeixar como segue:127.0.0.1 localhost127.0.1.1 host1.dominio.com.br host1192.168.0.2 host2.dominio.com.br host2host2:# mcedit /etc/hostsDeixar como segue:127.0.0.1 localhost127.0.1.1 host2.dominio.com.br host2192.168.0.1 host1.dominio.com.br host1Para verificar:Host1:# ping host2Host2:# ping host15.3 INSTALAÇÃO DOS SOFTWARE NECESSÁRIOSHost1:# 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 mceditHost2:# apt-get install drbd8-utils drbd8-modules-2.6.26-2-686
  23. 23. 23# apt-get install heartbeat-2# apt-get install samba# apt-get install mon# apt-get install mc #Editor de texto mcedit5.4 CONFIGURANDO DRBD Nem todas distribuições possuem os dispositivos do drbd1 criados em /dev ou o pacotecorrespondente cria na instalação. Verifique se eles existemHost1:# 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;doneHost2:# for i in $(seq 0 15) ; do mknod /dev/drbd$i b 147 $i;doneO próximo passo é configurar o arquivo /etc/drbd.conf nas duas máquinas (deixar oarquivo exatamente igual nas duas)Host1:# mcedit /etc/drbd.confHost2:# mcedit /etc/drbd.confAdicione as linhas abaixo:----------------------------------------------------------------------------------------------------------------global {usage-count yes;}
  24. 24. 24common {# 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@dominio.com";split-brain "echo split-brain. drbdadm -- --discard-my-data connect /$DRBD_RESOURCE ? | mail -s DRBD Alert pager@braslink.com";}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 valorafter-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 redeal-extents 257;}on host1 {device /dev/drbd1; #aqui será o endereço do dispositivo (disco) virtual do DRBDdisk /dev/sda2; #aqui será a partição do disco que será replicadaaddress 192.168.0.1:7788; #IP do host1meta-disk internal; #onde será colocado o meta-disk do drbd (ficará junto com o resto do sistema)
  25. 25. 25}on host2 {device /dev/drbd1; #aqui será o endereço do dispositivo (disco) virtual do DRBDdisk /dev/sda2; #aqui será a partição do disco que será replicadaaddress 192.168.0.2:7788; #IP do host2meta-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 /sejusHost2:# umount /sejusEm seguida, retirare a entrada para a pasta do fstab das duas máquinas (oucomente com tralha):Host1:# mcedit /etc/fstabHost2:# 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=128Host2:# dd if=/dev/zero of=/dev/sda2 bs=1M count=128Criar o disco virtual:Host1:# drbdadm create-md dadosHost2:# drbdadm create-md dadosAtar o disco nas duas máquinas:
  26. 26. 26Host1:# drbdadm attach dadosHost2:# drbdadm attach dadosSincronizar:Host1:# drbdadm syncer dadosHost2:# drbdadm syncer dadosIniciar replicação no Host1:Host1:# drbdadm -- --overwrite-data-of-peer primary dadosReiniciar o serviço nas duas máquinas:Host1:# /etc/init.d/drbd restartHost2:# /etc/init.d/drbd restartVerifique se a sincronização começou:Host1:# cat /proc/drbdVerifique 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:330: 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[==>.................] synced: 18.5% (3892/4769)Mfinish: 0:00:39 speed: 99,760 (99,760) K/secresync: used:2/61 hits:56431 misses:56 starving:0 dirty:0 changed:56act_log: used:0/257 hits:0 misses:0 starving:0 dirty:0 changed:0Após a sincronização ter terminado, verifique o resultado do comando novamente:
  27. 27. 27Host1:# cat /proc/drbdVerifique 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:330: 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:0resync: used:0/61 hits:304925 misses:299 starving:0 dirty:0 changed:299act_log: used:0/257 hits:0 misses:0 starving:0 dirty:0 changed:0Definindo máquina primária:Host1:# drbdadm primary allHost2:# drbdadm secondary allFormate o disco virtual no Host1:Host1:# mkfs.ext3 /dev/drbd1Caso precise alterar a máquina primária e secundária, use:Host1:# drbdadm secondary allHost2:# drbdadm primary allAdicione no fstab das duas máquinas:host1:# mcedit /etc/fstabAdicione a linha:---------------------------------------------------------------------------------------------------------------/dev/drbd1 /sejus ext3 noauto 0 0---------------------------------------------------------------------------------------------------------------
  28. 28. 28Host2:# vim /etc/fstabAdicione a linha:/dev/drbd1 /sejus ext3 noauto 0 0Realizando testes:Monte a pasta no Host1:Host1# mount /sejusCrie um pasta vazia na partição montada:Host1# cd /sejus# mkdir testeVerifique se a pasta foi criado:Host1# ls /sejusDesmonte a pasta:Host1# umount /sejusDefina o Host1 como secundário:Host1# drbdadm secondary allDefina o Host2 como primário:Host2# drbdadm primary allMonte a pasta no Host2:Host2# mount /sejusVerifique se o arquivo foi criado:Host2# ls /sejus
  29. 29. 295.5 CONFIGURANDO O HEARTBEAT.Host1:# mcedit /etc/ha.d/ha.cfHost2:# vim /etc/ha.d/ha.cfDeixar como segue:#informe os nomes dos computadores que formam a replicação(deve ser igual asaída do comando "uname -n-----------------------------------------------------------------------------------node host1node host2udp eth1 #qual a interface vai ser usada para comunicaçãoserial /dev/ttys0 # indica a porta serial que vai ser usada para comunicaçãobaud 19200 #Define a baud rate para as portas seriais. O valor padrão é 19200debugfile /var/log/ha-debug #arquivos de loglogfile /var/log/ha-log #arquivos de logkeepalive 1 #freqüência, em segundos, da verificação das máquinasdeadtime 5 #tempo mínimo para declarar a outra máquina como mortaauto_failback on #Faz com que quando o servidor primário suba, ele reassuma os serviçosConfigurar o arquivo haresources nas duas máquinasHost1:# mcedit /etc/ha.d/haresourcesNode2:# vim /etc/ha.d/haresourcesDeixar como segue:----------------------------------------------------------------------------------------------------------------host1 drbddisk::dados Filesystem::/dev/drbd1::/sejus::ext3 192.168.0.10 sambaObs.: 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. 30. 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 dareplicação):host1:# mcedit /etc/ha.d/authkeyshost2:# mcedit /etc/ha.d/authkeysDeixar como segue:----------------------------------------------------------------------------------------------------------------auth 33 md5 digiteumafrase----------------------------------------------------------------------------------------------------------------Mudar os atributos do arquivo authkeysHost1:# chmod 600 /etc/ha.d/authkeysHost2:# chmod 600 /etc/ha.d/authkeysReinicie o serviço do heartbeatHost1:# /etc/init.d/heartbeat restartHost2:# /etc/init.d/heartbeat restart5.6 CONFIGURANDO MON Essa configuração monitorará o processo do Samba da seguinte maneira: eleverificará de 10 em 10 segundos (interval) se o Samba está respondendo. Caso omesmo 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 amáquina slave assumir e irá disparar um e-mail através do script mail.alert com o
  31. 31. 31assunto explícito em -S “ASSUNTO” para root@localhost O arquivo heartbeat.alertpoderá ser baixado aqui, já que o mesmo não vem instalado por default.Host1:# mcedit /etc/mon/mon.cfHost2:# mcedit /etc/mon/mon.cf---------------------------------------------------------------------------------------------------------------alertdir = /usr/lib/mon/alert.dmondir = /usr/lib/mon/mon.dmaxprocs = 20histlength = 100randstart = 60shostgroup samba localhostwatch sambaservice sambainterval 10smonitor samba.monitorallow_empty_groupperiod wd {Sun-Sat}alert heartbeat.alertalert mail.alert -S "Servidor Samba está parado" root@localhostupalert mail.alert -S "Servidor Samba está OK" root@localhostalertevery 1m5.7 CONFIGURANDO O SAMBAHost1:# mcedit /etc/samba/smb.confHost2:# mcedit /etc/samba/smb.conf-------------------------------------------------------------------------------------------------------------[global]workgroup = WORKGROUP # Ou seu dominio.com.br
  32. 32. 32server string = Dadosnetbios name = Dadosdns proxy = nolog file = /var/log/samba/%m.logmax log size = 500debug level = 1security = shareencrypt passwords = yessmb passwd file = /etc/samba/smbpasswdusername map =/etc/samba/smbuserssocket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192unix charset = iso-8859-1winbind uid = 10000-20000winbind gid = 10000-20000winbind enum users = yeswinbind enum groups = yestemplate homedir = /dev/nulltemplate shell = /dev/nullwinbind use default domain = yespassdb backend =smbpasswdpreferred master = nowins support = yes[SEJUS]path = /sejus/read only = Nocreate mask = 0777force create mode = 0777directory mask = 0777force directory mode = 0777guest ok = yes6 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. 33. 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 umacesso a um dos compartilhamentos disponibilizados no servidor Samba usando oendereço IP do cluster (192.168.0.10), e em seguida, foram copiados vários arquivospara 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 sendoexecutado, 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 everificar se o failover ocorreria com sucesso. Após aproximadamente 5 segundos oserviço Samba estava disponível novamente. Para confirmar se o serviço estavaexecutando no outro nó, foi feita uma conexão ssh, novamente usando o endereçoIP do cluster, e identificado que o servidor que estava respondendo era o Host2, oque significa que o failover foi bem sucedido. Com o intuito de checar se houve a replicação de arquivos para o segundonó, foi feito um novo acesso ao servidor Samba através do IP do cluster, econstatado 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 Host1e, como o cluster estava configurado com a opção auto_failback ativada, novamentefoi 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, simulandoalgum problema de inicialização ou interrupção do serviço, constatando que foienviado um e-mail para o usuário root notificando a parada e fazendo com que umalerta (heratbeat.alert) parasse o heartbeat, ocasionando a elevação dos serviços noHost2 em aproximadamente 5 segundos
  34. 34. 34 Para finalizar os testes e verificar se a solução estava tolerante a falhas deconectividade, foi desconectado o cabo de rede que ligava o Host1 a rede local, poronde os clientes acessavam os serviços disponibilizados. Após pouco mais de 5segundos, ocorreu um failover provocado pelo componente MON, para que osclientes pudessem acessar o serviço através do outro nó.
  35. 35. 357 CONSIDERAÇÕES FINAIS O conceito de alta disponibilidade não deve, e nem pode, ser uma novidadepara os administradores de sistemas, principalmente em ambientes computacionaisonde a disponibilidade é uma característica crítica. Esse conceito, que não érecente, está sendo amplamente disseminado, e ganha importância diretamenteproporcional a influência que os sistemas de computação exercem nas empresas ouentidades que sustentam. Quando relacionamos alta disponibilidade com ossistemas Linux, está na sombra desse conceito dois maduros softwares livres quepermitem preencher alguns requisitos de sua implementação: o Heartbeat e oDRBD. Ambos são parte integrante do conhecido projeto Linux-HA. Este artigo mostrou como pode ser implementado um ambiente de altadisponibilidade através de software livre, no exemplo utilizado, abordamos umservidor de arquivo samba, mas podendo facilmente ser modificado para utilizaçãoem 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 clientesfosse atendida, também simulamos a falha de conectividade, que ocasionaram ofailover e o failback com sucesso. O sistema permite paralisação para manutenção planejada de cada um deseus componentes, desde que não seja simultaneamente. Caso haja a necessidadede 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çosprestado e muito menos ter que fazer horas extras para não estar atrapalhando aprodutividade 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 escutaras famosas frases do chefe, como por exemplo: "Quanto tempo o servidor demora avoltar, 5 minutos?"
  36. 36. 36 REFERÊNCIASELLENBERG, L. Quick Start Guide For DRBD 0.7. [on-line]. Disponível nainternet via http://wiki.linux-ha.org/DRBD_2fQuickStart07. Arquivo capturadoem 2 de abril de 2005.ROBERTSON, A. Heartbeat Home Page. [on-line]. Disponível na internet viahttp://www.linux-ha.org/heartbeat/. Arquivo capturado em 2 de abril de 2005.BAIOCCO. DOUGLAS. Instalação do DRBD + Heartbeat + Samba. Disponivel nainternet, via :http://www.guiadohardware.net/tutoriais/drbd-heartbeat-samba/ .Acessado em 01 de Dezembro de 2010FILHO, 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: BerkeleyBrasil, 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 ConectivaLinux. 2003. Http://www.conectiva.com.br.MARCO, L. M. d. Computação de Alto Desempenho: Clusters. Artigo publicadopela 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 deServidores BDC em Ambientes Samba. Minas Gerais: Monografia apresentada naUniversidade Federal de Lavras.BASSAN, Ramon. Avaliação de Cluster de Alta Disponibilidade Baseado emSoftware Livre. Monografia defendida e aprovada na FAJ em 2008

×