Ceph 客户端和 Ceph OSD 都使用 CRUSH map 和 CRUSH 算法。

有多个对象副本或 M 纠删代码区块有助于防止数据丢失，但这不足以解决高可用性问题。通过反映 Ceph 存储群集的底层物理组织，CRUSH 可以建模，从而解决潜在的关联设备故障来源。通过将集群的拓扑编码到集群映射中，CRUSH 放置策略可以在不同故障域中分隔对象副本或纠删代码区块，同时仍然保持所需的伪随机分布。例如，为了解决并发故障的可能性，可能需要确保数据副本或纠删代码区块位于使用不同的 shelves、机架、电源、控制器或物理位置的设备中。这有助于防止数据丢失，并允许集群处于降级状态。

Ceph 可以支持多种层次结构，将一种类型的硬件性能配置文件与其他类型的硬件性能配置文件分隔开。例如，CRUSH 可以为硬盘创建一个层次结构，并为 SSD 创建另一个层次结构。性能域 - 由于需要支持不同的性能特性，因此将底层硬件的性能配置集考虑到性能域 - 由于需要支持不同的性能特性，因此越来越流行。从操作角度而言，它们只是具有多个 根 bucket 的 CRUSH map。使用案例示例包括：

在 RHCS 3 及更高版本中，CRUSH map 支持设备 类 的概念。Ceph 可以发现存储设备的各个方面，并且自动分配 hdd、ssd 或 nvme 等类。但是，CRUSH 不限于这些默认值。例如，CRUSH 层次结构也可能用于分隔不同类型的工作负载。例如，SSD 可用于日志或 write-ahead 日志、bucket 索引或原始对象存储。CRUSH 可以支持不同的设备类别，如 ssd-bucket-index 或 ssd-object-storage，因此 Ceph 不会将相同的存储介质用于不同的工作负载，提高性能可预测性和一致性。

CRUSH 位置是 OSD 在 CRUSH map 的层次结构方面的位置。当您在命令行界面上表达 CRUSH 位置时，CRUSH 位置指定符采用描述 OSD 位置的名称/值对的列表。例如，如果某一 OSD 位于特定的行、机架、机箱和主机中，并且是 默认 CRUSH 树的一部分，其 crush 位置可以描述为：

root=default row=a rack=a2 chassis=a2a host=a2a1

注：

若要添加 bucket 实例到 CRUSH 层次结构，可指定 bucket 名称及其类型。bucket 名称在 CRUSH map 中必须是唯一的。

ceph osd crush add-bucket {name} {type}

如果您计划使用多个层次结构（例如，针对不同的硬件性能配置文件），请考虑根据其硬件类型或用例命名存储桶。

例如，您可以为固态硬盘(ssd)、带有 SSD 日志(hdd-journal)的 SAS 磁盘创建层次结构，并为 SATA 驱动器创建另一个层次结构(hdd)：

ceph osd crush add-bucket ssd-root root
ceph osd crush add-bucket hdd-journal-root root
ceph osd crush add-bucket hdd-root root

Ceph CLI 输出：

added bucket ssd-root type root to crush map
added bucket hdd-journal-root type root to crush map
added bucket hdd-root type root to crush map

添加层次结构所需的每种 bucket 类型的实例。以下示例演示了如何添加一行中的 bucket，其中包含 SSD 主机的机架和对象存储的主机机架。

ceph osd crush add-bucket ssd-row1 row
ceph osd crush add-bucket ssd-row1-rack1 rack
ceph osd crush add-bucket ssd-row1-rack1-host1 host
ceph osd crush add-bucket ssd-row1-rack1-host2 host
ceph osd crush add-bucket hdd-row1 row
ceph osd crush add-bucket hdd-row1-rack2 rack
ceph osd crush add-bucket hdd-row1-rack1-host1 host
ceph osd crush add-bucket hdd-row1-rack1-host2 host
ceph osd crush add-bucket hdd-row1-rack1-host3 host
ceph osd crush add-bucket hdd-row1-rack1-host4 host

完成这些步骤后，请查看您的树。

ceph osd tree

请注意，层次结构保持扁平状态。将存储桶添加到 CRUSH map 后，您必须将它们移到层次结构位置。

在创建初始集群时，Ceph 具有名为 default 的根 bucket 的默认 CRUSH map，您的初始 OSD 主机显示在 默认 bucket 下。当您添加 bucket 实例到 CRUSH map 时，它会出现在 CRUSH 层次结构中，但不一定显示在特定 bucket 下。

若要将 bucket 实例移到 CRUSH 层次结构中的特定位置，可指定 bucket 名称及其类型。例如：

ceph osd crush move ssd-row1 root=ssd-root
ceph osd crush move ssd-row1-rack1 row=ssd-row1
ceph osd crush move ssd-row1-rack1-host1 rack=ssd-row1-rack1
ceph osd crush move ssd-row1-rack1-host2 rack=ssd-row1-rack1

完成这些步骤后，您可以查看树。

ceph osd tree

若要从 CRUSH 层次结构中移除 bucket 实例，可指定 bucket 名称。例如：

ceph osd crush remove {bucket-name}

或者：

ceph osd crush rm {bucket-name}

如果您要删除更高级别的存储桶（如 default），请检查池是否使用 CRUSH 规则来选择该 bucket。如果是这样，您需要修改 CRUSH 规则；否则，peering 会失败。

在使用 Ceph CLI 创建 bucket 时，Ceph 会默认将算法设置为 straw。Ceph 支持四种 bucket 算法，每种算法代表性能和提升效率之间的权衡。如果您不确定要使用的存储桶类型，我们建议使用 straw bucket。bucket 算法是：

ceph osd crush tree 命令在树 视图中打印 CRUSH bucket 和项。使用此命令来确定特定 bucket 中的 OSD 列表。它将打印类似于 ceph osd 树 的输出。

要返回更多详细信息，请执行以下操作：

# ceph osd crush tree -f json-pretty

该命令返回类似如下的输出：

[
    {
        "id": -2,
        "name": "ssd",
        "type": "root",
        "type_id": 10,
        "items": [
            {
                "id": -6,
                "name": "dell-per630-11-ssd",
                "type": "host",
                "type_id": 1,
                "items": [
                    {
                        "id": 6,
                        "name": "osd.6",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.099991,
                        "depth": 2
                    }
                ]
            },
            {
                "id": -7,
                "name": "dell-per630-12-ssd",
                "type": "host",
                "type_id": 1,
                "items": [
                    {
                        "id": 7,
                        "name": "osd.7",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.099991,
                        "depth": 2
                    }
                ]
            },
            {
                "id": -8,
                "name": "dell-per630-13-ssd",
                "type": "host",
                "type_id": 1,
                "items": [
                    {
                        "id": 8,
                        "name": "osd.8",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.099991,
                        "depth": 2
                    }
                ]
            }
        ]
    },
    {
        "id": -1,
        "name": "default",
        "type": "root",
        "type_id": 10,
        "items": [
            {
                "id": -3,
                "name": "dell-per630-11",
                "type": "host",
                "type_id": 1,
                "items": [
                    {
                        "id": 0,
                        "name": "osd.0",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.449997,
                        "depth": 2
                    },
                    {
                        "id": 3,
                        "name": "osd.3",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.289993,
                        "depth": 2
                    }
                ]
            },
            {
                "id": -4,
                "name": "dell-per630-12",
                "type": "host",
                "type_id": 1,
                "items": [
                    {
                        "id": 1,
                        "name": "osd.1",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.449997,
                        "depth": 2
                    },
                    {
                        "id": 4,
                        "name": "osd.4",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.289993,
                        "depth": 2
                    }
                ]
            },
            {
                "id": -5,
                "name": "dell-per630-13",
                "type": "host",
                "type_id": 1,
                "items": [
                    {
                        "id": 2,
                        "name": "osd.2",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.449997,
                        "depth": 2
                    },
                    {
                        "id": 5,
                        "name": "osd.5",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.289993,
                        "depth": 2
                    }
                ]
            }
        ]
    }
]

将 OSD 添加到 CRUSH 层次结构中是最后一步，然后您启动 OSD（ 在 中进行渲染），Ceph 将 PG 分配到 OSD。

您必须先准备 OSD，然后才能将它添加到 CRUSH 层次结构中。部署实用程序（如 Ansible 自动化应用）为您执行这一步。如需了解更多详细信息，请参阅添加/删除 OSD。

CRUSH 层次结构是概念性的，因此 ceph osd crush add 命令允许您在您希望的任何位置添加 OSD 到 CRUSH 层次结构。您指定的位置 应反映 其实际位置。如果至少指定了一个 bucket，命令会将 OSD 放置到您指定的最具体的 bucket 中，它会 将 bucket 移到您指定的任何其他 bucket 的下方。

将 OSD 添加到 CRUSH 层次结构中：

ceph osd crush add {id-or-name} {weight}  [{bucket-type}={bucket-name} ...]

以下示例在层次结构中添加 osd.0 ：

ceph osd crush add osd.0 1.0 root=default datacenter=dc1 room=room1 row=foo rack=bar host=foo-bar-1

如果部署实用程序（如 Ansible 自动化应用在更优的 CRUSH 位置添加了 OSD 到 CRUSH map），或者集群拓扑发生变化，则可以移动 CRUSH 层次结构中的 OSD 以反映其实际位置。

在 CRUSH 层次结构中移动 OSD：

ceph osd crush set {id-or-name} {weight} root={pool-name}  [{bucket-type}={bucket-name} ...]

在您要从集群中删除 OSD 时，从 CRUSH 层次结构中删除 OSD 是第一步。当您从 CRUSH map 移除 OSD 时，CRUSH 会重新计算哪些 OSD 获取 PG，并相应地重新平衡数据。如需了解更多详细信息，请参阅添加/删除 OSD。

要从正在运行的集群的 CRUSH map 移除 OSD，请执行以下操作：

ceph osd crush remove {name}

要为 OSD 设置设备类，请执行以下操作：

# ceph osd crush set-device-class <class> <osdId> [<osdId>...]

例如：

# ceph osd crush set-device-class hdd osd.0 osd.1
# ceph osd crush set-device-class ssd osd.2 osd.3
# ceph osd crush set-device-class bucket-index osd.4

要删除 OSD 的设备类，请执行以下操作：

# ceph osd crush rm-device-class <class> <osdId> [<osdId>...]

例如：

# ceph osd crush rm-device-class hdd osd.0 osd.1
# ceph osd crush rm-device-class ssd osd.2 osd.3
# ceph osd crush rm-device-class bucket-index osd.4

要为所有使用该类的 OSD 重命名设备类，请执行以下操作：

# ceph osd crush class rename <oldName> <newName>

例如：

# ceph osd crush class rename hdd sas15k

要列出 CRUSH map 中的设备类，请执行以下操作：

# ceph osd crush class ls

输出将类似如下：

[
    "hdd",
    "ssd",
    "bucket-index"
]

要列出属于特定类的所有 OSD，请执行以下操作：

# ceph osd crush class ls-osd <class>

例如：

# ceph osd crush class ls-osd hdd

输出只是 OSD 编号的列表。例如：

0
1
2
3
4
5
6

要列出所有引用同一类的规则，请执行以下操作：

# ceph osd crush rule ls-by-class <class>

例如：

# ceph osd crush rule ls-by-class hdd

要在 CRUSH map 内以 Terabytes 为单位设置 OSD CRUSH 权重，请执行以下命令

ceph osd crush reweight {name} {weight}

其中：

此设置在创建 OSD 时使用，或者在添加 OSD 后立即调整 CRUSH 权重。它通常不会在 OSD 的生命周期内更改。

使用 ceph osd crush reweight 可能会非常耗时。您可以通过执行以下命令在 bucket 下设置（或重置）所有 Ceph OSD 权重（row、rack 和 node 等）：

osd crush reweight-subtree <name>

其中,

name 是 CRUSH bucket 的名称。

出于 ceph osd in 和 ceph osd out 的目的 ， OSD 在集群中或集群 外。这是监控器记录 OSD 状态的方式。但是，即使 OSD 在 集群中存在，但可能会遇到故障问题，因此您可能希望在修复前完全依赖它（例如，替换存储驱动器，更改控制器等等）。

您可以通过执行以下命令来增加或减小特定 OSD 的权重 （即，不更改其以 Terabytes 为单位的权重）：

ceph osd reweight {id} {weight}

其中：

CRUSH 设计为用于写入请求的近似平均度分布，从而将新数据对象 PG 和 PG 分配到 OSD。但是，集群可能会变得不平衡。这样做的原因有很多。例如：

您可以通过执行以下内容来重新加权 OSD：

ceph osd reweight-by-utilization [threshold]  [weight_change_amount] [number_of_OSDs] [--no-increasing]

例如：

ceph osd test-reweight-by-utilization 110 .5 4 --no-increasing

其中：

执行此或其他分配权重的权重命令将覆盖此命令分配的权重（例如，osd reweight-by-utilization、os d crush weight、os d weight、in或 out）。

在具有数量较少 OSD 的 CRUSH 层次结构中，一些 OSD 可能获得比其他 OSD 更多的 PG，从而导致负载更高。您可以通过执行以下内容，按 PG 分布重新加权 OSD 来解决这种情况：

osd reweight-by-pg <poolname>

其中：

CRUSH 树 bucket 应当是其 leaf 权重的总和。如果手动编辑 CRUSH map 权重，您应该执行下列命令，以确保 CRUSH bucket 树准确反映 bucket 下的 leaf OSD 的总和。

osd crush reweight-all

要从命令行列出 CRUSH 规则，请执行以下操作：

ceph osd crush rule list
ceph osd crush rule ls

要转储特定 CRUSH 规则的内容，请执行以下操作：

ceph osd crush rule dump {name}

要添加 CRUSH 规则，您必须指定规则名称、要使用的层次结构的根节点、您要复制到的存储桶类型（例如，'rack'、'row' 等），以及选择存储桶的模式。

ceph osd crush rule create-simple {rulename} {root} {bucket-type} {firstn|indep}

Ceph 将创建一个包含您指定类型的 select leaf 和 1 bucket 的规则。

例如：

ceph osd crush rule create-simple deleteme default host firstn

创建以下规则：

{ "rule_id": 1,
  "rule_name": "deleteme",
  "ruleset": 1,
  "type": 1,
  "min_size": 1,
  "max_size": 10,
  "steps": [
        { "op": "take",
          "item": -1,
          "item_name": "default"},
        { "op": "chooseleaf_firstn",
          "num": 0,
          "type": "host"},
        { "op": "emit"}]}

要为复制池创建 CRUSH 规则，请执行以下操作：

# ceph osd crush rule create-replicated <name> <root> <failure-domain> <class>

其中：

例如：

# ceph osd crush rule create-replicated fast default host ssd

要添加用于纠删代码池的 CRUSH 规则，您可以指定规则名称和纠删代码 profile。

ceph osd crush rule create-erasure {rulename} {profilename}

要移除规则，请执行下列命令并指定 CRUSH 规则名称：

ceph osd crush rule rm {name}

0.48 之前的 Ceph 客户端和守护进程无法检测到可调项，且与版本 0.48 及更高版本不兼容，您必须升级。调整可调 CRUSH 值的功能也随着主要 Ceph 发行版而得到演进。

在您调优 CRUSH 之前，您应该确保所有 Ceph 客户端和所有 Ceph 守护进程都使用相同的版本。如果您最近升级了，请确保已重启守护进程并重新连接了客户端。

调整 CRUSH 可调项的最简单方法是更改为已知的配置文件。这些是：

您可以使用以下命令在正在运行的集群中选择配置集：

# ceph osd crush tunables <profile>

通常，您应该在升级后或者收到警告时设置 CRUSH 可调项。从版本 v0.74 开始，如果 CRUSH 可调项未设置为其最佳值，Ceph 将发出健康警告，优化值是 v0.73 的默认值。要使此警告消失，有两个选项：

如果可以确保所有客户端都运行最新的代码，您可以通过提取 CRUSH map、修改值并将它重新注入到集群中来调整可调项。

为便于参考，可使用以下方法设置 CRUSH 可调项的旧值：

crushtool -i /tmp/crush --set-choose-local-tries 2 --set-choose-local-fallback-tries 5 --set-choose-total-tries 19 --set-chooseleaf-descend-once 0 --set-chooseleaf-vary-r 0 -o /tmp/crush.legacy

再强调一下，需要使用特殊的 --enable-unsafe-tunables 选项。此外，如上所述，在还原旧值后，请小心运行 ceph-osd 守护进程的旧版本，因为功能位没有被完全强制实施。

要获取集群的 CRUSH map，请执行以下操作：

ceph osd getcrushmap -o {compiled-crushmap-filename}

Ceph 将输出(-o)编译的 CRUSH map 到您指定的文件名。由于 CRUSH map 采用编译的形式，您必须先解译它，然后才能编辑它。

要解译 CRUSH map，请执行以下操作：

crushtool -d {compiled-crushmap-filename} -o {decompiled-crushmap-filename}

Ceph 会将编译后的 CRUSH map 和输出(-o)解译为您指定的文件名。

要编译 CRUSH map，请执行以下操作：

crushtool -c {decompiled-crush-map-filename} -o {compiled-crush-map-filename}

Ceph 将存储编译后的 CRUSH map 到您指定的文件名。

要为您的集群设置 CRUSH map，请执行以下操作：

ceph osd setcrushmap -i  {compiled-crushmap-filename}

Ceph 将输入您指定为集群 CRUSH map 的文件名编译的 CRUSH map。

Ceph 努力防止数据永久丢失。但是，在 OSD 出现故障后，永久数据丢失的风险会增加，直到其包含的数据被完全恢复。永久数据丢失虽然很少，但仍可能发生。以下场景描述了 Ceph 如何在具有三个数据副本的单个放置组中永久丢失数据：

硬件故障并非例外，而是预期的结果。为防止这种情况，理想情况下的恢复过程应尽可能快。集群的大小、您的硬件配置和放置组在总恢复时间中扮演着重要角色。

Ceph 可能会在剩余的 9 个 OSD 中随机存储剩余的 150 个 PG。因此，每个剩余的 OSD 可能会发送对象副本到所有其他 OSD，并且接收一些新的对象，因为剩余的 OSD 不再负责现在分配给它们的部分 150 个 PG。

恢复时间总量取决于支持池的硬件。例如，在一个 10 个 OSD 集群中，如果一个主机包含一个具有 1 TB SSD 的 OSD，并且 10 GB/s 交换机连接每个 10 个主机，恢复时间将花费 M 分钟。相反，如果主机包含两个 SATA OSD，并且 1 GB/s 交换机连接了五个主机，恢复将花费大量时间。有趣的是，在这个规模的群集中，放置组的数量几乎对数据持久性没有影响。放置组数可以是 128 或 8192，恢复速度不会慢或较快。

不过，将同一 Ceph 集群扩展到 20 个 OSD 而非 10 个 OSD 可能会加快恢复速度，从而显著提高数据持久性。为什么？每个 OSD 现在仅参与 75 个放置组，而非 150。20 OSD 集群仍然需要所有 19 个 OSD 执行相同数量的副本操作才能恢复。在 10 个 OSD 集群中，每个 OSD 必须复制约 100 GB。在 20 OSD 集群中，每个 OSD 只需要每个 OSD 复制到 50 GB。如果网络成为瓶颈，恢复会以最快的速度进行两次。换句话说，随着 OSD 数量的增加，恢复时间会减少。

在上述 10 OSD 集群中，如果任何 OSD 失败，则大约 8 个 PG（即 75 pgs / 9 osds / 9 osds）将只有一个存活副本。如果任何 8 个剩余的 OSD 失败，一个 PG 的最后一个对象可能会丢失（即 8 pgs / 8 osds，只有一个剩余的副本被恢复）。这就是为什么从一些较大的集群开始，最好使用 50 个 OSD。

当集群大小增加到 20 个 OSD 时，丢失三个 OSD 的 PG 数量会下降。第二个 OSD 丢失大约 2（即 35 pgs / 19 osds，而不是 8 个），而第三个 OSD 只有在包含 surviving copy 的两个 OSD 中的一个时，才会丢失数据。换而言之，如果恢复时间范围内丢失一个 OSD 的可能性为 0.0001%，则它从具有 10 个 OSD 的集群中的 8 * 0.0001% 到具有 20 个 OSD 的集群中 2 * 0.0001%。就数据持久性而言，在少于 50 个 OSD 的集群中，拥有 512 或 4096 个 PG 大致相等。

将 OSD 添加到集群中时，可能需要很长时间来填充具有放置组和对象的新 OSD。不过，任何对象都不会降级，添加 OSD 不会影响数据持久性。

Ceph 力图避免热点，即，一些 OSD 获得的流量比其他 OSD 更多。理想情况下，CRUSH 将对象均匀分配给放置组，使得放置组分配到 OSD 时（也是随机的），Primary OSD 存储对象，使得它们均匀分布在群集、热点和网络超额订阅问题中。

由于 CRUSH 计算各个对象的 PG，但实际上不知道此放置组内各个 OSD 中存储多少数据，而 PG 数量和 OSD 的数量可能会显著影响数据的分布。

例如，如果三个副本池中只有一个 PG，Ceph 将仅使用三个 OSD 来存储数据，因为 CRUSH 没有其他选择。当有更多放置组可用时，CRUSH 更有可能在 OSD 之间均匀分布对象。CRUSH 也均匀分配 PG 到 OSD。

只要 PG 比 OSD 高一或两个数量级，分布就应该是均匀的。例如，32 个 PG 用于 3 个 OSD，512 或 1024 个 PG 用于 10 个 OSD，以此类推。

OSD 和 PG 之间的比例通常解决了实施对象分条等高级功能的 Ceph 客户端的数据分布不均匀的问题。例如，一个 4 TB 块设备可能会分片到 4MB 对象中。

在其他情形中，OSD 和 PG 之间的比率不会解决数据分布不均匀的问题，因为 CRUSH 不考虑对象大小。使用 librados 接口存储一些相对较小的对象，一些非常大的对象可能会导致数据分布不均匀。例如，总共 4 GB 的 100万个 4K 对象均匀分布在 10 个 OSD 上的 1000 个放置组中。它们将在每个 OSD 上使用 4 GB / 10 = 400 MB。如果一个 400 MB 的对象添加到池中，则支持放置对象的 PG 的三个 OSD 将会填充 400 MB + 400 MB = 800 MB，而其他七个 OSD 仍然仅被占据 400MB。

对于每个放置组，OSD 和 Ceph 监视器始终需要内存、网络和 CPU，在恢复期间则需要更多。在放置组中通过集群对象共享此开销是放置组存在的主要原因之一。

最大程度减少 PG 数量可节省大量资源。

PG 计算器为您计算 PG 数量，并解决特定的用例。当使用 Ceph 客户端（如 Ceph 对象网关）时，PG 计算器特别有用，因为有许多池通常使用相同的规则（CRUSH 层次结构）。您可能仍然使用 PG Count for Small Clusters 和 Calculating PG Count 来手动计算 PG。不过，PG 计算器是计算 PG 的首选方法。

详情请参阅 红帽客户门户 上的每个池 PG(PG )。

在创建池时，您还会为池创建多个 PG。如果不指定放置组的数量，Ceph 将使用默认值 32，对于某些池而言 这 比较低。您可以为池增加 PG 数量，但我们也建议在 Ceph 配置文件中设置合理的默认值。

osd pool default pg num = 1024
osd pool default pgp num = 1024

您需要设置 PG 数量（完整），以及用于对象的 PG 数量（用于 PG 拆分）。它们应该是相等的。

小型集群不会从大量放置组中受益。随着 OSD 数量增加，pg_num 和 pgp_num 的正确值变得更为重要，因为它对集群的行为有显著影响，并在出现问题时对数据的持久性（严重事件事件导致数据丢失）。务必要将 PG 计算器 用于小型集群。

如果您有 50 多个 OSD，我们建议每个 OSD 大约 50-100 个 PG，以平衡资源使用量、数据持久性和分布。如果您没有 50 个 OSD，理想的做法是在 PG Count 中选择 Small Clusters。对于单个对象池，您可以使用以下公式来获取基准：

                (OSDs * 100)
   Total PGs =  ------------
                 pool size

其中，池大小 是复制池的副本数量，或者是纠删代码池的 K+M 和（由 ceph osd erasure-code-profile get返回）。

然后，您应该检查结果是否与 Ceph 集群的设计方式有关，以最大程度提高数据的持久性、数据分布并最大程度减少资源使用量。

结果应 四舍五入至 2 个最接近的力量。向上取整是可选的，但建议 CRUSH 在放置组之间均匀平衡对象数量。

对于具有 200 个 OSD 且池大小为 3 个副本的集群，您可以估算 PG 数量，如下所示：

   (200 * 100)
   ----------- = 6667. Nearest power of 2: 8192
        3

放置组分布在 200 个 OSD 的 8192 个 PG 中，它评估到每个 OSD 大约 41 个 PG。您还需要考虑您可能在集群中使用的池数量，因为每个池也会创建 PG。确保您有合理的 最大 PG 数。

在使用多个数据池来存储对象时，您需要确保平衡每个池的 PG 数量和每个 OSD 的 PG 数量，以便达到合理的 PG 总数。目标是在不耗费系统资源或使 peering 进程变得太慢的情况下，实现每个 OSD 的相对差异。

在由 10 个池组成的实例式 Ceph 存储群集中，每个池在 10 个 OSD 上具有 512 个 PG，每个 OSD 共有 5,120 个 PG，分散在 10 个 OSD 或 512 个 PG 上。这可能不会根据您的硬件配置使用太多的资源。相比之下，如果您创建 1,000 个池，各自具有 512 个 PG，OSD 将分别处理大约 50,000 个 PG，并且需要的资源明显多得多。每个 OSD 使用太多 PG 运行可能会显著降低性能，特别是在重新平衡或恢复期间。

Ceph 存储集群每个 OSD 的默认值最大为 300 个 PG。您可以在 Ceph 配置文件中设置不同的最大值。

mon_max_pg_per_osd

红帽 Ceph 存储集群中的每个池都有 PG 的 a pg_autoscale_mode 属性，您可以设置为 off、on 或 warn。

pg_autoscale_mode 的默认值为 warn 模式。

SIZE 是池中存储的数据量。TARGET SIZE （如果存在）是管理员所指定的数据量，它们最终预计存储在这个池中。系统将较大的值用于计算。

RATE 是池的倍数，它决定了池使用的原始存储容量。例如，3 个副本池的比例为 3.0，而 k=4,m=2 纠删代码池则比率为 1.5。

RAW CAPACITY 是 OSD 上原始存储容量的总量，它们负责存储池的数据。RATIO 是池消耗的总容量的比例，即比率 = 大小 * 速率/原始容量。

TARGET RATIO （若存在）是管理员指定的存储比率，他们希望池相对于设置了目标比率的其他池使用。如果同时指定了目标大小字节和比率，则比率优先。

EFFECTIVE RATIO 是调整后通过两种方式调整后的目标比率：1. 减去由设置了目标大小的池预期使用的任何容量。2. 规范设置了目标比率的池之间的目标比率，以便它们共同将剩余空间作为目标。例如，4 个 目标比率为 1.0 的池将 有效比率为 0.25。系统使用较大的实际比率和计算的有效比率。

BIAS 是池属性，PG 自动扩展器以 PG 数量比其他池更快地扩展。它基本上是一个倍数，用于向池提供比默认 PG 数量更多的 PG。此属性特别用于元数据池，它们的大小可能很小，但具有大量对象，因此更快地扩展它们对于更好的性能至关重要。BIAS 的默认值为 1.0。您可以通过运行 ceph osd pool set pool-name pg_autoscale_bias 4 命令来设置这个值。接受的值介于 0 到 1000 之间。但是，建议默认为 CephFS 元数据池和 Ceph 对象网关索引池将 BIAS 的值设置为 4.0。

PG_NUM 是池的当前 PG 数量，或者池正在工作的 PG 数量（如果 a pg_num 正在进行更改）。新 PG_NUM （若存在）是推荐的 PG 数量(pg_num)。它始终是 2 的幂，且只有建议的值与当前值相差时超过 3 倍。

AUTOSCALE 是 pool pg_autoscale_mode，是 on、off 或 warn。

允许集群根据集群使用情况自动扩展 PG 是扩展 PG 最简单的方法。红帽 Ceph 存储提取整个系统的可用存储总数和目标 PG 数量，比较每个池中存储的数据量，并相应地调整 PG。命令仅对当前数量 PG(pg_num)超过计算或建议的 PG 编号的池进行更改。

每个 OSD 的 PG 的目标数量基于可配置的 mon_target_pg_per_osd。默认值为 100。

新创建的池消耗集群总容量的一小部分，显示在系统中需要少量 PG。然而，在大多数情况下，集群管理员知道哪些池会随着时间推移消耗大多数系统容量。如果您提供此信息（称为红帽 Ceph 存储 的目标大小 ），则这些池可以从开始便使用更合适的 PG 数量(pg_num)。这种方法可以防止后续的 change pg_num 以及那些调整时移动数据相关的开销。

您可以通过以下方法指定池 的目标大小 ：

要在池中设置 PG 数量，您必须在创建池时指定 PG 数量。详情请参阅 创建池。要在创建池后更改 PG 数量，请执行以下操作：

ceph osd pool set {pool-name} pg_num {pg_num}

旦增加了 PG 的数量，还必须增加放置的 PG 数量(pgp_num)，然后才能重新平衡集群。The pgp_num 应当等于 the pg_num。The pgp_num 将是由 CRUSH 算法考虑放置的 PG 数量。Increasing pg_num 可分割 PG，但不会将数据迁移到较新的 PG，直到放置的 PG 被增加，即 pgp_num。要增加放置的 PG 数量，请执行以下操作：

ceph osd pool set {pool-name} pgp_num {pgp_num}

在减少 PG 数量时，pgp_num 会自动调整。

要获取池中 PG 的数量，请执行以下操作：

ceph osd pool get {pool-name} pg_num

要获取集群中 PG 的统计信息，请执行以下操作：

ceph pg dump [--format {format}]

有效格式为 纯文本 （默认）和 json。

要获取处于指定状态的所有放置组的统计信息，请执行以下操作：

ceph pg dump_stuck {inactive|unclean|stale|undersized|degraded [inactive|unclean|stale|undersized|degraded...]} {<int>}

不 活跃的 PG 无法处理读取和写入，因为它们正在等待具有最新数据的 OSD 出现并进入。

unclean 放置组包含没有复制所需次数的对象。它们应该正在恢复。

stale Placement 组处于未知状态 - 托管它们的 OSD 暂时尚未报告到 monitor 集群（ mon_osd_report_timeout配置）。

有效格式为 纯文本 （默认）和 json。该阈值定义 PG 在将 PG 包含在返回统计信息（默认值 300 秒）之前卡住的最少秒数。

要获取特定 PG 的 PG map，请执行以下操作：

ceph pg map {pg-id}

例如：

ceph pg map 1.6c

Ceph 将返回 PG map、PG 和 OSD 状态：

osdmap e13 pg 1.6c (1.6c) -> up [1,0] acting [1,0]

要检索特定放置组的统计信息，请执行以下操作：

ceph pg {pg-id} query

要清理 PG，请执行以下操作：

ceph pg scrub {pg-id}

Ceph 检查主节点和任何副本节点，生成放置组中所有对象的目录，并将它们进行比较，以确保没有对象缺失或不匹配，并且其内容一致。假设副本全部匹配，则最终语义深度可确保与快照相关的所有对象元数据保持一致。错误通过日志中报告。

如果集群丢失了一个或多个对象，并且您决定放弃搜索丢失的数据，您必须将未找到的对象标记为 丢失。

如果查询了所有可能的位置，并且对象仍丢失，您可能必须放弃丢失的对象。这可能是因为异常故障组合允许集群了解在恢复写入本身前执行的写入操作。

目前唯一支持的选项是"恢复"，该选项将回滚到对象的以前版本，或者（如果它是一个新对象）完全忘记该对象。要将 "unfound" 对象标记为 "lost"，请执行以下操作：

ceph pg {pg-id} mark_unfound_lost revert|delete

创建新纠删代码 profile：

ceph osd erasure-code-profile set <name> \
         [<directory=directory>] \
         [<plugin=plugin>] \
         [<stripe_unit=stripe_unit>] \
         [<crush-device-class>]\
         [<crush-failure-domain>]\
         [<key=value> ...] \
         [--force]

其中：

删除纠删代码 profile：

ceph osd erasure-code-profile rm <name>

如果配置集被池引用，则删除会失败。

显示纠删代码 profile：

ceph osd erasure-code-profile get <name>

列出所有纠删代码配置集的名称：

ceph osd erasure-code-profile ls

jerasure 插件是最通用且最灵活的插件。它也是 Ceph 纠删代码池的默认方法。

jerasure 插件封装 JerasureH 库。有关参数的详情，请查看 jerasure 文档。

要使用 jerasure 插件创建新的纠删代码 profile，请运行以下命令：

ceph osd erasure-code-profile set <name> \
     plugin=jerasure \
     k=<data-chunks> \
     m=<coding-chunks> \
     technique=<reed_sol_van|reed_sol_r6_op|cauchy_orig|cauchy_good|liberation|blaum_roth|liber8tion> \
     [crush-root=<root>] \
     [crush-failure-domain=<bucket-type>] \
     [directory=<directory>] \
     [--force]

其中：

利用 jerasure 插件，Ceph 将纠删代码对象存储在多个 OSD 上时，从丢失的 OSD 中恢复需要从所有其他 OSD 读取。例如，如果您使用 k=8 和 m= 4 配置 jerasure，则丢失一个 OSD 需要从 10 个 OSD 中读取才能修复。

lrc 纠删代码插件创建本地奇偶校验区块，以便能够使用更少的 OSD 恢复。例如，如果您使用 k=8、m= 4 和 l=4 配置 l rc，它将为每四个 OSD 创建一个额外的奇偶校验块。当 Ceph 丢失单个 OSD 时，它可以仅使用四个 OSD 而不是十个 OSD 恢复对象数据。

虽然当所有主机都连接到同一交换机时，可能不是有趣的用例，但实际上您可以在使用 lrc 纠删代码插件时看到机架之间的带宽使用量降低。

$ ceph osd erasure-code-profile set LRCprofile \
     plugin=lrc \
     k=4 m=2 l=3 \
     crush-failure-domain=host
$ ceph osd pool create lrcpool 12 12 erasure LRCprofile

在 1.2 版本中，只有Primary OSD 与丢失的块处于相同的机架时，您才能看到带宽降低。

$ ceph osd erasure-code-profile set LRCprofile \
     plugin=lrc \
     k=4 m=2 l=3 \
     crush-locality=rack \
     crush-failure-domain=host
$ ceph osd pool create lrcpool 12 12 erasure LRCprofile

ceph osd erasure-code-profile set <name> \
     plugin=lrc \
     k=<data-chunks> \
     m=<coding-chunks> \
     l=<locality> \
     [crush-root=<root>] \
     [crush-locality=<bucket-type>] \
     [crush-failure-domain=<bucket-type>] \
     [directory=<directory>] \
     [--force]

chunk nr    01234567
step 1      _cDD_cDD
step 2      cDDD____
step 3      ____cDDD

$ ceph osd erasure-code-profile set LRCprofile \
     plugin=lrc \
     mapping=DD_ \
     layers='[ [ "DDc", "" ] ]'
$ ceph osd pool create lrcpool 12 12 erasure LRCprofile

$ ceph osd erasure-code-profile set LRCprofile \
     plugin=lrc \
     mapping=__DD__DD \
     layers='[
               [ "_cDD_cDD", "" ],
               [ "cDDD____", "" ],
               [ "____cDDD", "" ],
             ]'
$ ceph osd pool create lrcpool 12 12 erasure LRCprofile

$ ceph osd erasure-code-profile set LRCprofile \
     plugin=lrc \
     mapping=__DD__DD \
     layers='[
               [ "_cDD_cDD", "" ],
               [ "cDDD____", "" ],
               [ "____cDDD", "" ],
             ]' \
     crush-steps='[
                     [ "choose", "rack", 2 ],
                     [ "chooseleaf", "host", 4 ],
                    ]'
$ ceph osd pool create lrcpool 12 12 erasure LRCprofile

$ ceph osd erasure-code-profile set LRCprofile \
     plugin=lrc \
     mapping=DD_ \
     layers='[ [ "DDc", "plugin=isa technique=cauchy" ] ]'
$ ceph osd pool create lrcpool 12 12 erasure LRCprofile

$ ceph osd erasure-code-profile set LRCprofile \
     plugin=lrc \
     mapping=__DD__DD \
     layers='[
               [ "_cDD_cDD", "plugin=isa technique=cauchy" ],
               [ "cDDD____", "plugin=isa" ],
               [ "____cDDD", "plugin=jerasure" ],
             ]'
$ ceph osd pool create lrcpool 12 12 erasure LRCprofile

默认 CRUSH 规则提供位于不同主机上的 OSD。例如：

chunk nr    01234567

step 1      _cDD_cDD
step 2      cDDD____
step 3      ____cDDD

需要正好 8 个 OSD，每个区块一个。如果主机位于两个相邻的机架中，则前四个区块可以放在第一个机架中，然后在第二架中排在最后四块中。恢复单一 OSD 丢失不需要在两个机架之间使用带宽。

例如：

crush-steps='[ [ "choose", "rack", 2 ], [ "chooseleaf", "host", 4 ] ]'

将创建一条规则，以选择两个类型为 rack 的 crush bucket，并且各自选择四个 OSD，分别位于 主机 类型不同的 bucket 中。

也可以手动创建该规则以进行更精细的控制。