Let's evaluate one by one.
Consider a V for order.
There are three brilliant cases where you can choose to have a V, forwarder and architecture.
Number one is to filter out.
The locks.
Let's see.
My firewall is just killing my license and it is sending 200 GB of data per day.
I'll filter out all the day night connections.
I can filter out denied connections at every forwarder level.
And also I can remove some event codes from the Windows event log to reduce the noise on my license
or the logs on my indexes.
Second first one is filtering out the logs.
The second one is to mask your sensitive information from the logs.
Let's say I need to anonymize some part of the data which am sending to logs.
I have some credit card information from my database which needs to be retrieved on Splunk to analyze,
but the credit card numbers should be masked.
You can do this using every forwarder.
Going to.
The third point is.
Having a heavy forwarder can add a major performance boost for your indexer because imagine indexer
is receiving 200 syslog inputs, either IWU'S or the precious IOPS input output operations per second
is like gold for your indexer.
The more it has, the more efficient it is when you are receiving 200 different syslog inputs or 200
from 200 different IPS on the index, your indexer is reading from 200 different sources or let's say
it is trying to read for this example will consider it is committing 200 read operations for just receiving
those logs, which is highly acceptable because I have only 1000 left for processing, for storing,
for fetching the results and giving it to my searcher.
So what do I do?
I place a V forward intercept.
All this to reduce the noise.
Initially the locks break down into pieces, then I'll feed it to my indexer.
This will add good performance boost and release some of your Evos from your indexer, which is done
by your every forwarder to go through all this.
Three cases where you need a V for this one to filter out the noise in the logs.
Second, to mask sensitive information in the logs.
Third, to boost your indexer performance.
These are the three cases where you can justify for having or evaluate successfully for every forward.
The next one is evaluating the need for deployment server and the license master.
Remember, deployment server is a must in large scale deployment where you will be having hundreds of
orders to manage along with your Splunk instance deployment server will be your friend, which can help
in changing the configuration of large number of clients.
When I say client, it can be your universal forwarder, it can be your indexer, it can be your search
it.
It can be your folder.
It can manage all the clients.
And change the configuration in the matter of minutes.
But if you have a small deployment of 10 to 20 clients to manage, there is absolutely no real reason
for having a separate deployment server.
In case if you are scaling up in the future, make sure you add a deployment server to manage your clients.
And also one point to remember our deployment server is in a large scale environment.
Deployment server plays a vital role in managing the entire Splunk infrastructure and its clients.
And now coming to the license manager.
This component, as we already know it, keeps track of license utilization by communicating to all
our indexers.
Most of these cases, this is an optional since either search, either indexer or your deployment server
can carry out this licensing function.
This license master functionality is very minimal when compared to other components in most of the environment
or organization you can see it is usually clubbed along with your search it or your indexer.
And.
The next and the last option before moving on to storage calculation is clustering and high availability.
We'll be discussing more about clustering in a separate module.
As of now, we'll proceed with why we need clustering and Splunk.
There are two main reasons for considering clustering and high availability.
Number one is availability of your data so that if.
Any single instance of your index that goes down, that should not be any impact or search results should
be retrieved from one indexer so that if I have two indexes in my environment, let's say I don't have
clustering and high availability, enable the index that has like 50% of data at any point of time.
If one index goes down, I get only 50% of results, which is not accurate.
That is one scenario to go for a clustering.
The second option is the integrity of data so that the file system gets corrupted.
You are not able to restore the data on one of the indexer.
That shouldn't give you a chance to lose 50% of your data.
But if you have a clustering enabled, it should be available on other indexes.
These are some of the.
Major factors to know before designing an architecture.