Deployment Architecture
Highlighted

Search head clustering across a WAN?

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
Highlighted

Re: Search head clustering across a WAN?

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
Highlighted

Re: Search head clustering across a WAN?

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
Highlighted

Re: Search head clustering across a WAN?

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
Highlighted

Re: Search head clustering across a WAN?

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