Replicaçã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 ou 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.

Verificações iniciais

1. 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.

2. 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;

3. 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;

   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-sync pode ser executado 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);

4. 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.