Key differences between clustered and non-clustered deployments of indexers

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.

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 use deployment server to distribute updates to search heads in indexer clusters, as long as they are standalone search heads. You cannot use the deployment server to distribute updates to members of a search head cluster.

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 for indexer clusters". 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 that 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".
• Cluster nodes 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. See "How indexer acknowledgment works."
• You can simplify the process of connecting forwarders to peer nodes by using the indexer discovery feature. See "Advantages of the indexer discovery method."
• There will be some overall reduction in performance due to a few factors. The primary one is indexer acknowledgment. In addition, the need to store, and potentially index, replicated data coming from other peer nodes has some effect on performance.
• When restarting cluster peers, you should use Splunk Web or one of the cluster-aware CLI commands, such as splunk offline or splunk rolling-restart. Do not use splunk restart. For details, see "Restart the entire indexer 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 clustered environment".