Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gossip tuneables #4444

Merged
merged 4 commits into from
Jul 26, 2018
Merged

Gossip tuneables #4444

merged 4 commits into from
Jul 26, 2018

Conversation

mkeeler
Copy link
Member

@mkeeler mkeeler commented Jul 25, 2018

Fixes: #4058

This PR exposes a number of the serf/memberlist/gossip tuneables. Previously all of these were being forced to default values. For users with extremely large clusters it would be nice to tune these to provide for quicker convergence and gossip message propagation (at the expense of increased network bandwidth).

The only changes here are to expose the configuration entries to the user. They end up just modifying being set on the agent's Config struct as Config.SerfConfig.MemberlistConfig..

The runtime tests were updated to test having these configurations in the hcl/json config and making sure they end up with the correct values in the RuntimeConfig. I then did a little manual testing to verify that the values get set properly in the agent's Config from the RuntimeConfig.

@pearkes pearkes added this to the 1.2.2 milestone Jul 25, 2018
@mkeeler mkeeler requested review from banks and pearkes July 25, 2018 18:46
Copy link
Member

@banks banks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great. I had a couple of questions inline more for my understanding than because I think anything is wrong.

I have just a couple of minor suggestions on the docs which are worth changing.

gossip_interval = "100ms"
probe_interval = "100ms"
probe_timeout = "100ms"
suspicion_mult = 3
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are retransmit_mult and gossip_nodes not set here for a good reason? I suspect because we already use the default value for them in memberlist here but is it worth hard coding it for clarity?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See my other comment. We don't want to do that here. Only items specifically overridden for dev mode go here.

@@ -26,6 +26,10 @@ func DefaultRPCProtocol() (int, error) {
// todo(fs): IMO, this should be the definitive default for all configurable values
// todo(fs): and whatever is in here should clobber every default value. Hence, no sourcing.
func DefaultSource() Source {
cfg := consul.DefaultConfig()
serfLAN := cfg.SerfLANConfig.MemberlistConfig
serfWAN := cfg.SerfWANConfig.MemberlistConfig
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the significance of these moving from DefaultConsulSource to here? This seems like a better place but I don't recall offhand the details of how these two methods interact...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In depth explanation in my other comment.

DefaultConsulSource = non user modifiable
DefaultSource = user modifiable

// hcl: gossip_lan { gossip_interval = duration}
GossipLANGossipInterval time.Duration

// GossipfLANGossipNodes is the number of random nodes to send gossip messages to
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: extra f in the variable name.

//
// The default is: 3
//
// hcl: gossip_lan { gossip_nodes = int}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: space after int


// GossipLANRetransmitMult is the multiplier for the number of retransmissions
// that are attempted for messages broadcasted over gossip. This
// configuration only applies to WAN gossip communications. The actual
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LAN variable but you said "only applies to WAN"

// hcl: gossip_wan { gossip_interval = duration}
GossipWANGossipInterval time.Duration

// GossipfWANGossipNodes is the number of random nodes to send gossip messages to
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extra f again

rt.GossipWANGossipInterval = 100 * time.Millisecond
rt.GossipWANProbeInterval = 100 * time.Millisecond
rt.GossipWANProbeTimeout = 100 * time.Millisecond
rt.GossipWANSuspicionMult = 3
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why don't we have tests for Gossip*Nodes and Gossip*RetransmitMult here again?

Copy link
Member Author

@mkeeler mkeeler Jul 25, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That test is just for -dev mode overrides. I guess we could add validation for some other values not being overridden but other tests already cover that.

* <a name="gossip_lan"></a><a href="#gossip_lan">`gossip_lan`</a> - (Advanced) This object contains a number of sub-keys
which can be set to tune the LAN gossip communications. These are only provided for users running especially large
clusters that need fine tuning and are prepared to spend significant effort correctly tuning them for their
environment and workload.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great, maybe add a sentence: "The default values are most appropriate in almost all deployments." to hammer it home.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ha I just repeated this even after that change. 😂


* <a name="probe_timeout"></a><a href="#probe_timeout">`probe_timeout`</a> - The timeout to wait for an ack from
a probed node before assuming it is unhealthy. This should be set to 99-percentile of RTT (round-trip time) on
your network.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we specify the default? Also maybe the language is confusing "This should be set to " implies that users should fiddle with this when we don't really want to encourage that.

Maybe instead something like "This should be at least the 99-percentile of RTT in you network. The default is 500ms and is a conservative value suitable for almost all realistic deployments."

* <a name="retransmit_mult"></a><a href="#retransmit_mult">`retransmit_mult`</a> - The multiplier for the number
of retransmissions that are attempted for messages broadcasted over gossip. The number of retransmits is scaled
using this multiplier and the cluster size. The higher the multiplier, the more likely a failed broadcast is to
converge at the expense of increased bandwidth.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Default

@mkeeler
Copy link
Member Author

mkeeler commented Jul 25, 2018

Some of this might require a more in depth explanation of how the config is loaded.

Our configuration build (agent/config/builder.go) has a concept of user configuration as well as injected configurations. When given config fragments and config files. Our base configuration fragments to inject are located in agent/config/default.go.

How the builder sets things up is:

DefaultSource
DevSource (only if -dev mode is enabled)
User Defined Sources
NonUserSource
DefaultConsulSource
DefaultEnterpriseSource
DefaultVersionSource
DevConsulSource (if -dev mode is enabled)

Why we have NonUserSource and DefaultConsulSource I am not entirely sure. They both just override anything configured by the user previously to force specific values.

DevSource just overrides default configuration that is setup in DefaultSource and should only contain those items that it specifically wants to override.

Previously the gossip tuneables were in the DefaultConsulSource and thus not user modifiable even though they were technically valid configuration entries. They also existed in DevConsulSource to override them to better values for a -dev environment.

This PR shuffles things around a bit. No longer are the tuneables under the Consul configuration but we also want them to be user modifiable so they were put into the DefaultSource. This sets up sane defaults. A few of them that were previously overridden in DevConsulSource were moved to DevSource to get the override but to still allow user modification.

Copy link
Contributor

@pearkes pearkes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Docs look great here. Just a small note about reminding people why not to touch this stuff.

@@ -883,6 +883,74 @@ Consul will not enable TLS for the HTTP API unless the `https` port has been ass
* <a name="disable_keyring_file"></a><a href="#disable_keyring_file">`disable_keyring_file`</a> - Equivalent to the
[`-disable-keyring-file` command-line flag](#_disable_keyring_file).

* <a name="gossip_lan"></a><a href="#gossip_lan">`gossip_lan`</a> - (Advanced) This object contains a number of sub-keys
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd add:

Tuning these improperly can cause Consul to fail in unexpected ways.

Or something similarly strong language wise about potentially shooting yourself in the foot.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And maybe even bold that line 😄

@mkeeler
Copy link
Member Author

mkeeler commented Jul 26, 2018

Docs update and bolded where appropriate.

@mkeeler mkeeler merged commit 0e02277 into master Jul 26, 2018
@mkeeler mkeeler deleted the serf-tuneables branch September 6, 2018 19:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants