ORGANIZAÇÃO SETE DE SETEMBRO DE CULTURA E ENSINO
LTDA
FACULDADE SETE DE SETEMBRO – FASETE
CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO
Jamilson Ramalho Dantas
Cluster de Alta Disponibilidade com Arquitetura HeartBeat, um
Projeto Linux-HA para Software Livres
Paulo Afonso – BA
Dez./ 2009
I
Jamilson Ramalho Dantas
Cluster de Alta Disponibilidade com Arquitetura HeartBeat, um
Projeto Linux-HA para Software Livres
Monografia apresentada ao curso de Graduação
em Sistemas de Informação da Faculdade Sete de
Setembro – FASETE, como pré-requisito para a
obtenção do título de Bacharel.
Orientador Prof. Antonio Henrique Pereira de
Souza.
Paulo Afonso – BA
Dez./ 2009
II
FACULDADE SETE DE SETEMBRO – FASETE.
CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO
Cluster de Alta Disponibilidade com Arquitetura HeartBeat, um Projeto
Linux-HA para Software Livres
Monografia apresentada ao curso de Graduação
em Sistemas de Informação da Faculdade Sete de
Setembro – FASETE. Sob a orientação do Prof.
Antonio Henrique Pereira de Souza.
BANCA EXAMINADORA
_______________________________________________
Prof. Antonio Henrique Pereira de Souza, Especialista (Orientador).
_______________________________________________
Profa. Jalyana Mota de Moura, Especialista.
_______________________________________________
Prof. Fabiano Amorim Vaz, Mestrando.
Paulo Afonso – BA
Dez./ 2009
III
Dedico este trabalho primeiramente a Deus que
sem ele não seria possível a minha existência e
muito menos a conclusão desse trabalho,
posteriormente a todos que fazem a instituição
Sete de Setembro, em especial ao Colégio Sete de
Setembro que foi o propulsor dessa minha
conquista, e sem a oportunidade que tive não seria
possível dar passos longos, como este, em minha
vida, e não deixando de dedicar esse trabalho,
também, a minha família que esteve ao meu lado
sempre, em especial minha namorada, Renata, que
me ajudou bastante.
IV
AGRADECIMENTOS
Agradeço a Deus por me dar força e coragem e nunca me abandonar, fazendo com que a
conclusão desse trabalho se tornasse mais um desafio vencido em minha vida.
Aos meus pais, Cícera Dantas e Oscar Dantas que sempre acreditaram em mim e me deram
forças para continuar na luta, bem como meus irmãos, Josmarina, Osman, Jackeline, Osmar e
Josmarino que me apoiaram em momentos difíceis fazendo com que não desistisse dos meus
sonhos.
Agradeço ainda a minha “menina” que esteve e sempre vai estar ao meu lado compreendendo
quando estive ausente em momentos em que ela mais precisava. Em especial a minha futura
sogra no qual tenho grande admiração e não esquecendo do meu futuro sogro no qual procuro
ajudar sempre.
Aos colegas de trabalho, Ricardo Moreira, Ricardinho (EMO), Gildo, Edmilson, Dennis e
Denise por me apoiar, não esquecendo de meu chefe Carlos André (big boss maior), por
fornecer as ferramentas necessárias para elaboração do laboratório de teste além do apoio e
incentivo no trabalho proposto.
Agradeço também aos meus colegas de classe por estarem sempre comigo em especial a Erick
Barros, Aislan Correia, Jaime Batista, Filipe, Edson, Jalyson, Dany, Fernanda, Denise e
Danilo.
Ao meu orientador Antonio Henrique, por aceitar ser meu orientador e estar sempre presente
na hora que precisar.
A FASETE pela Bolsa de estudos concedida durante todo o curso, e em especial ao Colégio
Sete de Setembro por me acolher e dispor de uma vaga para prestação de meus serviços
acreditando em meu potencial a ponto de me colocar na lista de funcionários efetivados neste
ano.
E por fim aos que não lembrei e me ajudaram na conquista de mais um trabalho realizado.
V
DANTAS, Jamilson Ramalho. Cluster de Alta Disponibilidade com Arquitetura
HeartBeat, um Projeto Linux-HA para Software Livres. 2009. 66f. Monografia.
(Bacharelado em Sistemas de Informação). Faculdade Sete de Setembro – FASETE, Paulo
Afonso-BA.
É inevitável a ocorrência de defeitos ou problemas com equipamentos de informática,
principalmente quando se trata de computadores, onde falhas em software, componentes
queimados e até mesmo manutenções planejadas prejudicam a disponibilidade de informações
da página Web, o que pode gerar a insatisfação dos clientes e até mesmo prejudicar os
empreendimentos. Assim, foram desenvolvidas as tecnologias de Alta Disponibilidade para
corrigir problemas, deixando os sistemas disponíveis o maior tempo possível. Porém, a
maioria dessas soluções é considerada de alto custo, tornando-se, muitas vezes, inviáveis para
pequenas empresas. Como alternativa, para realização deste trabalho foi utilizado o heartbeat
um projeto Linux-ha que dispõe do serviço a baixo custo podendo ser implementado em
organizações de qualquer porte. A proposta da pesquisa foi montar um laboratório que
permitiu a instalação e testes de um sistema Web de Alta Disponibilidade onde foi construída
uma arquitetura com dois nós mostrando, de forma prática, como uma empresa pode adotar
essa medida. Para elaboração de um conhecimento necessário à efetivação da experiência em
laboratório foi realizada uma pesquisa bibliográfica, que permitiu a compreensão dos
conceitos, procedimentos técnicos e resultados publicados por outros estudiosos. O estudo
revelou que esse tipo de tecnologia tem possibilita manter por maior tempo possível a
disponibilidade dos serviços prestado, porém para que seja alcançado resultados mais
satisfatórios existem ferramentas que acoplados ao heartbeat permite maior confiabilidade e
segurança das informações.
Palavras Chave: Alta Disponibilidade. Heartbeat. Servidor Web. Projeto LINUX-HA
VI
DANTAS, Jamilson Ramalho. High Availability Cluster Architecture with HeartBeat, a
Linux-HA Project to Free Software. 2009. 66p. Monograph. (Course of Bachelor of
Information Systems), Faculdade Sete de Setembro - FASETE, Paulo Afonso-BA.
It is inevitable the occurrence of faults and problems with computer equipment, especially
when it comes to computers, where flaws in software, components and even burned planned
maintenance affect the availability of the website, which can lead to customer dissatisfaction
and even undermine the developments. Thus, we developed the high-availability technologies
to correct problems, leaving the systems available as long as possible. However, most of these
solutions is considered expensive, making it often impractical for small businesses.
Alternatively, the study's heartbeat was used a Linux-ha project which provides the service at
low cost and can be implemented in organizations of any size. The research proposal was to
set up a laboratory that allowed the installation and testing of a web system where highavailability architecture was built with two nodes showing a practical way how a company
can adopt this measure. For an elaboration of knowledge necessary to accomplish the
experiment in laboratory was conducted a literature search, which led to the understanding of
the concepts, technical procedures and results published by other scholars. The study revealed
that this type of technology is possible to maintain for as long as possible the availability of
services provided, but in order to reach more satisfactory results are tools that bound to the
heartbeat allows greater reliability and security of information.
Keywords: High Availability. Heartbeat. Web Server. Project Linux-HA
VII
LISTA DE FIGURAS
Figura 1: Disponibilidade Básica ................................................................................... 22
Figura 2: Esquema lógico com o uso de DRBD ............................................................. 23
Figura 3: Disponibilidade Continua ............................................................................... 24
Figura 4: Modelo de 3 universos: falha, erro e defeito ................................................... 25
Figura 5: Ponto crítico de falha ...................................................................................... 29
Figura 6: Computador convencional .............................................................................. 29
Figura 7: Computador convencional .............................................................................. 30
Figura 8: Rede com dois nós .......................................................................................... 30
Figura 9: Example of an HAGEO cluster ....................................................................... 36
Figura 10: IP Address Takeover (IPAT) ......................................................................... 41
Figura 11: Configuração Assimétrica ............................................................................. 43
Figura 12: Configuração Simétrica................................................................................. 43
Figura 13: Instalação heartbeat ...................................................................................... 44
Figura 14: Esquema de Diretorias .................................................................................. 45
Figura 15: Instalação apache versão 2 ............................................................................ 45
Figura 16: Arquivo Authkeys .......................................................................................... 47
Figura 17: Permissão de acesso authkeys ....................................................................... 48
Figura 18: Configuração Hosts ....................................................................................... 49
VIII
LISTA DE TABELAS
Tabela 1: O significado dos noves .................................................................................. 20
Tabela 2: O custo médio de falha no sistema ................................................................. 20
Tabela 3: Número máximo de nós que têm suporte em um cluster ............................... 34
Tabela 4: Arquivo ha.cf .................................................................................................. 46
Tabela 5: Configuração geral arquivo ha.cf ................................................................... 46
Tabela 6: Configuração authkeys ................................................................................... 48
Tabela 7: Configuração Haresources ............................................................................. 48
IX
SUMÁRIO
LISTA DE FIGURAS.................................................................................................. VII
LISTA DE TABELAS ................................................................................................VIII
CAPÍTULO I
1.
1.1.
1.2.
1.3.
1.4.
1.4.1.
1.4.2.
1.5.
1.6.
CONSIDERAÇÕES INICIAIS ........................................................................ 12
CONTEXTUALIZAÇÃO ................................................................................ 12
JUSTIFICATIVA ............................................................................................. 14
PROBLEMA DE PESQUISA .......................................................................... 14
OBJETIVOS ..................................................................................................... 15
Objetivo Geral ................................................................................................ 15
Objetivo Específico ......................................................................................... 15
METODOLOGIA DE PESQUISA .................................................................. 15
ESTRUTURA DO TRABALHO ..................................................................... 16
CAPÍTULO II
2.
2.1.
2.2.
2.2.1.
2.2.2.
2.2.3.
2.3.
2.3.1.
2.3.1.1.
2.3.2.
2.3.3.
2.3.4.
2.3.5.
2.4.
2.5.
DISPONIBILIDADE ....................................................................................... 19
INTRODUÇÃO................................................................................................ 19
CLASSIFICAÇÃO DA DISPONIBILIDADE ................................................ 21
Disponibilidade Básica ................................................................................... 21
Alta Disponibilidade ....................................................................................... 22
Disponibilidade Contínua .............................................................................. 23
CLUSTER ........................................................................................................ 24
Confiabilidade em Cluster.............................................................................. 25
Falha, erro e defeito .......................................................................................... 25
Escalabilidade ................................................................................................. 26
Cluster de Alta Disponibilidade ..................................................................... 26
Cluster de Balanceamento de Cargas............................................................ 27
Cluster de Computação .................................................................................. 28
PONTO CRÍTICO DE FALHA ....................................................................... 28
PROJETO LINUX-HA .................................................................................... 31
CAPÍTULO III
3.
3.1.
3.1.1.
3.1.2.
3.1.3.
3.1.4.
3.2.
3.2.1.
DESENVOLVIMENTOS PARA CLUSTER DE ALTA DISPONIBILIDADE33
CLUSTERS COMERCIAIS ............................................................................ 33
Microsoft Windows Server 2008 R2 ............................................................. 33
IBM: High Availability Cluster Multi-Processing (Hacmp) ...................... 34
IBM: High Availability Geographic Clustering Software (Hageo) ........... 35
HP Serviceguard ............................................................................................. 36
OPEN SOURCES............................................................................................. 37
Common Address Redundancy Protocol (Carp) ......................................... 37
X
3.2.2.
3.2.3.
3.2.4.
Distributed Replicated Block Device (Drbd) ............................................... 37
Linux Virtual Server (LVS) ............................................................................ 38
Heartbeat.......................................................................................................... 38
CAPÍTULO IV
4.
4.1.
4.1.1.
4.1.2.
4.2.
4.3.
4.3.1.
4.3.2.
4.3.3.
4.3.4.
HEARTBEAT .................................................................................................... 40
ARQUITETURA HEARTBEAT ..................................................................... 40
Ip Address Takeover (Ipat).............................................................................. 40
Mac Address Takeover .................................................................................... 42
INSTALAÇÃO ................................................................................................ 44
CONFIGURAÇÃO .......................................................................................... 45
Configuração Ha.Cf........................................................................................ 45
Configuração Authkeys .................................................................................. 47
Configuração Haresources ............................................................................. 48
Configuração Hosts ........................................................................................ 49
CAPÍTULO V
5.
5.1.
5.2.
5.2.1.
5.2.1.1.
5.2.2.
5.2.3.
5.2.4.
CENÁRIO DE TESTE ..................................................................................... 51
CONFIGURAÇÃO DE REDE ........................................................................ 51
INICIANDO O SERVIÇO HEARTBEAT ...................................................... 52
Primeiro Teste: Parando O Heartbeat .......................................................... 55
Reiniciando o Heartbeat. ................................................................................. 56
Segundo Teste: Parando O Servidor Web Apache ...................................... 57
Terceiro Teste: Retirando o Cabo Que Alimenta o Heartbeat ................... 58
Quarto Teste: Desligando o Servidor Principal........................................... 60
CAPÍTULO VI
6.
CONSIDERAÇÕES FINAIS ........................................................................... 62
REFERÊNCIAS ........................................................................................................... 64
CAPÍTULO I
CONSIDERAÇÕES INICIAIS
12
1.
CONSIDERAÇÕES INICIAIS
Este capítulo apresenta o planejamento inicial da pesquisa com a contextualização sobre o
tema e a proposta de delimitação do estudo, seguido da justificativa para a sua escolha. Em
seguida, a definição do problema, metodologia utilizada, o objetivo geral e os específicos e
por fim, a estrutura da monografia.
1.1.
CONTEXTUALIZAÇÃO
A base para o sucesso de uma empresa está diretamente ligada ao meio tecnológico, que
necessita de componentes específicos para auxiliar em seu crescimento, como servidores e
unidades de armazenamentos de dados. Relacionados a isso estão às pessoas, sejam gestores,
colaboradores ou clientes que fazem uso destes elementos.
Os equipamentos tecnológicos são constituídos de componentes eletrônicos que podem ser
afetados em seu sistema por falhas de artefatos agregados, sendo os servidores os que mais
sofrem com esse tipo de problema, onde, fontes, capacitores, placas, entre outros, são
corrigidos individualmente em caso de falhas.
A necessidade da utilização de serviços e/ou componentes eletrônicos possibilita a ocorrência
de falhas, afetando sua disponibilidade e acesso às informações por usuários da rede.
Quando há a ocorrência de algum tipo de falha é necessário que o administrador de redes
direcione todo o serviço para um servidor secundário para que não ocorra a indisponibilidade
por tempo prolongado, neste sentido é utilizado sistemas em “nós” no que se refere a cluster1
de Alta Disponibilidade com arquitetura em HeartBeat2, que será responsável por monitorar e
recuperar clusters que apresentaram falhas. Porém, para esse tipo de solução existem diversos
software que promovem Alta Disponibilidade, no entanto com um custo elevado. Este
trabalho vem mostra que é possível a implementação desta tecnologia com um custo
relativamente baixo.
1
Um cluster, ou conjunto de computadores, é formado por vários computadores em conjunto onde os mesmos
têm as mesmas informações inscritas em todos os computadores envolvidos.
2
Ver Capítulo IV
13
Segundo Ferreira e Santos (2005), a Alta Disponibilidade – (High Availability - HA) visa
manter o máximo de disponibilidade possível dos serviços prestados, recorrendo a hardware e
software especifico para o efeito, tornando assim possível o contorno de alguns tipos de
falhas, desde as relacionadas com o armazenamento até a elaboração de procedimentos em
casos de falhas mais graves. Ike (2009), por sua vez diz que HA é um sistema tolerante a
qualquer tipo de falha, seja ela de equipamentos, energia elétrica, software, entre outras. Esse
tipo de sistema busca diminuir ou eliminar os pontos únicos de falhas, podendo utilizar
redundância de nós de ativos de rede (switches, roteadores, etc), servidores de aplicação,
servidores de banco de dados, geradores de energia e outros.
Uma das formas de se ter um sistema em HA consiste em agrupar vários servidores
independentes em um único sistema cluster, contudo, um sistema HA será capaz de detectar,
recuperar e realizar o mascaramento de falhas, visando manter o funcionamento dos serviços
durante o máximo de tempo possível, inclusive no processo de manutenções programadas.
Entretanto, essas soluções tem custos associados, por isso, os sistemas OpenSource tem
crescido consideravelmente, trabalhando e investindo cada vez mais para solucionar
problemas. Uma das soluções mais usadas é o projeto Linux-HA (High-Availability Linux),
que desenvolve o heartbeat, um daemon3 responsável por monitorar o status dos servidores
do cluster e permitir que o segundo servidor assuma as funções do primeiro em caso de pane.
(FERREIRA E SANTOS, 2005.)
Pretende-se, com esse projeto, mostrar as funcionalidades de um sistema HA utilizando o
heartbeat, expondo desde sua instalação e configuração até sua efetividade de funcionamento.
Testar-se-á a usabilidade do sistema utilizando software livres, revelando como grandes
empresas podem reduzir gastos, aumentar lucros e conseqüentemente ter perdas menores com
sistemas disponíveis.
3
Um programa geralmente associado a sistemas UNIX que executa funções utilitárias (de faxina ou
manutenção) sem ser requisitado, ou até, sem que o usuário perceba. (http://o-que-querdizer.blogspot.com/2005/04/daemon.html)
14
1.2.
JUSTIFICATIVA
Alta Disponibilidade ou HA é fundamental em grandes empresas como Microsoft, IBM,
Bancos, porém tais empresas dispõem de recursos que possibilitam a construção de sistemas
com tamanha tecnologia, mas, é notável que os sistemas open sources evoluíram
consideravelmente nos últimos anos a ponto de fornecerem tecnologias de Alta
Disponibilidade fazendo com que pequenas empresas possam implementar e dispor seus
serviços por mais tempo.
Com o custo elevado de soluções prioritárias em cluster de Alta Disponibilidade empresas de
todo o mundo abrem as portas para soluções open source, desta forma pequenas empresas
poderão adotar esse tipo de solução, trazendo estabilidade e por conseqüência confiança de
seus usuários.
Este projeto ganha relevância por propor um estudo de como servidores em cluster podem
trabalhar simultaneamente propondo Alta Disponibilidade de seus recursos e com o menor
custo possível demonstrando possíveis falhas que poderão ocasionar a indisponibilidade do
sistema e artefatos que contornam o problema.
1.3.
PROBLEMA DE PESQUISA
A partir da realização de pesquisas pôde-se perceber que um sistema de Alta Disponibilidade
é de grande importância para as empresas, pois contribui em seu crescimento e fortalece-as no
mercado competitivo.
Diante deste propósito é perceptível que não basta apenas à implantação de um sistema de
Alta Disponibilidade, é preciso acompanhá-lo visto que, do contrário, o mesmo pode gerar
alguns problemas para as instituições.
Desta forma, este estudo visa responder aos seguintes questionamentos:
15
Há a possibilidade de um administrador de redes saber quando um dos hosts4 apresentou falha
ou ficou off-line? Caso o servidor Web venha a falhar como proceder para que o servidor
secundário assuma os comandos já que o heartbeat continuará em atividade? Caso os
servidores não recebam mensagens de heatbeat um do outro, qual o servidor que entrará em
atividade já que os dois declararão que os nós estão mortos e cada um iniciará seus serviços?
1.4.
OBJETIVOS
1.4.1. Objetivo Geral
Analisar a qualidade da utilização de um sistema de Alta Disponibilidade com a arquitetura
HeartBeat, a partir da construção de um laboratório de testes a fim de realizar procedimentos,
como instalação, configuração e funcionalidade do mesmo.
1.4.2. Objetivo Específico
• Demonstrar os artifícios que podem ser adotados e combinados para aumentar a
disponibilidade de um sistema;
• Revelar as possíveis falhas e as possíveis soluções para um sistema de Alta
Disponibilidade;
• Mostrar desde a instalação e configuração até o funcionamento do sistema, fazendo
uma análise laboratorial de um ambiente de Alta Disponibilidade com arquitetura
heartbeat.
1.5.
METODOLOGIA DE PESQUISA
Este trabalho foi dividido em três etapas, a primeira consistiu em levantar material necessário
para estudos bibliográficos, que abordam assuntos relacionados ao tema, através de fontes de
revistas, livros, internet ou publicações relacionadas.
Nesse sentido foi realizado a implementação da pesquisa em laboratório, onde está o
embasamento de todo o trabalho, segundo Lakatos e Marconi (2001, p.155), a pesquisa é um
4
Computador ligado a rede.
16
procedimento reflexivo sistemático, controlado e crítico, que permite descobrir novos fatos ou
dados, relações ou leis, em qualquer campo do conhecimento, mas partindo para a idéia de
que a pesquisa será realizada em laboratório temos segundo Santana (2004) uma pesquisa de
laboratório tem como objetivo reproduzir e observar certos fenômenos e em ambientes
artificialmente construídos.
Na segunda etapa foi construído o laboratório de pesquisa, onde foi feito todo o estudo prático
do projeto, testando e avaliando o trabalho do HeartBeat, se o mesmo seria eficaz no trabalho
que lhe é proposto.
A terceira etapa é a junção das anteriores, onde é pretendido demonstrar a instalação,
configuração e funcionamento de um sistema altamente disponível revelando falhas e
possíveis soluções para um sistema cem por cento disponível, ou o mais próximo disso, que
sugestiona em Cluster de Alta Disponibilidade com arquitetura HeartBeat um projeto Linux HA para software livres.
Foi feita uma demonstração do funcionamento de um cluster de HA em um ambiente Linux,
bem como demonstração de seu funcionamento observando se um servidor secundário pode
assumir as atividades do servidor principal em um curto período de tempo com a ocorrência
de algum tipo de falha.
1.6.
ESTRUTURA DO TRABALHO
A monografia está organizada de modo a propor ao leitor fácil entendimento e compreensão
do assunto a ser discutido, proporcionando prazer ao ler e também ao praticar os
conhecimentos passados aqui.
Sendo assim, os capítulos serão organizados como se segue:
Capítulo 01 – Considerações Iniciais: Apresenta a introdução ao tema escolhido, Cluster de
Alta Disponibilidade com Arquitetura HeartBeat um projeto Linux-HA para software Livres,
seguindo da justificativa. Em seguida a definição do problema, metodologia utilizada,
objetivo geral e os específicos.
17
Capítulo 02 – Disponibilidade: Será abordado o conceito de disponibilidade e disponibilidade
continua, bem como suas diferenças, para posteriormente falar do que vem a ser o projeto
Linux-HA.
Capítulo 03 – Desenvolvimentos para Cluster de Alta Disponibilidade: Aqui será abordada
algumas soluções para desenvolvimento de cluster de Alta Disponibilidade, soluções essas
que podem ser comerciais ou OpenSource.
Capítulo 04 – HeartBeat: Será apresentado seu conceito e passo a passo da instalação e
configuração do serviço HeartBeat.
Capítulo 05 – Cenário de teste: Será apresentando a estrutura do laboratório de testes,
configurações de maquinas utilizadas e simulações de possíveis falhas que poderão ocorrer
em uma empresa.
Capítulo 06 – Considerações finais: Será descrito uma conclusão do trabalho realizado e
sugestões para trabalhos futuros.
Ao final deste trabalho poderá ser vista as Referências contendo todo o material pesquisado
no decorrer da elaboração deste projeto.
CAPÍTULO II
DISPONIBILIDADE
19
2.
DISPONIBILIDADE
Este capítulo tem como objetivo apresentar a importância de um sistema disponível bem
como sua classificação e confiabilidade, abordando assim, as principais diferenças entre falha,
erro e defeito, componentes que afetam diretamente o sistema.
2.1.
INTRODUÇÃO
A importância de um sistema disponível é notável em grande parte das tarefas executadas
pelas pessoas em seu dia a dia, que dispõe de sistemas informáticos diversas atividades, como
compra de um bilhete de passagem, compras em lojas virtuais e até mesmo em agências
bancárias. A disponibilidade torna-se tão importante a ponto de fazer com que a empresa
tenha prosperidade em seus negócios ou torne-se o fracasso chegando à falência.
De acordo com o dicionário Aurélio (2001, p. 260), disponibilidade significa “qualidade ou
estado de disponível”. Devido a essa necessidade de obtenção de recursos na hora exigida, o
ser humano exige cada vez mais de um sistema que venha atendê-lo a qualquer hora.
A disponibilidade de um serviço é calculada na percentagem que quantifica a probabilidade
de encontrar o serviço operacional em determinado momento (FERREIRA e SANTOS,
2005).
Com isso pode-se calcular o tempo em que um servidor estará disponível (uptime), ou o
tempo em que o mesmo estará indisponível (downtime) (FERREIRA e SANTOS, 2005). Para
o cálculo da percentagem é utilizada a formula descrita abaixo, sendo que a mesma pode ser
aplicada para as três classes de disponibilidades existentes (ver tópico 2.2).
Disponibilidade = (Unidade de tempo total - downtime) / Unidade de tempo total
Toma-se como exemplo um servidor Web que está operando em um período de uma semana
considerando que o mesmo apresentou problemas ficando indisponível (downtime) durante 1
hora.
Unidade de tempo total = 1 semana (168 horas)
Downtime = 1 hora
20
Disponibilidade = (168 - 1) / 168 = 99,4047 %
Alcançar 100% de disponibilidade é uma tarefa quase que impossível, pois os componentes
de hardware possuem vida útil necessitando de trocas de tempos em tempos e
conseqüentemente exigindo que o administrador de redes pare as tarefas mesmo que sejam
por períodos curtos de tempo.
Na tabela 1, o site da Microsoft TechNet, traduz o significado dos noves em um sistema
disponível, enquanto mais nove tiver, menor será o downtime (Microsoft TechNet, 2009).
%
100
99,999 (5 noves)
99,99 (4 noves)
99,9 (3 noves)
99 ( 2 noves)
90,0 - 98,9 (1 nove)
Tabela 1: O significado dos noves
Downtime (por ano)
Nenhum downtime
Menos de 5,26 min.
De 5,26 a 52 min.
De 52 min. a 8 horas e 45 min.
De 8 horas e 45 min. a 87 horas e 56 min
87 horas e 56 min a 875 horas 54 min
Fonte: Microsoft TechNet
Para Barraza (2002), o custo de inatividade pode ser incapacitante ou mesmo fatal para uma
organização (ver Tabela 2).
APLICAÇÃO
INDÚSTRIA
Correntistas
Finanças
Vendas de cartão de Finanças
crédito
Pay-Per-View
Mídia
Utilidades Domésticas
Varejo
Catálogo de Vendas
Varejo
Reservas Aéreas
Transporte
Tabela 2: O custo médio de falha no sistema
CUSTO POR HORA ($)
$ 6,45 milhão
$ 2,60 milhão
$ 150.000
$ 150.000
$ 150.000
$ 150.000
Fonte: Barraza (2002, p. 2)
A disponibilidade ainda pode ser melhorada com investimentos de hardware e software,
passando assim para outra classe de disponibilidade, caso o administrador não aplique
corretamente os investimentos necessários pode acarretar em perdas ainda maiores
(BARRAZA, 2002).
21
A disponibilidade de um sistema pode ser dividida, ainda, em três classes, disponibilidade
básica, Alta Disponibilidade e disponibilidade contínua.
2.2.
CLASSIFICAÇÃO DA DISPONIBILIDADE
Como se pode ver, a disponibilidade pode ser calculada de acordo com o tempo em que o
computador esteve disponível e indisponível, com o resultado desse calculo pode-se
classificar a disponibilidade em três classes, disponibilidade básica, Alta Disponibilidade e
disponibilidade contínua.
2.2.1. Disponibilidade Básica
Esse tipo de disponibilidade pode ser encontrado em todos os computadores, desde os mais
simples até os mais avançados, sem a necessidade do uso de software ou hardware específico
para o efeito. Assim sendo, um sistema de disponibilidade básica será capaz de atender ao
cliente no tempo necessário, respondendo as expectativas do mesmo.
Com um sistema desse nível pode-se realizar tarefas desde as mais simples até as mais
complexas ressaltando, então, que se ocorrer falhas ou manutenções planeadas o sistema
ficará indisponível.
Segundo Guindani (2008), um sistema com disponibilidade básica pode chegar de 99% a
99,9% de disponibilidade. Dizendo ele que, em um ano de operação a máquina pode ficar
indisponível por um período de 9 horas a quatro dias.
Um exemplo de um sistema de disponibilidade básica pode ser visto na figura 1.
22
Figura 1: Disponibilidade Básica
Fonte: NAKAI (2008)
Este tipo de sistema traz um único servidor como provedor de serviço, quando há a
sobrecarga ou uma falha em um de seus componentes esse servidor para o serviço ficando
indisponível por algum tempo, só retomando as atividades normais depois de concertado.
2.2.2. Alta Disponibilidade
Esse tipo de disponibilidade só é possível por intermédio de dispositivos de software ou
hardware que sejam capazes de detectar e recuperar hosts que obtiveram falhas. Segundo
Guindani (2008), nessa classe, as máquinas normalmente apresentam disponibilidade na faixa
de 99,99% a 99,999%, podendo ficar indisponíveis por período de pouco mais de cinco
minutos até uma hora em um ano de operação.
Um típico cenário de Alta Disponibilidade pode ser visto na figura 2, onde se tenta passar ao
usuário final o mais próximo possível de 100% da entrega do serviço.
23
Figura 2: Esquema lógico com o uso de DRBD
Fonte: Dr. White Hat, 2009
É notável a quantidade de servidores web, verifica-se que os mesmos trabalharam em
conjunto para que se tenha um balanceamento de cargas, os dois últimos farão a troca de
serviço caso venham a falhar deixando assim o sistema com o máximo de disponibilidade
possível.
2.2.3. Disponibilidade Contínua
Esse tipo de disponibilidade visa manter um sistema totalmente disponível, sem nenhuma
falha, o que implica em 24 horas por dia e sete dias por semana. Segundo Ferreira e Santos
(2005, p. 10), “a disponibilidade contínua (continuous availability) combina as características
da operação contínua e da Alta Disponibilidade representando um estado ideal”.
Esse tipo de cenário pode ser visto na figura 3, onde o sistema tenta dispor ao usuário final
100% da entrega do serviço.
24
Figura 3: Disponibilidade Continua
Fonte: QUORUM
Para prover continuidade na transferência de dados pode ser criado data centers5 em pontos
estratégicos, no exemplo de disponibilidade contínua, quando o data Center principal falhar o
segundo assume os serviços fazendo com que os dados trafeguem ininterruptamente.
2.3.
CLUSTER
Também conhecidos como nós ou nodos, os clusters segundo Ferreira e Santos (2005, p. 5),
“é um conjunto de computadores independentes, designados de nós, que colaboram entre si
para atingir um determinado objetivo comum, criando assim um sistema mais robusto”.
Para isso, os computadores devem ser ligados com conexões de alta velocidade para fornecer
serviços de alto desempenho podendo trazer grandes vantagens, como, confiabilidade e
escalabilidade, além de possuir três tipos de Cluster que serão descritos em seguida.
5
Centro de Processamento de dados agrupam diversos computadores para o processamento de dados de uma
empresa.
25
2.3.1. Confiabilidade em Cluster
A confiabilidade de qualquer sistema leva ao questionamento se o mesmo será capaz de
oferecer o serviço prometido na hora que se deseja essa confiabilidade, somente sendo
permitida caso algum dos fatores abaixo não aconteça.
2.3.1.1.
Falha, erro e defeito
Um Servidor Web que está em disponibilidade por um período longo de tempo pode ser
afetado de diversas maneiras, através de falhas, erros ou defeitos, porém esses três tipos de
distorções têm significados distintos.
Segundo Weber (2001, p. 4), “[...] falhas estão associadas ao universo físico, erros ao
universo da informação e defeitos ao universo do usuário”. Observa-se que na figura 4 a falha
pode ocasionar um erro e, por conseguinte, gerar um defeito, mas, nem sempre isso ocorre,
justamente por que uma linha de código do programa que está com falha pode ser que nunca
seja executada ou um erro nunca levar a um estado de defeito, pois a informação, talvez, não
seja usada (WEBER, 2001).
Figura 4: Modelo de 3 universos: falha, erro e defeito
Fonte: Weber (2001, p. 4)
Toma-se como exemplo uma fonte de alimentação de um computador, diz-se então, que há
uma oscilação constante de energia nesta fonte, com a ocorrência dessa falha pode ser gerado
um erro de troca de bit na máquina inesperadamente, por conseqüência seria gerado um
defeito podendo travar o equipamento ou até mesmo, queima do material, deixando assim, em
indisponibilidade (ANDERSON, 1981).
26
2.3.2. Escalabilidade
A escalabilidade em Cluster permite que novos nós sejam adicionados na rede fazendo com
que cresça consideravelmente. Com isso, cada host pode ser identificado por seu estado de
atividade, ativo ou em espera (standby), quando o servidor está ativo subentende-se que este é
o host principal, e quando esta em espera ou standby, diz-se então, que o mesmo é o
secundário.
Segundo Ferreira e Santos (2005, p. 12), “a junção de nós, periféricos e interligações de rede
não devem interferir na disponibilidade dos serviços prestados”. Por conseqüência, a
escalabilidade deve trazer ao sistema confiabilidade.
2.3.3. Cluster de Alta Disponibilidade
Esse tipo de Cluster tem como finalidade prover, por maior tempo possível, a disponibilidade
do sistema, podendo alcançar, o mais próximo possível, de 100% de disponibilidade. Com
esse sistema implementado é comum encontrarmos, apenas dois nós configurados, já que é o
requisito mínimo para oferecer redundância dos dados (FERREIRA e SANTOS, 2005).
A implementação de um sistema desse porte permite que seja contornada possíveis falhas do
sistema, que podem ser de hardware ou software. Quando um dos nós ativos chegarem a
falhar o outro assume as responsabilidades no instante do ocorrido.
Um sistema desses é freqüentemente utilizado em bancos de dados, compartilhamento de
arquivos em rede e em aplicativos de negócios, como sites de comercio eletrônico. Segundo
Reis, et. al (p. 3), “nesta classe as máquinas tipicamente apresentam disponibilidade na
faixa de 99,99% a 99,999%”.
Esse tipo de cluster apresenta duas características importantes, failover6 cluster e cluster de
escalabilidade.
Segundo Reis et. al (p. 3), “um cluster de failover em caso de falha o sistema age
automaticamente sem que seja preciso a intervenção humana”. Toma-se como exemplo
6
Modo operacional do sistema onde as funções de um componente do sistema ficam como secundário até
quando o componente primário obtiver falha.
27
um nó de cluster com apenas duas máquinas dispondo de serviços de Alta Disponibilidade em
um servidor Web, onde uma delas é a principal, se o servidor principal vier a falhar e ficar
inoperante por alguns minutos a máquina secundária entra em operação, automaticamente,
sem que o usuário perceba.
O outro ponto importante é a escalabilidade que segundo Ferreira e Santos (2005, p. 12), diz
que, “através da junção de nós, periféricos e interligações de rede não devem interferir na
disponibilidade dos serviços prestados”. Ou seja, através da adição ou substituição de recursos
de máquinas existentes, o serviço não é comprometido, não havendo a necessidade de
paragens ou interrupções (ver tópico 2.3.2).
2.3.4. Cluster de Balanceamento de Cargas
O cluster para balanceamento de cargas é usado quando existem várias requisições para um
único serviço. Segundo Arthur (2009, p. 2), “um bom cluster de balanceamento de carga deve
ter a capacidade de receber os pedidos de requisição de serviço de vários clientes e distribuir
(balancear a carga de trabalho) tais serviços às máquinas que constituem o cluster de forma
que nenhuma máquina fique sobrecarregada e/ou ociosa”.
Para que se tenha um bom balanceamento de cargas são utilizados alguns métodos de controle
de carga, os dois métodos principais são.
Algoritmo de Round-robin, esse tipo de algoritmo é responsável por distribuir a carga
igualmente para cada servidor, independentemente do numero de conexões atuais. Esse
algoritmo é adequado quando os servidores do cluster tiverem a capacidade de processamento
igual, caso contrário, os servidores podem receber pedidos de mais do que podem processar
enquanto outros estão usando parte do processamento (MICROSOFT, 2009a).
Equilibradores de cargas, esse tipo de controle permite que seja controlado equipamentos de
hardware de modo que não seja utilizado demasiadamente. Segundo Mora (2008, p. 15), “esse
método deve monitorar a utilização do processador, memória, rede e disco de um conjunto de
servidores, e ser capaz de analisar estes dados a fim de não deixar um servidor mais
carregado, enquanto há servidores sendo subutilizados”.
28
2.3.5. Cluster de Computação
O tipo de cluster de computação mais conhecido é o cluster de Beowulf. O primeiro cluster
Beowulf surgiu nos laboratórios do Center of Excellence in Space Data Information Sciences
(CEDIS – Centro de Excelência em Ciência da Informação e em Dados Espaciais), uma
divisão da NASA, que tinha como objetivo construir uma organização paralela ás seguintes
características: baixo custo, composto por equipamentos disponíveis a qualquer usuário e que
oferece alto poder computacional (OLIVEIRA, 2004).
Também conhecido como cluster de alto desempenho é do tipo que divide os processos em
inúmeros pedaços para que os mesmos possam ser executados e trabalhados em nós
separados. Segundo Brandão (2009, p. 3), “o Cluster de Alto Desempenho é projetado para
fornecer maior poder de computação para a solução de um problema e tradicionalmente está
relacionado com aplicações científicas, de simulação ou de manipulação de imagens”.
Esse tipo de cluster trabalha com um dos computadores do nó como mestre, onde o mesmo
será responsável por dividir e compartilhar as tarefas para os demais nodos da rede.
2.4.
PONTO CRÍTICO DE FALHA
Do inglês single points of failure (SPOF), os pontos críticos de falha são componentes da
rede, ou mesmo do computador, que por alguma razão venha a falhar, deixando o sistema
inoperante, mesmo que seja por períodos curtos de tempo.
Ao projetar um sistema de HA alguns aspectos devem ser analisados, como equipamentos e
software envolvidos, ambiente onde instalar e poder de processamento e armazenamento de
dados (FERREIRA E SANTOS, 2005, P. 14). Com isso, a inexistência, ou a quebra, de um
desses
componentes
pode
acarretar
na
falta
da
disponibilidade
do
sistema
e
conseqüentemente, gerar transtornos ainda maiores para a empresa provocando perdas
financeiras.
Esses pontos de falhas são inúmeros, pode-se ter conhecimento da quantidade de pontos
existentes na empresa, ou não.
29
SPOF
Figura 5: Ponto crítico de falha
Fonte: Dantas, 2009
A figura 5 ilustra um ponto critico de falha aplicada em uma rede, onde todo o tráfico da
informação é transmitido a partir de um roteador para os outros componentes da rede, caso o
roteador venha a falhar todos ficarão sem acesso à informação.
Ferreira e Santos (2005), discutem alguns componentes cruciais para ocorrência de falhas
mais também propõe soluções com o intuito de prover maior disponibilidade possível no
sistema.
Ferreira e Santos (2005) explicam que de acordo com a figura 6, um computador simples que
contém um disco rígido, componentes de hardware e algumas aplicações também sofrem com
falhas indesejadas afetando, principalmente os componentes citados anteriormente.
Figura 6: Computador convencional
Fonte: FERREIRA e SANTOS (2005, p. 16)
30
Mais, para minimizar ou até mesmo sanar esses pontos críticos, basta apenas à duplicação dos
componentes do sistema, disco rígido, hardware e aplicações podendo ser construída em uma
nova máquina que poderá trabalhar em conjunto com a máquina anterior.
Figura 7: Computador convencional
Fonte: FERREIRA e SANTOS (2005, p. 17)
Agora que se têm duas máquinas idênticas, como fazer para que as mesmas se enxerguem?
Isso é o mais simples, basta apenas à criação de uma rede entre os dois nós (Figura 8).
Figura 8: Rede com dois nós
Fonte: Adaptado de FERREIRA e SANTOS (2005, p. 17)
É notável que com apenas isso a rede não venha a ter cem por cento de disponibilidade,
sanado todos os pontos críticos de falha, apenas complicaria mais a vida de qualquer
administrador de redes, pois com a criação da rede foram acoplados novos equipamentos o
que gerou mais pontos de falhas, cabo de rede e switch são os principais, pois a inexistência
de um deles pode acarretar sérios problemas.
31
Observa-se que a partir do momento que é adicionado novos recursos e equipamentos mais
pontos críticos são acoplados em seu interior, sendo necessário, assim, uma pessoa especifica
para lidar com situações criticas, a ponto de analisar e sanar todos os pontos encontrados.
2.5.
PROJETO LINUX-HA
Com início em 1997 o projeto Linux-HA começou com uma lista de discussão criada por
Harald Milz para discutir como se pode criar um conjunto de capacidades de Alta
Disponibilidade para Linux (ROBERTSON, 2009). Com o projeto ainda em discussão o autor
decidiu fazer uma das peças do software que realizaria a função de verificação entre máquinas
através de pulsos o que deu o nome ao software de HeartBeat ou batimentos cardíacos.
Desde então o interesse por ele cresce continuamente, com o intuito de prover Alta
Disponibilidade de seus serviços, o projeto distribuí o software como parte integrante dos
sistemas Linux além de rodar em alguns outros sistemas, como FreeBSD, Solaris e OpenBSD
e mesmo no MacOS / X (LINUX-HA, 2009a).
Com o objetivo firmado em prover uma solução de (clustering) de Alta Disponibilidade que
promova confiabilidade e robustez, disponibilidade e continuidade na prestação de serviços
como traz o site do próprio projeto (LINUX-HA, 2009a), o projeto ainda conta com algumas
outras ferramentas que trabalhando em conjunto para prover maior sustentabilidade ao
sistema, como é perceptível a Alta Disponibilidade, não baseia-se apenas no projeto Linux-ha
podendo ter soluções que disponham de custos elevados nos quais serão descritas no próximo
capítulo.
CAPÍTULO III
DESENVOLVIMENTOS PARA CLUSTER
DE ALTA DISPONIBILIDADE
33
3.
DESENVOLVIMENTOS
DISPONIBILIDADE
PARA
CLUSTER
DE
ALTA
Aqui será abordada, as possíveis soluções para desenvolvimento de cluster de Alta
Disponibilidade, podendo ser comerciais ou OpenSource.
3.1.
CLUSTERS COMERCIAIS
Serão abordadas aqui, algumas soluções em cluster para construir um sistema de Alta
Disponibilidade, sendo que estas possuem algum custo associado.
3.1.1. Microsoft Windows Server 2008 R2
Foi escolhido o Windows Server 2008 por ser o software mais atual para este fim, ressaltando
ainda que este software não possui tantas diferenças com a versão 2003 Server.
O Windows Server 2008 R2 traz duas edições que disponibilizam serviços de segurança e
disponibilidade: Windows Server 2008 Enterprise, Windows Server 2008 Datacenter.
Windows Server 2008 Enterprise R2 é um ótimo sistema operacional para servidores que
executam aplicativos como o networking, messaging, inventário, bancos de dados e sistemas
de atendimento ao cliente, além de conter todas as funcionalidades do Windows Server 2008
R2 Standard Plus (MICROSOFT, 2009b).
Windows Server 2008 R2 Datacenter é otimizado para virtualização em grande escala em
sistemas de servidor de pequeno a grande porte e para cargas de trabalho que exigem os
maiores níveis de escalabilidade, confiabilidade e disponibilidade para suportar grandes
aplicações de missão crítica (MICROSOFT, 2009c).
O Windows, por sua vez, dá suporte a determinado número de servidores em cluster, essa
quantidade máxima em sistemas Windows pode ser vista na tabela 3.
34
Sistema Operacional (SO)
Número de
nós
Armazenamento
Windows NT 4.0 Enterprise Edition
Windows 2000 Advanced Server
Windows 2000 Datacenter Server
Windows Server 2003, Enterprise Edition
1-2
SCSI
Windows Server 2003, Enterprise x 64 Edition
Windows Server 2003, Datacenter Edition
Windows Server 2003, Datacenter x 64 Edition
Windows NT 4.0 Enterprise Edition
1-2
Fibre Channel
Windows 2000 Advanced Server
Windows 2000 Datacenter Server
1-4
Fibre Channel
Windows Server 2003, Enterprise Edition
Windows Server 2003, Enterprise x 64 Edition
Windows Server 2003, Enterprise Edition para
sistemas baseados no Itanium
Windows Server 2003, Datacenter Edition
Windows Server 2003, Datacenter x 64 Edition
Windows Server 2003, Datacenter Edition para
Fibra Canal, iSCSI ou
1-8
sistemas baseados no Itanium
SAS
Windows Server 2008, Enterprise Edition
Windows Server 2008, Enterprise Edition para
sistemas baseados no Itanium
Windows Server 2008, Datacenter Edition
Windows Server 2008, Datacenter Edition para
sistemas baseados no Itanium
Windows Server 2008, Enterprise x 64 Edition
Fibra Canal, iSCSI ou
1-16
Windows Server 2008, Datacenter x 64 Edition
SAS
Tabela 3: Número máximo de nós que têm suporte em um cluster
Fonte: SUPPORT, 2009
Os clusters em sistemas Windows vêm como parte integrante do sistema, sem nenhum custo
adicional, bastando apenas à compra do software apropriado, instalação e configuração do
mesmo.
3.1.2. IBM: High Availability Cluster Multi-Processing (Hacmp)
Solução proprietária da IBM que disponibiliza formas de monitoração e de detecção de falhas
de aplicações. Faz a manutenção de cópias de segurança armazenadas nos recursos de backup
de uma organização (FERREIRA e SANTOS, 2005, p. 22).
Esse sistema é construído para plataformas IBM system Power, linhas de produtos da IBM,
rodando em IBM Unix AIX e Linux, podendo ser executado em até 32 computadores em nós
35
em sistema AIX da IBM e em até oito nós em sistemas Linux, esse tipo de sistema pode ser
configurado para responder a centenas de eventos que venham a ocorrer, até mesmo
problemas que não agravam suficientemente o sistema ocasionando interrupções de operações
do sistema.
Por se tratar de uma solução de Alta Disponibilidade o HACMP, também, trabalha com
detecção e recuperação de hosts que apresentaram falhas, fazendo com que a disponibilidade
do sistema não seja afetada (IBM, 2009).
Embora esteja preparado para instalação e configuração em sistemas Linux, o software de
Alta Disponibilidade que a IBM oferece só pode atuar mediante a compra de licenças.
3.1.3. IBM: High Availability Geographic Clustering Software (Hageo)
HAGEO é um complemento do HACMP com o objetivo de proporcionar a Alta
Disponibilidade entre cluster que possam estar localizados, geograficamente, em locais
separados, sem limite de distância. (IBM, 2009).
Enquanto que o HACMP oferece disponibilidade em um ambiente de computação dentro do
local de trabalho o HAGEO oferece Alta Disponibilidade em casos mais críticos, como no
acontecimento de explosão ou algum outro tipo de desastre ocorrido na própria empresa,
permitindo que os dados fiquem seguros em outro local longe dali.
Essa solução oferece alguns benefícios:
• Capacidade de desempenho de rede aprimorada com a adição da opção de transporte
TCP.
• Suporte 64-bit kernel
• Escolhas adicionais na ordem de gravação de dados espelhados
• Maior integração com IBM High Availability Cluster de Multiprocessamento
(HACMP) para AIX ® clustering software (IBM, 2009, p.1)
O exemplo de um sistema em HAGEO pode ser visto na figura 9.
36
Figura 9: Example of an HAGEO cluster
Fonte: IBM, 2003
No exemplo acima os nós estão em diferentes locais geográficos, um em Boston e outro em
Hartford. Observe que os nós de cada local são definidos como pertencentes a um dos dois
locais, o nó Boston e o nó Hartford construídos com sistema HACMP. Os dois locais juntos
formam um cluster HAGEO único. O site é um componente de cluster HACMP. (IBM, 2003).
3.1.4. HP Serviceguard
Solução proprietária da HP onde os serviços aplicacionais são agrupados em packages7 para
que, no caso de falha de um recurso, o controle da package possa ser transferido
automaticamente para outro nó dentro do cluster. Desta forma, os serviços continuam
disponíveis com o mínimo de downtime (FERREIRA e SANTOS, 2005, p. 22).
Feitos para sistemas HP-UX e sistemas Linux, a HP Service Guard fornece Alta
Disponibilidade com promessa de restaurar rapidamente serviços após a ocorrência de falhas,
seja ela de hardware ou software (HP, 2009).
7
Um pacote de software é o software empacotado num formato de arquivo para ser instalado por um sistema
gestor de pacotes ou por um instalador autônomo. (http://pt.wikipedia.org/wiki/Package)
37
Esse tipo de sistema utiliza o protocolo TCP/IP para comunicação entre nós ativos de rede,
caso um dos nós não receba a mensagem transmitida inicia-se uma nova montagem do
sistema. Esse tipo de sistema pode ser utilizado em cluster de até 16 nós, tanto para sistemas
HP, quanto para sistemas Linux.
3.2.
OPEN SOURCES
Nesta seção será abordada algumas soluções de código aberto para implementação de um
sistema de Alta Disponibilidade.
3.2.1. Common Address Redundancy Protocol (Carp)
Segundo Botelho (2006, p. 27), Common Address Redundancy Protocol, CARP, é o
Protocolo de Redundância de Endereço Comum. Seu objetivo principal é permitir que
múltiplos hosts no mesmo segmento de rede compartilhem o mesmo endereço IP.
Com o propósito de dispor Alta Disponibilidade, esse protocolo pode também efetuar o
balanceamento de cargas se for configurado para tal efeito, mais, para isso, o mesmo só será
capaz de realizar um dos serviços.
As
vantagens
desse
protocolo
são:
baixo
overhead8,
mensagens
criptográficas,
interoperatividade entre sistemas operativos diferentes e o fato de não necessitar de nenhuma
ligação secundária entre os hosts redundantes (FERREIRA e SANTOS, 2005, p. 25).
3.2.2. Distributed Replicated Block Device (Drbd)
Segundo a Sun Microsystems (2009, p. 8), o DRBD é um dispositivo de bloco do kernel9
Linux de código aberto que potencializa a replicação síncrona para conseguir uma exibição
consistente de dados entre dois sistemas, normalmente um sistema ativo e um passivo.
Podendo trabalhar em conjunto com o HeartBeat, o DRBD faz com que todas as informações
inscritas no servidor primário sejam copiadas, sem nenhuma alteração, para o servidor
secundário.
8
processamento ou armazenamento em excesso.
9
É o núcleo do sistema, o Kernel é responsável por realizar a comunicação entre software e hardware.
38
Para prover Alta Disponibilidade em um sistema Web, é necessário que todos os dados que
estejam no servidor secundário sejam idênticos aos contidos no servidor primário, sendo
assim, havendo a necessidade da troca de servidores os dados retornados ao usuário final
sejam dados sem alterações, para isso existe o DRBD como forma de prover replicação dos
dados sem alterá-los.
3.2.3. Linux Virtual Server (LVS)
Linux Virtual Server (LVS) é um arranjo (cluster) de servidores Linux que provê serviços de
Alta Disponibilidade e alto desempenho. Essas características são obtidas com o uso das
técnicas de failover, redundância com substituição automática, e load balancing, distribuição
da demanda para vários servidores (PEREIRA JÚNIOR, 2008.)
Com essa ferramenta é possível criar um sistema avançado de balanceamento de cargas
fornecendo, assim, para usuários Linux, maior disponibilidade e desempenho de seus
serviços, dando-lhes ainda altos níveis de confiança e usabilidade (CENTOS, 2008)
3.2.4. Heartbeat
O HeartBeat significa batimentos cardíacos, trabalha com pulsos de máquina para máquina,
enviando pacotes do servidor principal para o servidor secundário, e vice versa, verificando se
os mesmos estão ativos, caso o servidor principal venha a ficar indisponível o secundário
assume seu lugar na rede.
Ele pode fazer comunicação via serial enviando heartbeats de um nodo para outro, ou por
interfaces de rede (OPENS, 2009, p. 1). Com duas máquinas no nó da rede pode-se fazer uma
ligação serial ligando-as através de um cabo crossover10, ou, até mesmo, utilizando de
equipamentos de rede, como Hub, Switch, roteadores, entre outros.
Será descrito de uma forma mais aprofundada sobre essa arquitetura no próximo capítulo.
10
Tipo de cabo de rede, que permite a ligação de dois computadores pelas suas placas de rede sem a
necessidade do uso de componentes de rede (Hub ou Switch).
CAPÍTULO IV
HEARTBEAT
40
4.
HEARTBEAT
Neste capítulo será abordado o conceito de HeartBeat, bem como, instalação e configuração
do mesmo dispondo assim da Alta Disponibilidade para usuários do sistema. Este capítulo é
bem prático necessitando assim de um bom entendimento sobre Linux e dos capítulos
anteriores.
4.1.
ARQUITETURA HEARTBEAT
Será utilizado neste projeto, o heartbeat, com o propósito de identificar e recuperar um
computador secundário, que esteja trabalhando no nó do cluster quando o primário obtiver
falha ficando inativo, proporcionando assim, um serviço de Alta Disponibilidade em um
servidor Web.
Segundo Haas (2009), o heartbeat é um subsistema de pulsação para prover Alta
Disponibilidade em ambiente Linux. Trabalhando com a execução de scripts na sua
inicialização, verificando assim, quais as máquinas estarão disponíveis.
Ele trabalhará com a execução de pings11 entre as máquinas do nó do cluster, verificando
assim quando uma delas estiver inoperante, declarando a mesma como um nó morto.
Praticamente existem duas versões principais do heartbeat, a versão 1.x com ela é possível a
configuração de apenas dois nós em cluster, e a versão 2.x que permite a configuração de até
16 nós em cluster (SAMBA, 2007).
Contudo o heartbeat trabalhará através de processos de takeover (aquisição de recursos),
podendo ser implementado em uma das duas estratégias de aquisição discutidas a seguir.
4.1.1. Ip Address Takeover (Ipat)
Com esse tipo de recurso é possível contornar possíveis falhas do sistema, protegendo assim,
de erros de instalação de placas de redes ou até mesmo da quebra do hardware de rede. Para
esse mecanismo é necessária a instalação de duas placas de rede para cada endereço IP, as
11
Comando para testar a conectividade entre computadores.
41
mesmas devem estar configuradas para a mesma rede física, uma das placas deve ficar sempre
ativa enquanto o outro fica em espera.
No momento em que o sistema detecta um problema com a placa principal, imediatamente o
NIC de espera é ativado. Como resultado clientes não notam qualquer tempo de inatividade
no servidor (ORACLE, 2004).
Para sistemas Linux, é possível a alocação de dois IPs em uma mesma placa de rede,
chamados aqui de endereços virtuais, como mostra a figura 10.
Cliente
Gateway 192.168.0.20
Cliente
Gateway 192.168.0.20
Eth0 – 192.168.0.5
Eth0:1 – 192.168.0.20
Eth0 – 192.168.0.10
Eth0 – 192.168.0.5
Eth0 – 192.168.0.10
Eth0:1 – 192.168.0.20
Servidor
Primário
Servidor em
espera
Servidor
Primário
Servidor em
espera
Figura 10: IP Address Takeover (IPAT)
Fonte: Dantas, 2009
Note que na figura 10 tem-se, no servidor principal dois endereços, Eth0 192.168.0.5 IP fixo
que identifica o servidor primário e o endereço Eth0 192.168.0.10 que identifica o servidor
em espera, alocado a mesma placa de rede tem-se um IP virtual Eth0:1 192.168.0.20 que está
rodando em ambas as máquinas sendo que no servidor em espera o IP virtual só ficará ativo
caso o servidor primário não esteja mais operando. Na ocorrência de algum tipo de falha com
o servidor principal o servidor em espera ativa sua interface virtual disponibilizando o serviço
para o usuário final sem que o mesmo perceba a troca do equipamento.
42
Como afirma Ferreira e Santos (2005, p. 28), “a disponibilidade dos servidores pode ser
controlada com o utilitário fake12 que permite efetuar o método IPAT colocando operacional
uma interface adicional (física ou virtual).”
4.1.2. Mac Address Takeover
O endereço MAC é quem controla o acesso de cada máquina na rede sendo que, o mesmo
funciona como identificador dos dispositivos de rede não existindo endereços MACs iguais.
Segundo Ferreira e Santos (2005, p. 28), quando ocorre um IPAT, as máquinas dos
utilizadores são confrontadas com um endereço MAC diferente para o mesmo endereço IP.
Todas as implementações IP devem atualizar os caches13 do ARP14 caso ocorra um pedido
ARP para o qual já exista um endereço IP associado.
Esse método consiste na troca do processamento do servidor principal para o servidor
secundário permitindo que as informações trafeguem sem interrupções no caso de failover do
servidor principal. Para isso pode-se destacar dois tipos de configurações a serem realizadas,
configuração simétrica e assimétrica (Ferreira e Santos, 2005).
12
Do português Falso, permite assumir o endereço IP da outra máquina na rede local.
13
Dispositivo para acesso rápido, ao efetuar o primeiro acesso a um dispositivo o cache guarda as informações
para que possam ser utilizadas posteriormente e com mais rapidez em seu acesso.
14
Address Resolution Protocol ARP é um protocolo utilizado para mapear endereços IP para endereços MAC
(http://pt.tech-faq.com/arp.shtml&prev=hp&rurl=translate.google.com)
43
Figura 11: Configuração Assimétrica
Fonte: Dantas, 2009.
Na configuração assimétrica o cliente solicita a execução de uma aplicação no servidor
principal, caso o mesmo venha a ficar inoperante o servidor secundário será capaz de realizar
as mesmas tarefas do servidor principal ficando a espera apenas para a realização dessa tarefa.
Figura 12: Configuração Simétrica
Fonte: Dantas, 2009.
44
Neste tipo de configuração cada servidor é responsável por executar uma aplicação diferente,
sendo utilizado como um balanceador de cargas, no caso do servidor principal ficar
inoperante o servidor secundário será capaz de executar as duas aplicações ficando com toda a
carga do processamento (Figura 12).
Para cada uma das estratégias citadas acima existe um tempo de resposta para aquisição de
serviços, como por exemplo, por endereço MAC é quase que instantâneo mais sua
implementação é, de certa forma, desorganizada, em aquisição por endereço IP é um pouco
mais lento do que por endereço MAC tornando sua implementação menos viável (LINUXHA, 2009b).
4.2.
INSTALAÇÃO
O processo de instalação do heartbeat mostrados aqui deverá ser executado em todos os nós
do cluster. Será utilizado o heartbeat versão 2.1.4, por ser a versão mais atual do programa. O
software utilizado pode ser baixado direto do site do projeto, Linux-ha.org, ou através de
comandos digitados no terminal de comandos Linux, para que isso ocorra é necessário que o
computador esteja conectado a internet, figura 13.
Figura 13: Instalação heartbeat
Fonte: Dantas, 2009.
A partir do comando utilizado na figura 13 é possível baixar e instalar, automaticamente, a
versão mais recente do programa.
Com a instalação foram criados ficheiros e alguns diretórios que podem ser vistos na figura
14. (Ferreira e Santos, 2005).
45
Figura 14: Esquema de Diretorias
Fonte: Ferreira e Santos, 2005, p. 30.
Como é um sistema de Alta Disponibilidade em um servidor web é necessária a instalação do
servidor para prover a disponibilidade das páginas, como se trata de um projeto utilizando
apenas software livres foi escolhido o apache como servidor. A instalação pode ser executada,
também, direto do terminal Linux especificando a versão a ser instalada (Figura 15).
Figura 15: Instalação apache versão 2
Fonte: Dantas, 2009.
4.3.
CONFIGURAÇÃO
O processo de configuração resume-se apenas a três arquivos, ha.cf, authkeys, haresources,
que deverão, após a instalação, ser copiados para a pasta do sistema denominada de ha.d
localizada em /etc/ha.d. Um quarto arquivo será configurado posteriormente o arquivo hosts,
para definir quais as máquinas participarão do cluster.
4.3.1. Configuração Ha.Cf
Esse arquivo é o mais importante para a configuração do heartbeat, é nele que será descrito a
quantidade de nós utilizados no cluster, tipo de comunicação entre máquinas além de conter
arquivos adicionais que poderão ser habilitados. É importante saber que algumas das opções
descritas abaixo são realizadas em todas as versões tornando assim opções globais, e a
ordenação da mesma no arquivo é de grande importância para sua execução.
46
As opções globais podem ser vista na tabela 4.
Linha de configuração
Debugfile
Logfile
Logfacility
Udpport
Descrição
Utilizado para guardar mensagens de
depuração
Guarda mensagens de logs do cluster
Responsável por enviar mensagens de logs
para o syslog
Porta utilizada para comunicação do heartbeat
Tabela 4: Arquivo ha.cf
Fonte: Linux-HA, 2009c.
O ficheiro ha.cf, assim como todos os outros, vem com todas as linhas de configuração prédefinidas, bastando apenas apagar o símbolo à esquerda (‘#’), que indica que a linha está
comentada. Ao iniciar o heartbeat a linha que contém este símbolo não será executada, as
linhas configuradas deverão ser as seguintes. (tabela 5).
Linha de Configuração
Debugfile
/var/log/ha-debug
Logfile
/var/log/ha-log
Logfacility
local0
Keepalive
2
Deadtime
10
Warntime
10
Initdead
60
Udpport
694
Bcast
eth0
auto_failback
on/off
Node
Node
server01
server02
#CRM
on/off
Descrição
Tabela 4
Tabela 4
Tabela 4
Define o intervalo de tempo entre heartbeat,
aqui definido com 2 segundos
Declara um nó como morto em 10 segundos
sem respostas
Tempo em que será incluído nos arquivos
de log que um nó se encontra inacessível
Tempo de inicialização para declarar o
primeiro deadtime, o site do projeto sugere
que esse tempo seja, no mínimo, 2 x o
deadtime.
Tabela 4
Indica qual a placa de rede enviará
mensagens broadcast.
Em caso de falha, o nó principal ao
retornar as atividades pare o servidor
secundário e volte a trabalhar.
Nome do host 1 do cluster
Nome do host 2 do cluster
Usar arquivo cib.xml, responsável por
mostrar quais máquinas e recursos estão
trabalhando naquele instante.
Tabela 5: Configuração geral arquivo ha.cf
Fonte: Dantas, 2009.
Observe que o ultimo arquivo configurado, CRM, está comentado não sendo utilizado no
projeto, para as versões 1.X do heartbeat esse arquivo pode ser usado sem problemas, a partir
47
da
versão
2.X
é
necessário
configurar
o
arquivo
cib.xml
localizado
em
/var/lib/heartbeat/crm/cib.xml, para que o mesmo utilize o maior números de nós possíveis no
cluster, como a implementação utiliza apenas 2 nós não será necessária sua configuração
sendo desnecessária sua utilização.
4.3.2. Configuração Authkeys
Segundo Ferreira e Santos (2005, p. 32), esse arquivo contém informação utilizada pelo
heartbeat na autenticação dos membros do cluster. É composto por duas linhas: uma que
define qual o número da chave a ser utilizado para assinalar os pacotes de saída e outra que
define o método de autenticação (forma como esses pacotes vão ser assinalados).
Figura 16: Arquivo Authkeys
Fonte: Dantas, 2009.
A primeira linha traz o método que será utilizado para a autenticação dos dados, auth 1, 2 ou
3. Existem três métodos de autenticação, CRC (Cyclic Redundancy Check), MD5 (Message
Digest 5) e SHA1 (Secure Hash Algorithm 1), (Ferreira e Santos, 2005, p. 33).
O método Cyclic Redundancy Check – CRC é um método inseguro, não requer chave de
autenticação, destinado a redes seguras. O Message Digest 5 – MD5 esse método requer uma
chave de autenticação sendo utilizado quando se que economizar o máximo em uso de CPU.
O Secure Hash Algorithm 1 – SHA1 é o método mais seguro desde que você não se preocupe
com o uso de CPU (LINUX-HA, 2009d).
Como o projeto destina-se apenas a demonstração do funcionamento de um sistema de Alta
Disponibilidade não há a necessidade de autenticar o serviço do heartbeat de modo a não
utilizar os processos de uso de CPU ao máximo, por isso foi utilizado o método descrito a
seguir. (Tabela 6).
48
Linha
Descrição
auth 1
Método de autenticação 1
1 crc
Não requer chave de autenticação
Tabela 6: Configuração authkeys
Fonte: Dantas, 2009.
Para finalizar, esse arquivo deve ter as permissões de acesso alteradas para que somente o
administrador possa acessá-las, para isso execute o seguinte comando descrito na figura 17.
Figura 17: Permissão de acesso authkeys
Fonte: Dantas, 2009.
4.3.3. Configuração Haresources
Um arquivo, também, bastante importante, é nele que será descritos os recursos a serem
utilizados no cluster. Neste caso será utilizado o apache e um IP virtual usado para acesso a
página web.
Este ficheiro permite agrupar vários recursos num único grupo (ResourceGroup). Todos os
recursos do grupo são iniciados em conjunto num único servidor. O heartbeat inicia sempre
os recursos da esquerda para a direita no grupo e termina-os na ordem inversa, direita para a
esquerda (FERREIRA E SANTOS, 2005, p. 32).
A tabela 7 mostra a configuração realizada neste arquivo.
Linha
Descrição
Server01 IPaddr::192.168.0.20/24/eth1:1 apache2 Recursos controlados pelo heartbeat.
Tabela 7: Configuração Haresources
Fonte: Dantas, 2009.
Na configuração do haresources, ao inicializar o serviço ele terá o server01 como servidor
principal, para isso é necessário que o auto_failback esteja como on (tabela 5), em seguida ele
inicia um IP virtual 192.168.0.20 com máscara de subrede 255.255.255.0 criando uma
interface virtual, como já existe um IP na interface eht1 será criada outra com interface eth1:1,
na mesma faixa de IP e mesma interface de rede, e por último será iniciado o servidor web
49
apache. Quando o heartbeat parar os serviços será parado da direita para esquerda, parando
primeiro o apache e depois liberando a interface virtual.
Todos os arquivos do heartbeat configurados aqui deverão ser iguais em todas as máquinas
participantes do cluster, podendo ser copiados ou mesmos repetindo os procedimentos
anteriormente citados.
4.3.4. Configuração Hosts
Esse arquivo não pertence às configurações do heartbeat mais é necessária a sua configuração
para que o servidor identifique os nós participantes (figura 18).
Figura 18: Configuração Hosts
Fonte: Dantas, 2009.
É descrito aqui os servidores que trabalharão em conjunto no cluster, informações mais
detalhadas sobre os endereços IPs e virtual serão descritas no próximo capítulo.
CAPÍTULO V
CENÁRIO DE TESTE
51
5.
CENÁRIO DE TESTE
O cenário de teste foi construído no laboratório do Colégio Sete de Setembro no qual foram
disponibilizadas três máquinas onde as configurações das mesmas serão descrita a seguir
(tabela 8).
Máquina 1 – Server01
Máquina 2 – Server02
Processador – Core 2 Duo
Processador – Core 2 Duo
HD – 80Gb
HD – 80Gb
Memória – 1Gb DDR
Memória – 1Gb DDR
2 Placas de Rede – 10/100
2 Placas de Rede – 10/100
MBps
MBps
Tabela 8 – Máquinas utilizadas no cenário de teste
Máquina 3 - Cliente
Processador – Core 2 Duo
HD – 80Gb
Memória – 1Gb DDR
1 Placa de Rede – 10/100
MBps
Fonte: Dantas, 2009.
Nas duas máquinas utilizadas como servidor foram instalados os seguintes software, ubuntu
9.0415 como sistema operacional, apache 2.216 como servidor Web e o heartbeat descrito no
capítulo anterior.
Na máquina cliente, utilizada apenas para testes, foi usado o sistema operacional Windows
juntamente a ele o internet Explorer para acesso a página Web.
5.1.
CONFIGURAÇÃO DE REDE
Cada servidor dispõe de duas placas de rede sendo uma para uso independente do heartbeat
ficando assim em outra faixa de IP, e a outra para distribuição de IPs na rede podendo ser
acessado por todos, figura 19.
15
Download http://www.ubuntu.com/GetUbuntu/download
16
Pode ser baixado e instalado como descrito no capítulo anterior ou encontrado no site www.apache.org
52
IP: 192.168.0.5
IP: 10.1.1.2
IP: 192.168.0.20
IP: 192.168.0.X
IP: 10.1.1.3
IP: 192.168.0.10
Figura 19 – Implementação cenário de teste
Fonte: Dantas, 2009.
A figura 19 demonstra o cenário proposto, onde por meio de um cabo Crossover17, conectado
a uma das placas de rede, realizará a comunicação entre os servidores, IP 10.1.1.X, o
heartbeat trabalhará independente, a outra placa de rede fará a distribuição de outra faixa de
IP sendo distribuída por meio de um switch IP 192.168.0.X, o cliente fará os acessos através
do IP virtual configurado, fazendo com que imaginemos que o IP 192.168.0.20 é uma
máquina servidora qualquer da rede e que só existe ela.
5.2.
INICIANDO O SERVIÇO HEARTBEAT
Depois de instalado e configurado (capítulo 4), é chegada a hora de executar os testes para
isso é necessário que os serviços configurados no haresources (tabela 7) não sejam iniciados
na inicialização do sistema, o IP virtual levantado não pode ser configurado em nenhum outro
lugar e o apache tem que ficar parado, para isso é necessária a execução do seguinte
comando.
#update-rc.d heartbeat defaults
#update-rc.d -f apache2 remove
Isso fará com que o heartbeat seja inicializado junto com o sistema e o servidor apache fique
parado sendo controlado pelo heartbeat.
17
Cabo de Rede do tipo cruzado feita para ligação entre duas máquinas.
53
O server01 deverá mostrar em sua interface de rede a configuração do IP virtual enquanto que
o server02 mostrará, apenas, seu IP real, figura 20, e figura 21.
Figura 20 – Server01 IP real e Virtual
Fonte: Dantas, 2009.
54
Figura 21 – Server02 IP real
Fonte: Dantas, 2009.
Isso indica que tudo está funcionando bem, já com o IP virtual levantado, será digitado no
browser na máquina cliente o endereço do IP virtual configurado e observa-se a seguinte
mensagem na tela (figura 22).
Figura 22 – Acessando o servidor 1
Fonte: Dantas, 2009.
Isso indica que o server01 é o servidor principal e está operando corretamente, o próximo
passo será a realização de testes para verificar o quanto o sistema ficará disponível.
55
5.2.1. Primeiro Teste: Parando O Heartbeat
Com os serviços iniciados nos servidores (server01 e server02) foi feita a parada do heartbeat
no servidor primário (server01) executando o seguinte comando.
#sudo /etc/init.d/heartbeat stop
Com isso pressupõe que o server02 inicie seus serviços e assuma o comando da operação
(figura 23).
Figura 23 – Acessando o servidor 2
Fonte: Dantas, 2009.
É importante salientar que a página web de cada servidor foi modificada propositalmente para
facilitar o entendimento e compreender qual dos servidores está operando naquele instante.
O arquivo de debug do servidor 1 mostra o seguinte conteúdo.
Figura 24 – ha-debug servidor 1
Fonte: Dantas, 2009.
As linhas do arquivo dizem que os recursos foram parados, houve tentativa de envio de
pacotes para o servidor 02, mas sem sucesso e por final o heartbeat completou a parada dos
serviços.
56
O arquivo de degug do servidor 2 mostra o seguinte conteúdo.
Figura 25 – ha-debug servidor 2
Fonte: Dantas, 2009.
No servidor 2 mostra que os recursos configurados são inicializados e ao final mostra que o
server01 e a placa de rede eth0 estão “mortos”.
5.2.1.1.
Reiniciando o Heartbeat.
Ao reinicializar o serviço no servidor 1 o heartbeat trabalhou de forma inversa, deixando o
servidor 2 em standby e reativando o servidor 1 (Figura 26).
Figura 26: Start Heartbeat
Fonte: Dantas, 2009.
57
Configurado no ha.cf (Tabela 5) e haresources (Tabela 7) o heartbeat identificará que o
servidor principal é o server01 e que ele deverá voltar às atividades caso volte a operar, e é
justamente o que ocorre, o heartbeat do servidor 1 inicializa seus recursos enquanto que o
servidor 2 voltará para o status standby.
O heartbeat se comportou do jeito que deveria, parando os recursos no servidor principal e
ativando-os no servidor secundário, e vice e versa, fazendo com que a página web opere o
maior tempo possível.
5.2.2. Segundo Teste: Parando O Servidor Web Apache
Como o heartbeat controla todos os serviços é notável que o mesmo se comporte de maneira
satisfatória, mais se apenas o servidor apache for parado como será o comportamento do
heartbeat? Para isso os dois servidores devem estar ativos (heartbeat startados), em seguida
será executado a parada do apache em uma das máquinas, servidor 1 a escolhida, com o
seguinte comando.
#sudo /etc/init.d/apache2 stop
Visto que, o servidor 1 é o que está ativo no momento e o apache não mais funcionará, a
empresa correrá o risco de sofrer complicações com um sistema de Alta Disponibilidade
indisponível.
58
Figura 25 – Indisponibilidade web apache
Fonte: Dantas, 2009.
Em um sistema como esse utilizando apenas o heartbeat para prover Alta Disponibilidade
seria arriscado à implementação do mesmo em uma empresa que contém grande acesso e
tráfego de informações, mais para isso existe programas que podem contornar esse tipo de
falha, como é o caso do MON, software de monitoramento do heartbeat, ele pode ser
configurado para monitorar os recursos configurados no haresources (Tabela 7), e parar o
heartbeat em caso de falhas ocorridas em um dos arquivos configurados, ele ainda pode ser
configurado para mandar e-mails para o administrador avisando dos transtornos.
5.2.3. Terceiro Teste: Retirando o Cabo Que Alimenta o Heartbeat
Neste teste foi realizada a retirada do cabo que alimenta o heartbeat, cabo crossover, de modo
a observar o comportamento dos servidores quando não recebem pacotes heartbeat.
Com isso os serviços de cada servidor são inicializados já que os mesmos não recebem
pacotes heartbeat, o servidor primário traz em sua mensagem de log a inexistência do
servidor secundário juntamente com sua placa de rede (figura 26) enquanto que o servidor
secundário diz o contrário e avisa que o servidor primário é quem está indisponível (figura
27).
59
Figura 26 – Log server01
Fonte: Dantas, 2009.
Figura 27 – Log server02
Fonte: Dantas, 2009.
Com os serviços, em ambas as máquinas, levantados o cliente continuará acessando a página
Web, porém, teremos em uma mesma rede dois computadores com o mesmo endereço IP
levantados, IP: 192.168.0.20, sendo inaceitável para arquitetura de redes gerando conflitos de
IP e provocando a queda da página Web de instante em instante.
Segundo Ferreira e Santos (2005) este tipo de problema denomina-se como a síndrome do
cérebro dividido, onde todos os participantes do cluster não mais recebem mensagens
heartbeat ou de pulsação. Isso ocorre devido a falhas na rede alocadas para desempenhar o
papel de comunicação entre os nós.
Ferreira e Santos (2005, p. 46) ainda trazem possíveis soluções para o problema:
STONITH: Este método permite que o servidor principal envie uma mensagem de shutdown18
para o servidor secundário, para que este liberte os recursos adquiridos indevidamente;
Ligação SLIP: Acrescentar uma ligação série entre os servidores apenas para o envio das
mensagens de heartbeat. Desta forma em caso de falha da ligação ethernet existe uma ligação
em backup para garantir a comunicação entre os servidores;
18
Shutdown em português quer dizer encerramento, conhecida na informática quando desliga-se o
computador abruptamente
60
Broadcast: Admitindo que existe pelo menos duas ligações entre os servidores, a utilização do
modo de comunicação broadcast permite que as mensagens de heartbeat sejam enviadas por
várias ligações e assim, caso uma dessas ligações falhe, estas mensagens não são perdidas.
5.2.4. Quarto Teste: Desligando o Servidor Principal
Tendo em vista que ao desligar o computador principal todos os seus recursos e componentes
também o serão, logo os resultados obtidos é o mesmo da seção 5.2.1 onde o servidor em
standby (server02) assume as responsabilidades deixando o serviço altamente disponível.
CAPÍTULO VI
CONSIDERAÇÕES FINAIS
62
6.
CONSIDERAÇÕES FINAIS
As empresas atuantes no mercado, sejam elas grandes ou pequenas, dispõem de grande
número de clientes, porém as mesmas devem tratá-los de forma preferencial de modo a não
causarem transtornos e aborrecimentos. A Alta Disponibilidade visa eliminar grande parte
desses contratempos provocados por algum tipo de falha ou manutenções planeadas, contudo
quando se faz referência a esse tipo de disponibilidade vem à mente altos custos e gastos
desnecessários, mas, é perceptível a forma com que os sistemas open sources vêm ganhando
cada vez mais mercado.
Com base nesse principio o presente trabalho apresenta uma forma de obter Alta
Disponibilidade a baixo custo mostrando possíveis falhas de um servidor web, as simulações
feitas demonstram que há a possibilidade de empresas aderirem essa solução obtendo
segurança nos dados e confiabilidade da informação.
Pôde-se perceber em um dos testes realizados que ao parar o servidor Web apache a página
ficaria indisponível decepcionando assim, todos que trabalham para dispor ao máximo os
serviços de uma empresa, mas, para contornar esse tipo de falha existe software que acoplado
ao heartbeat provê maior confiabilidade e segurança nas informações como é o caso do
MON, respondendo assim um dos problemas de pesquisa tratado aqui.
Quanto ao outro problema de pesquisa, há a possibilidade de um administrador de redes saber
quando um dos hosts apresentou falha ou ficou off-line? Pode-se perceber que nos arquivos
de logs existentes em cada cluster os administradores podem e devem realizar
acompanhamento dos arquivos a fim de observar e detectar problemas precocemente.
Para concluir essa etapa foi necessário responder mais um problema, que se refere ao modo de
comunicação do heartbeat que é feita através de uma ligação direta por um cabo crosover,
verificando-se que ao desconectar o mesmo os serviços dos computadores pertencentes ao
cluster entram em atividade podendo gerar transtornos nos quais podem ser contornados
como foi visto no capítulo anterior.
Com o objetivo firmado em construir e analisar um sistema de Alta Disponibilidade dispondo
apenas de software livre o projeto gerou pequenas preocupações, haja vista que o trabalho
63
com software nunca utilizados exige esforço e dedicação, porém todo empenho para
construção do laboratório obteve sucesso podendo ser visto nos capítulos anteriores, com isso
todo os objetivos proposto foram alcançados.
Desta forma, pode-se perceber que com as tecnologias trabalhadas a implementação torna-se
viável tanto em pequenas empresas quanto em empresas de grande porte.
A leitura e realização das etapas descritas aqui demonstram a construção de um sistema de
Alta Disponibilidade voltado apenas para detecção e recuperação de um cluster que apresente
falha, para replicação de dados e para tornar o sistema cada vez mais disponível sugere-se
algumas pesquisas, como: Instalação e configuração do DRBD para replicação de dados;
configuração do MON, sistema de monitoramento dos serviços e recursos utilizados no
heartbeat; balanceamento de cargas; e por fim, realizar testes com as ferramentas descritas
para analisar o funcionamento em conjunto com o Heartbeat.
64
REFERÊNCIAS
ANDERSON, T.; LEE, P. A. Fault tolerance – principles and practice. Englewood Cliffs,
Prentice-Hall, 1981.
ARTHUR, Luiz. Cluster de balanceamento de cargas. Disponível em:
<http://www.slideshare.net/luiz_arthur/tpicos-cluster-de-balanceamento-de-carga> Acesso
em: 16 de setembro de 2009.
BARRAZA, Omar. Achieving 99.9998+% Storage Uptime and Availability. Dot Hill
Systems Corp. Janeiro de 2002.
BOTELHO, Marco Antônio Faria. Alta Disponibilidade Em Firewall Utilizando Pfsync E
Carp Sobre Freebsd. Lavras – Minas Gerais – Brasil, 2006.
BRANDÃO, William Losina. Computação em cluster: modelos, middlewares,
arquiteturas e aplicações. Porto Alegre – RS – Brasil, 2009.
CENTOS. Linux Virtual Server. 2008. Disponível em:
<http://www.centos.org/docs/5/pdf/Virtual_Server_Administration.pdf> Acesso em: 06 de
outubro de 2009.
Dr. White Hat. Alta Disponibilidade com Baixo custo. Disponivel em:
<http://drwhitehat.wordpress.com/2008/11/07/alta-disponibilidade-com-baixo-custo/> Acesso
em: 13 de setembro de 2009.
FERREIRA, Aurélio B. de Holanda. Mini Aurélio: o minidicionário da Língua
Portuguesa. 5 ed. Rio de Janeiro: Nova Fronteira, 2001.
FERREIRA, Felipa Silva, SANTOS, Nélia Catarina Gaspar Gil dos. Cluster de Alta
Disponibilidade Abordagem OpenSource. Portugal: 2005.
GUINDANI, Alexandre. Gestão da Continuidade dos Negócios. Disponível em:
<http://www.upis.br/posgraduacao/revista_integracao/gestao_continuidade.pdf> Acesso em:
10 de setembro de 2009.
HAAS, Juergen. Heartbeat. Disponível em:
<http://linux.about.com/cs/linux101/g/heartbeat.htm> Acesso em: 20 de Outubro de 2009.
HP. Serviceguard Cluster Configuration for HP-UX 11i or Linux Partitioned Systems.
April, 2009.
IBM. Disponível em: <http://www03.ibm.com/systems/power/software/aix/high_avail_network/hageo_georm.html> Acesso em:
13 de setembro de 2009.
65
IBM. High Availability Geographic Cluster for AIX. 2003. Disponível em:
<http://publib.boulder.ibm.com/epubs/pdf/am8hc240.pdf > Acesso em: 16 de setembro de
2009.
IKE, Fernando. Revista Linux Magazine: Dados em Risco. Maio 2009.
LAKATOS, Eva Maria e MARCONI, Marina de Andrade. Fundamentos de Metodologia
Científica. 4 ed. São Paulo. Atlas, 2001.
LINUX-HA, Projeto High-Availability Linux. Assunto disponível em: <http://www.linuxha.org/pt_BR/HomePage_pt_BR> Acesso em 29 de Agosto de 2009a.
_________. Network failover strategies. Assunto disponível em: <http://www.linuxha.org/AddressFailover> Acesso em 22 de outubro de 2009b.
_________. The ha.cf file. Disponivel em: <http://www.linux-ha.org/ha.cf> Acesso em: 25
de outubro de 2009c.
_________. Configuring authkeys. Disponivel em: <http://www.linux-ha.org/authkeys>
Acesso em: 25 de outubro de 2009d.
MICROSOFT TechNet. Conceitos sobre Disponibilidade. Disponível em:
<http://technet.microsoft.com/pt-br/library/cc668492.aspx> Acesso em: 8 de setembro de
2009.
MICROSOFT. Load-Balanced Cluster. Disponível em: <http://msdn.microsoft.com/enus/library/ms978730.aspx> Acesso em: 16 de setembro de 2009a.
___________. Windows Server 2008 R2 Enterprise. Disponível em:
<http://www.microsoft.com/windowsserver2008/en/us/2008-ent.aspx> Acesso em: 13 de
setembro de 2009b.
___________. Windows Server 2008 R2 Datacenter. Disponível em:
<http://www.microsoft.com/windowsserver2008/en/us/2008-dc.aspx> Acesso em: 13 de
setembro de 2009c.
MORA, Gustavo Foletto. Balanceamento de carga de Servidores virtualizados. Santa
Maria, RS, Brasil, 2008.
NAKAI, Alan Massaru. Balanceamento de Cargas para Serviços Web Altamente
Disponíveis. Unicamp SP: 2008.
OLIVEIRA, Carlos Augusto Ferreira de. Cluster Beowulf uma solução de baixo custo.
Salvador – BA – Brasil, 2004.
OPENS. Instalando e configurando o Heartbeat. Disponível em:
<http://www.opens.com.br/documentacao/HA/Portugues/heartbeat.html> Acesso em: 18 de
setembro de 2009.
66
ORACLE. Internet Directory Administrator's Guide, 2004. Disponível em:
<http://download.oracle.com/docs/cd/B15904_01/manage.1012/b14082/failover.htm> Acesso
em: 21 de outubro de 2009.
PEREIRA JÚNIOR, João Eurípedes. Alta Disponibilidade em roteadores: Um ambiente de
teste. Universidade Federal do Uberlândia (UFU). Uberlândia – MG – Brasil, 2008.
QUORUM. Automated Disaster Recovery for XenServer. Disponível em:
<http://www.quoruminc.com/bc.html> Acesso em 13 de setembro de 2009.
REIS, Cristiane de Freitas, ET al. Cluster de Alta Disponibilidade. Disponível em:
<http://www.4learn.pro.br/fatec/SD/Apresentacao%201/HA/HA.pdf>. Acesso em: 30 de maio
de 2009.
ROBERTSON, Alan. The Evolution of The Linux-HA project. International Business
Machines Corporation. Disponível em: <http://www.linux-ha.org/TechnicalPapers> Acesso
em: 06 de setembro de 2009.
SAMBA. Heartbeat HA Configuration. Ultima modificação em 12 de março de 2007.
Disponível em: <http://wiki.samba.org/index.php/5.0:_Heartbeat_HA_Configuration> Acesso
em: 27 de setembro de 2009.
SANTANA, Paulo Afrânio. Delineamento de Pesquisa. Texto extraído do site do autor.
Disponível em: < http://www.pauloasantanna.psc.br/p4.htm> Acesso em: 23 de Agosto de
2009.
SUN MICROSYSTEMS. MySQL e DRBD Arquiteturas de Alta Disponibilidade. Uma
introdução a arquiteturas de Alta Disponibilidade com MySQL, DRBD e Linux
Heartbeat. Janeiro de 2009. Disponível em:
<http://br.sun.com/practice/systems/mysql/pdf/DRBD_MySQL_WP_152009.pdf.> Acesso
em: 16 de setembro de 2009.
SUPPORT, Microsoft. Número máximo de nós com suporte em um cluster. Disponível
em: <http://support.microsoft.com/kb/288778/pt-br> Acesso em: 13 de setembro de 2009.
WEBER, Taisy Silva. Tolerância a falhas: conceitos e exemplos. Porto Alegre – RS –
Brasil, 2001.