Deployment planning

You must have a pre-configured Splunk platform installation to implement Splunk Enterprise Security. There are several architectures and features to consider when implementing Splunk software.

Common deployment architectures

This topic covers how to integrate Splunk Enterprise Security in the following common deployment architectures:

• Single instance deployment
• Cloud deployment
• Distributed search deployment

The recommended deployment architectures share common components:

Search head	A Splunk platform instance that is the central location for Splunk software apps and search knowledge, hosting the users, and providing authentication and authorization. The search head also manages and directs search requests to the few or many indexers. Splunk Enterprise Security must be installed on its own search head.
Indexer	A Splunk platform instance that processes search requests from search heads. The indexer also accepts incoming data streams from forwarders, transforms the streams into events, and writes the events into indexes.
Forwarder	A light weight Splunk platform instance that obtains and streams data to the indexers. Forwarders are designed to load balance the data streams between indexers.

Single instance deployment

When designing simple and small deployments, use a single Splunk platform instance with Splunk Enterprise Security installed. A single instance serves both the search head and indexer logistical roles, accepting data streams from forwarders along with parsing, storing, and searching the data. A single instance Splunk platform configuration is often used for a lab or test environment, and supports one or two users running concurrent searches. For more information about storage requirements and Enterprise Security, see Indexers in this topic.

Whenever possible, use forwarders for data collection.

Cloud deployment

Splunk Enterprise Security is available as a service in Splunk Cloud. The Splunk Cloud deployment architecture varies based upon data and search load. Splunk Cloud customers will work with Splunk Support to setup, manage, and maintain their cloud infrastructure. For information on Splunk Cloud managed deployments, see the Types of Splunk Cloud deployment in the Splunk Cloud User manual.

Distributed search deployments

A distributed Splunk Enterprise deployment is recommended when running Splunk Enterprise Security. A dedicated search head hosting Enterprise Security provides the user interface and search management roles. A collection of indexers provides improved search performance by distributing the workload of searching data across more nodes. Having multiple indexers also allows distribution of both the incoming data streams from the forwarders and the workload of processing those streams.

For scaling recommendations, see Indexers in this topic . To review critical details in determining scale and the hardware required, see Introduction to capacity planning for Splunk Enterprise in the Capacity Planning Manual.

Whenever possible, use forwarders for data collection.

Splunk Enterprise system requirements

Splunk Enterprise Security requires a 64-bit OS install on all search heads and indexers. Use this table to determine the compatibility of the ES 4.2.x versions and Splunk platform versions.

Splunk Enterprise Security version	Splunk platform version
4.2.0	6.4.x
4.2.1	6.4.x and 6.5.x
4.2.2	6.4.x and 6.5.x

For the list of supported operating systems, browsers, and file systems, see System Requirements in the Splunk Enterprise Installation Manual.

Note: Configuring a Splunk platform instance on a *nix OS requires a review of the ulimit settings. See Considerations regarding file descriptor limits (FDs) on *nix systems in the Splunk Enterprise Installation Manual.

Search Head considerations

Splunk Enterprise Security supports installation on one dedicated search head or dedicated search head cluster. Install only Common Information Model (CIM) compatible add-ons on a search head or search head cluster hosting Enterprise Security.

Splunk Enterprise Security requires all real-time searches to use the indexed real-time setting for improved indexing performance. For more information, see About real-time searches and reports in the Search Manual. If you revert the configuration, that will reduce the overall indexing capacity. To review the performance implications, see Known limitations of real-time searches in the Search Manual.

CPU cores

An Enterprise Security search head requires a minimum of 16 CPU cores. Additional cores are necessary depending on search concurrency, search type, and number of users. For the latest reference hardware requirements for Splunk Enterprise, see Reference Hardware: Dedicated search head in the Capacity Planning Manual

Note: SPARC platform support is a deprecated feature, and cannot be used to host Enterprise Security.

Memory

An Enterprise Security search head requires a minimum of 32GB of RAM. Add additional memory to address search concurrency, the number of correlation searches enabled, and the size of the asset and identity tables referenced by Enterprise Security.

Forward search head data to indexers

In a distributed search deployment, configure the search head to forward all data to the indexers. See Forward search head data to the indexer layer in the Distributed Search manual. You must use this configuration to implement search head clustering.

Deployment Client

The installation of Enterprise Security on a search head will not complete if apps or add-ons included in the ES package are managed by a deployment server. Before beginning the ES installation, remove the deploymentclient.conf containing references to the deployment server and restart Splunk services.

Search head pooling

Splunk Enterprise Security does not support search head pooling.

Search head clustering

Splunk Enterprise Security supports installation on Linux-based search head clusters only. A search head cluster multiplies the maximum search concurrency of the Splunk environment by the number of search heads in the cluster. To manage the increase in search load, add more indexers or allocate additional cores to the indexers when implementing a search head cluster. For a complete list of requirements, see System requirements and other deployment considerations for search head clusters in the Splunk Enterprise Distributed Search Manual. For details on search head clustering architecture, see Search head clustering architecture in the Distributed Search Manual.

Using Splunk Enterprise Security alongside other apps

Install only CIM compatible add-ons on a search head or search head cluster hosting Enterprise Security.

KV Store

Splunk Enterprise Security requires use of the KV Store feature. For more information about KV Store, including the system requirements, see About the app key value store in the Splunk Enterprise Admin Manual.

Forward search head data to indexers

The search head cluster members must send all locally-generated data to the indexers. See the topic Forward data from search head cluster members in the Splunk Enterprise Distributed Search Manual.

Deploying configuration changes in a search head cluster

Using search head clustering changes the process for deploying apps and configuration files to the search head cluster members. To distribute app and add-on configurations across a set of search head cluster members, you must use the search head cluster deployer. See Installing Add-ons on a Search Head cluster in this manual.

To enable the deployer to manage configuration files with hashed passwords, the captain replicates its splunk.secret file to all other cluster members during initial deployment of the cluster. For more information, see Deploy secure passwords across multiple servers in the Securing Splunk Enterprise Manual.

Indexer considerations

Indexing is an I/O-intensive process. The indexers require sufficient disk I/O to ingest and parse data efficiently while responding to search requests. For the latest IOPS requirements to run Splunk Enterprise, see Reference Hardware: Indexer in the Capacity Planning Manual.

A collection of indexers can serve more than one search head. Additional search heads using the same indexers will impact the total performance, and reduce the resources available to the Enterprise Security search infrastructure. You should always increase the number of indexers to scale with increases in search load and search concurrency.

CPU cores

An Enterprise Security indexer requires a minimum of 16 CPU cores. If the number of indexer CPU cores exceeds these specifications, consider implementing one of the parallelization settings to improve the indexer performance for specific use cases. For more information, see Parallelization settings in the Capacity Planning Manual.

Memory

An Enterprise Security indexer requires a minimum of 32GB of RAM.

Performance test results

The Splunk platform uses indexers to scale horizontally. The number of indexers required in an Enterprise Security deployment varies based on the data volume, data type, retention requirements, search type, and search concurrency.

The two largest factors in sizing Enterprise Security are correlation search load, and data model acceleration load based on data type and volume of data being accelerated. Depending on the data mix, the scaling volume can range from 40GB to 100GB per indexer.

Variables	Details
Reference Hardware	All indexers were configured with 32GB of RAM and 16 CPU cores.
Test scenario: utilize a mix of data models.
Data types	A selection of data sources with varying ratios were ingested and accelerated across 4 data models. Web: 65% of all data Network Traffic: 25% of all data Change Analysis: 1% of all data Authentication: 1% of all data with any remaining percentage not applicable to any data model.
Search Load	60 correlation searches were enabled. No additional user load was added.
Scaling results: Data Volume	100	300	500	800	1000
Scaling results: Indexer count	1	3	5	8	10
Summary: Each indexer sustained a 100GB/Day data ingestion while maintaining low latency for data model accelerations and UI responsiveness.
Test scenario: maximum utilization for one data model.
Data types	Ingest and accelerate data in the Network Traffic data model only.
Search Load	60 correlation searches were enabled. No additional user load was added.
Scaling results: Data Volume	40	120	200	320	400
Scaling results: Indexer count	1	3	5	8	10
Summary: Each indexer sustained a 40GB/Day data ingestion while maintaining low latency for the Network Traffic data model accelerations and UI responsiveness.

Indexes

Splunk Enterprise Security defines custom indexes for event storage. For more information about the indexes required, see Configure and deploy indexes in this manual.

Indexer Clustering

Splunk Enterprise Security supports both single site and multisite cluster architectures. See The basics of indexer cluster architecture and Multisite cluster architecture in the Managing Indexers and Clusters Manual.

A single site or multisite indexer cluster architecture may have one search head or search head cluster with a running instance of Enterprise Security. Additional single instance search heads cannot run Enterprise Security.

Using the clustering feature changes the method used to deploy apps and configuration files to the indexer peer nodes. See Manage common configurations across all cluster peers and Manage app deployment across all cluster peers in the Managing Indexers and Clusters Manual.

Data model accelerations

Splunk Enterprise Security accelerates data models to provide dashboard, panel, and correlation search results. Data model acceleration uses the indexers for processing and storage with the accelerated data being stored within each index. To calculate the additional storage needed on the indexers based on the total volume of data, use the formula:

Accelerated data model storage/year = Data volume per day * 3.4

This formula assumes that you are using the recommended retention rates for the accelerated data models.

Example: If you process 100GB/day of data volume for use with Enterprise Security, you need approximately 340GB more space available across all of the indexers to allow for up to one year of data model retention and source retention.

The storage used for data model acceleration is not added to index sizing calculations for maintenance tasks such as bucket rolling and free space checks. For more information, see Data model acceleration storage and retention in this manual.

TSIDX reduction compatibility

A retention policy for an index's TSDIX files is available in Splunk Enterprise 6.4.x. For more information, see Reduce tsidx disk usage in the Splunk Enterprise Managing Indexers and Clusters of Indexers manual. Setting a retention policy for the TSIDX files does not effect data model acceleration retention.

Some searches provided with Enterprise Security will not work on buckets with reduced TSIDX files.

Panel/Search Name	Default time range	Workaround
Forwarder Audit panel: Event Count Over Time by Host	-30d	Set the TSIDX retention to a value greater then the time range.
Saved Search: Audit - Event Count Over Time By Top 10 Hosts	-30d	Set the TSIDX retention to a value greater then the time range.
Saved Search: Audit - Events Per Day - Lookup Gen	-1d	Set the TSIDX retention to a value greater than the default time range.
Saved Search: Endpoint - Index Time Delta 2 - Summary Gen	-1d	Set the TSIDX retention to a value greater than the default time range.

Deployment server

The deployment server deploys apps to nodes within the Splunk platform environment. In a Splunk Enterprise Security environment, use the deployment server to deploy add-ons to forwarders and indexers.

The installation of Enterprise Security on a search head will not complete if apps or add-ons included in the ES package are managed by a deployment server. Before beginning the ES installation, remove the deploymentclient.conf containing references to the deployment server and restart Splunk services.

For information about the deployment server configuration and use, see About deployment server and forwarder management in the Updating Splunk Enterprise Instances Manual

The use of a Splunk platform clustering feature changes the method used to deploy apps and configuration files. Do not use the deployment server to deploy apps or add-ons to a search cluster or index cluster members. Each cluster tier, search heads and indexers, has their own configuration methodology and tool.

Splunk Enterprise Security includes a tool to gather the indexes.conf and index-time props.conf and transforms.conf settings from all enabled apps and add-ons on the search head and assemble them into one add-on. For more details, see Distributed Configuration Management in this manual.

Virtualized hardware

Installing Splunk Enterprise Security in a virtualized environment requires the same memory and CPU allocation as an installation in a non-virtualized, bare-metal environment. You must reserve all CPU and memory resources, with no oversubscription of hardware.

In a virtualized environment, test the storage IOPS across all Splunk platform indexer nodes simultaneously. The results from every node must conform to the Reference Hardware IOPS specified in the Capacity Planning Manual. Insufficient storage performance is a common cause for poor search response and timeouts when scaling the Splunk platform in a virtualized environment.

For VMware configuration details, review the technical brief: "Deploying Splunk Inside Virtual Environments: Configuring VMware Virtual Machines to Run Splunk" available in Splunk Resources.

Distributed Management Console

If the DMC is enabled on an ES search head, it must remain in a standalone mode. For more information on when and how to configure the DMC for use in a distributed environment, see Which instance should host the console? in the Splunk Enterprise Distributed Management Console Manual.

Enterprise Security compatibility with other apps

Enterprise Security relies on the search knowledge and CIM support supplied through add-ons. The add-ons are responsible for defining the event processing necessary to optimize, normalize, and categorize IT security data for use with the Common Information Model. Apps that are compatible with the ES are documented as CIM compatible.

Splunk apps and other add-ons that have been developed separately from Enterprise Security can include data knowledge that has not been normalized for the CIM, and could prevent ES searches and dashboards that rely on those fields from functioning properly.