Cluster de Alta Disponibilidade com Ferramentas Open Source High Availability Cluster With Open Source Tools Fernando Luis Diesel¹, Ms. Fernanda Pamplona Ramão 2 1.2 Curso de Especialização em Redes de Computadores de Alta Velocidade - Faculdade Alfa Brasil - FAAB Cascavel - Brasil fernandodiesel.info@gmail.com Resumo: A necessidade de se ter serviços de rede em alta disponibilidade vem crescendo a medida que as empresas dependem primordialmente dos mesmos para seu pleno funcionamento. A exigência de investimento em equipamentos de rede para que haja segurança em disponibilidade de serviços na área computacional é grande, e é por isso que empresas buscam soluções viáveis através de softwares gratuitos para o gerenciamento de Clusters de Alta Disponibilidade. Este artigo tem como principal intuito, dar uma ampla visão ao leitor e administrador de redes sobre o que venha ser e como funciona a computação em cluster, soluções em ferramentas e hardwares utilizados, também as vantagens e a necessidade de se ter este tipo de infra-estrutura, tem como foco principal em cluster de Alta Disponibilidade com ferramentas Open Source. Palavras-chave: artigo; cluster; disponibilidade; ferramentas. Abstract: The need to have network services for high availability is growing as companies rely primarily on the same for their full operation. The requirement for investment in network equipment to provide safety in the availability of services in computing is great, and why companies seek viable solutions through free software for managing High Availability Clusters. This article has as its main purpose, to give the reader a broad overview and network administrators about what will be and how the cluster computing solutions, tools and hardware used, also the advantages and the need to have this type of infrastructure structure, focused primarily on cluster High Availability with Open Source tools. Key-words: Article; cluster; availability; tools. 1. Introdução Atualmente com o avanço dos sistemas informatizados e o seu papel importante perante o mercado, fez com que a necessidade de manter determinados serviços ativos e com o menor tempo inoperante possível, se tornasse um dos principais requisitos para o mercado. Isso vem a prevalecer às soluções Open Source voltadas ao serviço de alta disponibilidade, seguindo no princípio e focando em clusters de Alta Disponibilidade. Assim, o objetivo é apresentar não só o conceito de clusters como também soluções de ferramentas Open Source, também como, algumas opções de hardware e redundância entre os mesmos, e por fim problemas e soluções que poderão ocorrer e intervir neste tipo de ambiente.
2. Clusters Um cluster pode ser definido como um conjunto de dois ou mais computadores, denominados nodos ou nós, que resulta em um único sistema que responda por um ou mais serviços. É denominado Sistemas de Imagem Única (Single System Image Operating System - SSI OS), independente da infra-estrutura por detrás de um ambiente de alta disponibilidade, um único sistema irá responder a solicitação pelo serviço requerido (PITANGA, 2003). Clusters são usados em ambientes críticos onde há a necessidade de serviços estarem sempre disponíveis e/ou processados em menor tempo possível. Provedores de internet, sites de comércio eletrônico, redes sociais requerem alta disponibilidade e balanceamento de carga escalável em seus serviços. 3. A necessidade da utilização de um Cluster De acordo com Pitanga (2003), 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. Os clusters de Alta Disponibilidade e Balanceamento de Carga normalmente são utilizados por lojas virtuais, Data Centers onde possuem recursos para detectar, recuperar e ocultar eventuais falhas, pois a porcentagem de disponibilidade destes serviços precisa ser o mais alto possível, por isso é usado em ambientes críticos onde a paralisação de determinados serviços, podem afetar gravemente o funcionamento do ambiente como um todo. Clusters de Processamento Paralelo são utilizados em ambientes onde há necessidade de se obter alto desempenho, como por exemplo, a renderização de gráficos de altíssima qualidade e animações. Já em ambientes com clusters Beowulf ou aglomerado Beowulf são utilizados no processamento de dados com finalidade na pesquisa científica. As necessidades de implementação de clusters surgem em empresas que desejam incrementar sua escalabilidade, gerenciamento de recursos, disponibilidade ou processamento a nível supercomputacional com um investimento viável. 4. Tipos de Cluster utilizados: Segundo Pitanga (2003), basicamente, existem quatro tipos de clusters mais conhecidos e
4.1 Balanceamento de carga (HS Load Balancing): este tipo de cluster tem como função receber o tráfego de entrada e direcionar aos nodos para que executem os mesmos programas e ao mesmo tempo entre as máquinas que compõem o cluster. Este tipo de ambiente se faz necessário onde há uma demanda de processamento em larga escala e em determinados ambientes onde uma máquina só não conseguiria manter o serviço no ar, como por exemplo, as lojas virtuais. 4.2 Alta disponibilidade (HA High Availability): este tipo de cluster tem como função permanecer o sistema ativo por um longo período de tempo e em plena condição de uso; sendo assim, pode se afirmar que eles nunca param seu funcionamento, além disso, conseguem detectar erros se protegendo de possíveis falhas; 4.3 Combinação HA & HS: combina as características de dois tipos de cluster, aumentando assim a disponibilidade e escalabilidade de serviços e recursos. Este tipo de configuração de cluster geralmente é utilizado em servidores de web, mail ou ftp. 4.4 Alto desempenho (HPC): este tipo de cluster é associado ao projeto Beowulf e é usado onde há a necessidade de executar tarefas ou serviços que exigem alto poder de processamento, seja ele paralelo ou distribuído, fazendo com que as mesmas sejam processadas em menor tempo possível. Essas tarefas podem ser divididas em pequenas tarefas que são distribuídas entre os nós do cluster. Este tipo de ambiente computacional é comumente utilizado em áreas ligadas onde são feito cálculos científicos, análises financeiras, entre outros. 5. Cluster de Alta Disponibilidade A busca por soluções plausíveis e a tolerância a falhas em sistemas computacionais faz com que haja um avanço na área de alta disponibilidade, resultando em necessidade de se ter ambientes de clusters com o propósito de ter redundância caso haja quedas ou falhas em sistemas críticos. Quando se fala em alta disponibilidade, aglomera-se uma série de fatores que atuam em conjunto para que haja disponibilidade propriamente dita. A disponibilidade de um sistema operacional pode ser calculada a partir de alguns fatores: MTBF(Mean Time Between Failures): Tempo médio entre as falhas. MTTR(Mean Time To Repair): Tempo médio para a reparação. Essa disponibilidade pode ser calculada pela seguinte fórmula:
Disponibilidade = MTBF/(MTBF+MTTR) O resultado aceitável em um ambiente crítico deverá ser de aproximadamente acima de 99%, logicamente que quanto mais um ambiente se aproximar de um resultado de 100% mais tolerante a falhas ele vai ser e o custo de sua implantação será mais alto (PITANGA, 2003). 6. A composição de um Cluster de Alta Disponibilidade A composição de um ambiente Cluster HA vária muito da necessidade de cada empresa, geralmente quando projetado este tipo de ambiente deve-se conter um projeto detalhado não só das necessidades e problemas como também soluções de implantação com base no custo e benefício que a empresa dispõe-se de investir. 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 monitoramento os outros e assumindo seus serviços caso alguns deles venham a falhar (IKE, 2008). Um Cluster de Alta Disponibilidade além dos nós ou nodos também é formado pela disponibilidade de hardware, software para gerenciamento, monitoramento, e a estrutura de rede instalada no ambiente. 6.1. Hardware A importância de se ter alta disponibilidade de hardware dentro de um ambiente Cluster HA é de suma importância, uma vez que o hardware é vital para o ambiente, logo se ele falhar como um todo, tudo estará comprometido no mesmo momento da falha. A redundância do hardware instalado no ambiente Cluster HA depende muito da prioridade dada na necessidade em que é montado o ambiente, isso implica na quantidade e estrutura dos equipamentos na rede, a seguir será mostrado em quais equipamentos pode-se obter proveito, disponibilidade e segurança no ambiente com base em detalhes técnicos. Nó ou Nodo: Toda máquina existente por trás de um ambiente Cluster é denominado nó ou nodo, logo se ela se integra ao ambiente também é denominada Membership (The Cluster Membership Object). A quantidade de nós existentes em um Cluster pode variar dependendo da necessidade e do propósito que ele vai ser instalado.
Hard Disk Disco Rígido: Os discos rígidos ou comumente chamados de HD s, tem como função o armazenamento de dados, em um ambiente Cluster HA eles podem ser utilizados para implantação de RAID, LVM ou Storage iscsi. Fonte Redundante: A fonte tem função de gerar energia e prover o funcionamento a todos os componentes de um computador, se tornando vital no funcionamento do mesmo. Por isso há a necessidade de fontes redundantes, pois quando houver a necessidade de uma potência maior no ambiente, a mesma não deixará o ambiente cair por falta de potência de energia. Storage: É um hardware que contém slots para vários discos rígidos, ele pode ser ligado aos nós do cluster através de iscsi ou fibra óptica. Storages pode aceitar diversas conexões de servidores diferentes, ao mesmo tempo, logo poderá ser utilizado para criar RAID, LVM, se tornando seguro e altamente portável. Controladora RAID: É um dispositivo dedicado para fazer RAID, pois ao invés de se fazer via software e hardware de uma máquina comum, as controladoras têm a função dedicada a isto, com isso se ganha mais confiabilidade, segurança e desempenho. Switch Fibre Channel: Dispositivo de comunicação de alta velocidade, é comumente utilizado para interligar servidores a sistemas de armazenamento do tipo SAN (Storage Area Network), pode ser utilizado tanto por cabeamento de fibra óptica como por cabeamento metálico. Adaptador de Rede: São os adaptadores de rede que fazem a diferença na comunicação entre os nós do cluster, pois são úteis para bonding de interfaces, no ambiente cluster há exigência se tratando do tipo de interface a se utilizar, pois as mesmas devem ser de boa qualidade sendo gigabit ou fibre channel para se obter melhor desempenho e segurança na comunicação dedicada entre os nodos do cluster. 6.2. Softwares e Ferramentas Open Source As falhas ocorridas por software em um ambiente cluster normalmente são contornadas através da redundância entre os nodos, já se tratando de falha de hardware dependendo da estrutura do ambiente, ainda haverá redundância para que o sistema não fique inoperante. O custo com a redundância de equipamentos de um ambiente cluster torna-se alto, por isso a busca por soluções Open Source torna-se um fator relevante devido o alto custo direcionado aos equipamentos. 6.2.1. Distributed Replicated Block Device (DRBD)
DRBD (Distributed Replicated Block Device) consiste em um módulo do kernel Linux, que somado com alguns scripts, oferece um dispositivo de bloco projetado para disponibilizar dispositivos de armazenamento distribuídos, é comumente utilizado em ambientes de cluster de alta disponibilidade. Geralmente sua implementação é espelhada em conjuntos de blocos via rede dedicada, inclusive este espelhamento de rede de dados é totalmente transparente, com isso consiste em fazer Raid1 em rede em tempo real. Trabalha no nível mais baixo do filesystem, pois seu módulo está devidamente localizado entre o sistema de arquivos e o I/O Sheduler. O DRBD não tem capacidade de detectar nenhum corrompimento no filesystem, porém isto não diminui sua importância no ambiente, toda e qualquer leitura e escrita será feita apenas no nodo primário e replicado via rede para o nodo secundário, sendo que o dispositivo replicado não é montado no nodo secundário para não haver conflitos na rede do ambiente, pois os nodos terão que ter um filesystem suportado para escrita concorrente, juntamente com respectivo storage, ambiente este que será citada posteriormente. Outro fator que deve ser observado é que quando o DRBD faz a replicação de dados pela rede, conseqüentemente há uma perda de desempenho tanto pela rede como nos nodos. Devido ao problema de desempenho o DRBD possui mais de um protocolo de comunicação para ser escolhido conforme a necessidade de cada ambiente, dentre eles são: - Protocolo A (assíncrono): Protocolo assíncrono é o mais rápido, porém tem uma maior probabilidade de perda dados, este protocolo tem seu processo de escrita contínua independente da confirmação de escrita do nodo primário para o nodo secundário. Por isso quando o nodo primário falhar, a replicação será feita para o nodo secundário e as requisições não confirmadas estarão inconsistentes. - Protocolo B (semi-assíncrono): Completa as operações de gravação local no nodo primário e são consideradas concluídas assim que ocorreu a gravação do disco local e o quadro de replicação alcançar os nodos pares. - Protocolo C (síncrono): Protocolo mais seguro, pois só completa a requisição quando a operação local for concluída e for recebida a mensagem de WriteACK do nodo secundário.
Figura 1 - Visão de nível conceitual do funcionamento do DRBD. Fonte: Adaptado de REIS et al. 6.2.2. Heartbeat Heartbeat é o software responsável por monitorar os nodos do cluster e tomar atitudes de acordo com os casos encontrados, pode-se dizer que o heartbeat é o coração do ambiente HA (alta disponibilidade). O heartbeat é um daemon que fornece infra-estrutura de cluster, provendo a comunicação e participação de serviços aos seus nodos. Isso permite que os nodos comuniquem entre si para que os mesmos saibam qual deles estão inoperantes, assim havendo a replicação e levantamento de serviços no outro nodo. A partir do momento em que o nodo master parar de responder, o heartbeat irá automaticamente levantar os serviços e o ip virtual juntamente com o DRBD fazendo a replicação dos dados existentes no nodo master, lembrando que ele monitora somente o nodo em si, se acaso um serviço cair, o mesmo não será levantado no nodo slave, por causa do heartbeat, ele não monitora o serviço e sim o nodo.
Figura 2 - Visão de nível conceitual do funcionamento do Heartbeat. Fonte: Elaboração do autor. 6.2.3. Mon Mon é um utilitário, para gerenciamento e monitoramento de processos, programas, arquivo, diretório e sistema de arquivos em um sistema UNIX. O Mon realiza manutenção e reparação automática e pode executar ações casuais em situações de erro. No ambiente cluster, ao contrário do heartbeat, o mon irá monitorar os serviços ao invés do nodo em si, para que quando um serviço cair no nodo master, o mesmo seja levantado no nodo slave. Com isso o mon vem como solução perante a deficiência do heartbeat de monitorar só o nodo em si e não os serviços e aplicações que por ventura venham a falhar no ambiente. 6.2.4. Ethtool - Channel-Bonding de Interfaces Ethtool é um utilitário cuja função é a configuração de placas de rede ou comente chamada de interfaces, o mesmo permite consultar e alterar configurações como velocidade, porta, autonegociação, PCI locais e descarregamento de checksum em muitos dispositivos de rede, inclusive também possui suporte a função de channel-bonding. Channel-Bonding ou comumente citado como trunking ou até mesmo chamado de link agregation é uma técnica que permite o agrupamento de interfaces de rede como se fosse uma só, para garantir redundância do serviço nelas instalado. Qualquer nodo que se utilize deste serviço, necessitará de ao menos de duas interfaces de rede, que o mesmo poderá perder uma interface e o serviço nela instalado ainda estará operante, sem a queda do mesmo. Além de redundância, dependendo do modo operante do bonding, pode-se também obter velocidade de conexão, e
também a soma da velocidade de cada uma das interfaces envolvidas. Esta redundância de interfaces garante que a comunicação entre os nodos torne-se segura, pois uma vez que ocorra o rompimento desta comunicação, o ambiente pode sofrer com Split-Brain (cérebro dividido), ou seja, os dois nodos acham que são master e levantam os mesmos serviços causando problemas de consistência de dados. Dependendo do ambiente e da estrutura instalada existe vários modos que bonding pode operar, abaixo citado os principais modos: - Modo 0 (balance-rr): modo mais utilizado, transmite os pacotes em ordem seqüencial do primeiro slave ao último. É o modo padrão, é também o único modo que permite com que o tráfego seja distribuído entre as interfaces slave simultaneamente. - Modo 1 (active-backup): neste modo apenas um slave estará ativo, as demais placas de rede apenas serão ativadas no caso de falha do slave ativo. Este modo é propicio para tolerância a falhas e alta disponibilidade. - Modo 2 (balance-xor): os dados transmitidos neste modo passam por uma política adotada baseada em hashs, as funcionalidades deste modo são as mesmas do modo 0. Neste modo também é possível configurar políticas alternativas modificando xmit_hash_policy ao carregar o módulo. - Modo 3 (broadcast): transmite todos os pacotes em todos os slaves. Provê tolerância a falhas e alta disponibilidade. - Modo 4 (padrão 802.3ad): permite agregação dinâmica de links. É necessário um switch que suporte 802.3ad e que o ethtool consiga configurar os parâmetros speed e duplex em todos os slaves. 6.2.5. Oracle Cluster File System - OCFS2 OCFS2 é um CFS (Cluster File System), sistema de arquivos de cluster de disco compartilhado, é capaz de fornecer alto desempenho e alta disponibilidade. OCFS2 tem o propósito de suprir a deficiência dos tipos de sistemas ext4, ext3, entre outros, pois os mesmos não possuem suporte a DLM (Distributed Lock Manager), fazendo com que não tenham sucesso em ambientes com escrita de arquivos de dois ou mais nodos em discos compartilhados. Atualmente é mantido e suportado pela Oracle, e é usado em empresas de médio porte até em grandes estruturas de cluster, onde a necessidade de se ter este tipo de CFS é muito grande. Dentre as soluções Open Source, a mais cabível há um ambiente cluster seria formatar partições e discos compartilhados com OCFS2, justamente por ser livre, e está ao nível de muitos filesystem s de soluções pagas. 6.2.6. Openfiler - iscsi
Openfiler é um poderoso software para armazenamento Open Source, considerado por muitos a melhor e mais completa ferramenta livre para esta categoria, além de leve e ter um bom desempenho também pode ser gerenciado via broswer facilitando e muito o seu acesso. É suportado a diversos hardwares podendo se tornar um poderoso servidor NAS (Network Attached Storage). Openfiler é construído sobre o Linux Metadistribuição rpath e é distribuído como um dispositivo stand-alone, os protocolos de rede baseados em arquivos suportados pelo Openfiler incluem: NFS, SMB, CIFS, HTTP, FTP e WebDAV. Diretórios de rede suportados pelo Openfiler incluem NIS, LDAP (com suporte para SMB, CIFS senhas criptografadas), Active Directory nos modos nativos e mistos, protocolos de autenticação Kerberos, e gerenciamento de servidores iscsi, além de ter suporte a RAID e LVM. ISCSI (Internet Small Computer System Interface) é um protocolo da pilha TCP/IP, utilizado para criar uma ligação entre rede e armazenamento de dados. Para isso, este carrega comandos SCSI sobre redes TCP/IP para armazenamentos em redes locais e remotas. Este serviço atua rodando em portas 860 e 3260, além de suportar clientes, chamados de initiators enviem comando SCSI para os dispositivos de armazenamento SCSI denominados targets. É um protocolo SAN (Storage Area Network), permitindo que empresas consolidem sua área de armazenamento dentro de Data Centers enquanto provê hospedagem de servidores como banco de dados, web, com a ilusão que possuem discos localmente anexados. Figura 3 - Visão de nível conceitual do funcionamento Servidor iscsi com o Openfiler Fonte: Elaboração do autor.. 6.2.7. Nagios
Em um ambiente cluster é essencial que se tenha monitoramento tantos dos serviços como seus membros, para tal tarefa é designada a ferramenta nagios, por ser robusta e totalmente intuitiva, a mesma é distribuída sob a licença GPL (General Public License) com isso sendo de código aberto. O nagios atualmente é mantido por Ethan Galstad junto com uma equipe de desenvolvedores que ativamente mantém plugins oficiais e não oficiais. Dentre as características do nagios pode-se citar: Monitoramento de serviços de rede (DHCP, SMTP, POP3,HTTP,FTP,SSH, IMAP, etc); Monitoramento de recursos (CPU, disco, memória, etc); Monitoramento do estado dos dispositivos; Define hierarquia da rede; Possui sistema inteligente de notificações (sons, pop-up, e-mail, sms, etc); Possui checagem paralela de serviços; Possui interface WEB capaz de informar sobre status de rede, hosts, serviços, logs e notificações. 6.2.8. Ganglia Em um ambiente cluster há a necessidade de monitorar os nodos deste ambiente, tanto o desempenho como eventuais falhas e até prover antecipação de erros e falhas que podem ocasionar interoperabilidade do ambiente. Além da ferramenta nagios citado anteriormente para o monitoramento de serviços, o ganglia pode atuar como um complemento a esta, fazendo o que a mesma não faz, que é monitorar o desempenho dos nodos. Ganglia é uma ferramenta de monitoramento de desempenho, destinando a computação de alto desempenho com foco em clusters. Permite a visualização remota de estatísticas em tempo real, histórico de utilização de carga de rede, utilização de CPU, entre outros, para todas as máquinas que estão sendo monitoradas. O ganglia possui alguns daemons dentre eles existe o gmond, que é usado para monitorar as mudanças no estado de host, anunciar mudanças relevantes, além de ouvir o estado dos outros nodos com o ganglia instalado através de um canal unicast ou multicast.
7. Problemas A segurança em um ambiente cluster não se limita somente em um sistema implantado propriamente dito, mas sim como um todo, somando a estrutura com comunicações dedicadas entre os nodos, redundância de energia, redundância de link WAN, entre outros que garantem uma maior segurança e estabilidade do ambiente, abaixo uma tabela com alguns desses requisitos: Tabela 1 - Problemas ocasionados em um cluster. Fonte: Elaboração do autor. Problema Conseqüência Solução Perda de dados Inconsistência no ambiente Raid, Backup local e remoto Perda de energia Ambiente Inoperante Links redundantes de energia Perda de comunicação WAN Comunicação afetada Link WAN redundantes Interrupção na comunicação entre os nodos Resulta perda parcial ou completa dos serviços gerando inconsistência Comunicação dedicada entre os nodos com cabeamento fibrechannel ou interface e cabeamento gigabit. Superaquecimento Queima dos equipamentos Boa Refrigeração, e evitar aglomeração de equipamentos Eventuais Furtos de informações Pode-se manchar a imagem da empresa Implantação de firewall, segurança, hardening de serviços, etc. Hora não igual para os nodos Gravação de dados inconsistentes Implantação de servidor ntp. Quando se trata de redundância de link WAN, deve-se observar se a última milha provedora do serviço é a mesma que provê para os links do cluster, porque se for, e a mesma chegar a ser derrubada, conseqüentemente ambos os links irão cair e o ambiente terá seus serviços inoperantes. O mesmo acontece com a redundância de energia, se a empresa que fornece energia, for a mesma que fornece para ambos os links de energia do ambiente, e a mesma chegar a ser derrubada ambos os links de energia irão cair e o cluster parar de funcionar devido ao problema. Segundo Tanenbaum (1996), quando se começa a trabalhar com várias máquinas em ambientes distribuídos, cada uma com seu próprio relógio, o risco de inconsistência de a hora ficar diferente entre as máquinas é grande, pois embora a freqüência de um oscilador de cristal ser muito estável, dificilmente cada um terá exatamente a mesma freqüência. Para contornar este problema recomenda-se a utilização de um servidor NTP (Network Time Protocol), onde os nodos do cluster consultaram de tempo em tempo na internet a hora certa. 8. Datacenter A consistência de um cluster depende muito da forma com que o ambiente é implementado, isso varia desde a escolha por soluções até o custo com que vai ser investido para que se tenham vantagens. Vantagens essas que garantem a segurança do serviço e das informações neles contidos.
Figura 4 - Sistema de Alta Disponibilidade com dois nodos e sendo acessados por três clientes. Nodo primário(ativo) e nodo secundário(passivo) 9. Conclusão Fonte: Adaptado de REIS et al. Atualmente ambientes clusters estão se tornando essenciais para suprir a demanda de alto tráfego de dados e a disponibilidade de serviços em sistemas críticos, a busca também é muito grande para soluções Open Source devido ao alto investimento de equipamentos. Soluções estas que às vezes são difíceis de escolher, de implantar, ou até quais escolher na hora de implantação de um cluster, por isso este artigo teve seu principal objetivo além de apresentar as definições de ambientes aos mais diferenciados, como também apresentar ferramentas fáceis de ser implementadas e também esclarecer alguns detalhes que devem ser observados atentamente. Referências PITANGA, Marcos. Computação em cluster: O Estado da arte da computação. Rio de Janeiro: Brasport, 2003a. PITANGA, Marcos. Construindo supercomputadores com Linux. 2. ed. Rio de Janeiro: Brasport, 2003b. IKE, Fernando. O máximo da disponibilidade: Sempre Alerta. Linux Magazine. 43º edição, 2008.
TANENBAUM, Andrew S. Sistemas Distribuídos. Rio de Janeiro: Editora Pearson Prentice Hall, 1996. REIS, Adrieli C. et al. Cluster de Alta Disponibilidade. São Paulo: Faculdade de Tecnologia de Guaratinguetá (FATEC-GT),. Fernando Luis Diesel Filiação institucional: Faculdade Alfa Brasil (FAAB) Aluno. Rua Domingos Correa Ribas, 611 Centro. Foz do Jordão-PR. CEP: 85.145-000 (42)8824-9672 fernandodiesel.info@gmail.com Fernanda Pamplona Ramão Faculdade de Ciências Sociais Aplicadas de Cascavel (UNIVEL) Docente. Mestre. Rua Padre Anchieta, 266 Pq São Paulo. Cascavel-PR. CEP: 85.803-740 fernandapramao@yahoo.com.br