Using Consul For Discovery and Leader Election Only

[Mike]

Being new to the consul, I understand the use case it is being focused on where it is important for consul to persist state but I was wondering if I could use consul for live and lightweight member discovery and leader election where persistence is not required and should be disabled.

Basically, I want to to install the consul agent on hundreds of nodes such that it would consume minimal resources/almost none (ram, CPU,  disk)  on each node and let the nodes to find each other (after bootstrapping) and elect a leader among them where a leader can be re-elected upon the current leader failure. 

Does such use-case make sense for consul? 

Is it even possible to remove/disable kv storage requirement of the consul? if so, would you please give me a pointer?

is raft practically capable of leader election when you have hundreds of nodes deciding?

Thank you for your help in advance. 

[Armon Dadgar]

Mike,

If you want a system that is effectively stateless and has no KV, I would recommend

taking a look at Serf instead. Consul makes certain tradeoffs to provide durability and

strong consistency which requires it has central servers. Similarly, Raft is not designed

to handle hundreds of participants.

We strongly recommend running running Consul with 3 or 5 designated servers, and as

many clients as you like. More exotic arrangements are neither recommended or tested.

Hope that helps!

Best Regards,

Armon Dadgar

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/consul/issues
IRC: #consul on Freenode
---
You received this message because you are subscribed to the Google Groups "Consul" group.
To unsubscribe from this group and stop receiving emails from it, send an email to consul-tool...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/consul-tool/fef33de9-3d93-4558-b577-0b42bfa84bdb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mike]

Thanks a lot Armon for the response. Two quick questions:

1> Would you please talk a little bit about the "certain tradeoffs" you mentioned? In other words, what are these "certain tradeoffs"?
2> When consul runs in server mode and in production, what does it need in terms of resources? what is the required hardware spec? Any means to lower/tune down these requirements?

Btw, thanks for this great project.

[Armon Dadgar]

Mike,

The tradeoffs are Consul is CP where Serf is AP. In practice, this means Consul requires a majority

of its servers (2 or 3, 3 of 5) to be available and able to communicate to function. Serf is able to work

under the most extreme of failure conditions. However, to do so, Serf sacrifices consistency meaning

events are delivered out of order and can be lost entirely. Consul has central servers that store all the

state, where Serf agents all have the full cluster state. For small amounts of state that is fine, for large

amounts of K/V you may have 1000x duplication with Serf instead of 3x with Consul.

Consul basically trades being less tolerant of failures for performance improvements, reducing data duplication,

and the ability to provide strong coordination. Serf trades higher level features for being lightweight

and extremely failure tolerant.

The resource requirements of the Consul servers is hard to estimate without knowing the number

of clients, amount of K/V, anticipated query volume, etc. The best bet is to just benchmark your

use case. Generally, writes are IO bounded and reads are CPU bounded. The full Consul data set

must be resident in memory, and you want to have a 1-2x free memory buffer in addition to that.

Hope that helps!

Best Regards,

Armon Dadgar

To view this discussion on the web visit https://groups.google.com/d/msgid/consul-tool/15282dfc-7ffc-4c5d-8900-2cb99925a1d8%40googlegroups.com.