Configure the indexer cluster with server.conf
Before reading this topic, see "About configuration files" and the topics that follow it in the Admin Manual. Those topics explain how Splunk Enterprise uses configuration files.
Indexer cluster settings reside in the server.conf file, located in
$SPLUNK_HOME/etc/system/local/. When you deploy a cluster node through Splunk Web or the CLI, the node saves the settings to that file. You can also edit
server.conf file directly, either to deploy initially or to change settings later.
server.conf stanza that controls indexer clustering is
[clustering]. Besides the basic attributes that correspond to settings in Splunk Web,
server.conf provides a number of advanced settings that control communication between cluster nodes. Unless advised by Splunk Support, do not change those settings.
This topic discusses some issues that are common to all node types. For specific instructions for each node type, see:
- "Configure the master with server.conf".
- "Configure peer nodes with server.conf".
- "Configure the search head with server.conf".
For details on all the clustering attributes, including the advanced ones, read the server.conf specification.
For multisite cluster configurations, also read "Configure multisite indexer clusters with server.conf".
Here is an example master node configuration:
[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".
Peer node and search head configuration are similar.
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.
You must set the key inside the
[clustering] stanza for indexer clustering. You can also set
pass4SymmKey in the
[general] stanza for licensing.
Important: You should save a copy of the key in a safe place. Once an instance starts running, the secret key changes from clear text to encrypted form, and it is no longer recoverable from
server.conf. If you later want to add a new node, you will need to use the clear text version to set the key.
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.
If you make a configuration change later on, you might not need to restart the instance, depending on the type of change. Avoid restarting peers when possible. Restarting the set of peers can result in prolonged amounts of bucket-fixing.
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:
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. Do not restart the master while it is waiting for the peers to join the cluster. If you do, you will need to restart the peers a second time.
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 any of the following attributes in the
server.conf file, you do not need to restart the node.
On a peer node or search head:
On a master node:
All other cluster-related configuration changes require a restart.
Configure the cluster with the dashboards
Configure and manage the indexer cluster with the CLI
This documentation applies to the following versions of Splunk® Enterprise: 6.1, 6.1.1, 6.1.2, 6.1.3, 6.1.4, 6.1.5, 6.1.6, 6.1.7, 6.1.8, 6.1.9, 6.1.10, 6.1.11, 6.1.12, 6.1.13, 6.1.14