Quando o custo da redundância é maior, então o custo de ficar inativo enquanto o que está quebrado está sendo substituído, é para muita redundância.
O padrão da indústria quando se trata de redundância é bastante alto, para dizer o mínimo. Para ilustrar meu ponto, aqui está minha configuração atual (estou executando um serviço financeiro).
Cada servidor tem uma matriz RAID no caso de algo dar errado em um disco rígido
... e caso algo dê errado no servidor, ele será espelhado por outro servidor idêntico de reserva
... e o servidor não pode diminuir ao mesmo tempo, porque eu tenho energia redundante e conectividade de rede redundante, etc.
... e meu próprio centro de hospedagem tem duas conexões de eletricidade para dois provedores de energia diferentes, e conectividade de rede redundante e banheiros redundantes no caso de os dois guardas de segurança (desculpe, quatro) precisarem usá-lo ao mesmo tempo
... e no caso de algo dar errado de qualquer maneira (uma bomba nuclear não pode pensar em mais nada), eu tenho outra instalação de hospedagem idêntica em outro país com a mesma configuração.
Em outras palavras, sinto que poderia hospedar um laptop barato no apartamento da minha mãe, e os problemas humanos / de software ainda seriam meu maior risco.
Claro, há outras coisas a serem levadas em consideração, como:
Mas ainda assim, a hospedagem de dois servidores em dois datacenters diferentes (sem servidores sobressalentes extras nem o dobro de equipamentos de rede além do fornecido pela minha instalação de hospedagem) me forneceria a escalabilidade e a segurança física de que preciso.
Eu sinto que estamos chegando a um ponto em que a redundância é apenas uma ferramenta de comunicação. Honestamente, qual é a diferença entre um tempo de atividade de 99,999% e um tempo de atividade de 99,9999% quando você sabe que ficará 1% abaixo do tempo devido a erros de software?
Quão longe você empurra sua loucura de redundância?
Quando o custo da redundância é maior, então o custo de ficar inativo enquanto o que está quebrado está sendo substituído, é para muita redundância.
É tudo sobre o gerenciamento de risco. Mesmo com 2x tudo, você ainda pode ter tempo de inatividade devido a problemas imprevistos.
por exemplo. Meu provedor de hospedagem tem conexões duplas e redundantes para a Internet upstream. Então, no dia em que um de seus cabos foi cortado por alguns empreiteiros, seu fornecedor de upstream retirou o outro para alguma manutenção. E não só isso, porque todos os telefones eram SIP, ninguém podia ligar para dizer que não havia conectividade e eles não perceberam que havia um problema por muito tempo.
Agora, esse foi um em um milhão de tentativas, e isso poderia ter sido evitado adicionando mais camadas de redundância ou supervisão de gerenciamento ... mas a chance de isso acontecer era tão pequena que você nunca pensaria que haveria um problema, então não valeria o custo de impedir que isso acontecesse.
Outro exemplo: implementamos o espelhamento do SQL Server em uma sala de controle do Ambulance 999, os bancos de dados espelhados deveriam significar que não haveria nenhum problema ... exceto que encontramos um bug no SQLServer que congelou o banco de dados principal e impediu que ele falhasse espelho. Portanto, embora tenhamos feito o possível para garantir o tempo de atividade contínuo, ainda tivemos que transferir para o calltaking manual enquanto o problema do DB foi resolvido. Nesse caso, tivemos a melhor solução que poderíamos implementar de forma razoável e um plano de fallback caso a 'melhor solução' falhasse. Tentar garantir uma garantia total de 100% de tempo de atividade para a 'melhor solução' simplesmente não teria sido eficaz em termos de custo, e provavelmente ainda não nos daria 100% de garantia.
Novamente, outra história: temos uma rede de servidores replicados do Active Directory em toda a Europa, com fallback em caso de falha em qualquer país. Assim, quando um determinado administrador acidentalmente excluiu alguns registros demais, a solução era parar o servidor e permitir que as pessoas se autenticassem no próximo país. Apenas a replicação chegou lá primeiro e os registros excluídos começaram a ser excluídos dos outros servidores também .... demorou uma semana, com a ajuda de especialistas da Microsoft para resolver as coisas completamente.
Então - tudo depende do risco / custo. Você decide quanto risco está disposto a aceitar e custa. Ele chega rapidamente a um ponto em que reduzir o risco custa ainda mais, nesse ponto você deve encontrar estratégias alternativas para lidar com o tempo de inatividade quando acontecer.
Você está fazendo o que eu faço - não acho nada maluco.
... and in case something goes wrong anyway (a nuclear nuke? can't think of anything else), I've got another identical hosting facility in another country with the exact same setup.
Como os outros notaram: isso é simplesmente um caso de negócios. O nível de redundância necessário é ditado diretamente pelos requisitos e expectativas de seus clientes / usuários. Se eles pagam e esperam uptime na região de cinco-9s, então você precisa fornecer isso. Se não o fizerem, então você deve abordar isso como uma estratégia de negócios.
However, if I try to guesstimate the probability of another problem (software or human), I think it's several order of magnitudes higher than that.
Resposta simples: Isso tem que ser tratado pelo procedimento. Não por redundância física.
Se um erro humano estiver causando o tempo de inatividade, você precisará reforçar a verificação de erros executada sempre que os humanos intervirem. Isso provavelmente significa que todas as emendas da plataforma são emitidas como solicitações de alteração e assinadas por uma pessoa secundária. Ou que essas solicitações de mudança contenham mais detalhes sobre as tarefas a serem realizadas e nenhum desvio possa ser feito. Ou que os funcionários simplesmente precisam de mais treinamento sobre como trabalhar com cuidado em ambientes de produção.
Se um erro de software estiver causando tempo de inatividade, talvez seja necessário fortalecer o procedimento de teste. Assegure-se de que você tenha um bom ambiente de preparação, que pode ser inteiramente virtualizado para reduzir os requisitos de hardware, mas que ainda corresponda o máximo possível aos seus ambientes de produção. Quaisquer alterações de software devem ser testadas no ambiente de preparação por um período de tempo especificado antes de serem implementadas para implantação geral.
Todo design e arquitetura deve ser orientado por requisitos. Uma boa engenharia de sistemas exige definir as restrições do projeto e implementar uma solução que atenda a isso. Se você tem um SLA com seus clientes que exige um .99999, sua solução de redundância N + N deve ser responsável por todas as LRU (unidades substituíveis em linha) que podem falhar. O planejamento de RAID, PS e COOP deve explicar isso. Além disso, o seu SLA com fornecedores deve ser do tipo de tempo de resposta de 4 horas ou conta para um grande número de peças no local.
Disponibilidade (Ao daqui de fora) é esse estudo. Se você está fazendo todas essas coisas, porque parece ser a coisa certa a fazer, então você está perdendo seu tempo e dinheiro de seus clientes. Se pressionado, todos desejariam 5x9, mas poucos podem pagar por isso. Tenha uma discussão honesta sobre a disponibilidade dos dados e do sistema na perspectiva de custo.
As perguntas e respostas apresentadas até agora não levam em conta os requisitos. A cadeia assume que a redundância N + N com hardware e políticas é a chave. Em vez disso, eu diria que os requisitos dos seus clientes e do SLA conduzam o design. Talvez o apartamento da sua mãe e o seu antigo laptop sejam suficientes.
Nós, nerds, às vezes, procuramos por um problema apenas para que possamos implementar uma solução interessante.
Quanto custa a sua reputação? Se o seu software falhar, você fez o melhor para proteger os dados do cliente, fornecendo a melhor redundância de hardware / cluster. Se você chegou ao seu melhor ponto, então é hora de colocar mais orçamento no seu gerenciamento de mudança / qa.
Se você tem o orçamento adequado e sua hospedagem é importante para você (como seria para uma instituição financeira), você deve continuar. Eu notei que você não fala sobre seus backups ... talvez algumas melhorias possam ser feitas lá? Eu nunca vi nenhuma configuração que foi tão incrível que eu senti que não precisava de trabalho adicional (às vezes isso é apenas a fixação de procedimentos).
Eu faria o cálculo com entradas:
Você pode calcular o risco financeiro:
potencial_outage_cost = hourly_outage_cost * recovery_time * outage_probability
Em seguida, basta ponderar o custo de redundância em relação a esse custo.
Espero não precisar lembrá-lo de que há vários tipos de interrupções, como:
disco com falha (muito provável, muito fatal, mas a redundância é barata)
falha na fonte de alimentação
servidor com falha
falha na conexão de rede
falha no uplink ...
Em qualquer caso, faça a análise de risco primeiro, pois ela fornece a linha de base.
... and in case something goes wrong anyway (a nuclear nuke? can't think of anything else),
O incêndio no data center pode desativá-lo (não aconteceu com um DC compartilhado no ano passado?), embora exista muita redundância dentro do centro.
Dois CDs podem ajudar, mas até mesmo eventos únicos podem levar os dois para fora. Por exemplo, no tornado aliado nos EUA, duas CDs próximas o suficiente para fibra escura poderiam ser facilmente atingidas por tornados do mesmo sistema super-celular. Esse risco pode ser mitigado por um posicionamento geográfico relativo cuidadoso (comece verificando rastros históricos de tempestades), mas não completamente eliminado.
I've got another identical hosting facility in another country with the exact same setup.
E como outros já disseram, tudo se resume ao custo da indisponibilidade versus o custo da redundância, e muitos dos custos da indisponibilidade são intangíveis (perda da confiança do cliente).
Apenas fique feliz por ter o orçamento para fazer as coisas da maneira certa.
Ao mesmo tempo, seus procedimentos para atualizações de software provavelmente poderiam usar algum trabalho agora.
Você está certo sobre a parte "hardware" da configuração. Fornecer HA por geo-redundância tornará muito improvável que seus serviços estejam inativos por causa de hardware com falha.
In other words, I feel like I could host a cheap laptop in my mother's flat, and the human/software problems would still be my higher risk.
Eu discordo totalmente. Você está perdendo o ponto crucial de testar e liberar o gerenciamento. Além disso, existem estratégias que garantirão que um software nunca permitirá que seu serviço seja prejudicado para todos os clientes.
Algumas empresas chegam a não apenas usar uma única marca de servidor apenas porque temem que um bug no Apache possa ser acionado em todo o lugar de uma só vez, portanto, eles implementam vários servidores Web.
No que diz respeito aos testes: tem de haver um certo nível de confiança, mesmo com um sistema com acesso completo a todas as fontes que você não pode ter recursos para testar tudo (ou se os testes não forem suficientes - provar formalmente a exatidão).
O ponto é que você deve ter testes antes do seu software entrar em produção. Isso é algo como:
No que diz respeito ao gerenciamento de versões: se você não quiser que um bug desconhecido na nova versão acione o tempo de inatividade: não libere a nova versão em todos os lugares. Apenas exponha uma pequena fração de clientes à nova versão. Se funcionar bem, migre mais alguns clientes (algo como 5%, 20%, 50%, 100%). Note que você pode ter um ciclo de rolagem aqui:
Portanto, você não tem muito tempo entre os ciclos de lançamento se sua definição for permitir que ele seja executado por duas semanas em cada lote de implantação.
Descobri que o problema não está em criar um sistema desse tipo, mas em vender isso para o gerenciamento. Porque vai custar muito tempo e dinheiro para fazê-lo (pelo menos quando iniciar) uma vez que o processo é estabelecido, acho ainda mais barato. Ter lançamentos contínuos também contribui para um perfeito fallback, já que o software (digamos que a versão 5 do último exemplo está completamente quebrado) só precisa ter um mecanismo para trabalhar com dados antigos e novos, o que significa novamente:
How far do you push your redundancy crazyness ?
Na medida em que a administração está disposta a pagar, se achar que vale a pena e considerar o risco de uma interrupção ser de um custo muito maior do que o custo de (algum nível aleatório) de alta disponibilidade.
Tags hardware redundancy