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
Esteemed 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
Esteemed 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

0 Karma

gcusello
Esteemed 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
Get Updates on the Splunk Community!

New Splunk Observability innovations: Deeper visibility and smarter alerting to ...

You asked, we delivered. Splunk Observability Cloud has several new innovations giving you deeper visibility ...

Synthetic Monitoring: Not your Grandma’s Polyester! Tech Talk: DevOps Edition

Register today and join TekStream on Tuesday, February 28 at 11am PT/2pm ET for a demonstration of Splunk ...

Instrumenting Java Websocket Messaging

Instrumenting Java Websocket MessagingThis article is a code-based discussion of passing OpenTelemetry trace ...