所有 Red Hat Ceph Storage 集群都有一个配置，它定义：

部署工具（如 cephadm ）通常会为您创建初始 Ceph 配置文件。但是，如果您想在没有使用部署工具的情况下引导 Red Hat Ceph Storage 集群，您可以自己创建一个。

Ceph Monitor 管理 Ceph 选项的配置数据库，通过存储整个存储集群的配置选项来集中管理配置管理。通过将 Ceph 配置集中到一个数据库中，从而简化了存储集群管理。

Ceph 用于设置选项的优先级顺序是：

仍然可在本地 Ceph 配置文件中定义一些 Ceph 选项，默认为 /etc/ceph/ceph.conf。但是，对于 Red Hat Ceph Storage 5，ceph.conf 已被弃用。

cephadm 使用基本的 ceph.conf 文件，该文件仅包含连接到 Ceph 监控器、身份验证和获取配置信息的最小选项集合。在大多数情况下，cephadm 仅使用 mon_host 选项。要避免仅将 ceph.conf 用于 mon_host 选项，请使用 DNS SRV 记录来通过 monitor 执行操作。

Ceph 允许您在运行时更改守护进程的配置。通过启用或禁用 debug 设置，此功能可用于增加或减少日志输出，甚至可用于运行时优化。

Ceph 配置选项可以带有关联的掩码。这些掩码可以进一步限制选项应用到的守护进程或客户端。

掩码有两种形式：

Metavariables 简化了 Ceph 存储集群配置。在配置值中设置 metavariable 时，Ceph 会将 metavariable 扩展为 Concrete 值。

在 Ceph 配置文件的 [global], [osd], [mon], 或 [client] 部分中使用时，Mtavariables 非常强大。但是，您也可以在管理套接字中使用它们。Ceph 元变量与 Bash shell 扩展类似。

Ceph 支持以下元变量：

可以在启动时或运行时查看 Ceph 配置文件。

Red Hat Ceph Storage 的配置设置可在 Ceph 监控节点运行时查看。

要在运行时设置特定的 Ceph 配置，请使用 ceph config set 命令。

ceph config set mgr mgr/cephadm/manage_etc_ceph_ceph_conf false

BlueStore 将 OSD 堆内存使用量保留在指定目标大小下，并使用 osd_memory_target 配置选项。

选项 osd_memory_target 根据系统中可用的 RAM 来设置 OSD 内存。当 TCMalloc 配置为内存分配器，BlueStore 中的 bluestore_cache_autotune 选项设为 true 时，则使用此选项。

当块设备速度较慢时（例如，传统的硬盘驱动器），Ceph OSD 内存缓存更为重要，因为缓存命中的好处要高于固态硬盘的情况。但是，这需要考虑 OSD 与其他服务共处的情况，比如在超融合基础架构 (HCI) 或其他应用程序中。

OSD 守护进程根据 osd_memory_target 配置选项调整内存消耗。选项 osd_memory_target 根据系统中可用的 RAM 来设置 OSD 内存。

如果 Red Hat Ceph Storage 部署在不与其他服务共享内存的专用节点上，cephadm 会自动根据 RAM 总量和部署的 OSD 数量自动调整每个 OSD 消耗。

ceph config set osd osd_memory_target_autotune true

当存储集群升级到 Red Hat Ceph Storage 5.0（例如添加 OSD 或替换 OSD）后，红帽建议将 osd_memory_target_autotune 参数设置为 true，以根据系统内存自动调优 osd memory。

Cephadm 以一个 mgr/cephadm/autotune_memory_target_ratio 分数开头，默认为系统总 RAM 的 0.7，这会减小非自动tuned守护进程（如 non-OSDS）以及 osd_memory_target_autotune 为 false 的 OSD，然后划分剩余的 OSD。

默认情况下，autotune_memory_target_ratio 是 0.2（hyper-converged infrastructure）和 0.7（其他环境）。

osd_memory_target 参数计算如下：

osd_memory_target = TOTAL_RAM_OF_THE_OSD_NODE (in Bytes) * (autotune_memory_target_ratio) / NUMBER_OF_OSDS_IN_THE_OSD_NODE - (SPACE_ALLOCATED_FOR_OTHER_DAEMONS (in Bytes))

SPACE_ALLOCATED_FOR_OTHER_DAEMONS 可能包括以下守护进程空间分配：

例如，如果节点有 24 个 OSD 且具有 251 GB RAM 空间，则 osd_memory_target 为 7860684936。

最终目标反映在带有选项的配置数据库中。您可以从 ceph orch ps 输出的 MEM LIMIT 列下查看各个守护进程使用的限值和当前内存。

[ceph: root@host01 /]# ceph config set mgr mgr/cephadm/autotune_memory_target_ratio 0.2

您可以为存储集群中的 OSD 手动设置特定内存目标。

[ceph: root@host01 /]# ceph config set osd.123 osd_memory_target 7860684936

您可以为存储集群中的 OSD 主机手动设置特定内存目标。

ceph config set osd/host:HOSTNAME osd_memory_target TARGET_BYTES

[ceph: root@host01 /]# ceph config set osd/host:host01 osd_memory_target 1000000000

ceph orch host label add HOSTNAME _no_autotune_memory

您可以通过禁用 autotune 选项并设置特定内存目标，从内存自动调整 OSD 中排除。

[ceph: root@host01 /]# ceph config set osd.123 osd_memory_target_autotune false
[ceph: root@host01 /]# ceph config set osd.123 osd_memory_target 16G

MDS 服务器将其元数据保留在一个单独的存储池中（名为 cephfs_metadata），并且是 Ceph OSD 的用户。对于 Ceph 文件系统，MDS 服务器必须支持整个 Red Hat Ceph Storage 集群，而不支持存储集群中的单个存储设备，因此它们的内存要求可能会非常显著，特别是当工作负载包含小时时，数据元数据的比例更大。

例如，将 mds_cache_memory_limit 设置为 2000000000

ceph_conf_overrides:
  osd:
    mds_cache_memory_limit=2000000000

网络配置对于构建高性能 Red Hat Ceph Storage 集群至关重要。Ceph 存储集群不代表 Ceph 客户端执行请求路由或分配请求。相反，Ceph 客户端直接向 Ceph OSD 守护进程发出请求。Ceph OSD 代表 Ceph 客户端执行数据复制，这意味着复制和其他因素对 Ceph 存储集群的网络造成额外的负载。

Ceph 有一个网络配置要求适用于所有守护进程。Ceph 配置文件必须为每个守护进程指定 host。

一些部署实用程序（如 cephadm ）会为您创建一个配置文件。如果部署实用程序为您设置这些值，则不要设置这些值。

所有 Ceph 集群都必须使用公共网络。但是，除非指定了内部集群网络，Ceph 会假定有一个公共网络。Ceph 可以只使用公共网络运行，但对于大型存储集群，如果您有一个私有的专用网络用于处理与集群相关的网络流量，则性能会显著提升。

要支持两个网络，每个 Ceph 节点都需要有一个以上的网络接口卡(NIC)。

需要考虑操作两个独立网络的原因有很多：

不需要网络配置设置。Ceph 可只用于公共网络，假定在运行 Ceph 守护进程的所有主机上都配置了公共网络。但是，Ceph 允许您建立更加具体的标准，包括用于公共网络的多个 IP 网络和子网掩码。您还可以建立一个单独的集群网络来处理 OSD 心跳、对象复制和恢复流量。

不要将您在配置中设置的 IP 地址与面向公共的 IP 地址网络客户端混淆。典型的内部 IP 网络通常为 192.168.0.0 或 10.0.0.0。

当配置网络时，您可以重启集群或重启每个守护进程。Ceph 守护进程动态绑定，因此如果更改网络配置，不必一次重启整个集群。

messenger 是 Ceph 网络层实施。红帽支持两种 messenger 类型：

在 Red Hat Ceph Storage 4 及更高版本中，sync 是默认的 mesenger 类型。要更改 messenger 类型，请在 Ceph 配置文件的 [global] 部分中指定 ms_type 配置设置。

要配置 Ceph 网络，请在 cephadm shell 中使用 config set 命令。请注意，您在网络配置中设置的 IP 地址与网络客户端可能用来访问您的服务的面向公共 IP 地址不同。

Ceph 可只在一个公共网络中完美地正常工作。但是，Ceph 允许您建立更加具体的标准，包括用于公共网络的多个 IP 网络。

您还可以建立一个单独的私有集群网络来处理 OSD 心跳、对象复制和恢复流量。有关专用网络的更多信息，请参阅配置专用网络。

公共网络配置允许您为公共网络定义 IP 地址和子网。

当用户想将 Ceph 监控守护进程放在属于多个网络子网的主机上时，需要配置多个公共网络到集群。用法示例是在 OpenShift Data Foundation 的 Metro DR 中用于 Advanced Cluster Management (ACM)的扩展集群模式。

您可以在 bootstrap 过程中将多个公共网络配置为集群，并在 bootstrap 完成后配置。

不需要网络配置设置。Ceph 假设所有主机都在一个公共网络中，除非您专门配置集群网络，也称为私有网络。

如果您创建集群网络，OSD 会通过集群网络路由心跳、对象复制和恢复流量。与使用单个网络相比，这可以提高性能。

要分配集群网络，请将 --cluster-network 选项与 cephadm bootstrap 命令一起使用。您指定的集群网络必须使用 CIDR 标记（如 10.90.90.0/24 or fe80::/64）定义子网。

您还可以在 boostrap 后配置 cluster_network。

默认情况下，Red Hat Ceph Storage 守护进程使用 TCP 端口 6800-​7100 与集群中的其他主机进行通信。您可以验证主机的防火墙是否允许连接这些端口。

如需更多信息，请参阅防火墙的文档。

您可以通过引入 messenger 版本 2 协议，通过网络启用所有 Ceph 流量的加密。me senger v2 的安全模式设置加密 Ceph 守护进程和 Ceph 客户端之间的通信，从而为您提供端到端加密。

Ceph 守护进程绑定到多个端口，允许旧旧 v1- 兼容新的 v2 兼容 Ceph 客户端，以连接同一存储集群。Ceph 客户端或其他 Ceph 守护进程连接到 Ceph Monitor 守护进程将先尝试使用 v2 协议（如果可能），但若不可能，则使用旧的 v1 协议。默认情况下，启用 messenger 协议 v1 和 v2。新的 v2 端口为 3300，旧的 v1 端口默认为 6789。

默认情况下，Ceph OSD 绑定到从 6800 端口开始的 Ceph 节点上第一个可用端口。确保对于节点上运行的每个 OSD，至少打开从端口 6800 开始的四个端口：

端口特定于节点。但是，如果进程重启并且绑定端口没有释放绑定端口，您可能需要打开比该 Ceph 节点上运行的端口所需的端口数量。当守护进程失败并重启而不释放端口，以便重启的守护进程绑定到新端口时，请考虑打开一些额外的端口。另外，请考虑在每个 OSD 节点上打开 6800-​7300 端口范围。

如果设置了单独的公共和集群网络，您必须同时为公共网络和集群网络添加规则，因为客户端将使用公共网络连接，其他 Ceph OSD 守护进程将使用集群网络进行连接。

如果将集群网络放在另一个区中，请根据需要在该区中打开端口。

了解如何配置 Ceph monitor 是构建可靠的 Red Hat Ceph Storage 集群的重要部分。所有存储集群都至少有一个监控器。Ceph 监控器配置通常保持一致性，但您可以在存储集群中添加、删除或替换 Ceph Monitor。

Ceph 监视器维护集群映射的"主副本"。这意味着，Ceph 客户端可以通过连接到一个 Ceph 监视器并检索当前 cluster map 来确定所有 Ceph 监视器和 Ceph OSD 的位置。

在 Ceph 客户端可以从 Ceph OSD 读取或写入到 Ceph OSD 之前，它们必须首先连接到 Ceph monitor。使用 cluster map 的当前副本和 CRUSH 算法时，Ceph 客户端可以计算任何对象的位置。计算对象位置的功能允许 Ceph 客户端直接与 Ceph OSD 通信，这是 Ceph 高可扩展性和性能的一个重要方面。

Ceph Monitor 的主要角色是维护集群映射的主副本。Ceph 监控程序也提供身份验证和日志记录服务。Ceph 监视器将监控服务中的所有更改写入单个 Paxos 实例，Paxos 会将更改写入到键值存储，以实现强一致性。Ceph monitor 可以在同步操作期间查询 cluster map 的最新版本。Ceph Monitor 利用键值存储的快照和迭代器（使用 rocksdb 数据库）来执行存储范围的同步。

集群映射不同映射的一个组合，包括 monitor 映射、OSD 映射和放置组映射。集群映射跟踪多个重要事件：

例如，当集群状态有重大改变时，Ceph OSD 会停机时，放置组将进入降级状态，以此类推。集群映射会更新，以反映集群的当前状态。此外，Ceph 监控器也维护了群集之前状态的历史记录。monitor 映射、OSD 映射和放置组映射各自维护其映射版本的历史记录。每个版本称为一个 epoch。

运行 Red Hat Ceph Storage 集群时，要跟踪这些状态是集群管理的一个重要部分。

集群将通过单一监控器运行。但是，如果只有一个监控器，则代表有单一故障点。为确保生产 Ceph 存储群集中的高可用性，可运行具有多个监控器的 Ceph，因此当一个控制器出现故障时不会造成整个存储群集故障。

当 Ceph 存储集群运行多个 Ceph Monitor 以实现高可用性时，Ceph Monitor 使用 Paxos 算法来建立与主集群映射相关的共识。共识需要大多数运行的监控器建立一个仲裁（quorum）以达成对集群映射的共识。例如，1; 2 out of 3; 3 out of 5; 4 out of 6; 等

红帽建议运行至少有三个 Ceph Monitor 的生产环境 Red Hat Ceph Storage 集群，以确保高可用性。运行多个监视器时，您可以指定必须成为存储集群成员的初始监控器，才能建立仲裁。这可减少存储集群在线所需的时间。

[mon]
mon_initial_members = a,b,c

将监控设置添加到 Ceph 配置文件时，您需要了解 Ceph 监控的一些架构方面。在发现集群中的另一个 Ceph monitor 时，Ceph 为 Ceph 监控器实施严格的一致性要求。Ceph 客户端和其他 Ceph 守护进程使用 Ceph 配置文件来发现 monitor，monitor 使用 monitor 映射(monmap )而不是 Ceph 配置文件互相发现。

在发现 Red Hat Ceph Storage 集群中的其他 Ceph 监控器时，Ceph Monitor 始终指 monitor map 的本地副本。使用 monitor 映射而不是 Ceph 配置文件可以避免会破坏集群的错误。例如，在指定监控地址或端口时 Ceph 配置文件中的拼写错误。由于 monitor 使用 monitor map 进行发现，并且它们与客户端和其他 Ceph 守护进程共享 monitor 映射，monitor 映射为 monitor 提供严格保证其共识有效。

如果 Ceph 监控通过 Ceph 配置文件而不是监视器映射发现相互发现，它将带来额外的风险，因为 Ceph 配置文件没有被自动更新并分发。Ceph 监控可能会意外地使用旧的 Ceph 配置文件，无法识别 Ceph monitor，无法承担仲裁状态，或者开发 Paxos 无法准确确定系统当前状态的情况。

在大多数配置和部署情形中，部署 Ceph 的工具（如 cephadm ）可能会为您生成 monitor 来引导 Ceph 监视器。

Ceph 监控需要一些显式设置：

如果 Ceph 配置文件中尚未配置 DNS 和 monitor 地址，则 Ceph Monitor 的裸机监控设置包括每个 monitor 的主机名。默认情况下，Ceph 监控在端口 6789 和 3300 上运行。

您可以使用以下命令设置或读取存储集群配置选项。

这里，WHO 参数可以是项的名称或一个 Ceph 守护进程， OPTION 是一个配置文件，VALUE 可以是 true 或 false。

ceph cephadm set-extra-ceph-conf

每个 Red Hat Ceph Storage 集群都有一个唯一标识符(fsid)。如果指定，它通常出现在配置文件的 [global] 部分中。部署工具通常会生成 fsid 并将其存储在 monitor 映射中，因此该值可能不会出现在配置文件中。通过 fsid，可以在同一硬件上为多个集群运行守护进程。

Ceph 提供了 Ceph 监视器存储数据的默认路径。

Ceph 监控器经常调用 fsync() 函数，这可能会影响 Ceph OSD 工作负载。

Ceph 监视器将其数据存储为键值对。使用数据存储可防止恢复 Ceph 监视器通过 Paxos 运行损坏版本，而且它可在一个原子批处理中实现多次修改操作，以及其他优势。

当 Red Hat Ceph Storage 集群接近其最大容量时（通过 mon_osd_full_ratio 参数显示），Ceph 会阻止您写入或读取 Ceph OSD 的安全措施，以防止数据丢失。因此，使一个生产环境的 Red Hat Ceph Storage 集群接近其全满比率是一个不好的做法，因为它降低了高可用性。默认全满比率为 .95 或 95% 的容量。对于具有多个 OSD 的测试集群来说，这是一个非常积极的设置。

测试集群的常见场景涉及系统管理员从 Red Hat Ceph Storage 集群中删除 Ceph OSD，以观察集群重新平衡。然后，删除另一个 Ceph OSD，直到 Red Hat Ceph Storage 集群最终达到完全的比例并锁定。

理想情况下，您要规划一系列 Ceph OSD 失败的情况，集群可以在不立即替换这些 Ceph OSD 的情况下恢复到 active + clean 状态。您可以运行状态为 active + degraded 的集群，但这对正常操作并不是一个理想的状态。

下图显示了一个简化的 Red Hat Ceph Storage 集群，其中包含每个主机有一个 Ceph OSD 的 33 Ceph 节点，每个 Ceph OSD 守护进程从中读取并写入 3TB 驱动器。因此，这一 Red Hat Ceph Storage 集群具有最大 99TB 的实际容量。当 mon osd full ratio 为 0.95 时，如果 Red Hat Ceph Storage 集群剩余的容量降到只有 5TB 时，集群将不再允许 Ceph 客户端读取和写入数据。因此，Red Hat Ceph Storage 集群的操作容量为 95 TB，而不是 99 TB。

在这样的集群中，一个或多个 OSD 无法正常使用。较为频繁但合理的方案涉及机架的路由器或电源故障，例如同时导致多个 OSD 下线，例如 OSDs 7-12。在这种情况下，保持集群正常运行并处于 active + clean 状态仍会为您带来更大益处，即使这需要在短时间内添加具有额外 OSD 的主机。如果您的容量利用率太高，可能不会丢失数据，但您仍然可能会牺牲数据可用性，同时在故障域内解决集群的容量利用率超过完整的比例。因此，红帽建议至少使用一些最小容量规划。

识别集群的两个值：

要确定集群中的 OSD 的平均容量，请将集群的总容量除以集群中的 OSD 数量。考虑将这个数量乘以您希望在正常操作期间同时出现故障的 OSD 数量（相对较小的数）。最后，通过满比例将集群的容量乘以达到最大操作容量。然后，从 OSD 中减去您希望无法达到合理的全满比率的 OSD 的数据量。重复处理数量较高的 OSD 故障（例如，一个 OSD 机架），以达到接近的全满比率的合理数量。

Ceph 监视器通过要求来自每个 OSD 的报告以及从 OSD 接收关于其邻居 OSD 状态的报告来了解集群。Ceph 为 monitor 和 OSD 之间的交互提供了合理的默认设置，但您可以根据需要修改它们。

当您使用多个监控器运行生产集群时，每个 monitor 会检查邻居监视器是否有最新版本的 cluster map。例如，一个邻居监视器中的映射，其一个或多个 epoch 号高于即时监视器映射中当前 epoch 的数值。定期，集群中的一个监视器可能位于其他 monitor 后，它必须离开仲裁，同步来检索有关集群的最新信息，然后重新加入仲裁。

这些角色使领导能够将同步任务委派给提供程序，从而防止同步请求过载，并提高性能。在下图中，请求者已了解到它已位于其他 monitor 后。请求者要求领导要同步，并且领导者告诉请求者与提供程序同步。

同步完成后，Ceph 需要在集群中修剪。修剪要求放置组处于 active + clean 状态。

Ceph 守护进程将关键消息传递到彼此，这必须在守护进程到达超时阈值前进行处理。如果 Ceph 监视器中的时钟没有同步，则可以导致一些异常。

例如：

时钟偏移可能仍然可以通过 NTP 发现，即使差异尚未有害。Ceph 时钟偏移和时钟偏移警告可能会触发，即使 NTP 维护合理的同步级别。在这种情况下，可以容忍时钟偏移。但是，很多因素，如工作负载、网络延迟、配置为默认超时，其他同步选项会影响可接受的时钟偏移级别，而不影响 Paxos 保证。

cephx 协议默认启用。加密身份验证具有一些计算成本，尽管它们通常很低。如果连接了客户端和服务器的网络环境被视为安全性，并且您无法负担身份验证计算成本，您可以禁用它。在部署 Ceph 存储集群时，部署工具将创建 client.admin 用户和密钥环。

启用 cephx 后，Ceph 将在默认搜索路径中查找密钥环，其中包括 /etc/ceph/$cluster.$name.keyring。您可以通过在 Ceph 配置文件的 [global] 部分添加 keyring 选项来覆盖该位置，但不建议这样做。

执行以下步骤，在禁用身份验证的集群中启用 cephx。如果您或部署实用程序生成了密钥，您可以跳过与生成密钥相关的步骤。

以下流程描述了如何禁用 Cephx。如果您的集群环境相对安全，您可以降低运行身份验证的计算费用。

但是，在设置或故障排除过程中可能会更容易地禁用身份验证。

当您运行 Ceph 并启用了身份验证时，ceph 管理命令和 Ceph 客户端需要身份验证密钥来访问 Ceph 存储集群。

向 ceph 管理命令和客户端提供这些密钥的最常见方式是在 /etc/ceph/ 目录下包含 Ceph 密钥环。文件名通常是 ceph.client.admin.keyring 或 $cluster.client.admin.keyring。如果您在 /etc/ceph/ 目录下包含密钥环，则不需要在 Ceph 配置文件中指定 keyring 条目。

要做到这一点，请执行以下命令：

# scp USER@HOSTNAME:/etc/ceph/ceph.client.admin.keyring /etc/ceph/ceph.client.admin.keyring

将 USER 替换为主机上的用户名，使用 client.admin 键，将 HOSTNAME 替换为该主机的主机名。

您可以使用 key 设置在 Ceph 配置文件中（不推荐）指定密钥本身，或使用 keyfile 设置来指定到密钥文件的路径。

管理用户或部署工具可能会像生成用户密钥环一样生成守护进程密钥环。默认情况下，Ceph 将守护进程密钥环存储在其数据目录中。默认密钥环位置，以及守护进程正常工作所需的功能。

守护进程数据目录位置默认为表单的目录：

/var/lib/ceph/$type/CLUSTER-ID

/var/lib/ceph/osd/ceph-12

您可以覆盖这些位置，但不推荐进行。

Ceph 提供精细的控制，您可以为客户端和 Ceph 之间的服务消息启用或禁用签名。您可以为 Ceph 守护进程之间的消息启用或禁用签名。

当您创建池并为池设置放置组数量时，Ceph 在不特别覆盖默认值时会使用默认值。

您可以在运行池命令时设置这些值。

默认情况下，Ceph 生成 3 个对象副本。如果要将对象的 4 个副本设置为默认值，一个主和三个副本，重新设置默认值，如 osd_pool_default_size 所示。如果要允许 Ceph 在降级状态写入副本数，将 osd_pool_default_min_size 设置为比 osd_pool_default_size 值小的数字。

[ceph: root@host01 /]# ceph config set global osd_pool_default_size 4  # Write an object 4 times.
[ceph: root@host01 /]# ceph config set global osd_pool_default_min_size 1  # Allow writing one copy in a degraded state.

确定您有实际的放置组数量。红帽建议每个 OSD 大约 100 个。例如，OSD 的总数乘以 100 的倍数并除以副本数（osd_pool_default_size）。对于 10 个 OSD 和 osd_pool_default_size = 4，我们建议的值为 (100 * 10)/ 4 = 250。

[ceph: root@host01 /]# ceph config set global osd_pool_default_pg_num 250
[ceph: root@host01 /]# ceph config set global osd_pool_default_pgp_num 250

所有 Ceph 集群都有一个配置，它定义：

部署工具（如 cephadm ）通常会为您创建初始 Ceph 配置文件。但是，如果您想在不使用部署工具的情况下引导集群，您可以自己创建一个。

为方便起见，每个守护进程都有一系列默认值。许多由 ceph/src/common/config_opts.h 脚本设置。您可以通过 Ceph 配置文件或运行时覆盖这些设置，方法是使用 monitor tell 命令，或直接连接到 Ceph 节点上的守护进程套接字。

除了生成多个对象副本外，Ceph 还能通过清理放置组来确保数据完整性。Ceph 清理与对象存储层上的 fsck 命令类似。

对于每个放置组，Ceph 都会生成所有对象的目录，并比较每个主对象及其副本，以确保缺少对象或不匹配。

轻度清理(每日)会检查对象大小和属性。深度刮除（每周）读取数据并使用 checksum 来确保数据完整性。

清理对于保持数据完整性非常重要，但可能会降低性能。调整以下设置以增加或减少清理操作。

将 Ceph OSD 添加到集群或从集群中删除时，CRUSH 算法会通过将放置组移到 Ceph OSD 或从中移出来重新平衡集群。迁移放置组和包含的对象可以大大降低集群操作性能。为保持操作性能，Ceph 会使用"回填"进程执行此迁移，这使 Ceph 将回填操作设置为比读取或写入数据的请求较低优先级。

当集群启动或 Ceph OSD 意外终止并重启时，OSD 在出现写入操作前开始与其他 Ceph OSD 的对等。

如果 Ceph OSD 崩溃然后又恢复在线，通常它将与其他 Ceph OSD 同步，包含 PG 中最新版本的对象。发生这种情况时，Ceph OSD 进入恢复模式并寻求数据的最新副本，并使其映射重新变为最新。根据 Ceph OSD 停机的时长，OSD 对象和放置组可能会显著不同步。另外，如果故障域停止（例如，一个机架出现问题），则在恢复过程中可能出现多个 Ceph OSD 同时上线的问题。这样可使恢复过程消耗和大量资源。

为保持可操作的性能，Ceph 对恢复请求、线程数和对象块大小（允许 Ceph 处于降级状态）执行恢复。

完成初始 Ceph 配置后，您可以部署并运行 Ceph。当您执行 ceph health 或 ceph -s 等命令时，Ceph Monitor 会报告 Ceph Storage 集群的当前状态。Ceph Monitor 通过从每个 Ceph OSD 守护进程要求报告来了解 Ceph 存储集群，并通过从 Ceph OSD 守护进程接收报告来了解其邻居 Ceph OSD 守护进程的状态。如果 Ceph Monitor 没有接收报告，或者它收到 Ceph 存储集群中更改的报告，Ceph 监控器会更新 Ceph 集群映射的状态。

Ceph 为 Ceph Monitor 和 OSD 交互提供合理的默认设置。但是，您可以覆盖默认值。以下小节论述了 Ceph 监控器和 Ceph OSD 守护进程如何进行交互，以满足监控 Ceph 存储集群的目的。

每个 Ceph OSD 守护进程会每 6 秒检查其他 Ceph OSD 守护进程的心跳。要更改心跳间隔，请在运行时更改值：

ceph config set osd osd_heartbeat_interval TIME_IN_SECONDS

[ceph: root@host01 /]# ceph config set osd osd_heartbeat_interval 60

如果邻居 Ceph OSD 守护进程没有在 20 秒宽限期内发送心跳数据包，Ceph OSD 守护进程可能会认为邻居 Ceph OSD 守护进程 down。它可以报告回 Ceph monitor，它会更新 Ceph cluster map。要更改宽限期，请在运行时设置值：

ceph config set osd osd_heartbeat_grace TIME_IN_SECONDS

[ceph: root@host01 /]# ceph config set osd osd_heartbeat_grace 30

默认情况下，来自不同主机的两个 Ceph OSD 守护进程必须报告给另一个 Ceph OSD 守护进程处于 down 状态的 Ceph 监控器，然后确认报告的 Ceph OSD 守护进程为 down。

但是，所有 OSD 报告失败的可能性都位于具有错误交换机的机架中，导致 OSD 之间的连接问题。

为避免"错误警报"，Ceph 会将故障报告为类似 lagy 的"subcluster"的代理。虽然情况并非总是如此，但可能帮助管理员对性能不良的系统子集进行本地化处理。

Ceph 使用 mon_osd_reporter_subtree_level 设置，将 peer 分到"cluster"的常用级别类型。

默认情况下，仅需要两个来自不同子树的报告，才能报告另一个 Ceph OSD 守护进程为 down。管理员可以通过在运行时设置 mon_osd_min_down_reporters 和 mon_osd_reporter_subtree_level 的值，修改报告者的数量，将用于报告一个 Ceph OSD Daemon down 所需的唯一的子树和祖先类型改为 Ceph Monitor：

ceph config set mon mon_osd_min_down_reporters NUMBER

[ceph: root@host01 /]# ceph config set mon mon_osd_min_down_reporters 4

ceph config set mon mon_osd_reporter_subtree_level CRUSH_ITEM

[ceph: root@host01 /]# ceph config set mon mon_osd_reporter_subtree_level host
[ceph: root@host01 /]# ceph config set mon mon_osd_reporter_subtree_level rack
[ceph: root@host01 /]# ceph config set mon mon_osd_reporter_subtree_level osd

如果 Ceph OSD 守护进程无法与其 Ceph 配置文件或 cluster map 中定义的任何 Ceph OSD 守护进程的对等点，它会每 30 秒对集群 map 的最新副本发出 Ceph Monitor 命令。您可以通过在运行时设置值来更改 Ceph 监控心跳间隔：

ceph config set osd osd_mon_heartbeat_interval TIME_IN_SECONDS

[ceph: root@host01 /]# ceph config set osd osd_mon_heartbeat_interval 60

如果 Ceph OSD 守护进程没有报告到 Ceph 监控器，Ceph Monitor 会在 mon_osd_report_timeout 之后标记 Ceph OSD 守护进程，即 900 秒。当可报告事件（如故障）时，Ceph OSD 守护进程会向 Ceph 监控器发送报告，这是放置组统计的变化、up_thru 或在 5 秒内引导时发生的变化。

您可以通过在运行时设置 osd_mon_report_interval 值来更改 Ceph OSD 守护进程最小报告间隔：

ceph config set osd osd_mon_report_interval TIME_IN_SECONDS

要获取、设置和验证配置，您可以使用以下示例：

[ceph: root@host01 /]# ceph config get osd osd_mon_report_interval
5
[ceph: root@host01 /]# ceph config set osd osd_mon_report_interval 20
[ceph: root@host01 /]# ceph config dump | grep osd

global                  advanced  osd_pool_default_crush_rule                  -1
  osd                   basic     osd_memory_target                            4294967296
  osd                   advanced  osd_mon_report_interval                      20