Duplicação e independência
Dois servidores ligados ao mesmo switch, armazenamento e alimentação continuam compartilhando falhas importantes. Liste os componentes necessários ao fluxo e desenhe quais dependências são comuns. Redundância só protege contra falhas cobertas por essa separação; não protege automaticamente contra erro de configuração ou corrupção replicada.
Uma matriz simples relaciona falha, impacto, mecanismo de detecção, componente sobrevivente e procedimento de retorno. Ela deve incluir rede, banco, filas, armazenamento, identidade e interface com equipamentos, não apenas a aplicação WCS.
Ativo-passivo e ativo-ativo
Ativo-passivo simplifica a autoridade de comando, mas exige demonstrar que a instância de reserva consegue assumir. Ativo-ativo pode distribuir recursos distintos, porém requer propriedade explícita de cada recurso e coordenação dos estados compartilhados. Executar duas cópias da mesma lógica não cria por si só uma solução correta.
Quorum e testemunhas podem ajudar a decidir quem permanece ativo. Ainda é necessário impedir comandos da instância que perdeu autoridade. Em partições, preservar consistência pode significar interromper parte do serviço; essa escolha deve estar prevista, e não surgir como surpresa no incidente.
Replicação não substitui backup
Um dado excluído indevidamente pode ser replicado para todas as cópias. Backup e restauração atendem a outro problema: recuperar um estado anterior confiável. Sua retenção e proteção devem considerar falhas administrativas e incidentes que atinjam o ambiente inteiro.
A configuração do sistema de reserva também precisa acompanhar mudanças. Divergência de adaptadores, certificados ou mapas de equipamentos pode aparecer somente no failover. Inclua validação de configuração no processo de manutenção.
Exemplo: perda do switch compartilhado
Duas instâncias permanecem ligadas, mas ambas perdem o caminho até os PLCs por dependerem do mesmo switch. Trocar de instância não restaura o serviço. A correção de arquitetura depende de um caminho alternativo suportado e testado, ou de aceitar explicitamente esse domínio de falha.
No ensaio, remova uma dependência por vez e observe a operação completa. Registre também o failback: o retorno ao componente original pode introduzir outra interrupção. A documentação deve dizer o que a redundância cobre, o que exige recuperação e como verificar a integridade final.
Critérios para verificar no projeto
- Identificar energia, rede e armazenamento compartilhados.
- Testar perda de quorum e prevenção de comandos concorrentes.
- Validar configuração da reserva e retorno após failover.
Os exemplos descrevem decisões de engenharia e cenários de teste. Interfaces, limites e recursos implantados são definidos no escopo de cada projeto.