Este documento discute clusters de alta disponibilidade, definindo-os como sistemas compostos por dois ou mais computadores trabalhando juntos de forma transparente aos usuários. Detalha os principais tipos de clusters, incluindo clusters de alta disponibilidade, e explica como esses clusters funcionam através da redundância de hardware e software para garantir a disponibilidade dos serviços.

1. Cluster de Alta Disponibilidade
Adrieli Cristiane de Freitas Reis1
, Claudio Gonçalves Soares Júnior1
, Jorge Felipe
da Silva Ferreira1
, Júlio César Parra de Almeida1
, Matheus Marcondes da Silva1
,
Sabrina Aparecida dos Santos Gavinier1
.
1
Faculdade de Tecnologia de Guaratinguetá (FATEC-GT)
12517-475 – Guaratinguetá – SP – Brasil
dri.bela@hotmail.com, claudiogsjr@gmail.com, jfelipelilo@hotmail.com,
jcpa.parra@gmail.com, matheusmarcondes@gmail.com,
sabrinagavinier@hotmail.com.
Abstract. This article has the intuit of showing the reader a vision of what is
and how cluster computation works, focusing in High Availability Clusters.
Resumo. Este artigo tem o intuito de dar ao leitor uma visão do que vem a ser
e como funciona a computação em cluster, focando em Clusters de Alta
Disponibilidade.
1. Introdução.
A dependência cada vez maior dos sistemas informatizados fez com que a necessidade
de manter determinados serviços ativos e sem ocorrência de falhas durante a maior parte
do tempo, se tornasse um dos principais requisitos para o mercado. As soluções
tecnológicas evoluíram, surgindo o serviço de Alta Disponibilidade, e
consequentemente os clusters de Alta Disponibilidade.
2. Clusters.
Um cluster pode ser definido como um sistema que compreende dois ou mais
computadores ou sistemas, denominados nodos ou nós, no qual trabalham em conjunto
para executar aplicações ou realizar outras tarefas, de maneira transparente aos usuários,
ou seja, os usuários terão a impressão de estar utilizando um único sistema [1].
Os clusters são utilizados para processar conteúdos críticos e garantir a
disponibilidade de determinados serviços, buscando manter-se funcionando sem
ocorrência de falhas e durante a maior parte do tempo possível. Pode-se citar como
exemplo, a utilização de clusters de Alta Disponibilidade em Data Centers de bancos e
sites de e-commerce, uma vez que tais exemplos necessitam manter-se no ar ‘24 horas
por dia, 7 dias por semana, 365 dias no ano’.
Como características fundamentais para a construção destas plataformas
incluem-se: elevação da confiança, distribuição de carga e desempenho [1].
Neste artigo, serão abordados conceitos sobre clusters de Alta Disponibilidade,
indispensável para aplicações de missão crítica, suas possíveis falhas e soluções.
3. Razões para utilização de um Cluster.
Os clusters ou combinações de clusters são utilizados a fim de processar conteúdos
críticos ou disponibilização de serviços durante a maior parte do tempo [1]. Os clusters

2. de Alta Disponibilidade e Balanceamento de Carga geralmente são utilizados por lojas
virtuais. Clusters paralelos normalmente são utilizados pela indústria cinematográfica a
fim de renderizar gráficos de altíssima qualidade e animações. Por sua vez, os clusters
Beowulf são utilizados na pesquisa cientifica, pelo seu poder de processamento e custo
de implementação.
Os clusters também são utilizados em empresas que desejam incrementar sua
escalabilidade, gerenciamento de recursos, disponibilidade ou processamento a nível
supercomputacional a um preço moderado [2].
4. Tipos de Cluster
Basicamente, existem quatro tipos de clusters mais conhecidos e utilizados [1]:
4.1. Alta Disponibilidade (HA - High Availability): estes modelos de clusters são
construídos para prover uma disponibilidade de serviços e recursos de maneira
ininterrupta, através do uso da redundância implícita ao sistema. Caso um nó do cluster
vier a falhar (failover), aplicações ou serviços estarão disponíveis em outro nó. Estes
tipos de cluster são utilizados para base de dados de missões críticas, correio, servidores
de arquivos e aplicações.
4.2. Balanceamento de carga (HS- Load Balancing): distribui o tráfego entrante ou
requisições de recursos provenientes dos nodos que executam os mesmos programas
entre as máquinas que compõem o cluster. Todos os nodos estão responsáveis em
controlar os pedidos. Em caso de falha em um nó, as requisições são redistribuídas entre
os nós disponíveis no momento. Este tipo de cluster é normalmente utilizado por
servidores web que demandam muito acesso, como por exemplo, as lojas virtuais.
4.3. Combinação Alta Disponibilidade e Balanceamento de carga: combina os dois
clusters acima, aumentando a disponibilidade e escalabilidade dos serviços e recursos.
Muito utilizado em servidores web e e-mail.
4.4. Processamento Distribuído ou Processamento Paralelo (HPC): este modelo de
cluster aumenta a disponibilidade e desempenho para as aplicações, sendo utilizado em
tarefas típicas em que se exige desempenho no processamento. Uma grande tarefa
computacional pode ser dividida em pequenas tarefas que são distribuídas entre os nós,
que ficam com a tarefa de processá-las. Este tipo de cluster é comumente associado ao
projeto Beowulf. Estes clusters são usados em computação científica ou análises
financeiras, tarefas típicas que exigem um alto poder de processamento.
5. Clusters de Alta Disponibilidade
As falhas em sistemas computacionais são inevitáveis, porém, um dos principais
objetivos na utilização dos clusters é justamente proporcionar meios de tolerância a
estas falhas.
A Alta Disponibilidade é a soma de diversos fatores que buscam garanti-la e
não somente uma atitude isolada. A disponibilidade de um sistema computacional pode
ser calculada utilizando a seguinte fórmula: Disponibilidade = Tempo médio entre
falhas / (Tempo médio entre falhas + tempo médio para realização do reparo) [3].
Esta disponibilidade pode ser classificada de acordo com a faixa de valores do
tempo de disponibilidade. São elas: Disponibilidade Básica, Alta Disponibilidade e

3. Disponibilidade Contínua. Para que um sistema se enquadre como de Alta
Disponibilidade, adiciona-se à Disponibilidade Básica, encontrada comumente em
máquinas básicas, sem nenhum mecanismo especial de software ou hardware,
mecanismos especializados de detecção, recuperação e mascaramento de falhas. Nesta
classe as máquinas tipicamente apresentam disponibilidade na faixa de 99,99% a
99,999%, podendo ficar indisponíveis por um período de pouco mais de 5 minutos até
uma hora em um ano de operação. Nesta categoria, se encaixam grande parte das
aplicações comerciais de Alta Disponibilidade, como centrais telefônicas. [3].
A Alta Disponibilidade está ligada diretamente a crescente dependência aos
sistemas informatizados, uma vez que tais equipamentos possuem um papel crítico,
principalmente em empresas cuja maior funcionalidade é exatamente a oferta de algum
serviço computacional, como e-business, notícias, sites web, banco de dados, dentre
outros [3].
Existem duas caracteristicas importantes que devem ser observadas para clusters
de Alta disponibilidade: [4]:
- Failover: Em caso de falha o sistema age automaticamente sem que seja
preciso a intervenção humana. Por exemplo: um link de acesso à Internet que prove
serviços para usuários de uma rede privada. Este link é composto por três provedores de
acesso distintos, sendo um deles o principal e os demais secundários. Caso o acesso
principal seja interrompido por algum motivo, o secundário irá entrar em ação,
provendo o acesso sem interrupções sem que o usuário perceba.
- Escalabilidade: Capacidade que permite acrescentar novos recursos ou
substituir existentes, sem a necessidade de paralisar o serviço.
6. Funcionamento dos clusters de Alta Disponibilidade.
A utilização de um cluster de Alta Disponibilidade visa manter a
disponibilidade dos serviços prestados por um sistema computacional replicando
serviços e servidores, através da redundância de hardware e reconfiguração de software.
Vários computadores juntos agindo como um só, cada um monitorando os outros e
assumindo seus serviços caso algum deles venha a falhar.
As vantagens em se utilizar um cluster de Alta Disponibilidade estão no alto
desempenho, escalabilidade e tolerância a falhas [5].
Os clusters de Alta Disponibilidade têm como função principal prover uma alta
disponibilidade de recursos e serviços o maior tempo possível, de forma ininterrupta,
onde há uma grande dependência dos computadores. Sua forma mais básica de
funcionamento é substituir um nó do cluster no momento que este vier a falhar, por
outro, de modo transparente ao usuário. Geralmente são usados por servidores web,
servidores de arquivos e aplicações, bases de dados de missões críticas [5].
O Sistema de Alta Disponibilidade com maior maturidade e mais utilizado no
sistema operacional Linux é o Heartbeat [6]. Este sistema controla a parada e o início de
serviços ou a execução de comandos em um conjunto de máquinas. Adiante será
tratado o Heartbeat, juntamente com uma solução OpenSource.

4. 7. Falhas e soluções em Clusters de Alta Disponibilidade
Quando se pensa em montar um Cluster de Alta Disponibilidade deve se levar
em consideração diversos fatores, para que realmente se tenha um sistema confiável e
tolerante aos diversos tipos de falhas que possam vir a ocorrer.
É muito comum, quando se pensa em Alta Disponibilidade, lembrar somente de
aspectos como backup de dados, RAID, redundância de servidores, porém a
abrangência para Clusters de Alta Disponibilidade é bem maior.
Na tabela 1 serão descritos alguns dos possíveis pontos de falhas e como
minimizá-los ou saná-los.
Tabela 1. Tipos de falhas e possíveis soluções.
Tipo de Falha Falha Possível Solução
Rede Elétrica Queda total ou parcial de energia Implementação de
sistemas UPS
(Uninterruptible Power
Supply) e Geradores de
Energia Elétrica (figura 1)
Rede Dados Inoperância de ativos de rede
(placa de rede, switches)
Redundância de placas
de rede com uso de
bonding e uso de
switches com stacking e
suporte 802.3ad (figura
2)
Hardware Problemas na fonte de alimentação Redundância de fonte,
hotswap
Hardware Falha no disco Uso de RAID em
hardware ou software,
hotswap
Softwares Falha de Sistemas ou Aplicações Redundância das
Aplicações/Sistemas
Softwares Corrupção de Sistema Operacional Redundância de
Servidores (figura 3)
Hardware/Softwar
e
Falha completa do Servidor
(memória, processador, SO)
Redundância de
Servidores
Data Center Desastres Naturais / Incidentes
Criminosos
Redundância de Data
Center
7.1. Rede Elétrica
Uma das primeiras preocupações para garantir que se consiga ter Alta Disponibilidade é
o tratamento com a alimentação elétrica do Data Center / Cluster. A falta de
alimentação elétrica parcial ou total pode ser ocasionada por diversos motivos, como
temporais, raios, manutenção da rede pública, etc. Como não há como prever quando
este tipo de problema irá surgir, principalmente quando se trata de desastres naturais, é
necessário que se tenha uma forma de se garantir a alimentação do cluster.

5. Dentre as possibilidades as que mais se destacam atualmente são o uso de UPS
(Uninterruptible Power Supply) e de Geradores Elétricos. Os UPS garantem a
alimentação, como o próprio nome diz, ininterruptamente, ou seja, o sistema não parará
de funcionar quando ocorrer uma queda brusca de energia. Porém, o UPS, por trabalhar
baseado em baterias, tem sua autonomia limitada a poucas horas, o que não irá garantir
a disponibilidade do sistema caso a falta de energia perdure por muito tempo. Nesse
caso, a combinação UPS + Gerador acaba suprindo esta lacuna, pois o primeiro
garantirá que o serviço/aplicação fornecido pelo cluster não sofra interrupção, e o
segundo garantirá a alimentação elétrica por muito mais tempo, pois sua autonomia será
limitada pelo combustível utilizado no funcionamento do gerador.
Nesse sentido é sempre importante garantir que o combustível do gerador esteja
sempre à disposição e com quantidade suficiente para garantir a autonomia necessária.
7.2. Rede de Dados
Outro fator importante para se garantir a Alta Disponibilidade é garantir que o sistema
esteja sempre conectado a rede, caso contrário todo esforço será em vão.
Um falha em uma placa de rede ou em um switch poderá ser suficiente para
tornar inacessível um sistema que necessite de Alta Disponibilidade, caso o mesmo não
tenha sido corretamente configurado.
As técnicas atualmente muito utilizadas para driblar esses problemas são o
Bonding das interfaces de rede e a utilização de switches com stacking e suporte a
802.3ad (Link Agregation).
O bonding corresponde a agregação de mais de uma interface de rede, fazendo
com que, para o sistema operacional, seja tratada como uma única interface. Com isto é
possível que, caso uma das interfaces que constitui o bonding venha a falhar, as demais
continuem em operação, permitindo a acessibilidade do sistema.
Outra técnica importante para se trabalhar com Clusters de Alta Disponibilidade
é o uso de switches com tecnologia de suporte a stacking e 802.3ad.
A tecnologia 802.3ad permite que mais de uma porta do switch seja agregada
(link agregation) fornecendo assim uma redundância de conexão em um mesmo
equipamento. Já o stacking fornece a possibilidade de se trabalhar com dois switchs
como se fosse um só. Ou seja, um “link agregation” entre dois switches.
7.3. Hardware
Das falhas que podem ocorrer no hardware de um dos servidores que fazem parte do
cluster, as que mais se destacam e que podem sofrer medidas preventivas são as de
fonte de alimentação e disco rígido [8].
No caso da fonte de alimentação, a solução para evitar problemas é que o
servidor possua fontes redundantes, com isso, caso uma pare de funcionar por algum
motivo, a alimentação não será suspensa. É importante também que a mesma possua a
tecnologia HotSwap, pois quando ocorrer um problema, a mesma poderá ser substituída
sem a necessidade de desligamento do servidor.
Para os discos rígidos, normalmente são utilizados as soluções de RAID (pt:
Conjunto Redundante de Discos Independentes). O RAID pode ser implementado tanto
através de hardware quanto através de software. Normalmente são utilizados os RAID
10, 1 ou 5. É importante também, no caso do uso de RAID, o suporte a HotSwap.

6. Outra alternativa é a utilização de um NAS ( etwork-Attached Storage), que é
um servidor de rede dedicado exclusivamente ao armazenamento de dados, sendo
normalmente mais custoso para implementação [8].
7.4. Software
Normalmente as falhas que podem ocorrer em um cluster na parte de software acabam
sendo minimizadas somente com a redundância de servidores (nós). Como exemplo,
pode-se citar um sistema operacional corrompido por qualquer motivo, em que o
servidor acabará se tornando inoperante, sendo assim, não será possível fazer algo de
imediato no mesmo para restabelecê-lo sem ocasionar uma perda de disponibilidade.
O mesmo ocorreria caso a falha fosse, por exemplo, na memória, ou ainda, no
processador de um dos nós, onde somente se outro nó assumir suas funções, o sistema
continuará disponível.
7.5. Data Center
Até agora foram vistas diversas formas de se manter um Cluster de Alta
Disponibilidade, porém, tão importante quanto as garantias mencionadas anteriormente,
é necessário garantir que, caso ocorra tanto um desastre natural ou acidental, quanto um
incidente criminoso em todo o data center, este possa ser prontamente restabelecido,
minimizando ao máximo, ou ainda, suprimindo a indisponibilidade dos sistemas
clusterizados.
Um exemplo disto pode ser visto no fatídico incidente ocorrido em 2001 no
World Trade Center, em Nova York. No primeiro caso, uma corretora de seguros tinha
seu data center em uma das torres e sua réplica na outra torre. Só não imaginaram que a
segunda torre cairia junto com a primeira, ocorreu. No segundo caso, uma instituição
bancária também tinha seu data center em uma das torres, mas sua réplica estava a
alguns quilômetros de distância do principal. Nesse caso, ocorreu uma leve
indisponibilidade do sistema corporativo, até que o segundo data center estivesse em
plena operação.[7]
7.6. Medidas Adicionais
Algumas medidas adicionais podem ser tomadas para garantir que um Cluster de Alta
Disponibilidade fique menos tempo inoperante, são elas:
- Backup: Cópia de segurança dos dados e configurações dos sistemas;
- Segurança Lógica: Implementação de medidas de segurança para tornar o
cluster somente acessível pra quem de direito, e conforme as necessidades (firewall, ids,
etc.)
- Segurança Física: Isolamento do data center das demais instalações, evitando o
tráfego constante de pessoas, principalmente as não autorizadas.
- Refrigeração: Garantir que a refrigeração do data center seja constante e
eficiente.
8. Virtualização e Cluster de Alta Disponibilidade
Na busca constante das empresas por alta disponibilidade, vem se tornando comum o
uso de sistemas virtuais para aplicações de balanceamento de carga ou failover[9].

7. Isso se deve principalmente por dois fatores: A facilidade de migração das
maquinas virtualizadas para outros servidores e a redução do custo na aquisição de
hardware. Porém, o “mocinho” pode virar “vilão” caso alguns cuidados não sejam
tomados. Por abrigar em um único servidor físico diversos sistemas virtuais, pode se ter
uma idéia do desastre que seria se não tivermos soluções que garanta a disponibilidade
do sistema no caso de uma falha ocorrer na máquina principal (hospedeira). Uma falha
em um disco rígido, ou ainda, de uma placa de rede, pode ser crítica, pois afetará não
somente um serviço/servidor, mas diversos. Ou seja, a virtualização esta para suprir em
muito as necessidades de alta disponibilidade, principalmente pelo seu custo reduzido.
Mas deverá sofrer um estudo detalhado para que as falha mencionadas anteriormente
possam ser contornadas tanto na máquina hospedeira, quanto nas virtualizadas.
9. Cluster de Alta Disponibilidade com Solução OpenSource
A necessidade de se ter sistemas que necessitam de Alta Disponibilidade acaba trazendo
um alto custo em virtude das redundâncias necessárias. Para tornar isso um pouco mais
acessível, além do uso de virtualização, deve ser considerado o uso de Softwares Livres
/ OpenSource na implementação de Clusters de Alta Disponibilidade. Isso garantirá
uma economia considerável, sem perder, no entanto, a confiabilidade e disponibilidade
do sistema.
Antes de falarmos sobre os softwares utilizados para o cluster de alta
disponibilidade, vamos definir, em poucas palavras, a arquitetura de nosso cluster. A
montagem de um ambiente de alta disponibilidade necessitará [10]:
- Hardware: redundância de máquinas (requisito), de links, conexão dedicada e
de alta velocidade (recomendada).
- Instalação do sistema: os softwares devem ser independentes de distribuição. A
identidade das máquinas fica a cargo do administrador do sistema, quem será o principal
e quem será o espelho.
- Consistência dos dados: sistemas de arquivo journaled. Estes sistemas
armazenam em um journal (log) as ações antes de serem efetuadas. Desta forma, em
uma parada no sistema, seja por pane no sistema ou queda de energia, a recuperação é
muito mais rápida e indolor.
- Espelhamento de dados: os dados devem ser espelhados em tempo real para a
completa disponibilidade do sistema em caso de defeito.
- Controle de serviços: com os dados espelhados, os serviços podem ser
passados de uma máquina para outra. Porém o sistema deve ser autônomo nesta
transferência e ser capaz de se reconfigurar para continuar atendendo aos usuários.
- Monitoração: o sistema deve monitorar seus serviços para detectar um defeito,
disparando assim a reconfiguração.
Uma solução para este cluster utiliza a combinação de ext3 + drbd + heartbeat
+ mon.
Sistema de Arquivos Journaled - Ext3: Como mencionado anteriormente, é
importantíssimo que o sistema de arquivos utilize mecanismos de journaled. Dentre os
disponíveis e mais utilizados nos sistemas operacionais GNU/Linux estão o Reiserfs e o
Ext3. No caso, opta se por utilizar o Ext3 pela sua facilidade e compatibilidade com o
Ext2, versão anterior que não suportava journaling.
Espelhamento de dados - DRBD: o DRBD (Distributed Replicated Block
Device) espelha os dados em blocos, repassando-os através da rede. Funcionando em
pares, ele estabelece em cada nodo uma partição para espelhar, e seta um dos nodos

8. como primário. Toda alteração neste irá ser refletida no secundário. O primário tem a
partição montada com DRBD montada, enquanto o secundário não (figura 1).
A partir da versão 8 passou a suportar a configuração com dois dispositivos
primários permitindo além da alta disponibilidade o balanceamento de carga através da
distribuição das operações de leitura e escrita. Este modo, entretanto, exige a utilização
de sistemas de arquivos distribuídos.
O DRBD resulta numa perda de performance (tanto na rede como nos
servidores) devido a realização de replicação síncrona entre os discos dos nós. Por essa
razão pode-se escolher qual protocolo utilizar para essa replicação dentre os citados
abaixo:
- Protocolo A (assíncrono): Completa a requisição logo que a operação local é
concluída e mandada ao segundo nó pela rede. Caso o primeiro nó falhe e o serviço
passe para o segundo nó, todas as operações de escrita que ainda não atingiram este
segundo nó serão perdidas;
- Protocolo B (quase-assíncrono): Completa a requisição logo que a operação
local é concluída e a resposta de RecvAck do segundo é recebida. Considerando o
recebimento da resposta no nó primário, os dados provavelmente alcançaram o disco
remoto (nó secundário). Mesmo que o nó primário falhe e o serviço passe ao secundário
nenhum dado foi perdido;
- Protocolo C (síncrono): Completa a requisição apenas quando a operação local
for concluída e for recebida a mensagem de WriteAck do nó secundário.
Figura 1: Visão do nível conceitual de funcionamento do DRBD.
Sinal de Vida - Heartbeat: O nó considerado principal é onde reside a
configuração dos serviços e do 'IP de serviço'. É o hertbeat o responsável pela
reconfiguração automatizada na ocorrência de problemas. Cada máquina possui seu IP
próprio, válido ou não, mas o conjunto é identificado por um IP de serviço, que é
mantido pela máquina primária no par.

9. Ao acontecer uma pane no sistema (figura 2), o heartbeat de um lado libera os
serviços e IP’s, e do outro assume. Possui duas versões sendo que em sua primeira
versão trabalhar apenas com clusters de 2 nós e em sua segunda versão trabalha com
clusters de 1 a N nós.
Figura 2: Sistema de Alta Disponibilidade com dois servidores sendo acessados por
quatro clientes. Servidor Primário (ativo) e Servidor Secundário (passivo).
Mon: bastante leve, possui diversos monitores e sistemas de alerta para as mais
variadas funções e serviços. Possui envio de mensagens via página, correio, sms, bem
como pode ser configurado para disparar programas em quaisquer linguagens. Inclusive
o heartbeat.
Esta solução é estável, de implementação simples e utilizada em todo o mundo.
Entretanto, uma requisição enviada ao servidor primário antes de sua falha que envolva
alguma atividade de escrita (e-mail, banco de dados, servidor de arquivos, etc.) e não
tenha sido gravada no disco do servidor primário, será perdida quando o servidor
secundário assumir. Pois, o servidor secundário só possui as informações que tiverem
sido gravadas no disco do servidor primário e replicadas em seu disco.
Recomenda-se utilizar uma solução deste tipo em sistemas de e-mail, servidor de
arquivos, servidor web e banco de dados. Sendo que devem ser tomados os devidos
cuidados no sistema gerenciador de banco de dados para que não sejam perdidas
requisições de transação.
10. Conclusão
O uso de clusters de alta disponibilidade já é uma realidade. A dependência de sistemas
informatizados para acesso e armazenamento de informações tem se tornado cada vez
maior. Com isso, diversas empresas terão de optar por esse tipo de solução, tornando-se
imprescindível para diversos ramos do negócio, uma vez que falhas são inevitáveis,
porém podem ser minimizadas, tornando transparente para o usuário e garantindo a
segurança e continuidade dos serviços, principalmente quando o mesmo lida com dados
críticos. Apesar de demandar um custo relativamente alto, é possível utilizar soluções

10. OpenSource para que o custo seja minimizado e a aplicação seja acessível por empresas
de menor porte, ou ainda, empresas onde a alta disponibilidade apesar de necessária,
pode não ser vital.
Referências
[1] Pitanga, Marcos. (2003) “Computação em cluster”,
http://www.clubedohardware.com.br/artigos/153.
[2] Oliveira, Carlos Augusto Ferreira de. “Cluster Beowulf – Uma solução de baixo
custo”, Brasil.
[3] Guia no Servidor Conectiva Linux,
http://www.conectiva.com/doc/livros/online/9.0/servidor/ha.html
[4] Guia de Inovação tecnológica em Cluster e Grid,
http://guialivre.governoeletronico.gov.br/guiaonline/guiacluster/node26.php
[5] Pinto, Hudson de Jesus L. e Silva, Michel Pires da. e Silveiras, Gabriel Damaso da.
“Ambientes de Alto Desempenho utilizando Cluster de Computadores”, Brasil.
[6] Linux-HA. “Heartbeat”, http://www.linux-ha.org/Heartbeat
[7] Ike, Fernando. (2008) “O máximo da disponibilidade: Sempre Alerta”, Linux
Magazine - 43ª edição.
[8] Sinhoreli, Marcos. (2008) “Armazenamento com alta disponibilidade: Os dados não
param”, Linux Magazine - 43ª edição.
[9] Sinhoreli, Marcos. (2008) “HA com Xen: substituto virtual”, Linux Magazine - 43ª
edição.
[10] Vigliazzi, Douglas. Alta Disponibilidade em Sistemas GNU-Linux,
http://www.vivaolinux.com.br/artigo/Alta-Disponibilidade-(High-Availability)-em-
sistemas-GNU-Linux