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

#1. 概述和架构

本文介绍如何使用已安装的 Alauda Storage Volume Replication Operator 镜像中内置的 Rclone 组件，将 Kubernetes 中高可用（HA）MinIO 部署的所有数据迁移到 Rook Ceph RGW。

#1.1 架构说明

• 安全地复用镜像：此方法会调度一个 Kubernetes Job，复用经过安全修复的 build-harbor.alauda.cn/acp/volsync Operator 镜像，覆盖默认入口点，并直接调用内部 Rclone binary，以执行标准的 S3 到 S3 API 级对象同步。

#1.2 同步策略

采用三阶段策略：“全量 -> 增量 -> 切换”：

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

#2. 前提条件和准备工作

#2.1 验证 Alauda Storage Volume Replication 安装并提取版本（关键前提条件）

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

有关 Alauda Storage Volume Replication 的详细安装说明，请参阅配置 Persistent Volume Claims 的灾难恢复。

获取版本的方法： 登录集群管理控制台，导航至 Marketplace / OperatorHub，打开 Installed Operators，找到 Alauda Storage Volume Replication Operator，并记录显示的版本（例如 v0.8.0 或 v0.9.0）。将此值保存为 <OPERATOR_VERSION>，供后续配置使用。

#2.2 收集 MinIO 源信息

• Endpoint：MinIO 内部 Service 地址（例如：http://minio.tenant-ns.svc:9000）。
• 凭据：在所有 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. 部署配置（Manifest）

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

在应用两个 Manifest 前，先创建它们共用的命名空间：

kubectl create ns migration-ops

部署位置建议（重要）

在迁移期间，Rclone 会在本地读取数据进行处理，然后将其上传到目标 S3 集群。因此，运行迁移任务的集群所在网络位置会直接影响带宽和完成时间。建议将 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 Storage Volume Replication 镜像来执行 S3 数据同步。

关于 remote:bucket[/prefix] 与 remote:（重要）

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

务必将以下 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 operator 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"，然后将 - "--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. 故障排查与调优建议