Disponibilidade é do serviço completo
Um processo respondendo não significa que a operação consegue executar tarefas. O serviço depende de banco, filas, rede, identidade, adaptadores e equipamentos. Defina quais falhas o projeto precisa suportar e qual função deve permanecer disponível em cada uma. Alta disponibilidade não elimina paradas mecânicas ou todas as falhas comuns.
Estabeleça o tempo de recuperação aceitável e como medi-lo: detecção, decisão de troca, recuperação do estado e liberação operacional. Medir apenas o tempo de inicialização do processo omite parte importante da interrupção.
Uma autoridade para cada recurso
Em uma configuração com instâncias redundantes, apenas a instância autorizada deve comandar determinado equipamento. Se uma partição de rede deixar duas instâncias acreditando que são líderes, pode haver comandos conflitantes. O desenho precisa impedir que uma autoridade antiga continue atuando após a troca.
Esse bloqueio, frequentemente chamado fencing, deve alcançar a fronteira efetiva do comando. Uma eleição no banco não resolve o problema se o antigo líder ainda puder escrever diretamente no PLC. A solução concreta depende dos recursos da infraestrutura e do protocolo.
Estado antes da retomada
A nova instância precisa distinguir tarefa não enviada, aceita, em movimento e concluída com confirmação pendente. Replicar somente a lista de tarefas não é suficiente quando o estado do equipamento avançou durante a falha. A retomada deve consultar ou reconciliar a execução.
O trade-off entre replicação síncrona e assíncrona envolve latência e possibilidade de perda de dados recentes. O requisito deve declarar o que pode ser perdido e como isso será reconciliado fisicamente; nenhuma configuração deve ser descrita como perda zero sem evidência.
Exemplo de failover
A instância A envia o comando 88 e perde conectividade. B assume após invalidar a autoridade de A. Antes de reenviar 88, verifica a sequência reconhecida e a posição da carga. Se a evidência for ambígua, mantém a tarefa em reconciliação em vez de inventar uma conclusão.
Teste desligamento, isolamento de rede e perda de dependência separadamente. Registre tempo até serviço coerente, comandos duplicados e tarefas pendentes. Os critérios de disponibilidade do ABNET WCS devem ser definidos e comprovados para a arquitetura contratada.
Critérios para verificar no projeto
- Medir recuperação até a execução coerente, não apenas processo ativo.
- Isolar o líder e verificar que ele perde autoridade de comando.
- Reconciliar comandos em trânsito antes de retomar.
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.