Deployment Architecture

How are knowledge bundles used?

echalex
Builder

Hi,

I'm about to implement search head pooling and probably also mounted knowledge bundles. I'm interested in what this will mean for the searches. Having read the documentation, I understand that the indexers will share a knowledge bundle, which is copied from one of the search heads, whereas the search heads will continue blissfully oblivious. What's confusing to me is that without mounted bundles, it seems the indexers constantly need to get an up-to-date version of the bundle(s) from each search head. Mounted bundles will disable this, correct?

Will the indexers update the bundles they are sharing?

Will upgrading splunk require me to copy the etc/system-directory again?

Since the indexers don't need to keep the bundle in synch with the search heads, I'm not sure I understand the purpose of distributing them in the first place.

Clarification: Having checked the documentation again, it seems that I don't have a clear understanding of how etc/system is used in the knowledge bundle. The documentation states clearly that the search heads will use their own etc/system. Doesn't that mean that replicating etc/system is somewhat redundant?

1 Solution

adamw
Communicator

The documentation on mounted knowledge bundles is a little confusing. The knowledge bundle is stored on the searchhead, and is then replicated to the indexers on a search.

The indexers need a read only copy of the knowledge bundle in order to run searches with the latest search-time data (field extracts, lookups, etc).

When you bring search head polling int play (where you have 2 searchheads running queries against multiple indexers), you need some type of shared storage between the searchheads, as well as a read only copy of the same shared storage on the indexers.

For example, the searchhead might be sharing an NFS mount of $SPLUNK_HOME/etc/, and all of the indexers mounting that NFS share read only on /data/searchhead, then disable bundle replication and configure distsearch.conf on the indexers and you should be good to go.

Thanks,
--adam

View solution in original post

adamw
Communicator

The documentation on mounted knowledge bundles is a little confusing. The knowledge bundle is stored on the searchhead, and is then replicated to the indexers on a search.

The indexers need a read only copy of the knowledge bundle in order to run searches with the latest search-time data (field extracts, lookups, etc).

When you bring search head polling int play (where you have 2 searchheads running queries against multiple indexers), you need some type of shared storage between the searchheads, as well as a read only copy of the same shared storage on the indexers.

For example, the searchhead might be sharing an NFS mount of $SPLUNK_HOME/etc/, and all of the indexers mounting that NFS share read only on /data/searchhead, then disable bundle replication and configure distsearch.conf on the indexers and you should be good to go.

Thanks,
--adam

mookiie2005
Communicator

How does the search head know the shared location of the mounted bundle? Don't you need to indicate it somewhere?

0 Karma

echalex
Builder

Thanks, adamw.
Your answer does clarify the documentation to a degree, especially since I needed to re-read the doc. 😉

Ok, so the indexers only need to read the bundles. Apparently the search heads update the bundles location, correct? Would you mind showing me a simple listing of your /data/searchhead?

0 Karma
Get Updates on the Splunk Community!

Earn a $35 Gift Card for Answering our Splunk Admins & App Developer Survey

Survey for Splunk Admins and App Developers is open now! | Earn a $35 gift card!      Hello there,  Splunk ...

Continuing Innovation & New Integrations Unlock Full Stack Observability For Your ...

You’ve probably heard the latest about AppDynamics joining the Splunk Observability portfolio, deepening our ...

Monitoring Amazon Elastic Kubernetes Service (EKS)

As we’ve seen, integrating Kubernetes environments with Splunk Observability Cloud is a quick and easy way to ...