Deployment Architecture

deployment-server issue : This DC shares a Splunk instance with its DS :unsupported configuration.

mataharry
Communicator

After upgrading to Splunk 6, I started to notice that the deployment-client was disabled on my deployment-server instance. FYI my deployment-server is also a deployment-client of itself.

I found this error in splunkd.log on the server

ERROR DC:DeploymentClient - This DC shares a Splunk instance with its DS: unsupported configuration.

It was working before in 5., it is not working anymore in 6. ?

Tags (1)
1 Solution

yannK
Splunk Employee
Splunk Employee

Exact. Having a Splunk deployment-server instance being it own deployment-client has always been a worse practice, that leads to many issues.

see http://docs.splunk.com/Documentation/Splunk/latest/Updating/Deploymentserverarchitecture

A deployment server is a Splunk Enterprise instance that acts as a centralized configuration manager for any number of other instances, called "deployment clients". Any full Splunk Enterprise instance - even one indexing data locally - can act as a deployment server. A deployment server cannot be a client of itself.

Since splunk 6.0, the deployment code was refactored, and unsupported configurations are now prevented, and if this is detected, the deployment-client will disable itself preventively.

Recommendations are :
- use a dedicated deployment server instance, with no other roles, therefore without the need to be a client.
- do not make your indexers/search-head a deployment-server (even if you may be tempted by the forwarder management web UI)
- on linux you can have a separate instance on the same server, using different management ports.

The only possible confusion may be if you have actually 2 splunk instances on the same server, (one deployment-server, and one deployment-client on different ports). Because the hostname and dns name will be identical, the test may trigger. To be tested.

View solution in original post

gavin1_davenpor
Path Finder

use a dedicated deployment server instance, with no other roles, therefore without the need to be a client.
This sucks. My deployment server(s) run apps which I manage/propogate with deployment server.

What if i have deployment slaves ? (also both clients and deployment servers).

where was this change in functionality published - when did it happen ?

I have one splunk instance running 6.1.4 happily running as a DS, DC, indexer, search head, all working fine (this started life as a much earlier version)
I've just built another 6.1.4 instance (simply a DS, nothing else), and I can't get it to connect to itself.

Why do you deem it to be worst practise ?

0 Karma

yannK
Splunk Employee
Splunk Employee

Exact. Having a Splunk deployment-server instance being it own deployment-client has always been a worse practice, that leads to many issues.

see http://docs.splunk.com/Documentation/Splunk/latest/Updating/Deploymentserverarchitecture

A deployment server is a Splunk Enterprise instance that acts as a centralized configuration manager for any number of other instances, called "deployment clients". Any full Splunk Enterprise instance - even one indexing data locally - can act as a deployment server. A deployment server cannot be a client of itself.

Since splunk 6.0, the deployment code was refactored, and unsupported configurations are now prevented, and if this is detected, the deployment-client will disable itself preventively.

Recommendations are :
- use a dedicated deployment server instance, with no other roles, therefore without the need to be a client.
- do not make your indexers/search-head a deployment-server (even if you may be tempted by the forwarder management web UI)
- on linux you can have a separate instance on the same server, using different management ports.

The only possible confusion may be if you have actually 2 splunk instances on the same server, (one deployment-server, and one deployment-client on different ports). Because the hostname and dns name will be identical, the test may trigger. To be tested.

gavsdavs_GR
Path Finder

I downvoted this post because even for a dedicated deployment server, it makes sense for it to deploy content to itself. (because it shares config with other instances, like outputs, authentication, etc). Your approach means i need to have multiple copies of the same app, and maintain those in /apps/ seperately to those I maintain in /deployment-apps/

0 Karma
Get Updates on the Splunk Community!

Index This | Divide 100 by half. What do you get?

November 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with this ...

Stay Connected: Your Guide to December Tech Talks, Office Hours, and Webinars!

❄️ Celebrate the season with our December lineup of Community Office Hours, Tech Talks, and Webinars! ...

Splunk and Fraud

Watch Now!Watch an insightful webinar where we delve into the innovative approaches to solving fraud using the ...