Now, since we have all the required factors, let's proceed to have a look of how different architecture
looks like for demonstration purpose.
These are purely design based on my experience on Splunk for after working for close to five years in
these tutorials, I made three scenarios of architecture that is small, medium, large enterprise and
the one more the crazy one I call it, as it's the large enterprise with high availability and clustering
mention.
Let's go through them one by one.
The first one, as we see in our screen, it is the small architecture which can be compared to organization
with a license limit, which is less than 100 GB per day.
As you can see in this picture, we have one indexer, one searcher and a couple of people using it,
and we have lots of data forwarded from many different sources.
This is our typical small enterprise architecture.
Looks like.
Yet even the search can be optional if you have just one or two users.
All you can do is one.
Indexer should be able to handle the two one or two users load.
You can deploy everything as a single standalone instance, but always keep in your mind in a big organization,
even if the license is 100 GB per day.
That's good to start deploying them in distributed mode.
And as a distributed mode, it means that all the Splunk components are of dedicated rules.
That means search.
It is separated, indexer is separated, forwarders are separated, every forwarder.
So this is how each dedicated rules are configured.
So we call it a distributed mode of deployment.
I say this because as organization, let's say a big corporation at a ten G, it has purchased ten GB
license for just monitoring their logs.
My experience, I was seeing like once the organization realized the value of Splunk and the variety
of data it can process, it can scale from ten GB to several hundreds of GB in a matter of months.
So as an architecture, you should be aware of what level of data you have in your organisation and
how big is your organisation.
So that you should always think one step ahead so that you cover all these scenarios and you should
be ready that in case if I expand from 10 to 200 gigs, I need to add more indexes, more searchers,
so it's better to deploy from get going in a distributed mode.
And as we have discussed, it can be scaled up from a single instance setup to distributed setup where
each component will be responsible for specific task at any point of Splunk installation or operations
phase.
In previous videos, we have gone through saying that you can add your search at any time.
You can add your indexer at any time.
There is no impact, no data loss or no operational disruption, because that is how Splunk has been
designed.
It is easy to scale horizontally and vertically.
You can add resources to one machine, you can add additional components to one architecture, but you
still have all the data.
You can search, you can report, you can do everything.
But it's always a good practice to start from a good foundation.
Moving to the architecture.
Let me open up.
The designs which I have created for architecture.
So here, this is the architecture.
Which we have created for small enterprise, which has less than 100 GB of data we can see via only
one indexer.
One searcher and many universal forwarder which are covered as a block because it will be looking ugly
if I draw lines from all these end points to pointing to one indexes.
So I made it a container and sending it as a single.
The final motto is simple.
All the logs which are collected by agents or syslog devices will be sent to the indexer.
This is a typical small Splunk architecture.
Looks like the data sources can be off syslog firewalls, universal forwarders, Apple, Solaris, Linux,
Windows, or even scripted inputs.
We'll be sending logs to our indexes and the search engine if you come to the data flow.
The logs have been collected from the universal forwarder and it has been sent to index where it is
passed and broken down into pieces and then stored into our storage.
The indexer holds 100% of the data here search.
It is the one which queries the indexer based on the searches we write or the alerts or the reports,
and this query is run on the storage and indexer fetches the results and gives it to search it for visualization
or alerting purposes.