Troubleshooting

Storage Volumes of the HostPath Type Cannot Be Backed Up

Both HostPath and Local volumes are local storage volumes. However, the Restic tool integrated in Velero cannot back up the PVs of the HostPath type and supports only the Local type. Therefore, you need to replace the storage volumes of the HostPath type with the Local type in the source cluster.

1. Create a storage class for the Local volume. Example YAML:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: local
   provisioner: kubernetes.io/no-provisioner
   volumeBindingMode: WaitForFirstConsumer
   

2. Change the hostPath field to the local field, specify the original local disk path of the host machine, and add the nodeAffinity field. Example YAML:

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: mysql-pv
     labels: 
       app: mysql
   spec:
     accessModes:
     - ReadWriteOnce
     capacity:
       storage: 5Gi
     storageClassName: local     # Storage class created in the previous step
     persistentVolumeReclaimPolicy: Delete
     local:
       path: "/mnt/data"     # Path of the attached local disk
     nodeAffinity:
       required:
         nodeSelectorTerms:
         - matchExpressions:
           - key: kubernetes.io/hostname
             operator: Exists
   

3. Run the following commands to verify the creation result:

   $ kubectl get pv -A
   NAME       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM               STORAGECLASS   REASON   AGE
   mysql-pv   5Gi        RWO            Delete           Available                       local                   3s
   

More usage

• restore từ namespace này qua namespace khác
• thay đổi restore order với --restore-resource-priorities
• thay đổi Storage Classes bằng config map
• thay đổi Image Repositories bằng config map
• thay đổi PVC selected-node (in PVC, can select node for PVC by this annotation volume.kubernetes.io/selected-node: <node-name>).
• when restore service nodeport, nodeport number is delete and auto assign again in new cluster (can use flag --preserve-nodeports=true to keep)
• velero không sửa lại resource nếu đã tồn tại, trừ service account: merge các quyền của nó và thêm các label và annotation (dùng flag --existing-resource-policy=update để đổi)
• incremental backup dựa trên PVCs

Các lỗi có thể xảy ra

• velero server nằm trên node bị lệch time so với s3 server, ko tạo được backup.
• daemonset node-agent bị taint và tolleration chặn trên node, không copy được filesystem được mount vô node, ko backup được volume
• persistent volume đã bị sử dụng, ko claim được nữa
• name volume backup in annotation is pod.spec.volumes, not pvc name
• hostPath volumes are not supported. Local persistent volumes are supported.

Restic and Kopia perfromance and impact

Tham khảo performance do Velero cung cấp: link

helm repo add vmonitor-platform https://vngcloud.github.io/helm-charts-vmonitor

helm install vmonitor-metric-agent vmonitor-platform/vmonitor-metric-agent \
    --set vmonitor.iamClientID=____________________ \
    --set vmonitor.iamClientSecret=____________________ \
    --set vmonitor.clusterName=____________________

Cài node-exporter cho cụm VKS, ta có những thông số (CPU, RAM,...) khi trong cụm đang sử dụng như sau:

Impact của kopia lớn hơn so với restic. Nhưng theo docs của Velero benchmark:

• Với lượng data ít, số file nhiều, kopia tốn CPU hơn, tuy nhiên lưu trữ và thời gian tốt hơn, restic sẽ tốn lượng storage cực lớn.
• Với lượng data tăng dần, kopia tốn CPU và max RAM usage hơn, tuy nhiên lưu trữ và thời gian tốt hơn. Kopia sẽ dễ OOM kill hơn.
• Khi lượng data trong mỗi file lớn (>=1GB), Restic lại ngốn CPU và thời gian lâu hơn, dễ bị timeout hơn, tuy nhiên max memory thấp hơn.

Kết luận:

• Kopia tốn ít thời gian hơn với cùng thông số kĩ thuật
• Trường hợp sao lưu lượng dữ liệu lớn hoặc các tệp nhỏ có dung lượng lớn thì Kopia vẫn tốt hơn
• Nên tính toán resource phân bổ trước để tránh trường hợp timeout hoặc OOM.

Disk IOPS and throughput

Mount 1 persistent volume with config is:...... Use fio to test IOPS and throughput for 2 action read/write when normal and backup. Reference

sudo apt update
sudo apt install -y fio
sudo lsblk

TEST_DIR=/mnt/disks/mnt_dir/fiotest
TEST_DIR=/usr/share/nginx/html/fiotest
sudo mkdir -p $TEST_DIR

Test with 4 scenario:

# write throughput
fio --name=write_throughput --directory=$TEST_DIR --numjobs=400 \
--size=1G --time_based --runtime=2m --ramp_time=2s --ioengine=libaio \
--direct=1 --verify=0 --bs=1M --iodepth=64 --rw=write \
--group_reporting=1 --iodepth_batch_submit=64 \
--iodepth_batch_complete_max=64

# write IOPS
fio --name=write_iops --directory=$TEST_DIR --size=1G \
--time_based --runtime=2m --ramp_time=2s --ioengine=libaio --direct=1 \
--verify=0 --bs=4K --iodepth=256 --rw=randwrite --group_reporting=1  \
--iodepth_batch_submit=256  --iodepth_batch_complete_max=256

# read throughput
fio --name=read_throughput --directory=$TEST_DIR --numjobs=16 \
--size=1G --time_based --runtime=2m --ramp_time=2s --ioengine=libaio \
--direct=1 --verify=0 --bs=1M --iodepth=64 --rw=read \
--group_reporting=1 \
--iodepth_batch_submit=64 --iodepth_batch_complete_max=64

# read IOPS
fio --name=read_iops --directory=$TEST_DIR --size=1G \
--time_based --runtime=2m --ramp_time=2s --ioengine=libaio --direct=1 \
--verify=0 --bs=4K --iodepth=256 --rw=randread --group_reporting=1 \
--iodepth_batch_submit=256  --iodepth_batch_complete_max=256

Incremental backup

kubectl exec -n annd2 -it nginx bash
cd /usr/share/nginx/html
git clone https://github.com/torvalds/linux.git

Chắc chắn các tool về backup thì sẽ luôn có incremental backup. Nhưng khi tích hợp cùng với velero thì cần phải kiểm tra lại hiệu suất tham khảo. Cần đo các thông số (khoảng thời gian, sizes of the backup storage) sau các bước với restic và kopia như sau:

• Đầu tiên, clone source linux, tạo backup
• Checkout to commit 01/01/2022 git checkout -f 60c332029c8da6f4ef791807fcbfbd98e71a5fbd, tạo backup
• Checkout to commit 01/01/2024 git checkout -f 77e01b49e35f24ebd1659096d5fc5c3b75975545, tạo backup
• Checkout to commit 01/01/2023 git checkout -f 5b24ac2dfd3eb3e36f794af3aa7f2828b19035bd, tạo backup
• Checkout to commit 01/01/2013 git checkout -f 1b8d52e63c53fd271846a56b7b1e3f622fd6a0a8, tạo backup

Install wordpress:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm install wordpress bitnami/wordpress \
    --set mariadb.primary.persistence.enabled=true \
    --set mariadb.primary.persistence.storageClass=alicloud-disk-ssd \
    --set mariadb.primary.persistence.size=20Gi \
    --set persistence.enabled=false 

• tinh toan resource cho node agent khi data lon, ~ 400GB
• co the overwrite config and volume hay ko