Are there any gotchas setting up Hunk Search Head Clustering over both an Indexer Cluster and Virtual Indexes

[splunk_zen]

Is there anything to take into account for setting up a Hunk Search Head cluster both with virtual indexes mapped into HDFS as well as a standard Indexer Cluster?

Currently our DataNodes count/YARN queue could serve as a bottleneck which would eat up on the max concurrent searches, but could we offset that with a beefy enough search peer members count and CPU cores? What other things could catch us off guard?

[rdagan_splunk]

The only gotchas are .. we recommend you create 3 different Hunk HDFS working directories to avoid MR Jobs colliding. So for example, Hunk 1 will get /user/hunk/splunkmr1 and Hunk 2 will get /user/hunk/splunkmr2

[rdagan_splunk]

Exactly correct, you can use Hunk as a normal Splunk Search Head to create a single pane of glass having Hunk look into HDFS as well as Splunk indexed data.

[splunk_zen]

Crystal clear.
Cheers Rdagan

[ppablo]

Hi @splunk_zen

Please don't forget to resolve your post(s) by clicking "Accept" directly below the answer that solved your question. Thanks!

Patrick

[splunk_zen]

So it would be possible to have a single pane of glass having Hunk look into HDFS as well as Splunk indexed data, scraping and reusing our Splunk search peers into Hunk ones correct?

[splunk_zen]

For instance, keep reading Hunk doesn't support real time searches.
Is this exclusively meant for searches over virtual indexes or even if we'd setup the Hunk search head to join a standard Indexer Cluster?
As far as I'm aware, the rpm is the same, if we add a Splunk Enterprise and Hunk license to the License Master it should work no?