Uma Melhores Práticas para Resiliência

Este tópico descreve as melhores práticas para manter a operação contínua caso uma única máquina virtual (VM) de uma instância de forma Corporativa do Oracle Blockchain Platform seja colocada off-line para manutenção ou falhe inesperadamente.

As etapas a seguir só se aplicam a instâncias do Oracle Blockchain Platform com base na forma Corporativa (não na forma Padrão). Além disso, essa orientação se aplica apenas aos seguintes modelos de implantação:
  • Uma única organização fundadora
  • Um fundador com uma ou mais organizações participantes
Como as instâncias do Oracle Blockchain Platform com base na forma Padrão executam todos os componentes (pares, solicitantes e serviços de plataforma) em uma única VM, toda a instância se torna indisponível se uma VM falhar ou precisar ser interrompida para manutenção. Não há isolamento entre domínios de disponibilidade ou domínios de falha. Não use instâncias baseadas na forma Padrão para ambientes de produção.

Em vez disso, use instâncias com base na forma do Enterprise para ambientes de produção. Essas instâncias fornecem dimensionamento independente de componentes do Hyperledger Fabric e configurações de maior capacidade. As instâncias de forma empresarial distribuem automaticamente pares, solicitantes e componentes da plataforma entre domínios de disponibilidade e domínios de falha para fornecer isolamento de falhas no nível da infraestrutura. Para aproveitar esse comportamento e garantir alta disponibilidade, use as melhores práticas descritas nas seções a seguir.

Políticas de Endosso

Para uma rede com uma única organização (fundadora), use políticas de endosso que permitam qualquer peer disponível para endossar transações, como OR('Founder.member') ou OutOf(1, 'Founder.member'). Implante pelo menos dois pares para a organização fundadora.

Para uma rede com um fundador e uma organização participante, geralmente você pode usar a seguinte política: OutOf(1, 'Founder.member', 'Participant1.member'). Para uma configuração mais rígida, somente se houver redundância, você poderá usar OutOf(2, 'Founder.member', 'Participant1.member'). Evite políticas rigorosas, como AND('Founder.member', 'Participant1.member'), a menos que ambas as organizações tenham redundância de pares suficiente.

Para obter mais informações, consulte Especificar uma Política de Endosso.

Implantação de Pares

Implante pelo menos dois pares por organização. O Oracle Blockchain Platform distribui automaticamente pares entre domínios de disponibilidade e domínios de falha para garantir que pelo menos um par permaneça disponível após uma falha de VM.

Coleções de Dados Privados

Se você usar coletas de dados privadas, defina o valor Pares Obrigatórios (requiredPeerCount) como um ou mais e defina o valor Contagem Máxima de Pares (maxPeerCount) como dois ou mais na definição da coleta de dados privada. Certifique-se de que pelo menos dois pares sejam membros de cada coleta de dados privada e que os dados privados sejam confirmados em pelo menos dois pares. O valor Pares Obrigatórios é o número mínimo de pares (excluindo o par de endosso) que devem receber com êxito os dados privados antes que a proposta de transação seja considerada concluída.

Para coletas de dados privadas entre organizações, configure a contagem de pares necessária para ser maior que o número de pares de uma única organização e garanta a distribuição entre várias organizações e VMs.

Para obter mais informações, consulte Adicionar Coletas de Dados Privados.

Serviço de pedidos de jangada

Use o serviço de ordenação Raft de três nós padrão. O Oracle Blockchain Platform distribui os solicitantes entre domínios de disponibilidade e domínios de falha, o que permite que o serviço de solicitação lide com uma falha de nó único.

Pares de âncora

Em redes com várias organizações, configure pelo menos um ponto de ancoragem por organização. Para maior resiliência, configure pelo menos dois pontos de ancoragem por organização. Os pares de âncora só são necessários quando mais de uma instância da organização do Oracle Blockchain Platform existe na rede, pois eles permitem comunicação baseada em fofocas e descoberta de pares em diferentes organizações.

Para obter mais informações, consulte Adicionar um Pare de Âncora.

Implantação de Chaincode

Para garantir a continuidade se um par ficar indisponível, instale e aprove chaincode em pelo menos dois pares por organização. Você pode distribuir essas implantações entre instâncias do Oracle Blockchain Platform em uma rede se seus requisitos de privacidade permitirem isso.

Conexão com o cliente

Configure aplicativos cliente para nunca travar para pares específicos. Em vez disso, permita que a biblioteca do cliente subjacente lide com a seleção de pares.

Banco de dados de estado de fallback

O banco de dados de estado é armazenado em cada par para todos os canais aos quais o par está conectado. Se uma VM falhar, o banco de dados de estado local nesse par ficará indisponível até que o par seja restaurado. O Oracle Blockchain Platform suporta um modelo de banco de dados de estado híbrido, no qual um Oracle Database externo atua como um banco de dados de estado de fallback (secundário). Quando o banco de dados de estado de fallback está ativado, os dados de estado são persistidos fora da VM de mesmo nível em um banco de dados que pode assumir o controle como o banco de dados de estado principal, conforme necessário, o que melhora a durabilidade e a recuperação.

Siga as etapas abaixo para usar essa função para melhorar a resiliência.
  • Ativar o banco de dados de estado de fallback para cargas de trabalho de produção ou cargas de trabalho críticas
  • Implante o Oracle Database independentemente das VMs de mesmo nível.
  • Configurar o Oracle Database para alta disponibilidade.
Ao executar essas etapas, você pode garantir que os dados de estado não estejam vinculados ao ciclo de vida de uma única VM. O banco de dados de estado de fallback funciona em complemento à redundância de pares para cenários em que uma única VM falha.

Para obter mais informações, consulte Criar o Banco de Dados de Estado de Fallback.