Cada vez mais é necessário garantir a disponibilidade de um serviço, mas sendo que muitos componentes dos sistemas de informação atuais contém partes mecânicas, a confiabilidade destes é relativamente insuficiente se o serviço for crítico. Para garantir a ausência de interrupções de serviço é necessário, muitas vezes, dispor de hardware redundante que entre em funcionamento automaticamente quando da falha de um dos componentes em utilização.

Quanto mais redundância existir, menores serão os SPOF (Single Point Of Failure), e menor será a probabilidade de interrupções no serviço. Até poucos anos atrás tais sistemas eram muito dispendiosos e tem-se vindo a intensificar uma procura em soluções alternativas. Surgem então os sistemas construídos com hardware acessível (clusters), altamente escaláveis e de custo mínimo. A figura 1 ilustra a configuração típica de um sistema de alta disponibilidade dual-node. Como se pode observar, não existe um único ponto nesta arquitetura que, ao falhar, implique a indisponibilidade de outro ponto qualquer (SPOF). O fato de ambos os servidores se encontrarem em funcionamento e ligados à rede não implica, porém, que se encontrem a desempenhar as mesmas tarefas. Esse é uma decisão por parte do administrador e que tem o nome de balanceamento de carga.

A tabela 1 ilustra um dos termos de comparação geralmente utilizado na avaliação de soluções HA: níveis de disponibilidade segundo tempos de indisponibilidade (downtime). Excluídos desta tabela, os tempos de downtime estimados (geralmente para manutenção ou reconfiguração dos sistemas) são alheios às soluções e muito variáveis.

Tabela 1 - Níveis de alta disponibilidade

Disponibilidade (%)	Downtime/ano	     Downtime/mês
95%	                18 dias 6:00:00	     1 dias 12:00:00
96%	                14 dias 14:24:00     1 dias 4:48:00
97%	                10 dias 22:48:00     0 dias 21:36:00
98%	                7 dias 7:12:00	     0 dias 14:24:00
99%	                3 dias 15:36:00	     0 dias 7:12:00
99,9%	                0 dias 8:45:35.99    0 dias 0:43:11.99
99,99%	                0 dias 0:52:33.60    0 dias 0:04:19.20
99,999%	                0 dias 0:05:15.36    0 dias 0:00:25.92

Geralmente, quanto maior a disponibilidade, maior a redundância e custo das soluções: tudo depende do tipo de serviço que se pretende disponibilizar. Por exemplo, um operador de telecomunicações quererá certamente o mais elevado a fim de poder garantir um elevado nível de disponibilidade, sob pena de perder os seus clientes caso o sistema sofra falhas constantemente. No entanto, uma empresa com horário de trabalho normal poderá considerar que 90% de disponibilidade serão suficientes. É de salientar que o nível de disponibilidade mensal não é o mesmo que o anual. Efetivamente, para se obter um nível de disponibilidade mensal de 97%, é necessário que o nível anual seja aproximadamente de 99,75%. A tolerância a falhas consiste, basicamente, em ter hardware redundante que entra em funcionamento automaticamente após a detecção de falha do hardware principal. Independentemente da solução adotada, existem sempre dois parâmetros que possibilitam mensurar o grau de tolerância a falhas que são o MTBF - Mean Time Between Failures - (tempo médio entre falhas) e o MTTR - Mean Time To Repair - tempo médio de recuperação, que é o espaço de tempo (médio) que decorre entre a ocorrência da falha e a total recuperação do sistema ao seu estado operacional. A disponibilidade de um sistema pode ser calculada pela fórmula:

Disponibilidade = MTBF / (MTBF + MTTR)

Fonte: http://pt.wikipedia.org/wiki/Disponibilidade

Clusters de alta disponibilidade

Em vez de montar um único servidor com componentes redundantes, existe também a opção de usar um cluster de alta disponibilidade (chamado de "high-availability cluster" ou "failover cluster"), onde são usados dois servidores completos, onde a única função do segundo servidor é assumir a posição do primeiro em caso de falhas (modo chamado de ativo/passivo), diferente de um cluster com balanceamento de carga, onde os servidores dividem as requisições (ativo/ativo).

Existem diversas soluções para clusters de alta disponibilidade. Entre as soluções abertas, uma das mais usadas é o projeto Linux-HA (High-Availability Linux, disponível no http://www.linux-ha.org), que desenvolve o Heartbeat, um daemon 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.

Cada um dos servidores possui pelo menos duas placas de rede, o que permite que eles sejam simultaneamente ligados à rede e ligados entre si através de um cabo crossover ou de um switch dedicado. A conexão interna é usada pelo Heartbeat para as funções de monitoramento e sincronismo dos processos, de forma que o segundo servidor possa assumir imediatamente a função do primeiro quando necessário, assumindo o endereço IP anteriormente usado por ele.

É comum também o uso de uma terceira interface de rede em cada servidor (ligada a um switch separado), destinada a oferecer uma conexão de backup com a rede. Isso permite eliminar mais um possível ponto de falha, afinal, de nada adianta ter servidores redundantes se o switch que os liga à rede parar de funcionar. :)

Em geral, o Heartbeat é usado em conjunto com o Drbd, que assume a função de manter os HDs dos dois servidores sincronizados, como uma espécie de RAID 1 via rede. Ao usar o Drbd, o HD do segundo servidor assume o papel de unidade secundária e é atualizado em relação ao do primeiro em tempo real. Quando o primeiro servidor pára, a unidade de armazenamento do segundo servidor passa a ser usada como unidade primária. Quando o servidor principal retorna, o HD é sincronizado em relação ao secundário e só então ele reassume suas funções.

Outra opção é utilizar uma SAN (veja a seguir) para que os dois servidores compartilhem a mesma unidade de armazenamento. Nesse caso, não é necessário manter o sincronismo, já que os dados são armazenados em uma unidade comum aos dois servidores.

Como pode ver, adicionar componentes redundantes, sejam fontes, HDs ou servidores adicionais aumentam consideravelmente os custos. A principal questão é avaliar se o prejuízo de ter o servidor fora do ar por algumas horas ou dias durante as manutenções, acidentes e imprevistos em geral é maior ou menor do que o investimento necessário.

Um pequeno servidor de rede local, que atende a meia dúzia de usuários em um pequeno escritório dificilmente precisaria de redundância, mas um servidor de missão-crítica (como no caso de um banco) com certeza precisa. Cada nível de redundância adiciona um certo valor ao custo dos servidores, mas reduz em certa proporção o tempo de downtime.

A disponibilidade do servidor é genericamente medida em "noves". Um nove indica uma disponibilidade de 90%, ou seja, uma situação em que o servidor fica fora do ar até 10% do tempo (imagine o caso de uma máquina instável, que precisa ser freqüentemente reiniciada, por exemplo), o que não é admissível na maioria das situações.

Com dois noves temos um servidor que fica disponível 99%, o que seria uma boa marca para um servidor "comum", sem recursos de redundância.

Por outro lado, uma disponibilidade de 99% significa que o servidor pode ficar fora do ar por até 7 horas e 18 minutos por mês (incluindo todas as manutenções, quedas de energia, operações de backup que tornem necessário parar os serviços e assim por diante), o que é tolerável no caso de uma rede local, ou no caso de um servidor que hospeda um site fora da área de comércio eletrônico, mas ainda não é adequado para operações de missão crítica.

Para adicionar mais um nove, atingindo 99.9% de disponibilidade (o famoso "three nines"), não é possível mais contar apenas com a sorte. É necessário começar a pensar nos possíveis pontos de falha e começar a adicionar recursos de redundância. Entram em cena as fontes redundantes, o uso de uma controladora RAID com suporte a hot-swap, uso de um nobreak com boa autonomia para todo o equipamento de rede, de forma que o servidor continue disponível mesmo durante as quedas de luz, e assim por diante. Afinal, 99.9% de disponibilidade significa que o servidor não fica fora do ar por mais de 43 minutos por mês.

No caso de servidores de missão crítica, qualquer interrupção no serviço pode representar um grande prejuízo, como no caso de instituições financeiras e grandes sites de comércio eletrônico. Passa então a fazer sentido investir no uso de um cluster de alta disponibilidade e em links redundantes, de forma a tentar atingir 99.99% de disponibilidade. Esta marca é difícil de atingir, pois significa que o servidor não deve ficar mais do que 4 minutos e meio (em média) fora do ar por mês, incluindo aí tudo o que possa dar errado.

Como sempre, não existe uma fórmula mágica para calcular o ponto ideal (é justamente por isso que existem consultores e analistas), mas é sempre prudente ter pelo menos um nível mínimo de redundância, nem que seja apenas um backup atualizado, que permita restaurar o servidor (usando outra máquina) caso alguma tragédia aconteça.

Referência: http://www.gdhpress.com.br/servidores/leia/index.php?p=cap14-3

Este artigo cobre como implementar a alta disponibilidade, ela pode ser aplicada a vários tipos de serviços.

Heartbeat funciona como gestor do cluster e dos seus recursos. Como o nome indica, a sinalização da presença (ou ausência) de contato com os nodos do cluster faz-se mediante o envio de pequenos pacotes (heartbeats, batimentos cardíacos) dirigidos a todos os nodos do cluster, cuja confirmação de recepção por parte de cada nodo indica o estado desse nodo.

Fonte: http://pt.wikipedia.org/wiki/Linux-HA

DBRD é a acrônimo para o nome inglês Distributed Replicated Block Device. O DRBD consiste num módulo para o núcleo Linux que, juntamente com alguns scripts, oferece um dispositivo de bloco projetado para disponibilizar dispositivos de armazenamento distribuídos, geralmente utilizado em clusters de alta disponibilidade. Isto é feito espelhando conjuntos de blocos via rede (dedicada). O DRBD funciona, portanto, como um sistema RAID baseado em rede.

Fonte: http://pt.wikipedia.org/wiki/Drbd

OCFS2 é um sistema de arquivos de cluster para Linux capaz de fornecer tanto de alto desempenho quanto alta disponibilidade.

Uma vez que fornece a semântica do sistema de arquivos local, ele pode ser usado com qualquer aplicação. Como cluster de aplicações sensíveis pode fazer uso de I/O paralelo para um melhor desempenho e fornecer um failover de configuração para aumentar a sua disponibilidade.

Além de ser usado com o Oracle Real Application Cluster de banco de dados do produto, OCFS2 está atualmente em uso para fornecer servidores de web escaláveis e servidores de arquivo, bem como fail-over-mail e servidores para hospedagem de imagens da máquina virtual. E pode ser utilizado para as mais diversas finalidades dentro de um sistema, não somente para os Bancos de dados, mas sim para qualquer partição na qual se deseje o acesso simultâneo de vários clientes.

Algumas das características notáveis do sistema de arquivos são:

• Tamanho variável de bloco
• Alocação flexível (extensões, escasso, as extensões não-escrita com a capacidade de furos)
• Journaling (ordenado e dados de write-back diário modos)
• Endian e Arquitetura Neutro (x86, x86_64, ia64 e ppc64)
• In-built Clusterstack com um Distributed Lock Manager Suporte para Buffered, Direct, Asynchronous, Splice e Memory Mapped I / Os
• Cluster Ferramentas de conhecimento (mkfs, fsck, tunefs etc)

Fonte: http://oss.oracle.com/projects/ocfs2

Monit é um utilitário de código aberto para gerenciamento e monitoramento, processos, arquivos, diretórios e arquivos em um sistema UNIX.

Monit efetua manutenção e reparo automático e pode executar ações significativas em situações de erro.

O que pode fazer o Monit?

Monit pode iniciar um processo se não funcionar, reiniciar um processo se ele não responder e interromper um processo, se ele usa recursos demais. Você pode usar Monit para monitorar arquivos, diretórios e arquivos para mudanças, como alterações carimbo do tempo, alterações ou mudanças de verificação de tamanho. Você também pode controlar máquinas remotas; Monit pode executar ping um host remoto e pode verificar conexões TCP / IP e porta do servidor. Monit é controlado através de um arquivo de controle baseados em um formato livre, sintaxe token-orientado.

Os logs do Monit podem ser para o syslog ou ao seu próprio arquivo de log e notificá-lo sobre as condições de erro e status de cobrança por via de alerta customizável.

Fonte: http://mmonit.com/monit/

LVS Linux Virtual Server (LVS) é uma solução de balanceamento de carga avançada para sistemas Linux. É um projeto Open Source começado por Wensong Zhang em maio de 1998. A missão do projeto é construir um servidor de alto desempenho e altamente disponível para Linux usando a tecnologia de clustering, que fornece altos níveis de escalabilidade, confiabilidade e usabilidade.

O trabalho principal do projeto de LVS deve agora desenvolver o software de balanceamento de carga avançado de IP (IPVS), o software de balanceamento de carga a nível aplicativo (KTCPVS) e componentes de gerenciamento de cluster.

IPVS: é um software balanceador de carga avançado do IP executado dentro do Linux. O código de IPVS era já incluído no núcleo padrão 2.4 e 2.6 de Linux.

KTCPVS: executa a carga do nível de aplicação que balança dentro do Linux, atualmente sob desenvolvimento.

Os usuários podem usar as soluções de LVS para construir serviços de rede altamente escaláveis e altamente disponíveis, tais como o serviço de mídia, serviço de email. Os meios prestam serviços de manutenção e serviços de VoIP, e integram serviços de rede escaláveis em aplicações de confiança em grande escala do e-comércio ou do e-governo.

As soluções de LVS têm sido desdobradas já em muitas aplicações reais durante todo o mundo.

Fonte: http://pt.wikipedia.org/wiki/LVS

Para mais informações a respeito dessas ferramentas podem ser consultados os links abaixo.

• Heartbeat
• DRBD
• OCFS2
• MONIT
• LVS

Essas ferramentas são ótimas para garantir a alta disponibilidade dos nossos servidores como pode ser visto.

A implementação é um pouco trabalhosa na primeira vez, mas com o passar do tempo isso fica bem fácil que você pode até criar um script para fazer tudo isso.

Só não vão achando que este artigo vai deixar você um expert em alta disponibilidade, eu só vou dar o caminho das pedras e vocês tem que ir seguindo em diante.

Dependendo da distribuição GNU/Linux isso pode se tornar mais fácil ou mais difícil em questão de trabalho, fora isso é aplicado a qualquer distro. No momento estou fazendo esta implementação em FreeBSD, assim que terminar vou publicar as diferenças na implementação.

Então chega de história, só os oriento a pesquisarem mais sobre o assunto e fazerem muitos testes antes de colocarem em produção por que só com o tempo para ir se familiarizando com os possíveis erros.

Vamos começar!