Simplicidade vs Redundância

Question

Suponha que você tenha a tarefa de executar um conjunto de serviços da web de missão crítica com um tempo de ativação de 99,5%

Para conseguir isso, você tem dois clusters de hardware idênticos em dois data centers totalmente separados, com diferentes provedores de largura de banda, etc.

Na parte superior de cada rack, é preciso haver algum hardware de topo de rack (equipamentos de comutação e firewall).

Sua configuração de software é tal que, com a intervenção humana, é muito fácil redirecionar todos os serviços de um dos datacenters para o outro caso um dos clusters seja desconectado. Diga que isso levaria cerca de 15 minutos.

A questão é esta: você gastaria 8k extras por centro de dados para não ter nenhum ponto único de falha no equipamento de rack (hot fail over switching e firewalls). Como referência, cada rack de equipamento tem cerca de 50k em servidores.

A configuração redundante é muito mais complexa, tem mais modos de falha e tem um custo garantido em termos de preço de compra inicial e também no tempo gasto na manutenção e na solução de problemas da configuração mais complicada.

Além disso, temos executado a configuração (redundante) há mais de 8 anos e nunca uma (bater na madeira) teve uma falha no topo do equipamento do rack. Substituímos todas as nossas coisas em 3 anos em ciclos de serviço.

A desvantagem do modelo de ponto único de falha é que, se perdermos um switch ou um firewall, todo o data center ficará inativo. Além disso, um humano deve lançar um switch para rotear os serviços com falha para o outro centro de dados (por várias razões, não há maneira confiável de fazer isso automaticamente)

Eu suspeito que, porque ele usa menos hardware e é mais simples , a opção de ponto único de falha resultará em maior tempo de atividade no mundo real. Minha experiência é que as falhas de hardware ocorrem com muito menos frequência do que as que as pessoas fazem e os switches / firewalls (sem unidades de disco giratórias e SOs seguros etc.) raramente falham ...

O que a comunidade de falhas de servidor pensa?

    

Answer 1

Não importa o que você faça, o hardware falhará. As pessoas cometem erros.

Sem sombra de dúvida, eu atualizaria cada rack para ter vários de tudo.

Você diz que tem 50k de servidores em cada rack, mas apenas um único switch os conecta ao mundo externo? Também um único roteador e firewall único eu presumo. Não tenho certeza se poderia lidar pessoalmente com isso se eu fosse o Sysadmin. Eu exigiria vários provedores de trânsito diversos, um par de roteadores de borda no modo HA / HSRP, um par de firewalls HA, pelo menos dois switches, e todos os servidores com duas nics, teriam um switch diferente em cada NIC.

STP lida com a falha de um switch ou de uma porta, isso é automagic. A falha de um roteador é tratada pelo software HA no par. Ditto firewalls. Perdendo um datacenter e trocando o tráfego entre eles, estou assumindo que você usa alguma forma de dispositivo GSLB?

Eu mudei completamente sua idéia, mas o problema é, digamos que o DC1 fique offline devido a um grande incidente, isso levará dias ou semanas para voltar (fogo, inundação, ação de $ imaginary_deity) .. então você tem um falha do roteador no DC2. Este não é um cenário terrivelmente impossível. Toda a sua infraestrutura agora está inacessível na Internet, com base no que você nos informou.

Este é um dos modos de falha aceitáveis? Eu certamente não suportaria esse tipo de interrupção, quando é tão fácil (não barato) evitável.

Suponho que, se você fizer a avaliação de risco para esse tipo de interrupção e levar em consideração o negócio perdido que seu empregador sofreria, se o custo do upgrade for menor do que a perda de negócios por uma semana, então é um bom lidar.