I'd like to use a single DNS entry on all of my forwarders, and have the deployment server send traffic for my secondary environment to the secondary deployment server.
In the primary deployment server environment, where the DNS entries is pointing to, I tried setting up a tenants.conf
[tenant:dit]
whitelist.0 = secondary_environment_hostname_prefix*
and a pubsub.conf
[pubsub-server:dit]
targetUri=secondary_deployment_server:18089
The documentation gives hints at this topology, although mostly focuses on handling multiple serverclass.conf files.
I’ve been reviewing these pages:
http://docs.splunk.com/Documentation/Splunk/5.0.4/Deploy/Deployinmulti-tenantenvironments
http://docs.splunk.com/Documentation/Splunk/5.0.4/Admin/Tenantsconf
http://docs.splunk.com/Documentation/Splunk/latest/Admin/Pubsubconf
I saw some documentation on how to make one deployment server a client of the other, but I doesn’t sound like that is an appropriate solution for what I’m trying to achieve.
Any creative ideas out there?
Hi SloshBurch,
There's a few different interpretations of what you're after here. Just to confirm, is this the topology you're after?
So depsvr.blah.com is never actually handing out configs to clients in the subdomains.
(I got bored in a meeting 🙂
Yes, but I am also trying to have certain forwarders pull config from the secondary deployment server while everything else pulls from the primary.
Hi SloshBurch,
There's a few different interpretations of what you're after here. Just to confirm, is this the topology you're after?
So depsvr.blah.com is never actually handing out configs to clients in the subdomains.
(I got bored in a meeting 🙂
R.Turk - you're my new favorite splunker 😉 Awesome use of the stencil! That's exactly is with an important quirk: depsvr.dep1.blah.com in the same host as depsrv.blah.com while depsvr.dept2.blah.com is a DIFFERENT host than depsrv.blah.com.
You could conceivably produce an app bundle that provided a new deploymentclient.conf. Whilst that would then produce a permanent change until the other server provided a reversion configuration, you could tailor it on the primary with your serverclass configuration on your "primary" deployment server to target the override only those servers which needed it.
Indeed, I have been thinking about deploying just such a configuration across our estate for future flexibility.
I may have lost you on a few of the details - Once the forwarders have that app, they will be pointing to that secondary deployment server but will not be able to revert back to the primary if the secondary goes offline. Right?
It sounds like you want to clone deployment servers, and have DNS point to the one that is available, and have the forwarder configured to query DNS instead of using a static path to the server. Is that right?