System requirements and other deployment considerations for search head clusters
The members of a search head cluster have most of the same system requirements as any non-clustered search head. This topic details requirements specific to a search head cluster.
Summary of key requirements
These are the main issues to note regarding provisioning of cluster members:
- Each member must run on its own machine or virtual machine, and all machines must run the same operating system.
- All members must run on the same version of Splunk Enterprise.
- All members must be connected over a high-speed network.
- You must deploy at least as many members as either the replication factor or three, whichever is greater.
In addition to the cluster members, you need a deployer to distribute updates to the members. The deployer must run on a non-member instance. In some cases, it can run on the same instance as a deployment server or an indexer cluster master node.
See the remainder of this topic for details on these and other issues.
Hardware and operating system requirements
Machine requirements for cluster members
Each member must run on its own, separate machine or virtual machine.
The hardware requirements for the machine are essentially the same as for any Splunk Enterprise search head. See "Reference hardware" in the Capacity Planning Manual. The main difference is the need for increased storage to accommodate a larger dispatch directory. See "Storage considerations".
Splunk recommends that you use homogeneous machines with identical hardware specifications for all cluster members. The reason is because the cluster captain assigns scheduled jobs to members based on their current job loads. When it does this, it does not have insight into the actual processing power of each member's machine. Instead, it assumes that each machine is provisioned equally.
Operating system requirements for cluster members
All search head cluster members and the deployer must run on the same operating system.
If the search head cluster is connected to an indexer cluster, then the indexer cluster instances must run on the same operating system as the search head cluster members.
Search head clustering is available on the following operating systems:
Splunk does not currently support search head clustering on Windows systems.
When determining the storage requirements for your clustered search heads, you need to consider the increased capacity necessary to handle replicated copies of search artifacts.
For the purpose of developing storage estimates, you can observe the size over time of dispatch directories on the search heads in your non-clustered environment, if any, before you migrate to a cluster. Total up the size of dispatch directories across all the non-clustered search heads and then make adjustments to account for the cluster-specific factors.
The most important factor to take into consideration is the replication factor. For example, if you have a replication factor of 3, you will need approximately triple the amount of the total pre-cluster storage, distributed equally among the cluster members.
Other factors can further increase the cluster storage needs. One key factor is the need to plan for node failure. If a member goes down, causing its set of artifacts (original and replicated) to disappear from the cluster, fix-up activities take place to ensure that each artifact once again has its full complement of copies, matching the replication factor. During fix-up, the copies that were resident on the failed member get replicated among the remaining members, increasing the size of each member's dispatch directory.
Other issues can also increase storage on a per-member basis. For example, the cluster does not guarantee an absolutely equal distribution of replicated copies across the members. In addition, the cluster can hold more than the replication factor number of some search artifacts. See "How the cluster handles search artifacts."
As a best practice, equip each member machine with substantially more storage than the estimated need. This allows both for future growth and for temporarily increased need resulting from downed cluster members. The cluster will stop running searches if any of its members runs out of disk space.
Splunk Enterprise instance requirements
Splunk Enterprise version compatibility
You can implement search head clustering on any group of Splunk Enterprise instances, version 6.2 or above. All cluster members must run on the same version of Splunk Enterprise.
Licensing needs are the same as for any search head. See "Types of Splunk Enterprise licenses" in the Admin Manual.
Required number of instances
The cluster must contain at a minimum the number of members needed to fulfill both of these requirements:
- Three members, so that the cluster can continue to function if one member goes down. See "Captain election process has deployment implications."
- The replication factor number of instances. See "Choose the replication factor for the search head cluster."
For example, if your replication factor is either 2 or 3, you need at least three instances. If your replication factor is 5, you need at least five instances.
You can optionally add more members to boost search and user capacity.
Maximum number of instances
Search head clustering supports up to 50 members in a single cluster.
Search head clusters running across multiple sites
Running a cluster across multiple sites is not currently supported. Search head clusters have been tested only with all members running on a single site.
Cluster member cannot be a search peer
A cluster member cannot be the search peer of another search head. For the recommended approach to accessing cluster member data, see "Best practice: Forward search head data to the indexer layer."
All members must reside on a high speed network where each member can access every other member.
The members do not necessarily need to be on the same subnet, or even in the same data center, if you have a fast connection between the data centers. You can adjust the various search head clustering timeout settings in server.conf. For help in configuring timeout settings, contact Splunk Professional Services.
Ports that the cluster members use
These ports must be available on each member:
- The management port (by default, 8089) must be available to all other members.
- The http port (by default, 8000) must be available to any browsers accessing data from the member.
- The KV store port (by default, 8191) must be available to all other members. You can use the CLI command
splunk show kvstore-portto identify the port number.
- The replication port must be available to all other members.
These ports must be in your firewall's list of allowed ports.
Caution: Do not change the management port on any of the members while they are participating in the cluster. If you need to change the management port, you must first remove the member from the cluster.
Synchronize system clocks across the distributed search environment
It is important that you synchronize the system clocks on all machines, virtual or physical, that are running Splunk Enterprise instances participating in distributed search. Specifically, this means your cluster members and search peers. Otherwise, various issues can arise, such as search failures, premature expiration of search artifacts, or problems with alerts.
The synchronization method you use depends on your specific set of machines. Consult the system documentation for the particular machines and operating systems on which you are running Splunk Enterprise. For most environments, Network Time Protocol (NTP) is the best approach.
You need a Splunk Enterprise instance that functions as the deployer. The deployer updates member configurations. See "Use the deployer to distribute apps and configuration updates".
Deployer functionality is only for use with search head clustering, but it is built into all Splunk Enterprise instances running version 6.2 or above. You have several options as to the instance on which you run the deployer:
- If you have a deployment server that is servicing only a small number of deployment clients (no more than 50), you can run the deployer on the same instance as the deployment server. The deployer and deployment server functionalities can interfere with each other at larger client counts. See "Deployment server provisioning" in the Updating Splunk Enterprise Instances manual.
- If you are running an indexer cluster, you might be able to run the deployer on the same instance as the indexer cluster master node. Whether this option is available to you depends on the master's load. See "Additional roles for the master node" in the Managing Indexers and Clusters of Indexers manual for information on cluster master load limits.
- If you have a distributed management console, you can run the deployer on the same instance as the console. See "Configure the distributed management console" in the Admin Manual.
- If none of the instance types enumerated above are available, run the deployer on a dedicated Splunk Enterprise instance.
Important: Do not locate deployer functionality on a search head cluster member. The deployer must be a separate instance from any cluster member.
A deployer can service only a single search head cluster. If you have multiple clusters, you must use a separate deployer for each one. The deployers must run on separate instances.
Deployment server and search head clusters
Do not use deployment server to update cluster members.
The deployment server is not supported as a means to distribute configurations or apps to cluster members. To distribute configurations across the set of members, you must use the search head cluster deployer. See "Use the deployer to distribute apps and configuration updates".
Search head clustering and search head pooling
You cannot enable search head clustering on an instance that is part of a search head pool. For information on migrating, see "Migrate from a search head pool to a search head cluster".
Search head clustering architecture
Deploy a search head cluster
This documentation applies to the following versions of Splunk® Enterprise: 6.2.0, 6.2.1, 6.2.2, 6.2.3, 6.2.4, 6.2.5, 6.2.6, 6.2.7, 6.2.8, 6.2.9, 6.2.10, 6.2.11, 6.2.12, 6.2.13, 6.2.14, 6.2.15