Date 1 - 2 of 2
How many ordering services should a network have? #fabric #fabric-orderer
Joe Alewine <joe.alewine@...>
toggle quoted message Show quoted text
While it's possible to use the console to build a configuration of any number of ordering nodes (no configuration is explicitly restricted), some numbers provide a better balance between cost and performance than others. The reason for this lies in satisfying the needs of high availability (HA) and in understanding the Raft concept of the "quorum", the minimum number of nodes that must be available (out of the total number) for the ordering service to process transactions.
In Raft, a majority of the total number of nodes is needed to form a quorum. In other words, if you have one node, you need that node available to have a quorum, because the majority of one is one. Similarly, if you have two nodes, you will need both available, since the majority of two is two (for this reason, a configuration of two nodes is discouraged; there is no advantage to a two node configuration). In a similar vein, the majority of three is two, the majority of four is three, the majority of five is three, and so on.
While satisfying the quorum will make sure the ordering service is functioning, production networks also have to think about deployment configurations that are highly available (in other words, configurations in which the loss of a certain number of nodes can be tolerated by the system). Typically, this means tolerating two nodes failing: one node going down during a normal maintenance cycle, and another going down for any other reason (such as a power outage or error).
This is why five nodes is a good number for a production network. Recall that the majority of five is three. This means that in a five node configuration, the loss of two nodes can be tolerated. If your configuration features four nodes, only one node can be down for any reason before another node going down means a quorum has been lost and the ordering service will stop processing transactions.
Hope this helps.
IBM Blockchain, Raleigh
rocket chat: joe-alewine
----- Original message -----
I was just wondering what is the best practice when it comes to the ordering service in a production environment.
What is the proportion of ordering service nodes in relation to the size of the network? Or is a ordering service node with Raft, meaning various instances, enough for a production network?
Should each organization have its own ordering service node? or only a instance?
Help would be much apreciated guys, Thank You.
|1 - 2 of 2|