Nebulaworks Insight Content Card Background - Scott webb blue purple mosaic

Nebulaworks Insight Content Card Background - Scott webb blue purple mosaic

Consul Raft Protocol vs. Raft Consensus Algorithm

June 18, 2019 Lynn Dong

Distinguish protocols from algorithms and discover the who, what, when, why, and how as it pertains to Consul in distributed systems.

Recent Updates

As much as I love technology and learning, reading about low-level protocols is not my idea of fun. I’m going to assume a lot of people feel the same way. As an engineer, we need to know how things work fundamentally. One of the key items I see others get confused about (and I admit I got them mixed up as well when I first started at Nebulaworks) are protocols and algorithms. In this blog post, we will quickly differentiate the line between the two, as well as make some food analogies along the way!

There is one thing I want to be clear on: Protocols != Algorithms

HashiCorp’s Consul Raft Protocol is an implementation of the Raft Consensus Algorithm. A couple of students developed this algorithm at Stanford. HashiCorp took the Raft Consensus Algorithm and created their version of a Raft protocol for their service mesh tool called Consul. They have written it in Golang and you can see the open source project here. While this implementation is written in Go, there are other Raft protocols written in C++, Java, Rust, etc.

ex: It’s as if grandma gave HashiCorp a recipe to her blue ribbon award-winning apple pie. Hashi attempts to create an apple pie following her recipe. Hashi knows they must use apples, sugar, cinnamon, etc but have the option to decide specifically what kind of apples and brands to use for their ingredients, as well as the option to add a little extra or less. HashiCorp also knows they need to bake their apple pie in the oven at a certain heat for a certain amount of time, however, they can decide how hot and how long they can bake their pie to get the specific results that fit their specific tastes.

Grandma Stanford’s Blue Ribbon Award Winning Apple Pie Recipe

  1. Cut up 5 apples
  2. Mix sugar, cinnamon, apple, and all purpose flour into a bowl
  3. Pour mix into pie crust
  4. Bake @ 300 degrees for 30 minutes (Please do not actually follow this recipe, it will make a very weird implementation of an apple pie!)

HashiCorp’s Apple Pie Ingredients

Mmm...Apple Pie
Mmm...Apple Pie

Why

to have a working solution to solve a specific problem (what problem? check the what section)

without a recipe and an idea of what ingredients make up an apple pie, you’re probably going to end up not having an apple pie

to provide an outline on how a system works

without specific ingredients and information on how HashiCorp makes their pie within their context, you’re going to end up with a slightly different pie

What

Raft was created to solve the need for consensus in distributed systems. In a nutshell, there was already a solution called Paxos for this problem but it was challenging to implement and even more challenging to understand. Stanford peeps wanted to create a consensus algorithm similar to Paxos but way simpler. They went ahead and created the Raft Consensus Algorithm which is as efficient as Paxos but has a different structure. They also achieved their goal of making it a lot easier to implement and understand, which is beneficial for everyone!

ex: Imagine a restaurant is a distributed system. We’ve got the host, waiter, busser, chef, dishwasher, etc. I want to put in a read request for this restaurant. This could be wanting to read the most recent version of their menu, viewing the most up-to-date list of parties waiting to be seated, seeing the available reservation slots, etc. No matter what this read request is, a client does not want to see something outdated or irrelevant and if there is a problem with their request, they would want to know as soon as possible as well as why the restaurant is unable to provide them with the information. If the host of a restaurant was the only person who had the ability to provide them with the information on # of parties waiting to be seated and they decided not to show up to work, the restaurant would not have consistency. Luckily, the restaurant has an employee handbook the provides all the information on how the restaurant should run. In order to avoid this scenario from happening, the employee handbook says there must always be more than one host on a shift. One of the hosts needs to be designated the leader and all client requests that the host position should handle will be directed to the leader. The leader will get consensus from the other hosts and respond to the client. Now the restaurant has consistency.

How

I think this is a great and easy way to learn Raft and this section from HashiCorp for learning the CRP. These resources will do a better job explaining than anything I can write on my own so check them out!

When

Only Consul server nodes participate in Raft. Client nodes forward requests to the server nodes.

Leader nodes only generate new log entries when there is a request that will modify the state of the cluster. Otherwise, if it is a read-only request, the leader will return information based on the current state.

ex: A customer asks how long the wait is for a party of 4. The leader host will not need to make a change to the list and only needs to read it so the host gets the information and provides it for the customer. A customer wants to change their party from 4 to 5 people. Since this will alter the state of the waiting list, the leader host must get consensus from the other hosts to make sure that the change is approved by all hosts.

There will be separate clusters or datasets and therefore leaders if there are multiple datacenters. This will avoid latency in the network and performance degradation.

ex: Let’s take my favorite steak restaurant for this specific example, Mastro’s. Mastro’s has multiple locations with their own hosts, servers, bussers, etc. If a host had to sort through the waitlist of all the various Mastro’s locations, it would take a long time and definitely create performance issues for the restaurant. It would also not be ideal if the leader host had to get consensus from all the hosts in different locations to make a change to one restaurant. Similar to network partitions, restaurants are separate from eachother and have their own leader, clients, waitlists, etc.

Who

Protocols aren’t a Who but I am! If you’ve gotten to this point and you’re wondering who I am, my name is Lynn and I am a Cloud Engineer at Nebulaworks! I try to make analogies for complex technology so that I can understand things better. My goal is to build my own understanding in order to help teach others that are just as confused as I was.

Me With Food (as always)

tldr

I hope this was beneficial for you and that you are now navigating away from this page with more knowledge about Consul Raft Protocol vs the Raft Consensus Algorithm than when you first clicked in! If you have any comments or questions regarding this post or the HashiCorp stack, do not hesitate to contact us!

Now get out there and build your own distributed system or heck, maybe even create your own algorithm!

Insight Authors

Lynn Dong, Sr. Cloud Engineer Lynn Dong Sr. Cloud Engineer
Nebulaworks - Wide/concrete light half gray

Looking for a partner with engineering prowess? We got you.

Learn how we've helped companies like yours.