Roberto Benedito de Oliveira Pereira

Alta Disponibilidade em Sistemas GNU/LINUX utilizando as ferramentas Drbd, Heartbeat e Mon

Monograa apresentada ao Departamento de Cincia da Computao da Universidade Federal de Lavras como parte das exigncias do curso de Ps-Graduao "Lato Sensu" Administrao em Redes Linux para obteno do ttulo de Especialista em "Administracao em Redes Linux".

Orientador Prof. DSc. Ricardo Martins De Abreu Silva

Lavras Minas Gerais - Brasil 2005

Roberto Benedito de Oliveira Pereira

Alta Disponibilidade em Sistemas GNU/LINUX utilizando as ferramentas Drbd, Heartbeat e Mon

Monograa apresentada ao Departamento de Cincia da Computao da Universidade Federal de Lavras como parte das exigncias do curso de Ps-Graduao "Lato Sensu" Administrao em Redes Linux para obteno do ttulo de Especialista em "Administracao em Redes Linux". Aprovada em 12 de setembro de 2005

Prof. Esp. Rmulo Maia Alves

Prof. Esp. Samuel Pereira Dias

Prof. Esp. Anderson B. dos Santos

Prof. Esp. Andre Zambalde

Prof. DSc. Ricardo Martins De Abreu Silva (Orientador) Lavras Minas Gerais - Brasil

Agradecimentos
Agradeo a Deus, a So Benedito, Santa Rita e aos meus pais, que esto sempre presentes nos momentos mais difceis da minha vida, apoiando e respeitando as minhas decises, agradeo tambm aos meus amigos, ao meu orientador e a todos aqueles que me ajudam e que me ajudaram.

vi

Resumo
Sistemas de alta disponibilidade so sistemas que tem como principal nalidade tornar os servios prestados por um servidor disponvel o maior tempo possvel ao usurio de forma que, aps a falha de um servidor primrio, um servidor secundrio supra a falha do mesmo, proporcionando com isso maior qualidade nos servios prestado pelo mesmo. Para isso, so utilizadas tanto tcnicas de hardware como de software, onde nesta monograa focada mais a parte de software, que dentre eles, destacam-se o Drbd, Heartbeat e o Mon. Nesta monograa ser apresentado a terica da alta disponibilidade, bem como os resultados obtidos na implementao de um estudo de caso de um sistema de alta disponibilidade.

vii

viii

Dedico est monograa a todos os usurios de LINUX, Universidade Federal de Lavras e em especial a todos os membros da ARL.

ix

Sumrio
1 2 Introduo Linux 2.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Tipos de licenas de software . . . . . . . . . . . . . . . . . . . . 2.3 Viso geral do sistema operacional Linux . . . . . . . . . . . . . Cluster 3.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Princpio de um cluster . . . . . . . . . . . . . . . . . . . . . . . 3.3 Tipos de cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . Alta Disponibilidade 4.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . 4.2 Conceitos . . . . . . . . . . . . . . . . . . . . . . . 4.3 Conabilidade e Disponibilidade . . . . . . . . . . . 4.4 Taxonomia de Alta-Disponibilidade . . . . . . . . . 4.4.1 Disponibilidade bsica . . . . . . . . . . . . 4.4.2 Alta disponibilidade . . . . . . . . . . . . . 4.4.3 Disponibilidade contnua . . . . . . . . . . . 4.5 Avarias, erros e falhas . . . . . . . . . . . . . . . . . 4.6 Fases na tolerncia a falhas . . . . . . . . . . . . . . 4.6.1 Deteco de erros . . . . . . . . . . . . . . . 4.6.2 Connamento de estragos e avaliao . . . . 4.6.3 Recuperao de erros . . . . . . . . . . . . . 4.6.4 Tratamento de falhas e servios continuados . 4.7 Software utilizado . . . . . . . . . . . . . . . . . . . xi 3 5 5 7 7 9 9 10 11 13 13 14 14 15 15 16 17 17 18 18 20 20 20 21

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

Ferramentas 5.1 Drbd . . . . . . . . . . 5.1.1 Introduo . . 5.1.2 Como funciona 5.1.3 Como instalar . 5.1.4 Comandos . . 5.2 Heartbeat . . . . . . . 5.2.1 Introduo . . 5.2.2 Como funciona 5.2.3 Como instalar . 5.2.4 Comando . . . 5.3 Mon . . . . . . . . . . 5.3.1 Introduo . . 5.3.2 Como instalar . 5.3.3 Comando . . . Estudo de Caso 6.1 Estrutura . . . . . . . 6.2 Drbd . . . . . . . . . 6.2.1 Congurao 6.2.2 Inicializao 6.3 Heartbeat . . . . . . 6.3.1 Congurao 6.3.2 Inicializao 6.4 Mon . . . . . . . . . 6.4.1 Congurao 6.4.2 Inicializao 6.5 Teste no sistema . . . Concluso

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

23 23 23 23 24 24 31 31 31 32 33 33 33 33 35 39 39 42 42 42 44 44 45 45 45 47 47 49 53 53 54 59 63 85 85 86

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

A Ferramentas - Congurao A.1 Drbd . . . . . . . . . . . . A.1.1 Formato do arquivo A.2 Heartbeat . . . . . . . . . A.3 Mon . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

B Log B.1 Drbd - Servidor ND . . . . . . . . . . . . . . . . . . . . . . . . . B.2 Drbd - Servidor 03 . . . . . . . . . . . . . . . . . . . . . . . . . xii

B.3 B.4 B.5 B.6 B.7 B.8 B.9 B.10 C CD

Heartbeat - Servidor ND . . . . . . . . . . . . . . . . . . . . . . 87 Heartbeat - Servidor 03 . . . . . . . . . . . . . . . . . . . . . . . 88 Mon - Servidor 03 . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Primeiro servidor cai . . . . . . . . . . . . . . . . . . . . . . . . 89 Segundo servidor assume . . . . . . . . . . . . . . . . . . . . . . 90 Primeiro servidor volta . . . . . . . . . . . . . . . . . . . . . . . 91 Segundo servidor libera os servios . . . . . . . . . . . . . . . . 91 Servidor de Alta-Disponibilidade perde conectividade com o Roteador 92 93

xiii

xiv

Lista de Figuras
6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 Servidor primrio . . . . . . . . . . . . . . . . . Servidor secundrio . . . . . . . . . . . . . . . . Switch . . . . . . . . . . . . . . . . . . . . . . . Roteador . . . . . . . . . . . . . . . . . . . . . . Mapeamento geral da rede de alta disponibilidade Congurao do drbd.conf . . . . . . . . . . . . Congurao do ha.cf . . . . . . . . . . . . . . . Congurao do haresource . . . . . . . . . . . Congurao do authkeys . . . . . . . . . . . . . Congurao do mon.cf . . . . . . . . . . . . . . Congurao do auth.cf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 40 41 41 41 43 44 44 45 45 46

xv

xvi

Lista de Tabelas
4.1 4.2 Medindo a disponibilidade de um servidor . . . . . . . . . . . . . Classicao da disponibilidade . . . . . . . . . . . . . . . . . . 15 15

Captulo 1

Introduo
O objetivo principal desta monograa apresentar a soluo de Alta Disponibilidade em um Sistema Operacional GNU/Linux elucidando as principais caractersticas do funcionamento de um Cluster de Alta Disponibilidade, buscando com isso divulgar, por meios de um relatrio escrito, um conjunto de poderosas ferramentas de baixo custo que unidas visam alcanar esse objetivo, objetivo esse que ainda no muito explorado pelos administradores de sistemas. Um sistema de Alta Disponibilidade tem como principal caracterstica de suprir a falha de um servidor em um sistema on-line de forma automtica para que os servios prestado pelo mesmo que o maior tempo possvel disponvel ao usurio e o mais importante que nesta monograa, isso foi feito de uma forma que no foi necessrio gastar muito dinheiro para isso. Desde o surgimento do sistema operacional Linux, lembrando que ele foi um dos precursores do movimento do software livre, tendo tambm como principal caracterstica ser um dos grandes personagens da concretizao dessa ideologia, onde que at pouco tempo atrs, a participao do Linux em servidores de misso critica se restringia bastante, pois ainda no se tinha uma estrutura muito bem estabelecida e ele ainda no era robusto o suciente para isso. Porem essa situao se alterou, quando foram desenvolvidas solues de baixo custo que supriro a necessidade do Linux preparando-o para tal. Grupos de desenvolvedores deram inicio a vrios projetos open-source para pesquisarem tais solues, como resultado disso, surgiram vrios projetos, dentre eles o Drbd, o Heartbeat e o Mon, que tiveram a capacidade de solucionar problemas de disponibilidade de servio, replicao e monitoramento de servios. Basicamente o termo alta disponibilidade consiste em tentar manter um servio provido por um ou mais servidores o mximo de tempo possvel disponvel, onde que na falta de um dos servidores, seja ela por queima de um diso, pela queima 3

de uma placa de rede ou qualquer coisa do tipo, seja suprido automaticamente por outro servidor, de tal forma que no interrompa a disponibilidade do servio. Vrias tcnicas so utilizadas para isso, primeiramente necessrio ter em mente, que a alta disponibilidade no consiste somente a software instalados, mas tambm de uma estrutura de hardware. Quando dito alta disponibilidade deve ser levado em considerao tambm a redundncia tanto no que diz respeito a hardware, como por exemplo: hubs, switchs, roteadores, fonte de alimentao, quanto no que diz respeito a software, como por exemplo: programa de replicao, programas de decises e programas de monitoramento. No que diz respeito a parte de software est monograa aborda os seguintes programas: o Drbd, o Heartbeat e o Mon. O Drbd tem como principal nalidade a de estar replicando as informaes de um servidor em outro, utilizando como meio de transmisso a rede. O Heartbeat responsvel pela vericao e tomada de decises. O Mon responsvel pelo monitoramento dos servios e enviar, caso congurado, informaes ao Heartbeat. Assim esta monograa foi estruturada em 6 partes, de tal forma a elucidar primeiramente os conceitos bsicos para um melhor entendimento do leitor e logo, partindo para a parte teorica de Cluster de alta disponibilidade. No Captulo 2 foi apresentado uma pequena historia de um grande sistema operacional que surgiu na Universidade de Helsinky na Finlndia em 1991, sistema esse, que atualmente conhecido com Linux. Nele foi abordado tambm tipos de licenas bem como uma viso geral desse formidvel sistema operacional. No Captulo 3 foi apresentado a teoria geral de Cluster visando elucidar seu principio de funcionamento e principalmente destacar os principais tipos de Cluster que se tem atualmente que so Cluster de Processamente, Cluster de Balanceamento de Carga e Cluster de Alta Disponibilidade. No Captulo 4 foi apresentado a teoria de um Cluster de Alta disponibilidade tendo como principal caracterstica a de estar abortando os conceitos de Alta Disponibilidade , bem como estar criando um jargo em comum para o meio de forma a padronizar os termos utilizados, alm disso demonstrar a diferena entre avaria, erros e falhas e nalmente elucidar as fases na tolerncia a falha, que consiste basicamente na deteco de erros, connamento de estragos, recuperao de erros e tratamento de falhas. E nalmente no Captulo 6 ser apresentado um estudo de caso que visa comprovar a funcionalidade das ferramentas bem como da teoria apresentada.

Captulo 2

Linux
2.1 Introduo

O Linux um sistema operacional criado por Linus Torvalds na Universidade de Helsinky na Finlndia em 1991. O Linux tem em suas inmeras caractersticas importantes, a de ser um sistema operacional de cdigo fonte aberto e de ser distribudo gratuitamente pela Internet, conforme disse (BONAN, 2003). Segundo (NORTON; GRIFFITH, 2000) o Linux representa um novo modelo de computao, bem como de distribuio. A primeira verso ocial do Linux foi liberada em 5 de outubro de 1991, que teve como principais caractersticas,alguns programas GNU1 , como por exemplo, o Bash2 e o GCC3 . Dentre inmeras caractersticas que o Linux tem possvel destacar: 1. Poder: O sistema operacional Linux tem a capacidade de transformar microcomputadores considerados obsoletos e ultrapassados em uma mquina poderosa para determinados tipos de tarefas. Isso possvel por diversos fatores, entre eles, por ter sido projetado desde o inicio para permitir o acesso a hardware e perifricos a um nvel bastante bsico.
GNU uma sigla recursiva que signica Gnu is Not Unix e uma organizao dedicada criao de software livre. O Projeto GNU foi iniciado em 1984 para desenvolver um sistema operacional completo, compatvel com o UNIX, que fosse software livre, para mais informaes acesse http://www.gnu.org/home.pt.html 2 Interpretador de linha de comando 3 Compilador da linguagem C do projeto GNU, ele gratuito e de cdigo fonte aberto
1

2. Preo: Por ser gratuito, o Linux desenvolvido e mantido por vrios programadores voluntrios.A maioria das distribuies Linux vem com vrios pacotes de software que valem muito dinheiro se fossem adquiridos de empresas. 3. Desenvolvimento: O sistema operacional Linux oferece vrias linguagens de programao maduras e respeitadas ferramentas de desenvolvimento. O Linux possui disponveis diversos conjunto de ferramentas, IDEs e principalmente bibliotecas que tornam esse sistema operacional um sonho para os desenvolvedores. 4. Portabilidade: Uma das suas principais caractersticas justamente a de ele ser executado em uma diversa gama de arquiteturas de processadores diferentes, como por exemplo: i386, Alpha, Arm, M68k, Mips, Ppc e Sparc. 5. Distribuies: Conforme disse (NORTON; GRIFFITH, 2000) ao contrrio da crena popular, o Linux na verdade apenas a poro Kernel do sistema operacional. J as distribuies so um conjunto de pacotes de programas, normalmente regido pela GNU, mais o Kernel Linux, onde este conjunto se pode dar o nome de GNU/Linux ou somente Distribuio Linux. Normalmente a maioria das distribuies esto disponveis gratuitamente e para compra no varejo. A nica diferena entre se baixar uma distribuio pela internet ou a de comprar que quando se compra, recebe-se os manuais para auxiliar na congurao mais a assistncia tcnica. Existem inmeras distribuies Linux disponveis na Internet, dentre elas, podem ser citadas a Suse Linux, Turbo Linux, Debian Linux e Slackware Linux4 . Segundo (SZTOLTZ; TEIXEIRA; RIBEIRO., 2003) de uma forma geral, pode-se dizer que o Linux um sistema operacional multiusurio, multitarefa e multiprocessado, de livre distribuio, baseado no sistema operacional UNIX . A origem do nome Linux vem justamente do nome de seu criador Linus Torvalds. Ser multiusurio signica ter a possibilidade de que vrias pessoas utilizem o mesmo computador e ao mesmo tempo, utilizando para isso conexes remotas ou terminais, essa caracterstica, a de ser multiusurio muito importante, principalmente no quesito de permisses, pos atravs disso possvel controlar o acesso a programas, que podem ser chamado de processos e tambm controlar o acesso
Esta ser a distribuio usada nesta monograa, a mesma pode ser baixado em www.slackware.org
4

aos arquivos , de forma que cada usurio tenha uma permisso diferente do outro, permisses esta que podem ser de execuo, leitura e gravao. Quando se diz que o Linux multitarefa isso signica que ele capaz de executar diversos programas, tarefas ou servios ao mesmo tempo, de forma que possibilite rodar simultaneamente vrios programas, como por exemplo: um servidor web, um servidor de e-mail, um servidor de arquivo e ate mesmo um banco de dados. Vale ressaltar que tudo isso feito de forma transparente para o usurio. J no que diz respeito a multiprocessado, a caracterstica que o Linux tem de suportar mais de um processador e capaz de utilizar de maneira inteligente esses processadores, de uma forma a obter o melhor desempenho possvel.E nalmente, a livre distribuio representa que ele pode ser distribudo de forma que no se tenha que pagar por licenas de uso.

2.2

Tipos de licenas de software

O Linux tem o seu cdigo fonte liberado na forma de software livre, aonde importante elucidar que software livre, comummente chamado de livre distribuio usado para caracterizar o software que pode ser copiado livremente e que possui junto o seu cdigo fonte para que caso ocorra a necessidade, o usurio o consulte e ate mesmo o altere, porem importante salientar tambm que existem vrios tipos de licena, sendo a mais utilizada a GPL5 . J quando dito freeware o programa que gratuito e no contem seu cdigo fonte junto. J o shareware quando um programa pode ser copiado mas ele funcionara somente em modo de demonstrao aonde expirado o tempo o usurio dever comprar a sua licena. E nalmente o software comercial que aquela que necessrio comprar uma licena de uso da empresa que o desenvolveu e na maioria das vezes tem o cdigo fonte no disponvel.

2.3

Viso geral do sistema operacional Linux

Basicamente, conforme disse (SZTOLTZ; TEIXEIRA; RIBEIRO., 2003) o sistema operacional Linux compostos dos seguintes componentes: kernel, aplicaes de sistema e aplicaes de usurio. Embora o kernel do Linux seja uma das partes mais importantes do sistema operacional, ele por si s no constitui o sistema como um todo, aonde ele
5

General Public License - Licena Pblica Geral.

somente o ncleo do sistema e tem como principal nalidade a de ser responsvel pelas funes de mais baixo nvel, dentre elas possvel citar: gerenciamento de memria, gerenciamento de processos e ate mesmo gerenciamento das CPUs.Alm disso ele ainda responsvel pela parte do suporte ao sistema de arquivos, perifricos, dispositivos e das placas de forma geral. O utilizados do Linux deve ter sempre em mente que o kernel do Linux pode ser compilado 6 de forma que ele se adeque melhor ao tipo de mquina e ao tipo de servios e tarefas que essa mquina vai desempenhar. Um bom exemplo justamente quando se necessite de algum recurso, como por exemplo um protocolo de comunicao que no veja por padro compilado ou at mesmo se no houver a necessidade de se usar um determinado tipo de protocolo ou at mesmo um determinado tipo de modulo. Esse tipo de adequao resulta em um kernel menor, com isso liberando mais espaos em memria para os programas que sero executados. No que diz respeito a aplicaes de sistema, o kernel faz um pouco sozinho, uma vez que provido por ele os recursos que so necessrios para que outro programas sejam executados, logo necessrio a utilizao de programas para implementar os vrios servios necessrio ao sistema operacional, conforme disse (SZTOLTZ; TEIXEIRA; RIBEIRO., 2003) A grande diferena entre a aplicao do sistema e a aplicao do usurio no que dis respeito ao propsito de cada aplicao, normalmente as aplicaes de sistema so necessrias para fazer o sistema funcionar, como por exemplo a funo init7 aonde ele o primeiro programa lanado aps a execuo do kernel na memria e ele responsvel por continuar o processo de boot executando os outros programas, enquanto que as aplicaes do usurios so os programas utilizados pelo cliente para realizar suas tarefas, como por exemplo, um editor de texto. Logo possvel concluir que as aplicaes do usurio so todos os programas utilizados pelo usurio para executar determinada tarefa, dentre elas possvel citar: Editor de texto, editor de imagens, navegador e leitor de email.

6 7

Compilao o processo de transformao de um cdigo-fonte em um programa executvel. para mais informaes consulte (SZTOLTZ; TEIXEIRA; RIBEIRO., 2003)

Captulo 3

Cluster
3.1 Introduo

Segundo (PITANGA, 2003) na sua forma mais bsica, um cluster um sistema que compreende dois ou mais computadores ou sistemas ( denominados nodos ) que trabalham em conjunto para executar determinada aplicaes ou realizar tarefas, de tal forma que os usurios do agrupamento de mquinas tenham a impresso de que somente um nico sistema responde para eles, criando assim uma iluso de um recurso nico. A tecnologia de Cluster teve seu inicio nas mquinas de alto desempenho, tambm conhecidas como supercomputadores, porm o seu desenvolvimento em PCs comeou em 1994 pela NASA1 , que teve como principal fator de motivao o alto preo dos supercomputadores. Conforme disse (PITANGA, 2003) esse projeto foi iniciado pela NASA, pelo principal motivo de que a mesma precisava de alto processamento na ordem de alguns gigaop. E nessa poca, uma mquina, a esse nvel de desempenho de processamento custava alguns milhes de dlares. Como resultado disso, Thomas Sterling e Donald J. Backer resolvero interligar 16 PCs, cada um era dotado de um processador 486 DX4-100, utilizava o sistema operacional Linux e os conectaram atravs de um rede. Inicialmente esse grupo de computadores interligado pela rede atingiu a marca de 70 megaops tendo um custo de aproximadamente quarenta mil dlares, o que equivale a pouco mais que dez por cento do preo de uma supercomputador equivalente na poca.Esse grupo de computadores recebeu o nome de Cluster podendo possuir vrios tipos de conguraes diferentes, tanto no quesito hardware como software.
1

National Aeronautics and Space Administration - www.nasa.org

Segundo (PITANGA, 2003) um Cluster composto por um conjunto de ns processadores ( PCs ou estaes ) autnomos e que interligados por uma rede comportam-se como um sistema de imagem nica. O que o autor (PITANGA, 2003) quis dizer com imagem nica que, pode ser um sistema paralelo ou distribudo, que pode ser multiprocessado ou no e podem estar geogracamente localizado em lugares diferentes, porm comportamse como um sistema centralizado, o que considerado como Cluster.

3.2

Princpio de um cluster

Para um Cluster ser realmente til, segundo (FILHO, 2002), ele deve seguir alguns conceitos bsicos como: 1. Comodidade: Todos os computadores, ao qual so chamados de ns, devem estar interconectados por uma rede genrica. J com relao ao sistema operacional, ele deve ser padro, pois o software de gerenciamento deve ir acima deles como uma aplicao comum. 2. Escalabilidade: Deve haver a possibilidade de adicionar aplicaes, perifricos, ns e at mesmos mais interconexes de rede sem interromper a disponibilidade dos servios do Cluster. 3. Transparncia: O Cluster, que construdo por vrios ns independentes e fracamente acoplados, deve parecer como se fosse apenas um computador para o cliente. 4. Conabilidade: O Cluster tem que ser dotado da capacidade de detectar falhas internas, e assim, tomar a deciso cabvel para solucionar o problema, para que o mesmo, no venha a prejudicar os servios oferecidos. 5. Gerenciamento e Manuteno: Umas das grandes diculdade de um Cluster a sua manuteno e principalmente a sua congurao, pois na maioria das vezes so tarefas morosas e que tem grande propenso a erros. Ento um Cluster deve ter um ambiente que facilite a sua congurao e principalmente a sua administrao, a m de que o Cluster no seja um grande sistema complexo, com um moroso trabalho de congurao e administrao. 10

3.3

Tipos de cluster

Cluster de Processamento Paralelo: Um Cluster de Processamento Paralelo tem como principal caracterstica a de que a cada novo processo inicializado, o Cluster pega o processo e divide entre os computadores. Utilizando essa tecnologia, o tempo de trmino de processamento desse processo torna-se consideravelmente menor do que se fosse realizado em um nico computador. Cluster de Balanceamento de Carga: Um Cluster de Balanceamento de Carga tem como principal nalidade estar distribuindo a carga de informaes entre servidores para que, no grupo de servidores, um nico servidor no que sobrecarregado e outros sem carga. Cluster de Alta Disponibilidade: Um Cluster de Alta Disponibilidade tem como principal nalidade a de manter os servios de um servidor disponvel o mximo de tempo possvel, onde para isso, utiliza-se tcnicas de replicao de arquivos e servios, e redundncia de hardware.

11

12

Captulo 4

Alta Disponibilidade
4.1 Introduo

Um sistema de Alta Disponibilidade tem como principal nalidade a de estar o maior tempo possvel disponvel para que seus servios, de alguma forma, no sejam interrompidos. Atualmente, as redes e hardware vm se tornando cada vez mais rpidos e de uma certa forma, mais baratos, o que os torna muito mais atrativos e a principal conseqncia disso que cada dia uma empresa acaba dependendo mais de um sistema computacional para realizar as tarefas crticas, onde algum tipo de falha, poderia causar danos materiais e at mesmo, em algumas ocasies, a perda de vidas humanas. Todo sistema est, de forma direta ou indireta, sucessvel a falhas, que podem ser contornadas, usando algumas tcnicas para garantir a continuidade desse servio. Segundo (FILHO, 2002) estas tcnicas podem ser tanto no nvel de hardware como no de software. Conforme disse (PITANGA, 2003) no so raras as situaes em que disco, fontes de alimentao, interfaces de rede e outras partes do sistema comea a apresentar falhas entre 30.000 e 80.000 horas de uso. Quando isso acontece e seu trabalho comea a ser penalizar, j hora de pensar em uma soluo que seja tolerante a falhas e que apresente uma boa relao custo/benefcio. Devido ao caso de algum sistema estar suscetvel a falhas, Clusters so implementados de tal modo que quando um servidor primrio falhe, outro servidor secundrio tome o lugar do primrio de forma transparente ao usurio. Segundo (PITANGA, 2003) um Cluster de Alta Disponibilidade visa manter a disponibilidade dos servios prestado por um sistema computacional replicando servio e servidores atravs da redundncia de hardware e recongurao de soft13

ware

4.2

Conceitos

Segundo (FILHO, 2002) primeiramente, necessrio compreender que a redundncia de recursos um pr-requisito para se atingir um alto grau de disponibilidade. Lembrando que as falhas no so restritas somente aos hardwares, mas tambm redes de computadores, s redes eltricas e localizao dos recursos. No que diz respeito a redes de computadores, deve ser levar em considerao os hubs, switchs, cabos, roteadores e todos equipamento fsico de uma rede. J com relao as redes eltricas deve se entender que qualquer tipo de oscilao ou indisponibilidade do servio deve ser suprima por outra forma de gerao de energia, como no-break e at mesmo geradores. E nalmente com relao a localizao fsica do recursos deve-se sempre lembrar que um local est propcio a furaces, enchentes, terremotos, roubos e at mesmo ataques terroristas, ento importante sempre ter equipamentos em locais distinto, onde na falta de um o outro o supra, de forma que no pare o servio. Ento, quando se diz que um sistema de alta disponibilidade, este sistema deve envolver no somente uma simples redundncia 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 considerao em um sistema de alta disponibilidade como medir a disponibilidade dos servios. Para tal deve ser levado em considerao o tempo em que o servios cam ativos e quanto tempo o servios cam foram do ar. Para se calcular a disponibilidade de um sistemas, basta utilizar a seguinte frmula, conforme disse (GUNDA; TECHNOLOGIES, 2001): TA TD X100 TA Onde AD = Alta disponibilidade, TA = Total de horas por ano Ativo e TD = Total de horas por ano Desativado. A tabela 4.1 apresenta um exemplo do resultado da formula conforme disse (FILHO, 2002) e (MARCUS; STERN, 2003), e na tabela 4.2 apresentado uma outra viso de classicao da disponibilidade segundo (RUSSEL et al., 2001). AD =

4.3

Conabilidade e Disponibilidade

A conabilidade a habilidade de se conar em algum ou alguma coisa. 14

Tabela 4.1: Medindo a disponibilidade de um servidor Tempo-Ativo 98% 99% 99.8% 99.9% 99.99% 99.999% 99.9999% Tempo-Desativado 2% 1% 0.2% 0.1% 0.01% 0.001% 0.0001% Tempo-Desativador-por-Ano 7.3 dias 3.65 dias 17 horas e 30 minutos 8 horas e 45 minutos 52.5 minutos 5.25 minutos 31.5 segundos Tempo-Desativado-por-Semana 3 horas e 22 minutos 1 hora e 41 minutos 20 minutos e 10 segundos 10 minutos e 5 segundos 1 minutos 6 segundos 0.6 segundos

Tabela 4.2: Classicao da disponibilidade Porcentagem 99.5% 99.9% 99.99% 99.999% 99.9999% Tempo-Desativado 3.7 dias 8,8 horas 1 minutos 6 segundos 0.6 segundos Classicao Convencional Disponivel Alta Disponibilidade Resistente a Falhas Tolerante a Falhas

A disponibilidade qualidade ou estado do que disponvel. A disponibilidade e a conabilidade so palavras ou termos muito parecidos. Conforme pode ser visto em (FILHO, 2002) o objetivo bsico da tolerncia a falhas aumentar a conabilidade de um certo sistema, utilizando-se tolerncia a falhas, muitas falhas que podem ocorrer so evitadas, aumentando-se assim a conabilidade. O que possvel concluir que utilizando as tcnicas de tolerncia a falhas, aumenta-se a conabilidade e a disponibilidade de um servio.

4.4

Taxonomia de Alta-Disponibilidade

Esta sesso tem como principal nalidade elucidar os principais termos da altadisponibilidade, bem com o seu sentido ou melhor dizendo, o seu signicado, a m de formar um vocabulrio padro da rea, conforme disse (FILHO, 2002).

4.4.1

Disponibilidade bsica

A Disponibilidade Bsica, tambm conhecida como Basic Availability - BA quando um sistema desenhado, projetado, implementado e implantado com um 15

nmero suciente de equipamentos para satisfazer sua funcionalidade, onde qualquer sistema de rede que funcione corretamente j pode ser considerado como disponibilidade bsica.

4.4.2

Alta disponibilidade

A Alta Disponibilidade consiste nas mesmas teorias da Disponibilidade Bsica, e alm de tudo a Disponibilidade Bsica possui, a Alta Disponibilidade que possui redundncia nos equipamentos, para que na falha de um, essa falha seja mascarada por outro equipamento, de forma transparente ao usurio. Quando dito mascara, isso signica impedir a sua visualizao por um observador externo, conforme disse (FILHO, 2002). Porm o nvel de transparncia, ou melhor dizendo, de mascaramento nesse processo pode levar a algumas modicaes no sistema de "Alta Disponibilidade". Com relao aos tipos de mascaramento pode-se citar: Manual Masking - MM: onde aps uma falha necessrio uma interveno manual para o sistema voltar. Cold Standby - CS: onde aps uma falha, os usurio so desconectados e perdem todo o trabalho e o sistema redundante est desativado precisando ser inicializado para poder comear a operar. Warm Standby - WS: da mesma forma que o Cold Stanby, porm o sistema redundante j esta funcionando e operando, porm os usurio so desconectados e perdem o trabalho em progresso. Hot Standby - HS ou Active Replication - AR: neste tipo de mascaramento, todos os componentes esto fortemente agrupados e so transparentes ao usurio, o estado do processamento ativa e completamente compartilhado. Alm disso deve ser levado em considerao a necessidade do sistema por Alta Disponibilidade, como por exemplo, em alguns casos no so necessrios mascarar as falhas de hardware, s as de software e vice-versa. Nem sempre possvel mascarar todas as falhas. Assim, quando desenvolver um projeto de Alta Disponibilidade importante especicar qual o conjunto de falhas que sero compensadas pelo sistema de Alta Disponibilidade. 16

4.4.3

Disponibilidade contnua

Como pode ser visto, a Alta Disponibilidade somente mascara as falhas, ou seja, mascara as paradas no planejadas dos servios providos em uma rede, j quando dizemos Disponibilidade Contnua, ela estende a denio de Alta Disponibilidade a um ponto que at se mascara as paradas planejadas do servios. Este modelo de disponibilidade exclusivo para o Hot Standby ou Active Replication. A Disponibilidade Contnua possvel somente na teoria, onde a taxa da disponibilidade seria igual a 1, ou seja, o sistema nunca pararia por nada, conforme disse (GARCIA, 2003).

4.5

Avarias, erros e falhas

Como a principal caracterstica da alta disponibilidade a de mascarar falhas tornando-a imperceptvel ao usurio, o termo "falha"acada sendo usado de uma forma vaga. Alguns termos que devem ser levados em considerao so: Avaria: quando ocorre um avaria no comportamento do sistema e ele desviado do que foi designado a fazer. Erro: a parte do estado do sistema que est suscetvel a levar a avarias. Conforme pode ser visto, quando h um erro no estado do sistema, logo se tem uma seqencia de ao que pode ser executadas e que levaro a avarias no sistema, conforme disse (FILHO, 2002). A causa de um erro uma falha. Como um erro a propriedade de um sistema, o erro pode ser observado e avaliado, j uma avaria no, pois ela no uma propriedade do sistema. A avaria deduzida detectando-se a ocorrncia de algum erro no sistema. J as falhas so associadas com a noo de defeitos e falhas denido como sendo os defeitos que possuem o potencial de gerar erros. Conforme disse (FILHO, 2002) a durao da falha e o seu momento de ocorrncia, podem ser classicadas como transientes ou permanentes. Onde as transientes so aquelas que tem uma durao limitada, que podem ser causadas por algum mal funcionamento temporrio ou at mesmo por interferncias. 17

J as permanentes so aquelas que aps ter falhado, nunca mais voltam a funcionar normalmente. Deve-se levar em considerao, que quando utilizado um sistema distribudo, possvel classicar as falhas de acordo com o comportamento do defeito, conforme disse (FILHO, 2002): Falhas de Travamento: so aquelas que causam a perda do estado interno do componente defeituoso ou pode at mesmo causar o travamento. A falha de travamento conhecida como Crash Faults. Falhas de Omisso: quando uma falha faz com que o componente no responda a algumas requisies. A falha de omisso conhecida como Omission Faults. Falhas de Timing: quando um componente responde muito rpido ou muito devagar, essa falha conhecida tambm pelos nomes de falhas de performance ou Timing Faults. Falhas Bizantinas: quando um componente se comporta de forma completamente arbitrria. A falha bizantina conhecida como Byzantine Faults.

4.6

Fases na tolerncia a falhas

Anteriormente foi vericado que um sistema tolerante a falhas tenta evitar a ocorrncia de avarias no sistema mesmo quando ocorre uma falha. Um sistema tolerante a falhas depender totalmente da arquitetura empregada e ao projeto dos recursos e servios que sero providos. Abaixo ser descrito algumas tcnicas gerais de como adicionar tolerncia a falhas em um sistema de Alta Disponibilidade.

4.6.1

Deteco de erros

O primeiro passo para a tolerncia a falhas detectar o erro. As falhas de avaria no podem ser detectadas diretamente, mas podem ser detectadas a partir de um erro no sistema. Dessa forma adequado executar teste para vericar a sua possvel ocorrncia. Atravs disso possvel saber a ecincia de um esquema de tolerncia a falhas na capacidade de se detectar erros. Por causa da importncia da deteco dos erros preciso determinar como deve se proceder os teste ideal para a deteco de erros. 18

Existem algumas formas importantes que devem ser levadas em considerao durante esse processo que so: O teste deve se basear nas especicaes do sistema e no pela constituio interna, de tal forma que a sua implementao seja ignorada, tratando como se fosse uma caixa preta. O teste deve vericar todos os possveis erros existentes e nenhum erro deve ser declarado quando no existente. O teste deve ser independente do sistema no que se diz respeito suscetibilidade de falhas. Quando realizado o teste de deteco de erro, o teste pode ocorrer de vrias formas, dependendo do sistema e dos erros de interesse, conforme disse (FILHO, 2002): 1. Teste de Replicao: Este teste tem como principal caracterstica a de replicar um componente do sistema, compar-lo e retornar resultados de diferentes sistemas com a nalidade de detectar algum erro de replicao. 2. Teste de Timing: Este teste realiza uma solicitao a algum componente e verica se o tempo de resposta excede ou no a restrio imposta. Eles podem ser usados tanto ao nvel de hardware com ao de software. 3. Teste Estruturais e Codicao: Neste tipo de teste so realizados teste de semntica que visa garantir se o valor consistente com o resto do sistema e teste estruturais que considera a informao e garantem que internamente a sua estrutura como deveria ser, onde a forma mais comum a codicao. 4. Teste de Coerncia: Este teste tem como nalidade a de determinar se o estado de algum objeto no sistema est coerente. 5. Teste de Diagnsticos: Neste teste um sistema usa algumas tcnicas de vericao em seus componente para vericar se o mesmo est funcionando de forma correta. 19

4.6.2

Connamento de estragos e avaliao

Um sistema deve ser monitorado constantemente para que no haja um intervalo entre a falha e a deteco de erro. Caso isso no seja feito, o erro pode se propagar para outras partes do sistemas. Conforme diz (FILHO, 2002) por isso, antes de executar medidas corretivas, necessrio determinar exatamente os limites da corrupo, ou seja, as partes do estado que esto corrompidas. Para se avaliar os estragos que ocorreram aps a deteco de um erro, deve ser examinado o uxo das informaes entre os diferentes componente, ento deve ser feito algumas suposies referentes a origem e ao momento da gerao do erro onde o objetivo disso encontrar as barreiras no estado onde nenhuma das trocas de informaes tenha sido feita. Segundo (FILHO, 2002) as barreiras podem ser encontradas dinamicamente, gravando-se e examinando-se o uxo das informaes. Por serem complexos, a melhor maneira implementar um sistema tal que um Firewall sejam estaticamente incorporado no sistema, com a nalidade de garantir que nenhuma informao se espalhe alm deles.

4.6.3

Recuperao de erros

Aps a deteco do erro e sua identicao, o prximo passo a ser feito retir-lo do sistema. As tcnicas para se recuperar de erros segundo (FILHO, 2002) so: Recuperao para Trs: Nesta tcnica, o estado do sistema retornado a um estado anterior a sua falha, na esperana de que neste estado esteja livre de erros. Para isso checkpoints peridicos so estabelecidos. Este uma tcnica muito utilizada, pois no depende da natureza da falha. Recuperao para Frente: Nesta tcnica, nenhum dos estados do sistema est disponvel, onde feita a tentativa de se ir para frente e tentar tornar o estado livre de erros aplicando medidas corretivas. Quando utilizado essa tcnica pode ocorrer overhead.

4.6.4

Tratamento de falhas e servios continuados

Como pode ser visto, o foco sempre foi o "erro"propriamente dito, onde caso ele tenha sido gerado por uma falha transiente no precisa ser tratada pois provavelmente o erro j desapareceu, mas caso tenha sido gerado por um erro permanente, 20

ento teoricamente, o erro tende a estar presente aps a sua recuperao, onde que no novo sistema o erro tende a ocorrer novamente. Algumas tcnicas so utilizadas para identicar o componente defeituoso e evitar que ocorra o erro novamente. Segundo (FILHO, 2002), esta fase possui duas sub-fases: Localizao da Falha: Nesta fase tem que se identicar o erro. Caso no for possvel sua localizao, no ser possvel reparar o sistema. Reparo do Sistema: Nesta fase o sistema reparado de forma que o componente defeituoso no seja novamente utilizado. A manuteno tem que ser feita on-line sem a interveno manual. A restaurao ou melhor dizendo o reparo feito por um sistema que possui um mtodo de recongurao dinmica, de tal forma que o sistema distribudo seja usado para substituir o componente que apresenta falhas ou defeito.

4.7

Software utilizado

Os principais software utilizados para se ter uma alta-disponibilidade so o Drbd1 que tem como nalidade fazer a replicao dos dados, o Heartbeat que tem como nalidade vericar o sistema e tomar decises para contornar os erros apresentados e o Mon2 que responsvel pelos alertas. Cada um ser abordado no prximo captulo.

1 2

Data Replication Block Device Service Monitoring Daemon

21

22

Captulo 5

Ferramentas
Este captulo visa elucidar as 3 ferramentas utilizadas nesta monograa para implementar um Cluster de Alta Disponibilidade e ferramentas estas que podem ser baixada gratuitamente pela internet ou copiadas do CD que est no Anexo. Para vericar as opes de congurao dos programas veja o apndice A

5.1
5.1.1

Drbd
Introduo

O Drbd1 um sistema de replicao desenvolvido para Cluster de Alta Disponibilidade. O que ele faz exatamente criar um espelho de um dispositivo a outro utilizando a rede como meio de transmisso.

5.1.2

Como funciona

O Drbd funciona criando uma imagem, que na verdade uma copia exata, de um dispositivo em outro, utilizando para isso, a rede como seu meio de transmisso. Os dispositivos Drbd funcionam em dois estado: primrio e secundrio. Quando um dos dispositivos setado como primrio e outro como secundrio, todo o contedo do primrio transferido ao dispositivos secundrio, esse processo chamado de sincronizao. Aps feito a sincronizao, somente ser transferido informaes para o dispositivo secundrio, se houver um processo de escrita no dispositivo primrio. possvel criar vrios espelhamentos, sendo limitado inicialmente somente pela largura de banda da rede.
1

Data Replication Block Device

23

5.1.3

Como instalar

O primeiro passo a ser feito baixar o pacote do Drbd2 Utilizando o usurio root, descompacte o Drbd com o comando tar -zxvf drbd-0.7.10.tar.gz Entre no diretrio do drbd, cd drbd-0.7.10 e compile o drbd com os comando make e instale-o com o comando make install Pronto se no der nenhum erro o Drbd foi instalado com sucesso. O segundo passo criar os device Drbd que so bem simples, a sintaxe para se criar a seguinte: mknod -m 0660 /dev/drbdX b 147 X Onde o X o nmero do dispositivo, abaixo segue dois exemplos de como criar mknod -m 0660 /dev/drbd0 b 147 0 mknod -m 0660 /dev/drbd1 b 147 1

5.1.4

Comandos

Est sesso tem como principal nalidade elucidar os principais comandos que podem ser utilizado para congurar o Drbd e at mesmo estar interagindo com o mesmo. drbd Este comando um script para gerenciar o drbd, que tem como principal nalidade a de inicializar ou parar os dispositivos Drbd. Sintaxe drbd {start|stop|status|reload|restart|force-reload} Comandos start: Inicia stop: Para status: Mostra o status dos dispositivos
2

http://oss.linbit.com/drbd/

24

reload: Recarrega a congurao restart: Seria a mesma coisa que um Stop e depois um Start. force-reload: Serve para recarregar a congurao de uma modo forado. drbdsetup O drbdsetup um aplicativo para congurar o Drbd direto pela linha de comando. Outra caractersticas principal do drbdsetup estar vericando o status de cada dispositivos Drbd e caso seja necessrio, estar modicando o estado do dispositivo em questo. Sintaxe drbdsetup device disk lower_dev [ -d size ] [ -e err_handler ] meta_data_dev meta_data_index

drbdsetup device net local_addr [ :port ] remote_addr [ :port ] protocol [ -c time ] [ -i time ] [ -t val ] [ -S size ] [ -k count ] [ -d discon_handler ] drbdsetup device syncer [ -k ] [ -g group ] [ -r rate ] [ -e extents ] drbdsetup device disconnect drbdsetup device detach drbdsetup device down drbdsetup device primary [ -h ] [ -t ] [ -d ] drbdsetup device secondary drbdsetup device on_primary [ -h ] [ -t ] drbdsetup device invalidate drbdsetup device invalidate_remote drbdsetup device wait_connect [ -t wfc_timeout ] [ -d degr_wfc_timeout ] 25

drbdsetup device wait_sync [ -t wfc_timeout ] [ -d degr_wfc_timeout ] drbdsetup device state drbdsetup device cstate drbdsetup device resize [ -d size ] drbdsetup device show Comandos DISK Serve para associar dispositivos de armazenamento sobre um bloco de dados. O -d ( ou disk-size) deve ser usado somente se for necessrio. Se no for utilizado o -d o dispositivo somente ser operacional assim que conectado ao seu par. -d, disk-size size possvel cancelar o mtodo de deteco do tamanho do Drbd. Se for necessrio usar o dispositivo antes de se conectar com o outro par, ento essa opo deve ser especicada. A unidade de medida padro em KB, lembrando que 1KB = a 1024 Bytes. -e, on-io-error err_handler Se o driver de um dispositivo relatar algum erro ao Drbd, ele ir passar o erro a camada superiores do sistema operacional. As opes de err_handler so: pass_on, panic and detach. NET Congura os dispositivos para escutar em um endereo_local:porta para conexo entrantes e para tentar conectar ao endereo_remoto:porta. Se o valor da porta for omitido, o valor padro a ser usado ser 7788. Em um link TCP/IP a especicao do protocolo deve ser usado. As especicaes vlidas dos protocolos so A, B e C. O Protocolo A: Uma operao de escrita considerada completa, se est escrita no disk local e enviado pela rede. O Protocolo B: Uma operao de escrita considerada completa, se est escrita no disk local e conrmado a recepo no disco remoto. 26

O Protocolo C: Uma operao de escrita considerada completa, se chegar a conrmao do disco local e do remoto. A descrio das opes abaixo j foram elucidadas na sesso de parmetro do arquivo de congurao. -c, connect-int time -i, ping-int time -t, timeout val -S, sndbuf-size size -k, ko-count count -e, max-epoch-size val -b, max-buffers val -d, on-disconnect discon_handler SYNCER A descrio das opes abaixo j foram elucidadas na sesso de parmetro do arquivo de congurao. -r, rate rate -k, skip-sync -g, sync-group group -e, al-extents extents PRIMARY Congura o dispositivo no estado primrio, isto signica que as aplicaes podem abrir o dispositivo em modo de leitura e escrita. Os dados escritos no dispositivos primrio so espelhados para o dispositivo secundrio. No possvel ajustar ambos os dispositivos de um par conectado do dispositivo de Drbd ao estado preliminar. No possvel congurar ambos os dispositivos Drbd no estado primrio. -h, human Indica que o estado est sendo mudado pelo administrado e o Cluster reinicia o tempo precedente sobre a deciso para os outros nos. -t, timeout-expired Indica que a mudana do estado foi por causa de um n que no mostrou que inicio o Cluster, ento o Cluster ir iniciar em modo degraded. 27

-d, do-what-I-say Torna-se primrio, mais a replicao local pode se tornar inconsistente. Usando esta opo possvel for-lo a entrar no estado primrio. S utilize esta opo se souber o que est fazendo. SECONDARY Congura um dispositivo Drbd no estado secundrio. possvel que ambos os pares de um dispositivos Drbd estejam no estado secundrio. ON_PRIMARY Isto congura o ags adicionais para a transao para o estado primrio. As possibilidades das ags so inc-human e inc-timeout-expired. INVALIDATE Este comando fora o dispositivo local que esto conectado ao Drbd ao estado de SyncTarget, que signica que todos os blocos de dados do dispositivos so copiados para o par. Este comando falhar se o dispositivo no for parte de um par conectado ao dispositivo. INVALIDATE_REMOTE Este comando fora o disco local de um par do dispositivo Drbd ao estado SyncSoure, que signica que todos os blocos dos dados do dispositivos sero copiados ao par. WAIT_CONNECT A descrio das opes abaixo j foram elucidadas na sesso de parmetro do arquivo de congurao. -t, wfc-timeout wfc_timeout -d, degr-wfc-timeout degr_wfc_timeout WAIT_SYNC Retorna assim que o dispositivo sair do estado de sincronizao e retornar ao estado de conectado. As opes so as mesmas do comando wait_connect. DISCONNECT Remove as informaes conguradas pelo comando net para um dispositivo. Isso signica que os dispositivos em estados de no conectado no mais aguardaro um conexo entrante. 28

DETACH Remove as informaes conguradas pelo comando disk para um dispositivo. Isto signica que o dispositivo estar desconectado do seu dispositivo Drbd de armazenamento para votar ao modo normal. DOWN Remove todas as informaes de congurao de um dispositivo forando-o a voltar ao estado de no congurado. STATE Mostra os estado do dispositivo e a do seu par ( local / remoto ). CSTATE Mostra os estados atuais da conexo de um dispositivo. RESIZE Isto faz com que o Drbd reexamine o tamanho do dispositivo de armazenamento. SHOW Mostra todas as informaes de congurao disponveis de um dispositivo. drbdadmin O drbdadmin um aplicativo para administrao do Drbd Sintaxe drbdadm [ -d ] [ -c le ] [ -s cmd ] command [ all | resource ... ] Opes -d, dry-run Somente imprime as chamadas do drbdsetup ao stdout, mas no roda como um comando. -c, cong-le le Especica o local do arquivo de congurao que ser usado. -s, drbdsetup le Especica o caminho completo para o programa drbdsetup. Esta opo omitida, pois o drbdadmin ira olhar para /sbin/drbd-setup e ./drbdsetup Comandos 29

attach Anexa um dispositivo de bloco local ao dispositivo Drbd. Na linguagem do sistema ser uma operao mount. detach Remove o dispositivo de armazenamento do dispositivo Drbd. connect Ajusta a congurao da rede do dispositivo Drbd. Se os dois dispositivos j estiverem congurados, os dois se conectaro. disconnect Remove a congurao da rede do dispositivo Drbd. O dispositivo entrar no estado de StandAllone. syncer L os parmetros de ressincronizao do dispositivo. up um atalho para o attach e connect. down um atalho para a disconnect e detach. primary Altera o dispositivo Drbd para o estado primrio. necessrio fazer isto antes de se montar um sistema de arquivo no dispositivo. secondary Altera o dispositivo Drbd para o estado secundrio. Isto necessrio desde que um dos pares conectados ao dispositivo Drbd tem que ser secundrio. invalidate Isto fora o Drbd a considerar os dados no dispositivo local de armazenamento como out-of-sync. Para depois o Drbd copiar cada bloco do seu par, para trazer de volta a sincronizao entre os dispositivos. invalidate_remote Este comando similar ao comando de invalidate, mas o armazenamento suportando pelo par invalidado e reescrito com os dados do n local. resize O Drbd ira reexaminar todas as constantes de um tamanho e redimensionar aos dispositivos Drbd de acordo. 30

adjust Sincroniza a congurao dos dispositivos com o arquivo de congurao local. wait_connect Espera at que o dispositivos esteja conectado ao outro dispositivo. state Mostra os estados atuais dos dispositivos (local/peer). Por exemplo primary/secondary. cstate Mostra o status atual das conexes dos dispositivos. dump Apenas analisa gramaticalmente o arquivo de congurao e o depura. Pode ser usado para vericar o arquivo de congurao no que diz respeito as sintaxe.

5.2
5.2.1

Heartbeat
Introduo

A principal nalidade do Heartbeat a de ser um monitor do estado do sistema e dependendo do resultado encontrado, tomar uma deciso. Heartbeat representa batimentos cardacos, esse termo foi escolhido porque o Heartbeat tem como principal caractersticas estar enviando pacotes a outra mquina para vericar se essa est ainda operante. O Heartbeat um dos principais programas para a criao de um sistemas de Cluster de Alta-Disponibilidade.

5.2.2

Como funciona

Aps congurado o arquivo ha.conf, o Heartbeat vai car vericando de tempos em tempos as mquinas conguradas em seu arquivo de congurao. Caso alguma delas no responda ele poder assumir os recursos desse computador que no esta respondendo. Com apenas 2 nodos IP o Heartbeat pode assumir os recursos e servios de um nmero ilimitado de interfaces IPs. O Heartbeat tem vrias formas de estar vericando se um computador est ativo ou no, a primeira forma utilizando a prpria interface de rede e a outra atravs de uma porta serial. 31

Cada pacote enviado pelo Heartbeat com a nalidade de checar se o outro computador esta ativo ou no chamado de heartbeats.

5.2.3

Como instalar

Inicialmente necessrio baixar o pacote chamado libnet3 verso 1.1.2.1, netsmnp4 verso 5.1.3. e swig 5 verso 1.3.24. Lembre-se que antes de comear qualquer compilao importante j se ter criado o usurio hacluster e o grupo hacluster utilizando os comandos useradd hacluster e groupadd hacluster. Descompacte o libnet com o comando tar -zxvf libnet.tar.gz Entre no diretrio libnet, cd libnet e inicie o script de congurao ./configure Compile o libnet com o comando make e depois instale-o com o comando make install Agora descompacte o net-smnp com o comando tar -zxvf net-snmp-5.1.3.tar.gz Entre no diretrio net-smnp, cd net-snmp-5.1.3/ e inicie o script de congurao ./configure Durante esse processo sero feitos algumas perguntas, caso tenha duvida, tecle <ENTER> para adotadar o valor padro. Compile-o com o comando make e depois instale-o com o comando make install Descompacte o swig com o comando tar -zxvf swig-1.3.24.tar.gz Entre no diretrio swig, cd SWIG-1.3.24/ e inicie o script de congurao ./configure Compile o swig com o comando make e depois instale-o com o comando make install O ltimo passo baixar a ltima verso do heartbeat6 , que at o atual momento a 1.99.4. Descompacte com o comando tar -zxvf heartbeat-1.99.4.tar.gz Entre no diretrio do heartbeat, cd heartbeat-1.99.4 e inicie o script congurao ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var Compile o hearbeat com o comando make e depois instale-o com o comando make install Feito isso, ainda no diretrio do hearbeat copie o arquivo modelo de congurao ha.conf para o diretrio /etc/ha.d, cp doc/ha.cf /etc/ha.d/ Finalmente copie os arquivos haresources e authkeys para o diretrio /usr/local/etc/ha.d com os comandos cp doc/haresources /etc/ha.d/ e cp doc/authkeys /etc/ha.d/
3 4

http://unix.freshmeat.net/redir/second-libnet/34005/url_tgz/libnet-1.1.2.1.tar.gz http://www.net-snmp.org/download/ 5 http://www.swig.org/download.html 6 http://handhelds.freshmeat.net/projects/linux-ha/

32

5.2.4

Comando

Est sesso tem como principal nalidade elucidar o principal comando que utilizado para gerenciar o Heartbeat que o heartbeat. Este comando um script para gerencia-lo, que tem como principal nalidade a de inicializa-lo ou para-lo. Sintaxe Usage: /etc/rc.d/heartbeat {start|stop|status|restart|reload|force-reload} Opes start: Inicia. stop: Para. status: Mostra o status dos dispositivos. restart: Seria a mesma coisa que um Stop e depois um Start. reload: Recarrega a congurao. force-reload: Serve para recarregar a congurao de uma modo forado.

5.3
5.3.1

Mon
Introduo

O Mon tem como principal nalidade a de ser um monitor do sistema. Quando ele detecta uma falha possvel enviar um e-mail e at mesmo fazer com que ele acione o Heartbeat para que ele tome alguma deciso para a soluo do problema.

5.3.2

Como instalar

O primeiro passo para se instalar o Mon ter o perl instalado. Aps isto entre na shell do module MCPAN, para isso digite no console o comando: perl -MCPAN -e shell Caso for, a primeira vez que voc esteja executando, responda o questionrio, na duvida pode ir pressionando <Enter>, exceto na hora de congurar o local de onde se deve baixar o modulo7 .
7

necessrio ter uma conexo com a Internet para poder baixar os arquivos

33

Feito isso, aparecera o prompt do CPAN, agora s digitar os seguintes comandos para instalar os mdulos adicionais: install install install install exit Time::Period Time::HiRes Convert::BER Mon::Client

Os mdulos para rodar o Mon j esto prontos e ainda se faz necessrio baixar o programa fping 8 verso 2.4b2 para utilizar todas as funcionalidade do Mon. Aps baixado apenas descompacte-o com tar -xvf fping.tar , entre no diretrio com cd fping-2.4b2_to e congure-o com ./configure . Feito isso compile o fping com make e instale-o com make install . Agora baixe os arquivos do Mon9 verso 0.99.2. Feito isso descompacte-o com o comando tar -jxvf mon-0.99.2.tar.bz2 Agora a estrutura dos arquivos do Mon ser, arquivos de congurao caram em /etc/mon/, o arquivo executvel cara em /usr/local/bin e os scripts em /usr/lib/mon/. Entre no diretrio do Mon, cd mon-0.99.2 Feito isso vamos criar a estrutura de diretrio com os seguintes comandos: mkdir mkdir mkdir mkdir /etc/mon/ /usr/lib/mon/ /usr/lib/mon/state.d/ /usr/lib/mon/log.d/

E por m, colocar cada arquivo no seu lugar, primeiro copiando os arquivos de congurao: cp etc/example.cf /etc/mon/ cp etc/auth.cf /etc/mon/ Agora devem ser copiados os arquivos executveis, com o seguinte comando: cp mon /usr/local/bin/ cp clients/moncmd /usr/local/bin/ cp clients/monshow /usr/local/bin/ E por m, deve ser copiados os scripts, com os comandos: cp alert.d/ /usr/lib/mon/ -R cp mon.d/ /usr/lib/mon/ -R
8 9

http://www.fping.com/download/ http://freshmeat.net/projects/mon/

34

5.3.3

Comando

Est sesso tem como principal nalidade elucidar o principal comando que utilizado para gerenciar o Mon que o mon. O software Mon tem como principal nalidade a de ser o monitor dos servios para a disponibilidade, emitindo alarmes para as falhas. sintaxe: mon [-dfhlMSv] [-a dir] [-A authle] [-b dir] [-B dir] [-c cong] [-D dir] [-i secs] [-k num] [-l dir] [-m num] [-p num] [-P pidle] [-r delay] [-s dir] Descrio O Mon um monitor com nalidade geral de monitorar a disponibilidade do servio e gerar alertas no caso de detectar falhas. O Mon foi projetado para ser de fcil monitorao e tambm utilizar mtodos de alertas atravs de uma relao comum, que so executados facilmente com os programas (em C, em Perl, em Shell, etc.), traps SNMP e traps MON (pacote do UDP). Opes -a dir Indica o local dos scripts de alerta. O padro /usr/local/bin/mon/alert.d -b dir Indica o diretrio base do mon. O padro /usr/lib/mon. -B dir Indica o diretrio base do arquivo de congurao. Todos os arquivos de congurao devem car nesse diretrio, incluindo o mon.cf, monusers.cf e auth.cf. -A authle Indica o local do arquivo de autenticao. O padro /etc/mon/auth.cf, isso se o diretrio /etc/mon exister, caso no, o padro /usr/lib/mon/auth.cf. -c le L o arquivo de congurao especicado em le. -d Ativa o mode de depurao. 35

-D dir Indica o caminho do diretrio de estado. O valor padro /var/state/mon, /var/lib/mon e /usr/lib/mon/state.d caso existo. -f fora a rodar em modo daemon. Est a maneira preferida de executar o mon. -h Mostra a tela de ajuda. -i secs Indica o intervalo de descanso, em segundos. O valor padro 1. -k num Congura o nmero mximo de linhas do log histrico. O valor padro 100. -l L o estado de um arquivo. -L dir Congura o local do diretrio de log. O valo padro /var/log/mon. -M Pre-processa o arquivo de congurao utilizando a pacote m4. -m num Congura o nmero de trottle para o nmero mximo de processos. -p num Cria um porta de comunicao. O valor padro 2583. -S Inicia quando scheduler estiver parado. -P pidle Grava o pid do servidor no arquivo pidle. O valor padro /var/run/mon/mon.pid, /var/run/mon.pid, e /etc/mon.pid -r delay Congura o nmero de segundos a ser usado no atraso da inicializao aps cada servio ter sido programado. Mais informaes verique o comando randstart. 36

-s dir Indica o caminho dos scripts de monitorao. O valor padro /usr/local/bin/mon/mon.d/ -v Imprime as informaes da verso

37

38

Captulo 6

Estudo de Caso
Neste estudo de caso ser abordado a implementao de um simples sistema de alta disponibilidade com a demonstrao de como esse sistema funciona. O interessante dessa demonstrao que a partir dela pode-se modicar sua estrutura adaptando a diversas necessidade que possa vir a existir.

6.1

Estrutura

Esta implementao consiste na seguinte estrutura, um servidor primrio, que ter sua base principal de dados replicada em um servidor secundrio, que na sua queda o servidor secundrio tomar seu lugar. Est replicao foi feita da seguinte forma, foi centralizado em uma partio todos os arquivos de congurao, arquivos de dados e at mesmo o banco de dados. Foram criados links simblicos para os arquivos de conguraes, para que com isso no fosse mudado a estrutura padro da localizao desses arquivos. Com relao a congurao dos equipamentos utilizado, bem como suas especicaes para este estudo de caso, seguem especicados na gura x: A congurao do servidor secundrio apresentada na gura x foi utilizado um hub-switch para interligar os servidores onde sua congurao apresentada na gura x foi utilizado um roteador para fazer a conexo com a Internet onde sua congurao apresentada na gura x abaixo segue um diagrama ilustrando o mapeamento da localizao dos equipamentos. A lgica de funcionamento deste esquema o seguinte, tem o servidor primrio que est no IP 10.0.0.200 e o servidor secundrio que esta no IP 10.0.0.4, o IP que ser utilizado para acessar os servios provido ser o 10.0.0.201. 39

Figura 6.1: Servidor primrio

Figura 6.2: Servidor secundrio

Os servios providos nesta estrutura so: Servio de Pgina e Proxy. Ento quando inicializado o servio, o servidor primrio adicionar uma interface virtual com o IP 10.0.0.201. 40

Figura 6.3: Switch

Figura 6.4: Roteador

Figura 6.5: Mapeamento geral da rede de alta disponibilidade

41

Toda a comunicao entre os servidores feito pelos IPs 10.0.0.200 e 10.0.0.4, isso inclui, a replicao das informaes bem como a vericao se o servidor esta ativo ou no. No caso da queda do primeiro servidor, isso ser vericado pelo IP 10.0.0.200, o servidor secundrio ir adicionar uma interface virtual e nela atribuindo o IP 10.0.0.201 logo tornando-se responsvel pela resposta a esse IP. pq A replicao da partio feita pelos IPs 10.0.0.200 e 10.0.0.4. No que diz respeito ao proxy, o que o servidor faz somente redirecionar os pacotes vindo at ele para o IP 192.168.200.254. O servidor secundrio alm de car monitorando o servidor primrio, tambm tem a nalidade de car monitorando o roteador, cujo IP 192.168.200.254, utilizando para isso a segunda interface de rede que tem o IP 192.168.200.2.

6.2

Drbd

Nesta sesso ser demonstrado como feito a replicao dos dados entre o servidor primrio e o servidor secundrio e para isso, ser necessrio elucidar melhor como foi feito a estruturao dos diretrios. O disco local foi particionado em 3 parties: hda1, hda2 e hda3, onde na hda1 onde cou o sistema operacional como um todo, na hda2 cou a pasta /home e na hda3 ca a memria swap. O diretrio de congurao do Apache, que ca em /etc/apache, foi movido para dentro do diretrio /home, onde em seu lugar padro foi criado um link simblico, com isso mantendo o padro de localizao dos arquivos de congurao do sistema. Ex: ln -s /home/apache /etc/apache

6.2.1

Congurao

A congurao nos dois servidores monstrada na gura x.

6.2.2

Inicializao

Para inicializar a replicao basta executar o comando /etc/rc.d/drbd start nos dois servidores. 42

Figura 6.6: Congurao do drbd.conf

43

6.3
6.3.1

Heartbeat
Congurao

Esta sesso tem como nalidade mostrar um exemplo de congurao do Heartbeat, lembrando que os arquivos devem ser idnticos nos dois servidores e que os servios a serem utilizados sero a rplica de disco e o servidor de pginas. ha.cf Arquivo localizado em /etc/ha.d/ha.cf

Figura 6.7: Congurao do ha.cf

haresources Arquivo localizado em /etc/ha.d/haresources

Figura 6.8: Congurao do haresource

44

authkeys Arquivo localizado em /etc/ha.d/authkeys

Figura 6.9: Congurao do authkeys

Aps a congurao deste arquivo no esquecer de mudar as permisses com chmod 600 authkeys

6.3.2

Inicializao

Para inicializar o Hearbeat digite /etc/rc.d/heartbeat start , deve ser levado em conta que interessante sempre levantar o servidor principal e depois o de alta-disponibilidade.

6.4
6.4.1

Mon
Congurao

A congurao do Mon neste estudo de caso foi feito somente no servidor de altadisponibilidade, dependendo da situao e da necessidade pode ser implementando em ambos os servidores. mon.cf Arquivo localizado em /etc/mon/ auth.cf Arquivo localizado em /etc/mon/

6.4.2

Inicializao

Para executar o Mon digite mon na linha de comando e caso queira que o mesmo que em modo background digite mon & . 45

6.5

Teste no sistema

Para validar a congurao feita neste estudo de caso, foi realizados testes de simulao de falha no servidor nd onde o servidor 03 deve tomar todas as funes servidas pelo servidor nd. A primeira fase deste teste foi levantar a replicao no servidor primrio, que pode ser visto no apndice A.1. e tambm no servidor secundrio, que pode ser visto no apndice A.2. Quando executado o Drbd nos dois servidores, os dois at o presente momento so estabelecidos como secundrio. A segunda fase foi levantar o Heartbeat no servidor primrio, que pode ser visto no apndice A.3. e no servidor secundrio que pode ser visto no apndice A.4. Feito isso pode ser visto que a interface virtual j e adicionada no servidor primrio, bem como o servio de pgina e ele automaticamente congurado como servidor primrio no Drbd. A terceira fase foi executar o programa de monitoramento Mon para vericar o estado do roteador, pode ser visto no apndice A.5. Na Quarta fase simulado a queda do servidor primrio arrancando o cabo de rede, conforme pode ser visto no apndice A.6. Aps retirado o cabo, o servidor secundrio toma o lugar do servidor primrio como pode ser visto no apndice A.7 J na Quinta fase o servidor primrio retorna a sua funcionalidade, conforme pode ser visto no apndice A.8. E o servidor secundrio volta ao estado de monitoramento liberando os servios para que voltem ao servidor primrio, conforme visto no apndice A.9. E a Sexta fase foi a simulao da perda de comunicao do servidor secundrio com o roteador, aonde o mesmo gerou um email de alerta, conforme pode ser visto em A.10. Com isso pode ser conrmado a validade desse estudo de caso.

46

47

Figura 6.11: Congurao do auth.cf

48

Captulo 7

Concluso
Como pde ser visto nesta monograa possvel ter um sistema de alta disponibilidade baseado em ferramentas open-source, sem gastar muito dinheiro no quesito software. Um fator que chama muito a ateno que com a implementao de um servidor de alta disponibilidade em uma rede se tem um aumento na qualidade de servio prestado pelo mesmo, onde o servios prestado por um servidor ca o maior tempo possvel disponvel ao usurio, valendo lembrar que cada minuto que um servidor ca fora dinheiro perdido. O mais satisfeito foi o potencial e a maturidade que o sistema operacionais Linux possui hoje. Ele pode ser colocado como sendo um servidor de misses criticas tanto de uma pequena empresa quanto de uma grande empresa, sem deixar a desejar nada das outras solues concorrentes. Um fator muito importante que se deve levar em considerao durante a implantao de um servidor de alta disponibilidade justamente o custo x benecio, como pode ser visto, quando maior o grau de disponibilidade maior ser o recurso nanceiro necessrio para implementao de tal, porem tudo isso depende do quanto importante a sua informao estar disponvel para os usurios. Como pode ser visto, os resultados obtidos com o teste dos trs software foram muito satisfatrios, pos de uma forma barata, foi possvel resolver o problema de replicao, bem como a de monitoramento dos servidores, fator este que tornou essas ferramentas muito atrativas, justamente pelo recurso que as mesmas proporciona. Um dos fatores que chamou a ateno durante a implantao da alta disponibilidade foi justamente na parte das paradas obrigatrias para manuteno, valendo lembrar que quando isso ocorre se trabalha com a manuteno preventiva onde se trabalha com a preveno e no com a manuteno corretiva que se trabalha 49

com a correo de uma falha aps ela ter surgido, pos dessa forma possvel estar parando um servidor sem interromper os servios prestado e muito menos ter que fazer horas extras para no estar atrapalhando a produtividade da empresa. Inicialmente a alta disponibilidade parece ser muito difcil de ser alcanada, pois para atingir tal meta, tem que se levar em considerao vrios fatores, como por exemplo, a redundncia de fonte de energia, de equipamentos e at a prpria redundncia das informaes e programas se analisado no ponto nanceiro, isso seria um grande desperdcio de dinheiro, mas no decorrer desta monograa, percebese completamente o contrrio, de tal forma que o desperdcio de recurso se convertia em investimento, em qualidade de servio, coisa ao qual essencial a uma empresa. Outro problema interessante foi como que um problema de disponibilidade pode ser resolvida de uma forma to simples, sem a necessidade de nenhum equipamento caro e de arquitetura proprietria. E por m, nada melhor que se ter um servidor de alta disponibilidade, principalmente quando o disco rgido do servidor queira e no ter mais que escutar as famosas frases do chefe, como por exemplo: "Quanto tempo o servidor demora a voltar, 5 minutos?"

50

Referncias Bibliogrcas
BONAN, A. R. Congurando e usando o Sistema Operaciona Linux. 2. ed. So Paulo: Futura, 2003. FILHO, N. A. P. Linux, Clusters e Alta Disponibilidade. Dissertao (Mestrado) Universidade de So Paulo, 2002. GARCIA, S. Alta Disponibilidade (High Availability) em sistemas GNU/LINUX. 2003. Http://ha.underlinux.com.br/. GUNDA, B.; TECHNOLOGIES, O. S. High Availability and Disaster Recovery Strategies White Paper. 2001. Revison A. MARCUS, E.; STERN, H. Blueprints for High Availability. 2. ed. Rio de Janeiro: Wiley Publishing, 2003. NORTON, P.; GRIFFITH, A. Guia completo do Linux. 1. ed. So Paulo: Berkeley Brasil, 2000. PITANGA, M. Computao em Cluster. 1. ed. Rio de Janeiro: Brasport, 2003. RUSSEL, S. et al. High Availability Without Clustering. 1. ed. maro: IBM, 2001. SZTOLTZ, L.; TEIXEIRA, R. S.; RIBEIRO., E. de O. F. Entendendo o Conectiva Linux. 2003. Http://www.conectiva.com.br.

51

52

Apndice A

Ferramentas - Congurao
A.1 Drbd

O arquivo de congurao do Drbd o drbd.conf que se localiza em /etc/drbd.conf. A estrutura de congurao desenvolvida pela equipe do Drbd foi feita de uma forma onde se tenha que editar somente um vez o arquivo de congurao e copilo a todos os nodes que faro parte da replicao. Exemplo de congurao do drbd.conf: resource drbd0 { protocol B; incon-degr-cmd "halt -f"; on servidor1 device disk address } on servidor3 device disk address } } 53 { /dev/drbd0; /dev/hda2; 10.0.0.4:7789; { /dev/drbd0; /dev/hda2; 10.0.0.2:7789;

Esse foi um exemplo de uma congurao de uma replicao chamada drbd0 que utiliza o protocolo B1 como mtodo de conrmao entre os dispositivos. O primeiro dispositivo est no servidor1 em /dev/drbd0, que na verdade corresponde a partio /dev/hda2. J o IP usado para especicar qual interface de rede ele usar. Poder haver vrios resources no arquivo de congurao caso deseja-se ter mais de uma replicao de disco.

A.1.1

Formato do arquivo

O arquivo consiste em sesses e parmetros. As sesses iniciam com uma palavrachave, vrias vezes associada a um nome e um abre chaves { e um fecha chaves } que tem como nalidade fechar o parmetros. sintaxe: sesso [nome] parmetro valor; ... O parmetro inicia com o identicador de parmetros seguido por um espao em branco e o valor subseqente considerado como um valor que faz parte do parmetro. Em alguns casos especiais os parmetros booleanos consistem somente de um identicador. Para nalizar o parmetro utilize o ; Sesso skip Comentrios fora do texto, sempre tendo mais de uma linha. global Congurao do parmetro global. Usa somente minor-count,dialog-refresh, e disable-io-hits so permitidos nesta sesso. Pode-se ter somente um sesso global e preferencialmente ela sendo a primeira sesso do arquivo de congurao. resource name Congura os resource Drbd. A sesso de resource necessita de duas sesses "on host" e pode ter uma sesso "startup", uma "syncer", uma "net" e uma "disk". Os seguintes parmetro requerido: Protocol Parmetros opcionais: incon-degr-cmd.
Este protocolo especica que uma operao de escrita considerada completa, se est escrita no disco local e enviado pela rede
1

54

on host-name Chaves so parmetros de congurao necessrios para fazer o fechamento de um dispositivos Drbd, o host-name o nome da mquina, que pode ser conseguida com o comando uname -n. Parmetros requeridos: device, disk,address,meta-disk. disk Esta sesso usada para uma congurao precisa das propriedades do Drbd no que diz respeito a localizao do disco a baixo nvel. Parmetros opcionais: on-io-error net Esta sesso utilizada para a congurao das propriedades da rede. Parmetros opcionais: sendbuf-size,timeout, connect-int, ping-int,max-buffers,maxepoch-size,ko-count,on-disconnect. startup Esta sesso utilizada para congurar a inicializao do Drbd. Para mais referncias sobre os parmetros, veja em drbdsetup. Parmetros opcionais:wfc-timeout,degr-wfc-timeout. syncer Esta sesso utilizada para congurar o daemon de sincronismo para um dispositivo. Para mais referencias sobre os parmetros, veja em drbdsetup. Parmetros opcionais:rate,group,al-extents. Parmetro minor-count count count pode ter um nmero entre 1 e 255. Use minor-count se desejar denir o nmero de resoucers apos ter recarregado o mdulo Drbd. Por padro o mdulo l exatamente o nmero de device congurado no arquivo de congurao. dialog-refresh time O time pode ser o valor 0 ou um nmero positivo. O uso do dialog redesenha o contador de segundo a cada segundo especicado ( ou no se o valor for 0 ). O valor padro para ele 1. disable-io-hints Use o disable-io-hints se quiser congurar o drbd utilizando o endereo de rede loopback ou entre duas mquinas virtuais. 55

protocol prot-id Em um link TCP/IP a especicao do protocolo deve ser usado. As especicaes vlidas dos protocolos so A, B e C. O Protocolo A: Uma operao de escrita considerada completa, se est escrita no disco local e enviado pela rede. O Protocolo B: Uma operao de escrita considerada completa, se est escrita no disco local e conrmado a recepo no disco remoto. O Protocolo C: Uma operao de escrita considerada completa, se chegar a conrmao do disco local e do remoto. incon-degr-cmd command Caso um dos ns, durante a sua inicializao, inicialize na modalidade degradado e a replicao dos dados local inconsistente, este comando executado. Se o comando no retornar erro, o drbddisk espera o device Drbd ir para o estado primrio. device name O nome do n de um dispositivo de bloco do recurso especicado nesta opo. Poder ser usado o device como sendo uma aplicao (sistema de arquivo) ou no poder usar o dispositivo de block de baixo nvel que especicado no parmetro de disco. disk name O Drbd usa realmente este dispositivo de bloco para armazenar e recuperar as informaes. Nunca utilize este dispositivo quando Drbd estiver rodando pos pode acabar danicando os arquivos caso algum opo seja passada de forma errada. address IP:port O recurso precisa de um endereo IP para o dispositivo, que usado para esperar as conexes com o outro dispositivo. Cada recurso do Drbd necessita de uma porta TCP para ser usada durante a conexo com o outro dispositivo. Dois dispositivos Drbd diferentes no podem usar a mesma combinao de IP e Porta. meta-disk internal Est opo j fala por si so. 56

meta-disk device [index] Internamente, os ltimos 128 MB de um dispositivo so usados para gravar os meta-data. Est opo no poder ser usado [index] quando utilizado a opo interna descrita acima. Com essa opo possvel gravar a informao de meta-data de dois dispositivos em apenas um. on-io-error handler O handler vericado, e se o dispositivo de baixo nvel reportar um erro de I/O2 a ele a opo ser executado. O handler poder ser pass_on, panic ou detach. pass_on: Reporta um erro de io para o programa. Quando primrio o relatrio sobre o sistema de arquivo montado. J no secundrio isso ignorado. panic: Este opo leva o n Cluster a receber um kernel panic. detach: O n desativa o dispositivo de baixo nvel e continua com um disco a menos. sndbuf-size size O size o tamanho do buffer de envio do pacote TCP. O valor padro 128k. timeout time Se o no falhar ao enviar a resposta esperada no tempo de dcimos de segundo, o n scio considerado morto e conseqentemente a conexo TCP/IP abandonada. Isso deve ser mais baixo que as opes connect-int e ping-int. O valor padro 60 = a 6 segundos, a unidade medida em 0.1 segundos. connect-int time Caso no for possvel conectar ao device Drbd remoto imediatamente, o DRBD tenta conectar novamente. Com essa opo possvel congurar o tempo entra as tentativas. O valor padro de 10 segundos e a unidade de medida em 1 segundo. ping-int time Se a conexo que liga o par de dispositivos Drbd for inativa mais do que o temo expresso em segundos, o Drbd ir gerar um pacote keep-aliva para
2

Isto corresponde a um processo de escrita/leitura.

57

vericar se o seu scio ainda esta vivo. O valor padro 10 segundos, e a unidade de medida 1 segundo. max-buffers number Nmero mximo de requisies alocada pelo Drbd. A unidade do tamanho da pagine de 4 KB na maioria dos sistemas. max-epoch-size number O maior nmero de blocos de dados entre duas barreiras de escritas. Se ajustada para um valor menor que 10, poder diminuir o desempenho. ko-count count No caso do segundo n falhar completamente um nico pedido de escrita por um tempo contado de intervalos de parada, ele est expulso do conjunto ( Caso for o no primrio ele ir para o modo StandAlone ). O valor padro 0, o que no ativa esta opo. on-disconnect handler Quando a conexo entre o par perdida, o Drbd pode entrar na modalidade Stand_Alone, tentando reconectar com o outro par ou ento parando todos os pedidos de IO. As opes vlidas para essa opo stand_alone, reconnect e freeze_io. O valor padro do handler reconnect. stand_alone: No reconecta e vai para o estado StandAlone. reconnect: Tenta reconectar freeze_io: Tenta reconectar, mas para todo IO at que a conexo sej refeita. wfc-timeout time Espera que a conexo caia. O script de blocos Drbd obstrudo para no carregar o processo at que os recursos do Drbd estejam conectados. Isso acontece quando o gerente do conjunto de Cluster inicia depois. Caso seja necessrio limitar o tempo de espera, isso ser feito aqui. O valor padro 0, ou seja, ilimitado. A unidade medidas em segundos. degr-wfc-timeout time Espera que a conexo caia, se este node for um degraded Cluster , caso o degraded Cluster sej reinicializado, o valor do time-out ser o valor especicado aqui em vez do wfc-timeout. O valor padro de 60 e a unidade tempo medida em segundos. O valor 0 corresponde a ilimitado. 58

rate rate Serve para controlar as operaes feitas pelo Drbd, nesta opo possvel limitar a largura da banda que usada para uma sincronizao em modo background. O valor padro de 250 KB/sec, e a unidade de medida KB/sec. Os suxos opcionais permitidos so: K, M, G. group number Ressincronizao de todos os dispositivos de um grupo paralelo. Os grupos so colocados em sria e na ordem crescente. O valor padro do grupo 0. Isso padro para todos os dispositivos sincronizados em paralelo. Valor positivos e negativos so permitidos. al-extents extents O Drbd automaticamente faz a deteco da hot rea. Com este parmetro possvel controlar o inicio do tamanho da hot rea ( = active set ). Cada extenso de armazenamento marca 4M. Caso o no primrio saia do Clustes inesperadamente as reas cobertas pela active ser vo ressincronizar tornando a reunir o no que ocorreu a falha. A estrutura de dados armazenada na rea do meta-data, conseqentemente cada mudana da active set necessrio reescrever a operao no dispositivo meta-data. Um alto nmero da extents d um tempo mais elevado para a ressincronizao, porm menor para a atualizao do meta-data. O nmero padro 127 onde o mnimo 7 e o maior 3843.

A.2

Heartbeat

O Heartbeat possui basicamente trs arquivos de conguraes que so: ha.conf, haresources e authkeys que sero abordados mais abaixo. ha.conf Ser abordado uma lista de opes para o arquivo de congurao . O que ter que ser feito congurar as opes deste arquivo, como por exemplo, os ns, no que diz respeito ao mtodo de vericao, poder ser feito atravs da serial, broadcast, multicast e unicast, alm disso deve ser especicado o valor do auto_failback. debugle /var/log/ha-debug Est opo indica onde ser escrito as mensagens de debugao. logle /var/log/ha-log Est opo especica o local do arquivo de log. 59

logfacility local0 Facilidade de uso para syslog/logger. keepalive 2 Tempo de vida entre os heartbeats, a unidade medida em 10 mini segundos, porm pode ser especicados em unidade de milesegundos: 1500ms deadtime 30 Est opo indica quanto tempo o host declarado como morto. warntime 10 Quanto tempo aps deve ser usado "o hearbeat atrasado"de perigo. initdead 120 Verica a primeira vez que morreu. Deve ser pelo menos duas vezes o tempo de deadtime. udpport 694 Especica a porta udp que ser usada para broadcast e unicast baud 19200 Velocidade da porta serial. serial /dev/ttyS0 Localizao da porta serial. bcast eth0 ou bcast eth1 eth2 Esta opo indica qual interface deve ser enviada os hearbeats. mcast eth0 225.0.0.1 694 1 0 congura o multicast da seguinte forma, mcast [ device ] [mascara] [ porta ] [ ttl ] [ loop ] ucast eth0 192.168.1.2 Congura um unicast da seguinte forma, ucast [ device ] [ ip ] auto_failback on Est opo determina se o resource retornar ela ira automaticamente a node primrio . Opes: on = ativa, off = desativa e legacy = Ativa automaticamente o failback no sistema quando todos os nos no suportarem est opo. O valor padro legacy. Est opo equivalente a antiga nice_failback. 60

stonith baytech /etc/ha.d/conf/stonith.baytech Est diretriz assume que h um conjunto de dispositivos stonith e sua forma de usar stonith [tipo] [arquivo] stonith_host * baytech 10.0.0.3 mylogin mysecretpassword ou stonith_host ken3 rps10 /dev/ttyS1 kathy 0 ou stonith_host kathy rps10 /dev/ttyS1 ken3 0 com est opo possvel congurar multiplos stonith, a forma de se usar stonith_host [hostfrom] [ tipo_stonith ] [ parametro ]. Para pegar a lista de stonith suportados digite stonith -L e para mais informaes digite stonith -h. watchdog /dev/watchdog watchdog o temporizador do Co de guarda. Ele funciona assim, se o prprio corao no bater por alguns minutos, a mquina ir reinicializar. Se for usar o software watchdog, ter que ser carregado o modulo com o parmetro nowayout=0 ou compila-lo com a opo CONFIG_WATCHDOG_NOWAYOUT. node ken3 ou node kathy est opo especica quais ns fazem parte do Cluster, o nome pode ser encontrado com o comando uname -n. ping 10.10.10.254 Congurao de membro de um pseudo-Cluster. ping_group group1 10.10.10.254 10.10.10.253 So a congurao de grupo de membros de um pseudo-Cluster. hbaping fc-card-name So pings destinado a canais de bra. respawn userid /path/name/to/run ou respawn hacluster /usr/lib/heartbeat/ipfail Processo de inicio e parada do heartbeat. Reinicia quando sai com valor rc=100. apiauth client-name gid=gidlist uid=uidlist ou apiauth ipfail gid=haclient uid=hacluster so controle a api por usurios. hopfudge 1 congura o nmero mximo de pulos entre os nos. 61

deadping 30 tempo de vida dos ping dos nos. hbgenmethod time Mtodo de criao de generation heartbeat. Normalmente estes so armazenados no disco e incrementados quando necessrio. realtime off Ativa ou desativa a execuo em tempo real, o valor padro on. debug 1 Congura o nvel de depurao, valor padro 0. apiauth ipfail uid=hacluster ou apiauth ccm uid=hacluster ou apiauth cms uid=hacluster ou apiauth ping gid=haclient uid=alanr,root ou apiauth default gid=haclient congura a autenticao API. o padro para ipfail e ccm uid=HA_COMUSER e para ping e cl_status gid=HA_APIGROUP msgfmt classic/netstring formato da mensagem . Valor padro: classic. use_logd yes/no Deve ser logado o daemon, valor padro no. conn_logd_time 60 O tempo de log nos intervalo de reconexo no caso de uma conexo falhar. Valor padro 60 segundos. haresources Aps congurado o arquivo ha.conf, este arquivo deve ser congurado com os nodes do arquivo anterior. Porm a principal nalidade deste arquivo estar especicando quais servios devem ser vericados. Este arquivo deve ser igual em todos os ns. Est uma lista dos recursos que se movem de mquina para mquina enquanto os conjuntos de ns caem ou levantam. No inclua "endereos administrativos" A forma de se utilizar node-name resource1 resource2 ... resourceN servios1 servios2...... serviosN Exemplos: 62

just.linux-ha.org 135.9.216.110 just.linux-ha.org 135.9.216.110 http just.linux-ha.org 135.9.216.110 135.9.215.111 135.9.216.112 httpd just.linux-ha.org 135.9.216.3/28/eth0/135.9.216.12 httpd node1 10.0.0.170 Filesystem::/dev/sda1::/data1::ext2 authkeys Este o arquivo de autenticao. A permisso dele deve ser 600 A forma dele a seguinte auth <metodo> onde auth indica qual a forma de autenticao. Os mtodos vlidos so: crc, sha1 e md5. crc mtodo que utiliza menos recurso da rede. sha1 melhor autenticao sem se preocupar com os recursos da CPU. md5 No caso da rede ser insegura e gostar de muita segurana. exemplo: auth 2 1 crc 2 sha1 HI! 3 md5 Hello!

A.3
mon.cf

Mon

O arquivo de congurao consiste em nenhuma ou mais denies de hostgroup, e uma ou mais denies de watch. Cada denio de watch pode ter uma ou mais 63

denies de servios. Uma linha comea com um espao em branco e um # que reservado a comentrios e so ignorados. As linhas so analisadas gramaticalmente enquanto so lidas. as linhas longas podem conter terminadores com os backslash \ . Se uma linha continuar e o espao em branco principal da prxima linha for removido, no nal ser considerado como somente uma nica linha. Abaixo segue um exemplo de congurao do arquivo mon.cf Opes Globais cfbasedir = /usr/lib/mon/etc Localizao dos arquivos de conguraes. alertdir = /usr/lib/mon/alert.d Localizao dos arquivos de alerta. mondir = /usr/lib/mon/mon.d Localizao dos arquivos do monitoramento do Mon. maxprocs = 20 Nmero mximo de processos. histlength = 100 Tamanho da lista do histrico. randstart = 60s Tempo de inicializao. Tipos de Autenticao authtype = getpwnam getpwnam = Senhas padro do UNIX, no para senhas no formato "shadow"3 . shadow = Senhas padro shadow do UNIX, no implementado. userle = "mon"user le. Denio de Grupo hostgroup hostname ou endereos IP exemplos:
3

xxx

64

hostgroup serversbd1 dns-yp1 foo1 bar1 hostgroup serversbd2 dns-yp2 foo2 bar2 ola3 hostgroup routers cisco7000 linuxrouter agsplus hostgroup hubs cisco316t hp800t ssii10 hostgroup workstations blue yellow red green cornower violet hostgroup netapps f330 f540 hostgroup wwwservers www hostgroup printers hp5si hp5c hp750c hostgroup new nntp hostgroup ftp ftp Seguem alguns casos de congurao das watch

watch serversbd1 service ping description ping servers in bd1 interval 5m monitor fping.monitor period wd {Mon-Fri} hr {7am-10pm} alert mail.alert mis@domain.com alert page.alert mis-pagers@domain.com alertevery 1h period NOALERTEVERY: wd {Mon-Fri} hr {7am-10pm} alert mail.alert mis@domain.com alert page.alert mis-pagers@domain.com period wd {Sat-Sun} alert mail.alert bofh@domain.com alert page.alert bofh@domain.com service telnet description telnet to servers in bd1 interval 10m monitor telnet.monitor 65

depend serversbd1:ping period wd {Mon-Fri} hr {7am-10pm} alertevery 1h alertafter 2 30m alert mail.alert mis@domain.com alert page.alert mis-pagers@domain.com begingroup watch serversbd2 service ping description ping servers in bd2 interval 5m monitor fping.monitor depend routers:ping period wd {Mon-Fri} hr {7am-10pm} alert mail.alert mis@domain.com alert page.alert mis-pagers@domain.com alertevery 1h period wd {Sat-Sun} alert mail.alert bofh@domain.com alert page.alert bofh@domain.com service telnet description telnet to servers in bd2 interval 10m monitor telnet.monitor depend routers:ping serversbd2:ping period wd {Mon-Fri} hr {7am-10pm} alertevery 1h alertafter 2 30m alert mail.alert mis@domain.com alert page.alert mis-pagers@domain.com watch mailhost service fping period wd {Mon-Fri} hr {7am-10pm} alert mail.alert mis@domain.com alert page.alert mis-pagers@domain.com alertevery 1h service telnet

66

interval 10m monitor telnet.monitor period wd {Mon-Fri} hr {7am-10pm} alertevery 1h alertafter 2 30m alert mail.alert mis@domain.com alert page.alert mis-pagers@domain.com service smtp interval 10m monitor smtp.monitor period wd {Mon-Fri} hr {7am-10pm} alertevery 1h alertafter 2 30m alert page.alert mis-pagers@domain.com service imap interval 10m monitor imap.monitor period wd {Mon-Fri} hr {7am-10pm} alertevery 1h alertafter 2 30m alert page.alert mis-pagers@domain.com service pop interval 10m monitor pop3.monitor period wd {Mon-Fri} hr {7am-10pm} alertevery 1h alertafter 2 30m alert page.alert mis-pagers@domain.com watch wwwservers service ping interval 2m monitor fping.monitor allow_empty_group period wd {Sun-Sat} alert qpage.alert mis-pagers alertevery 45m service http interval 4m

67

monitor http.monitor allow_empty_group period wd {Sun-Sat} alert qpage.alert mis-pagers upalert mail.alert -S "web server is back up" mis alertevery 45m service telnet monitor telnet.monitor allow_empty_group period wd {Mon-Fri} hr {7am-10pm} alertevery 1h alertafter 2 30m alert mail.alert mis@domain.com alert page.alert mis-pagers@domain.com Se os roteadores no estiverem comunicvel, ser enviado uma mensagem utilizando a linha telefnica ou o Protocolo IXO. Falhas no roteadores da rede so coisas srias, ento eles tm que ser checado a cada 2 minutos. watch routers service ping description routers which connect bd1 and bd2 interval 1m monitor fping.monitor period wd {Sun-Sat} alert qpage.alert mis-pagers alertevery 45m period LOGFILE: wd {Sun-Sat} alert file.alert -d /usr/lib/mon/log.d routers.log Se o mon no conseguir vericar um dos hubs, o usurio ser chamado atravs de uma mensagem no pager. watch hubs service ping interval 1m monitor fping.monitor period wd {Sun-Sat} alert qpage.alert mis-pagers alertevery 45m 68

Monitor de espao livre em disco em um servidor NFS. Quando o espao estiver entre 5 MB, ser enviado um email. Monitores terminados com ;;no sero executados em um grupo de host adicionado linha de comando. watch netapps service freespace interval 15m monitor freespace.monitor /f330:5000 /f540:5000 ;; period wd {Sun-Sat} alert mail.alert mis@domain.com \# alert delete.snapshot alertevery 1h Estaes de rede watch workstations service ping interval 5m monitor fping.monitor period wd {Sun-Sat} alert mail.alert mis@domain.com alertevery 1h Servidor de NEWS watch news service ping interval 5m monitor fping.monitor period wd {Sun-Sat} alert mail.alert mis@domain.com alertevery 1h service nntp interval 5m monitor nntp.monitor period wd {Sun-Sat} alert mail.alert mis@domain.com alertevery 1h Impressora HP watch printers 69

service ping interval 5m monitor fping.monitor period wd {Sun-Sat} alert mail.alert mis@domain.com alertevery 1h service hpnp interval 5m monitor hpnp.monitor period wd {Sun-Sat} alert mail.alert mis@domain.com alertevery 1h Servidor FTP watch ftp service ftp interval 5m monitor ftp.monitor period wd {Sun-Sat} alert mail.alert mis@domain.com alertevery 1h Servidor de terminal dial-in. watch dialin service 555-1212 interval 60m monitor dialin.monitor.wrap -n 555-1212 -t 80 ;; period wd {Sun-Sat} alert mail.alert mis@domain.com upalert mail.alert mis@domain.com alertevery 8h service 555-1213 interval 33m monitor dialin.monitor.wrap -n 555-1213 -t 80 ;; period wd {Sun-Sat} alert mail.alert mis@domain.com upalert mail.alert mis@domain.com alertevery 8h Denies 70

monitor um programa que testar uma determinada condio, retornando um valor verdadeiro ou falso, produzindo opcionalmente uma sada a ser passada ao programa scheduler. Os monitores normalmente detectam um host inalcansvel atravs de um pacote echo ICMP ou atravs de uma conexo a um servio TCP. period Indica um perodo de tempo onde interpretado o mdulo Time::Period. alert um programa que envia mensagem quando invocoda pelo scheduler. O scheduler chama um alerta quando detecta que uma falha de um monitor ocorreu. O programa de alerta aceita uma argumentos de linha de comando do scheduler, alm de dados atravs de entrada padro. hostgroup um nico host ou uma lista de hosts, especicado com nomes ou endereos IP service uma coleo de parmetros usado para tratar um monitoramento em particular que fosse fornecido por um grupo. Os servios so modelados geralmente aps vericar o servidor SMTP, o ECHO ICMP, a disponibilidade do espao em disco ou um evento SNMP. watch uma coleo de servios que se aplica a um grupo em particular. Operaes Quando o scheduler do Mon inicializado, a primeira coisa feita ler o arquivo de conguraes, assim determinado os servios que necessitam ser monitorados. O Arquivo de congurao normalmente ca em /etc/mon.cf e pode ser especicado com a opes -c parmetro. Se a opo -M for especicada, o arquivo de congura ser pre-processado com o m4. Se o arquivo de congurao j estiver no formato m4, ele ira process-lo automaticamente sem a necessidade de especicar o parmetro. O sheculer entra no lao de conexes do cliente, invocando os monitores e alertando sobre falhas. Cada servio tem um temporizador que pode ser especicado no arquivo de congurao como varivel de intervalo, o que diz ao scheduler com qual freqncia invocar um processo de monitoramento. O temporizador do scheduler pode ser parado temporariamente. 71

Programas monitores Os processos do monitor so invocados com os argumento especicados no arquivo de congurao, adicionando o hosts do grupo da aplicao. Por exemplo, se o grupo watch for "server", que contenha os hostnames "smtp", "nntp"e "ns", o monitor l as linhas da seguinte forma, monitor fping.monitor -t 4000 -r 2 e adiciona os hostnames. O fping.monitor ser executado conforme o parmetro abaixo: MONITOR_DIR/fping.monitor -t 4000 -r 2 smtp nntp ns O MONITOR_DIR o caminho atual a ser pesquisado, por padro /usr/local/lib/mon/mon.d e /usr/lib/mon/mon.d, mas pode ser modicado com a opo -s ou no arquivo de congurao. Se todos os hosts de um hostgroup forem desativados, um aviso ser enviado ao syslog e o monitor no funcionara mais. Este comportamento pode ser modicado com a opo allow_empty_group na denio do servio. Se ao nal da lina do argumento do "monitor"tiver ";;", a linha do host no ser adicionada lista de parmetro. MON_LAST_SUMMARY A primeira linha da sada aps a ltima vez que o monitor saiu. MON_LAST_OUTPUT A sada inteira do monitor da ltima vez que saiu. MON_LAST_FAILURE As duas ltimas vezes da falha deste servio. MON_FIRST_FAILURE As duas primeiras vezes que o servio falhou. MON_DESCRIPTION A descrio do servio MON_DEPEND_STATUS O status de dependncia, 0 se a dependncia falhar. MON_LOGDIR O diretrio do arquivo de log, como indicado na varivel global de congurao logdir. MON_STATEDIR O diretrio onde devem ser mantida os arquivos de estados. 72

"fping.monitor"deve retornar um status de sada 0 se terminar com sucesso, ou um valor diferente de zero se algum problema for encontrado. A primeira linha da sada do script do monitor tem um especial meaning: onde isto usado para um breve sumrio da falha detectada e logo passada ao programa de alerta. Toda sada restante passada tambm ao programa de alerta, porem no tendo nenhuma interpretao requerida Programas de alerta Os programas de alerta so encontrado no diretrio fornecido com o parmetro -a, ou no diretrio /usr/local/lib/mon/alert.d. Eles podem ser invocados com os seguintes parmetro de comando de linha. -s service Tag de servio para o arquivo de congurao. -g group Nome do grupo de host do arquivo de congurao. -h hosts Uma verso estendida do grupo de host, espao limitado, mas contendo uma nica palavra shell. -l alertevery Nmero de segundos para o prximo alerta ser enviado. -O Esta opo fornecida a um alerta somente se o alerta est sendo gerado em conseqncia de um esperado timing out -t time o time de quando esta condio da falha foi detectada -T Esta opo fornecida a um alerta somente se o alerta foi provocado por uma trap. -u Esta opo fornecida a um alerta somente se ele esta sendo chamado por um upalert. Os argumentes restantes so fornecido por parmetros adquiridos do arquivo de congurao, aps o servio de parmetro alert. Como os programas de monitoramento, os programas de alerta so invocados com as variveis ambiente denidas pelo usurio durante a denio do servio, as opes abaixo so ajustadas explicitamente pelo servidor. 73

MON_LAST_SUMMARY A primeira linha da sada aps a ltima vez que o monitor saiu. MON_LAST_OUTPUT A sada inteira do monitor da ltima vez que saiu. MON_LAST_FAILURE As duas ltimas vezes da falha deste servio. MON_FIRST_FAILURE As duas primeiras vezes que o servio falhou. MON_LAST_SUCCESS As duas ltimas vezes que o servio passou. MON_DESCRIPTION A descrio do servio MON_GROUP O grupo watch que provocou este alarme. MON_SERVICE O headin do servio que gerou este alerta. MON_RETVAL O valor da sada do programa monitor que falhou ou retorna um valor como aceito para o trap. MON_OPSTATUS Status operacional do servio. MON_ALERTTYPE Esta opo tem os seguintes valores: "failure", "up", "startup", "trap"ou "traptimeout"que signicam o tipo de alerta que foi provocado. MON_LOGDIR O diretrio do arquivo de log, como indicado na varivel global de congurao logdir. MON_STATEDIR O diretrio aonde devem ser mantida os arquivos de estados. A primeira linha da entrada padro deve ser usada como um breve sumrio do problema, normalmente fornecido como uma linha de um subjetc de um email ou 74

texto, sendo enviado a um pager. Os parmetros usuais so uma lista de receptores para entrega de noticao. A interpretao dos receptores no especicada e at o programa de alerta. Variveis Globais As seguintes variveis podem ser ajustadas como valor padro. A opo de linha de comando ter uma prioridade mais elevada nas denies. alertdir = dir Indica o diretrio onde esto os scripts de alerta. O valos padro pode ser passado pela opo -a na linha de comando. mondir = dir Indica o diretrio onde esto os scripts monitor. O valor padro pode ser passado pela opo -s na linha de comando. statedir = dir Indica o diretrio de estado. Este diretrio utilizado para salvar as informaes referentes ao estado. logdir = dir Indica o diretrio onde sero gravados os log. basedir = dir Indica o caminho da base de diretrio de estado, scripts e diretrio de alerta. cfbasedir = dir Indica o diretrio onde cam todos os arquivos de congurao. authle = le Indica o caminho do arquivo de autenticao. authtype = type [type...] Tipo de autenticao utilizada. userle = le Este arquivo usado quando o authtype for ajustado para userle. pamservice = service No caso do servio PAM for usado para autenticar. Esta opo aceita somento o parmetro pam. snmpport = portnum Congura qual porta SNMP a qual o usurio conectara. 75

serverbind = addr trapbind = addr Congura qual endereo que o serverbind e o trapbind iro utilizar. snmp = {yes|no} Ativa ou desativa o suporte a SNMP. dtlogle = le Indica o nome do arquivo que contem os registro do downtime. dtlogging = yes/no Ativa ou desativa o log de downtime. histlength = num Congura o nmero mximo dos eventos na lista do histrico. O valor padro 100. Esta opo pode ser ajustada com o parmetro -k na linha de comando. historicle = le Se esta varivel for congurada, os alertas sero logados em arquivos, e quando inicializado o servio, algum ou todos os historicos sero carregados na memria. historictime = timeval a quantidade de arquivos de histricos carregados na memria durante a inicializao. serverport = port Especica o nmero da porta TCP que o servidor vai usar. O valor padro 2583 trapport = port Especica a porta UDP que vai ser usada para transferir os trap. O valor padro 2583. pidle = path Indica o caminho do arquivo que vai ser gravado o pid. Esse valor pode ser alterado com o parmetro -P na linha de comando. maxprocs = num Indica o nmero mximo de processos 76

cltimeout = secs Congura o tempo de inatividade do usurio para dar timeout, valor em segundos. syslog_facility = facility Especica a facilidade do syslog usada no login. o valor padro daemon. startupalerts_on_reset = {yes|no} Se congurado com yes a inicializao dos alertar sero invocados pela linha de comando quando o cliente executar. O valor padro no. Sintaxe hostgroup As entradas do hosgroup comeam com a palavra chave hostgroup e so seguidas por um tag do hostgroup seguido de um ou mais hostname ou endereo IP, separados por um espao em branco. A Tag do hostgroup deve ser composta de caracteres alfanumricos, aps a primeira que no estejam em branco so consideradas hosts pertencentes ao grupo. A denio do hostgroup termina com uma linha em branco. Conforme o exemplo abaixo: hostgroup servers nameserver smtpserver nntpserver nfsserver httpserver smbserver hostgroup router_group cisco7000 agsplus Sintaxe de grupo watch A entradas watch comeam com a linha com a palavra chave watch seguido por um espao em branco e por uma nica palavra que normalmente referencia um hostgroup predenido. Se a segunda palavra no for reconhecida como uma tag do hostgroup, um hostgroup novo ser criado com esse nome. As entradas watch consistem em uma ou mais denies de servios. Denies de servio service servicename Uma denio de servio comea com est palavra chave seguida por uma palavra que seja uma Tag para este servio interval timeval A palavra chave interval seguida de uma valor especica com que freqncia o scrip monitor ir disparar. Os valores so denidos como 30s. 5m, 1h, 1d , 1.5h este ltimo representa uma hora e meia. 77

traptimeout timeval Esta palavra chave faz exame do mesmo argumento de especicao internal, e faz o servio esperar ao menos um trap de uma fonte externa. Isso usado para o servio heartbeat-style. trapduration timeval Se o trap for recebido dentro do tempo, o status do servio do trap continuar normal, permanecendo constante. randskew timeval Coloca o scheduler do monitor de script para funcionar no incio de cada intervalo, ele ter um ajuste aleatrio durante o intervalo de tempo especicado pelo parmetro. monitor monitor-name [arg...] A palavra chave monitor seguida por um nome de script especica para o monitor roda-lo quando o tempo espirar. allow_empty_group A opo allow_empty_group permitira que um monitor seja invocado mesmo quando o hostgroup para essa watch esteja vazio por causa de um host desativado. description descriptiontext Um texto seguido de uma descrio perguntada pelo programa cliente, passando aos alertas e aos monitores por uma varivel de ambiente. Deve conter uma descrio breve do servio, apropriada para a incluso em e-mail ou em uma web page. exclude_hosts host [host...] Qualquer host listado aps exclude_hosts ser excludo da vericao do servio exclude_period periodspec No execute o monitor programado durante o tempo identicado pelo periodspec depend dependexpression A palavra chave depend usada para especicar a expresso da dependncia, seu valor pode ser verdadeiro ou falso, no senso booleanico. Dependendo a expresso Perl e de vrias outras regras de sintaxe. Esta feature pode ser usada para controlar alerta de servios que depende de outro servio. 78

dep_behavior {a|m} A avaliao da dependncia grca pode ser controlada a suspenso de alertas ou monitorao invocadas. Alert suppression Se a opo for congurada como a, a expresso de dependncia ira avaliar aps o monitoramento do servio ou aps o trap ser recebido. Monitor suppression Se a opo for congurada como m, a expresso de dependncia ira avaliar antes de um servio ter sido executado. Denies de perodo Os perodos so usados para denir as circunstncias que devem permitir que os alertas sejam enviados. period [label:] periodspec Um period agrupa um ou mais alarmes e variveis que controlam, com qual freqencia um alerta acontece quando h uma falha. A palavra chave period tem duas formas. A primeira faz o exame do argumento que seja uma especicao do perodo do mdulo do Perl 5 a Time::Period de Patrick Ryan. A segunda forma requer um nome para a especicao do period, como denido acima. Este nome uma Tag que consistem em um caracter alfabtico ou em um underscore seguido por zero ou mais indicadores alfanumricos que terminados por dois pontos. Esta forma permite mltiplos periods com a mesma denio de period. alertevery timeval [observe_detail] A palavra chave alertevery faz um exame do mesmo tipo de argumento que a varivel interval e limita o nmero de vezes que um alerta emitido quando o servio continua a falhar. alertafter num ou alertafter num timeval alertafter timeval A palavra chave alertafter tem trs formas: a primeira onde tem somente o argumento num, outra que tem os argumentos num trimeval e a terceira que tem trimeval. Na primeira forma, um alerta ser invocado somente aps a quantidade do nmero de falhas consecutivas especicadas em num. Na segunda forma, os argumentos um valor inteiro seguido por um intervalo de tempo, funcionando da mesma forma que a anterior. Caso haja 79

falhas em um intervalo de tempo ela so; exemplo: 3 falhas em 30 minutos. E na terceira forma, o argumento o interval, como descrito pela tem anterior, os alertas para esse perodo sero chamados somente se o servio estiver em um estado de falhas para mais que o tempo descrito pelo interval. numalerts num Esta varivel diz ao servidor para chamar no mais que o num de alertas durante uma falha. no_comp_alerts Se est opo for especicadas, os upalerts sero chamados sempre que o estado do servio mudar de falho para sucesso. alert alert [arg...] Um period pode conter vrios alertas, que so provocados por falhas de servio. Um alerta especicado com a palavra chave alert seguido de um parmetro de sada e pelos argumentos que so interpretador da mesma forma que na denio do Monitor. failure_interval timeval Ajusta o intervalo de vericao do timeval em que a vericao do servio est falhando. Reinicia o intervalo original quando o servio bem sucedido. upalert alert [arg...] Um upalert um complemento de um alert, um upalert chamado quando os servios fazem a transio do estado de falhar para sucesso, se corresponder a down um alerta ser previamente enviado. startupalert alert [arg...] um startualert chamado somente quando o usurio do Mom inicia a execuo. upalertafter timeval O parmetro upalertafter especicado com uma string de parmetro de intervalo, como por exemplo 30s, 1m e etc e controles de disparo do upalert. Se um servio voltar aps estar caido por um momento maior do que o especicado nesta opo, um upalert ser chamado. MON TRAPPING Mon tem a facilidade para receber um mon traps especial de todas as mquinas ou de uma mquina remota. Atualmente, o nico mtodo disponvel para enviar 80

um mon trap e atravs da relao do classe Perl Mon::Client, embora o formato do pacote seja UDP ele bem denido para permitir as escrita das traps em outras linguagens. As traps so cabealhos semelhantes ao monitores, uma trap envia um status operacional, um texto de descrio e o Mon gera um alerta ou um upalert quando necessrio. Elas podem ser travadas por qualquer grupo watch/service especicado no arquivo de congurao do Mon, porm aconselhvel congurar grupos watch/service especicamente para cada tripo de traps que se esperado receber. Quando denido um grupo especial de watch/service para traps, no inclua as diretrizes do monitor, pois no necessrio invocar um monitor. Desde que um monitor no esteja sendo invocado, no necessrio que a denio watch tenha um hostgroup que contenha os nomes reais dos hosts. Somente faa o nome do usurio e o Mon automaticamente criar um grupo watch. Abaixo segue um exemplo do arquivo de congurao: watch trap-service service host1-disks description TRAP: for host1 disk status period wd {Sun-Sat} alert mail.alert someone@your.org upalert mail.alert -u someone@your.org O Mon escuta as portas UDP para qualquer trap, um padro de facilidade disponvel para handling traps aos grupos desconhecidos ou servios. Para ativar tal facilidade, deve ser includo um grupo padro watch de servios que deve conter as especicaes dos alarms. Se um grupo padro watch e seus servios no forem congurados, traps desconhecidos sero logados via syslog e nenhum alarme sera enviado. Caso queira mais facilidade, utilize o default/default para travar todas as traps. Seria mais indicado desabilitar os upalerts e usar as varivel de ambiente MON_TRAP_INTENDED em scripts de alerta para fazer os alertas mais signicativo. Abaixo segue um exemplo padro watch default service default description Default trap service period wd {Sun-Sat} alert mail.alert someone@your.org upalert mail.alert -u someone@your.org 81

auth.cf A especicao do arquivo para as variveis de autenticao esto no arquivo de congurao, ou passado pelo parmetro -A, que ser lido na inicializao. Este arquivo dene as restries referentes ao comandos que os usurios podem executar. O arquivo de autenticao em modo texto que consiste em comentrios, denies de comandos e parmetros trap para autenticao. As linhas em branco so ignoradas. O arquivo separado pela seo do comando e uma seo trap. As sees so especicadas por uma nica linha que contem as seguintes formas: command section ou trap section A denio do comando consiste em um comando, seguido por dois pontos e por uma lista de usurios separado por vrgula. O padro que nenhum usurio pode executar todos os comandos, a menos que for explicitamente permitido neste arquivo de congurao. Para maior detalhe, um usurio pode ser negado prexando o seu nome com um !. Se a palavra AUTH_ANY for usada para um usurio, todos os usurio autenticado executaro o comando. A seo trap permite a congurao de quais usurios podem enviar traps para um hosts. A sintaxe um host fonte, que pode ser o nome ou o endereo IP, um espao em branco, um usurio e uma senha em texto puro. Se um usurio for *, ento todos os traps de todos os hosts sero aceitos sem considerar o usurio e a senha. Se nenhum host ou senha for especicado, ento nenhum trap ser aceito. Um exemplo do arquivo de congurao:

command section list: all reset: root,admin loadstate: root savestate: root trap section 82

127.0.0.1

root

r@@tp4sswrd

Isto signica que todos os clientes podem executar a lista de comando, porm s o root pode executar o reset, loadstate e savestate. O admin so pode executar o comando do reset. Arquivo de congurao de autenticao Sintaxe: comando: {user|all}[,user...] Abaixo segue um exemplo do arquivo de congurao Sesso de comandos ack: AUTH_ANY checkauth: all clear: AUTH_ANY disable: AUTH_ANY dump: AUTH_ANY enable: AUTH_ANY get: AUTH_ANY list: all loadstate: AUTH_ANY protid: all quit: all reload: AUTH_ANY reset: AUTH_ANY savestate: AUTH_ANY servertime: all set: AUTH_ANY start: AUTH_ANY stop: AUTH_ANY term: AUTH_ANY test: AUTH_ANY version: all

83

84

Apndice B

Log
Nesta sesso ser abordado os log gerado por cada programa do estudo de casos

B.1

Drbd - Servidor ND

Jul 26 18:05:42 nd syslogd 1.4.1: restart. Jul 26 18:05:43 nd kernel: klogd 1.4.1, log source = /proc/kmsg started. Jul 26 18:07:08 nd kernel: drbd: initialised. Version: 0.7.10 (api:77/proto:74) Jul 26 18:07:08 nd kernel: drbd: SVN Revision: 1743 build by root@nd.nide.com.br, 2005-05-19 10:45:31 Jul 26 18:07:08 nd kernel: drbd: registered as block device major 147 Jul 26 18:07:09 nd kernel: drbd0: resync bitmap: bits=366848 words=11464 Jul 26 18:07:09 nd kernel: drbd0: size = 1433 MB (1467392 KB) Jul 26 18:07:09 nd kernel: drbd0: 0 KB marked out-of-sync by on disk bit-map Jul 26 18:07:09 nd kernel: drbd0: Found 3 transactions (3 active extents) in activity log. Jul 26 18:07:09 nd kernel: drbd0: drbdsetup [5584]: cstate Unconfigured --> StandAlone Jul 26 18:07:09 nd kernel: drbd0: drbdsetup [5597]: cstate StandAlone --> Unconnected Jul 26 18:07:09 nd kernel: drbd0: drbd0_receiver [5598]: cstate Unconnected --> WFConnection Jul 26 18:07:13 nd kernel: drbd0: drbd0_receiver [5598]: cstate WFConnection --> WFReportParams Jul 26 18:07:13 nd kernel: drbd0: Handshake successful:

85

DRBD Network Protocol version 74 Jul 26 18:07:13 nd kernel: drbd0: Connection established. Jul 26 18:07:13 nd kernel: drbd0: I am(S): 1:00000004:00000001:0000001d:00000004:00 Jul 26 18:07:13 nd kernel: drbd0: Peer(S): 1:00000004:00000001:0000001d:00000004:00 Jul 26 18:07:13 nd kernel: drbd0: drbd0_receiver [5598]: cstate WFReportParams --> Connected Jul 26 18:07:13 nd kernel: drbd0: Secondary/Unknown --> Secondary/Secondary

B.2

Drbd - Servidor 03

Jul 26 18:07:26 servidor3 syslogd 1.4.1: restart. Jul 26 18:07:27 servidor3 kernel: klogd 1.4.1, log source = /proc/kmsg started. Jul 26 18:09:32 servidor3 kernel: drbd: initialised. Version: 0.7.10 (api:77/proto:74) Jul 26 18:09:32 servidor3 kernel: drbd: SVN Revision: 1743 build by root@servidor3.nide.com.br, 2005-07-20 14:29:52 Jul 26 18:09:32 servidor3 kernel: drbd: registered as block device major 147 Jul 26 18:09:32 servidor3 kernel: drbd0: resync bitmap: bits=366848 words=11464 Jul 26 18:09:32 servidor3 kernel: drbd0: size = 1433 MB (1467392 KB) Jul 26 18:09:33 servidor3 kernel: drbd0: 0 KB marked out-of-sync by on disk bit-map. Jul 26 18:09:33 servidor3 kernel: drbd0: drbdsetup [3193]: cstate Unconfigured --> StandAlone Jul 26 18:09:33 servidor3 kernel: drbd0: drbdsetup [3206]: cstate StandAlone --> Unconnected Jul 26 18:09:33 servidor3 kernel: drbd0: drbd0_receiver [3207]: cstate Unconnected --> WFConnection Jul 26 18:09:33 servidor3 kernel: drbd0: drbd0_receiver [3207]: cstate WFConnection --> WFReportParams Jul 26 18:09:33 servidor3 kernel: drbd0: Handshake successful: DRBD Network Protocol version 74 Jul 26 18:09:33 servidor3 kernel: drbd0: Connection established. Jul 26 18:09:33 servidor3 kernel: drbd0: I am(S): 1:00000004:00000001:0000001d:00000004:00 Jul 26 18:09:33 servidor3 kernel: drbd0: Peer(S): 1:00000004:00000001:0000001d:00000004:00 Jul 26 18:09:33 servidor3 kernel: drbd0: drbd0_receiver [3207]: cstate WFReportParams --> Connected

86

Jul 26 18:09:33 servidor3 kernel: drbd0: Secondary/Unknown --> Secondary/Secondary

B.3

Heartbeat - Servidor ND

Jul 26 18:08:07 nd heartbeat: [5654]: info: ************************** Jul 26 18:08:07 nd heartbeat: [5654]: info: Configuration validated. Starting heartbeat 1.99.4 Jul 26 18:08:07 nd heartbeat: [5655]: info: heartbeat: version 1.99.4 Jul 26 18:08:08 nd heartbeat: [5655]: info: Heartbeat generation: 16 Jul 26 18:08:08 nd heartbeat: [5655]: info: glib: UDP Broadcast heartbeat started on port 694 (694) interface eth0 Jul 26 18:08:08 nd heartbeat: [5655]: info: pid 5655 locked in memory. Jul 26 18:08:08 nd heartbeat: [5655]: info: Local status now set to: up Jul 26 18:08:08 nd heartbeat: [5658]: info: pid 5658 locked in memory. Jul 26 18:08:08 nd heartbeat: [5659]: info: pid 5659 locked in memory. Jul 26 18:08:08 nd heartbeat: [5660]: info: pid 5660 locked in memory. Jul 26 18:08:08 nd heartbeat: [5655]: info: Link nd:eth0 up. Jul 26 18:08:10 nd heartbeat: [5655]: info: Link servidor3:eth0 up. Jul 26 18:08:10 nd heartbeat: [5655]: info: Local status now set to: active Jul 26 18:08:10 nd heartbeat: [5655]: info: Status update for node servidor3: status up Jul 26 18:08:10 nd heartbeat: [5655]: info: Status update for node servidor3: status active Jul 26 18:08:10 nd heartbeat: info: Running /etc/ha.d/rc.d/ status status Jul 26 18:08:10 nd heartbeat: info: Running /etc/ha.d/rc.d/ status status Jul 26 18:08:22 nd heartbeat: [5655]: info: local resource transition completed Jul 26 18:08:22 nd heartbeat: [5655]: info: Initial resource acquisition complete (T_RESOURCES(us)) Jul 26 18:08:22 nd heartbeat: [5655]: info: remote resource transition completed. Jul 26 18:08:23 nd heartbeat: [5674]: info: Local Resource acquisition completed. Jul 26 18:08:23 nd heartbeat: info: Running /etc/ha.d/rc.d/ ip-request-resp ip-request-resp Jul 26 18:08:23 nd heartbeat: received ip-request-resp IPaddr::10.0.0.201 OK yes Jul 26 18:08:23 nd heartbeat: info: Acquiring resource group: nd IPaddr::10.0.0.201 drbddisk httpd

87

Jul 26 18:08:23 nd heartbeat: info: Running /etc/ha.d/resource.d/IPaddr 10.0.0.201 start Jul 26 18:08:23 nd heartbeat: info: /sbin/ifconfig eth0:0 10.0.0.201 netmask 255.0.0.0\^Ibroadcast 10.255.255.255 Jul 26 18:08:23 nd heartbeat: info: Sending Gratuitous Arp for 10.0.0.201 on eth0:0 [eth0] Jul 26 18:08:23 nd heartbeat: /usr/lib/heartbeat/send_arp -i 500 -r 10 -p /var/lib/heartbeat/rsctmp/send_arp/send_arp-10.0.0.201 eth0 10.0.0.201 auto 10.0.0.201 ffffffffffff Jul 26 18:08:23 nd heartbeat: info: Running /etc/ha.d/resource.d/drbddisk start Jul 26 18:08:23 nd kernel: drbd0: Secondary/Secondary --> Primary/Secondary Jul 26 18:08:24 nd heartbeat: info: Running /etc/ha.d/resource.d/httpd start

B.4

Heartbeat - Servidor 03
************************** Configuration validated. heartbeat: Heartbeat glib: UDP Broadcast pid 3266 locked Local status now pid 3269 locked pid 3270 locked pid 3271 locked Link servidor3: Link nd:eth0 Status update Local status

Jul 26 18:10:30 servidor3 heartbeat: [3265]: info: Jul 26 18:10:30 servidor3 heartbeat: [3265]: info: Starting heartbeat 1.99.4 Jul 26 18:10:30 servidor3 heartbeat: [3266]: info: version 1.99.4 Jul 26 18:10:30 servidor3 heartbeat: [3266]: info: generation: 16 Jul 26 18:10:30 servidor3 heartbeat: [3266]: info: heartbeat started on port 694 (694) interface eth0 Jul 26 18:10:30 servidor3 heartbeat: [3266]: info: in memory. Jul 26 18:10:30 servidor3 heartbeat: [3266]: info: set to: up Jul 26 18:10:30 servidor3 heartbeat: [3269]: info: in memory. Jul 26 18:10:30 servidor3 heartbeat: [3270]: info: in memory. Jul 26 18:10:30 servidor3 heartbeat: [3271]: info: in memory. Jul 26 18:10:30 servidor3 heartbeat: [3266]: info: eth0 up. Jul 26 18:10:30 servidor3 heartbeat: [3266]: info: up. Jul 26 18:10:30 servidor3 heartbeat: [3266]: info: for node nd: status active Jul 26 18:10:30 servidor3 heartbeat: [3266]: info:

88

now set to: active Jul 26 18:10:30 servidor3 heartbeat: info: Running /etc/ha.d/rc.d/status status Jul 26 18:10:42 servidor3 heartbeat: [3266]: info: local resource transition completed. Jul 26 18:10:42 servidor3 heartbeat: [3266]: info: Initial resource acquisition complete (T_RESOURCES(us)) Jul 26 18:10:42 servidor3 heartbeat: [3266]: info: remote resource transition completed. Jul 26 18:10:42 servidor3 heartbeat: [3278]: info: No local resources [/usr/lib/heartbeat/ResourceManager listkeys servidor3] to acquire. Jul 26 18:10:43 servidor3 kernel: drbd0: Secondary/Secondary --> Secondary/Primary

B.5

Mon - Servidor 03

Jul 26 18:11:22 servidor3 mon[3287]: mon server started

B.6

Primeiro servidor cai

Jul 26 18:10:27 nd kernel: eth0: Setting half-duplex based on MII #1 link partner capability of 0000. Jul 26 18:10:29 nd heartbeat: [5655]: info: Resources being acquired from servidor3. Jul 26 18:10:29 nd heartbeat: [5655]: info: Link servidor3:eth0 dead. Jul 26 18:10:29 nd heartbeat: info: Running /etc/ha.d/rc.d/status status Jul 26 18:10:29 nd heartbeat: info: /usr/lib/heartbeat/ mach_down: nice_failback: foreign resources acquired Jul 26 18:10:29 nd heartbeat: [5655]: info: mach_down takeover complete. Jul 26 18:10:29 nd heartbeat: info: mach_down takeover complete for node servidor3. Jul 26 18:10:29 nd heartbeat: [5914]: info: Local Resource acquisition completed. Jul 26 18:10:36 nd kernel: drbd0: drbd0_asender [5608]: cstate Connected --> NetworkFailure Jul 26 18:10:36 nd kernel: drbd0: asender terminated Jul 26 18:10:36 nd kernel: drbd0: drbd0_receiver [5598]: cstate NetworkFailure --> BrokenPipe Jul 26 18:10:36 nd kernel: drbd0: worker terminated Jul 26 18:10:36 nd kernel: drbd0: drbd0_receiver [5598]:

89

cstate BrokenPipe --> Unconnected Jul 26 18:10:36 nd kernel: drbd0: Connection lost. Jul 26 18:10:36 nd kernel: drbd0: drbd0_receiver [5598]: cstate Unconnected --> WFConnection Jul 26 18:11:37 nd heartbeat: [5655]: info: See documentation for information on tuning deadtime.

B.7

Segundo servidor assume

Jul 26 18:12:51 servidor3 heartbeat: [3266]: info: Resources being acquired from nd. Jul 26 18:12:51 servidor3 heartbeat: [3266]: info: Link nd:eth0 dead. Jul 26 18:12:51 servidor3 heartbeat: info: Running /etc/ha.d/rc.d/status status Jul 26 18:12:51 servidor3 heartbeat: info: Taking over resource group IPaddr::10.0.0.201 Jul 26 18:12:51 servidor3 heartbeat: [3298]: info: No local resources [/usr/lib/heartbeat/ResourceManager listkeys servidor3] to acquire. Jul 26 18:12:51 servidor3 heartbeat: info: Acquiring resource group: nd IPaddr::10.0.0.201 drbddisk httpd Jul 26 18:12:51 servidor3 heartbeat: info: Running /etc/ha.d/res ource.d/IPaddr 10.0.0.201 start Jul 26 18:12:51 servidor3 heartbeat: info: /sbin/ifconfig eth0:0 10.0.0.201 netmask 255.0.0.0\^Ibroadcast 10.255.255.255 Jul 26 18:12:51 servidor3 heartbeat: info: Sending Gratuitous Arp for 10.0.0.201 on eth0:0 [eth0] Jul 26 18:12:51 servidor3 heartbeat: /usr/lib/heartbeat/send_arp -i 500 -r 10 -p /var/lib/heartbeat/rsctmp/send_arp/send_arp10.0.0.201 eth0 10.0.0.201 auto 10.0.0.201 ffffffffffff Jul 26 18:12:51 servidor3 heartbeat: info: Running /etc/ha.d/ resource.d/drbddisk start Jul 26 18:12:56 servidor3 kernel: drbd0: drbd0_asender [3217]: cstate Connected --> NetworkFailure Jul 26 18:12:56 servidor3 kernel: drbd0: asender terminated Jul 26 18:12:56 servidor3 kernel: drbd0: drbd0_receiver [3207]: cstate NetworkFailure --> BrokenPipe Jul 26 18:12:56 servidor3 kernel: drbd0: worker terminated Jul 26 18:12:56 servidor3 kernel: drbd0: drbd0_receiver [3207]: cstate BrokenPipe --> Unconnected Jul 26 18:12:56 servidor3 kernel: drbd0: Connection lost. Jul 26 18:12:56 servidor3 kernel: drbd0: drbd0_receiver [3207]: cstate Unconnected --> WFConnection Jul 26 18:12:56 servidor3 kernel: drbd0: Secondary/Unknown --> Pr

90

imary/Unknown Jul 26 18:12:56 servidor3 heartbeat: info: Running /etc/ha.d/resou rce.d/httpd start Jul 26 18:12:57 servidor3 heartbeat: info: /usr/lib/heartbeat/mach _down: nice_failback: foreign resources acquired Jul 26 18:12:57 servidor3 heartbeat: [3266]: info: mach_down takeover complete. Jul 26 18:12:57 servidor3 heartbeat: info: mach_down takeover complete for node nd.

B.8

Primeiro servidor volta

Jul 26 18:11:37 nd heartbeat: [5655]: info: Link servidor3:eth0 up. Jul 26 18:11:37 nd heartbeat: [5655]: info: Status update for node servidor3: status active Jul 26 18:11:37 nd heartbeat: [5655]: info: No pkts missing from servidor3! Jul 26 18:11:37 nd heartbeat: info: Running /etc/ha.d/rc.d/status status Jul 26 18:11:37 nd kernel: eth0: Setting full-duplex based on MII \#1 link partner capability of 4de1. Jul 26 18:11:39 nd heartbeat: [5655]: info: Heartbeat shutdown in progress. (5655) Jul 26 18:11:39 nd heartbeat: [5655]: info: Received shutdown notice from servidor3. Jul 26 18:11:39 nd heartbeat: [5655]: info: Resource takeover cancelled - shutdown in progress. Jul 26 18:11:39 nd heartbeat: [5980]: info: Giving up all HA resources.

B.9

Segundo servidor libera os servios

[3266]: info: See documentation for [3266]: info: Link nd:eth0 up. [3266]: info: Status update for node info: Running /etc/ha.d/rc.d/status status [3266]: info: No pkts missing from nd! [3266]: info: Heartbeat shutdown in [3595]: info: Giving up all HA resources. info: Releasing resource group: nd info: Running /etc/ha.d/resource.d/httpd

Jul 26 18:13:57 servidor3 heartbeat: information on tuning deadtime. Jul 26 18:13:57 servidor3 heartbeat: Jul 26 18:13:57 servidor3 heartbeat: nd: status active Jul 26 18:13:57 servidor3 heartbeat: Jul 26 18:13:57 servidor3 heartbeat: Jul 26 18:13:59 servidor3 heartbeat: progress. (3266) Jul 26 18:13:59 servidor3 heartbeat: Jul 26 18:13:59 servidor3 heartbeat: IPaddr::10.0.0.201 drbddisk httpd Jul 26 18:13:59 servidor3 heartbeat:

91

stop Jul 26 18:13:59 stop Jul 26 18:13:59 Jul 26 18:13:59 10.0.0.201 stop Jul 26 18:13:59 Jul 26 18:13:59 Jul 26 18:13:59

servidor3 heartbeat: info: Running /etc/ha.d/resource.d/drbddisk servidor3 kernel: drbd0: Primary/Unknown --> Secondary/Unknown servidor3 heartbeat: info: Running /etc/ha.d/resource.d/IPaddr servidor3 heartbeat: info: /sbin/route -n del -host 10.0.0.201 servidor3 heartbeat: info: /sbin/ifconfig eth0:0 down servidor3 heartbeat: info: IP Address 10.0.0.201 released

B.10

Servidor de Alta-Disponibilidade perde conectividade com o Roteador

Jul 26 18:15:13 servidor3 mon[3287]: failure for roteador ping 1122416113 unidentified output from fping: [ICMP Host Unreachable from 192.168.200.2 for ICMP Echo sent to 192.168.200.254] Jul 26 18:15:13 servidor3 mon[3287]: calling alert mail.alert for roteador/ping (/usr/lib/mon/alert.d/mail.alert,nd@nide.com.br) unidentified output from fping: [ICMP Host Unreachable from 192.168.200.2 for ICMP Echo sent to 192.168.200.254]

92

Apndice C

CD
Esta sesso leva um CD, onde nele conter uma cpia digital em formato PDF desta monograa, os programas para se implementar um servidor de Alta-Disponibilidade, os e-books utilizado como referncia para a elaborao desta monograa e os logs de todo o estudo de caso.

93