Overview of search head pooling

This feature is deprecated.
Search head pooling is deprecated as of Splunk Enterprise version 6.2. This means that although it continues to function, it might be removed in a future version. As an alternative, you can deploy search head clustering. See About search head clustering. For a list of all deprecated features, see the topic Deprecated features in the Release Notes.

Important: Search head pooling is an advanced feature. It's recommended that you contact the Splunk sales team to discuss your deployment before attempting to implement it.

You can set up multiple search heads so that they share configuration and user data. This is known as search head pooling. The main reason for having multiple search heads is to facilitate horizontal scaling when you have large numbers of users searching across the same data. Search head pooling can also reduce the impact if a search head becomes unavailable. This diagram provides an overview of a typical deployment with search head pooling:

You enable search head pooling on each search head that you want to be included in the pool, so that they can share configuration and user data. Once search head pooling has been enabled, these categories of objects will be available as common resources across all search heads in the pool:

• configuration data -- configuration files containing settings for saved searches and other knowledge objects.
• search artifacts, records of specific search runs.
• scheduler state, so that only one search head in the pool runs a particular scheduled report.

For example, if you create and save a search on one search head, all the other search heads in the pool will automatically have access to it.

Search head pooling makes all files in $SPLUNK_HOME/etc/{apps,users} available for sharing. This includes *.conf files, *.meta files, view files, search scripts, lookup tables, etc.

Key implementation issues

Note the following:

• Most shared storage solutions don't perform well across a WAN. Since search head pooling requires low-latency shared storage capable of serving a high number of operations per second, implementing search head pooling across a WAN is not supported.

• All search heads in a pool must be running the same version of Splunk Enterprise. Be sure to upgrade all of them at once. See "Upgrade your distributed Splunk Enterprise deployment" in the Installation Manual.

• The purpose of search head pooling is to simplify the management of groups of dedicated search heads. Do not implement it on groups of indexers doubling as search heads. That is an unsupported configuration. Search head pooling has a significant effect on indexing performance.

• The search heads in a pool cannot be search peers of each other.

Search head pooling and knowledge bundles

The set of data that a search head distributes to its search peers is known as the knowledge bundle. For details, see What search heads send to search peers.

By default, only one search head in a search head pool sends the knowledge bundle to the set of search peers. This optimization is controllable by means of the useSHPBundleReplication attribute in distsearch.conf.

As a further optimization, you can mount knowledge bundles on shared storage, as described in About mounted bundles. By doing so, you eliminate the need to distribute the bundle to the search peers. For information on how to combine search head pooling with mounted knowledge bundles, read Use mounted bundles with search head pooling.

For more information

See the other topics in this chapter for more information on search head pooling:

• "Create a search head pool"
• "Use a load balancer with the search head pool"
• "Other pooling operations"
• "Manage configuration changes"
• "Deployment server and search head pooling"
• "Select timing for configuration refresh"

Answers

Have questions? Visit Splunk Answers and see what questions and answers the Splunk community has about search head pooling.