Cluster de Alta Disponibilidade
Adrieli Cristiane de Freitas Reis1
, Claudio Gonçalves Soares Júnior1
, Jorge Felipe
da Si...
de Alta Disponibilidade e Balanceamento de Carga geralmente são utilizados por lojas
virtuais. Clusters paralelos normalme...
Disponibilidade Contínua. Para que um sistema se enquadre como de Alta
Disponibilidade, adiciona-se à Disponibilidade Bási...
7. Falhas e soluções em Clusters de Alta Disponibilidade
Quando se pensa em montar um Cluster de Alta Disponibilidade deve...
Dentre as possibilidades as que mais se destacam atualmente são o uso de UPS
(Uninterruptible Power Supply) e de Geradores...
Outra alternativa é a utilização de um NAS ( etwork-Attached Storage), que é
um servidor de rede dedicado exclusivamente a...
Isso se deve principalmente por dois fatores: A facilidade de migração das
maquinas virtualizadas para outros servidores e...
como primário. Toda alteração neste irá ser refletida no secundário. O primário tem a
partição montada com DRBD montada, e...
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 d...
OpenSource para que o custo seja minimizado e a aplicação seja acessível por empresas
de menor porte, ou ainda, empresas o...
Upcoming SlideShare
Loading in...5
×

Alta Disponibilidade

236

Published on

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

  • Be the first to like this

No Downloads
Views
Total Views
236
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Alta Disponibilidade

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×