Splunk Enterprise Security

Search Head Clustering, Enterprise Security and PCI apps

javiergn
SplunkTrust
SplunkTrust

Hi all,

I've got a couple of questions with regards to Enterprise Security, PCI and Search Head Clustering. We are initially going to be indexing 200GB/day but this will definitely grow beyond that within the next 2 years or so:

  1. If we decided to buy enterprise security and implement search head clustering, the minimum number of nodes we need is 3. If we also want non-ES Search Heads, I'm assuming these will need to be outside the ES Cluster, correct?
  2. If we also wanted search head clustering on the non-ES search heads, would that then require another 3 nodes and therefore we would require 6 Search Heads in total across 2 Search Head Cluster (ES and non-ES)?
  3. Splunk also recommends a dedicated search head for the PCI app so you can probably guess what I'm going to ask next. Would we then need another 3 search heads in a new cluster for the PCI app? That's 9 already!
  4. Would each search head cluster require its own deployer?

Thanks,
J

0 Karma
1 Solution

dshpritz
SplunkTrust
SplunkTrust

Hey there J,

  1. Yes, your non-ES Search Heads would have to be outside of the SHC.
  2. Yes, if you wanted to do SHC on your non-ES Search Heads, you would need to have 3 in that cluster too.
  3. The latest version of PCI actually acts more like a plug-in to ES, (see the PCI docs)
  4. It is possible to use the same deployer, but in reality you most likely wouldn't want to, as the deployer only has one set of apps that it will deploy to both clusters, so I would plan on having two deployers.

HTH,

Dave

View solution in original post

dshpritz
SplunkTrust
SplunkTrust

Hey there J,

  1. Yes, your non-ES Search Heads would have to be outside of the SHC.
  2. Yes, if you wanted to do SHC on your non-ES Search Heads, you would need to have 3 in that cluster too.
  3. The latest version of PCI actually acts more like a plug-in to ES, (see the PCI docs)
  4. It is possible to use the same deployer, but in reality you most likely wouldn't want to, as the deployer only has one set of apps that it will deploy to both clusters, so I would plan on having two deployers.

HTH,

Dave

jplumsdaine22
Influencer

Just a note on #4. For your deployer, which doesn't do a whole lot resource wise, there is no problem having two splunk instances on one server. eg /opt/splunk-ES and /opt/splunk-non-ES. This may save you paying for two servers, but you will still have two separate deployer instances

0 Karma

javiergn
SplunkTrust
SplunkTrust

Hi Dave,

Thanks for your quick answer. It makes perfect sense but just to gather a second opinion on this topic too. Given that Search Head Clustering helps distributing the load across your Search Heads, is there still any real reason to keep ES on a dedicated Search Head (or Search Head Clustering)?

If we decided to go for 6 Search Heads, all of them part of the same SHC, all of them running ES, all them used for any production-related task, shouldn't that be perfectly doable and would require a less complex and easy to maintain deployment?

My thinking process is very simple: increasing the number of SHs running ES will reduce the load ES generates per SH and therefore allow that extra capacity to be used for something else.

Thanks,
J

0 Karma

dshpritz
SplunkTrust
SplunkTrust

It is possible to run into problems with other apps installed on an ES Search Head that are not CIM compliant, that is, they may have different field mappings that are incorrect, and would cause ES to misbehave, or, on the flip side, you might have ES configs that cause problems for the other apps you are trying to use.

For a lot of customers, they have non-CIM apps that they want to use, so they end up having an "ad-hoc" SH that they use for other apps. You are correct, the more SH in the SHC, the more spread the load (saves searches and ad-hoc).

0 Karma

javiergn
SplunkTrust
SplunkTrust

OK, thanks

0 Karma
Get Updates on the Splunk Community!

.conf24 | Registration Open!

Hello, hello! I come bearing good news: Registration for .conf24 is now open!   conf is Splunk’s rad annual ...

Splunk is officially part of Cisco

Revolutionizing how our customers build resilience across their entire digital footprint.   Splunk ...

Splunk APM & RUM | Planned Maintenance March 26 - March 28, 2024

There will be planned maintenance for Splunk APM and RUM between March 26, 2024 and March 28, 2024 as ...