How the deployment server works

How the deployment server works

This section describes the Splunk deployment server and its features. If you want an overview of the different ways you can design a Splunk deployment in your organization, check out the deployment information in the Community Wiki.

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 one 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.

To change the configuration of one or more of your Splunk deployment clients, you push out updated configuration information for a given server class (defined below) from the deployment server to the deployment clients that belong to the server class.

Note: If you're running Splunk 3.4 or later and looking for instructions on enabling the Splunk light forwarder via the deployment server, go here.

Note: The Splunk desktop configuration (available in version 3.4 and later) disables deployment server functionality, but supports running as a deployment client. To run the Splunk deployment server, you must disable the desktop configuration app. Refer to the topic about the Splunk desktop app for more information.

Server classes

A server class is a Splunk deployment client configuration that you have defined. To manage client configurations, assign a Splunk deployment client to one or more server classes. Then, you can manage all the Splunk deployment clients that belong to a given server class as a unit. A deployment client may be a member of multiple server classes at once. You can group clients by application, OS, data type to be indexed, or any other feature of your Splunk deployment.

In most cases, server class membership information is located on the deployment server in deployment.conf. By default, the deployment server stores the configuration information for each server class in $SPLUNK_HOME/etc/modules/distributedDeployment/classes, arranged in subdirectories by the name of the server class. For example, if you have defined 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.

How configuration files are deployed

To 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.

Location of configuration files for deployment server

Both deployment servers and clients are configured in deployment.conf.

Communication between deployment server and clients

Splunk deployment server currently supports two different methods of 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 communication is sent via SSL.

• Multicast:
  • The deployment server sends multicast packets.
  • Multicast packets contain the server class name and a CRC (checksum) for the configuration information files.
  • Deployment clients listen on the deployment server's multicast URI.
  • Deployment clients can also specify the interface if needed, otherwise the kernel will select one as the default.
• Polling:
  • The deployment client periodically polls the deployment server, requesting applicable server class/CRC pairs.

Configurations for deployment server and clients are dependent on one-another; if you use multicast, you must use it on both client and server.

Where to go next

To set up a deployment server, read about configuring the deployment server. To configure a client, see this page.

• Was this topic useful?
• Post a comment