Deployment Architecture

What is the best naming convention for serverclasses?

yaye
Explorer

Hello,

I'm currently trying to update our Splunk environment, but one problem I'm having is getting our server classes named correctly to make them future-proof and easy to use.

Currently my server class naming convention looks something like this:

<name> (general serverclass)

<name>_<location>(location based)

<name>_<machine type> (machine type based)

<name>_<machine type>_<location> (location and machine type based)


Example:
clients

clients_munich

clients_berlin

clients_linux

clients_linux_munich

clients_linux_berlin

clients_windows

clients_windows_munich

clients_windows_berlin

 

I would also use this convention for all other "groups" that need server classes.

Server, Services, Appliances, Network, ...

If you need examples for them just ask me 😄

Labels (1)
0 Karma
1 Solution

gcusello
SplunkTrust
SplunkTrust

Hi @yaye,

as @ITWhisperer hinted, the first thing id define (on paper) what each serverclass has to do.

In other words if the clients of Munich and paris must have the same apps you don't need to have two serverclasses.

So at first identify what each serverclass have to do in terms of apps to deploy, avoiding unuseful serverclasses that deploy exactly the same apps.

You could do this also defining a logic to use, and you can follow two approaches:

  • a serverclass for each omogeneous group of targets, in this way each target is in only one serverclass,
  • create different serverclasses for different scopes.

I prefer the second one:

for example, I create a serverclass to deploy the TA_Forwarders that contains outputs.conf and deploymentserver.conf and I created one serverclass for each group of targets that points to the same destination, on other words, one for the targets that point to one heavy Forwarder in a closed subnet, another for the targets that directly points to indexers and so on.

Then I created a serverclass for targets that need one or more special apps (e.g. syslog inputs or SAP, etc...)

In this way I can reduce the serverclasses and each target can be in more than one serverclasses.

Choose the logic you like!

then you can define a naming convention related to the logic you choosed: geografic, applications, ect...

Ciao.

Giuseppe

View solution in original post

0 Karma

gcusello
SplunkTrust
SplunkTrust

Hi @yaye,

as @ITWhisperer hinted, the first thing id define (on paper) what each serverclass has to do.

In other words if the clients of Munich and paris must have the same apps you don't need to have two serverclasses.

So at first identify what each serverclass have to do in terms of apps to deploy, avoiding unuseful serverclasses that deploy exactly the same apps.

You could do this also defining a logic to use, and you can follow two approaches:

  • a serverclass for each omogeneous group of targets, in this way each target is in only one serverclass,
  • create different serverclasses for different scopes.

I prefer the second one:

for example, I create a serverclass to deploy the TA_Forwarders that contains outputs.conf and deploymentserver.conf and I created one serverclass for each group of targets that points to the same destination, on other words, one for the targets that point to one heavy Forwarder in a closed subnet, another for the targets that directly points to indexers and so on.

Then I created a serverclass for targets that need one or more special apps (e.g. syslog inputs or SAP, etc...)

In this way I can reduce the serverclasses and each target can be in more than one serverclasses.

Choose the logic you like!

then you can define a naming convention related to the logic you choosed: geografic, applications, ect...

Ciao.

Giuseppe

0 Karma

gcusello
SplunkTrust
SplunkTrust

Hi @yaye ,

good for you, see next time!

Ciao and happy splunking

Giuseppe

P.S.: Karma Points are appreciated by all the contributors 😉

0 Karma

ITWhisperer
SplunkTrust
SplunkTrust

How are you expecting to use the serverclass? How are you expecting it to change? What is important to you about the serverclass?

Whatever you choose, the important thing is probably picking one convention and sticking to it!

0 Karma
Get Updates on the Splunk Community!

ICYMI - Check out the latest releases of Splunk Edge Processor

Splunk is pleased to announce the latest enhancements to Splunk Edge Processor.  HEC Receiver authorization ...

Introducing the 2024 SplunkTrust!

Hello, Splunk Community! We are beyond thrilled to announce our newest group of SplunkTrust members!  The ...

Introducing the 2024 Splunk MVPs!

We are excited to announce the 2024 cohort of the Splunk MVP program. Splunk MVPs are passionate members of ...