1
00:00:00,580 --> 00:00:02,530
Let's evaluate one by one.

2
00:00:02,680 --> 00:00:04,690
Consider a V for order.

3
00:00:04,720 --> 00:00:10,900
There are three brilliant cases where you can choose to have a V, forwarder and architecture.

4
00:00:11,080 --> 00:00:13,900
Number one is to filter out.

5
00:00:14,720 --> 00:00:15,600
The locks.

6
00:00:15,620 --> 00:00:16,360
Let's see.

7
00:00:16,370 --> 00:00:21,860
My firewall is just killing my license and it is sending 200 GB of data per day.

8
00:00:22,240 --> 00:00:24,700
I'll filter out all the day night connections.

9
00:00:24,710 --> 00:00:29,660
I can filter out denied connections at every forwarder level.

10
00:00:30,410 --> 00:00:37,370
And also I can remove some event codes from the Windows event log to reduce the noise on my license

11
00:00:37,370 --> 00:00:39,620
or the logs on my indexes.

12
00:00:39,860 --> 00:00:43,250
Second first one is filtering out the logs.

13
00:00:43,280 --> 00:00:47,900
The second one is to mask your sensitive information from the logs.

14
00:00:47,930 --> 00:00:52,390
Let's say I need to anonymize some part of the data which am sending to logs.

15
00:00:52,400 --> 00:00:58,690
I have some credit card information from my database which needs to be retrieved on Splunk to analyze,

16
00:00:58,700 --> 00:01:01,580
but the credit card numbers should be masked.

17
00:01:01,610 --> 00:01:04,130
You can do this using every forwarder.

18
00:01:04,910 --> 00:01:05,300
Going to.

19
00:01:05,300 --> 00:01:06,920
The third point is.

20
00:01:07,840 --> 00:01:17,320
Having a heavy forwarder can add a major performance boost for your indexer because imagine indexer

21
00:01:17,320 --> 00:01:25,740
is receiving 200 syslog inputs, either IWU'S or the precious IOPS input output operations per second

22
00:01:25,810 --> 00:01:27,790
is like gold for your indexer.

23
00:01:27,820 --> 00:01:36,070
The more it has, the more efficient it is when you are receiving 200 different syslog inputs or 200

24
00:01:36,070 --> 00:01:43,420
from 200 different IPS on the index, your indexer is reading from 200 different sources or let's say

25
00:01:43,840 --> 00:01:52,120
it is trying to read for this example will consider it is committing 200 read operations for just receiving

26
00:01:52,120 --> 00:01:58,540
those logs, which is highly acceptable because I have only 1000 left for processing, for storing,

27
00:01:58,540 --> 00:02:01,510
for fetching the results and giving it to my searcher.

28
00:02:01,780 --> 00:02:03,040
So what do I do?

29
00:02:03,070 --> 00:02:05,170
I place a V forward intercept.

30
00:02:05,170 --> 00:02:08,020
All this to reduce the noise.

31
00:02:09,070 --> 00:02:14,000
Initially the locks break down into pieces, then I'll feed it to my indexer.

32
00:02:14,050 --> 00:02:21,700
This will add good performance boost and release some of your Evos from your indexer, which is done

33
00:02:21,700 --> 00:02:25,730
by your every forwarder to go through all this.

34
00:02:25,750 --> 00:02:31,310
Three cases where you need a V for this one to filter out the noise in the logs.

35
00:02:31,330 --> 00:02:34,810
Second, to mask sensitive information in the logs.

36
00:02:34,900 --> 00:02:37,870
Third, to boost your indexer performance.

37
00:02:39,200 --> 00:02:48,290
These are the three cases where you can justify for having or evaluate successfully for every forward.

38
00:02:48,620 --> 00:02:55,550
The next one is evaluating the need for deployment server and the license master.

39
00:02:57,200 --> 00:03:07,010
Remember, deployment server is a must in large scale deployment where you will be having hundreds of

40
00:03:07,010 --> 00:03:15,200
orders to manage along with your Splunk instance deployment server will be your friend, which can help

41
00:03:15,200 --> 00:03:18,350
in changing the configuration of large number of clients.

42
00:03:18,350 --> 00:03:24,440
When I say client, it can be your universal forwarder, it can be your indexer, it can be your search

43
00:03:24,440 --> 00:03:24,590
it.

44
00:03:24,590 --> 00:03:26,360
It can be your folder.

45
00:03:26,390 --> 00:03:29,330
It can manage all the clients.

46
00:03:30,600 --> 00:03:33,420
And change the configuration in the matter of minutes.

47
00:03:33,420 --> 00:03:41,040
But if you have a small deployment of 10 to 20 clients to manage, there is absolutely no real reason

48
00:03:41,040 --> 00:03:43,200
for having a separate deployment server.

49
00:03:43,230 --> 00:03:51,270
In case if you are scaling up in the future, make sure you add a deployment server to manage your clients.

50
00:03:53,480 --> 00:03:58,880
And also one point to remember our deployment server is in a large scale environment.

51
00:03:58,910 --> 00:04:05,450
Deployment server plays a vital role in managing the entire Splunk infrastructure and its clients.

52
00:04:06,090 --> 00:04:09,050
And now coming to the license manager.

53
00:04:09,530 --> 00:04:17,120
This component, as we already know it, keeps track of license utilization by communicating to all

54
00:04:17,120 --> 00:04:18,270
our indexers.

55
00:04:18,290 --> 00:04:26,570
Most of these cases, this is an optional since either search, either indexer or your deployment server

56
00:04:26,600 --> 00:04:29,150
can carry out this licensing function.

57
00:04:29,420 --> 00:04:36,590
This license master functionality is very minimal when compared to other components in most of the environment

58
00:04:36,590 --> 00:04:42,350
or organization you can see it is usually clubbed along with your search it or your indexer.

59
00:04:44,700 --> 00:04:45,160
And.

60
00:04:46,200 --> 00:04:54,240
The next and the last option before moving on to storage calculation is clustering and high availability.

61
00:04:54,270 --> 00:04:58,000
We'll be discussing more about clustering in a separate module.

62
00:04:58,020 --> 00:05:01,980
As of now, we'll proceed with why we need clustering and Splunk.

63
00:05:02,820 --> 00:05:07,560
There are two main reasons for considering clustering and high availability.

64
00:05:10,180 --> 00:05:15,760
Number one is availability of your data so that if.

65
00:05:16,570 --> 00:05:23,320
Any single instance of your index that goes down, that should not be any impact or search results should

66
00:05:23,320 --> 00:05:33,010
be retrieved from one indexer so that if I have two indexes in my environment, let's say I don't have

67
00:05:33,010 --> 00:05:38,320
clustering and high availability, enable the index that has like 50% of data at any point of time.

68
00:05:38,320 --> 00:05:43,380
If one index goes down, I get only 50% of results, which is not accurate.

69
00:05:43,390 --> 00:05:45,940
That is one scenario to go for a clustering.

70
00:05:46,330 --> 00:05:52,060
The second option is the integrity of data so that the file system gets corrupted.

71
00:05:52,060 --> 00:05:55,570
You are not able to restore the data on one of the indexer.

72
00:05:55,600 --> 00:05:59,290
That shouldn't give you a chance to lose 50% of your data.

73
00:05:59,290 --> 00:06:03,730
But if you have a clustering enabled, it should be available on other indexes.

74
00:06:05,930 --> 00:06:07,580
These are some of the.

75
00:06:09,300 --> 00:06:13,620
Major factors to know before designing an architecture.