Una mejores prácticas para la resiliencia
En este tema se describen las mejores prácticas para mantener el funcionamiento continuo en caso de que una sola máquina virtual (VM) de una instancia de unidad de negocio de Oracle Blockchain Platform se desconecte para realizar el mantenimiento o falle inesperadamente.
- Una única organización fundadora
- Un fundador con una o más organizaciones participantes
En su lugar, utilice instancias basadas en la unidad Enterprise para entornos de producción. Esas instancias proporcionan una ampliación independiente de los componentes de Hyperledger Fabric y configuraciones de mayor capacidad. Las instancias de unidades empresariales distribuyen automáticamente peers, solicitantes y componentes de plataforma entre dominios de disponibilidad y dominios de errores para proporcionar aislamiento de errores de nivel de infraestructura. Para aprovechar este comportamiento y garantizar una alta disponibilidad, utilice las mejores prácticas descritas en las siguientes secciones.
Políticas de endoso
Para una red con una única organización (fundadora), utilice políticas de endoso que permitan que cualquier peer disponible respalde las transacciones, como OR('Founder.member') o OutOf(1, 'Founder.member'). Despliegue al menos dos peers para la organización fundadora.
Para una red con un fundador y una organización participante, normalmente puede utilizar la siguiente política: OutOf(1, 'Founder.member', 'Participant1.member'). Para una configuración más estricta, solo si existe redundancia, puede utilizar OutOf(2, 'Founder.member', 'Participant1.member'). Evite políticas estrictas, como AND('Founder.member', 'Participant1.member'), a menos que ambas organizaciones tengan suficiente redundancia entre iguales.
Para obtener más información, consulte Especificación de una política de aprobación.
Despliegue de peer
Despliegue al menos dos peers por organización. Oracle Blockchain Platform distribuye automáticamente peers entre los dominios de disponibilidad y los dominios de errores para garantizar que al menos un peer permanezca disponible después de un fallo de VM.
Recopilaciones de datos privadas
Si utiliza recopilaciones de datos privadas, defina el valor Peers Required (requiredPeerCount) en uno o más y defina el valor Max Peer Count (maxPeerCount) en dos o más en la definición de la recopilación de datos privada. Asegúrese de que al menos dos iguales son miembros de cada recopilación de datos privados y de que los datos privados se confirman en al menos dos iguales. El valor Peers Required (Peers necesarios) es el número mínimo de peers (excluyendo el peer endosante) que deben recibir correctamente los datos privados antes de que la propuesta de transacción se considere completa.
Para las recopilaciones de datos privadas entre organizaciones, configure el recuento de pares necesario para que sea mayor que el número de pares de una sola organización y garantice la distribución entre varias organizaciones y máquinas virtuales.
Para obtener más información, consulte Agregar recopilaciones de datos privadas.
Servicio de pedidos de balsa
Utilice el servicio de ordenación Raft de tres nodos por defecto. Oracle Blockchain Platform distribuye los solicitantes entre los dominios de disponibilidad y los dominios de errores, lo que permite al servicio de pedidos gestionar un fallo de un solo nodo.
Pares de anclaje
En redes con varias organizaciones, configure al menos un par de anclaje por organización. Para mejorar la resiliencia, configure al menos dos pares de anclaje por organización. Los pares de anclaje solo se necesitan cuando hay más de una instancia de organización de Oracle Blockchain Platform en la red, ya que permiten la comunicación basada en chismes y el descubrimiento de pares en diferentes organizaciones.
Para obtener más información, consulte Adición de un peer de anclaje.
Despliegue de código de cadena
Para garantizar la continuidad si un par deja de estar disponible, instale y apruebe el código de cadena en al menos dos pares por organización. Puede distribuir estos despliegues en las instancias de Oracle Blockchain Platform en una red si sus requisitos de privacidad lo permiten.
Conectividad de cliente
Configure las aplicaciones cliente para que nunca se bloqueen en pares específicos. En su lugar, permita que la biblioteca de cliente subyacente trate con la selección de pares.
Base de Datos de Estado de Reserva
La base de datos de estado se almacena en cada peer para todos los canales a los que se une el peer. Si falla una máquina virtual, la base de datos de estado local de ese par deja de estar disponible hasta que se restaure el par. Oracle Blockchain Platform admite un modelo de base de datos de estado híbrido, donde una Oracle Database externa actúa como base de datos de estado de reserva (secundaria). Cuando la base de datos de estado de reserva está activada, los datos de estado se mantienen fuera de la máquina virtual peer en una base de datos que puede asumir el control como base de datos de estado principal según sea necesario, lo que mejora la durabilidad y la recuperación.
- Activar la base de datos de estado de reserva para cargas de trabajo de producción o cargas de trabajo críticas
- Despliegue Oracle Database independientemente de las máquinas virtuales peer.
- Configure Oracle Database para alta disponibilidad.
Para obtener más información, consulte Creación de la base de datos de estado de reserva.