Host de reposição quente vs host de reposição frio?

Temos vários hosts nos quais temos um host hot spare idêntico, que é corrigido e atualizado, portanto é muito próximo do 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, pois geralmente há um pouco mais que precisa de modificação.

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

Os hot spare hosts são antigos e existem maneiras melhores agora?

Em vez de ter um host sobressalente a quente, faria sentido torná-lo um sobressalente a frio, pegue os discos rígidos e os coloque no host primário e altere o RAID de 1 para 1 + 1. Em caso de falha, tudo o que eu teria que fazer é trocar os cabos de rede, atualizar o servidor DHCP, pegar os discos rígidos e inseri-los na bateria sobressalente fria e ligar. O benefício, a meu ver, é que os discos 2x2 estão sempre sincronizados, portanto, apenas um host deve ser mantido e nenhuma alteração na configuração é necessária ao realizar o failover.

Essa é uma boa ideia?

Sobrique explica como a intervenção manual faz com que sua solução proposta seja ótima e o ewwhite fala sobre a probabilidade de falha de vários componentes . Os dois membros da OMI fazem pontos muito bons e devem ser fortemente considerados.

No entanto, há um problema que ninguém parece ter comentado até agora, o que me surpreende um pouco. Você propõe:

torne [o atual hot spare atual] um cold poupe, pegue os discos rígidos e coloque-os no host principal e altere o RAID de 1 para 1 + 1.

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

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

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

• Digamos que você esteja instalando atualizações do sistema, e algo causa uma falha no processo até a metade; talvez haja uma falha no fornecimento de energia e no no-break , ou talvez você tenha um acidente estranho e tenha atingido um bug no kernel (o Linux é bastante confiável hoje em dia, mas ainda existe o risco).
• Talvez uma atualização introduza um problema que você não detectou durante o teste (você faz 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 no disco.
• Talvez um administrador gordo (ou até mal-intencionado) faça rm -rf ../*ou rm -rf /*não rm -rf ./*.
• Talvez um bug no seu próprio software faça com que ele danifique massivamente 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 pelas quais sua abordagem proposta pode falhar.) No entanto, no final, tudo se resume à sua "vantagem" dos "dois conjuntos estão sempre sincronizados". Às vezes você não quer que eles estejam perfeitamente sincronizados.

Dependendo do que exatamente aconteceu, é quando você deseja um modo de espera quente ou frio pronto para ser ligado e alternado ou backups adequados. De qualquer forma, os espelhos RAID dos espelhos (ou espelhos RAID) não ajudam se o modo de falha envolve muito mais do que a falha do dispositivo de armazenamento de hardware (falha no disco). Algo como o raidzN do ZFS provavelmente pode se sair um pouco melhor em alguns aspectos, mas nem um pouco melhor em outros.

Para mim, isso faria com que sua abordagem proposta não fosse possível desde o início, se a intenção for algum tipo de failover de desastre.

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

Para hosts:

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

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

É bastante ineficiente - principalmente devido à dependência da intervenção manual para fazer a troca.

Eu trabalhei em locais que executam um site de DR quente - literalmente, servidores idênticos ao primário, prontos para serem instalados instantaneamente. No entanto, a alternância de DR é um processo automatizado - não estamos falando de cabeamento, um pouco de mexer e de alternar, mas um processo quando pressionamos o botão inverte tudo de um site para outro.

Essa abordagem é extremamente cara, mas é uma decisão comercial - 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 de zero ele fica, mais ele custa.

Mas é disso que se trata a sua pergunta. Qual é o seu objetivo de tempo de recuperação e qual é a maneira mais eficaz de alcançá-lo. Aguardar a inicialização de um servidor levará alguns minutos. Quanto tempo leva alguém para fazer o ajuste e as 'tarefas de recuperação' quando ele aparece às 4h?

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

Eu sugeriria que, se você está fazendo uma "recuperação a quente", deseja pensar em cluster. Você pode ser bastante barato em cluster com bom uso do VMWare - 'failover' para uma VM - mesmo física - significa que você não está executando um 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.

O fato de ser uma escola antiga não necessariamente torna uma má idéia o uso de um hot spare.

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 mitiga. Porque, na minha percepção, seu hot spare apenas trata de 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 estratégias alternativas proporcionem mais redução de risco ou economia significativa.

A execução de um hot spare com várias etapas de failover manual levará muito tempo e provavelmente dará errado, mas também pareço um failover automatizado, com os conjuntos de clusters 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 oferece continuidade aos negócios em caso de desastre local.

O conceito de ter uma reposição quente ou até fria depende de como os aplicativos são construídos.

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

Por exemplo, um aplicativo Web padrão geralmente requer um servidor Web e um servidor de banco de dados. Para os servidores web, basta carregar o equilíbrio 2 ou mais. Se alguém morre, nada demais. O banco de dados é geralmente mais difícil, pois precisa ser arquitetado para ser multimestre com todos os dados sincronizados nas máquinas participantes. Portanto, em vez de um único servidor de banco de dados, você acaba com 2 (ou mais) que atendem às suas necessidades de dados. Grandes provedores de serviços como Google, Amazon, Facebook etc. seguiram esse caminho. Há mais custos iniciais no tempo de desenvolvimento, mas paga dividendos se você precisar expandir.

Agora, se seu aplicativo não estiver estruturado dessa maneira ou se for simplesmente proibitivo ajustar o aplicativo de forma retroativa, sim, você provavelmente desejará um hot spare.