Deployment Architecture

Is it possible to configure a single splunk instance being index master, index peer node, and search head?

danielwan
Explorer

I am going to building a small Splunk cluster with 3 Splunk instances and would like all nodes be able to do indexing and search. But in Splunk documents, index master, index peer node, and search head seem to be sepearted.

Is it possible to configure a single Splunk instance being index master, index peer node, and search head? Is the configuration same as the normal Splunk cluster?

0 Karma
1 Solution

gcusello
SplunkTrust
SplunkTrust

Hi danielwan
from
http://docs.splunk.com/Documentation/Splunk/6.6.2/Indexer/Basicclusterarchitecture

Master nodes, peer nodes, and search heads are all specialized Splunk Enterprise instances. All nodes must reside on separate instances and separate machines. For example, the master node cannot reside on the same instance or machine as a peer node or a search head.

We created for a customer an Indexer Cluster (two peers and Master Node) where there are both Indexer and Search Head roles on the peers, but only indexes are replicated.
Master Node MUST be on a different instance.

Bye.
Giuseppe

View solution in original post

0 Karma

woodcock
Esteemed Legend

Is this for learning/testing purposes? In production you should do everything that you can to have 1 role per server.

0 Karma

woodcock
Esteemed Legend

You can install splunk in an "all-in-one" configuration where a single host is all of these: License Master, Indexer, Search Head, Forwarder, Monitoring Console and Deployment Server (but it cannot deploy to itself). As far as clustering goes, no, you cannot run either a Search Head Cluster or an Indexer Cluster on a single host; it really makes no sense.

0 Karma

gcusello
SplunkTrust
SplunkTrust

Hi danielwan
from
http://docs.splunk.com/Documentation/Splunk/6.6.2/Indexer/Basicclusterarchitecture

Master nodes, peer nodes, and search heads are all specialized Splunk Enterprise instances. All nodes must reside on separate instances and separate machines. For example, the master node cannot reside on the same instance or machine as a peer node or a search head.

We created for a customer an Indexer Cluster (two peers and Master Node) where there are both Indexer and Search Head roles on the peers, but only indexes are replicated.
Master Node MUST be on a different instance.

Bye.
Giuseppe

0 Karma

danielwan
Explorer

Thanks for the explaination.
do you mean even search header and peer node must be different hosts?

0 Karma

gcusello
SplunkTrust
SplunkTrust

Master Node must be on a different server.
It's better (raccomanded by Splunk) that Search Head and Indexer are on different servers but we have one installation where they are on the same servers.
In other words we have two peers (both with indexer and search head) and a Master node
Bye.
Giuseppe

0 Karma

danielwan
Explorer

one more question,in your installation where both search head and index peer node reside on the same host, is it a search head cluster or a single search head.if it is a search head cluster,is search artifact replicated properly?

also what is the value of "mode" of server.conf as one single host is both search head and peer node?

0 Karma

gcusello
SplunkTrust
SplunkTrust

Hi danielwan,
indexes are replicated between peers, instead search artifacts aren't replicated between peers.
We created a script that replicates knowledge objects from one server to the second.
Our script repicate all objects with the only exception of lookups.
Bye.
Giuseppe

0 Karma
Get Updates on the Splunk Community!

Enterprise Security Content Update (ESCU) | New Releases

In December, the Splunk Threat Research Team had 1 release of new security content via the Enterprise Security ...

Why am I not seeing the finding in Splunk Enterprise Security Analyst Queue?

(This is the first of a series of 2 blogs). Splunk Enterprise Security is a fantastic tool that offers robust ...

Index This | What are the 12 Days of Splunk-mas?

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