High Availability Orderer (peerpay-enterprise-orderer)

The peerpay-enterprise-orderer repository contains the configuration to deploy secondary, isolated ordering nodes (e.g. orderer2.example.com) for the PeerPay network.

At a Glance

Property Value
Role Secondary Raft orderer for high availability
Stack Hyperledger Fabric orderer image, Docker Compose, shell automation
Consensus Raft (joins the primary orderer's Raft cluster)
Identity mTLS using certificates issued by the master network's CA
Typical hostname orderer2.example.com (configurable)

Purpose

Hyperledger Fabric relies on an orderer cluster to validate and sequence transactions. To meet enterprise reliability targets, the primary orderer must not be a single point of failure. This repository deploys a backup orderer node so that, when the network uses Raft consensus, the cluster gains fault tolerance: if the primary node goes offline, the secondary orderer continues to sequence transactions and the network keeps producing blocks.

Prerequisites

  • The Main Fabric Network is up and reachable on the public network (or VPC) where this orderer will run.
  • TLS certificates and the orderer MSP have been generated for the new orderer host by the master network's CA.
  • Network connectivity to the master orderer's gRPC port (7050) over mTLS.
  • A populated .env with the orderer hostname, port, channel list and MSP paths.

How It Runs Independently

The secondary orderer is designed to run independently, potentially on completely separate physical infrastructure.

To start the node and automatically join all active channels on the network, run the included automation:

./start-and-join.sh

This script:

  1. Reads environment variables from .env.
  2. Spins up the orderer container with the correct MSP and TLS material.
  3. Auto-discovers active channels.
  4. Runs the osnadmin commands required to join the orderer to each channel's Raft cluster.

Communication

  • Raft consensus over gRPC — the secondary orderer connects to the primary orderer and to all channels' consensus groups using standard Fabric gRPC endpoints. It participates as an equal member of the Raft cluster.
  • Identity via mTLS — it presents TLS certificates pre-generated by the master network's CA. Once connected, it streams ledger data and stays in sync with the rest of the cluster.
  • No direct contact with the API — the API does not talk to the secondary orderer directly; it discovers all orderer endpoints via the channel configuration.

Operational Notes

  • For genuine fault tolerance, deploy at least three orderer nodes total (primary + two secondaries) so that Raft can tolerate a single-node failure while still maintaining quorum.
  • Run secondary orderers in separate availability zones or on distinct physical hosts.
  • Monitor the orderer container's /healthz endpoint and Raft leadership metrics.