I have an all-in-one instance and i want to add a search head to be used by a team to only access specific data.
is that possible without making a kind of distributed deployment, or i should make the all-in-one instance as the deployment server and then add the search head?
excuse my question if it seems basic, a newbie here 😅
The general idea is that you deploy a new Splunk Instance and add the old one as search peer.
But 1. You have to manage apps separately on both instances (which means you could use another instance as deployment server and it's getting complicated ;-)).
But 2. If you're not in control of the second search head, it's not a way of restricting access. The access control in Splunk is preformed on search head level. So if search head has access to an indexer (and in your case the all-in-one would fulfill the role of indexer), it has full access to its data.
So it might be easier to stick with your all-in-one (or indeed add a search-head and leave old instance as indexer only) and properly configure roles and limit access based on roles.
Thank you @PickleRick for your quick answer.
So in this case i will keep the all-in-one as indexer and use the new instance as search head (SHnew).
now i have another small question: besides the all-in-one instance, i need to search data from another splunk deployment (2 indexers), and i already have a search head (SHold) in that other deployment (i know, you will say why not use the existing one! lets say i have to 😅).
the question is, can I simply add the 2 indexers as search peers in the new search head (SHnew) or should i create a search head cluster using the SHold and SHnew (i also have a deployment server that manages the SHold)?
thanks for your help and your patience 🙏
Search head cluster has nothing to do with number of search peers. Technically, you could create a huge SHC searching from just one indexer (even if it didn't make much sense performance-wise). You can also use one SH to search from many indexers. There is no strict relation between those layers.
There are two different aspects here.
One is what is technically possible - and here you can have separate search heads querying various subsets of your indexers set (as - for example - one of your indexers might be gathering only security data and another one only ops data).
Another thing is the maintainability of such setup and conformance to SVA's - https://www.splunk.com/en_us/resources/splunk-validated-architectures.html?locale=en_us
Of course there is no hard rule that tells you that you definitely can't do something non-SVA, but it's harder to troubleshoot and get help with since it's a releatively unusual setup.
the best option is just add this as a new search peers.
You cannot create SHC without min. 3 SHs + deployer, that’s required by its technical solutions. Also in our kind of small environment there is no helps from it. Actually it makes things more complicated.
Anyhow when you start to see needs for additional splunk instances, it’s time to sit down and plan your whole (new) splunk architecture for next years.
You can. 🙂 It's just that it will have problems if a split-brain occurs because it will not be able to raise majority to elect captain.
Of course if you use a manually designated captain, it's even easiest.
But still, those are advanced topics and I would definitely _not_ advise anyone to run 2-node SHC in production.