SPLK-1002 Splunk Core Certified Power User – Splunk Indexer And Search Head Clustering Part 2

  1. Search Factor And Replication Factor

The core configuration during indexer clustering is determining how many replication factor or search factor best fits your environment. Replication factor and search factor refers to your single site indexer clustering, whereas site replication factor and site research factor refers to your multi site site indexer clustering. So these both represent the same, but depending on the scenario, these both will be taken into effect. The site replication factor and site search factor overrides your replication factor and search factor. When we are doing our lab explaining how the indexer clustering works, how to configure indexer clustering, you’ll be able to be much thorough about replication factor and search factor. For now, remember if replication factor is two, the data copies that exist in a cluster is two.

If a replication factor of a site is two, that means in this site there will be two copies of data and other site will be defined by your configuration to hold one or more than one. So the data copies are defined by your replication factor, whereas the search factor it is usually one in each site because you need only one searchable copy at any site. Even though if you have multiple searchable copies, you still search on only one set of data. Unless it is unavailable, you will be going for another search factor. The search factor refers to searchable data copy that is present in your indexer. Similarly, site search factor refers to the searchable data copies inside a site.

  1. Search Head Clustering Requirement Evaluation

The Search at Clustering the search at Clustering is only configured whenever it is deemed necessary. It is usually advisable to keep dedicated searches for your premium apps like Enterprise Security, pci vmware, splunk App for Exchange, and other pre premium solutions which are sold by splunk. Because these premium apps are resource intensive which consumes most of your splunk searched resources, it’s better to dedicate these premium apps on a single searched these premium apps. Most of them also support searched clustering. If you can afford another instance of splunk searched, you can cluster this searched in order to function these premium maps at an optimum level. Usually searched clustering is quite difficult to manage and upgrading these searches’during, a version upgrade or a patch release will be a challenge. You.

  1. Heavy Forwarder Clustering

Clustering. The ev forwarder clustering is made to ensure that any udp packets that are sent by assist log are not dropped. In any cases of crashing of av forwarders, the udp packets will be lost in case there is no evolveder clustering. In 99% of the cases it is not implemented because usually the packets that are sent are via tcp, Syslog or splunk forwarders. The splunk forwarders, if the ev forwarder or the indexer is not available, it can buffer these packets so that once this indexer or ev forwarder comes back online, it starts sending from where it stopped the logs before it indexer crashed, whereas even he told Scott for Syslog tcp.

But for Syslog udp, whenever an indexer or a av forward are listening on a specific port, if it crashes, the udp logs are lost. And also for large networks where there is too much noise that are received as part of Syslog. For the index, it is recommended to use a process called syslog ng, that is your Syslog receiver so that it receives and writes to a local file and a splunk instance will pick it up from the local return files. So this av forwardive clustering is commonly achieved by a shared IP address or OS cluster that at any moment of time, if one IP goes down, another can act as active passive. Similarly the OS level, if one instance goes down, the other device can act as active node and start receiving these locks.

  1. Handson Indexer Clustering : part 01

As of now, we have four splunk instances running. That is one search at indexer one and indexer two which would be used for our single site cluster and multisite clustering. And deployment server or license manager will be acting as our cluster master. Here we have indexer one and indexer two. Let me log into indexer one. Now I have logged in as application user splunk. Let me check if my splunk instance is running. Yes, it is running. So log into my second indexer which will be part of my cluster, verify whether the splunk is running. Yes, it is running. This is our cluster master. So we have all three instances up and running. Let me log into cluster master so that I will give you an overview how it looks before configuring cluster.

As part of this tutorial, we’ll be building much bigger architecture. That is we will have two main site indexes two, site two, that is Dr indexers two searches on both the sites. That is total of four indexes four searches and two av four orders in our multi site high availability splunk enterprise environment that we are going to build on our Amazon aws cloud. Once we are clear on understanding splunk, we will see how easy it is to build a splunk environment within a matter of day. So this is our deployment server. In deployment server, click on Settings and you’ll be able to see indexer cluster. As you can see, the indexer cluster is not enabled. As of now, we can enable the indexer cluster by clicking on enable indexer Cluster. This is our deployment server.

As you can see, we have dedicated this machine as our cluster master, so we’ll make it Master Node so here replication copies. I’ll keep it as two because we have two indexes so that the data replicated copies, the number of searchable copies of data the cluster maintains. Let it be two. And if you’d like to give some password for your cluster, you can give it, but it is an optional value. So for demonstration, I’m not keeping any password, but it is highly recommended in production environment. Give it a name. So I’ll label this as single site cluster enable master node so Once you have filled out and submitted this information, it requires a restart so that it will add all the clustering features to this splunk instance. We will see how this gui changes once the cluster has been enabled.

  1. Handson Indexer Clustering : part 02

The restart has completed, let us log in and view our indexer clustering page. As of now, we have just configured that is our master node cluster master which is reported itself as a search engine. So always your cluster master will report code to itself as a search engine. We don’t have any indexers added now. Once we add indexers, we’ll be able to see another tab where it shows the indexers. Now, let us log into one of our indexer. This is our indexer number two.

This indexes will be the slave nodes of your master node. That is, this indexer will manage all the replication among the other indexes which are its members. To configure this indexer as a Slave, go to settings. Follow the similar procedures as you did previously for Master node, but this time it will be a Slave node. Click on peer node. Next here you need to enter your master URL that is with management port 80 89 replication port by default it is 80 80. If you would like to customize, you can customize for our demonstration, we’ll keep 90 80 and as you can remember, while creating the master node, we didn’t provide any password. So I’ll leave this password blank.

We need to restart this instance to make the configuration changes take effect. So once we restart, there will be entry created in server conf file. We’ll see. Once we have set up our complete indexer single site cluster, we’ll be able to see all this configuration one by one and I will explain to you how in the back end the server conf is structured in order to reflect our indexer clustering configuration. Restart is successful. Once we have logged in, you’ll be able to see this ui will be frozen. You can’t see or modify anything here.

As you can see, Slave is unable to handle request at this time. Yes, it says the replication peers added to this cluster does not have any information because we don’t have our one more instance that has not been reported. As you can see, we have our one indexes which has already been part of our cluster. We’ll go ahead and add one more Slave so that this error will be cleared always while choosing a replication factor.

Keep in mind the replication factor should always be either minimum number of indexes or more than that. So it should not be less than your minimum number of indexes. So in our case, we have replication factor of two. But as of now, we have configured only one indexer. So it is saying the replication factor does not meet the requirements. Let us go ahead and add our second index.

 

img