Splunk® Enterprise

Managing Indexers and Clusters of Indexers

Download manual as PDF

This documentation does not apply to the most recent version of Splunk. Click here for the latest version.
Download topic as PDF

Configure the cluster with server.conf

For most purposes, it's easiest to enable cluster nodes through Splunk Web, as described in the chapter, "Deploying clusters". When you enable a node in Splunk Web, the configuration is saved in the node's underlying server.conf file, located in $SPLUNK_HOME/etc/system/local/. You can also enable a node or change its clustering configuration by editing its server.conf file directly.

The main server.conf stanza that controls clustering is [clustering]. Besides the basic attributes that control enablement and are parallel to settings in Splunk Web, server.conf controls a number of advanced clustering settings. To change those attributes, you must edit server.conf directly.

In addition to the [clustering] stanza, clustering uses the [replication_port] stanza to specify the port where a peer listens for replicated data.

This topic focuses on the attributes that control basic cluster node enablement and that parallel the settings in Splunk Web. For details on all the clustering attributes, including the advanced ones, read the server.conf specification.

Enable cluster nodes

The following sample set of clustering stanzas shows simple cluster enablement for each node type. The configuration attributes shown in these examples correspond to fields on the Enable clustering page of Splunk Web.

Note: When you set up cluster nodes in Splunk Web, the resulting server.conf stanzas will include attributes only for non-default values. For example, if, when enabling a master node in Splunk Web, you accept the default replication factor of 3 and don't enter a new value for it, the resulting stanza will not include the replication_factor attribute.

The master node

Here's an example of a basic configuration for a master node:

[clustering]
mode = master
replication_factor = 4
search_factor = 3
pass4SymmKey = whatever

This example specifies that:

  • the instance is a cluster master node.
  • the cluster's replication factor is 4.
  • the cluster's search factor is 3.
  • the secret key is "whatever".

The peer nodes

Here's an example configuration for a peer node:

[replication_port://9887]

[clustering]
master_uri = https://10.152.31.202:8089
mode = slave
pass4SymmKey = whatever

This example specifies that:

  • the peer will use port 9887 to listen for replicated data streamed from the other peers. You can specify any available, unused port as the replication port. Do not re-use the management or receiving ports.
  • the peer's cluster master is located at 10.152.31.202:8089.
  • the instance is a cluster peer ("slave") node.
  • the secret key is "whatever".

The search head

Here's an example configuration for a search head:

[clustering]
master_uri = https://10.152.31.202:8089
mode = searchhead
pass4SymmKey = whatever

This example specifies that:

  • the search head's cluster master is located at 10.152.31.202:8089.
  • the instance is a cluster search head.
  • the secret key is "whatever".

Note: You can also enable multi-cluster search by editing server.conf. For details, see "Configure multi-cluster search".

Configure the secret key

You can optionally set the pass4SymmKey attribute to configure a secret key that authenticates communication between the master, peers and, search heads. If you set it for one cluster node, you must also give it the same value for all other cluster nodes.

Set the key inside the [clustering] stanza to limit the use of the key to clustering functionality. If pass4SymmKey is set in the [general] stanza, the key will be valid for both clustering and licensing, unless you override it by also setting the key in the [clustering] stanza. As always in configuration stanzas, when an attribute is defined multiple times, the more specific definition overrides the general. So, if you set the key in the [general] stanza and also in the [clustering] stanza, clustering will use the setting in [clustering] and licensing will use the setting in [general].

Restart after modifying server.conf?

After you configure an instance as a cluster node for the first time, you need to restart it for the change to take effect. When you make certain configuration changes later on, you do not need to restart.

Initial configuration

After initially configuring instances as cluster nodes, you need to restart all of them (master, peers, and search head) for the changes to take effect. You can do this by invoking the CLI restart command on each node:

$SPLUNK_HOME/bin/splunk restart

When the master starts up for the first time, it blocks indexing on the peers until you enable and restart the replication factor number of peers.

Important: Although you can use the CLI restart command when you initially enable an instance as a cluster peer node, do not use it for subsequent restarts. The restart command is not compatible with index replication once replication has begun. For more information, including a discussion of safe restart methods, read "Restart a single peer".

Subsequent configuration changes

If you change the following attributes in a peer's or search head's server.conf file, you do not need to restart the node:

  • master_uri

All other cluster-related configuration changes require a restart.

Warning: Do not increase the replication factor or search factor on the master

Although it is possible to change the settings for the replication factor and search factor in server.conf, it is inadvisable to increase either of them once your cluster contains significant amounts of data. Doing so will kick off a great deal of bucket activity, which will have an adverse effect on the cluster's performance while bucket copies are being created and/or made searchable.

PREVIOUS
Configure the search head
  NEXT
Configure the cluster with the CLI

This documentation applies to the following versions of Splunk® Enterprise: 6.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, 6.0.5, 6.0.6, 6.0.7, 6.0.8, 6.0.9, 6.0.10, 6.0.11, 6.0.12, 6.0.13, 6.0.14, 6.0.15


Was this documentation topic helpful?

Enter your email address, and someone from the documentation team will respond to you:

Please provide your comments here. Ask a question or make a suggestion.

You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters