使用 Squid 中的 RBD 实时迁移在集群间无缝移动数据

2025 年 2 月 7 日 Sunil Angadi, Anthony D'Atri, Ila Dryomov (IBM)

使用 Squid 中的 RBD 实时迁移在集群间无缝移动数据 ¶

块存储简介 ¶

一个块是小而固定大小的数据片段，例如 512 字节的块。想象一下将一本书分解成许多页：每一页都是一个“块”。将所有页面组合在一起，就像组合许多较小的数据块创建更大的存储单元一样。

我们在哪里使用块？ ¶

基于块的存储通常用于计算中，以及包括以下设备中

硬盘或 SSD（您计算机的存储）
CD/DVD（用于音乐或电影的盘片）
软盘（较旧的存储设备）
磁带驱动器（用于大数据备份系统）

什么是 Ceph RADOS 块设备 (RBD)？ ¶

Ceph RADOS 块设备是由 Ceph 集群提供的存储类型，它就像一个虚拟物理存储驱动器。它不是将数据存储在单个设备上，而是将其跨多个存储节点和设备（称为 OSD）在 Ceph 集群中传播。这使其高效、可扩展且可靠。

Ceph 块设备有什么特别之处？ ¶

Ceph 块设备具有一些惊人的功能

快照 – 就像在某个时间点拍摄数据的照片，以便以后可以恢复或回滚到它。
复制 – 您的数据会被多次复制以防止丢失。
数据一致性 – 确保您的数据准确且安全。

Ceph 块设备如何工作？ ¶

客户端使用 librbd 库与 Ceph 集群的组件通信并有效地管理数据。

谁使用 Ceph 块设备？ ¶

云平台，如 OpenStack、Proxmox、AWS EBS 和 IBM Cloud 依赖于它们。
虚拟机 (KVM/QEMU) 使用它们来实现快速且可扩展的存储。
它们甚至可以与 Ceph 的对象存储一起工作，以提供灵活的存储解决方案。

简而言之，Ceph 块设备为现代计算需求提供快速、可扩展且可靠的存储，确保数据始终可用、准确且安全。

Ceph RBD 镜像的实时迁移 ¶

作为存储管理员，您有能力在 Ceph 集群内或在不同的 Ceph 集群之间无缝移动 (实时迁移) RBD 镜像。这就像在计算机上将文件从一个文件夹移动到另一个文件夹，但这种情况发生在大型分布式存储集群内或之间。

请注意，RBD 镜像也称为卷，这个术语不太可能与包含 Taylor Swift 或猫的图像的文件混淆。

主要功能 ¶

在 Ceph 集群内的池或 RBD 命名空间之间迁移
在 Ceph 集群之间的池和 RBD 命名空间之间迁移
支持多种镜像格式 (Native, QCOW, RAW)
实时迁移加密镜像
与外部数据源集成，包括 HTTP、S3 和 NBD
在迁移过程中保留快照历史和稀疏性

注意：Linux KRBD 内核客户端目前不支持实时迁移。

您可以迁移什么？ ¶

在不同的存储池之间（例如，从高性能复制的 TLC SSD 池迁移到具有成本效益的编码的 QLC 或 HDD 池）。
在同一个池内（例如，为了更好的管理或实现压缩而重新组织数据）。
跨不同的格式或布局（例如，从旧的存储格式升级到较新的格式）。
从外部数据源（例如，从非 Ceph 存储系统迁移到 Ceph）。

实时迁移：仅导入模式 ¶

想要从外部源或存储提供商迁移数据？没问题！您可以

从备份文件导入数据
从 Web URL（HTTP/HTTPS 文件）提取数据
从 S3 存储桶移动数据
连接到 NBD（网络块设备）导出

实时迁移是如何工作的？ ¶

当您启动实时迁移时，幕后会发生以下情况

深度复制 – 系统复制整个镜像，同时保留所有历史快照。
稀疏数据优化 – 仅复制实际使用的的数据，从而节省存储空间并加快过程。
无缝过渡 – 迁移发生时，镜像仍然可用，从而最大限度地减少停机时间。
源变为只读 – 原始镜像被锁定，因此不会进行任何新的更改。
自动 I/O 重定向 – 所有应用程序和用户会自动开始使用新的镜像，而不会中断。

为什么这很重要？ ¶

保持数据灵活性 – 根据性能、成本或组织需求移动存储。
确保数据完整性 – 快照历史和结构保持不变。
实时工作 – 迁移发生在不中断工作负载的情况下。

逐步指南：实时迁移 Ceph RBD 镜像 ¶

Ceph 中的 RBD 镜像实时迁移允许您在池、RBD 命名空间和不同集群中无缝移动存储，格式不同，停机时间最少。让我们将其分解为三个简单的步骤，以及执行它们所需的命令。

步骤 1：准备迁移 ¶

在开始迁移之前，会创建一个新的目标镜像并链接到源镜像。

如果未启用仅导入模式，则源镜像将被标记为只读以防止修改。
尝试读取新目标镜像的未初始化部分将重定向读取操作到源镜像。
如果将数据写入目标镜像的未初始化部分，Ceph 会自动深度复制来自源镜像的相应块。

语法

rbd migration prepare SOURCE_POOL_NAME/SOURCE_IMAGE_NAME TARGET_POOL_NAME/TARGET_IMAGE_NAME

示例

rbd migration prepare source_pool1/source_image1 target_pool1/target_image1

通过运行 rbd migration prepare 命令，并使用 --import-only 标志和 --source-spec 或 --source-spec-path 选项，启动仅导入的实时迁移过程，传递一个描述如何访问源镜像数据的 JSON 文件。

创建一个 JSON 文件

[ceph: root@rbd-client /]# cat testspec.json
 {
   "type": "raw",
    "stream": {
        "type": "s3",
        "url": "https:hots_ip:80/testbucket1/image.raw",
        "access_key": "Access key",
        "secret_key": "Secret Key"}
}

准备仅导入的实时迁移过程

语法

rbd migration prepare --import-only --source-spec-path "JSON_FILE" TARGET_POOL_NAME/TARGET_IMAGE_NAME

示例

[ceph: root@rbd-client /]# rbd migration prepare --import-only --source-spec-path "testspec.json" target_pool/traget_image

使用 rbd status 命令检查迁移状态

[ceph: root@rbd-client /]# rbd status target_pool/target_image
Watchers: none
Migration:
source: {"stream":{"access_key":"RLJOCP6345BGB38YQXI5","secret_key":"oahWRB2ote2rnLy4dojYjDrsvaBADriDDgtSfk6o","type":"s3","url":"http://10.74.253.18:80/testbucket1/image.raw"},"type":"raw"}
destination: targetpool1/sourceimage1 (b13865345e66)
state: prepared

步骤 2：执行迁移 ¶

准备完成后，Ceph 开始将所有现有数据从源镜像深度复制到目标镜像。

迁移在后台运行；应用程序可以立即使用新的目标镜像。
任何新的写入操作都仅存储在目标镜像上，从而确保无缝过渡。

语法

rbd migration execute TARGET_POOL_NAME/TARGET_IMAGE_NAME

示例

rbd migration execute target_pool1/target_image1

步骤 3：完成迁移 ¶

数据完全传输后，提交或中止迁移。

选项 1：提交迁移 ¶

提交迁移会删除源镜像和目标镜像之间的所有链接。

如果未使用仅导入模式，则会自动删除源镜像。
目标镜像变得完全独立。

语法

rbd migration commit TARGET_POOL_NAME/TARGET_IMAGE_NAME

示例

rbd migration commit target_pool1/target_image1

选项 2：中止迁移 ¶

可以取消迁移。取消迁移将导致以下情况发生

删除镜像之间的任何交叉链接。
删除目标镜像，将源镜像恢复到其先前状态。

语法

rbd migration abort TARGET_POOL_NAME/TARGET_IMAGE_NAME

示例

rbd migration abort targetpool1/targetimage1

以下示例显示了如何将数据从一个 Ceph 集群迁移到另一个 Ceph 集群，这里分别命名为 cluster1 和 cluster2:

[ceph: root@rbd-client /]# cat /tmp/native_spec
{
  "cluster_name": "c1",
  "type": "native",
  "pool_name": "pool1",
  "image_name": "image1",
  "snap_name": "snap1"
}
[ceph: root@rbd-client /]# rbd migration prepare --import-only --source-spec-path /tmp/native_spec c2pool1/c2image1 --cluster c2
[ceph: root@rbd-client /]# rbd migration execute c2pool1/c2image1 --cluster c2
Image migration: 100% complete...done.
[ceph: root@rbd-client /]# rbd migration commit c2pool1/c2image1 --cluster c2
Commit image migration: 100% complete...done.

支持的镜像格式 ¶

实时迁移支持三种主要格式

Native 格式 使用 Ceph 的内部格式来实现高效的迁移。

Native 格式不包括流，因为它使用 Native Ceph 操作。例如，要从镜像 rbd/ns1/image1@snap1 导入，可以按如下方式构造源规范

{
"type": "native",
"pool_name": "rbd",
"pool_namespace": "ns1",
"image_name": "image1",
"snap_name": "snap1"
}

QCOW 格式 与 QEMU Copy-On-Write 卷镜像兼容。

QCOW 格式描述了一个 QEMU 复制写入 (QCOW) 块设备。目前支持 QCOW v1 和 v2 格式，但某些功能除外，包括压缩、加密、备份文件和外部数据文件。使用任何支持的流源使用 QCOW 格式

{
    "type": "qcow",
    "stream": {
      "type": "file",
  "file_path": "/mnt/image.qcow"
    }
}

Raw 格式 用于厚配置的块设备导出。

{
    "type": "raw",
    "stream": {
      "type": "file",
      "file_path": "/mnt/image-head.raw"
    },
    "snapshots": [
        {
            "type": "raw",
            "name": "snap1",
            "stream": {
              "type": "file",
       "file_path": "/mnt/image-snap1.raw"
            }
        },
    (optional oldest to newest ordering of snapshots)
}

支持的流 ¶

有多种流类型可用于从各种数据源导入

文件流（本地文件） ¶

使用 file 流从本地可访问的 POSIX 文件源导入。

{
    <format-specific parameters>
    "stream": {
        "type": "file",
        "file_path": "FILE_PATH"
    }
}

HTTP 流（远程 Web 服务器） ¶

使用 HTTP 流从 HTTP 或 HTTPS Web 服务器导入。

{
    <format-specific parameters>
    "stream": {
        "type": "http",
        "url": "URL_PATH"
    }
}

S3 流（AWS 或兼容的对象存储） ¶

使用 s3 流从 S3 存储桶导入。

{
    <format-specific parameters>
    "stream": {
        "type": "s3",
        "url": "URL_PATH",
        "access_key": "ACCESS_KEY",
        "secret_key": "SECRET_KEY"
    }
}

NBD 流（网络块设备导出） ¶

使用 NBD 流从远程 NBD 导出导入。

{
    <format-specific parameters>
    "stream": {
        "type": "nbd",
        "uri": "<nbd-uri>",
    }
}

nbd-uri 参数必须遵循 NBD URI 规范。默认 NBD 端口是 tcp/10809。

RBD 实时迁移的使用案例 ¶

灾难恢复和数据迁移
场景：一家组织在位于一个数据中心的主要 Ceph 集群上运行关键任务应用程序。由于即将进行的维护窗口、潜在的硬件故障或灾难事件，他们需要将 RBD 镜像迁移到位于不同位置的辅助 Ceph 集群。
好处：实时迁移确保使用 RBD 卷的应用程序在过渡到辅助集群期间可以继续运行，而不会出现停机或数据丢失。
爆发和工作负载分配
场景：一家组织运营一个 Ceph 集群，该集群可以容纳常规工作负载，但偶尔需要在高峰使用期间需要额外的容量。通过将 RBD 镜像迁移到外部 Ceph 集群（可能部署在云中），他们可以暂时扩展操作，然后缩小规模。
好处：动态工作负载平衡有助于管理员仅在需要时利用外部资源，从而降低运营成本并提高可扩展性。
数据中心迁移
场景：一家组织正在将基础设施从一个物理数据中心迁移到另一个数据中心，因为要进行升级、整合或重新定位。所有来自源 Ceph 集群的 RBD 镜像都需要移动到新位置的目标 Ceph 集群。
好处：实时迁移最大限度地减少了数据中心迁移期间的服务中断，从而保持了应用程序的可用性。
合规性和数据主权
场景：一个组织必须遵守本地数据驻留法规，这些法规要求敏感数据存储在特定的地理边界内。因此，存储在 RBD 镜像中的数据必须从通用 Ceph 集群迁移到一个专门用于并位于受监管区域的集群。
优势：实时迁移功能能够无中断地重新定位 RBD 数据，确保符合法规要求。
多集群负载和容量平衡
场景：一个组织运行多个 Ceph 集群来处理高流量工作负载。为了防止任何单个集群过载，他们根据工作负载模式的变化在集群之间重新分配 RBD 镜像。
优势：实时迁移能够有效地在 Ceph 集群之间重新平衡工作负载，优化资源利用率和性能。
开发/测试到生产环境迁移
场景：开发人员在一个专用的 Ceph 集群上运行测试环境。测试完成后，生产就绪的 RBD 镜像可以迁移到生产 Ceph 集群，而无需数据复制或停机时间。
优势：简化了将测试数据提升到生产环境的过程，同时保持数据完整性。
硬件生命周期管理
场景：一个 Ceph 集群正在运行接近生命周期结束的旧硬件。管理员计划将 RBD 镜像迁移到一个配备升级硬件的新 Ceph 集群，以提高性能和可靠性。
优势：实时迁移能够实现从旧基础设施到现代基础设施的平稳过渡，而不会影响应用程序的正常运行时间。
注意：在许多情况下，可以在不中断或迁移的情况下逐步替换 100% 的 Ceph 集群硬件，但在其他情况下，可能需要启动一个新的独立集群并在两者之间迁移数据。
全球数据复制
场景：一家企业在不同地点分布着 Ceph 集群，以改善区域终端用户的延迟。RBD 镜像可以根据数据中心增加或关闭、用户流量模式变化或业务优先级在不同区域之间迁移。
优势：通过将数据移动到更靠近消耗点的位置，同时保持数据一致性，从而增强用户体验。

结论 ¶

Ceph RBD 镜像的实时迁移提供了一种无缝高效的方式来移动存储数据和工作负载，而不会中断操作。通过利用 Ceph 原生操作和外部流源，管理员可以确保平稳灵活的数据迁移流程。

作者谨向 IBM 致谢，感谢他们通过提供时间来创建这些帖子，支持社区。