Em vez de montar um único servidor com componentes redundantes, existe também a opção de usar um cluster de alta disponibilidade (chamados de “high-availability clusters” ou “failover clusters”), 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 cross-over 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 (http://www.drbd.org), 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.
