2.2.5.3. AWS MarketPlace mijin Catapult(v.2) Recovery Strategy with Architectural Patterns

Deployed in AWS MarketPlace, mijin Catapult(v.2) has various architectural patterns depending on the parameters used for deployment.
In this chapter, you will learn architectural patterns and describe recovery strategies through disaster recovery and other BCP measures.
creation-day:

Aug. 1, 2022

update date:

September 15, 2022

2.2.5.3.1. mijin Catapult(v.2) high availability and fault tolerance

mijin Catapult(v.2) keeps the same blockchain data on all nodes, so as long as there is at least one PEER node, the blockchain will continue to update. (Decentralized Fault Tolerance)
Blockchain is characterized by the fact that data is not stored in units of records, such as RDB, but is stored collectively in units of blocks.
Therefore, depending on the circumstances of the failure, the most recent blockchain data may not always be the most current and correct data.
The reason is that the block data of the blockchain is generated in the approximate number of seconds set during deployment, and is divided into nodes that generate blocks (harvesting nodes) and nodes that receive the generated blocks.
The nodes that create blockchain data are pruned by a consensus algorithm (Proof-of-Stake Plus), and the nodes that generate blocks (harvesting nodes) are pruned by a consensus algorithm (Proof-of-Stake Plus).
To learn more about the consensus algorithm, see Symbol’s Document.


Although rewards through the block generation mechanism exist in mijin, they are not required in a private blockchain, so the reward process is only running functionally.
The following diagram shows the blockchain being generated by PEER3 and the blockchain data being sent to each node.
../../_images/aws_dr1.png
If a failure occurs in a situation where only PEER2 remains without receiving the block data generated from PEER3, there may be a difference of at least one block.
At that time, PEER2 cannot recognize PEER1 and PEER3, so it generates new blockchain data and turns into an independent node.
However, if PEER1 and PEER3 are recovered immediately, PEER3 with the correct block data is rolled back as positive and recovered to the normal blockchain data.
If all the API nodes are down, they cannot be accessed by programs, etc., but block generation will proceed as long as the PEER nodes are present.

2.2.5.3.2. Multi-AZ Recovery Strategy

Recovery Time Objective (RTO)

Almost 0

Recovery Point Objective (RPO)

Almost 0

Deploying in Marketplace mijin Catapult(v.2) deploys each node in a multi-AZ environment.
Even if one AZ side fails, the distributed fault tolerance of mijin Catapult(v.2) allows the service to continue.
If you want to keep the connection to the API node, enable Elastic Load Balance to improve availability.
../../_images/aws_dr2.png

2.2.5.3.3. Multi-region and recovery strategies

2.2.5.3.3.1. Inter-region backup

Recovery Time Objective (RTO)

one day

Recovery Point Objective (RPO)

2 hours

All of the mijin Catapult(v.2) deployed in Marketplace can be recovered by backing up the blockchain data from one of the nodes.
Using AWS Backup, blockchain data on a node can be easily backed up to another region.
For backup instructions, see . /aws_tips_ebs_backup.
See below for information on how to restore until backed up.

../../_images/aws_dr4.png

2.2.5.3.3.2. Consortium chain with active/active

Recovery Time Objective (RTO)

Almost 0

Recovery Point Objective (RPO)

Almost 0

Warning

Manually build mijin in a separate region to achieve 0 downtime by realizing a consortium chain.
The following diagram shows an example, but since the construction procedure varies depending on the environment, we can provide paid support.

The mijin Catapult(v.2) deployed on Marketplace can be located in 21 regions around the world, but there is no mechanism for building nodes across regions.
By manually building mijin nodes outside of the main region, a multi-region disaster recovery strategy can be established.
The API nodes are also installed together to form a consortium chain, which is an active/active configuration even between regions.
../../_images/aws_dr3.png