Since you understood now how this plank architect can grow from one single standalone machine to a large
enterprise plant?
With the same flow.
Let us go through.
Simple, large enterprise scenario.
According to our previous architecture designs, like small and medium enterprise reveals, we have
come to an understanding that it's good to have for every hundred gig of logs or every other gig of
license, and it is still indexers, since in our previous example we have considered anything between
100 to 200 GB as our medium enterprise.
For large enterprise in this example, we'll consider.
Any lessons of 250 gbps or a greater than as large enterprise?
We have come to the conclusion that we will have more than two indexes which can linearly increase with
your license limit.
We have a number of indexes figured out.
Let's see how many searchers we need.
As we have discussed earlier in other architecture reviews.
If we have more than eight users who is constantly active on Splunk running multiple searches, we can
have additional search and it is totally fine to begin with.
One sector also and scale up the searchers as a number of the users are increasing to begin with their
article here, which represents a typical large environment.
We can see there are group of searchers.
Probably one will be with premium apps.
The other one will be the, let's say, premium apps, enterprise security, VMware or PCI and group
of servers for normal users who are accessing and running hard rock searches investigating these kind
of use cases.
It is reasonable that data there will be multiple teams accessing Splunk because they are indexing more
than 200 gigs of data.
Of course, they really are more than eight or 15 people accessing their Splunk environment.
And also any premium purchases as we discussed interest, security, PCI, VMware, etc., all these
premium apps, they might be using one or two for that app.
So for that apps, you need dedicated search ads.
We can allocate them individual searches.
Hence, in this architecture, we are multiple searches, getting the user load of the Splunk environment.
In our architecture, we see that we are a group of multiple indexes based on our understanding.
We know that by now we will have more than two indexes for this environment and these indexes stores
all the data that has been processed and in this architecture so that storage for these indexes will
be holding 100% of your data, whatever the data that has been processed in plan will be shared among
these three or four indexes in standalone mode by default.
Logic eight indexers.
Out of these three or three indexes, each indexes receives the data from forward from certain amount
of time and then the forwarder.
Forwards.
The data for the next available index says to send the next chunk of data and let's say we have three
indexes, 100% of data is now like 33.33% available per indexers.
This is typical round robin algorithm based on time in this mode, if one indexer goes down, your searches
will return just approximately around 6660 7% of the results only from available to indexes.
Let's say this went down, you will have 33, 33, around 66 to 67% of results from only two indexers.
To get around this, we will see how clustering can help the clustering in Splunk as two different types
on a single set cluster, and the other one is multi site cluster.
We'll see about this the later part.
And we'll also going through the deep technical aspects of Splunk clustering when we are implementing
our own enterprise level, high availability, multisite clustering set up in Amazon.
As part of this tutorials.