Если вы используете файловую систему SFS Turbo как PVC в кластере CCE, возможны следующие варианты миграции, которые зависят от характера переносимых данных:
Типы данных и их использование | Рекомендованное решение |
|---|---|
Мелкие файлы, частая запись (RWX), POSIX-семантика (используются блокировки, переименования, hard links), БД-подобные нагрузки | |
Крупные файлы, read-mostly — статические, медиа-файлы, бэкапы, архивы | |
Единственный потребитель тома (инстанс монтируется единственным клиентом или подом), базы данных, StatefulSet |
Решения можно комбинировать. Например, вы можете перенести часть нагрузок в общий инстанс, а часть — в OBS или EVS.
Проанализируйте, как используется каждый инстанс SFS Turbo, который нужно мигрировать.
По каждому инстансу SFS Turbo соберите следующую информацию в консоли управления Advanced:
ID
Емкость
IP-адрес
VPC/AZ
Проверьте фактическую утилизацию хранилища с любого клиента, где смонтирован инстанс:
df -h | grep -E 'nfs|<sfsturbo_ip>'
Зафиксируйте объем и количество файлов для каждого инстанса:
du -sh /mnt/<sfsturbo>/find /mnt/<sfsturbo>/ -type f | wc -l
Используя информацию, которую вы получили, определите подходящий способ миграции.
Перед миграцией выполните резервное копирование.
Используйте сервис Cloud Backup and Recovery (CBR) на платформе Advanced или выполните копирование вручную с хоста, где смонтирован инстанс SFS Turbo одним из способов:
Утилитой tar локально, например:
tar czf backup-<instance>.tgz -C /mnt/<sfsturbo> .
Утилитой obsutil или rsync в OBS-бакет, например:
obsutil config -i=YOUR_ACCESS_KEY_ID -k=YOUR_SECRET_ACCESS_KEY -e=obs.ru-moscow-1.hc.sbercloud.ruobsutil sync /mnt/<sfsturbo> obs://<your-bucket-name>/backup/
Где:
<access_key> и <secret_key> — ключи доступа AK/SK.
<bucket_name> — название бакета, в который будет помещен бэкап.
-u — будут скопированы только новые и измененные файлы.
В примерах манифестов, которые вы будете использовать далее, используются классы csi-sfsturbo, csi-obs и csi-disk.
Если ваш кластер был создан до перехода на CSI Everest, этих классов может не быть — вместо них устаревшие классы efs-standard, efs-performance, obs-standard, sas, sata, ssd на провижионере flexvolume-huawei.com.
Проверьте классы на провижионере:
kubectl get sc
Проверьте зарегистрированные CSI-драйверы:
kubectl get csidrivers
В ответе ожидаются sfsturbo.csi.everest.io, obs.csi.everest.io, disk.csi.everest.io.
Проверьте статус подов Everest:
kubectl get pods -n kube-system | grep everest
Все поды должны быть в статусе «Ready». Статус «Partially ready» в означает, что часть подов контроллера или DaemonSet не запущена. В этом состоянии биндинг PVC может проходить, но монтирование на соответствующих нодах будет завершаться ошибкой FailedMount.
Перед миграцией необходимо привести поды Everest в статус «Ready».
До начала миграции проверьте доступность квот подкаталогов и параметры классов — они зависят от версии вашего кластера CCE и CSI-аддона.
Для динамического провижининга (subpath, dynamic OBS, dynamic EVS) StorageClass обязателен, иначе PVC зависнет в статусе «Pending» с сообщением о том, что провижионер не ответил.
Для статических PV StorageClass может не существовать: поле storageClassName в этом случае работает только как метка для сопоставления PV и PVC.