Use clusters for high availability and ease of management (original) (raw)

You can group certain Splunk Enterprise components into clusters, so that they closely coordinate their activities. This serves two key purposes:

• High availability
• Ease of management

Indexer clusters

An indexer cluster is a group of Splunk Enterprise indexers that are configured to replicate each others' data, so that the system keeps multiple copies of all data. This process is known as index replication. By maintaining multiple, identical copies of Splunk Enterprise data, the cluster prevents data loss while promoting data availability for searching.

Splunk Enterprise clusters feature automatic failover from one indexer to the next. This means that, if one or more indexers fail, incoming data continues to get indexed and indexed data continues to be searchable.

Besides enhancing high availability, clusters have other features that help to simplify the management of a distributed deployment. For example:

• They include a capability to coordinate configuration updates easily across all indexers in the cluster.
• They include a built-in distributed search capability.
• They feature indexer discovery, which enables the set of forwarders to automatically load-balance across all indexers in the cluster.

Even if high availability is not a concern in your environment, you can still take advantage of the simplified management features by deploying an indexer cluster without index replication.

For guidance on implementing an indexer cluster, see "High availability deployment: Indexer cluster."

Search head clusters

A search head cluster is a group of search heads that serves as a central resource for searching. The search heads share knowledge objects, apps, and all other configurations. You can run the same searches, view the same dashboards, and access the same search results from any search head in the cluster.

Search head clusters provide several important benefits:

• Horizontal scaling. As the number of users and the search load increases, you can add new search heads to the cluster. By combining a search head cluster with a third-party load balancer placed between users and the cluster, the topology can be transparent to the users.
• High availability. If a search head goes down, you can run the same set of searches and access the same set of search results from any other search head in the cluster.
• No single point of failure. The search head cluster uses a dynamic captain to manage the cluster. If the captain goes down, another search head automatically takes over management of the cluster.

For guidance on implementing a search head cluster, see "Medium to large enterprise deployment: Search head cluster with multiple indexers."

| | Scale your deployment with Splunk Enterprise components | | How data moves through Splunk deployments: The data pipeline | | | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | ----------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- |

This documentation applies to the following versions of Splunk® Enterprise: 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.0.9, 7.0.10, 7.0.11, 7.0.13, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.1.8, 7.1.9, 7.1.10, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6, 7.2.7, 7.2.8, 7.2.9, 7.2.10, 7.3.0, 7.3.1, 7.3.2, 7.3.3, 7.3.4, 7.3.5, 7.3.6, 7.3.7, 7.3.8, 7.3.9, 8.0.0, 8.0.1, 8.0.2, 8.0.3, 8.0.4, 8.0.5, 8.0.6, 8.0.7, 8.0.8, 8.0.9, 8.0.10, 8.1.0, 8.1.1, 8.1.2, 8.1.3, 8.1.4, 8.1.5, 8.1.6, 8.1.7, 8.1.8, 8.1.9, 8.1.10, 8.1.11, 8.1.12, 8.1.13, 8.1.14, 8.2.0, 8.2.1, 8.2.2, 8.2.3, 8.2.4, 8.2.5, 8.2.6, 8.2.7, 8.2.8, 8.2.9, 8.2.10, 8.2.11, 8.2.12, 9.0.0, 9.0.1, 9.0.2, 9.0.3, 9.0.4, 9.0.5, 9.0.6, 9.0.7, 9.0.8, 9.0.9, 9.0.10, 9.1.0, 9.1.1, 9.1.2, 9.1.3, 9.1.4, 9.1.5, 9.1.6, 9.1.7, 9.1.8, 9.1.9, 9.2.0, 9.2.1, 9.2.2, 9.2.3, 9.2.4, 9.2.5, 9.2.6, 9.3.0, 9.3.1, 9.3.2, 9.3.3, 9.3.4, 9.4.0, 9.4.1, 9.4.2