Flexvolume scenario cloud disk migration scheme

Introduce:

If you have deployed applications on Alibaba Cloud Container Service and use cloud disk data volumes to store data, you may have needs for data migration, data rollback, and disk type configuration changes. This solution provides you with Flexvolume and Disk-Controller running In the cluster, the cloud disk data management solution;
​

Suitable for the following scenarios:

Disk rotation: You have used essd cloud disk before and want to rotate it to ssd disk; or vice versa;
Disk rotation: You have used an encrypted cloud disk before and want to rotate it to an unencrypted disk; or vice versa;
Migration across availability zones: You previously used the disk in availability zone A and want to use it in availability zone B;
Cross-Region Migration: You want to use the cloud disk you used in Hangzhou Region in Beijing Region;
Data rollback: Your disk has taken snapshots regularly, and you want to use a certain version of the snapshot to restore data;

The overall principle of the solution is: to implement data rollback, migration, and allocation operations through cloud disk snapshot technology, and to maintain data consistency.

Disk type conversion scenario:
In the above MySQL instance, the three pods use three ssd cloud disks. We turn the three cloud disks into essd types by rotation, but the data remains consistent. The rotation process includes:

Make multiple cloud disks into snapshots;
Create new pvc and pv through snapshots;
The pvc and pv names must conform to the new StatefulSet naming rules;
​

Step 1: Create a snapshot;
Find the cloud disk ID from the pv information corresponding to the three pods, and go to the ECS console to create cloud disk snapshots respectively;


Suppose the IDs of the three cloud disk snapshots are:

pod-0 -> ssd-mysql-0 -> d-2ze48olpbvnlpofw9wpi -> s-2zeh66llz43m8g65y4um
pod-1 -> ssd-mysql-1 -> d-2ze6sw4nc3n9ovquss0s -> s-2zegk0d8ne75tz0g15zd
pod-2 -> ssd-mysql-2 -> d-2zeddogm2wsjovoch45m -> s-2zec3gco02of30dt6lgb
Step 2: create new pvc;
The old pvc template is as follows:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: ssd-mysql-0
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
storageClassName: alicloud-disk-ssd

Create new pvc:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
annotations:
provider.disksnapshot.aliyuncs.com/disk-snapshot-id: s-2zeh66llz43m8g65y4um
name: essd-mysql-0
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
storageClassName: alicloud-disk-essd
Changes include:
1) Change the name to "essd-mysql-0";
2) Add annotations, and the value is the cloud disk snapshot ID corresponding to pod-0 and pvc-0;
3) Change storageClassName to alicloud-disk-essd;
​

Create pvc:

# kubectl apply -f pvc-0.yaml
essd-mysql-0 Bound d-2ze1nxm8hrcdmktxuocn 20Gi RWO alicloud-disk-essd 18m
​

Similarly, create pvc-1: essd-mysql-1, pvc-2: essd-mysql-2;

essd-mysql-1 Bound d-2zeh66llz43m8tzeminq 20Gi RWO alicloud-disk-essd 2m27s
essd-mysql-2 Bound d-2ze383b6z44xjm79qoj2 20Gi RWO alicloud-disk-essd 2m25s
​

Step 3: Update the app:
Delete the old statefulset and create a new statefulset. The template is as follows:

apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mysql
spec:
serviceName: "mysql"
replicas: 3
selector:
matchLabels:
app:mysql
template:
metadata:
labels:
app:mysql
spec:
containers:
- image: mysql:5.6
name: mysql
command: ["sh", "-c"]
args: ["sleep 10000"]
volumeMounts:
-name: essd
mountPath: /data
volumeClaimTemplates:
- metadata:
name: essd
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "alicloud-disk-ssd"
resources:
requests:
storage: 20Gi
Compared with the old template, two places need to be modified:
1) Change the name in volumeClaimTemplates to essd;
2) Change the name in volumeMounts to essd;

# kubectl describe pod mysql-0 |grep ClaimName
ClaimName: essd-mysql-0
# kubectl describe pod mysql-1 |grep ClaimName
ClaimName: essd-mysql-1
# kubectl describe pod mysql-2 |grep ClaimName
ClaimName: essd-mysql-2

# kubectl exec mysql-0 ls /data
lost+found mysql0

# kubectl exec mysql-1 ls /data
lost+found mysql1

# kubectl exec mysql-2 ls /data
lost+found mysql2
To sum up: the cloud disk of mysql 3 copy has been changed to essd type through snapshot;