#Руководство по миграции данных из MinIO в Rook Ceph RGW

#1. Обзор и архитектура

В этом документе объясняется, как использовать встроенный компонент Rclone в установленном образе оператора Alauda Build of VolSync для миграции всех данных из высокодоступного (HA) развертывания MinIO в Kubernetes в Rook Ceph RGW.

#1.1 Особенности архитектуры

• Безопасное повторное использование образа: данный подход запускает Kubernetes Job, который повторно использует образ оператора build-harbor.alauda.cn/acp/volsync с исправлениями безопасности, переопределяет стандартную точку входа и напрямую вызывает внутренний бинарник Rclone для выполнения стандартной синхронизации объектов на уровне API S3-to-S3.

#1.2 Стратегия синхронизации

Используйте трехфазную стратегию: «Полная -> Инкрементальная -> Переключение»:

1. Начальная синхронизация (Полная синхронизация): поддерживайте сервисы в онлайн-режиме при миграции исторических данных.
2. Инкрементальная синхронизация: поддерживайте сервисы в онлайн-режиме и запускайте несколько раз для догоняющей синхронизации новых или изменённых данных.
3. Переключение (Cutover): остановите записи, выполните строгие проверки согласованности и завершите окончательное переключение.

#2. Требования и подготовка

#2.1 Проверка установки Alauda VolSync и извлечение версии (Критическое требование)

Перед выполнением данного плана убедитесь, что оператор "Alauda Build of VolSync" установлен в namespace volsync-system. Версия образа для Job миграции должна строго совпадать с версией запущенного оператора.

Подробные инструкции по установке Alauda Build of VolSync см. в разделе Configure PVC DR with VolSync.

Как получить версию: Войдите в консоль управления кластером, перейдите в Marketplace / OperatorHub, откройте Installed Operators, найдите оператор VolSync и запишите отображаемую версию (например, v0.8.0 или v0.9.0). Сохраните это значение как <OPERATOR_VERSION> для дальнейшей настройки.

#2.2 Сбор информации о MinIO источнике

• Endpoint: внутренний адрес сервиса MinIO (например: http://minio.tenant-ns.svc:9000).
• Учетные данные: Access Key / Secret Key с правами Read и List для всех бакетов.

#2.3 Создание пользователя Ceph RGW (назначение)

Примените следующий YAML в кластере Rook Ceph для создания выделенного пользователя миграции и предоставления прав на создание бакетов.

apiVersion: ceph.rook.io/v1
kind: CephObjectStoreUser
metadata:
  name: volsync-migration-user
  namespace: rook-ceph
spec:
  store: object-store
  displayName: "VolSync Migration Admin"
  capabilities:
    bucket: "*"

Для минимизации прав оставьте только разрешения на уровне бакетов и не предоставляйте возможность управления пользователями (user).

Извлеките и декодируйте учетные данные Ceph для дальнейшего использования:

# Получить Access Key
kubectl -n rook-ceph get secret rook-ceph-object-user-object-store-volsync-migration-user -o jsonpath='{.data.AccessKey}' | base64 -d
# Получить Secret Key
kubectl -n rook-ceph get secret rook-ceph-object-user-object-store-volsync-migration-user -o jsonpath='{.data.SecretKey}' | base64 -d

#3. Конфигурация развертывания (манифесты)

Рекомендуется развертывать задачи миграции в namespace на стороне назначения (Ceph RGW) или в выделенном namespace для операций.

Создайте namespace, используемый обоими манифестами, перед их применением:

kubectl create ns migration-ops

Рекомендация по месту развертывания (Важно)

Во время миграции Rclone читает данные локально для обработки, а затем загружает их в целевой S3 кластер. Следовательно, сетевое расположение кластера, в котором выполняется задача миграции, напрямую влияет на пропускную способность и время завершения. Рекомендуется развернуть оператор VolSync/Job миграции в кластере MinIO или Ceph, чтобы уменьшить сетевые накладные расходы между кластерами и повысить стабильность передачи.

#3.1 Создание секрета конфигурации Rclone

Запишите учетные данные источника и назначения S3 в Secret. Важно: никогда не добавляйте кавычки вокруг endpoint или значений секретов.

apiVersion: v1
kind: Secret
metadata:
  name: volsync-rclone-config-secret
  namespace: migration-ops
type: Opaque
stringData:
  rclone.conf: |
    [source-minio]
    type = s3
    provider = Minio
    env_auth = false
    access_key_id = MINIO_ACCESS_KEY_HERE
    secret_access_key = MINIO_SECRET_KEY_HERE
    endpoint = MINIO_ENDPOINT_HERE
    no_check_certificate = true

    [dest-ceph]
    type = s3
    provider = Ceph
    env_auth = false
    access_key_id = CEPH_ACCESS_KEY_HERE
    secret_access_key = CEPH_SECRET_KEY_HERE
    endpoint = CEPH_ENDPOINT_HERE
    list_version = 2

#3.2 Определение Job миграции

Разверните Job, который вызывает исправленный образ Alauda VolSync для выполнения синхронизации данных S3.

О remote:bucket[/prefix] vs remote: (Важно)

• Для S3 backend’ов распространённый паттерн Rclone — remote:bucket или remote:bucket/prefix, что является самым явным и безопасным способом определения области.
• В этом документе намеренно используется source-minio: -> dest-ceph:, чтобы поддержать полную миграцию на уровне инстанса (все видимые бакеты со стороны источника).
• Предупреждение о рисках: remote: охватывает более широкую область. Если учетные данные имеют избыточные права, могут быть мигрированы бакеты вне предполагаемой области. Всегда проверяйте в тестовой среде и рассмотрите возможность перехода на явный allowlist с remote:bucket[/prefix] для финального переключения в продакшене.

Обязательно замените <OPERATOR_VERSION> в YAML ниже на фактическую версию, полученную в разделе 2.1.

apiVersion: batch/v1
kind: Job
metadata:
  name: volsync-s3-sync-job
  namespace: migration-ops
spec:
  backoffLimit: 0
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: rclone
          # Используйте исправленный образ volsync от Alauda. Версия должна точно совпадать с OperatorHub.
          image: build-harbor.alauda.cn/acp/volsync:<OPERATOR_VERSION>
          # Примечание: в кластерах ACP ссылка на образ автоматически переписывается
          # на адрес внутреннего реестра после создания Pod
          # (например: registry.alauda.cn:60070/acp/volsync:<OPERATOR_VERSION>).
          # Это ожидаемое поведение.
          # Используйте `kubectl describe pod <pod-name>`, чтобы проверить фактический Image / ImageID.
          imagePullPolicy: IfNotPresent
          # Переопределяем стандартную точку входа и напрямую вызываем rclone внутри образа
          command: ["rclone"]
          args:
            - "sync"
            - "source-minio:"
            - "dest-ceph:"
            - "--progress"
            - "--create-empty-src-dirs"
            - "--ignore-errors"
            # --- Флаги настройки производительности ---
            - "--transfers=32"      # параллельные передачи файлов
            - "--checkers=64"       # параллельные проверки
            - "--s3-chunk-size=64M" # размер чанка для больших объектов, чтобы уменьшить фрагментацию RGW
            - "--fast-list"         # использовать ListObjectsV2 для уменьшения количества API-запросов
            - "--metadata"          # синхронизировать метаданные объектов
          resources:
            requests:
              cpu: "2000m"
              memory: "4Gi"
            limits:
              cpu: "4000m"
              memory: "8Gi"
          env:
            - name: RCLONE_CONFIG
              value: "/config/rclone.conf"
          volumeMounts:
            - name: config-volume
              mountPath: /config
              readOnly: true
      volumes:
        - name: config-volume
          secret:
            secretName: volsync-rclone-config-secret

#4. Порядок выполнения

#Фаза 1: Начальная полная синхронизация

1. Создайте namespace для операций: kubectl create ns migration-ops
2. Примените Secret: kubectl apply -f rclone-secret.yaml
3. Запустите Job: kubectl apply -f rclone-job.yaml
4. Отслеживайте прогресс: kubectl -n migration-ops logs -f job/volsync-s3-sync-job

#Фаза 2: Инкрементальная синхронизация

Для догоняющей синхронизации новых данных, появившихся во время полной синхронизации, повторяйте этот шаг по мере необходимости.

1. Удалите предыдущий Job: kubectl -n migration-ops delete job volsync-s3-sync-job
2. Воссоздайте Job: kubectl apply -f rclone-job.yaml

Примечание по механизму: по умолчанию Rclone сравнивает Size и ModTime для решения о необходимости передачи. Существующие неизменённые файлы пропускаются.

#Фаза 3: Окончательное переключение

1. Остановите записи: прекратите записи в MinIO на уровне приложений или заблокируйте запись через балансировщик нагрузки/Ingress.
2. Строгая проверка синхронизации:

• Удалите текущий Job: kubectl -n migration-ops delete job volsync-s3-sync-job
• Обновите rclone-job.yaml: удалите - "--ignore-errors" для финального запуска, затем добавьте - "--checksum" в args. Это предотвратит маскировку ошибок объектов и отдаст приоритет сравнению Size+Checksum (если доступно) для обнаружения различий.
• Рекомендация по согласованности (Обязательно): не полагайтесь только на количество объектов или ETag. Перед переключением выполните rclone check source-minio: dest-ceph: --download --checksum (или выполните выборочные загрузки критичных объектов и вычислите SHA256), чтобы снизить ложные срабатывания из-за multipart/ETag различий.
• Повторно примените Job: kubectl apply -f rclone-job.yaml

3. Проверьте и переключитесь: после того, как Job завершится со статусом Completed и в логах не будет ошибок, обновите S3 Endpoint и учетные данные приложения на Ceph RGW.

#5. Рекомендации по устранению неполадок и настройке