Deployment Architecture

NON CLUSTER INDEXERS ONE SEARCH HEAD - WHERE DO I UPDATE PROPS.CONF

jcorcoran508
Path Finder

I inherited a one SH and 2 indexers , 1 LM, one Deployment server supporting forwarders.

I have too on board data  and not sure if I have to go to each indexer to update indexes.conf  and props.conf ?

On the Deployment server I created APP , serverclass.conf and configured the UF with serverclass.conf

I  configured an current existing  index in the inputs.conf that I distributed to the UF.   The UF was installed as root and owned by root. so I believe i can elimination log file permissions on the UF

 

It would be greatly appreciated if  you share your knowledge and approach on managing NON - Clustered indexers please.

3 non clustered indexers I have

 

 

 

 

 

 

 

 

 

Tags (1)
0 Karma
1 Solution

gcusello
Legend

Hi @jcorcoran508,

you can manage your Indexers in two ways and each way has pros and cons:

You can manage Indexers using the Deployment Servers:

  • you have the advantage to have the configurations in only one point and you're sure that configurations are always aligned betweeen Indexers;
  • but you have also the problem that when you make some upgrade to a conf file, all your Indexers will be restarted at the same time and this means that you could have a full stop to the service.

As second choice, you could manually upgrade each Indexer:

  • in this way you have a downtime of only one Indexer at a time,
  • but you have to manually upgrade each Indexer and you have to be sure that all the Indexers are aligned.

At the end, if the little downtime for Indexers restart isn't a problem, I hint to use the Deployment Server, especially if you have only logs from Universal Forwarders that cache logs during downtime.

At the same time, if you have storage availability, I hint to pass to a cluster that gives you high availability.

Ciao.

Giuseppe

View solution in original post

0 Karma

gcusello
Legend

Hi @jcorcoran508,

you can manage your Indexers in two ways and each way has pros and cons:

You can manage Indexers using the Deployment Servers:

  • you have the advantage to have the configurations in only one point and you're sure that configurations are always aligned betweeen Indexers;
  • but you have also the problem that when you make some upgrade to a conf file, all your Indexers will be restarted at the same time and this means that you could have a full stop to the service.

As second choice, you could manually upgrade each Indexer:

  • in this way you have a downtime of only one Indexer at a time,
  • but you have to manually upgrade each Indexer and you have to be sure that all the Indexers are aligned.

At the end, if the little downtime for Indexers restart isn't a problem, I hint to use the Deployment Server, especially if you have only logs from Universal Forwarders that cache logs during downtime.

At the same time, if you have storage availability, I hint to pass to a cluster that gives you high availability.

Ciao.

Giuseppe

View solution in original post

0 Karma

gcusello
Legend

Hi @jcorcoran508,

good for you, see next time!

Ciao and happy splunking.

Giuseppe

P.S.: Karma Points are appreciated by all the contributors 😉

0 Karma

isoutamo
SplunkTrust
SplunkTrust

A sophisticated version of manual update is use e.g. ansible to handle the deployment of those conf files. Just ensure that you have "serial: 1" on playbook and then those deployment steps are run one by one.

But if it's possible I propose to start to use cluster for several indexers. Then you will get also better availability for your data.

r. Ismo

0 Karma
Did you miss .conf21 Virtual?

Good news! The event's keynotes and many of its breakout sessions are now available online, and still totally FREE!