Deployment Architecture

Cluster everything for management simplicity even if Indexer replication not required?

pj
Contributor

I am currently building out a Splunk environment with a number of indexers and search heads. The Search Heads are to be clustered but clustered indexing is not required. However, as I go through this exercise, I am beginning to think it might actually be better/easier to simply cluster the indexers and set the SF and RF to 1 (i.e. cluster them, but not have them replicate data). Why? Well for the following reasons:

  1. The SHC requires a Deployer - which can (as stated in the documentation) go on the Deployment Server. However the new Distributed Management Console (DMC) in 6.2 cannot run on a SHC, nor is it recommended that it be put it on the Deployment Server. This means I have to find another server to put it on anyway...
  2. Without IDX clustering, I have to go to each SH in the SHC individually and manually add the Search Peers. Not a problem - but not exactly centrally managed and it would be possible to miss one on a given SH if you are not careful or had a lot of indexers. With IDX clustering, I can simply point the SHs in the SHC to the Master Node and it's job done on that front.
  3. With IDX clustering, I have a Master Node that can also act as the Deployer for the SHC. In addition, the DMC will also work on the Master Node, so my Master Node essentially becomes a nice Administrative SH for my Splunk environment. Maybe I will also shove some other things on there too like the FireBrigade app etc.
  4. If, in the future I do want to enable IDX clustering - I am pretty much good to go - just change the RF/SH settings.

Now - this approach does separate the management of the Splunk environment layers, but that isn't so bad as each layer will be mostly getting different configs anyway. SHs using the Deployer (on the Master Node), IDXs using the Master Node and then the Deployment Server left to manage the Forwarder Configurations.

Is this a viable approach? Anything to be aware of? It certainly seems like the overall environment would be a bit more tied together and potentially easier to manage.

1 Solution

Steve_G_
Splunk Employee
Splunk Employee

You can implement indexer clustering even when replication is not required. There are some good reasons to do so, documented here:

http://docs.splunk.com/Documentation/Splunk/6.2.0/Indexer/Clustersinscaledoutdeployments

As you mention, this topology has additional benefits with the advent of search head clustering, particularly in regards to simplifying the connection to the search peers.

View solution in original post

Steve_G_
Splunk Employee
Splunk Employee

You can implement indexer clustering even when replication is not required. There are some good reasons to do so, documented here:

http://docs.splunk.com/Documentation/Splunk/6.2.0/Indexer/Clustersinscaledoutdeployments

As you mention, this topology has additional benefits with the advent of search head clustering, particularly in regards to simplifying the connection to the search peers.

pj
Contributor

Perfect, thanks!

0 Karma
Get Updates on the Splunk Community!

What's New in Splunk Enterprise 9.4: Features to Power Your Digital Resilience

Hey Splunky People! We are excited to share the latest updates in Splunk Enterprise 9.4. In this release we ...

Take Your Breath Away with Splunk Risk-Based Alerting (RBA)

WATCH NOW!The Splunk Guide to Risk-Based Alerting is here to empower your SOC like never before. Join Haylee ...

SignalFlow: What? Why? How?

What is SignalFlow? Splunk Observability Cloud’s analytics engine, SignalFlow, opens up a world of in-depth ...