Topology selection guidance

Initial publication: June 26, 2024
Last reviewed: June 10, 2024

Overview

This document was created to aid the selection of core Splunk software deployment topologies and associated Splunk Validated Architectures (SVAs). It is not, itself, an SVA. The document provides background information on the tier categories, the methodology used to construct a topology category code, and includes a questionnaire that may be used to align requirements for your architecture to a topology category code.

Topology categories

The following is a key to SVA topology categories. These categories are used in the questionnaire below. You will also find references to these categories in the next steps of the SVA selection process.

Indexing tier categories

Category code	Explanation
S	Category "S" indicates the indexer of a single-server Splunk deployment
D	Category "D" indicates the need for a distributed indexer tier with at least 2 indexers
C	Category "C" indicates the need for a clustered indexer tier (data replication is required)
M	Category "M" indicates the need for a clustered indexer tier with multiple sites

Search tier categories

Category code	Explanation
1	Category "1" indicates a single search head may meet the requirements
2	Category "2" indicates multiple search heads are required to meet requirements
3	Category "3" indicates a search head cluster is required to meet requirements
4	Category "4" indicates a search head cluster that spans multiple sites (a "stretched" SHC) is required to meet requirements
+10	Category "+10" indicates a dedicated search head (cluster) is required to support Enterprise Security App. Add 10 to the search tier topology category and carefully read the description for the topology for specific requirements for this app.

Determine your topology category code

In the following Defining Your Requirements for Index and Search, section you answer questions to help identify the topology that best aligns with your requirements. You answer a series of questions and, based on your answers, you construct a combined topology category indicator that allows you to identify the best topology for your needs.

Instructions

1. Write down the questions to which you answer "yes."
2. If you answer "yes" to multiple questions, follow the topology recommendation for the highest numbered question. If you see multiple topology options (for example, "D/C/M"), look at the previous questions to determine which option is best suited for you.
3. Your topology category code begins with the letter representing the indexer tier (for example, "C" or "M"). This letter is followed by the number representing the search tier (for example, "1" or "13").

Example #1 Assume you answer "yes" to questions #3, #5 and #8. You end up with a topology category of "C13", indicating the need for a clustered indexing tier with two search head clusters.

Example #2 Assume you answer "yes" only to question #1. You end up with a topology category of "S1", indicating a single-server deployment as your ideal topology.

Questionnaire for defining your requirements for index and search tiers

Review and answer the questions in the table below to determine your topology category code. If you answer "yes" to multiple questions, use the topology category code for the highest numbered question.

#	Question	Considerations	Impact on topology	Indexer tier topology category	Search tier topology category
1	Is your expected daily data ingest less than ~300GB/day?	Consider short-term growth in the daily ingest (~6-12 months).	Candidate for a single server deployment, depending on answers to availability-related questions.	S	1
2	Do you require indexing and capacity in excess of ~300GB/day without a highly availability requirement?	If you are not planning on using Splunk for monitoring use cases that require continuous data ingestion, a temporary interruption of the inbound data flow and/or search may be acceptable; assuming no log data is lost. Consider a clustered solution if data redundancy is required.	Requires distributed deployment to support continuous ingest. Requires a distributed deployment to support higher ingest than one indexer	D	1
3	Assuming an available Search Head to run a search: Does your data need to be completely searchable at all times, i.e. you cannot afford any impact to search result completeness?	If your use case is calculating performance metrics and general usage monitoring using aggregate functions, for example, a single indexer outage may not materially affect the calculation of statistics over a large number of events. If your use case is security auditing and threat detection, blind spots in search results are very likely undesirable.	Requires clustered indexers with a replication factor of at least two (2). Note: While a replication factor of 2 provides minimal protection against a single indexer node failure, the recommended (and default) replication factor is 3.	C	1
4	Do you operate multiple data centers and require automatic recovery of your Splunk environment in case of a data center outage?	Disaster recovery requirements may dictate continuous operation out of two facilities (active/active) or prescribe RTO/RPO goals for manual disaster recovery.	Continuous operation will require multi-site indexer clustering and at least two active search heads to ensure failover at both the data ingest/indexing tier as well as the search tier.	M	2
5	Assuming continuous, lossless data ingest, do you require HA for the user-facing search tier?	If Splunk software is being used for continuous, near-time monitoring, interruptions in the search tier are likely not tolerable. This may or may not be true for other use cases.	Requires redundant search heads, potentially search head clustering.	D/C/M	3
6	Do you need to support a large number of concurrent users and/or a significant scheduled search workload?	Requirements for more than ~50 concurrent users/searches typically require horizontal scaling of the search tier.	May require a topology that uses a search head cluster in the search tier,	D/C/M	3
7	In a multi-data center environment, do you require user artifacts (searches, dashboards and other knowledge objects) to be synchronized between sites?	This will decide whether users will have a current and consistent experience in case of a site outage.	Requires a "stretched" search head cluster across sites with appropriate configuration. Important: While a stretched SHC can improve search availability for users during a complete site failure, it cannot be guaranteed that all artifacts are replicated across both sites at all times. This may affect specific applications that rely on consistent and current artifacts, like the Splunk Enterprise Security. Search Head Clustering alone cannot provide a complete DR solution. Other benefits for SHC still apply.	M	4
8	Are you intending to deploy Splunk Enterprise Security (ES)?	Please ensure you read and understand the specific limitations Splunk Enterprise Security is subject to as documented with each topology.	ES requires a dedicated Search Head environment (either standalone or clustered).	D/C/M	+10
9	Do you have a geographically distributed environment that is subject to data custody regulations?	Some countries' regulations do not allow data generated within the country to leave systems in that country.	Such regulations prevent deployment of a central Splunk indexing tier and require a custom architecture to be developed by collaboration between Splunk/Partner and the customer that considers the details of such a deployment in depth. In other words, there is no SVA to meet this requirement.	Custom	Custom
10	Do you have highly restrictive security policies that prevent co-location of specific log data sources on shared servers/indexers?	Highly sensitive log data may not be allowed to be collocated with lower risk datasets on the same physical system/within the same network zone based on corporate policies.	Multiple, independent indexing environments are needed, potentially with a shared, hybrid search tier. This is beyond the scope of SVAs and requires custom architecture development.	Custom	Custom

Choose a topology for indexing and search

The primary goal of the SVA selection process is to allow you to build what you need without introducing unnecessary components. Keep in mind that even though non-clustered deployments come with reduced availability and disaster recovery features, this deployment option may still be a good choice for your organization. While you may choose to implement a topology that provides additional benefits beyond your immediate needs, keep in mind that this will likely result in unnecessary costs. Moreover, the Introduction of additional complexity is often counterproductive to operational efficiency.

Next steps

After identifying the topology code that is appropriate for your requirements, the next step is to review the Splunk Validated Architecture (SVA) that aligns with your topology code. Links to the SVAs are available in the left navigation under the Splunk Platform Indexing and Search header as well as individually below.

• Single Server Deployment (S1)
• Distributed Clustered Deployment - Single Site (C1 / C11)
• Distributed Clustered Deployment with SHC - Single Site (C3 / C13)
• Distributed Non-Clustered Deployment (D1 / D11)
• Distributed Clustered Deployment - Multisite (M2 / M12)
• Distributed Clustered Deployment with SHC - Multisite (M3 / M13)
• Distributed Clustered Deployment with SHC - Multisite (M4 / M14)

Splunk Lantern has additional content that may be valuable while planning your infrastructure. The Planning for infrastructure and resource scalability article published as part of the Splunk Outcome Paths provides additional information as your planning activities progress towards implementation.