1
00:00:01,530 --> 00:00:05,790
Now we have a good idea about how a small enterprise looks like.

2
00:00:05,790 --> 00:00:10,980
Let's proceed further to medium enterprise architecture or Splunk.

3
00:00:15,260 --> 00:00:19,460
From the previous discussions and consideration we have come to conclusion.

4
00:00:19,640 --> 00:00:26,030
To use more than 100 GB per day licensing limit to have multiple indexers.

5
00:00:26,060 --> 00:00:34,760
In this scenario, we have medium enterprise architecture which can consume or ingest 100 to 200 GB

6
00:00:34,760 --> 00:00:37,940
per day into Splunk instance.

7
00:00:37,940 --> 00:00:45,190
By now we know that we are multiple indexes in a medium enterprise.

8
00:00:45,200 --> 00:00:53,110
As you can see, there is one index, the group of indexes, so it's better to have more than one indexes.

9
00:00:53,840 --> 00:00:56,750
If we can afford three, probably you can have three also.

10
00:00:56,960 --> 00:01:03,630
By now we know that we are having multiple indexes in a medium enterprise and when we come to searchers,

11
00:01:03,650 --> 00:01:05,570
it's better to have more than one search.

12
00:01:05,780 --> 00:01:16,010
If we are having more than eight users and also if we are using any of the premium apps offered by Splunk,

13
00:01:16,190 --> 00:01:24,530
it's good practice to dedicate one complete search for the premium apps, since premium apps like Splunk

14
00:01:24,530 --> 00:01:28,790
Enterprise Security, VMware App or IDSA or PCI.

15
00:01:28,820 --> 00:01:29,600
These are.

16
00:01:30,990 --> 00:01:34,480
Very high resource utilization apps.

17
00:01:34,500 --> 00:01:39,690
They'll be running constant searches, alerts, the dashboard acceleration, data model acceleration.

18
00:01:39,690 --> 00:01:45,450
There are a lot of features that will be going on inside the premium apps, so it's better to dedicate

19
00:01:45,450 --> 00:01:49,440
one complete search to your premium apps.

20
00:01:50,010 --> 00:01:56,190
The premium apps comes with Pre-Cert collection of reports, Dashboard Alert and data sets.

21
00:01:56,970 --> 00:02:01,010
These are the things which are constantly running in the background.

22
00:02:01,020 --> 00:02:07,500
And along with this, if you add a dock such as run by normal users and there are the alerts or the

23
00:02:07,500 --> 00:02:12,270
reports that you have created, it adds additional load on the search.

24
00:02:12,300 --> 00:02:16,110
And so starts search response starts to deteriorate.

25
00:02:16,140 --> 00:02:22,800
In our diagram, we can see we have two search efforts and two indexes or probably multiple indexes,

26
00:02:22,800 --> 00:02:26,820
which is pretty common for a medium and Splunk architecture.

27
00:02:29,850 --> 00:02:32,940
Here, the data flow will be like.

28
00:02:34,460 --> 00:02:36,170
The Universal Forwarders.

29
00:02:36,860 --> 00:02:39,290
Let me open up the bigger architecture.

30
00:02:40,100 --> 00:02:41,780
This is a medium enterprise.

31
00:02:42,980 --> 00:02:45,590
Here the data flow will be like.

32
00:02:47,080 --> 00:02:54,400
The Universal Forwarders are fetching the data and feeding it to a group of indexes and syslog devices,

33
00:02:54,400 --> 00:02:58,900
also sending logs to our indexers indexes direct.

34
00:02:58,930 --> 00:03:05,650
There is no intermediate any forwarders if they are syslog devices or noisy and much more.

35
00:03:06,530 --> 00:03:08,040
A causing trouble for the indexer.

36
00:03:08,040 --> 00:03:10,770
We can probably install it every forwarder in between.

37
00:03:12,590 --> 00:03:13,190
Now.

38
00:03:13,980 --> 00:03:15,000
The data flow.

39
00:03:15,600 --> 00:03:18,720
We collected the logs using your cell phone to send it to indexer.

40
00:03:18,720 --> 00:03:20,760
The same indexer parses certain stores.

41
00:03:21,900 --> 00:03:28,440
The searcher runs a query, indexer takes the query and searches it on the storage and fetches the results

42
00:03:28,440 --> 00:03:30,270
and gives it back to search it.

43
00:03:30,780 --> 00:03:35,550
The search searcher uses this data for the visualization or alerting purposes.

44
00:03:37,950 --> 00:03:43,920
Now in this architecture, everything seems to be fine for a medium enterprise.

45
00:03:43,920 --> 00:03:54,690
But as a Splunk, your job is not yet done before finalizing the design, evaluate the need for deployment

46
00:03:54,690 --> 00:04:02,010
server, analyze and predicts how many agents or universal forwarder will be in your deployments if

47
00:04:02,010 --> 00:04:04,680
it is greater than 25 to 50 lengths.

48
00:04:04,770 --> 00:04:10,320
Of course, it's a good practice to have a deployment server so that your management.

49
00:04:11,170 --> 00:04:13,720
Of these clients will be pretty good.

50
00:04:13,750 --> 00:04:20,440
You can put in a deployment server somewhere here because it will not be in your operational architecture.

51
00:04:20,440 --> 00:04:22,390
So it will be somewhere standing out.

52
00:04:23,530 --> 00:04:29,230
But if you're having just 10 to 20 clients, which are quite noisy and generating 100, so 200 gigs

53
00:04:29,230 --> 00:04:36,400
of data, it should be good to trade off just to postpone your deployments in case of your next plan

54
00:04:36,400 --> 00:04:39,400
of scaling up your architecture.

55
00:04:41,750 --> 00:04:44,660
Now we will evaluate it deployment.

56
00:04:44,660 --> 00:04:47,080
So let's see about have for order.

57
00:04:48,340 --> 00:04:49,750
As we discussed earlier.

58
00:04:52,540 --> 00:05:02,920
If our data sources in a deployment or in our organization are very much chatty or sending a lot of

59
00:05:02,920 --> 00:05:03,880
junk data.

60
00:05:05,910 --> 00:05:07,500
To Splunk, then.

61
00:05:08,520 --> 00:05:14,850
It would be best to have heavy forward in between your universal forward and index.

62
00:05:15,150 --> 00:05:21,660
That will be somewhere here where in between universal forwarders and index it, you can have your heavy

63
00:05:21,660 --> 00:05:22,170
forwarder.

64
00:05:24,750 --> 00:05:31,350
The syslog servers, then the data flow will change to every forwarder will receive the logs from syslog

65
00:05:31,350 --> 00:05:36,690
servers it passes, it then sends to your indexer, which will be much efficient.

66
00:05:37,240 --> 00:05:44,100
The logs will also be processed before reaching your Splunk indexes so that our parsing load on the

67
00:05:44,100 --> 00:05:45,960
indexers is also reduced.

68
00:05:45,960 --> 00:05:55,080
Instead of indexing listening on multiple ports for syslog or multiple IPS or reception of data from

69
00:05:55,080 --> 00:06:03,420
multiple points, it can efficiently use its previous input outputs operations per second or IOPS for

70
00:06:03,420 --> 00:06:10,470
concentrating and receiving the logs from heavy forwarders because indexer will have only one source

71
00:06:10,470 --> 00:06:11,700
for the reception of logs.

72
00:06:11,700 --> 00:06:20,160
Now that will be our way forward so that most of its IOO can be used for storing and fetching results

73
00:06:20,160 --> 00:06:21,930
for our queries.

74
00:06:23,210 --> 00:06:30,310
Based on this evaluating criteria for having a Ford as our architect, you will decide whether to have

75
00:06:30,310 --> 00:06:32,060
an RV forward or not.

76
00:06:32,780 --> 00:06:34,250
We are going through.

77
00:06:35,240 --> 00:06:39,110
The Medium Splunk enterprise thoroughly.

78
00:06:40,150 --> 00:06:47,740
As of now, you might have a good idea how Splunk detector grows from one single instance.