Getting Data In
Highlighted

Are there any plans to consolidate the many "deployment models" between forwarders, indexers, and search heads?

Contributor

I'm wondering if there are any plans to simplify the deployment mechanisms. Right now there seems to be a lot of confusion.

Highlighted

Re: Are there any plans to consolidate the many "deployment models" between forwarders, indexers, and search heads?

Contributor

Thinking specifically of:

master-app/slave-apps
deployment-apps
shcluster

Highlighted

Re: Are there any plans to consolidate the many "deployment models" between forwarders, indexers, and search heads?

SplunkTrust
SplunkTrust

When asking Splunk about future features, keep in mind:

alt text

Highlighted

Re: Are there any plans to consolidate the many "deployment models" between forwarders, indexers, and search heads?

Contributor

Looking for one of these...

alt text

Highlighted

Re: Are there any plans to consolidate the many "deployment models" between forwarders, indexers, and search heads?

SplunkTrust
SplunkTrust

alt text

0 Karma
Highlighted

Re: Are there any plans to consolidate the many "deployment models" between forwarders, indexers, and search heads?

Contributor

Sitting at .conf2015. Just heard about the new Distributed Management... Looks like we could have an answer.

0 Karma
Highlighted

Re: Are there any plans to consolidate the many "deployment models" between forwarders, indexers, and search heads?

SplunkTrust
SplunkTrust

Hi jaredlaney, This question is somewhat old, but as something of a attempt at a direct answer, I wouldn't expect there to be any unification between deployment models. The best that will happen is the Index Cluster Bundle mechanism being rolled up into the deployment server.

At a high level, the Deployment Server (DS) and Cluster Master (CM) do similar things when it relates to config deployment. They both have a directory of apps (deployment-apps, master-apps) that end up residing on some client splunk servers in a one-to-many fashion. This allows for configuration consistency.

However, they are different in the way that the DS mechanism is one where the clients poll the DS for updates to the app, and then download specific apps and restart if configured to do so. On the other hand, the CM pushes out an entire bundle of apps, and then proceeds to initiate a rolling restart of the cluster. There is no such coordination of restarts for the DS. This is something you need to have in an index cluster in order to retain search availability.

Now, past that, the Search Head Cluster Deployer (SHCD) is an utterly different monster. It takes its shcluster/apps and merges everything from local into the default directory, and then applies the bundle to the cluster (again, like the CM, a push).

The SHC itself continues to maintain a distinct set of local configuration files independent of what is set in local on the deployer. Neither the DS or the CM do anything like this. Also like with the CM, the SHCD push might result in a rolling restart.

Finally, with all that being said, it does seem possible to cook up your own configuration management system (salt, puppet, chef etc) to cover all these bases. You'll just have to account for the distinct needs in each case (most forwarders can just take whatever config and restart as needed, index cluster needs to be handled more carefully, and SHC will end up having local config that should be honored (lots of config ends up being set in UI through normal user interaction).

Please let me know if this answers your question! 😄