Developing for Splunk Enterprise

How to migrate configuration from indexer to search header quickly in Distributed Search

bestSplunker
Contributor

I have a single instance splunk (splunk A). now I want to do distributed search contain 1 indexer (splunk A)+ 1 search header (splunk B) and use the existing Splunk enterprise (splunk A) as the indexer, so I need to add a search header (splunk B).

Now there's a problem:

the existing single instance Splunk enterprise (splunk A) will become an indexer.The indexer stores the knowledge objects and configuration files created before, so how can I quickly migrate these configuration files to the new search header (splunk B)?

1). how to distinguish which configuration files need to be migrated to the new search header, which configuration files remain in the indexer? (For example, schedule search configuration savedsearches.conf, field extraction configurationprops.conf, which must be migrated to the search header, indexes.conf is retained at indexer,)

2). Because the indexer uses version 6.x and the search header uses version 7.X, So I can't copy the $SPLUNK_HOME directory directly from the indexer to the search header. It's very tedious to migrate the configuration file manually. Is there a fast migration method?

3).Now, they all use their own distributed console, which means that the indexer and the DMC of the search head are independent. Is that normal?

4). I saw it in the distributed console of the search header, Is it normal that my search header still acts as indexer roles ?

Tags (1)
0 Karma
1 Solution

DMohn
Motivator

1) and 2)
Thats highly depending on how you have configured your standalone instance before. If you have all configurations in $SPLUNK_HOME/etc/system/local it might be a bit tedious to distinguish which files you need to copy. If (what is best practice anyway) you stored your configs in $SPLUNK_HOME/etc/apps in one or more dedicated config app(s), you just need to copy the complete apps subfolder. You can copy indexer-only configs to the search head as well, it will just ignore the parameters which are not necessary. Yes, you might have indexes created on the search head in that case, but they will be unused. It's still a possibility to remove the unneccessary configs in a later stage.

3) You should configure the Monitoring Console on one instance only - in that case most probably the search head, as it is a good practice to disable web access to indexers. If you start to configure the MC in distributed mode, you can add other instances there as search peers and this will give you the overview over your complete environment.

4) After initial config this is normal, as without further configuration a search head will store (index) its internal logs. You should configure internal event forwarding for your search head, and then set up the roles in MC as so it is not longer treated as an indexer.

View solution in original post

0 Karma

DMohn
Motivator

1) and 2)
Thats highly depending on how you have configured your standalone instance before. If you have all configurations in $SPLUNK_HOME/etc/system/local it might be a bit tedious to distinguish which files you need to copy. If (what is best practice anyway) you stored your configs in $SPLUNK_HOME/etc/apps in one or more dedicated config app(s), you just need to copy the complete apps subfolder. You can copy indexer-only configs to the search head as well, it will just ignore the parameters which are not necessary. Yes, you might have indexes created on the search head in that case, but they will be unused. It's still a possibility to remove the unneccessary configs in a later stage.

3) You should configure the Monitoring Console on one instance only - in that case most probably the search head, as it is a good practice to disable web access to indexers. If you start to configure the MC in distributed mode, you can add other instances there as search peers and this will give you the overview over your complete environment.

4) After initial config this is normal, as without further configuration a search head will store (index) its internal logs. You should configure internal event forwarding for your search head, and then set up the roles in MC as so it is not longer treated as an indexer.

View solution in original post

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!