In Consul you can have many agents as servers or clients. Amongst all servers one is chosen as the leader. From the agent's point of view, how does it know it is the leader?
Consul agent can run in two different modes — Server and Agent. The main responsibilities of the Consul Server are to respond to the queries coming from the agents and to elect the leader. The leadership is selected using the consensus protocol to provide Consistency (as defined by CAP) based on the Raft algorithm.
By default, the Consul agent runs a DNS server listening on port 8600. By submitting DNS requests to the Consul agent's DNS server, you can get the IP address of a node running the service in which you are interested. The Consul DNS interface makes the port information for a service available via the SRV records.
Consul is a distributed system designed to run on a cluster of nodes. A Consul node can be a physical server, cloud instance, virtual machine, or container. Connected together, the set of nodes Consul runs on is called a datacenter. A datacenter will have between 3 - 5 servers and many clients.
The easiest way to view initial health status is by visiting the Consul Web UI at http://localhost:8500/ui . Click through to a specific service such as the counting service. The status of the service on each node will be displayed.
consul operator raft list-peers also show the relationship between peers; for example
consul operator raft list-peers
Node ID Address State Voter RaftProtocol
agent1 2a3ae4a0-8193-7da9-f978-911d7df0d184 192.168.110.128:8300 leader true 3
agent2 5ca6550b-c211-d11f-0236-82a9572e2485 192.168.110.133:8300 follower true 3
agent3 10e1b43d-9393-6985-242b-8e31411839c5 192.168.110.137:8300 follower true 3
The Consul leader is elected via an implementation of the Raft Protocol from amongst the Quorum of Consul Servers. Only Consul instances that are configured as Servers participate in the Raft Protocol communication. The Consul Agent (the daemon) can be started as either a Client or a Server. Only a Server can be the leader of a Datacenter.
The Raft Protocol was created by Diego Ongaro and John Ousterhout from Stanford University in response to the complexity of existing consensus protocols such as Paxos. Raft elects a leader via the use of randomized timers. The algorithm is detailed in Ongaro and Ousterhout's paper.
Consul instances that are configured as Clients communicate with the cluster via the Gossip Protocol which is based on Serf. Serf communication is eventually consistent. The Serf cluster has no central server, each node is considered equal. All nodes (Clients and Servers) in participating the Gossip/Serf Protocol spread messages to their neighbors, which in turn spread messages to their neighbors until the message has propagated to the entire cluster. Sort of like the infection path of a zombie apocalypse. This is done to greatly reduce communication overhead in the cluster as it scales to potentially tens of thousands of nodes.
Consul Clients can forward messages to any Consul Server which will then forward the message to the Leader. Consul Clients do not need to care which Consul Server is the Leader. Only the Servers need to care.
The Consul HTTP API running on any Consul Server will tell you which Server is the leader at $ANY_CONSUL_SERVER/v1/status/leader
. However, this has nothing to do with how Consul Agents do leader election.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With