This architecture can be considered as a scaled up version of the larger deployment, which we saw in
the previous tutorial.
This will be one of the craziest of involving like high availability and clustering of Splunk into your
design.
Since we have already gone through these scenarios of having high availability and clustering options
I'm using by now.
You should be aware of the benefits of having high availability and clustering option in your organization.
Let's see the architecture now.
Looking in Chile.
It looks like a total chaos in the architecture and a lot of components, but.
As a Splunk architect, you'll be able to see the beauty of Splunk flexibility and scaling up and its
design.
If you look carefully, there are two sides that is side one and side two.
These are two sites in real scenarios.
It will be like main data center and this could be your data or disaster recovery center.
For our understanding, let us call them site one and site to the site one component.
Looks identical to the large enterprise architecture which we have seen in our previous example.
This is our site one architecture.
If you just see in our previous.
A discussion.
We went through the large enterprise architecture which is identical to our site one.
It is clear that for high availability and cluster we are considering only the large scale enterprise.
So the site one is our main data centre where all the logs are collected using universal forwarders,
sis logs and then pass it by our AV forwarders.
Push push to the indexer for storage and retrieving.
The searchers do their fancy stuff of fetching the data from indexers and visualizing reporting or alerting.
The same applies to the D.R. or our site too, which is identical to our main site.
But from this diagram, we can see that some of the components like the deployment server and the license
manager are communicating to both side.
Having a deployment server talk to all the components will have a huge advantage of managing.
The configuration at one place.
It talks to all the components like circuits, indexer, every forwarder and the data sources.
Similarly, we know from our previous modules that license manager talks to all the indexers.
That at present inside one side too, or in any other side of your architecture to keep track of the
license utilization, since it has very limited functionality, we can make it as a cluster master.
Also, we can use the license server itself to function alongside us Cluster Master, which takes care
of making sure that the data has been copied or replicated to the other sites and vice versa.
The function of cluster muster can be clubbed with deployment, server or license manager, although
it is not recommended by Splunk.
It doesn't have much of an impact on the performance.
Since License Manager, which has very limited functionalities, it can be made as Cluster Master to.
And it is also the duty of cluster manager.
To make sure the replication and the search factors are met in between the cluster or the cluster members
and make sure the cluster is stable.
The health of the cluster can also be monitored from the cluster master.
To conclude, let us go through some scenarios when the multi-site clustering will be adding value.
Let's say one of the indexers in my main suit goes down.
So what happens?
There is still data between two indexes.
It should be more than enough if you have configured the replication factor of two.
We'll come to this replication factor and search factors and how they influence the cluster and the
storage and the high availability part.
Let's say we have two copies of data here, so if one indexer goes down, there is very good chance
that these two indexes can give you the results without any impact.
Let's say one of the searchers goes down as a second scenario where when the search goes down, if it
is a highly critical one and it is clustered into the searcher.
We can access our DVR searchers and continue with their dashboard reports or alerting whatever it was
it should operate without any issues.
Similarly, if it is a dedicated searcher like it handles a premium app which is configured only on
one searcher and it is not been clustered.
The impact will be the alerts or the schedule searches which are configured on this search.
It will not be running anymore if it has been clustered into our DVR or the site to the scheduled searches
and the alerts will be run by our search it and then side to.
The third scenario, let us consider there are two indexes going down.
In that case, our search will be impacted.
We will not be getting 100% of the results from the main indexes.
But if we make the same searches point to these indexes, it will be able to retrieve 100% of data.
Even though these two indexes are down.
So at any given point of time, either these three indexes or these three indexes should be able to
serve you with 100% of the results.
And the fourth scenario the deployment server goes to consider, the deployment server goes down, which
doesn't have a slave in this architecture or like it doesn't have a fellow but the deployment server.
There is a reason why it stands out from the regular architecture.
If you see it stands somewhere in the middle just communicating to all the servers.
But if you see if the deployment server goes down, there is no functional impact for.
Splunk architecture because it just makes sure that all the instances are up and you'll be able to modify
configuration, restart them and make sure the new configurations are deployed.
These kind of scenarios.
Whereas even if it goes down, the search, index, search and heavy folders will have a local copy
of their configuration.
And it will be able to operate without any issues in case of deployment.
So we're going to probably let's say you're not able to bring up the server, make sure to restore the
backup into new VM and you'll be able to assign the same IP and deployment should a server should be
up within a matter of no time.
By understanding all this architecture and the benefits, you should now be able to design one of the
best fit architecture for your organisation.