From UnderLinux Wiki

Unioeste – Universidade Estadual do Oeste do Paraná
CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS
Colegiado de Informática
Curso de Bacharelado em Informática
Alta Disponibilidade Utilizando o Sistema Operacional Linux
Mauro Alexandre Nogueira Cascavel
2002

Monografia apresentada como requisito
parcial para obtenção do grau de Bacharel em Informática.
Curso de Bacharelado em Informática.
Centro de Ciências Exatas e Tecnológicas.
Universidade Estadual do Oeste do Paraná - Campus de Cascavel.
Orientador: Prof. Francisco Sérgio Sambatti
Co-Orientador: Marcio Seiji Oyamada

DEDICATÓRIA

Dedico, primeiramente a Deus, por sempre me guiar e ter me dado forças para superar os obstáculos. Aos meus pais, por todo o incentivo e apoio em todos os aspectos e principalmente pela compreensão estar longe e, por muitas vezes não poder estar em casa em datas importantes.

AGRADECIMENTOS Agradeço ao meu orientador, o “ Chicão”, e ao meu co-orientador, o “Tio” Márcio pela paciência e prestabilidade nos momentos de dúvidas e pelos “Terabytes” de informações por eles ditas e mesmo tendo assimilado apenas alguns poucos “bytes”, sem eles não seria possível realizar este trabalho. Aos demais professores pela amizade e pelos ensinamentos. Aos meus amigos “Daltão”, Toshio, “Marcão”, “Paulão”, Mônica e a todos os demais colegas de turma, do curso, que sempre estiverem ao meu lado ao longo desses cinco anos de graduação, compartilhando bons e maus momentos, muitas festas e muitos trabalhos. Aos seguranças (os “guardinhas”) da UNIOESTE, que sempre se mostraram prestativos nas muitas madrugadas e finais de semana que passávamos nos laboratórios do nosso curso. Aos demais funcionários da universidade, principalmente a Carin e ao Nelson por serem prestativos e atender aos nossos pedidos junto aos laboratórios do curso. Ao outro integrante da “República dos Fera”, o amigo Reinaldo, que por muitas vezes me liberou de lavar a louça para que pudesse desenvolver este trabalho. Pelas muitas risadas juntos no tempo em que convivemos “rachando” um kitinete. A todas as pessoas que, de uma maneira ou de outra, contribuíram para que eu pudesse passar por esses anos na universidade e chegasse ao seu final. A todos, muito obrigado. RESUMO A alta disponibilidade objetiva manter em operação serviços prestados por um sistema computacional, através da redundância recursos. Esta idéia se torna mais atrativa quando é utilizado software gratuito operando em computadores de uso comum e de custo mais baixo do que os utilizados em sistemas construídos com esta finalidade. Este trabalho realiza uma análise de algumas das ferramentas disponíveis para o sistema operacional gratuito Linux, constatando, de maneira empírica a cobertura abrangida por essas ferramentas. Palavras Chaves: Alta disponibilidade, tolerância a falhas, Linux, heartbeat, MON, DRBD.

LISTA DE TABELAS TABELA 1: Parâmetros de configuração do arquivo /etc/ha.d/ha.cf TABELA 2: Métodos de autenticação para o heartbeat TABELA 3: Configuração do sistema TABELA 4: Resultados obtidos nos testes

Sumário 1 INTRODUÇÃO 2 FUNDAMENTAÇÃO TEÓRICA

 2.1   DEFEITO, ERRO E FALHA
 2.2   TOLERÂNCIA A FALHAS
 2.3   FASES NA TOLERÂNCIA A FALHAS
    2.3.1    Detecção de Erros 6
    2.3.2    Confinamento dos Danos
    2.3.3    Recuperação de Erro
    2.3.4    Tratamento da Falha e Continuidade de Serviço
 2.4   FUNDAMENTOS DA ALTA DISPONIBILIDADE

3 FERRAMENTAS PARA ALTA DISPONIBILIDADE NO SISTEMA OPERACIONAL LINUX

 3.1   DISTRIBUTED REPLICATED BLOCK DEVICE (DRBD)
 3.2   HEARTBEAT
 3.3   MON

4 AVALIAÇÃO DAS FERRAMENTAS DE ALTA DISPONIBILIDADE NO SISTEMA OPERACIONAL LINUX

 4.1   EXPECTATIVAS PARA O SISTEMA PROPOSTO
 4.2   CONFIGURAÇÃO DO SISTEMA PROPOSTO
 4.3   TESTES REALIZADOS
    4.3.1    Teste 1 – Queda e Retorno do Nodo Primário
    4.3.2    Teste 2 – Queda e Retorno Seqüencial
    4.3.3    Teste 3 – Retorno Inverso
    4.3.4    Teste 4 – Queda na Ordem Inversa dos Nodos
    4.3.5    Teste 5 – Queda e Retorno Nodo Secundário
    4.3.6    Teste 6 – Nodo Primário Isolado
    4.3.7    Teste 7 – Falha na Interface Serial (Heartbeat)
    4.3.8    Teste 8 – Falha na Interface de Rede Dedicada
    4.3.9    Teste 9 – Falha no Disco de Dados
    4.3.10   Teste 10 – Consistência dos Dados em Caso de Falha do Nodo Primário
 4.4   RESULTADOS OBTIDOS

5 CONCLUSÕES REFERÊNCIAS BIBLIOGRÁFICAS ANEXO I ANEXO II ANEXO III ANEXO IV

INTRODUÇÃO

                 Os sistemas de computação estão auxiliando cada vez mais as atividades das

pessoas, que passam a depender mais fortemente das funcionalidades dos mesmos. À medida que mais pessoas são beneficiadas pela máquina, maior é o prejuízo causado pelos problemas ocorridos no funcionamento destas.

                 Dessa forma, torna-se necessária a utilização de mecanismos para lidar com

os problemas que potencialmente possam afetar os sistemas. Tolerância à falhas é um desses mecanismos. Diferente da prevenção de falhas, tolerar falhas do sistema, implica em reconhecer que as falhas são inevitáveis; tendo origem em erros de projeto ou de implementação, desgaste do material ou colapsos na fonte de energia; e oferecer alternativas que permitam ao sistema manter o funcionamento desejado mesmo na ocorrência de falhas. Ainda que todo cuidado tenha sido empregado, utilizando técnicas formais de especificação e refinamento dos projetos e verificações de que a implementação dos algoritmos está correta, o software depende do hardware para executar suas funções, estando este sujeito ao desgaste físico do material, que é inevitável com o passar do tempo. Portanto para sistemas críticos, onde uma falha acarreta grandes prejuízos ou riscos, um bom método de tolerância a falhas deve ser empregado.

                 Para se adquirir tolerância a falhas, faz-se necessário o uso de redundância,

seja ela de componentes de software, hardware ou dados.

                 Evitar falhas é praticamente impossível, visto que não se consegue

determinar todos os tipos de problemas que podem ocorrer em um sistema computacional (geralmente sistemas que exijam tolerância a falhas e, consequentemente, alta disponibilidade tendem a ser complexos). Por mais minuciosa que seja a identificação de falhas, muitas delas ainda assim, passarão desapercebidas durante as fases de projeto, elaboração e concepção do sistema.

                 A partir da concepção de sistemas tolerantes a falhas, é possível, então,

construir um sistema com alta disponibilidade . Quando um sistema torna-se tolerante a falhas (ou tenta alcançar o maior grau de tolerância possível), menor é a possibilidade de que problemas afetem o sistema e sua funcionalidade.

                                                                                           2
                 Alta disponibilidade é a “...habilidade do sistema em restaurar operações

corretas, permitindo continuar fornecendo serviços durante períodos quando alguns componentes tenham falhado.” (BIRMAN, 1995, p. 29) Ou seja, mesmo quando acontece alguma ação que seja anormal à execução de um serviço e que comprometa o atendimento das requisições dos usuários, o sistema ainda consiga, de alguma maneira continuar em execução da forma mais normal possível, sem que o usuário perceba.

                 O Capítulo 2 trata aspectos relativos a natureza das falhas; quais são os

motivos que levam a ocorrência de uma, quando e porquê uma falha ocorre, quais são os precedentes de uma falha e suas ocorrências, bem como elas podem ser classificadas, conforme sua origem ou tipo. Este capítulo aborda também questões teóricas acerca da tolerância a falhas, desenvolvendo um contexto para elaboração de planos de correção e manipulação de problemas; as fases que ocorrem (ou devem ocorrer) quando implementa-se sistemas computacionais tolerantes a falhas. As fases estão divididas de maneira que os problemas possam ser detectados, avaliados e corrigidos, levando em consideração que durante todo esse processo, o usuário não perceba que isso ocorreu (transparência ao usuário).

                 O Capítulo 3 faz uma abordagem sobre algumas das ferramentas de alta

disponibilidade disponíveis no sistema operacional Linux, demonstrando a sua lógica de funcionamento, bem como alguns parâmetros de configuração necessários.

                 No Capítulo 4 estão definidas as expectativas que se têm para um sistema

com essa característica (alta disponibilidade) e em quais situações é desejável que o ambiente seja capaz de lidar em caso de problemas. O capítulo trata também da avaliação realizada no sistema, baseada nos testes práticos, elaborados a partir de situações típicas e algumas atípicas pelo qual um sistema computacional pode passar. As avaliações levam em consideração a ocorrência do problema, a expectativa de comportamento e o comportamento que o sistema apresentou.

2 FUNDAMENTAÇÃO TEÓRICA 2.1 Defeito, Erro e Falha

                 Para se entender as causas e conseqüências que as anomalias podem

acarretar é necessário distinguir e identificar alguns termos utilizados para definição de tolerância a falhas. Tais anomalias dentro do contexto de sistemas computacionais (distribuídos ou não) são as seguintes:

                 a) Falha: um comportamento inesperado do sistema em uma situação
                    aparentemente normal. Ocorre no universo físico;
                 b) Erro: manifestação visível da falha, que pode ser percebida pelo usuário
                    ou desenvolvedor do sistema, sem permitir a localização da falha que o
                    ocasionou. “Um ‘erro’ é aquela parte do estado do sistema que é
                    responsável por induzir a uma falha subseqüente.” (JALOTE, 1994 apud
                    LAPRIE, 1985;LAPRIE, 1992, p.6) Um erro acontece no universo lógico.
                    Com a ocorrência de um erro novas falhas podem ser geradas;
                 c) Defeito: causado pelo erro, onde o sistema fornece respostas ou reações
                    incorretas e inesperadas. O defeito é a manifestação perceptível pelo
                    usuário quando uma falha ocorre. “Um ‘defeito’ do sistema ocorre quando
                    o comportamento do sistema se desvia do que é requerido em suas
                    especificações.” (JALOTE, 1994 apud ANDERSON, 1981, p.6)
                 Por exemplo, suponha que em um dado momento uma posição de memória

retorne o valor 1 quando deveria retornar o valor 0. Devido a uma falha no dispositivo de memória, um erro ocorreu (valor 1 ao invés de 0), desse modo o resultado final apresentado ao usuário é incorreto (defeito).

                 Segundo (JALOTE, 1994) um erro é uma propriedade integrante do sistema,

então este pode ser observado e avaliado, ao contrário de uma falha, que não pode ser facilmente observada por não ser uma propriedade do sistema, a menos que sejam utilizadas ferramentas que registrem os eventos que ocorreram durante algum processo. Um defeito pode ser observado somente se o erro que o causou também está sendo observado.

                 “Em geral, quando algo vai contra ao que atribuímos é um defeito...”

(JALOTE, 1994, p.6) Embora isso ocorra, um erro pode não ser gerado durante o período de

                                                                                        4

observação, deixando a impressão que o sistema encontra-se em um estado estável. O caminho inverso torna-se verdadeiro, já que após a detecção de um erro, conclui-se que o sistema encontra-se em um estado de falha.

                 Segundo (JALOTE, 1994) falhas podem ser de duas espécies: transientes e

permanentes.

                 Falhas transientes são aquelas que após um determinado tempo se

desfazem, enquanto que falhas permanentes são aquelas que deixam o sistema em estado de falha por um longo ou indefinido período de tempo.

                 As falhas transientes acontecem devido a algum mau funcionamento de um

componente ou módulo do sistema e que com o decorrer do tempo retorna a sua operação normal. Esse tipo de acontecimento pode causar erros e defeitos durante a sua existência, que também podem ocorrer por um curto período de tempo. Segundo (JALOTE, 1994), se uma falha transiente raramente ocorre e os danos causados pela mesma podem ser retificados, então esse tipo de detecção não é necessariamente requerido. No entanto, se uma falha dessa categoria ocorre de maneira freqüente, algum mecanismo de detecção de erros é, então desejável, embora isso seja difícil e caro. Detecção de erros será discutida adiante na seção 2.3.1.

                 Pode ser considerada uma falha permanente aquela que pode causar erros ou

defeitos por um (longo) período de tempo, sendo considerada pelas muitas técnicas existentes para a construção/manutenção de tolerância a falhas tipos de falhas de caráter duradouro, ou seja, que não se desfazem com o decorrer do tempo.

                 Segundo (JALOTE, 1994 apud LAPRIE, 1992) uma outra categorização das

falhas pode ser em relação a fase em que foram introduzidas ao sistema. O fato de ser introduzida ao sistema significa que a referida falha não foi identificada em dado momento do projeto ao qual está sendo referenciada, e onde teoricamente seria a melhor etapa para que tal detecção/correção fosse realizada. Esse tipo de acontecimento se deva, talvez a própria capacidade humana de verificar as possibilidades de ocorrência de um evento sobre determinado fato. Essas falhas podem, então, ser falhas de projeto ou falhas operacionais. As falhas de projeto “...são aquelas que surgem durante o projeto do sistema ou durante modificações do sistema.” (JALOTE, 1994, p.7) Falhas operacionais “...são aquelas que surgem durante o tempo de vida do sistema e são causadas devido a razões físicas.” (JALOTE, 1994, p.7) Geralmente, falhas de projeto são mais trabalhosas de serem tratadas do

                                                                                     5

que as falhas operacionais, devido a estas estarem inseridas dentro do contexto do próprio sistema, enquanto que falhas operacionais ocorrem sob influência de agentes externos.