Deployment Architecture

Search head clustering across a WAN?

mfrost8
Builder

We're planning the move from search head pooling to search head clustering. With pooling we were limited by where we could make the NAS share available (i.e. not across a WAN). I'm wondering if there's any particular reason one could not do SH clustering across a WAN.

I haven't seen anything that talks about it in the documentation or in the 2014 .conf slides about it.

It would certainly be handy if users could be more assured that their environment would look the same no matter which location they were in.

thanks

Tags (1)
0 Karma

alacercogitatus
SplunkTrust
SplunkTrust

Search Head Clustering (SHC) across a WAN is possible. There are the usual caveats:

  1. Latency should be very low
  2. Your links must have the bandwidth to transfer bundles without saturating the links

Performance using the SHC is greatly improved over SHP (pooling), especially since NFS is no longer in the mix.

0 Karma

mfrost8
Builder

I don't believe we have large bundles.

Not so sure about the latency under certain circumstances. I don't particularly care about fast replication, just that it be done eventually. Would perhaps latency say across the Atlantic cause some kind of problem in a clustered scenario or would it solely be a matter of replication taking longer than some might expect?

Thanks

0 Karma

jacobwilkins
Communicator

How many indexers do you have on that side of the Atlantic? If you have 50/50ish split, then what you are doing is probably just a "somewhat bad idea". If most of your indexers are one one side of the WAN, doing SHC across it strikes me as a "very bad idea."

As a customer who distributes search across WAN to multiple continents, I can tell you that "somewhat bad ideas" are often the best you get for solving your problems.

0 Karma

mfrost8
Builder

All are on one side at the moment. Mostly I'm thinking how I'd like the search heads to present the same view (from a search head perspective) of things. I'm just thinking about this possibility now, but I would like to avoid having to explain to users "the reason your search was available when you want to this URL and isn't available over there is that they're different search heads, get it?"

The idea of geographic-dependency on search heads and having to get users to keep that in their heads as to what their search head environment is going to look like is something I'd like to avoid. I've had to go through that a few times with geo-dependent pooled search head environments in the US and I get a lot of deer-in-the-headlights looks.

Thanks

0 Karma
Get Updates on the Splunk Community!

Stay Connected: Your Guide to May Tech Talks, Office Hours, and Webinars!

Take a look below to explore our upcoming Community Office Hours, Tech Talks, and Webinars this month. This ...

They're back! Join the SplunkTrust and MVP at .conf24

With our highly anticipated annual conference, .conf, comes the fez-wearers you can trust! The SplunkTrust, as ...

Enterprise Security Content Update (ESCU) | New Releases

Last month, the Splunk Threat Research Team had two releases of new security content via the Enterprise ...