Entendendo Uptime em Servidores
Basicamente qualquer PC pode ser usado como um servidor, basta que você instale os softwares apropriados. Para tarefas leves, como compartilhar a conexão, até mesmo máquinas antigas podem prestar bons serviços. Entretanto, quando falamos de servidores de hospedagem e servidores usados em grandes empresas, o cenário é um pouco diferente.
Além de rodarem serviços e aplicativos muito mais pesados, atendendo a centenas de usuários simultâneos, estes servidores realizam tarefas essenciais, de forma que qualquer interrupção em suas atividades pode representar um grande prejuízo, ao contrário de um desktop, onde o usuário pode simplesmente reiniciar depois de uma tela azul, como se nada tivesse acontecido. Um bom servidor deve ser capaz de funcionar por anos a fio, com pouca ou nenhuma manutenção. Além de ser otimizado para um conjunto específico de tarefas, ele precisa ser muito mais estável e confiável do que um desktop típico.
Entra em cena então a questão da redundância, baseada na idéia de ter componentes "de reserva", prontos para assumirem o trabalho caso o primeiro falhe.
Existem fontes redundantes, arrays de discos redundantes e até mesmo servidores redundantes, onde temos dois servidores completos, sincronizados em tempo real, onde o segundo servidor monitora o primeiro e assume suas funções em caso de problemas.
As fontes redundantes são chamadas de RPS (Redundant Power Supply) e se baseiam no uso de módulos substituíveis. Para servidores menores, é mais comum o uso de fontes 1×1, onde temos dois módulos independentes e um circuito central, que monitora as tensões e ativa o segundo módulo em caso de problemas com o primeiro. Para servidores que precisam de mais do que 350 ou 400 watts de energia, é comum o uso de fontes 2×1, onde são usados três módulos, onde dois deles fornecem energia ao servidor (o que permite somar as capacidades) e o terceiro módulo fica de reserva para o caso qualquer um dos dois falhar:
Naturalmente, fontes redundantes são consideravelmente mais caras, não apenas porque os circuitos são todos duplicados, mas também por que elas precisam ser muito mais compactas do que uma fonte tradicional, já que temos essencialmente duas ou três fontes no espaço de uma.
Na maioria dos casos, os módulos podem ser substituídos a quente (hot-swap), sem necessidade de desligar o servidor. Um alarme sonoro ou visual avisa do problema, permitindo que o administrador substitua o módulo defeituoso assim que possível.
No caso dos discos rígidos, temos os diferentes modos de operação do RAID, que permitem adicionar redundância (sacrificando parte do espaço disponível), aumentar o desempenho (fazendo com que o sistema use os HDs simultaneamente, dividindo as operações entre eles), ou ambas as coisas combinadas.
Existem três categorias de RAID: RAID via hardware, RAID via software e fake-RAID. A grande diferença entre eles é justamente sobre em quem recai o trabalho.
No RAID via hardware é utilizada uma controladora dedicada, que realiza todas as funções. Este modo é o ideal tanto do ponto de vista do desempenho quanto do ponto de vista da compatibilidade e confiabilidade, já que a própria controladora executa todas as funções necessárias, de forma independente. A única desvantagem é o custo, já que uma boa controladora, destinada a uso em servidores, custa a partir de US$ 300.
O RAID via software é executado pelo próprio sistema operacional, sem necessidade de nenhum hardware adicional. É possível criar arrays RAID via software tanto no Linux quanto no Windows 2000, XP, 2003 Server e Vista, utilizando HDs ligados às próprias interfaces SATA da placa-mãe.
O fake-RAID é o modo utilizado pela maioria das controladoras RAID onboard, sobretudo nos micros desktop. Nele é utilizada uma combinação de funções adicionais no BIOS da placa e um driver que roda pelo sistema operacional. No final, tudo é processado via software, de forma que não existe ganho de desempenho em relação a utilizar RAID via software. Apenas a configuração é simplificada.
O procedimento de troca dos HDs defeituosos varia de acordo com os recursos oferecidos pela controladora. Ao utilizar RAID via software ou uma controladora fake-RAID, o processo de substituição do HD é inteiramente manual. Você precisa desligar o servidor, substituir o HD, ligar novamente o servidor, acessar a interface de gerenciamento e recriar o array, processo no qual a controladora reconstrói os dados usando os bits de paridade (no caso do RAID 5) ou copia os dados armazenados no segundo HD (no caso do RAID 1). Ou seja, os dados são preservados, mas é necessário desativar o servidor temporariamente, o que resulta em downtime.
Para permitir que o servidor continue funcionando continuamente, é necessário usar uma controladora dedicada, que ofereça suporte a hot-swap e seja capaz de reconstruir o array automaticamente após a substituição do HD defeituoso (recurso chamado de "automatic array rebuilding"), além de um gabinete que ofereça baias removíveis para os HDs. As três coisas somadas permitem que os HDs sejam substituídos rapidamente, sem desligar o servidor e sem interrupção no serviço. Outro recurso desejado é o "hot drive sparing", que permite utilizar um drive extra (hot-spare), usado automaticamente pela controladora em caso de falha de qualquer um dos drives do array, minimizando a possibilidade de perda de dados.
Continuando, 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.
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 (o que chamamos de Uptime) é 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.
Pra quem contrata planos de hospedagem, é importantíssimo saber qual será o Uptime do servidor que disponibilizará o site e será o grande responsável pelo seu desempenho, consequentemente pelo seu sucesso.