Distributed Clustered Deployment - Multisite (M2 / M12)

The following diagram represents a Distributed Multisite Clustered Deployment topology:

Architecture overview

The Multisite Distributed Clustered Deployment topology provides near-automatic disaster recovery (DR) in case of a catastrophic event, like a data center outage. Using this topology, you can deterministically replicate data to two or more sites of indexer cluster peers by configuring the site replication and search factor. Through configuring the site replication factor, you specify where to send replica copies to ensure data distribution across multiple failure domains.

A cluster manager manages a multisite cluster. If a disaster occurs and a single cluster manager is used, fail it over to the 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:

• Data redundancy across physically-separated distributed locations that multisite clustering provides, and the possibility of geographically separated distribution. It is subject to limitations in the Architecture overview section.
• Possibility to configure search affinity to use the WAN link between sites only if a search cannot be satisfied locally. To learn about search affinity, see Implement search affinity in a multisite indexer cluster in the Splunk Enterprise Managing Indexers and Clusters of Indexers manual.

Limitations

The limitation of this topology include the following:

• No sharing of available search head capacity and no replication of a search artifact across sites.
• If a site fails, inability to handle a failure of management functions through the Splunk software.
• System requirements and other deployment considerations for indexer clusters. To learn about system requirements, see System requirements and other deployment considerations for indexer clusters in the Splunk Enterprise Managing Indexers and Clusters of Indexers manual.
• Necessity to keep cross-site latency for index replication within limits. To learn about 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:

• To learn about SmartStore deployment, see SmartStore system requirements in the Splunk Enterprise Managing Indexers and Clusters of Indexers manual.
  • 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.
• To monitor the health of your Splunk environment, deploy the monitoring console (MC).
• 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.