About deployment server and forwarder management
Important: Before reading this manual, you should be familiar with the fundamentals of Splunk Enterprise distributed deployment, as described in the Distributed Deployment Manual.
Splunk Enterprise provides the deployment server, with its forwarder management interface, to manage the update process across distributed instances of Splunk Enterprise.
What is deployment server?
The deployment server is the tool for distributing configurations, apps, and content updates to groups of Splunk Enterprise instances. You can use it to distribute updates to most types of Splunk Enterprise components: forwarders, non-clustered indexers, and search heads.
The deployment server is just a Splunk Enterprise instance that has been configured to manage the update process across sets of other Splunk Enterprise instances. Depending on the number of instances it's deploying updates to, the deployment server instance might need to be dedicated exclusively to managing updates. For more information, read "Plan a deployment".
|The deployment server handles configuration and content updates to existing Splunk Enterprise installations. You cannot use it for initial or upgrade installations of Splunk Enterprise or the universal forwarder. To learn how to install and deploy Splunk Enterprise, see Step-by-step installation procedures for full Splunk Enterprise and Install the universal forwarder software for the Splunk Enterprise universal forwarder. To learn how to upgrade your deployment to a new version of Splunk Enterprise, see Upgrade your distributed Splunk Enterprise deployment in the Installation Manual.|
Is deployment server mandatory?
Deployment server is not required for managing forwarders and other Splunk Enterprise instances. If you prefer, you can use a third-party tool, such as Chef, Puppet, Salt, or one of the Windows configuration tools.
What is forwarder management?
Forwarder management is a graphical interface built on top of deployment server that provides an easy way to configure the deployment server and monitor the status of deployment updates. Although its primary purpose is to manage large groups of forwarders, you can use forwarder management to configure the deployment server for any update purposes, including managing and deploying updates to non-clustered indexers and search heads. For most purposes, the capabilities of forwarder management and the deployment server are identical. For more information, see "Forwarder management overview".
Important: If you are upgrading from a pre-6.0 version of the deployment server, your existing
serverclass.conf file might not be compatible with the forwarder management interface. This is because forwarder management can handle only a subset of the configurations possible through
serverclass.conf. In some cases, you might need to continue to work directly with
serverclass.conf, rather than switching to forwarder management as your configuration tool. For details on what configurations are compatible with forwarder management and how to handle deployment server upgrades, see the topic "Compatibility and forwarder management".
What the deployment server offers
The deployment server makes it possible to group Splunk Enterprise components by common characteristics and then distribute content based on those groups.
For example, if you've got Splunk Enterprise instances serving a variety of different needs within your organization, it's likely that their configurations vary depending on who uses them and for what purpose. You might have some instances serving the help desk team, configured with a specific app to accelerate troubleshooting of Windows desktop issues. You might have another group of instances in use by your operations staff, set up with a few different apps designed to track network issues, security incidents, and email traffic management. A third group of instances might serve the Web hosting group within the operations team.
Rather than trying to manage and maintain these divergent Splunk Enterprise instances one at a time, you can group them based on their use, identify the configurations and apps needed by each group, and then use the deployment server to update their apps and configurations when needed.
In addition to grouping Splunk Enterprise instances by use, there are other useful types of groupings you can specify. For example, you might group instances by OS or hardware type, by version, or by geographical location or timezone.
A key use case is to manage configurations for groups of forwarders. For example, if you have forwarders residing on a variety of machine types, you can use the deployment server to deploy different content to each machine type. The Windows forwarders can get one set of configuration updates; the Linux forwarders another, and so on.
Deployment server and clusters
You cannot use the deployment server to update indexer cluster peer nodes or search head cluster members.
Do not use deployment server or forwarder management to manage configuration files across peer nodes (indexers) in an indexer cluster. Instead, use the configuration bundle method. You can, however, use the deployment server to distribute updates to the master node, which then uses the configuration bundle method to distribute them to the peer nodes. See "Update common peer configurations" in the Managing Indexers and Clusters of Indexers manual.
Search head clusters
Do not use deployment server to update search head cluster members.
The deployment server is not supported as a means to distribute configurations or apps to cluster members. To distribute configurations across the set of members, you must use the search head cluster deployer. See "Use the deployer to distribute apps and configuration updates" in the Distributed Search manual.
Deployment server architecture
This documentation applies to the following versions of Splunk® Enterprise: 6.4.0, 6.4.1, 6.4.2, 6.4.3, 6.4.4, 6.4.5, 6.4.6, 6.4.7, 6.4.8, 6.4.9, 6.4.10, 6.5.0, 6.5.1, 6.5.1612 (Splunk Cloud only), 6.5.2, 6.5.3, 6.5.4, 6.5.5, 6.5.6, 6.5.7, 6.5.8, 6.5.9, 6.6.0, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 6.6.7, 6.6.8, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.1.0, 7.1.1, 7.1.2