Splunk® Enterprise

Managing Indexers and Clusters of Indexers

SmartStore system requirements

The requirements for SmartStore-enabled indexers are basically the same as for non-SmartStore-enabled indexers. The main differences are:

  • Local storage requirements
  • The need to connect to remote storage

Indexer requirements

Indexer hardware requirements

Hardware requirements, with the exception of local storage (see below), are the same as for any Splunk Enterprise indexer. See:

SmartStore operations generally have no significant impact on CPU performance.

Indexer hosting options

The type of object storage used for SmartStore determines where the indexers must be hosted:

  • Indexers running SmartStore with an AWS S3 remote store must be hosted on AWS.
  • Indexers running SmartStore with a GCP GCS remote store must be hosted on GCP.
  • Indexers running SmartStore with an Azure Blob remote store must be hosted on Azure.
  • Indexers running SmartStore with S3 API-compliant on-premises object storage must be hosted in an on-premises data center.

Local storage requirements

Based on your indexer deployment type, provision local storage as follows::

  • If you are running Splunk Enterprise indexers on local Linux machines, the preferred local storage type is SSD.
  • If you are running Splunk Enterprise indexers on AWS, use AWS with NVMe SSD Instance Storage (for example, AWS i3ens or i3s).
  • If you are running Splunk Enterprise indexers on GCP, use N1-high memory machine type (n1-highmem-64 or n1-highmem-32 preferred) with zonal SSD persistent disks.
  • If you are running Splunk Enterprise indexers on Azure, use Azure with high memory instance + SSD (E series, like Edv4 and Edsv4-series).

The amount of local storage available on each indexer for cached data must be in proportion to the expected working set. For best results, provision enough local storage to accommodate the equivalent of 30 days' worth of indexed data. For example, if the indexer is adding approximately 100GB/day of indexed data, the recommended size reserved for cached data is 3000GB. At a minimum, provision enough storage to keep at least 7-10 days of data in cache, as searches typically occur on data indexed within the last 7 - 10 days.

For use with Splunk Enterprise Security, provision enough local storage to accommodate 90 days' worth of indexed data, rather than the otherwise recommended 30 days.

Note: The size of data indexed is typically around 50% of the size of data ingested, due to compression of data during indexing. However, there are a number of other factors that also enter into determining the size ratio of indexed data to ingested data. For a general discussion of Splunk Enterprise data volume and how to estimate your storage needs, refer to "Estimating your storage requirements" in the Installation Manual.

For indexer clusters, other factors that enter into determining storage requirements include:

  • The distribution of ingested data across the indexer cluster. Strive for balanced data ingestion across the indexers, so that all the indexers are indexing, and storing, approximately the same amount of data.
  • The number of hot buckets on the indexers. Hot buckets follow replication and search factor policies, so they have, on a per bucket basis, larger storage requirements than warm buckets of the same size.

For purposes of configuring size, the cache is identical with the partition that the cache resides on. Typically, that partition also includes many other files, such as splunk binaries, the operating system, search artifacts, non-SmartStore indexes (if any), and so on. The index data itself resides in $SPLUNK_DB. Therfore, you must consider such files when provisioning storage and configuring cache size. For more information on cache sizing, see "Initiate eviction based on occupancy of the cache's disk partition".

Operating system requirements for on-premise deployments

If you are running Splunk Enterprise in your data center, each on-premise machine must run the same Linux 64-bit operating system.

No other operating systems are supported for on-premise deployments of SmartStore.

Splunk Enterprise version requirements

Standalone indexers must be running Splunk Enterprise version 7.2 or later.

In the case of indexer clusters, all nodes (manager, peer, and search head) in the cluster must be running Splunk Enterprise version 7.2 or later. Additional version compatibility requirements apply to nodes in any indexer cluster, as described in Splunk Enterprise version compatibility.

Other indexer cluster requirements

All indexer cluster requirements apply to SmartStore indexes. For example:

  • All index-related settings, including SmartStore-settings, must be configured identically across the peer nodes.
  • You must enable SmartStore for the same set of indexes on all peer nodes.
  • When you add a new index stanza, you must set repFactor to "auto".

For indexer cluster requirements in general, see System requirements and other deployment considerations for indexer clusters.

Network requirements

The indexers are clients of the remote store and use the standard https port to communicate with it.

For optimal performance, use 10Gbps network connectivity from each indexer to the remote store.

Remote store requirements

SmartStore can run on either an AWS S3 remote store (including S3 API-compliant on-premise object stores), a GCP GCS remote store, or an Azure Blob remote store. Depending on which remote store type you plan to deploy on, see Configure the S3 remote store for SmartStore, Configure the GCS remote store for SmartStore, or Configure the Azure Blob remote store for SmartStore

Multiple indexer clusters or standalone indexers cannot access the same remote volume. In other words, the value of any path setting in indexes.conf must be unique to a single running indexer or cluster. Do not share path settings among multiple indexers or clusters.

Last modified on 07 September, 2023
SmartStore architecture overview   Configure the S3 remote store for SmartStore

This documentation applies to the following versions of Splunk® Enterprise: 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.2.0, 9.2.1, 9.2.2, 9.2.3, 9.2.4, 9.3.0, 9.3.1, 9.3.2, 9.4.0


Was this topic useful?







You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters