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!

Updated Team Landing Page in Splunk Observability

We’re making some changes to the team landing page in Splunk Observability, based on your feedback. The ...

New! Splunk Observability Search Enhancements for Splunk APM Services/Traces and ...

Regardless of where you are in Splunk Observability, you can search for relevant APM targets including service ...

Webinar Recap | Revolutionizing IT Operations: The Transformative Power of AI and ML ...

The Transformative Power of AI and ML in Enhancing Observability   In the realm of IT operations, the ...