Splunk® Enterprise

Distributed Search

Download manual as PDF

This documentation does not apply to the most recent version of Splunk. Click here for the latest version.
Download topic as PDF

Migrate from a search head pool to a search head cluster

You can migrate the settings from a search head pool to a search head cluster. You cannot migrate the search head instances themselves, however. You must use new instances when enabling search head cluster members.

To migrate the settings from a search head pool to the search head cluster, you copy the shared directories in the search head pool to the deployer instance. You then use the deployer instance to propagate those directories to the cluster members.

The migration procedure varies somewhat depending on whether you are migrating to a new cluster or to a cluster that is already running.

Important points to consider

There are a few points to keep in mind when migrating your settings from a search head pool to a search head cluster.

Do not migrate default apps

When you migrate apps to the search head cluster, do not migrate any default apps, that is, apps that ship with Splunk Enterprise, such as the search app. If you push default apps to cluster members, you overwrite the version of those apps residing on the members, and you do not want to do this.

You can, however, migrate custom settings from a default app:

  • You can migrate any private objects associated with the default apps. Private objects are located under the etc/users directory, not under etc/apps.
  • You can migrate custom settings in the app itself by moving them to a new app and exporting them globally. The migration procedures in this topic each include a step for this.

Migrated settings get placed in default directories

The deployer puts all migrated settings into default directories on the cluster members. This includes any runtime changes that were made while the apps were running on the search head pool.

Because users cannot change settings in default directories, this means that users cannot perform certain runtime operations on migrated entities:

  • Delete. Users cannot delete any migrated entities.
  • Move. Users cannot move these settings from one app to another.
  • Change sharing level. Users cannot change sharing levels. For example, a user cannot change sharing from private to app-level.

Users can override existing attributes by editing entities in place. Runtime changes get put in the local directories on the cluster members. Local directories override default directories, so the changes override the default settings.

For more information on where deployed settings reside on the cluster members, see See "Location on the cluster members."

Note: Splunk does not support migration of per-user search history files.

Migrate to a new search head cluster

To migrate settings from a search head pool to a new search head cluster:

1. Follow the procedure for deploying any new search head cluster. Specify the deployer location at the time that you initialize the cluster members. See "Deploy a search head cluster."

Caution: You must deploy new instances. You cannot reuse existing search heads.

2. Copy the etc/apps and etc/users directories on the shared storage location in the search head pool to the distribution directory on the deployer instance. The distribution directory is located at $SPLUNK_HOME/etc/shcluster.

For details on the distribution directory file structure, see "What the configuration bundle contains."

3. If you want to migrate custom settings from a default app, you can move them to a new app and export them globally. For example, to migrate settings from the search app :

a. Copy the .../search/local directory in the distribution directory to a new app directory, such as search_migration_app, in the temporary directory. Do not name this new app "search."
b. Export the settings globally to make them available to all apps, including the search app. To do this, create a .../search_migration_app/metadata/local.meta file and populate it with the following content:
   []
   export=system
See the default.meta specification file for details.

4. If $SPLUNK_HOME/etc/shcluster/apps contains any default apps, such as the search app, you must delete them now. Do not push them to the cluster members. If you do, they will overwrite the versions of those apps already on the members.

5. Use the deployer to push the configuration bundle to the cluster members. See "Push the configuration bundle."

Note: If you point the cluster members at the same set of search peers previously used by the search head pool, the cluster will need to rebuild any report acceleration summaries or data model summaries resident on the search peers. It does this automatically. It does not, however, automatically remove the old set of summaries.

Migrate to an existing search head cluster

To migrate settings from a search head pool to an existing search head cluster:

1. Copy the /etc/apps and /etc/users directories on the shared storage location in the search head pool to a temporary directory where you can edit them.

2. If you want to migrate custom settings from a default app, you can move them to a new app and export them globally. For example, to migrate settings from the search app :

a. Copy the .../search/local directory in the temporary directory to a new app directory, such as search_migration_app, in the temporary directory. Do not name this new app "search."
b. Export the settings globally to make them available to all apps, including the search app. To do this, create a .../search_migration_app/metadata/local.meta file and populate it with the following content:
   []
   export=system
See the default.meta specification file for details.

3. In the temporary directory, delete these subdirctories:

  • Any default apps, such as the search app. Do not push default apps to the cluster members. If you do, they will overwrite the versions of those apps already on the members.
  • Any apps already existing in the deployer's distribution directory. Otherwise, the versions from the search head pool will overwrite the versions already on the members.

4. Copy the remaining subdirectories from the temporary location to the distribution directory on the deployer, located at $SPLUNK_HOME/etc/shcluster. Leave any subdirectories already in the distribution directory unchanged.

For details on the distribution directory file structure, see "What the configuration bundle contains."

5. Use the deployer to push the configuration bundle, including the migrated settings, to the cluster members. See "Push the configuration bundle."

Note: If you point the cluster members at the same set of search peers previously used by the search head pool, the cluster will need to rebuild any report acceleration summaries or data model summaries resident on the search peers. It does this automatically. It does not, however, automatically remove the old set of summaries.

Search head clustering and mounted bundles

For most types of deployments, including search head clustering, Splunk recommends that you use normal bundle replication, rather than mounted bundles with shared storage.

As a result of changes to bundle replication made in the 5.0 timeframe, such as the introduction of delta-based replication and improvements in streaming, the practical use case for mounted bundles is now extremely limited. In most cases, mounted bundles make little difference in the amount of network traffic or the speed at which bundle changes get distributed to the search peers. At the same time, they add significant management complexity, particularly when combined with shared storage. Because of delta-based replication, even if your configurations contain large files, normal bundle replication entails little ongoing replication cost, as long as those files rarely change.

PREVIOUS
Migrate from a standalone search head to a search head cluster
  NEXT
Upgrade a search head cluster

This documentation applies to the following versions of Splunk® Enterprise: 6.2.4, 6.2.5, 6.2.6


Was this documentation topic helpful?

Enter your email address, and someone from the documentation team will respond to you:

Please provide your comments here. Ask a question or make a suggestion.

You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters