Distributed Clustered Deployment with SHC - Multisite (M3 / M13)

The following diagram represents a Multisite Distributed Clustered Deployment with a Search Head Cluster (SHC) topology:

Architecture overview

The Multisite Distributed Clustered Deployment with a Search Head Cluster (SHC) topology uses a search head cluster (SHC) to add horizontal scalability, and removes the single point of failure from the search tier in each site. To implement an SHC, you need at least three search heads per site.

To manage the SHC configuration, use a search head cluster deployer for each SHC. Using this Splunk software component, you can deploy changes to configuration files in the cluster. The search head cluster deployer has no high availability (HA) requirements, that is, has no runtime role.

A cluster manager manages a multisite cluster. If a disaster occurs and a single cluster manager is used, fail it over to the disaster recovery (DR) site. Alternatively, you can deploy high availability (HA) cluster managers to automate this process. To learn about HA cluster managers, see High availability deployment: indexer cluster in the Splunk Enterprise Distributed Deployment manual.

Benefits

The benefits of this topology include the following:

• To meet specific requirements, for example, to run some of the Splunk premium applications that require dedicated search environments, you can deploy one or more independent SHCs.
• Using the SHC, you ensure the following:
  • Increase in available search capacity beyond what a single search head can provide
  • Distribution of scheduled search workload across the cluster
  • Optimal user failover if a search head fails

Limitations

The limitations of this topology include:

• No sharing of available search head capacity and no replication of a search artifacts across sites.
• Necessity to keep cross-site latency for index replication within limits. To learn about the network latency limits, see Network latency limits for clustered deployments in the Splunk Enterprise Capacity Planning manual.

To ensure the best experience, see Splunk Enterprise service limits in the Splunk Enterprise Capacity Planning manual.

Additional considerations

When using the topology, you may find the following information helpful:

• Customers deploying Splunk Enterprise on cloud service providers like Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure can leverage object store services for SmartStore implementation. See SmartStore system requirements in the Splunk Enterprise Managing Indexers and Clusters of Indexers manual.
• To monitor the health of your Splunk environment, deploy the monitoring console (MC).
• To make sure that users remain on a single search head throughout their session, in front of the SHC members, use a third-party network load-balancer that supports sticky sessions. To learn about the network load-balancer, see Use a load balancer with search head clustering in the Splunk Enterprise Distributed Search manual.
• Activate standby auxiliary services, such as a deployment server (DS), license manager (LM), MC, and search head cluster deployer (SHC-D), if they fail in the primary site.
• To manage high availability (HA) cluster managers, use an application load balancer. To learn about the load balancer, see Use a load balancer to support cluster manager redundancy in the Splunk Enterprise Managing Indexers and Clusters of Indexers manual.
• Customers considering deployment of Enterprise Security (ES) in an M13 category code should review the guidance for installation of ES in search head cluster environments. Splunk strongly recommends engaging with Splunk Professional Services when deploying ES in a HA/DR environment. See Install Splunk Enterprise Security in a search head cluster environment in the Splunk Enterprise Security Install and Upgrade Splunk Enterprise Security manual.