For simplicity purposes of this module.
In this slide we will be considering single site indexer clustering in single site indexer clustering.
Each indexers exchanges the data that it has been received from the forwarders so that at any point
if one index fails.
The data can be retrieved from the other two instances.
To understand how this is actually works.
We need to know more about replication and search factors which will be covering at a later stage because
of the complexity involved in choosing them and the depth of the concept of replication.
Search Factors We go now we understand that single site clustering in Splunk exchanges data between
indexers in order to overcome any data loss or disruption into our search results during an event of
any indexer going down.
Now we got it clear.
Let's move on further down and compare this with our medium architecture.
If we see our medium architecture, this is our medium architecture.
You can see that there are some components like deployment server and heavy forwarder and license manager.
There are three blocks which are new in large enterprise.
As you can see.
These three components are present in the large.
Enterprise of Splunk architecture.
We all know by now that a large deployment of Splunk we must have a deployment server.
For managing this plan universal for orders and also others plan components.
We will help to reduce managing Splunk infrastructure exponentially by having a single deployment server.
Consider an example of having 200 clients and logging them individually to just to change an IP or the
hostname.
Of that instance.
Instead of that, you can push this configuration from deployment.
So probably in 5 minutes rather than logging into 200 different machines one at a time.
The deployment service acts like a boss in an architecture where it talks to all the components across
the architecture and tells each component how to operate and what configurations are deployed on each
component.
And now we can also monitor the health of the components throughout the infrastructure using deployment.
So.
Now we got clear about deployments.
So let's move on to our license manager where we see from the architecture.
It keeps tabs on our license utilization.
And it can also alert based on the license violation on upon reaching a threshold as per alert configurations
of this license usage.
This functionality.
Of License manager is almost identical to non cluster or cluster environment where its only function
is to collect the license usage from all the components and keep track of the violations.
Daily user statistics of our licenses and report them accordingly.
And we also see in this architecture there are heavy forwarders in between universal forwarders or our
data sources and indexers.
This area.
Forwarders are receiving their data from forwarders and passing it and filters some of the.
Events.
And sent it to the index where the index will be receiving the data from these AP forwarder, which
are passed and filter by the EV forwarders, is being received on the indexes and stored on the indexes
itself.
This is a good option and best practice to have a V forwarder in newer architecture of large deployments.
It will add significant value to the Splunk architecture.
By now we are clear with the three architecture small, medium and large enterprises.
Now let us see one of the best architecture of Splunk considering and scaled up version of large deployment.