Deployment Architecture

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

cafissimo
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

thesplunkmonkey
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:

SiteAB_Outputs_app 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...)

SiteC_Outputs_app 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

richgalloway
SplunkTrust
SplunkTrust

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

---
If this reply helps you, Karma would be appreciated.

somesoni2
Revered Legend

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
Get Updates on the Splunk Community!

Extending Observability Content to Splunk Cloud

Watch Now!   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to leverage ...

More Control Over Your Monitoring Costs with Archived Metrics!

What if there was a way you could keep all the metrics data you need while saving on storage costs?This is now ...

New in Observability Cloud - Explicit Bucket Histograms

Splunk introduces native support for histograms as a metric data type within Observability Cloud with Explicit ...