Deployment Architecture

Is it possible to disable an app/add-on on one search head?

k_sam
Explorer

We have multi member search head cluster but we would like an particular add-on/app to be disabled on one search head but should be working/enabled on all the other search heads.. 
That particular app needs an integration towards an external service which at the moment doesn't seem feasible to achieve due to some network limitations.
Looking for something like below in local/app.conf

 

 

[install]
state = disabled

 

 

 Is it ok to do that? Or any other good way of achieving the same. 

Labels (2)
0 Karma
1 Solution

richgalloway
SplunkTrust
SplunkTrust

I think it may be possible, but perhaps not supported and certainly something to test in a dev environment.

If you manually edit local/app.conf on the desired search head then the app will be disabled only on that SH. UNLESS, that SH becomes the Captain and someone does a cluster resync.  Then all SHC members will replicate that app.conf file and the app will be disabled cluster-wide.  The converse is also possible - if the Captain has the app enabled when a resync occurs then all members will enable the app.

I think you may be painting yourself into a corner with this configuration.  If the integration is inbound then having it enabled on more than one SH risks data duplication.  If the integration is outbound then the SH with the disabled app will not function the same as the others.

---
If this reply helps you, Karma would be appreciated.

View solution in original post

k_sam
Explorer

Thanks for the responses @richgalloway  and @gcusello.
I have tested this by changing the proxy setting for one of the applications rather than disabling the app completely. 
Thanks for highlighting the risk involved if this member is elected as captain and a resync will change proxy settings at all the servers but we have decided to go for "not preferred captain" option for that member
(we acknowledge that the cluster attempts to respect the captaincy preference but it doesn't enforce this option).
And if a resync from captain with different configuration is pushed we will script it to be overwritten with what's default of this member. 
We will test it further with some scenarios and update if it helps to achieve what we were trying. 

 

0 Karma

richgalloway
SplunkTrust
SplunkTrust

I think it may be possible, but perhaps not supported and certainly something to test in a dev environment.

If you manually edit local/app.conf on the desired search head then the app will be disabled only on that SH. UNLESS, that SH becomes the Captain and someone does a cluster resync.  Then all SHC members will replicate that app.conf file and the app will be disabled cluster-wide.  The converse is also possible - if the Captain has the app enabled when a resync occurs then all members will enable the app.

I think you may be painting yourself into a corner with this configuration.  If the integration is inbound then having it enabled on more than one SH risks data duplication.  If the integration is outbound then the SH with the disabled app will not function the same as the others.

---
If this reply helps you, Karma would be appreciated.

gcusello
SplunkTrust
SplunkTrust

Hi @k_sam,

in my knowledge it isn't possible to have a different configuration only in one Search Head belonging to a Cluster, the configuration must be the same in all SHs of the Cluster and they are replicated by the Captain to all the Members.

The only way is to have another SH outside the Cluster.

Ciao.

Giuseppe

0 Karma
Get Updates on the Splunk Community!

New Case Study Shows the Value of Partnering with Splunk Academic Alliance

The University of Nevada, Las Vegas (UNLV) is another premier research institution helping to shape the next ...

How to Monitor Google Kubernetes Engine (GKE)

We’ve looked at how to integrate Kubernetes environments with Splunk Observability Cloud, but what about ...

Index This | How can you make 45 using only 4?

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