This documentation does not apply to the most recent version of Splunk.
This documentation applies to the following versions of Splunk: 3.0 , 3.0.1 , 3.0.2 , 3.1 , 3.1.1 , 3.1.2 , 3.1.3 , 3.1.4
Splunk can be deployed on a single server or multiple servers, depending on your needs. You can install Splunk on a dedicated server or on a server running other applications -- Splunk does not require special hardware. In a multi-server deployment, Splunk can be configured to support redundancy, data balancing, distributed searching and data access control. This section defines the Splunk deployment terms and presents general deployment guidelines. Continue reading the deployment section for more specifics on these various configurations.
A single server installation refers to any network that contains only one running instance of Splunk. That instance can receive data over network ports (including syslog over TCP/UDP), and tail or watch locally available files and directories. Mounted fileshares can provide for access to files from other servers.
Splunk can be installed on each production server that is generating logs and other data that you want to index. These light-weight Splunk servers can be configured to forward their data to a central, dedicated Splunk server for indexing. The forwarding servers can also index a copy locally although that adds overhead and is rarely necessary.
Your production environment may generate more data than one Splunk server can index. In this case, you may want to distribute indexing across multiple Splunk servers. For example, if you have terabytes of data to index a day, you can distribute this data across 10 servers, each indexing 100 gigabytes per day.
You can distribute indexing amongst multiple servers in one of two ways. Either different subsets of Splunk servers can forward their data to different Splunk servers for indexing, or each Splunk server can balance its forwarding among the entire cluster of central indexing servers.
You may want to index multiple copies of your events to ensure high availability of your data. In this case, each Splunk server that is capturing data clones its data to multiple Splunk servers for indexing. For more complete data redundancy, other network-based logging sources can also be configured to direct their traffic to multiple Splunk servers for indexing.
You may want to partition your data into separate data stores because you have varying policies or uses for different subsets of your data. Splunk allows you to create conditional rules for routing data from one Splunk server to multiple Splunk servers, or to different indexes on a single server.
You can distribute events over multiple servers in order to limit data access to specific servers or classes of users. With conditional routing, events can be written to indexers based on the host, source or source type, or by applying regular expressions to events. For example, application log data can be sent to a server (or series of servers) and network events sent to another.
With granular access controls, a Splunk administrator can restrict access to indexers. Those users supporting specific applications can be granted access only to the indexers containing relevant data, while the Splunk senior administrator can maintain control over all servers.
You may wish to set different data retention policies depending on your sources, sourcetypes or hosts. Routing allows you to send your data to specific Splunk servers which may then apply different rules for data retirement.
You may have a requirement to send data from Splunk to a non-Splunk system, for example, a Managed Security Service Provider (MSSP). In such an environment, Splunk may be used to log all relevant data for troubleshooting, reporting, compliance, or security investigations. Splunk then sends data to the third-party system via network ports.
You can use LDAP to authenticate users and authorize their access to Splunk. This greatly simplifies the management of users in a multi-server Splunk environment.