#MinIO 到 Rook Ceph RGW 数据迁移指南

#1. 概述与架构

本文档说明如何使用已安装的 Alauda Build of VolSync Operator 镜像中内置的 Rclone 组件，将 Kubernetes 中高可用（HA）MinIO 部署的全部数据迁移到 Rook Ceph RGW。

#1.1 架构说明

• 安全镜像复用：此方案会调度一个 Kubernetes Job，复用经过安全补丁加固的 build-harbor.alauda.cn/acp/volsync Operator 镜像，覆盖默认入口点，并直接调用内部的 Rclone 二进制文件，执行标准的 S3-to-S3 API 级对象同步。

#1.2 同步策略

采用三阶段策略：“Full -> Incremental -> Cutover”：

1. 初始同步（Full Sync）：在迁移历史数据的同时保持服务在线。
2. 增量同步（Incremental Sync）：保持服务在线，并多次运行以补齐新增或修改的数据。
3. 切换同步（Cutover Sync）：停止写入，执行严格的一致性检查，并完成最终切换。

#2. 前提条件与准备

#2.1 验证 Alauda VolSync 安装并提取版本（关键前提）

在执行此方案之前，请确保 “Alauda Build of VolSync” Operator 已安装在 volsync-system 命名空间中。迁移 Job 镜像版本必须与当前运行的 Operator 版本严格匹配。

有关 Alauda Build of VolSync 的详细安装说明，请参见 Configure PVC DR with VolSync。

获取版本的方法： 登录集群管理控制台，进入 Marketplace / OperatorHub，打开 Installed Operators，找到 VolSync Operator，并记录显示的版本（例如，v0.8.0 或 v0.9.0）。将该值保存为 <OPERATOR_VERSION>，以便后续配置使用。

#2.2 收集 MinIO 源端信息

• Endpoint：MinIO 内部 Service 地址（例如：http://minio.tenant-ns.svc:9000）。
• Credentials：在所有 bucket 上具有 Read 和 List 权限的 Access Key / Secret Key。

#2.3 创建 Ceph RGW 用户（目标端）

在 Rook Ceph 集群中应用以下 YAML，创建专用的迁移用户并授予 bucket 创建权限。

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: "*"

为了最小权限原则，仅为该迁移账号保留 bucket 级权限，不要授予 user 管理能力。

提取并解码 Ceph 凭据以便后续使用：

# Get Access Key
kubectl -n rook-ceph get secret rook-ceph-object-user-object-store-volsync-migration-user -o jsonpath='{.data.AccessKey}' | base64 -d
# Get Secret Key
kubectl -n rook-ceph get secret rook-ceph-object-user-object-store-volsync-migration-user -o jsonpath='{.data.SecretKey}' | base64 -d

#3. 部署配置（Manifests）

建议将迁移任务部署在目标端命名空间（Ceph RGW）中，或者部署在专用的运维命名空间中。

在应用这两个 manifest 之前，先创建它们共同使用的命名空间：

kubectl create ns migration-ops

部署位置建议（重要）

在迁移过程中，Rclone 会先在本地读取数据进行处理，然后再上传到目标 S3 集群。因此，运行迁移任务的集群网络位置会直接影响带宽和完成时间。建议将 VolSync Operator/迁移 Job 部署在 MinIO 或 Ceph 集群 中，以减少跨集群网络开销并提升传输稳定性。

#3.1 创建 Rclone Config Secret

将源端和目标端的 S3 凭据写入 Secret。重要：不要在 endpoint 或 secret 值周围添加引号。

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] 与 remote:（重要）

• 对于 S3 后端，常见的 Rclone 模式是 remote:bucket 或 remote:bucket/prefix，这也是定义作用范围最清晰、最安全的方式。
• 本文档故意保留 source-minio: -> dest-ceph: 的写法，以支持完整实例级迁移（源端所有可见 bucket）。
• 风险提示：remote: 的作用范围更大。如果凭据权限过高，可能会迁移到目标范围之外的 bucket。请务必先在测试环境中验证，并考虑在生产切换时改为显式的 remote:bucket[/prefix] 白名单模式。

请务必将下面 YAML 中的 <OPERATOR_VERSION> 替换为第 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
          # Use Alauda's patched volsync image. Version must exactly match OperatorHub.
          image: build-harbor.alauda.cn/acp/volsync:<OPERATOR_VERSION>
          # Note: In ACP clusters, this image reference is automatically rewritten
          # to an internal registry address after Pod creation
          # (for example: registry.alauda.cn:60070/acp/volsync:<OPERATOR_VERSION>).
          # This is expected behavior.
          # Use `kubectl describe pod <pod-name>` to check effective Image / ImageID.
          imagePullPolicy: IfNotPresent
          # Override default entrypoint and directly invoke rclone inside the image
          command: ["rclone"]
          args:
            - "sync"
            - "source-minio:"
            - "dest-ceph:"
            - "--progress"
            - "--create-empty-src-dirs"
            - "--ignore-errors"
            # --- Performance tuning flags ---
            - "--transfers=32"      # parallel file transfers
            - "--checkers=64"       # parallel checkers
            - "--s3-chunk-size=64M" # large-object chunk size to reduce RGW fragmentation
            - "--fast-list"         # use ListObjectsV2 to reduce API requests
            - "--metadata"          # synchronize object 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. 创建运维命名空间：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"，然后在 args 中追加 - "--checksum"。这样可以避免掩盖失败的对象，并在差异检测时优先使用 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. 故障排查与调优建议