Resolução de problemas no subsistema de replicação, antes do contato com o fabricante.

Observação: O suporte do fabricante pode ser necessário.

Sobre a camada de replicação

A Replicação (RL) do DINAMO é uma implementação de um sistema do tipo multi master síncrona, na qual todos os equipamentos de um pool aceitam requisições de alteração de dados (como criação/remoção de chaves, troca de senhas de usuários, etc). Qualquer dado modificado em um HSM é transmitido do node onde ocorreu a operação para todos os demais participantes, antes que uma transação distribuída seja finalmente confirmada.

A transmissão é efetuada através do conhecido protocolo two-phase commit (2PC), amplamente usado na indústria de bancos de dados. O 2PC possui algumas desvantagens, mas é popular na prática, apesar disso: é simples, eficiente, e fornece uma solução correta para o problema de consenso entre nodes. Infelizmente, é um protocolo que permite o bloqueio das operações distribuídas.

Consistência é uma característica intrínseca ao HSM. Nenhuma lógica/infraestrutura cliente é necessária para o tratamento de resultados operacionais não-determinísticos. De fato, se a RL devolve um dos códigos documentados de retorno, alguns passos podem ser seguidos para a resolução de problemas. Na maior parte do tempo, esses passos são suficientes para revelar as questões subjacentes; em todo caso, se a intervenção do fabricante se fizer realmente necessária, dados de depuração permitirão uma prestação de suporte mais ágil.

Em seu esforço de operação consistente, a RL foi projetada para detectar e evitar cenários do tipo split-brain. Nesse caso, o Sync-Point (SP) foi concebido como uma forma de codificar todo o estado de um HSM em um número único. Com apenas uma validação em nível de protocolo, o DINAMO é capaz de saber se seus pares compartilham um mesmo estado.

Resolução de problemas no subsistema de replicação, antes do contato com o fabricante

Como observado acima, todos os HSMs em um pool têm que se comunicar, para uma operação distribuída adequada; checar se todos os equipamentos possuem os endereços TCP/IP dos demais HSMs em seus caches de nodes; ex.: seja um pool composto de 2 HSMs, A e B: A deve ter o IP de B registrado, e, da mesma forma, B tem que possuir o IP de A (não importa se os endereços são obtidos via auto-discovery, ou se são cadastrados manualmente). A checagem pode ser feita via as consoles local ou remota;
Verificar se os HSMs conseguem se comunicar através dos endereços identificados em [1.]. O teste de comunicação pode ser feito via as consoles local ou remota;
Checar se todos os equipamentos de um mesmo pool compartilham o mesmo sync-point (SP); o SP é um número hexadecimal (ex.: CA110F4B3A0662A2; um pequeno número de verificação correspondente como 5058 também estará disponível, facilitando a execução deste passo).A checagem de SP pode ser feito via as consoles local ou remota;

Atenção
Caso [3.] não se verifique, deve ser garantida a sincronização do(s) equipamento(s) divergente(s), usando uma imagem oficial para o pool; live-syncs podem ser executados para esse fim, sem interrupção de serviços; backups/restores também podem ser efetuados, com a desvantagem de serem processos offline, que demandam ajustes nas configurações de rede; o live-sync é o método recomendado (depois da sincronização através dele, nodes pré-existentes têm seus caches com endereços IP sensibilizados como parte do procedimento, e começam a operar com os novos HSMs automaticamente);
Checar se um ou mais HSMs do pool possuem um log de transação pendente (PTL); como destacado na discussão sobre 2PC, operações distribuídas de escrita (ex.: criação de chaves) podem ser bloqueadas se uma transação prévia ainda está em andamento; normalmente - baseado na própria natureza operacional assíncrona da RL - transações pendentes são resolvidas automaticamente pelo replication-manager, em questão de minutos; cada PTL carrega toda a informação necessária para commits; se um dos nodes que participam da operação distribuída não pode ser alcançado (falha de hardware, rede, etc), o pool permanece bloqueado; mensagens administrativas de node-down podem ser usadas para informar o pool que um ou mais equipamentos não mais estarão em operação, permitindo que PTLs dependentes de HSMs indisponíveis possam ser comitados (e o pool, finalmente, desbloqueado). A operação de node-down só pode ser feita através da console remota.