Migrating Containerized Application Data from SFS 1.0 to SFS 3.0 or SFS Turbo

• The automatic scale-out capability of dynamic mounting is supported only by StatefulSets.
• SFS Turbo does not support dynamic provision. Therefore, after data of a StatefulSet is migrated from SFS 1.0 to SFS Turbo, the StatefulSet does not support the automatic scale-out capability of dynamic mounting.

1. Choose Workloads in the navigation pane of the cluster console. Switch to the StatefulSets tab page, record the number of pods of the target workload, and reduce the number of pods to 0.
   

   Perform steps 2 to 6 for the PVC used by each pod.

2. Check the PVC mounting mode of the StatefulSet.

   kubectl get statefulset {statefulset-name} -n {namespace} -ojsonpath='{range .items[*]}{.spec.volumeClaimTemplates}{"\n"}{end}'

   • If any command output is displayed, dynamic mounting is used. In this case, go to 3 through 7.
   • If there is no command output, dynamic mounting is not used. In this case, skip these steps and refer to Migrating Data from Statically Mounted Storage.

3. Run the following command to change the persistentVolumeReclaimPolicy value of the PV corresponding to the PVC used by the pod from Delete to Retain:

   kubectl edit pv {pv-name} -n {namespace}

   

   Check the result.

   kubectl get pv {pv-name} -n {namespace} -o yaml |grep persistentVolumeReclaimPolicy

   Example:

    # kubectl get pv pvc-29467e4a-0120-4698-a147-5b75f0ae9a43 -o yaml |grep persistentVolumeReclaimPolicy 
      persistentVolumeReclaimPolicy: Retain 

4. On the Storage page, click the PVs tab. Then, record the PVC name corresponding to the SFS 1.0 PV and delete the PVC. The PV is in the Released state.

   

5. Click Create PersistentVolume in the upper right corner and configure the following parameters:
   • Volume Type: Select SFS Turbo.
   • SFS Turbo: Select the target SFS Turbo volume for data migration.
   • PV Name: Enter a custom name.
   • Access Mode: Select ReadWriteMany.
   • Reclaim Policy: Select Retain.

   

6. Choose Storage in the navigation pane. In the right pane, click the PVCs tab. Click Create PVC in the upper right corner, create a PVC with the same name as that in 4, and bind the PVC to the SFS Turbo volume created in the previous step.

   

7. After the PVCs corresponding to all pods are migrated, expand the number of pods to the original number.

   After confirmation, go to the SFS console to delete the corresponding SFS 1.0 volume and delete the PV corresponding to SFS 1.0 on the CCE console.

• The automatic scale-out capability of dynamic mounting is supported only by StatefulSets.
• After a StatefulSet is migrated from SFS 1.0 to SFS 3.0, it still supports automatic scale-out.

To enable StatefulSets to support dynamic scale-out after the migration, change the StorageClass used by volumeClaimTemplates in StatefulSets from csi-nas to csi-sfs. The volumeClaimTemplates of stateful applications that use dynamic mounting cannot be modified. Therefore, delete the stateful applications and then rebuild them. During the process, ensure that the configurations, including the number of pods, are the same as those before the migration.

1. Choose Workloads in the navigation pane. On the displayed page, locate the target workload, record the number of pods of the workload, and reduce the number of pods to 0.
   

   Perform steps 2 to 6 for the PVC used by each pod.

2. Check the PVC mounting mode of the StatefulSet.

   kubectl get statefulset {statefulset-name} -n {namespace} -ojsonpath='{range .items[*]}{.spec.volumeClaimTemplates}{"\n"}{end}'

   • If any command output is displayed, dynamic mounting is used. In this case, go to 3 through 7.
   • If there is no command output, dynamic mounting is not used. In this case, skip these steps and refer to Migrating Data from Statically Mounted Storage.

3. Run the following command to change the persistentVolumeReclaimPolicy value of the SFS 1.0 PV from Delete to Retain:

   kubectl edit pv {pv-name} -n {namespace}

   

   Check the result.

   kubectl get pv {pv-name} -n {namespace} -o yaml |grep persistentVolumeReclaimPolicy

   Example:

    # kubectl get pv pvc-29467e4a-0120-4698-a147-5b75f0ae9a43 -o yaml |grep persistentVolumeReclaimPolicy 
      persistentVolumeReclaimPolicy: Retain 

4. On the Storage page, click the PVs tab. Then, record the PVC name corresponding to the SFS 1.0 PV and delete the PVC. The PV is in the Released state.

   

5. Click Create PersistentVolume in the upper right corner and configure the following parameters:
   • Volume Type: Select SFS.
   • SFS: Select the SFS 3.0 storage volume after data migration.
   • PV Name: Enter a custom name.
   • Access Mode: Select ReadWriteMany.
   • Reclaim Policy: Set this parameter as required.
     • Delete: The PV will be removed from Kubernetes, and the associated storage assets will also be removed from the external infrastructure.
     • Retain: When the PVC is deleted, the PV will be retained, and the target data volume is marked released.

   

6. Choose Storage in the navigation pane. In the right pane, click the PVCs tab. Click Create PVC in the upper right corner, create a PVC with the same name, and bind the PVC to the SFS 3.0 volume created in the previous step.
   • PVC Type: Select SFS.
   • PVC Name: Change it to the PVC with the same name in step 4.
   • Creation Method: Select Use existing.
   • PV: Select the volume created in the previous step.

   

7. Go to the Workloads page to view the original stateful application. Choose More > Edit YAML, and click Download or copy all content of the YAML file to back up the file locally.
8. Delete the original stateful application and modify the copied YAML configuration as follows:
   • Change the value of storageClassName from csi-nas to csi-sfs.
   • The resourceVersion field and its parameters are deleted because this field cannot be specified during creation.

   

9. Click Create from YAML in the upper right corner, click Import or paste the modified YAML file content, and click OK.
10. After the workload is created, scale-out the number of pods to the original number.

    After confirmation, go to the SFS console to delete the corresponding SFS 1.0 volume and delete the PV corresponding to SFS 1.0 on the CCE console.