Migration from Legacy Storage to Latest Storage Solution
This section describes the process of migrating the legacy storage to latest storage solution.
#
OverviewData migration is the process of moving data from a source storage to a destination storage. In OpenEBS context, the users can migrate the data from legacy OpenEBS storage to the latest OpenEBS storage.
There are different techniques/methodologies for performing data migration. Users can perform data migration within the same Kubernetes cluster or across Kubernetes clusters. The following guides outline several methodologies for migrating from legacy OpenEBS storage to latest OpenEBS storage:
info
Users of non-OpenEBS storage solutions can also use these approaches described below to migrate their data to OpenEBS storage.
#
Migration using pv-migrateIn this migration process, we are using pv-migrate that is a CLI tool/kubectl plugin to easily migrate the contents of one Kubernetes PersistentVolumeClaim
to another.
This tool is binary and can be downloaded from the release section for linux/amd64. For other OS and arch, download the respective binary from the latest release section.
- Once downloaded, untar the binary as below:
- Add the binary to
PATH
or move it to/usr/local/bin
to use the binary like any usual binary.
The binary can be used as specified in the migrate flows.
#
Migration from Local PV Device to Local PV LVMinfo
The following example describes the steps to migrate data from legacy OpenEBS Local PV Device storage to OpenEBS Local PV LVM storage. Legacy OpenEBS Local PV ZFS storage users can also use the below steps to migrate to OpenEBS Local PV LVM storage.
#
Assumptions- Local PV Device is already deployed.
- MongoDB Standalone is deployed as below using the Local PV Device PVC. (Here, MongoDB Standalone is an example.)
- For validation, some data has been inserted in the MongoDB as an example below:
#
Steps to migrate Local PV Device to Local PV LVMFollow the steps below to migrate OpenEBS Local PV Device to OpenEBS Local PV LVM.
Install Local Storage on your cluster.
Create a LVM PVC of the same configuration.
info
For the LVM volume to be created, the node (where the application was deployed) needs to be same as that of where Volume Group (VG) is created.
See the example below:
- Scale down the MongoDB pod.
note
In your case, scale down or delete the concerned application pod.
- Start the migration and let it complete.
info
Use the correct Local PV Device PVC name that your application has.
See the example below:
Deploy the MongoDB application using the LVM PVC.
Once the MongoDB pod is created, check the data that was persisted previously.
The migration is successful.
The Local PV Device volumes and pools can now be removed and Local PV Device can be uninstalled.
#
Migration from cStor to Replicatedinfo
The following example describes the steps to migrate data from legacy OpenEBS CStor storage to OpenEBS Replicated Storage (a.k.a Replicated Engine or Mayastor). Legacy OpenEBS Jiva storage users can also use the below steps to migrate to OpenEBS Replicated.
#
Assumptions- cStor is already deployed.
- MongoDB Standalone is deployed as below using the cStor PVC. (Here, MongoDB Standalone is an example.)
- For validation, some data has been inserted in the MongoDB as an example below:
#
Steps to migrate cStor to ReplicatedFollow the steps below to migrate OpenEBS cStor to OpenEBS Replicated (a.k.a Replicated Engine or Mayastor).
Install Replicated Storage on your cluster.
Create a replicated PVC of the same configuration. See the example below:
- Scale down the MongoDB pod.
note
In your case, scale down or delete the concerned application pod.
- Start the migration and let it complete.
info
Use the correct cStor PVC name that your application has.
See the example below:
Deploy the MongoDB application using the Replicated PVC.
Once the MongoDB pod is created, check the data that was persisted previously.
The migration is successful.
The cStor volume and pools can now be removed and cStor can be uninstalled.