A deployment server is Splunk instance that acts as a centralized configuration manager, grouping together and collectively managing any number of Splunk servers. Any Splunk instance -- even ones indexing data locally -- can act as a deployment server. Splunk servers that are remotely configured by deployment servers are called deployment clients. A Splunk instance can be both a deployment server and client at the same time.

NOTE: This section is purely instructional. If you want an overview of all deployment configuration options and concerns, read the Deployment Manual first.
Communication between deployment server and clientSplunk deployment currently supports two different methods for client/server communication: multicast or polling. Multicast only works on a LAN. Polling, however, can broadcast across subnets. If your Splunk deployment spans multiple subnets, you must use polling. If you're just setting up deployment within a LAN, multicast is the recommended method. All communications is sent via SSL.
Configurations for deployment server and clients are dependent on one-another. For example, if you use multicast, you must use it on both client and server.
To set up a deployment server, read about configuring the deployment server. To configure a client, see this page.
Server classesClient configurations are managed by membership in server classes. Server classes share common configuration definitions and are managed as a unit. A deployment client may be a member of multiple server classes at once, depending on which configurations updates it should be aware of. Group clients by application, OS, data type to be indexed or any other feature of your Splunk deployment.
Usually, class membership is stored in deployment.conf on the server side. By default, the deployment server stores configuration bundles in $SPLUNK_HOME/etc/modules/distributedDeployment/classes, arranged in subdirectories by class name. For example, you have the following server classes: web, apache, OS. Your $SPLUNK_HOME/etc/modules/distributedDeployment/classes must contain three subdirectories: ../web/, ../apache/ and ../OS/.
To set up server classes, read about configuring server classes.
Configuration file deploymentTo make changes to configurations for a server class, edit the specific configuration file within the server class subdirectory. Then, reload the server configurations. Clients that are members of the affected server class receive the configurations in a tarball. The client stores the tarball in its $SPLUNK_HOME/etc/bundles/ directory, named by server class and timestamp. Finally, the client restarts Splunk to reload configuration changes.
Note: Although in version 3.3 the Splunk configuration directory structure has changed (to $SPLUNK_HOME/etc/system, as described here), the Deployment server still uses the old configuration directory structure for backwards compatibility purposes.
The configuration fetch procedure generates an event in the Splunk logs. Splunk administrators can search for the event to check that all deployments worked properly. If the configuration fetch and kick procedure did not work properly, the previous configurations are restored and an event detailing this is sent to the indexer.
For details on configuration changes, see configuration changes after initial deployment.
Note: Currently, the deployment server does not push scripted inputs. In the future, Splunk will support this behavior. For now, use your preferred configuration automation tool to push your script directory to clients.
Configuration files for deployment serverBoth deployment servers and clients are configured in deployment.conf.
Comments
No comments have been submitted.