HSMs Dinamo
Ask or search…
K
Links

Replicação

O suporte do fabricante pode ser necessário.

Sobre a camada de replicação

A Replicação 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. 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 Console Local ou Console Linha de Comando.
  2. 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 Console Local ou Console Linha de Comando;
  3. 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 Console Local ou Console Linha de Comando;
    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; Database 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 Database 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. 4.
    Checar se um ou mais HSMs do pool possuem um Pending Transaction (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 Replicação 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 Console Linha de Comando.
Last modified 9mo ago