Plan a deployment
This documentation does not apply to the most recent version of Splunk. Click here for the latest version.
Contents
Plan a deployment
If you've got Splunk instances serving a variety of different populations within your organization, chances are their configurations vary depending on who uses them and for what purpose. You may have some number Splunk instances serving the helpdesk team, configured with a specific app to accelerate troubleshooting of Windows desktop issues. You may have another group of Splunk instances in use by your operations staff, set up with a few different apps designed specially to emphasize tracking of network issues, security incidents, and email traffic management. A third group of Splunk instances might serve the Web hosting group within the operations team.
Rather than having to manage and maintain these divergent Splunk instances one at a time, you can put them into groups based on their usage, identify the various configurations and apps needed by each group, and then use the deployment server to handle updating their various apps and configurations as needed.
You can group your Splunk instances for easier management when using the deployment server. You might simply have your Splunk instances grouped by OS or hardware type, by version, or by geographical location or timezone.
Configuration overview
For the great majority of deployment server configurations, you'll do the following:
- Designate one of your Splunk servers as the deployment server. Group the deployment clients into "server classes". A server class defines the content that is pushed out to the clients that belong to it. A given deployment client can belong to multiple server classes at the same time. A deployment server can also be a deployment client of itself, as long as the location you specify for the client to get the content from is different from the location it is supposed to put retrieved content into.
- The deployment server will hold the serverclass.conf file that defines the server classes that your deployment clients belong to. It will also hold the repository of content (Apps, configurations) to be pushed out. Refer to "Define server classes" in this manual for details.
- You can tell each server class you define to get its content from a particular location and to put it into a particular location when it gets it.
- Each deployment client will have a deploymentclient.conf that specifies what deployment server it should communicate with, the specific location on that server from which it should pick up content, and where it should put it locally. Refer to "Configure deployment clients" in this manual for details.
- For more complex deployments, you can edit tenants.conf. This allows you to define multiple deployment servers, and redirect incoming client requests to them using rules you specify. Refer to "Deploy in multi-tenant environments" in this manual for more information about configuring tenants.conf. Most deployment server topologies don't require that you touch tenants.conf, however.
Note: The deployment server and its deployment clients must agree in the SSL setting for their splunkd management ports. They must all have SSL enabled, or they must all have SSL disabled. To configure SSL on a Splunk instance, set the enableSplunkdSSL attribute in server.conf to "true" or "false".
Restart or reload?
The first time you configure the deployment server and its clients, you'll need to restart all the instances of Splunk. Once you've got it up and configured, you just need to use the CLI reload command as described in "Deploy or update Apps and configurations" in this manual.
This documentation applies to the following versions of Splunk: 4.0 , 4.0.1 , 4.0.2 , 4.0.3 , 4.0.4 , 4.0.5 , 4.0.6 , 4.0.7 , 4.0.8 , 4.0.9 , 4.0.10 , 4.0.11 View the Article History for its revisions.