Host de reserva quente versus host de reserva a frio?

Question

Temos vários hosts nos quais temos um host hot spare idêntico, que é corrigido e atualizado, por isso é muito próximo de ter o mesmo software e configuração. Em caso de falha, o cabo de rede é comutado e o servidor DHCP é atualizado com o novo endereço MAC. Este é o melhor caso, como geralmente há um pouco mais que precisa ser modificado.

Eu sinto que é um desperdício de eletricidade ter um host hot spare e perda de tempo para mantê-lo, e como modificações de configuração são necessárias em caso de failover, eu gostaria de perguntar o seguinte:

Os hosts de hot spare são da velha guarda e há maneiras melhores agora?

Em vez de ter um host hot spare, faria sentido deixá-lo a frio, pegar os discos rígidos e colocá-los no host primário e alterar o RAID de 1 para 1 + 1. Em caso de falha, tudo o que eu precisaria fazer é trocar os cabos de rede, atualizar o servidor DHCP, pegar os discos rígidos e inseri-los no sistema de reserva a frio e ligar. O benefício, como eu vejo, é que os discos 2x2 estão sempre em sincronia, então apenas um host para manter e nenhuma alteração de configuração é necessária ao falhar.

É uma boa ideia?

    

Answer 1

Sobrique explica como a intervenção manual faz com que a solução proposta seja otimizada e ewwhite fala sobre a probabilidade de falha de vários componentes . Ambas as IMO são muito boas e devem ser strongmente consideradas.

Há, no entanto, uma questão que ninguém parece ter comentado até agora, o que me surpreende um pouco. Você propõe:

make [the current hot spare host] a cold spare, take the hard drives and put them in the primary host and change the RAID from 1 to 1+1.

Isso não protege você contra qualquer coisa que o sistema operacional faça no disco.

Ele realmente protege contra falhas no disco, o que, ao mover de espelhos (RAID 1) para espelhos de espelhos (RAID 1 + 1), reduz muito o impacto inicial. Você pode obter o mesmo resultado aumentando o número de discos em cada conjunto de espelhos (por exemplo, de RAID 1 de 2 discos para RAID 1 de 4 discos), além de provavelmente melhorar o desempenho de leitura durante operações comuns.

Bem, então, vamos ver algumas maneiras que isso pode falhar .

• Digamos que você esteja instalando atualizações do sistema, e algo faz com que o processo falhe no meio do caminho; talvez haja uma queda de energia e no-break , ou talvez você tenha um acidente esquisito e tenha atingido um erro de kernel incapacitante (o Linux é bastante confiável nos dias de hoje, mas ainda há o risco).
• Talvez uma atualização apresente um problema que você não detectou durante o teste (você testa as atualizações do sistema, certo?) exigindo um failover para o sistema secundário enquanto você corrige o primário
• Talvez um bug no código do sistema de arquivos cause gravações falsas e inválidas em disco.
• Talvez um administrador com dedo gordo (ou mesmo malicioso) use rm -rf ../* ou rm -rf /* em vez de rm -rf ./* .
• Talvez um bug em seu próprio software faça com que ele corrompa maciçamente o conteúdo do banco de dados.
• Talvez um vírus consiga se infiltrar.

Talvez, talvez, talvez ... (e tenho certeza de que há muitas outras maneiras de sua abordagem proposta falhar). No entanto, no final, isso se resume a sua vantagem "os dois conjuntos estão sempre em sincronia" ". Às vezes você não quer que eles estejam em perfeita sincronia.

Dependendo do que exatamente aconteceu, é quando você quer um modo de espera a quente ou a frio pronto para ser ativado ou desativado, ou backups adequados. De qualquer forma, os espelhos RAID de espelhos (ou espelhos RAID) não ajudam se o modo de falha envolver muito de alguma coisa além da falha do dispositivo de armazenamento de hardware (falha de disco). Algo como o raidzN do ZFS pode fazer um pouco melhor em alguns aspectos, mas não é melhor em outros.

Para mim, isso tornaria sua abordagem proposta irrepetível desde o início se a intenção for qualquer tipo de failover de desastre.

    

Answer 2

Sim, é um pouco velha escola. Hardware moderno não falha apenas com frequência. Concentre-se em tornar seus aplicativos mais altamente disponíveis (nem sempre possíveis) ou nos itens necessários para tornar seus hosts individuais mais resilientes ...

Para hosts:

• Compre melhor hardware.
• Verifique se você tem contratos de suporte.
• REGISTRAR os contratos de suporte dos seus servidores (as peças de reposição são armazenadas localmente com base nos dados de registro!)
• Use fontes de alimentação redundantes, RAID (hardware?), ventiladores redundantes.
• Se o servidor não for capaz de acomodar os recursos redundantes acima, mantenha um chassi sobressalente ou componentes à mão para poder se auto-reparar em caso de falha.

Em ordem decrescente de frequência de falha, eu vejo: discos, RAM, fontes de alimentação, ventiladores com mais freqüência ... Às vezes, placa de sistema ou CPU. Mas esses dois últimos são onde o seu contrato de suporte deve entrar em vigor.

    

Answer 3

É bastante ineficiente - não apenas por causa da dependência da intervenção manual para fazer a troca.

Eu trabalhei em locais que funcionam em um site de DR quente - literalmente, servidores idênticos ao primário, prontos para serem usados instantaneamente. No entanto, a transição para DR é um processo automatizado - não estamos falando de cabeamento, de um pouco de manipulação e de um interruptor, mas um processo ao pressionar o botão inverte tudo de um site para outro.

Essa abordagem é repugnantemente cara, mas é uma decisão de negócios - risco aceitável versus o dinheiro necessário para atingir o objetivo. Como regra, há uma curva exponencial no objetivo do tempo de recuperação - quanto mais próximo do zero, mais custa.

Mas é sobre isso que a sua pergunta é realmente. Qual é seu objetivo de tempo de recuperação e qual é a maneira mais eficaz de alcançá-lo. Esperar por um servidor para inicializar levará alguns minutos. Quanto tempo leva para alguém fazer o ajuste e as 'tarefas de recuperação' quando ele sai às 4 da manhã?

E quanto tempo é uma interrupção aceitável?

Eu sugeriria que, se você está fazendo uma "recuperação acelerada", quer pensar em clustering. Você pode ser bastante barato em clustering com bom uso de VMWare - 'failover' para uma VM - mesmo a partir de um físico - significa que você não está executando hardware redundante. (Bem, N + 1 em vez de 2N).

Se o seu RTO for longo o suficiente, desligue a caixa. Você pode achar que o RTO é suficiente para uma reconstrução a frio do backup.

    

Answer 4

O fato de ser a velha escola não faz necessariamente do uso de um hot spare uma má ideia.

Sua principal preocupação deve ser a lógica, quais são os riscos que você corre e como a execução de um hot spare os atenua. Porque na minha percepção, o seu hot spare só atende a falhas de hardware, o que não é incomum, nem o único risco operacional que você corre, nem o mais provável. A segunda preocupação é que as estratégias alternativas proporcionem mais redução de risco ou economias significativas.

A execução de um hot spare com várias etapas manuais de failover demorará muito e provavelmente ocorrerá errado, mas também pareço um failover automatizado com suítes de cluster de alta disponibilidade se transformando em grandes f * cks de cluster.

Outra coisa é que a espera a quente ou a frio no mesmo local não fornece continuidade de negócios em caso de desastre local.

    

Answer 5

O conceito de ter um sobressalente quente ou mesmo frio depende como as aplicações são construídas em primeiro lugar.

O que quero dizer é que, se o aplicativo foi construído de tal forma que a carga de dados e serviços seja distribuída por várias máquinas, o conceito de uma única máquina desligar o sistema deve desaparecer. Nessa situação você não precisa de um hot spare. Em vez disso, você precisa de excesso de capacidade suficiente para lidar quando uma máquina / componente individual morre.

Por exemplo, um aplicativo da Web padrão geralmente requer um servidor da Web e um servidor de banco de dados. Para os servidores da web, basta carregar o saldo 2 ou mais. Se um morre, não é nada demais. Geralmente, o banco de dados é mais difícil, pois ele deve ser arquitetado para ser multi-master com todos os dados sincronizados entre as máquinas participantes. Então, em vez de um único servidor de banco de dados, você acaba com 2 (ou mais) que atendem às suas necessidades de dados. Grandes prestadores de serviços, como Google, Amazon, Facebook, etc, seguiram esse caminho. Há mais custo inicial em tempo de desenvolvimento, mas paga dividendos se você precisar se expandir.

Agora, se o seu aplicativo não estiver estruturado de tal maneira ou se for simplesmente proibitivo para o aplicativo retro, então sim, você provavelmente precisará de um hot spare.