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?
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
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.
Crystal clear.
Cheers Rdagan
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
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?
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?