#fabric-questions #fabric #fabric-orderer #hyperledger-fabric #fabric-questions #fabric #fabric-orderer #hyperledger-fabric


neha.ghogale@...
 

Hi,

I am designing zero downtime disaster recovery(DR) for hyperledger fabric. To do the same we will have DR(disaster recovery) some peers and orderers will be deployed on other location for the same channel. Normally peers won't be having problem, because they can sync data from orderer as well as through gossip. In case of ordering service, if maximum orderer nodes goes down then whole ordering service will failed. For example,if we keep 6 orderers at main location and 5 at DR location then if main location goes down, then the DR ordering service will not work. What should we do in this case? Also how to design zero downtime disaster recovery for hyperledger fabric?


Alexandre Pauwels
 

Neha,
The only way to provide for an entire data center going down is to have 3 separate locations. The RAFT ordering service uses 2N+1 to determine failure tolerance, where N is the number of ordering nodes that can go down and the network to still be operational. The same equation can be applied for the # of locations that can be tolerated to go down. You could have 3 data centers each with one ordering node.

Alex


On Thu, Oct 29, 2020, 08:12 <neha.ghogale@...> wrote:

Hi,

I am designing zero downtime disaster recovery(DR) for hyperledger fabric. To do the same we will have DR(disaster recovery) some peers and orderers will be deployed on other location for the same channel. Normally peers won't be having problem, because they can sync data from orderer as well as through gossip. In case of ordering service, if maximum orderer nodes goes down then whole ordering service will failed. For example,if we keep 6 orderers at main location and 5 at DR location then if main location goes down, then the DR ordering service will not work. What should we do in this case? Also how to design zero downtime disaster recovery for hyperledger fabric?


neha.ghogale@...
 

Hi,

Thanks for your solution. Our DLT network require high TPS and splitting ordering service in 3 different locations will have negative impact on the performance as per raft protocol all ordering nodes(deployed on different locations) will take part in consensus . So we have below questions related to this:

  1. Can we specify consenter set(contains orderer node only from main location) in raft ordering service so that ordering service will take consensus from only orderer node present in consenter set?

  2. Can we have orderer leader chosen from consenter set(contains orderer node only from main location)?

  3. Does other orderer nodes than consenter set does not take active participation in consensus?

Definition for consenter set is referred from https://hyperledger-fabric.readthedocs.io/en/latest/orderer/ordering_service.html

Is there any other way of doing this?