Migrating Containerized Application Data from SFS 1.0 to SFS 3.0 or SFS Turbo
Scalable File Service (SFS) provides the following types of file systems: SFS Capacity-Oriented, SFS 3.0, and SFS Turbo. For details, see File System Types.
In earlier versions, CCE supports mounting SFS 1.0 to workloads. You are advised to migrate workloads to SFS 3.0 or SFS Turbo.
You can select a proper storage mounting mode according to your workload types. Dynamic mounting and static mounting are distinguished by mounting storage volumes to workloads.
- Dynamic mounting applies to only StatefulSets. This function is implemented using the volumeClaimTemplates field and depends on dynamic creation of PVs through StorageClass. A StatefulSet associates each pod with a PVC using the volumeClaimTemplates field, and the PVC is bound to the corresponding PV. Therefore, after the pod is rescheduled, the original data can still be mounted based on the PVC name.
- Static mounting applies to all types of workloads. This function is implemented using the volumes field.
To migrate containerized applications from SFS 1.0 to SFS 3.0 or SFS Turbo, the procedure is the same. However, the only difference is that SFS Turbo does not allow dynamic creation, which affect StatefulSets that rely on it.
Notes and Constraints
- You need to migrate data from SFS 1.0 to SFS 3.0 or SFS Turbo beforehand. For details, see Migrating Data from SFS Capacity-Oriented to Another Type of File Systems. If necessary, contact SFS customer service.
- The SFS file system and the cluster must be in the same VPC.
- Before using SFS 3.0 for storage, ensure a VPC endpoint has been created in the VPC where the cluster is located for the cluster to access the SFS 3.0 file system. For details, see Configure a VPC Endpoint.
Migrating Storage Data Through Static Mounting
Static mounting applies to all types of workloads. This function is implemented using the volumes field. The procedure for migrating storage data using this mounting method from SFS 1.0 to SFS 3.0 or SFS Turbo is the same. This section uses SFS Turbo as an example.
- Access the cluster console and choose Storage in the navigation pane. In the right pane, click the PVs tab. Then, click Create PersistentVolume in the upper right corner.
Set 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.
- After the PV is created, switch to the PVCs and click Create PVC in the upper right corner.
Set the following parameters.
- PVC Type: Select SFS Turbo.
- PVC Name: Enter a custom name, which must be different from the original SFS 1.0 PVC name.
- Creation Method: Select Use existing.
- PV: Select the volume created in the previous step.
After the PVC is created, the following figure is displayed.
- Choose Workloads in the navigation pane. On the displayed page, locate the target workload and reduce the number of pods to 0.
- Click Upgrade in the Operation column of the workload. In Container Settings, switch to the Data Storage tab page, click Add Volume, and select PVC from the drop-down list. In the displayed PVC area, select the PVC created in step 2 to replace the PVC used by the workload.
After the migration, ensure that the mount path and subpath in the container are the same as those when SFS 1.0 is mounted.
- After the migration, you can increase the number of pods.
Check that the new volume works properly, and clear the SFS 1.0 storage volume on CCE.
Migrating StatefulSet Data to SFS Turbo Through Dynamic Mounting
- 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.
- Choose Workloads in the navigation pane. Switch to the StatefulSets tab page, record the number of pods of the target workload, and reduce the number of pods to 0.
- Click the workload name. Choose Containers > Data Storage and view the PVC mode used by the stateful application.
- For dynamic mounting, perform 3 to 7.
- If dynamic mounting is not used, skip these steps. For details, see Migrating Storage Data Through Static Mounting.
- Run the following command to change the value of persistentVolumeReclaimPolicy of the PV corresponding to the SFS 1.0 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
- Record the PVC name corresponding to the SFS 1.0 PV and delete the PVC. The PV is in the Released status.
- Choose Storage in the navigation pane. In the right pane, click the PVs tab. Then, click Create PersistentVolume in the upper right corner.
Set 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.
- 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.
- 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.
Migrating StatefulSet Data to SFS 3.0 Through Dynamic Mounting
- 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.
- 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.
- Click the workload name. Choose Containers > Data Storage and view the PVC mode used by the stateful application.
- For dynamic mounting, perform 3 to 7.
- If dynamic mounting is not used, skip these steps. For details, see Migrating Storage Data Through Static Mounting.
- Run the following command to change the value of persistentVolumeReclaimPolicy 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
- Record the PVC name corresponding to the SFS 1.0 PV and delete the PVC. The PV is in the Released status.
- Choose Storage in the navigation pane. In the right pane, click the PVs tab. Then, click Create PersistentVolume in the upper right corner.
Set 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.
- 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.
- 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.
- 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.
- Click Create from YAML in the upper right corner, click Import or paste the modified YAML file content, and click OK.
- 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.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot