Deployment Architecture

Decommissioning Old Site, Transitioning to Single Site

Sivrat
Path Finder

I have a multi-site cluster, and am planning on decommissioning one to transform it into a single-site cluster.

Looking over these two guides:
https://docs.splunk.com/Documentation/Splunk/8.0.2/Indexer/Decommissionasite

https://docs.splunk.com/Documentation/Splunk/8.1.2/Indexer/Converttosinglesite

And trying to see how to do both, preferably at the same time.

When converting to a single-site, it states to stop the entire cluster, update the configurations, then start the cluster back up.

Is there any issue with doing the configurations changes necessary for decommissioning the old site while everything is offline, and only bringing up the remaining site?

Basically, current plan is:

  1. Stop all nodes
  2. Update the Manager Configs
    1. Set multi-site to false
    2. Set single site search/rep factors
    3. Remove site attribute
    4. Remove available_sites attribute/site mappings
  3. Update Search Head Configs
    1. Set multi-site to false
    2. Remove site attribute
  4. Start nodes that are remaining from new site

Would this work, or would it cause conflicts in replication somehow? Do I need to use Splunk commands on the cluster manager to remove the old indexers?

0 Karma

trashyroadz
Splunk Employee
Splunk Employee

Quite some time has passed since this question was posted, but a similar question came up today...

Most likely, the processes need to remain separate so the CM can cleanly update journal.gz on all decommissioned site indexers to the site they are moving to, and to allow the CM to meet SF/RF on the remaining site before changing it to a single-site cluster. This assumes you set the remaining site's SF/RF to be identical to what it would be when it becomes single-site.

If this process CAN be combined, I suspect it is possible if site_mappings attribute in CM's server.conf was not removed, but instead updated to <decommissioned_site_id>:<remaining_site_id>.

site_mappings = site2:site1

When the CM comes back up, it will very quickly update journal.gz on all site2 indexers so the buckets are assigned to site1.

Assuming of course the cluster was placed into Maintenance Mode during this process, as doing so will keep the CM from initiating unnecessary fix-up tasks. 

-- now that's Trashy!
0 Karma
Get Updates on the Splunk Community!

New in Observability - Improvements to Custom Metrics SLOs, Log Observer Connect & ...

The latest enhancements to the Splunk observability portfolio deliver improved SLO management accuracy, better ...

Improve Data Pipelines Using Splunk Data Management

  Register Now   This Tech Talk will explore the pipeline management offerings Edge Processor and Ingest ...

3-2-1 Go! How Fast Can You Debug Microservices with Observability Cloud?

Register Join this Tech Talk to learn how unique features like Service Centric Views, Tag Spotlight, and ...