Overview

This guide covers how to implement Business Continuity and Disaster Recovery (BCDR) within Rayls, so that risk is mitigated and operation continues through unforeseen events.

The section sets out strategies for maintaining high availability and resilience across both the Private Network and Rayls Sovereign infrastructures, with a focus on disaster recovery, containerised deployments using Docker Compose and Kubernetes, and multi-region setups.

Rayls Components

Rayls recommends deploying all Rayls components inside containers, which opens up a range of BCDR strategies that can be matched to different business continuity policies and requirements.

Containers help disaster recovery in several ways, including isolation, portability and fast deployment. Encapsulating applications together with their dependencies keeps them consistent and compatible across environments, which in turn makes deployment and recovery quicker.

Container orchestration platforms go further by automating failover and load balancing, while versioning and rollback allow an organisation to return to a known good state quickly and reliably.

Taken together, containers give a flexible and reliable platform for disaster recovery, and they let an organisation maintain business continuity with as little downtime as possible.

Major cloud providers offer managed Kubernetes services across multiple availability zones, and Rayls components can be distributed across those zones through Kubernetes orchestration.

Contact Rayls for full access to the Rayls Installation Package.

Third Party Components

MongoDB

For customers using the cloud-based MongoDB service, MongoDB Atlas, a replica set is deployed by default with at least three nodes distributed across the Availability Zones (AZs) provided by the cloud provider. MongoDB Atlas also supports a multi-cloud and multi-region disaster recovery architecture.

For customers who prefer to install and manage their own MongoDB cluster, several resilient architectures are available, and the MongoDB official documentation is the reference for choosing between them. As a starting point, a MongoDB Replica Set with five nodes spread across multiple Availability Zones gives a resilient architecture suitable for mission-critical work.

Private Network Hub

The Rayls Private Network supports any EVM-based blockchain in the Private Network Hub role out of the box, and Hyperledger Besu is the recommendation in the current version. The architecture of Hyperledger Besu sits outside the scope of this document and is set out in the official Hyperledger Besu documentation, although one point carries directly into deployment planning, which is that a minimum of four nodes is required for the QBFT consensus protocol. Distributing those Besu nodes across different Availability Zones, regions or cloud providers is therefore the recommended approach for resilience and fault tolerance.

“In QBFT networks, approved accounts, known as validators, validate transactions and blocks. Validators take turns to create the next block. Before inserting the block onto the chain, a super-majority (greater than or equal to 2/3) of validators must first sign the block.”

For production and mission-critical applications, deploying five Besu validators distributed across multiple Availability Zones, regions, and/or cloud providers is strongly recommended.

PostgreSQL

PostgreSQL supports multiple read replicas, which can be spread across Availability Zones, regions or cloud providers for fault tolerance and scalability. Leading cloud providers also offer solutions that go beyond standard PostgreSQL, and Amazon Aurora is one example, since it allows multiple write instances and read replicas to be deployed across different regions for greater resilience and performance.

“Amazon Aurora Multi-Master is now generally available, allowing you to create multiple read-write instances of your Aurora database across multiple Availability Zones, which enables uptime-sensitive applications to achieve continuous write availability through instance failure. In the event of instance or Availability Zone failures, Aurora Multi-Master enables the Aurora database to maintain read and write availability with zero application downtime. With Aurora Multi-Master, there is no need for database failovers to resume write operations.”

See more:

Multi-Region and Disaster Recovery Strategy

For the highest level of availability and disaster tolerance, all key components should be deployed across multiple regions or availability zones, whether the deployment uses Docker Compose or Kubernetes.

Data Replication: Databases such as MongoDB should be configured to replicate data across multiple regions, which keeps downtime short and preserves data integrity through a regional failure.
Failover Automation: In Kubernetes, failover is handled automatically by routing traffic to healthy nodes in another region. With Docker Compose, failover may need to be configured manually, although it can still be achieved through load balancers or cloud services.
Cross-Region Load Balancing: Load balancing across regions gives both performance and redundancy, keeping the infrastructure operational through high-traffic periods and through failures.