2.6. Ceph 输入/输出操作
Ceph 客户端从 Ceph 监控器检索"Cluster map"，绑定至池，并在池中 PG 中的对象上执行输入/输出(I/O)。池的 CRUSH 规则集和 PG 数量是 Ceph 如何放置数据的主要因素。借助最新版本的 cluster map，客户端知道集群中的所有 monitor 和 OSD，以及它们的当前状态。然而，客户端不知道对象位置。
客户端唯一需要的输入是对象 ID 和池名称。很简单：Ceph 将数据存储在指定的池中。当客户端希望将指定对象存储在池中时，它会取对象名称、哈希代码、池中 PG 数量和池名称作为输入；然后，CRUSH（可扩展哈希下的复制）计算 PG 的 ID，以及 PG 的 Primary OSD。
Ceph 客户端使用下列步骤来计算 PG ID。
-
客户端输入池名称和对象 ID。例如
pool = liverpool和object-id = john。 - CRUSH 取对象 ID 并散列它。
-
CRUSH 计算 PG 数的哈希模数，以获取 PG ID。例如：
58。 - CRUSH 计算与 PG ID 对应的Primary OSD。
-
客户端获取给定池名称的池 ID。例如，池"liverpool"是池号
4。 -
客户端将池 ID 前缀到 PG ID。例如：
4.58。 - 客户端通过直接与操作集合中的 Primary OSD 通信来执行对象操作，如写入、读取或删除。
在会话期间，Ceph 存储集群的拓扑和状态相对稳定。通过 librados 为 Ceph 客户端提供计算对象位置的能力要比要求客户端通过 chatty 会话查询存储集群来进行每个读/写操作的查询。CRUSH 算法允许客户端计算对象 的存储 位置，并使 客户端能够直接联系操作集合中的Primary OSD， 以在对象中存储或检索数据。由于高级规模的集群具有数千个 OSD，通过客户端和 Ceph OSD 之间的订阅来联网并不是个大问题。如果集群状态发生变化，客户端只需从 Ceph monitor 请求对 cluster map 的更新。
对于 Red Hat Ceph Storage 2 及更早的发行版本，当集群映射增长过大时，非常大的集群中的守护进程可能会遇到较低的性能。例如，具有 10000 个 OSD 的群集可能每个 OSD 有 100 个 PG，从而能高效地为群集映射分发数据且有多个 epoch。因此，守护进程将在带有非常大集群的 Red Hat Ceph Storage 2 中使用更多 CPU 和 RAM。对于 Red Hat Ceph Storage 3 及更新的版本，守护进程会像 Red Hat Ceph Storage 2 及更早的版本一样接收集群的当前状态。但是，Ceph Manager（ceph-mgr守护进程）现在处理 PG 上的查询，从而显著提高性能。
红帽建议在具有数千 OSD 的大型集群中使用 Red Hat Ceph Storage 3 及更新的版本。
