Splunk Architectures

00:00

Hello and welcome back to the Splunk Enterprise Certified Administrator course on Sai Buri were on a lesson 2.3 the final lesson of module to *** architectures.

00:13

So in this lesson, or learning objectives are gonna be toe one review the basic Splunk architectures that you would see in the wild to identify how Splunk premium APS would affect a splint deployment or the way that the split deployment is architect er, architectures and then three

00:32

to define what a Splunk validated architecture where SDA is and

00:37

where to learn more about those

00:41

first. We're gonna talk quick about why we're learning this as we have in every other lesson. So I think it's important that as someone who is going to be managing a Splunk deployment, you should be able to understand basic layouts of Splunk so that you can identify what what architecture, your leveraging,

01:00

and then also identify opportunities for enhancing your splint deployment

01:06

by making changes to the architecture. So by knowing what options are out there, that makes this a much simpler process.

01:15

So here is a list of five basic Splunk architectures. You might see their more than this, but I think that this is a good baseline. So first there's all in one. Or you could have a distributed environment where you're separating your spelling components out from one device into multiple.

01:32

Then you could have extradited environment where you leverage index or clustering one where you leverage search head clustering, or you could be leveraging both.

01:40

So the all in one is not something really going to see in a lot of production environments, especially at the court corporate level.

01:49

It's just not a powerful enough or scalable enough solution. Toe handle. Large enterprise environments, amounts of data. So this is more something you'd see for testing environments or a personal spooling set up that you have for, you know, working on your own projects or something.

02:08

The benefits of it is it's very easy to manage, and you only have to work on one device.

02:15

The cons. As I mentioned, our performance limitations, lack of scalability, and if the device goes down, then it's a single point of failure. Four years funk.

02:25

So what a distributed environment is is it's just breaking up those functions of Splunk search and indexing into dedicated devices. So now you have search heads and indexers. You could have any number of search heads and number of indexers, and it'll still be a distributor environment.

02:46

One

02:46

indexer versus 10 still distributed environment.

02:50

Then you will also have to have management servers like the license master or deployment server, or all those other

02:58

management service that we talked about in module one. So the benefits of this is you get. You get scaling for your

03:07

performance of the Splunk

03:09

deployment. You can keep adding horizontal devices more, more indexers to keep increasing compute power and then also fault tolerance. Where if one device goes down now, you you can still access the other devices. But in a basic distribute environment that's pretty minimal because

03:28

it's not like a clustered environment where you have additional copies of the data, so you might have incomplete data.

03:36

So not quite as fault tolerant as when you leverage clustering

03:42

and then make a con is obviously the increased management overhead and also the cost of additional hardware.

03:49

Here's an example of what this could look like. One search head as many indexers as you want. It could even just be one and then obviously afford or sending data in But the key is that you're just separating the search and indexing functions.

04:03

So then you gotta distribute environment where you're clustering your indexers. So this is going toe. Increase your hardware components even more because you'll be required to have at least three indexers have a cluster, and then you'll also have to bring in an additional management. Console them the cluster master, as you remember from earlier

04:21

when you leverage index or clustering.

04:25

The good news is when you do this now, you can have multiple copies of your data split up among the indexers. So now you have real fault tolerance. Like if an index or goes down, you still have full access to all of your data, and it doesn't interrupt anything

04:40

but obviously cons of same thing as the distribute environment. As you get more complex, you are losing some performance and you're increasing hardware costs. So you just have to balance

04:53

that with the performance benefits and the and also the high availability and fault tolerance. Here's an example what this would look like. You can see that you have three indexers, and you could see the blue lines indicate that data is being sent back and forth between the indexers, which is unique to a cluster.

05:10

And then you also see that you have your cluster master or master node

05:15

distributing what environment could be with search clustering. This is gonna be where you have at least three search heads because that's required first or check lister and where they all work together. And generally they'll be put behind a load balancer so that

05:29

basically the end users can't distinguish which one they're touching. They just know that they're getting to Splunk, so they might not even know that it's clustered on then. Also, you'll have to add in the dip lawyer in this case to manage the search head cluster. So this gives you, ah, high availability searching. So if one search it goes down, the users won't notice they'll still connect.

05:47

And then also you'll have redundancy of search time knowledge objects.

05:51

So anything that's ah configuration made on the search head will be automatically duplicated across all of the search heads, which makes you less likely to lose any of your configurations. And again you'll have increased management overhead and increased hardware costs.

06:08

Here's an example of this as you can see the users connect through the low down, sir. And then they get assigned. They get sent. Teoh, one of these search heads based on load.

06:18

Uh, so yeah. Then something. That note is the captain here. So unlike the Cluster Master, where the cluster minister orchestrates a lot of the

06:28

replication and stuff in a search, I cluster the members of the search a cluster elected captain and the captain handles search, time knowledge, object replication and those tasks the deploy er, Onley pushes configurations.

06:45

And then obviously you could deploy it with both. So you get all the benefits of the previously mentioned what you do have to have a minimum of three search heads, three indexers in cluster master and a dip lawyer. So a lot more hardware and a lot more management overhead. Here's an example. This is basically just a combination of those

07:03

two pictures we'd see in previous labour brings it all together.

07:09

Then something quick to note is when you're dealing with splint premium naps like Enterprise security or T s. I I t service intelligence, these abs you have to pay for separately and they have their own licensing and they're also very, very resource intensive.

07:25

And so when you introduce one of these into your *** environment, you'll have to set up an entire search head or search had cluster

07:31

just to support the APP itself. So that's how it's going to impact your architecture. And it's important to keep in mind that this can really affect you, know how you deploys belong.

07:44

And then quickly we'll just do. A quick note on SDA is this is out of scope for this course, but it's I thought it was important just to be familiar with them. They're basically codes that Splunk uses to describe different architectures, and you can look at this sheet and it goes through them pretty thoroughly.

08:01

I'm gonna provide a link to the paper that Splunk has about SBS, so if you want more information, you can feel free toe read through and find that out. But I just wanted something important to be familiar with, but you don't need to know for the exam,

08:16

so we'll do a quick knowledge assessment for a review of the last lesson. So which components are management devices? You can pause here and select an answer. Next slide will answer this. And the answer is to cluster Master Deploy ER and license master

08:33

in one heavy Florida is not a management device, and in three, none of those are management devices.

08:39

So in summary, we've discussed the five basics blanc architectures that you're likely to see.

08:43

You've also talked about pre maps and how they'll require their own search head, and we'll also put increased load on your indexers. And then we've talked about slowing validated architectures and where you can find more information about that. So that wraps everything up for this lesson. So you know everything you need to know about Splunk architectures for now.