Now we have a good idea about how a small enterprise looks like.
Let's proceed further to medium enterprise architecture or Splunk.
From the previous discussions and consideration we have come to conclusion.
To use more than 100 GB per day licensing limit to have multiple indexers.
In this scenario, we have medium enterprise architecture which can consume or ingest 100 to 200 GB
per day into Splunk instance.
By now we know that we are multiple indexes in a medium enterprise.
As you can see, there is one index, the group of indexes, so it's better to have more than one indexes.
If we can afford three, probably you can have three also.
By now we know that we are having multiple indexes in a medium enterprise and when we come to searchers,
it's better to have more than one search.
If we are having more than eight users and also if we are using any of the premium apps offered by Splunk,
it's good practice to dedicate one complete search for the premium apps, since premium apps like Splunk
Enterprise Security, VMware App or IDSA or PCI.
These are.
Very high resource utilization apps.
They'll be running constant searches, alerts, the dashboard acceleration, data model acceleration.
There are a lot of features that will be going on inside the premium apps, so it's better to dedicate
one complete search to your premium apps.
The premium apps comes with Pre-Cert collection of reports, Dashboard Alert and data sets.
These are the things which are constantly running in the background.
And along with this, if you add a dock such as run by normal users and there are the alerts or the
reports that you have created, it adds additional load on the search.
And so starts search response starts to deteriorate.
In our diagram, we can see we have two search efforts and two indexes or probably multiple indexes,
which is pretty common for a medium and Splunk architecture.
Here, the data flow will be like.
The Universal Forwarders.
Let me open up the bigger architecture.
This is a medium enterprise.
Here the data flow will be like.
The Universal Forwarders are fetching the data and feeding it to a group of indexes and syslog devices,
also sending logs to our indexers indexes direct.
There is no intermediate any forwarders if they are syslog devices or noisy and much more.
A causing trouble for the indexer.
We can probably install it every forwarder in between.
Now.
The data flow.
We collected the logs using your cell phone to send it to indexer.
The same indexer parses certain stores.
The searcher runs a query, indexer takes the query and searches it on the storage and fetches the results
and gives it back to search it.
The search searcher uses this data for the visualization or alerting purposes.
Now in this architecture, everything seems to be fine for a medium enterprise.
But as a Splunk, your job is not yet done before finalizing the design, evaluate the need for deployment
server, analyze and predicts how many agents or universal forwarder will be in your deployments if
it is greater than 25 to 50 lengths.
Of course, it's a good practice to have a deployment server so that your management.
Of these clients will be pretty good.
You can put in a deployment server somewhere here because it will not be in your operational architecture.
So it will be somewhere standing out.
But if you're having just 10 to 20 clients, which are quite noisy and generating 100, so 200 gigs
of data, it should be good to trade off just to postpone your deployments in case of your next plan
of scaling up your architecture.
Now we will evaluate it deployment.
So let's see about have for order.
As we discussed earlier.
If our data sources in a deployment or in our organization are very much chatty or sending a lot of
junk data.
To Splunk, then.
It would be best to have heavy forward in between your universal forward and index.
That will be somewhere here where in between universal forwarders and index it, you can have your heavy
forwarder.
The syslog servers, then the data flow will change to every forwarder will receive the logs from syslog
servers it passes, it then sends to your indexer, which will be much efficient.
The logs will also be processed before reaching your Splunk indexes so that our parsing load on the
indexers is also reduced.
Instead of indexing listening on multiple ports for syslog or multiple IPS or reception of data from
multiple points, it can efficiently use its previous input outputs operations per second or IOPS for
concentrating and receiving the logs from heavy forwarders because indexer will have only one source
for the reception of logs.
Now that will be our way forward so that most of its IOO can be used for storing and fetching results
for our queries.
Based on this evaluating criteria for having a Ford as our architect, you will decide whether to have
an RV forward or not.
We are going through.
The Medium Splunk enterprise thoroughly.
As of now, you might have a good idea how Splunk detector grows from one single instance.