Deployment Architecture

In Two-Tiered Splunk Deployment Server Architecture, do we need to do the command splunk reload deploy-server twice?

jaracan
Communicator

We are planning to migrate to a Two-Tiered Splunk Deployment Server Architecture. Do we have guidelines that we can check so we can plan accordingly. And also, with regard to app deployment in a Two-Tiered Splunk Deployment Server Architecture, do we need to do the command splunk reload deploy-server twice (one in Master DS and another one in Slave DS) whenever we have some updates in the apps(deployment-apps)? Looking forward to your insights. Thank you

Labels (1)
0 Karma

PickleRick
SplunkTrust
SplunkTrust

I would have to check my notes (I don't have them with me, I'm walking my dog at the moment :)) but I believe so - without the reload the subordinate DS won't notice changes in the apps. Also remember that you need crossServerChecksum in serverclass.conf if you want to serve the contents from behind LB (if you just have a secondary DS in another location so that some of your clients hit DS1 and others - DS2, you don't need that).

As a side note, have you considered, instead of two-tiered DS infrastructure, a set of separate DS-es managed centrally by some automation solution (ansible?)?.

0 Karma

jaracan
Communicator

Hi @PickleRick ,

Thank you for your insights. About the crossServerChecksum parameter, do we need this config present for both serverclass.conf of Master DS and 2nd-tier DS ?

0 Karma

PickleRick
SplunkTrust
SplunkTrust

It depends on what your infrastructure will look like. If you have one primary DS deploying to several secondary DS-es and only those secondary DS-es will be deploying to clients, you only need that on secondaries. But if you want to have one primary and one or more secondaries but all of them will be serving apps to the same clients, you need that on all DS-es.

0 Karma

gcusello
SplunkTrust
SplunkTrust

Hi @jaracan,

I searched this guidelines but I never found them.

Anyway, there are three aspect to consider:

  • Apps updates,
  • ServerClasses.conf updates,
  • Configurations reload.

About the first aspect, you have to configure the main DS to upload Apps not in the $SPLUNK_HOME/etc/apps folder of the secondary DS, but the $SPLUNK_HOME/etc/deployment-apps folder.

This is possible using the repositoryLocation option in deploymentclient.conf on the secondary DS.

you can find more infos at https://docs.splunk.com/Documentation/Splunk/9.0.5/Admin/Deploymentclientconf 

repositoryLocation = $SPLUNK_HOME/etc/apps
* The location where content installs when downloaded from a deployment server.
* For the Splunk platform instance on the deployment client to recognize an app
  or configuration content, install the app or content in the default location:
  $SPLUNK_HOME/etc/apps.
    * NOTE: Apps and configuration content for deployment can be in other
      locations on the deployment server. Set both 'repositoryLocation' and
      'serverRepositoryLocationPolicy' explicitly to ensure that the content
      installs on the deployment client in the correct location, which is
      $SPLUNK_HOME/etc/apps.
    * The deployment client uses the following 'serverRepositoryLocationPolicy'
      to determine the value of 'repositoryLocation'.

About the ServerClass.conf file, I prefer to manually manage it, even if you could deploy it using the main DS.

About the reload of the configurations from the secondary DS, it's possible to force it, but anyway, it will automatically run when it's the turn of those clients.

Ciao.

Giuseppe

0 Karma

jaracan
Communicator

Thank you for your insights @gcusello . 

So for deploymentclient.conf in 2nd-tier DS, it will be

deploymentclient.conf 
[deployment-client]
phoneHomeIntervalInSecs = 600
serverRepositoryLocationPolicy = rejectAlways
repositoryLocation = $SPLUNK_HOME/etc/deployment-apps

[target-broker:deploymentServer]
targetUri= https://masterdeploymentserver:8089

Also, for these items below, can you further explain?

"About the ServerClass.conf file, I prefer to manually manage it, even if you could deploy it using the main DS." -  Do we have other configs we need to set in serverclass.conf for Master DS and 2nd-tier DS in backend? Or we can utilize the Splunk Web Forwarder Management alone?

"About the reload of the configurations from the secondary DS, it's possible to force it, but anyway, it will automatically run when it's the turn of those clients." - When you mention to force it, are we pertaining in running the /opt/splunk/bin/splunk reload deploy-server command?

0 Karma

gcusello
SplunkTrust
SplunkTrust

Hi @jaracan ,

about your questions:

"About the ServerClass.conf file, I prefer to manually manage it, even if you could deploy it using the main DS." -  Do we have other configs we need to set in serverclass.conf for Master DS and 2nd-tier DS in backend? Or we can utilize the Splunk Web Forwarder Management alone?

As I said, I prefer to use the two tiers to be sure that the deployed apps are the correct ones and always updated.

For ServerClass.conf, you can manage it by GUI or manually modifying it by CLI, but there isn't any automated management system.

"About the reload of the configurations from the secondary DS, it's possible to force it, but anyway, it will automatically run when it's the turn of those clients." - When you mention to force it, are we pertaining in running the /opt/splunk/bin/splunk reload deploy-server command?

Yes, as I said, after Apps updates, you can wait that the deployment process will run without forcing reload.

ciao.

Giuseppe

0 Karma
Get Updates on the Splunk Community!

Enterprise Security Content Update (ESCU) | New Releases

In December, the Splunk Threat Research Team had 1 release of new security content via the Enterprise Security ...

Why am I not seeing the finding in Splunk Enterprise Security Analyst Queue?

(This is the first of a series of 2 blogs). Splunk Enterprise Security is a fantastic tool that offers robust ...

Index This | What are the 12 Days of Splunk-mas?

December 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...