1
00:00:00,180 --> 00:00:03,420
For simplicity purposes of this module.

2
00:00:03,420 --> 00:00:10,110
In this slide we will be considering single site indexer clustering in single site indexer clustering.

3
00:00:11,440 --> 00:00:19,510
Each indexers exchanges the data that it has been received from the forwarders so that at any point

4
00:00:19,510 --> 00:00:21,460
if one index fails.

5
00:00:22,800 --> 00:00:26,040
The data can be retrieved from the other two instances.

6
00:00:26,040 --> 00:00:29,730
To understand how this is actually works.

7
00:00:29,760 --> 00:00:36,750
We need to know more about replication and search factors which will be covering at a later stage because

8
00:00:36,750 --> 00:00:42,870
of the complexity involved in choosing them and the depth of the concept of replication.

9
00:00:43,020 --> 00:00:50,490
Search Factors We go now we understand that single site clustering in Splunk exchanges data between

10
00:00:51,030 --> 00:00:59,520
indexers in order to overcome any data loss or disruption into our search results during an event of

11
00:00:59,520 --> 00:01:01,920
any indexer going down.

12
00:01:03,290 --> 00:01:05,330
Now we got it clear.

13
00:01:05,330 --> 00:01:10,280
Let's move on further down and compare this with our medium architecture.

14
00:01:11,600 --> 00:01:15,080
If we see our medium architecture, this is our medium architecture.

15
00:01:15,080 --> 00:01:22,250
You can see that there are some components like deployment server and heavy forwarder and license manager.

16
00:01:22,280 --> 00:01:25,790
There are three blocks which are new in large enterprise.

17
00:01:27,350 --> 00:01:28,280
As you can see.

18
00:01:29,710 --> 00:01:32,800
These three components are present in the large.

19
00:01:33,960 --> 00:01:36,000
Enterprise of Splunk architecture.

20
00:01:36,000 --> 00:01:43,800
We all know by now that a large deployment of Splunk we must have a deployment server.

21
00:01:45,130 --> 00:01:49,690
For managing this plan universal for orders and also others plan components.

22
00:01:50,110 --> 00:01:58,940
We will help to reduce managing Splunk infrastructure exponentially by having a single deployment server.

23
00:01:58,960 --> 00:02:05,830
Consider an example of having 200 clients and logging them individually to just to change an IP or the

24
00:02:05,830 --> 00:02:06,610
hostname.

25
00:02:07,410 --> 00:02:08,880
Of that instance.

26
00:02:08,880 --> 00:02:11,850
Instead of that, you can push this configuration from deployment.

27
00:02:11,850 --> 00:02:18,750
So probably in 5 minutes rather than logging into 200 different machines one at a time.

28
00:02:20,850 --> 00:02:28,470
The deployment service acts like a boss in an architecture where it talks to all the components across

29
00:02:28,470 --> 00:02:36,990
the architecture and tells each component how to operate and what configurations are deployed on each

30
00:02:36,990 --> 00:02:37,710
component.

31
00:02:37,710 --> 00:02:44,970
And now we can also monitor the health of the components throughout the infrastructure using deployment.

32
00:02:44,970 --> 00:02:45,450
So.

33
00:02:46,900 --> 00:02:49,860
Now we got clear about deployments.

34
00:02:49,870 --> 00:02:55,210
So let's move on to our license manager where we see from the architecture.

35
00:02:55,240 --> 00:02:58,600
It keeps tabs on our license utilization.

36
00:03:00,110 --> 00:03:08,570
And it can also alert based on the license violation on upon reaching a threshold as per alert configurations

37
00:03:08,780 --> 00:03:10,460
of this license usage.

38
00:03:10,640 --> 00:03:12,380
This functionality.

39
00:03:13,440 --> 00:03:21,810
Of License manager is almost identical to non cluster or cluster environment where its only function

40
00:03:21,810 --> 00:03:27,090
is to collect the license usage from all the components and keep track of the violations.

41
00:03:27,120 --> 00:03:31,740
Daily user statistics of our licenses and report them accordingly.

42
00:03:36,250 --> 00:03:43,240
And we also see in this architecture there are heavy forwarders in between universal forwarders or our

43
00:03:43,240 --> 00:03:46,090
data sources and indexers.

44
00:03:51,510 --> 00:03:52,230
This area.

45
00:03:52,230 --> 00:03:58,800
Forwarders are receiving their data from forwarders and passing it and filters some of the.

46
00:04:00,320 --> 00:04:01,100
Events.

47
00:04:02,160 --> 00:04:09,840
And sent it to the index where the index will be receiving the data from these AP forwarder, which

48
00:04:09,840 --> 00:04:17,880
are passed and filter by the EV forwarders, is being received on the indexes and stored on the indexes

49
00:04:17,880 --> 00:04:18,540
itself.

50
00:04:20,120 --> 00:04:28,950
This is a good option and best practice to have a V forwarder in newer architecture of large deployments.

51
00:04:28,970 --> 00:04:33,470
It will add significant value to the Splunk architecture.

52
00:04:36,220 --> 00:04:42,770
By now we are clear with the three architecture small, medium and large enterprises.

53
00:04:42,790 --> 00:04:51,610
Now let us see one of the best architecture of Splunk considering and scaled up version of large deployment.