Deployment Architecture

Multi site cluster (3 sites) with a site separated from the other ones

Communicator

Hello,
please I would like to know if the following one is a possible/valid Splunk architecture.

Multiste cluster, with sites A, B and C. 200 Forwarders.

  • site A and B communicating each other and replicating data, receiving logs from forwarders 1 to 100.
  • site C receiving logs from forwarders 101 to 200 and replicating data only inside the site itself.

Thanks and best regards.

0 Karma

Path Finder

Not within the same cluster. You would need to split your sites into different clusters. A & B with one cluster master, and C with a separate cluster master.

You can still search both, as if they are 'all the same' from the search head perspective. Just add stanzas for both of the cluster masters in server.conf

[clustering]
mode = searchhead
master_uri = clustermaster:clusterAB, clustermaster:clusterC

[clustermaster:clusterAB]
master_uri = https://master_for_site_AB.com:8089
multisite = true


[clustermaster:clusterC]
master_uri = https://master_for_site_C.com:8089
multisite = true

I would suggest using multisite, even for the Site C Only cluster, in case you want to stand up additional sites for that cluster later, or want to merge them later (If don't want a bunch of standalone buckets to deal with in that situation).


In order to split those forwarders out to the various sites on the indexer side, you can use a deployment app for the UFs that includes an outputs.conf file which would have a different [tcpout] stanza between the two apps.

For example:

SiteABOutputsapp inputs.conf:

[tcpout]
defaultGroup=AB_indexer_group

[tcpout:AB_indexer_group]
server= siteA_idx_1:8089,siteA_idx_2:8089,siteB_idx_3:8089,siteB_idx_4   (etc...)

SiteCOutputsapp inputs.conf

[tcpout]
defaultGroup=C_indexer_group

[tcpout:C_indexer_group]
server= siteC_idx_1:8089,siteC_idx_2:8089,siteC_idx_3:8089,siteC_idx_4   (etc...)

serverclass.conf

[serverClass:SiteAB_Outputs]
whitelist.0=uf_hostname1
whitelist.1=uf_hostname2
...etc... up through 100

[serverClass:SiteAB_Outputs:app:SiteAB_outputs_app]
restartSplunkd=1

[serverClass:SiteC_Outputs]
whitelist.0=uf_hostname101
whitelist.1=uf_hostname102
...etc... up through 200

[serverClass:SiteC_Outputs:app:SiteC_outputs_app]
restartSplunkd=1

Or if you have some other way to identify those UFs in order to split them, like perhaps using a clientName value, or wildcarding the hostname, or by OS, etc, you could use that instead of the individual whitelist.# whitelisting. Or even use an 'external' whitelist file similar to this:

[serverClass:SiteC_outputs]
whitelist.from_pathname = /path/to/whitelists/filename.list

filename.list

host1
host2
host3
host4
...etc...
0 Karma

SplunkTrust
SplunkTrust

Why do that? Why not just use 2 indexer clusters?

---
If this reply helps you, an upvote would be appreciated.

SplunkTrust
SplunkTrust

Correct, there is no replication happening between site C and other two, so technically they're not clustered together anyways. Keeping two clusters (one multisite with A and B and other in C) will help you segregate the forwarders as well (you would be able to utilize Indexer Discovery feature).

0 Karma