Mantenha a simplicidade, se possível. Uma caixa é melhor que a maioria dos aplicativos de banco de dados, a menos que você tenha motivos específicos, como desempenho.
É muito menos provável que a falha de hardware reduza o tempo de inatividade do que algo interrompido devido a um erro de configuração. A configuração mais simples geralmente será compensada por ter menos modos de falha. Você pode descobrir que, na prática, você obtém um sistema mais confiável com apenas um servidor e um banco de dados replicado simples em uma máquina em espera.
Não faça um SLA mais restrito do que realmente precisa e não crie um sistema com complexidade adicional para obter um SLA não suportado por todos os aspectos do software, operações e hardware.
Uma visão ligeiramente diferente da confiabilidade de "cinco noves".
Sem dúvida, seu fornecedor reivindicará algumas estatísticas de confiabilidade impressionantes para o produto. Como um contador, aqui está um take 'nines' relacionando vários níveis de SLAs ao que é realmente necessário para alcançá-los na prática:
-
Dois noves (99%) se traduzem em um período de 24 horas de recuperação de desastres e podem ser relevantes para aplicativos como sistemas de data warehouse em que o sistema não suporta diretamente os processos operacionais. Este nível de serviço pode ser alcançado restaurando o sistema a partir de backups.
-
Três noves (99,9%) equivalem a uma janela de DR de 4 horas e são realmente tudo o que é necessário para a maioria dos aplicativos de linha de negócios. Esse tipo de estratégia de recuperação de desastres pode ser obtido com replicação de envio de logs simples e um servidor em espera. Muitas vezes, a simplicidade desse tipo de arquitetura significa que ela possui relativamente poucos modos de falha baseados em configuração e alcança uma confiabilidade consideravelmente melhor na prática. Há vários exemplos de aplicativos 4GL de dois níveis que atingem uptimes contínuos de meses ou anos com esse tipo de configuração.
-
Quatro noves (99,99%) podem ser visualizados como uma janela de DR por alguns minutos e precisam de uma arquitetura hot standby ou hot failover. Atingir esse tipo de SLA na prática é bastante difícil e normalmente requer um software projetado para isso. Ironicamente, a complexidade adicional das arquiteturas de N camadas agrupadas abre uma superfície muito mais ampla de modos de falha devido à má configuração ou deslizes no gerenciamento de mudanças.
Deve-se notar que erros de configuração e gerenciamento de mudanças ruins são as maiores causas de falhas. tempo de inatividade não programado nas operações do data center e têm muito mais probabilidade de causar uma interrupção não programada do que a falha de hardware em um servidor.
-
Cinco noves (99,999%) exigem não mais do que alguns segundos de tempo de inatividade não programado a cada ano. Esse tipo de SLA coloca você no domínio de hardware e software especializados criados para tolerância a falhas. A implementação desse tipo de SLA é dispendiosa, requer uma plataforma específica, como um mainframe e pessoas com habilidades especializadas que a maioria das empresas não possui internamente.
A maioria das pessoas que reivindicam 99,999% de SLAs estão cheias de merda, q.v. Microsoft, Accenture e Bolsa de Valores de Londres .