Revista Do Linux
 
OUTRAS SEÇÕES
  Cartas
  Variedades
  Rádio Linux
  CD do Mês
  Coluna do Augusto
  Leitura
  Dicas e truques
  Opinião
 

Alta Disponibilidade

Alta disponibilidade é um tema que tem despertado muito interesse. Vamos observar mais de perto e descobrir os conceitos envolvidos, suas vantagens, desvantagens e explorar alguns exemplos práticos

A Alta Disponibilidade está ligada diretamente à nossa crescente dependência dos computadores. Com o avanço das atividades que dependem de recursos computacionais, é cada vez maior o transtorno causado pela eventual falha desses sistemas. De sistemas bancários a supermercados, os computadores desempenham um papel crítico. Não apenas em tais tipos de serviços, mas, principalmente, em empresas cuja principal função é precisamente a oferta de algum serviço computacional, como e-business, notícias, sites de Internet, etc. Vejamos alguns exemplos simples:

• Você oferece algum produto aos seus clientes. Claro que seu produto é ótimo e deixa o cliente entusiasmado com a revolução que oferece. Tudo atende perfeitamente às suas necessidades. Mas de repente ele lhe pergunta: ”Então vai estar funcionando sempre que eu precisar?” Claro que vai. Mas como implementar? Afinal, seu sistema pode ser perfeito e nunca apresentar problemas, mas e o computador? E o HUB, a placa de rede, o HD?

• Você é administrador de algum sistema, e ele parou. Enquanto você tenta desesperadamente descobrir o problema, ouve seu chefe perguntando por sobre o seu ombro: O que houve? Quanto tempo vai levar para arrumar?, Uns cinco minutos? Não? Quantos então, uns quinze? Infelizmente nem todos os gerentes sabem que digitação e manutenção de sistemas não são a mesma coisa. Pior então se você disser que não sabe qual foi o problema: Então, pra que foi que te contratei?

Apenas dois exemplos. Mas a questão é muito séria. Com a expansão do mercado de comunicação, as idéias e problemas se tornam comuns. Sistemas oscilantes, suporte mal qualificado e demora na solução de problemas são comuns. A eficiência e um sistema sempre disponível quando o cliente precisar, certamente serão um diferencial. Pesquisas mostram que um cliente bem atendido repassa a boa impressão para 2 ou 3 pessoas, mas um cliente mal atendido repassa para 8 a 10! Para o cliente, sistema sempre disponível é requisito básico, nada mais do que a sua obrigação. E eu concordo com ele.
Mas infelizmente, sistemas computacionais falham, e um bom projeto prevê essas falhas e uma forma de contorná-las. É aí que se encaixa a Alta Disponibilidade.

O que é Alta Disponibilidade?

Define-se disponibilidade como a probabilidade de um sistema estar disponível (em perfeito funcionamento) em dado momento. Ela pode ser classificada como :

• Básica: qualquer sistema existente no mercado tem uma disponibilidade garantida de 99%.

• Alta: sistemas mais especializados, que garantem soluções de alguns noves (99,99%, 99,9999%). A briga entre as empresas é sobre quem consegue adicionar mais noves à sua solução.

• Contínua: situação ideal, mas teórica. A disponibilidade é igual a 1, ou seja, o sistema está sempre disponível. Infelizmente, é hipotética. Embora se possam garantir muitos noves, sempre existe uma possibilidade de o sistema parar.

Este é um conceito geral de disponibilidade e de qual é a Alta Disponibilidade. Mas onde ela se encaixa em projetos de sistemas?

Alguns autores a classificam como um cluster. Podemos definir cluster como vários computadores que trabalham em conjunto, mas que são vistos como uma só máquina. Os clusters são construídos, por exemplo, para balancear serviços entre computadores ou para a obtenção de maior capacidade de processamento. Como um ambiente de Alta Disponibilidade é também um conjunto de computadores que se comunicam para a manutenção de serviços, e isto de forma transparente ao usuário final, eles podem, também, ser classificados como um cluster de alta disponibilidade.

Outros autores identificam a alta disponibilidade como um item a ser avaliado na questão da segurança de sistemas. Assim como controle de acesso, permissões, segurança física, a preocupação com a disponibilidade do sistema é fundamental. Afinal, de que adianta um sistema que não se pode usar?

Alta disponibilidade é também referida como uma subárea de tolerância a falhas, uma vez que objetiva a continuidade do sistema mesmo com a ocorrência de falhas.

Como aumentar a disponibilidade do seu sistema

Existem várias formas de tentar contornar as falhas dos sistemas computacionais. Alguns exemplos são:

• Hardware especializado: Há, no mercado, várias alternativas de hardwares mais especializados que prevêem uma possível falha, tratando-a com redundância de recursos. Outros são voltados para a disponibilidade, com softwares que executam balanceamento de carga, redundância de links, tomada de serviços, monitoração, backup em tempo real, etc. Mas quanto mais especializados, mais caros são tais sistemas. E também têm, muitas vezes, um poder computacional bem maior que o necessário.

• Sistemas de tolerância a falhas: Aplicativos que evitam que falhas se tornem erros, e erros se tornem defeitos. Falhas dizem respeito ao universo físico, quando há, por exemplo, interferência eletromagnética. Erros ocorrem quando essas falhas mudam o valor de algum dado, como por exemplo, trocando o valor de algum bit. Acredito que a melhor maneira de se tratar um problema é logo no seu começo e, certamente, é melhor tratar o erro no momento em que ocorre, evitando danos maiores, como corrupção e/ou perda de dados. Sistemas assim, porém, são extremamente trabalhosos e complexos de desenvolver e requerem um conhecimento profundo e especializado, além de serem aplicações pesadas.

• Alta disponibilidade: Prevê a redundância total do sistema, atuando em caso de defeito, quando a máquina trava. Um defeito é um erro que causa pane no sistema, afetando o universo do usuário. Trabalha com a hipótese de completa parada do sistema, através de uma solução em redundância de hardware e controle via software. Um sistema de alta disponibilidade prevê tal comportamento com hardware simples, deixando a complexidade e o controle da disponibilidade do sistema para o software.

Gerenciamento de um ambiente de Alta Disponibilidade

Para um bom desempenho deste ambiente, é necessário o planejamento de uma estratégia de gerenciamento. Uma análise primária deve identificar o que é envolvido neste ambiente, como:

• Um conjunto de recursos e respectivos estados a serem gerenciados
• Um conjunto de testes executados periodicamente e/ou sob comando
• Um conjunto de ações a serem tomadas quando os testes falharem
• Um conjunto de ferramentas para observar e gerenciar os recursos e seus estados

Estes componentes devem trabalhar juntos para gerenciar o ambiente e são parte do ambiente em si. Veja alguns exemplos de recursos ou estados a serem gerenciados:

• Um servidor HTTP
• A conectividade com uma determinada máquina
• O estado de uma placa de rede
• O estado de um hub ou switch
• Uma unidade de armazenamento

E algumas ações que podem ser tomadas:

• Reinício do serviço HTTP
• Reinício da máquina
• Reconfiguração de outra máquina para tomada do endereço IP
• Reconfiguração de rotas para contornar um equipamento que não responde
• Notificação do administrador do sistema via e-mail ou pager

Montando um ambiente de HA

Como dissemos, conseguimos um ambiente de alta disponibilidade com a redundância de hardware, tendo uma máquina - chamada de nodo - principal e sistemas secundários, que seriam como espelhos do nodo principal. Para que uma máquina espelho assuma o lugar quando a principal falhar, ambas devem possuir os mesmos dados e/ou recursos envolvidos no tipo de serviço oferecido. Devem ser configuradas de forma a espelharem seus dados, para que, em caso de substituição de um sistema por outro, estejam atualizados e consistentes. Somente esses dados seriam espelhados, pois não faria sentido espelhar uma máquina inteira. O mínimo que poderia acontecer seria as duas máquinas brigarem eternamente pelo controle do ambiente.

Vamos analisar mais detalhadamente o que envolve a montagem de um ambiente de alta disponibilidade:

• 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á a principal e quem será o espelho.

• Consistência dos dados: Sistemas de arquivos jornalados. Estes sistemas armazenam em um diário (log) as ações antes de serem efetuadas. Desta forma, numa parada de sistema, seja por pane no próprio 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. Nessa transferência, porém, o sistema deve ser autônomo e capaz de reconfigurar-se para continuar atendendo aos usuários.

• Monitoração: O sistema deve monitorar seus serviços para detectar um defeito, disparando assim a reconfiguração.

Exemplo de solução

Uma das soluções que já utilizei foi a combinação de Ext3 com DRBD, Heartbeat e Mon:

• Sistema de Arquivos Journaled - Ext3: talvez o Reiserfs seja mais utilizado, pois foi um dos primeiros sistemas jornalados que apareceram, mas o Ext3 oferece a compatibilidade com o Ext2, eliminando a necessidade de recriar o sistema de arquivos. Alguns testes mostraram uma leve superioridade do Reiserfs sobre o Ext3, mas tal diferença não chega a ser tão grande para suplantar a facilidade e segurança na mudança.

• Espelhamento de dados - DRBD: O 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 configura um dos nodos como primário. Toda alteração neste será refletida no secundário. O nodo primário tem a partição com DRDB montada, enquanto que o secundário não.

• Sinal de Vida - Heartbeat: onde reside a configuração dos serviços e do 'ip de serviço'. É o heartbeat 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. Ao acontecer uma pane no sistema, o heartbeat do nodo primário libera os serviços e ips, e o outro nodo assume o posto.

• 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, e também pode ser configurado para disparar programas em caso de incidente, inclusive o Heartbeat.

Então, num quadro geral, o Mon ficaria monitorando o sistema. Ao detectar que um serviço não está respondendo, que a máquina está com alguma pane, perceber que está isolado da rede (no nodo primário), ou que o nodo secundário não está respondendo, ele dispararia o heartbeat, para derrubar ou para levantar os serviços. Um destes serviços deve ser o Drdb, que embora sempre espelhando não estaria com a partição montada. Montando estas partições, que contêm os dados atualizados para o serviço que se oferece, estes serviços estarão em condições de responder com autoridade para os usuários.

Talvez alguém se pergunte: mas porque vários aplicativos e não um sistema geral? Além de ser muito mais portável e leve, estes aplicativos podem ter várias outras aplicações. Pode ser que se deseje apenas monitorar um servidor. Pode ser que se possua um storage externo compartilhado por duas máquinas e se queira coordenar o controle deste.

Oferecemos assim uma visão geral do que está envolvido na Alta Disponibilidade e um exemplo de um ambiente. Para mais detalhes sobre como implementar esse ambiente, disponibilizei na página ha.underlinux.com.br/ um HOWTO com todos os passos para sua instalação e configuração.


Sulamita Garcia - sulamita@fastpack.com.br


A Revista do Linux é editada pela Conectiva S/A
Todos os Direitos Reservados.

Política de Privacidade
Anuncie na Revista do Linux