READ THIS FIRST: Key differences between clustered and non-clustered deployments
This topic describes key differences between clustered and non-clustered indexers. In particular, it discusses issues regarding system requirements and deployment.
Read this topic carefully if you plan to migrate your current set of indexers to a cluster.
Do not use deployment server or third-party deployment tools with cluster peers
Neither the deployment server nor any third party deployment tool (such as Puppet or CFEngine, among others) is supported as a means to distribute configurations or apps to cluster peers (indexers).
To distribute configurations across the set of cluster peers, instead use the configuration bundle method outlined in the topic "Update common peer configurations". As that topic explains, the configuration bundle method involves first placing peer apps on the master node, which then distributes those apps to the peer nodes in a coordinated fashion. If desired, you can use deployment server or third-party tools to first place the peer apps on the master node.
For information on how to migrate app distribution from the deployment server to the configuration bundle method, see "Migrate apps to a cluster".
Note: You can, however, use deployment server to distribute updates to cluster search heads.
Differences in system requirements
Peer nodes have some different system requirements compared to non-clustered indexers. Before migrating your indexer, read the topic "System requirements and other deployment considerations". In particular, be aware of the following differences:
- When you convert an indexer to a cluster peer, disk usage will go up significantly. Make sure you have sufficient disk space available, relative to daily indexing volume, search factor, and replication factor. For detailed information on peer disk usage, read "Storage considerations".
- The peer node should reside on a high speed network with the other cluster components, as described in "Network requirements".
- Cluster components cannot share Splunk Enterprise instances. The master node, peer nodes, and search head must each run on its own instance.
Other considerations and differences from a non-cluster deployment
In addition, note the following:
- For most types of cluster deployments, you should enable indexer acknowledgment for the forwarders sending data to the peer. This will have some effect on indexing performance. See "How indexer acknowledgment works".
- There will be some overall reduction in performance due to a few factors; mainly, indexer acknowledgment, as well as the need to store, and potentially index, replicated data coming from other peer nodes.
- When restarting cluster peers, you should use Splunk Web or one of the cluster-aware CLI commands, such as
splunk rolling-restart. Do not use
splunk restart. For details, see "Restart the entire cluster or a single cluster node".
Migrate a non-clustered indexer
To learn how to migrate an existing indexer to a cluster and the ramifications of doing so, read the topic "Migrate non-clustered indexers to a cluster".
System requirements and other deployment considerations
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