6 hours 3 minutes
Hello. Welcome back to the Splunk Enterprise Certified Administrator course on Cyber. This is less an 8.3 Were will be discussing search head clustering. This will be the final lesson in module eight.
So why are we learning about search head clustering? So in the previous videos, we discussed how to configure search heads, and this is really the last configuration you might have to do for your search heads. So you need to be equipped as a Splunk admin with the knowledge
of what benefits you'll
derived from search. I clustering what the requirements for setting this up are going to be. How to do that configuration in order to make the decision. For
if you should
use search a clustering in your environment or not. Or if you've already decided to go with search clustering, then you'll also need this knowledge that you're capable of configuring it. And also, there are some caveats with how you manage an environment where there's a search head cluster,
uh, deployed, and so it's important to review that as well. In case you're inheriting an environment with a search head cluster,
make sure that you know how to manage the configurations for that environment.
So now we've discussed why we're learning it. Let's discuss exactly what we're gonna be learning in this video, so we'll define what search had. Clustering is. We'll talk about the benefits of search had clustering, and we'll also go over the requirements that you're going to have if you're going toe cluster your search heads as well.
So we discussed this briefly in other videos, but this could be a bit more of a deep dive. So let's get into what search had. Clustering is so essentially, it's just the grouping of multiple search heads, and the purpose of that is to provide some level of fault, tolerance and high availability.
So what happens when you do
cluster your search heads is essentially they'll become group together and then they'll hold an election among themselves. Using the raft protocol Toh, vote one of them as captain, and then whichever device is deemed, captain will essentially be put in charge
off, making sure any runtime configurations that exists on
the search heads are properly replicated across all the search heads so that each search head has a common set of configurations,
and then you'll also have a deploy er on the side to push out APS or baseline configurations, basically non runtime configurations.
So, uh, and as you could see it in the diagram and I believe we discussed before, these will generally be behind a load balancer. So as far as the users, no, there's just one search head they're connecting to. They don't really know what's going on in the background. And so the nice thing about this is, if one search head were to go down, they would automatically e
directed to one of the remaining search heads by the load balancer.
And so that's how it basically provides that high availability, fault, tolerance, capability. And so now, on the topic of high availability and fault tolerance will talk about what the benefits of searching blistering are. So you have horizontal scaling. Essentially, you can just keep adding more and more search heads to your cluster,
and then they will share the search load.
So, uh, you won't overwhelm the search heads so so easily, then you also have high availability and fault tolerance. Like I mentioned, we already talked about that. So Michael spends much time on it here. But those are the key benefits of using a clustered
search had an environment. So here are the requirements that you'll need in order to actually set up search and clustering, you'll need at least three search heads. The reason for that is
basically the way the raft protocol works is whenever basically when. Whenever there isn't a captain one captain, one device will randomly propose itself is Captain and it needs to receive at least 50%
over 50% of the votes in order for it to be elected captain. So if you only have to, there's no way for the device to earn over 50%
of the votes. And so you need at least three.
And then one key note about those devices is research. It will all have to have it exactly identical specs. So you cannot be mix and matching devices. They should all be
following the same
hardware requirements. And then also, you'll need a dip lawyer set up to push the APS to the search head cluster.
Okay, so that basically covers everything you need to know about searching, clustering for the Splunk administrator at exam. So we've covered what search and clustering is. We now know that it's just basically a way to group your search heads so that all your configurations get duplicated in your search load gets spread out.
We talked about the benefits of search had clustering the primary ones being fault, tolerance, high availability
and also horizontal scaling. And then we talked about the requirements First, search head clustering, which is just that you have at least three search heads with the exact same specs and then a dip lawyer as well.
So that covers everything you need to know about search high clustering and actually covers the rest of modulate, So we'll see you in module nine.