Storage migration tutorial - Consul to integrated storage
This tutorial provides steps to migrate your Vault storage from Consul to Integrated Storage. (NOTE: Integrated Storage requires Vault 1.4 or later.)
Before continuing with this tutorial, be sure to read the Preflight Checklist - Migrating to Integrated Storage first.
Read the upgrade guide to learn if there are any version specific notes related to your current Vault version or any versions between your current version and the intended upgrade version.
Vault storage migration workflow:
Backup Vault data
Before performing the Vault server upgrade, it is recommended to take a snapshot of the Vault data using the Consul Snapshots.
Consul Enterprise users may be using the automated Snapshot Agent to capture snapshot periodically and retained in a specified destination.
Snapshot Vault data
On the Consul server cluster that contains the Vault data to be saved in a snapshot, execute the following command from either a Consul server directly or any system running a Consul client agent connected to the server cluster.
The snapshot file backup.snap
will be present in the current working
directory.
Inspecting the Snapshot
The snapshot file is simply a gzip compressed archive. You can perform some
operational inspection on the snapshot file via the consul snapshot inspect
command and also manually by decompressing the file and examining its contents.
This output shows the snapshot ID, size in bytes, plus the snapshot index, term,
and version, which can be compared with the server (e.g. via consul info
) and
is useful to detect corruption.
Note
Refer to the Datacenter Backups for additional information.
Migrate Vault storage
If you have a multi-datacenter Vault Enterprise Replication deployments, skip to the Vault Enterprise Replication section.
Note
Vault will need to be offline during the migration process.
Perform the migration step on one of the nodes in the cluster which will become the leader node.
To walkthrough the migration steps, assume that the following is your new Vault server configuration.
Notice that the path
is set to /vault/raft/
and node_id
is set to
node_1
. (Refer to the server configuration documentation
for details.)
Note
When using the Raft storage backend, it is strongly recommended to
set disable_mlock
to true
, and to disable memory swapping on the system.
Create a migration configuration file (e.g.
migrate.hcl
).The
storage_source
stanza should be the current storage backend (consul
) configuration, and thestorage_destination
points to the Integrated Storage (raft
) configuration.The
path
andnode_id
must match the values you set in the server configuration file.Note
The
/vault/raft/
path must exist on the host machine. The migration command will not create the folder for you.Execute the
vault operator
command to perform the migration.Refer to the Vault command documentation on operator migrate for more information.
You can start the Vault server using the new server configuration pointing to the
raft
storage and unseal.At this point, there is only one raft cluster member.
Start the remaining Vault nodes in the cluster and add each node to the cluster using the
vault operator raft join
command. Ifretry_join
is configured, there is no need to invoke theraft join
command. The follower nodes should be added to the cluster automatically.While
https://13.57.14.206:8200
is the leader node'sapi_addr
.If you are not familiar with how the HA cluster with Integrated Storage works, read the Vault HA Cluster with Integrated Storage tutorial to familiarize yourself with the Integrated Storage.
Vault Enterprise Replications
If you have multi-datacenter Vault Enterprise Replication deployments such as the diagram below, read the recommendation in this section.
Recommended approach for Vault Enterprise
Stop the DR secondary cluster (Cluster 4 in the diagram above as an example).
Create a new Vault cluster configured with Integrated Storage (Cluster 5 in the diagram below) and add it as a new DR secondary.
As some workload comes through, monitor that the DR secondary cluster is catching up with its primary cluster (Cluster 2) which is still using Consul as the storage backend. If there is no issue, you can stop and terminate the old secondary cluster (Cluster 4) at this point.
Stop the primary cluster (Cluster 2) and promote the DR secondary (Cluster 5) to be the new primary.
If the cluster is a performance secondary, check to make sure that it is syncing up with its performance primary (Cluster 1).
Repeat the step by creating a new cluster configured with Integrated Storage (Cluster 6) and add it as a DR secondary to the new primary (Cluster 5).
Monitor that it syncs up with its primary as some workload comes through. Finally, you can terminate the old primary cluster (Cluster 2).
Repeat the same workflow to migrate the Vault data to Integrated Storage on the performance primary (Cluster 1) and its DR secondary (Cluster 3).
Post-migration health check
Once the storage is migrated, validate that the cluster is healthy and check logs for any unusual errors that are related to the cluster health. Refer to the following guides:
- Troubleshooting Vault - Vault Logs
- If you have Vault Enterprise Replication environment, refer to the Monitoring Vault Replication