1
00:00:03,440 --> 00:00:11,900
Since you understood now how this plank architect can grow from one single standalone machine to a large

2
00:00:11,900 --> 00:00:13,160
enterprise plant?

3
00:00:15,180 --> 00:00:16,860
With the same flow.

4
00:00:16,890 --> 00:00:17,990
Let us go through.

5
00:00:18,030 --> 00:00:21,390
Simple, large enterprise scenario.

6
00:00:22,170 --> 00:00:28,890
According to our previous architecture designs, like small and medium enterprise reveals, we have

7
00:00:28,890 --> 00:00:36,120
come to an understanding that it's good to have for every hundred gig of logs or every other gig of

8
00:00:36,120 --> 00:00:42,420
license, and it is still indexers, since in our previous example we have considered anything between

9
00:00:42,420 --> 00:00:48,690
100 to 200 GB as our medium enterprise.

10
00:00:51,120 --> 00:00:54,390
For large enterprise in this example, we'll consider.

11
00:00:56,830 --> 00:01:01,450
Any lessons of 250 gbps or a greater than as large enterprise?

12
00:01:01,480 --> 00:01:07,990
We have come to the conclusion that we will have more than two indexes which can linearly increase with

13
00:01:07,990 --> 00:01:10,150
your license limit.

14
00:01:12,900 --> 00:01:16,470
We have a number of indexes figured out.

15
00:01:16,590 --> 00:01:20,070
Let's see how many searchers we need.

16
00:01:21,480 --> 00:01:25,710
As we have discussed earlier in other architecture reviews.

17
00:01:26,100 --> 00:01:33,090
If we have more than eight users who is constantly active on Splunk running multiple searches, we can

18
00:01:33,090 --> 00:01:37,800
have additional search and it is totally fine to begin with.

19
00:01:39,270 --> 00:01:47,660
One sector also and scale up the searchers as a number of the users are increasing to begin with their

20
00:01:47,720 --> 00:01:52,680
article here, which represents a typical large environment.

21
00:01:54,210 --> 00:01:57,150
We can see there are group of searchers.

22
00:01:57,990 --> 00:02:01,170
Probably one will be with premium apps.

23
00:02:01,170 --> 00:02:08,190
The other one will be the, let's say, premium apps, enterprise security, VMware or PCI and group

24
00:02:08,190 --> 00:02:14,400
of servers for normal users who are accessing and running hard rock searches investigating these kind

25
00:02:14,400 --> 00:02:15,720
of use cases.

26
00:02:16,140 --> 00:02:24,480
It is reasonable that data there will be multiple teams accessing Splunk because they are indexing more

27
00:02:24,480 --> 00:02:25,980
than 200 gigs of data.

28
00:02:26,010 --> 00:02:32,820
Of course, they really are more than eight or 15 people accessing their Splunk environment.

29
00:02:33,890 --> 00:02:41,540
And also any premium purchases as we discussed interest, security, PCI, VMware, etc., all these

30
00:02:41,540 --> 00:02:44,960
premium apps, they might be using one or two for that app.

31
00:02:44,960 --> 00:02:48,720
So for that apps, you need dedicated search ads.

32
00:02:49,010 --> 00:02:51,770
We can allocate them individual searches.

33
00:02:52,100 --> 00:03:01,370
Hence, in this architecture, we are multiple searches, getting the user load of the Splunk environment.

34
00:03:03,910 --> 00:03:11,140
In our architecture, we see that we are a group of multiple indexes based on our understanding.

35
00:03:11,140 --> 00:03:18,760
We know that by now we will have more than two indexes for this environment and these indexes stores

36
00:03:18,760 --> 00:03:26,920
all the data that has been processed and in this architecture so that storage for these indexes will

37
00:03:26,920 --> 00:03:34,330
be holding 100% of your data, whatever the data that has been processed in plan will be shared among

38
00:03:34,330 --> 00:03:39,880
these three or four indexes in standalone mode by default.

39
00:03:40,980 --> 00:03:43,530
Logic eight indexers.

40
00:03:43,830 --> 00:03:51,240
Out of these three or three indexes, each indexes receives the data from forward from certain amount

41
00:03:51,240 --> 00:03:54,510
of time and then the forwarder.

42
00:03:55,520 --> 00:03:56,110
Forwards.

43
00:03:56,120 --> 00:04:04,610
The data for the next available index says to send the next chunk of data and let's say we have three

44
00:04:04,610 --> 00:04:11,690
indexes, 100% of data is now like 33.33% available per indexers.

45
00:04:13,390 --> 00:04:21,400
This is typical round robin algorithm based on time in this mode, if one indexer goes down, your searches

46
00:04:21,400 --> 00:04:30,590
will return just approximately around 6660 7% of the results only from available to indexes.

47
00:04:30,610 --> 00:04:38,830
Let's say this went down, you will have 33, 33, around 66 to 67% of results from only two indexers.

48
00:04:39,100 --> 00:04:47,170
To get around this, we will see how clustering can help the clustering in Splunk as two different types

49
00:04:47,170 --> 00:04:51,280
on a single set cluster, and the other one is multi site cluster.

50
00:04:51,280 --> 00:04:53,770
We'll see about this the later part.

51
00:04:55,180 --> 00:05:01,480
And we'll also going through the deep technical aspects of Splunk clustering when we are implementing

52
00:05:01,480 --> 00:05:09,110
our own enterprise level, high availability, multisite clustering set up in Amazon.

53
00:05:09,910 --> 00:05:12,010
As part of this tutorials.