Distributed Deployment Manual

 


Deploy in multi-tenant environments

Deploy in multi-tenant environments

Important: It is recommended that you work with Splunk Professional Services when designing a multi-tenant deployment.

A multi-tenant deployment server topology means that you have more than one deployment server running on the same Splunk instance, and each deployment server is serving content to its own set of deployment clients. (You can also achieve the same effect by using two Splunk instances, each with its own configuration.)

Use tenants.conf to redirect incoming requests from deployment clients to another deployment server or servers. The typical reason for doing this is to offload splunkd's HTTP server -- if too many deployment clients are simultaneously hitting the splunkd HTTP server to download apps and configurations, it can overload the deployment server. Over 400 connections at one time has been shown to bog down splunkd's HTTP server, but this does not take into account hardware or the size of the package the client is downloading.

To set up multiple deployment servers on a single Splunk instance, you:

  • Create a tenants.conf containing a whitelist or blacklist that tells deployment clients which deployment server instance to use.
  • Create a separate instance of serverclass.conf for each deployment server, named for that deployment server, like so: <tenantName>-serverclass.conf.
  • For each deployment client, configure deploymentclient.conf the way you would if there were just one deployment server.

What you can define in tenants.conf

You identify the different deployment servers as "tenants" in tenants.conf on the Splunk instance that will host these deployment servers. There isn't a tenants.conf file by default, so you must create one in $SPLUNK_HOME/etc/system/local and define the tenants in it.

For each tenant, create a stanza with the heading [tenant:<tenantName>] with these attributes:

Attribute What it's for Default
filterType Set to whitelist or blacklist. Determines the type of filter to use. Deployment clients use the filter to determine which deployment server to access. whitelist
whitelist.<n>

blacklist.<n>

<n> is a number starting at 0, and incrementing by 1. The client stops looking at the filter when <n> breaks.

Set the attribute to one of these value categories:

  • ipAddress: The IP address of the deployment client. You can use wildcards, for example, 10.1.1.*
  • hostname: The host name of deployment client. You can use wildcards, for example, *.splunk.com
  • clientName: A logical, or tag, name that can be assigned to a deployment client in deploymentclient.conf. A clientName takes precedence over ipAddress or hostname when matching a client to a filter.
n/a

Example

Here is an example of defining two tenants in the tenants.conf file:

# Define two tenants - dept1 and dept2.
# Deployment server configuration for dept1 will be in a matching dept1-serverclass.conf
# Deployment server configuration for dept2 will be in a matching dept2-serverclass.conf

[tenant:dept1]
whitelist.0=*.dept1.splunk.com

[tenant:dept2]
whitelist.0=*.dept2.splunk.com

This documentation applies to the following versions of Splunk: 4.2 , 4.2.1 , 4.2.2 , 4.2.3 , 4.2.4 , 4.2.5 , 4.3 , 4.3.1 , 4.3.2 , 4.3.3 , 4.3.4 , 4.3.5 , 4.3.6 , 5.0 , 5.0.1 , 5.0.2 , 5.0.3 View the Article History for its revisions.


You must be logged into splunk.com in order to post comments. Log in now.

Was this documentation topic helpful?

If you'd like to hear back from us, please provide your email address:

We'd love to hear what you think about this topic or the documentation as a whole. Feedback you enter here will be delivered to the documentation team.

Feedback submitted, thanks!