A Best Practices for Resilience

This topic outlines best practices to maintain continued operation in the event that a single virtual machine (VM) of an Enterprise shape instance of Oracle Blockchain Platform is taken offline for maintenance or fails unexpectedly.

The following steps apply only to instances of Oracle Blockchain Platform based on the Enterprise shape (not the Standard shape). Additionally, this guidance applies only to the following deployment models:
  • A single founder organization
  • A founder with one or more participant organizations
Because instances of Oracle Blockchain Platform based on the Standard shape run all components (peers, orderers, and platform services) on a single VM, the entire instance becomes unavailable if a VM fails or must be stopped for maintenance. There is no isolation across availability domains or fault domains. Do not use instances based on the Standard shape for production environments.

Instead, use instances based on the Enterprise shape for production environments. Those instances provide independent scaling of Hyperledger Fabric components and higher capacity configurations. Enterprise shape instances automatically distribute peers, orderers, and platform components across availability domains and fault domains to provide infrastructure-level fault isolation. To take advantage of this behavior and to ensure high availability, use the best practices described in the following sections.

Endorsement Policies

For a network with a single (founder) organization, use endorsement policies that allow any available peer to endorse transactions, such as OR('Founder.member') or OutOf(1, 'Founder.member'). Deploy at least two peers for the founder organization.

For a network with a founder and one participant organization, typically you can use the following policy: OutOf(1, 'Founder.member', 'Participant1.member'). For a stricter configuration, only if redundancy exists, you can use OutOf(2, 'Founder.member', 'Participant1.member'). Avoid strict policies such as AND('Founder.member', 'Participant1.member') unless both organizations have sufficient peer redundancy.

For more information, see Specify an Endorsement Policy.

Peer Deployment

Deploy at least two peers per organization. Oracle Blockchain Platform automatically distributes peers across availability domains and fault domains to ensure that at least one peer remains available after a VM failure.

Private Data Collections

If you use private data collections, set the Peers Required value (requiredPeerCount) to one or greater, and set the Max Peer Count value (maxPeerCount) to two or greater in the definition of the private data collection. Ensure that at least two peers are members of each private data collection and that private data is committed across at least two peers. The Peers Required value is the minimum number of peers (excluding the endorsing peer) that must successfully receive the private data before the transaction proposal is considered complete.

For cross-organization private data collections, configure the required peer count to be greater than the number of peers from a single organization and ensure distribution across multiple organizations and VMs.

For more information, see Add Private Data Collections.

Raft Ordering Service

Use the default three-node Raft ordering service. Oracle Blockchain Platform distributes orderers across availability domains and fault domains, which allows the ordering service to handle a single node failure.

Anchor Peers

In networks with multiple organizations, configure at least one anchor peer per organization. For improved resilience, configure at least two anchor peers per organization. Anchor peers are needed only when more than one Oracle Blockchain Platform organization instance exists in the network, as they enable gossip-based communication and peer discovery across different organizations.

For more information, see Add an Anchor Peer.

Chaincode Deployment

To ensure continuity if a peer becomes unavailable, install and approve chaincode on at least two peers per organization. You can spread these deployments across Oracle Blockchain Platform instances in a network if your privacy requirements allow for that.

Client Connectivity

Configure client applications to never latch to specific peers. Instead, allow the underlying client library to deal with peer selection.

Fallback State Database

The state database is stored on each peer for all channels that the peer is joined to. If a VM fails, the local state database on that peer becomes unavailable until the peer is restored. Oracle Blockchain Platform supports a hybrid state database model, where an external Oracle Database acts as a fallback (secondary) state database. When the fallback state database is enabled, state data is persisted outside the peer VM in a database that can take over as the primary state database as needed, which improves durability and recovery.

Complete the following steps to use this function to improve resilience.
  • Enable the fallback state database for production workloads or critical workloads
  • Deploy Oracle Database independently of the peer VMs.
  • Configure Oracle Database for high availability.
By taking these steps you can ensure that state data is not tied to the life cycle of a single VM. The fallback state database works in complement with peer redundancy for scenarios where a single VM fails.

For more information, see Create the Fallback State Database.