MinIO 到 Rook Ceph RGW 数据迁移指南

1. 概述和架构 1.1 架构说明 1.2 同步策略 2. 前提条件和准备工作 2.1 验证 Alauda VolSync 安装并提取版本（关键前提条件）2.2 收集 MinIO 源信息 2.3 创建 Ceph RGW 用户（目标端）3. 部署配置（清单）3.1 创建 Rclone 配置 Secret 3.2 定义迁移 Job 4. 执行工作流阶段 1：初始全量同步阶段 2：增量同步阶段 3：最终切换 5. 故障排查与调优建议

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 同步策略

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

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

2. 前提条件和准备工作

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

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

有关 Alauda Build of VolSync 的详细安装说明，请参阅使用 VolSync 配置 PVC DR。

获取版本的方法： 登录集群管理控制台，导航到 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）。
凭据：对所有存储桶具有 Read 和 List 权限的 Access Key / Secret Key。

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

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

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 凭据，供后续使用：

# 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. 部署配置（清单）

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

应用清单前，先创建两个清单都会使用的命名空间：

kubectl create ns migration-ops

部署位置建议（重要）

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

3.1 创建 Rclone 配置 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:，以支持完整的实例级迁移（源端所有可见存储桶）。

风险提示：remote: 的作用范围更广。如果凭据权限过大，可能会迁移预期范围之外的存储桶。请务必先在测试环境中验证，并考虑在生产切换时改用显式的 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：初始全量同步

创建运维命名空间：kubectl create ns migration-ops
应用 Secret：kubectl apply -f rclone-secret.yaml
启动 Job：kubectl apply -f rclone-job.yaml
监控进度：kubectl -n migration-ops logs -f job/volsync-s3-sync-job

阶段 2：增量同步

如需追赶全量同步期间生成的新数据，可根据需要重复此步骤。

删除之前的 Job：kubectl -n migration-ops delete job volsync-s3-sync-job
重新创建 Job：kubectl apply -f rclone-job.yaml

机制说明：默认情况下，Rclone 会比较 Size 和 ModTime，以判断是否需要传输。未修改的现有文件会被跳过。

阶段 3：最终切换

停止写入：在应用层停止向 MinIO 写入，或通过负载均衡器/Ingress 阻止写入流量。
严格同步验证：

删除当前 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

验证并切换：Job 达到 Completed 且日志中没有错误后，将应用的 S3 Endpoint 和凭据更新为 Ceph RGW。

5. 故障排查与调优建议

症状	技术诊断	解决方案
ImagePullBackOff	节点无法拉取镜像，或存在版本不匹配。ACP 集群会自动将 `build-harbor.alauda.cn` 重写为内部 registry 地址。	首先运行 `kubectl describe pod <pod-name>`，验证实际生效的 `Image`（是否已重写）和 `ImageID`。然后验证 `<OPERATOR_VERSION>`，并检查实际生效 registry（`imagePullSecrets`）的网络/身份验证。
Pod OOMKilled	在大量小对象场景下，`--fast-list` 会批量加载元数据，消耗大量内存。	将 Pod 内存限制提高到 8Gi+，或移除 `--fast-list`（这会增加 API 请求并减慢遍历速度）。
403 Forbidden	目标 Ceph 用户缺少创建 bucket 的权限。	检查 `CephObjectStoreUser` 配置，并确保 `capabilities` 包含 `bucket: "*"`。
dial tcp: lookup "http: no such host"	Secret 配置格式无效；Endpoint URL 被引号包围。	编辑 Secret，并移除 Endpoint URL 两侧的引号，确保格式严格为：`endpoint = http://...`。
503 Service Unavailable	迁移并发度过高，导致 Ceph RGW 写入压力过大。	降低 Job `args` 中的 `--transfers`，或添加 `--bwlimit` 以限制传输带宽。

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

#目录

#1. 概述和架构

#1.1 架构说明

#1.2 同步策略

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

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

#2.2 收集 MinIO 源信息

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

#3. 部署配置（清单）

#3.1 创建 Rclone 配置 Secret

#3.2 定义迁移 Job

#4. 执行工作流

#阶段 1：初始全量同步

#阶段 2：增量同步

#阶段 3：最终切换

#5. 故障排查与调优建议