【存储架构】CEPH架构 | 架构师研究会

语言 Chinese, Simplified

SEO Title

CEPH存储集群

Ceph提供了一个基于RADOS的可无限扩展的Ceph存储集群，RADOS是一种可靠的分布式存储服务，它使用每个节点中的智能来保护其存储的数据并将这些数据提供给客户端。有关RADOS的简要解释，请参阅Sage Weil的“RADOS对象存储”博客文章，有关RADOS详细解释，请参见RADOS-Petabyte规模存储集群的可扩展、可靠的存储服务。

Ceph存储集群由多种类型的守护程序组成：

Ceph监视器维护集群映射的主副本，并将其提供给Ceph客户端。Ceph集群中存在多个监控器可确保在某个监控器守护进程或其主机出现故障时可用。

Ceph OSD守护程序检查自己的状态和其他操作系统的状态，并向监视器报告。

Ceph管理器充当监视、编排和插件模块的端点。

当CephFS用于提供文件服务时，Ceph元数据服务器（MDS）管理文件元数据。

存储集群客户端和Ceph OSD守护程序使用CRUSH算法来计算有关数据位置的信息。CRUSH算法的使用意味着客户端和操作系统不受中央查找表的限制。Ceph的高级功能包括通过librados到Ceph存储集群的本地接口，以及在librados之上构建的许多服务接口。

存储数据

Ceph存储集群从Ceph客户端接收数据——无论数据来自Ceph块设备、Ceph对象存储、Ceph文件系统，还是您使用librados创建的自定义实现。Ceph存储集群接收的数据存储为RADOS对象。每个对象都存储在对象存储设备上（也称为“OSD”）。Ceph操作系统控制存储驱动器上的读、写和复制操作。默认的BlueStore后端以类似数据库的方式存储对象。

Ceph OSD守护程序将数据作为对象存储在平面名称空间中。这意味着对象不存储在目录层次结构中。对象具有标识符、二进制数据和由名称/值对组成的元数据。Ceph客户端决定对象数据的语义。例如，CephFS使用元数据来存储文件属性，如文件所有者、创建日期和上次修改日期。

笔记
对象ID在整个集群中是唯一的，而不仅仅是在本地文件系统中。

可扩展性和高可用性

在传统体系结构中，客户端与一个集中式组件进行通信。这个集中式组件可能是网关、代理、API或门面。这种集中式组件充当复杂子系统的单一入口点。依赖于这种集中式组件的体系结构只有一个故障点，并限制了性能和可扩展性。如果集中式组件出现故障，则整个系统将不可用。

Ceph消除了这个集中式组件。这使客户端能够直接与Ceph操作系统交互。Ceph操作系统在其他Ceph节点上创建对象副本，以确保数据安全和高可用性。Ceph还使用一组监控器来确保高可用性。为了消除集中，Ceph使用了一种名为CRUSH的算法。

CRUSH介绍

Ceph客户端和Ceph OSD守护程序都使用CRUSH算法来计算有关对象位置的信息，而不是依赖于中央查找表。CRUSH提供了比旧方法更好的数据管理机制，并且CRUSH通过将工作分配给集群中的所有OSD守护进程以及与它们通信的所有客户端来实现大规模扩展。CRUSH使用智能数据复制来确保恢复能力，这更适合于超规模存储。以下各节提供了有关CRUSH如何工作的更多详细信息。有关CRUSH的深入学术讨论，请参阅CRUSH-复制数据的受控、可扩展、去中心化放置。

聚类图（CLUSTER MAP）

为了使Ceph集群正常工作，Ceph客户端和Ceph操作系统必须具有关于集群拓扑的当前信息。当前信息存储在“集群地图”中，实际上它是五个地图的集合。构成集群地图的五个地图是：

监视器映射：包含每个监视器的群集fsid、位置、名称、地址和TCP端口。监视映射指定当前历元、创建监视映射的时间以及上次修改监视映射的日期。要查看监视器映射，请运行ceph-mon dump。
OSD映射：包含集群fsid、创建OSD映射的时间、OSD映射最后一次修改的时间、池列表、副本大小列表、PG编号列表以及操作系统及其状态列表（例如，up、in）。要查看OSD地图，请运行ceph-OSD-dump。
PG贴图：包含PG版本、时间戳、上一个OSD贴图历元、完整比例以及每个放置组的详细信息。这包括PG ID、Up Set、Acting Set、PG的状态（例如，active+clean）以及每个池的数据使用统计信息。
CRUSH映射：包含存储设备列表、故障域层次结构（例如，设备、主机、机架、行、房间）以及存储数据时遍历层次结构的规则。要查看CRUSH映射，请运行ceph-osd-getcrushmap-o｛filename｝，然后通过运行crushtol-d｛comp-crushmap filename｝-o｛deco-crushmap filename｝来对其进行反编译。使用文本编辑器或cat查看反编译的地图。
MDS映射：包含当前MDS映射epoch、创建映射的时间以及上次更改的时间。它还包含用于存储元数据的池、元数据服务器列表以及哪些元数据服务器已启动。要查看MDS映射，请执行ceph-fs-dump。

每个映射都会维护其操作状态的更改历史记录。Ceph监视器维护集群映射的主副本。此主副本包括集群成员、集群状态、对集群的更改以及记录Ceph存储集群总体运行状况的信息。

高可用性监视器

Ceph客户端必须联系Ceph监视器并获取集群映射的当前副本，才能从Ceph集群读取数据或向其写入数据。

Ceph集群可能只使用一个监视器就能正常工作，但只有一个监视器的Ceph集群只有一个故障点：如果监视器坏了，Ceph客户端将无法从集群中读取数据或向集群中写入数据。

Ceph利用一组监控器来提高可靠性和容错性。但是，当使用监控器集群时，集群中的一个或多个监控器可能会由于延迟或其他故障而落后。Ceph通过要求多个监控器实例就集群的状态达成一致来减轻这些负面影响。为了在监控器之间建立关于集群状态的一致性，Ceph使用Paxos算法和大多数监控器（例如，一个仅包含一个监控器的集群中有一个监控器，两个包含三个监控器，三个包含五个监控器，四个包含六个监控器，依此类推）。

有关配置监视器的更多详细信息，请参阅监视器配置参考。

高可用性身份验证

Ceph使用cephx身份验证系统对用户和守护进程进行身份验证，并防止中间人攻击。

笔记
cephx协议不处理传输中的数据加密（例如SSL/TLS）或静止时的加密。

cephx使用共享密钥进行身份验证。这意味着客户端和监视集群都保留客户端密钥的副本。

cephx协议使各方可以在不泄露密钥副本的情况下向另一方证明其拥有密钥副本。这提供了相互身份验证，并允许集群确认（1）用户拥有密钥，（2）用户可以确信集群拥有密钥的副本。

正如在Scalability and High Availability中所述，Ceph在客户端和Ceph对象存储之间没有任何集中式接口。通过避免这种集中式接口，Ceph避免了这种集中式接口的瓶颈。但是，这意味着客户端必须与操作系统直接交互。Ceph客户端和操作系统之间的直接交互需要经过身份验证的连接。cephx身份验证系统建立并维持这些经过身份验证的连接。

cephx协议的操作方式类似于Kerberos。

用户调用Ceph客户端来联系监控器。与Kerberos不同，每个监视器都可以对用户进行身份验证并分发密钥，这意味着在使用cephx时没有单点故障，也没有瓶颈。监视器返回一个类似于Kerberos票证的身份验证数据结构。此身份验证数据结构包含用于获取Ceph服务的会话密钥。会话密钥本身使用用户的永久密钥进行加密，这意味着只有用户才能从Ceph监视器请求服务。然后，客户端使用会话密钥向监视器请求服务，监视器向客户端提供一个票证，该票证根据实际处理数据的操作系统验证客户端。Ceph监视器和操作系统共享一个秘密，这意味着客户端可以使用监视器提供的票证对集群中的任何OSD或元数据服务器进行身份验证。

与Kerberos票证一样，cephx票证也会过期。攻击者不能使用秘密获取的过期票证或会话密钥。这种形式的身份验证可以防止访问通信介质的攻击者以另一个用户的身份创建虚假消息，并防止攻击者更改另一用户的合法消息，只要用户的密钥在到期前没有泄露。

管理员必须先设置用户，然后才能使用cephx。在下图中，client.admin用户从命令行调用ceph-auth-get-or create-key来生成用户名和密钥。Ceph的auth子系统生成用户名和密钥，在监视器上存储一个副本，并将用户的机密传输回client.admin用户。这意味着客户端和监视器共享一个密钥。

笔记
client.admin用户必须以安全的方式向用户提供用户ID和密钥。

以下是客户端如何通过监视器进行身份验证。客户端将用户名传递给监视器。监视器生成一个会话密钥，该密钥使用与用户名关联的密钥进行加密。监视器将加密的票证传输到客户端。客户端使用共享密钥对有效载荷进行解密。会话密钥标识用户，并且这种标识行为将在会话期间持续。客户端为用户请求票证，并使用会话密钥对票证进行签名。监视器生成一个票证，并使用用户的密钥对其进行加密。加密的票证被传输到客户端。客户端解密票证，并使用它对集群中的操作系统和元数据服务器的请求进行签名。

cephx协议验证客户端和Ceph守护进程之间正在进行的通信。在初始身份验证之后，在客户端和守护进程之间发送的每条消息都会使用一个票证进行签名，该票证可以由监视器、操作系统和元数据守护进程进行验证。此票证通过使用客户端和守护进程之间共享的机密进行验证。

此身份验证仅保护Ceph客户端和Ceph守护进程之间的连接。身份验证没有扩展到Ceph客户端之外。如果用户从远程主机访问Ceph客户端，则cephx身份验证将不会应用于用户主机和客户端主机之间的连接。

有关配置详细信息，请参阅Cephx配置指南。

有关用户管理的更多信息，请参阅用户管理。

有关授权和身份验证之间的区别以及Cephx票证和会话密钥设置的逐步解释，请参阅Cephx身份验证协议的详细说明。

智能守护程序实现超规模(SMART DAEMONS ENABLE HYPERSCALE)

许多存储集群的一个功能是集中化接口，用于跟踪允许客户端访问的节点。这种集中式体系结构通过双重调度向客户端提供服务。在PB到EB的规模上，这种双重调度是一个重要的瓶颈。

Ceph避免了这个瓶颈：Ceph的OSD Daemons和Ceph客户端是集群感知的。与Ceph客户端一样，每个Ceph OSD守护程序都知道集群中的其他Ceph OSD Daemon。这使得Ceph OSD守护程序可以直接与其他Ceph OSD Daemon交互，也可以直接与Ceph监视器交互。具有集群意识使得Ceph客户端可以直接与Ceph OSD守护进程进行交互。

由于Ceph客户端、Ceph监视器和Ceph OSD守护进程直接相互交互，因此Ceph OSD后台进程可以利用Ceph集群中节点的聚合CPU和RAM资源。这意味着Ceph集群可以轻松执行具有集中式接口的集群难以执行的任务。Ceph节点利用更大集群的计算能力的能力提供了几个好处：

操作系统直接为客户端提供服务：网络设备只能支持有限数量的并发连接。由于Ceph客户端直接联系Ceph OSD守护进程，而无需首先连接到中央接口，因此相对于包括中央接口的存储冗余策略，Ceph可以提高性能并增加系统容量。Ceph客户端仅在需要时维护会话，并且仅使用特定的Ceph OSD守护进程来维护这些会话，而不是使用集中式接口。
OSD成员资格和状态：当Ceph OSD守护进程加入集群时，它们会报告自己的状态。在最低级别，Ceph OSD守护程序的状态是向上还是向下：这反映了Ceph OSD后台程序是否正在运行并能够为Ceph客户端请求提供服务。如果Ceph OSD Daemon已关闭并且位于Ceph存储集群中，则此状态可能表示Ceph OSD Daemon失败。如果Ceph OSD守护程序由于崩溃而未运行，则Ceph OSD Daemon无法通知Ceph监视器它已关闭。OSD定期向Ceph Monitor发送消息（在Luminous之前的版本中，这是通过MPGStats完成的，从Luminous版本开始，这是用MOSDBeacon完成的）。如果Ceph监视器在可配置的一段时间后没有收到此类消息，则会将OSD标记为关闭。然而，这种机制是一种故障保护机制。通常，Ceph OSD守护程序会确定相邻OSD是否关闭，并将其报告给Ceph监视器。这有助于使Ceph监视器成为轻量级进程。有关更多详细信息，请参阅监控操作系统和检测信号。
数据清理：为了保持数据一致性，Ceph OSD守护程序会清理RADOS对象。Ceph OSD守护进程将它们自己的本地对象的元数据与存储在其他操作系统上的这些对象的副本的元数据进行比较。清理以每个放置组为基础进行，发现对象大小不匹配，发现元数据不匹配，通常每天执行。Ceph OSD守护程序通过将对象中的数据逐位与它们的校验和进行比较来执行更深入的清理。深度清理发现驱动器上的坏扇区，而这些扇区是用轻度清理无法检测到的。有关配置清理的详细信息，请参阅数据清理。
复制：数据复制涉及Ceph客户端和Ceph OSD守护程序之间的协作。Ceph OSD守护程序使用CRUSH算法来确定对象副本的存储位置。Ceph客户端使用CRUSH算法来确定对象的存储位置，然后将对象映射到池和放置组，然后客户端查阅CRUSH映射以识别放置组的主OSD。

在识别出目标放置组之后，客户端将对象写入到所识别的放置组的主OSD中。然后，主OSD查阅其自己的CRUSH映射副本，以识别二级和三级OSD，将对象复制到这些二级和四级OSD中的放置组，确认对象已成功存储在二级和五级OSD内，并向客户端报告对象已成功存储。

通过执行此数据复制操作，Ceph OSD守护程序减轻了Ceph客户端复制数据的负担。

动态集群管理

在可扩展性和高可用性部分，我们解释了Ceph如何使用CRUSH、集群拓扑和智能守护进程来扩展和维护高可用性。Ceph设计的关键是自主、自我修复和智能的Ceph OSD精灵。让我们更深入地了解CRUSH是如何使现代云存储基础设施能够放置数据、重新平衡集群、自适应地放置和平衡数据以及从故障中恢复的。

关于游泳池

Ceph存储系统支持“池”的概念，池是用于存储对象的逻辑分区。

Ceph客户端从Ceph监视器检索集群映射，并将RADOS对象写入池。Ceph在池中放置数据的方式由池的副本大小或数量、CRUSH规则以及池中放置组的数量决定。

池至少设置以下参数：

对象的所有权/访问权
放置组的数量，以及
要使用的CRUSH规则。

有关详细信息，请参阅设置池值。

将PGS映射到osd

每个池中都有许多放置组（PG）。CRUSH动态地将PG映射到操作系统。当Ceph客户端存储对象时，CRUSH会将每个RADOS对象映射到一个PG。

这种RADOS对象到PG的映射实现了Ceph OSD守护程序和Ceph客户端之间的抽象和间接层。Ceph存储集群必须能够在内部拓扑发生变化时自适应地增长（或收缩）和重新分发数据。

如果Ceph客户端“知道”哪些Ceph OSD Daemon正在存储哪些对象，则Ceph客户端和Ceph OSD Daemon之间将存在紧密耦合。但是Ceph避免了任何这样的紧密耦合。相反，CRUSH算法将每个RADOS对象映射到放置组，然后将每个放置组映射到一个或多个Ceph OSD Daemon。这个“间接层”允许Ceph在新的Ceph OSD守护程序及其底层OSD设备上线时动态重新平衡。下图显示了CRUSH算法如何将对象映射到放置组，以及如何将放置组映射到操作系统。

客户端使用其集群映射副本和CRUSH算法来精确计算在读取或写入特定对象时将使用的OSD。

计算PG IDS

当Ceph客户端绑定到Ceph监视器时，它会检索最新版本的集群映射。当客户端配备了集群映射的副本时，它会知道集群中的所有监视器、操作系统和元数据服务器。然而，即使配备了最新版本的集群映射的副本，客户端也不知道任何关于对象位置的信息。

必须计算对象位置。

客户端只需要对象ID和池的名称即可计算对象位置。

Ceph将数据存储在命名池中（例如“利物浦”）。当客户端存储命名对象（例如，“john”、“paul”、“george”或“ringo”）时，它会使用对象名称、哈希代码、池中PG的数量和池名称来计算放置组。Ceph客户端使用以下步骤来计算PG ID。

客户端输入池名称和对象ID（例如：pool=“利物浦”和object ID=“约翰”）
Ceph散列对象ID。
Ceph计算散列，将PG的数量取模（例如：58），以获得PG ID。
Ceph使用池名称来检索池ID:（例如：“利物浦”=4）
Ceph将池ID预先设置为PG ID（例如：4.58）。

计算对象位置比在聊天会话中执行对象位置查询快得多。CRUSH算法允许客户端计算预期存储对象的位置，并使客户端能够联系主OSD来存储或检索对象。

对等和集合（PEERING AND SETS）

在前几节中，我们注意到Ceph OSD守护程序会检查彼此的心跳并向Ceph监视器报告。Ceph OSD守护进程也是“对等”的，这是使存储放置组（PG）的所有操作系统就该PG中所有RADOS对象（及其元数据）的状态达成一致的过程。Ceph OSD daemons向Ceph监视器报告对等失败。对等问题通常会自行解决；但是，如果问题仍然存在，您可能需要参阅“Peering Failure故障排除”部分。

笔记
对集群状态达成一致的PG还不一定拥有当前数据。

Ceph存储集群设计用于存储一个对象的至少两个副本（即大小=2），这是数据安全的最低要求。为了获得高可用性，Ceph存储集群应存储一个对象的两个以上副本（即大小=3和最小大小=2），以便它能够在保持数据安全的同时继续在降级状态下运行。

警告
尽管我们在这里说R2（带两个拷贝的复制）是数据安全的最低要求，但建议使用R3（带三个拷贝的拷贝的复制。
在足够长的时间线上，使用R2策略存储的数据将丢失。

如Smart Daemons Enable Hyperscale中的图表所述，我们并没有具体命名Ceph OSD Daemons（例如，OSD.0、OSD.1等），而是将它们称为Primary、Secondary等。按照惯例，Primary是代理集中的第一个OSD，并负责为其充当Primary的每个放置组协调对等过程。主OSD是给定放置组中唯一一个接受客户端启动的对对象的写入的OSD。

负责一个安置组的OSD集合称为代理集合。术语“作用集”可以指当前负责放置组的Ceph OSD守护程序，也可以指在某个时期负责特定放置组的Ceph OSD守护进程。

作为代理集一部分的Ceph OSD守护进程可能并不总是处于启动状态。当“代理集”中的OSD已设置时，它就是“设置集”的一部分。设置是一个重要的区别，因为当OSD失败时，Ceph可以将PG重新映射到其他Ceph OSD Daemon。

笔记
考虑一个包含osd.25、osd.32和osd.61的PG的假设动作集。第一个OSD（OSD.25）是主OSD。如果OSD失败，
辅助（OSD.32）将变为主要，OSD.25将从设置中删除。

再平衡

当您将Ceph OSD守护程序添加到Ceph存储集群时，集群映射将使用新的OSD进行更新。返回“计算PG ID”，这将更改集群映射。因此，它会更改对象的位置，因为它会更改计算的输入。下图描述了再平衡过程（尽管相当粗略，因为它对大型集群的影响要小得多），其中一些（但不是所有）PG从现有OSD（OSD 1和OSD 2）迁移到新OSD（OSD 3）。即使再平衡，CRUSH也是稳定的。许多放置组仍保持其原始配置，并且每个OSD都增加了一些容量，因此在重新平衡完成后，新OSD上不会出现负载峰值。

数据一致性

作为保持数据一致性和清洁度的一部分，Ceph操作系统还清理放置组中的对象。也就是说，Ceph操作系统将一个放置组中的对象元数据与其存储在其他操作系统中的放置组中副本进行比较。清理（通常每天执行）捕获OSD错误或文件系统错误，通常是硬件问题造成的。操作系统还通过逐位比较对象中的数据来执行更深层次的清理。深度清理（默认情况下每周执行一次）会在驱动器上发现在轻度清理中不明显的坏块。

有关配置清理的详细信息，请参阅数据清理。

擦除编码

擦除编码池将每个对象存储为K+M个块。它被划分为K个数据块和M个编码块。池被配置为具有K+M的大小，使得每个块被存储在动作集中的OSD中。块的等级被存储为对象的属性。

例如，可以创建擦除编码池以使用五个OSD（K+M=5）并维持其中两个的丢失（M=2）。

读写编码块

将包含ABCDEFGHI的对象NYAN写入池时，擦除编码函数只需将内容分为三部分，即可将内容拆分为三个数据块：第一部分包含ABC，第二部分包含DEF，最后一部分包含GHI。如果内容长度不是K的倍数，则内容将被填充。该函数还创建两个编码块：第四个使用YXY，第五个使用QGC。每个块都存储在动作集中的OSD中。块存储在具有相同名称（NYAN）但位于不同操作系统上的对象中。创建块的顺序必须保留下来，并作为对象（shard_t）的属性及其名称存储。块1包含ABC并存储在OSD5上，而块4包含YXY并存储在OS D3上。

当从擦除编码池中读取对象NYAN时，解码功能读取三个块：包含ABC的块1、包含GHI的块3和包含YXY的块4。然后，它将重建对象的原始内容ABCDEFGHI。解码功能被告知块2和5丢失（它们被称为“擦除”）。由于OSD4已出，因此无法读取块5。只要读取三个块，就可以调用解码函数：OSD2是最慢的，它的块没有被考虑在内。

中断的完整写入

在擦除编码池中，设置中的主OSD接收所有写入操作。它负责将有效载荷编码为K+M个块，并将它们发送到其他操作系统。它还负责维护放置组日志的权威版本。

在下图中，创建了一个擦除编码的放置组，其中K＝2，M＝1，并由三个OSD支持，两个用于K，一个用于M。放置组的作用集由OSD 1、OSD 2和OSD 3组成。对象已被编码并存储在OSD中：块D1v1（即数据块编号1，版本1）在OSD 1上，D2v1在OSD 2上，C1v1（即编码块编号1、版本1）位于OSD 3上。每个OSD上的放置组日志是相同的（即，历元1的1,1，版本1）。

OSD 1是主要的，从客户端接收WRITE FULL，这意味着有效载荷将完全替换对象，而不是覆盖其一部分。创建对象的版本2（v2）以覆盖版本1（v1）。OSD 1将有效载荷编码成三个块：D1v2（即数据块号1版本2）将在OSD 1上，D2v2在OSD 2上，C1v2（即编码块号1版2）在OSD 3上。每个块被发送到目标OSD，包括主OSD，主OSD除了处理写入操作和维护放置组日志的权威版本之外，还负责存储块。当OSD接收到指示其写入块的消息时，它还会在放置组日志中创建一个新条目来反映更改。例如，一旦OSD 3存储了C1v2，它就将条目1,2（即epoch 1，版本2）添加到其日志中。由于操作系统是异步工作的，一些块可能仍在运行中（如D2v2），而其他块则被确认并持久化到存储驱动器（如C1v1和D1v1）。

如果一切顺利，块会在作用集中的每个OSD上得到确认，日志的last_complete指针可以从1,1移动到1,2。

最后，可以删除用于存储对象的先前版本的块的文件：OSD 1上的D1v1、OSD 2上的D2v1和OSD 3上的C1v1。

但意外也会发生。如果OSD 1在D2v2仍在运行时发生故障，则对象的版本2被部分写入：OSD 3有一个块，但这不足以恢复。它丢失了两个块：D1v2和D2v2，并且擦除编码参数K=2，M=1要求至少有两个块可用于重建第三个块。OSD 4成为新的主日志，并且发现last_complete日志条目（即，在该条目之前的所有对象已知在先前动作集中的所有OSD上可用）是1，1，并且这将是新的权威日志的头。

在OSD 3上发现的日志条目1、2与OSD 4提供的新权威日志不同：它被丢弃，并且包含C1v2块的文件被删除。在擦除期间利用擦除编码库的解码功能重建D1v1块，并将其存储在新的主OSD 4上。

有关其他详细信息，请参阅擦除代码说明。

缓存分层

笔记
Reef中不赞成使用缓存分层。

缓存层为存储在后备存储层中的数据子集提供了更好的Ceph客户端I/O性能。高速缓存分层包括创建一个相对快速/昂贵的存储设备池（例如，固态驱动器），这些设备被配置为用作高速缓存层，以及一个由擦除编码或相对较慢/较便宜的设备组成的后备池，这些设备配置为用作经济的存储层。Ceph对象器处理对象的放置位置，分层代理确定何时将对象从缓存刷新到后备存储层。因此，缓存层和后备存储层对Ceph客户端是完全透明的。

有关更多详细信息，请参阅缓存分层。请注意，缓存层可能很棘手，现在不鼓励使用它们。

扩展CEPH

您可以通过创建名为“Ceph类”的共享对象类来扩展Ceph。Ceph动态加载存储在osd-class-dir目录中的.so类（即默认情况下为$libdir/rados-classes）。当您实现一个类时，您可以创建新的对象方法，这些方法能够调用Ceph对象存储中的本机方法，或者通过库合并或自己创建的其他类方法。

在写入时，Ceph类可以调用本机或类方法，对入站数据执行任何一系列操作，并生成Ceph将原子应用的结果写入事务。

在读取时，Ceph类可以调用本机或类方法，对出站数据执行任何一系列操作，并将数据返回给客户端。

Ceph类示例

用于呈现特定大小和宽高比图片的内容管理系统的Ceph类可以获取入站位图图像，将其裁剪为特定宽高比，调整其大小，并嵌入不可见的版权或水印，以帮助保护知识产权；然后，将生成的位图图像保存到对象存储中。

有关示例性实现，请参见src/objclass/objlass.h、src/fooclass.cc和src/barclass。

摘要

Ceph存储集群是动态的——就像一个活的有机体。然而，许多存储设备并没有完全利用典型商品服务器的CPU和RAM，Ceph做到了。从心跳到对等，再到重新平衡集群或从故障中恢复，Ceph从客户端（以及Ceph体系结构中不存在的集中式网关）卸载工作，并使用操作系统的计算能力来执行工作。在参考硬件建议和网络配置参考时，要了解上述概念，以了解Ceph如何利用计算资源。

CEPH协议

Ceph客户端使用本机协议与Ceph存储集群进行交互。Ceph将此功能打包到librados库中，以便您可以创建自己的自定义Ceph客户端。下图描述了基本体系结构。

本机协议和库

现代应用程序需要一个具有异步通信能力的简单对象存储接口。Ceph存储集群提供了一个具有异步通信功能的简单对象存储接口。该接口提供对整个集群中的对象的直接、并行访问。

池操作
快照和写入时拷贝克隆
读/写对象-创建或删除-整个对象或字节范围-附加或截断
创建/设置/获取/删除XATTR
创建/设置/获取/删除键/值对
复合运算与对偶ack语义
对象类

对象监视/通知

客户端可以向对象注册持久兴趣，并保持到主OSD的会话打开。客户端可以向所有观察者发送通知消息和有效载荷，并在观察者接收到通知时接收通知。这使客户端能够使用任何对象作为同步/通信通道。

数据条带化

存储设备有吞吐量限制，这会影响性能和可扩展性。因此，存储系统通常支持条带化--跨多个存储设备存储连续的信息片段--以提高吞吐量和性能。最常见的数据条带化形式来自RAID。与Ceph的条带化最相似的RAID类型是RAID 0或“条带卷”。Ceph的条带化提供了RAID 0条带化的吞吐量、n路RAID镜像的可靠性和更快的恢复。

Ceph提供三种类型的客户端：Ceph块设备、Ceph文件系统和Ceph对象存储。Ceph客户端将其数据从提供给用户的表示格式（块设备映像、RESTful对象、CephFS文件系统目录）转换为存储在Ceph存储集群中的对象。

提示
Ceph存储在Ceph存储集群中的对象没有条纹。Ceph对象存储、Ceph块设备和Ceph文件系统将其数据分带到多个Ceph存储集群
对象上。通过librados直接写入Ceph存储集群的Ceph客户端必须为自己执行条带化（和并行I/O）才能获得这些好处。

最简单的Ceph条带化格式包括1个对象的条带计数。Ceph客户端将条带单元写入Ceph存储集群对象，直到该对象达到其最大容量，然后为其他数据条带创建另一个对象。最简单的条带形式可能足以用于小块设备图像、S3或Swift对象和CephFS文件。然而，这种简单的形式并没有最大限度地利用Ceph在放置组之间分发数据的能力，因此性能也没有得到很大提高。下图描述了最简单的分条形式：

如果您预计图像大小较大，S3或Swift对象（例如视频）较大，或者CephFS目录较大，则通过将客户端数据分条到对象集中的多个对象上，您可能会看到读/写性能显著提高。当客户端将条带单元并行写入其相应的对象时，会出现显著的写入性能。由于对象被映射到不同的放置组，并进一步映射到不同OSD，因此每次写入都以最大写入速度并行进行。对单个驱动器的写入将受到磁头移动（例如每次寻道6ms）和该设备带宽（例如100MB/s）的限制。通过将写入扩展到多个对象（映射到不同的放置组和操作系统），Ceph可以减少每个驱动器的寻道次数，并将多个驱动器的吞吐量结合起来，以实现更快的写入（或读取）速度。

笔记

条带化独立于对象复制副本。由于CRUSH跨操作系统复制对象，因此条带会自动复制。

在下图中，客户端数据在由4个对象组成的对象集（下图中的对象集1）上进行条带化，其中第一个条带单元是对象0中的条带单元0，第四个条带单位是对象3中的条条带第三单元。在写入第四个条带之后，客户端确定对象集是否已满。如果对象集未满，客户端将再次开始向第一个对象（下图中的对象0）写入条带。如果对象集已满，则客户端创建新的对象集（下图中的对象集2），并开始向新对象集中的第一对象（下图中对象4）中的第一条带（条带第十六单元）写入。

三个重要变量决定Ceph条纹数据的方式：

对象大小：Ceph存储集群中的对象具有最大可配置大小（例如，2MB、4MB等）。对象大小应足够大，以容纳许多条带单元，并且应为条带单元的倍数。
条带宽度：条带具有可配置的单位大小（例如64kb）。Ceph客户端将写入对象的数据划分为大小相等的条带单元，最后一个条带单元除外。条纹宽度应该是“对象大小”的一小部分，这样一个对象就可以包含许多条纹单位。
条带计数：Ceph客户端在由条带计数确定的一系列对象上写入一系列条带单元。该系列对象称为对象集。Ceph客户端写入对象集中的最后一个对象后，返回对象集中的第一个对象。

重要的
在将集群投入生产之前，测试条带化配置的性能。在对数据进行条带化并将其写入对象后，不能更改这些条带化参数。

一旦Ceph客户端将数据条带化到条带单元并将条带单元映射到对象，Ceph的CRUSH算法就会将对象映射到放置组，并将放置组映射到Ceph OSD Daemon，然后将对象作为文件存储在存储驱动器上。

笔记
由于客户端写入单个池，所以条带化到对象中的所有数据都映射到同一池中的放置组。因此，它们使用相同的CRUSH映射
和相同的访问控制。

CEPH客户端

Ceph客户端包括许多服务接口。其中包括：

块设备：Ceph块设备（也称为RBD）服务提供可调整大小的精简配置块设备，这些设备可以进行快照和克隆。Ceph在集群中划分块设备以获得高性能。Ceph同时支持内核对象（KO）和直接使用librbd的QEMU管理程序，从而避免了虚拟化系统的内核对象开销。
对象存储：Ceph对象存储（也称为RGW）服务提供RESTful API，其接口与Amazon S3和OpenStack Swift兼容。
文件系统：Ceph文件系统（CefFS）服务提供了一个兼容POSIX的文件系统，可用于挂载或作为用户空间（FUSE）中的文件系统。

Ceph可以运行额外的操作系统、MDS和监视器实例，以实现可扩展性和高可用性。下图描述了高级体系结构。

CEPH对象存储

Ceph对象存储守护进程radosgw是一个FastCGI服务，它提供RESTful HTTP API来存储对象和元数据。它使用自己的数据格式在Ceph存储集群之上分层，并维护自己的用户数据库、身份验证和访问控制。RADOS网关使用统一的名称空间，这意味着您可以使用OpenStack Swift兼容的API或Amazon S3-兼容的API。例如，您可以在一个应用程序中使用与S3-兼容的API写入数据，然后在另一个应用软件中使用与Swift-兼容的API读取数据。

S3/Swift对象和存储集群对象的比较

Ceph的对象存储使用术语对象来描述它存储的数据。S3和Swift对象与Ceph写入Ceph存储集群的对象不同。Ceph对象存储对象映射到Ceph存储集群对象。S3和Swift对象不一定以1:1的方式与存储集群中存储的对象相对应。S3或Swift对象可以映射到多个Ceph对象。

有关详细信息，请参阅Ceph对象存储。

CEPH块设备

Ceph块设备将块设备映像分带到Ceph存储集群中的多个对象上，其中每个对象都映射到一个放置组并进行分布，并且放置组分布在整个集群的单独Ceph-osd守护进程中。

重要的
条带化使RBD块设备的性能优于单个服务器！

精简配置的可快照Ceph块设备是虚拟化和云计算的一个有吸引力的选择。在虚拟机场景中，人们通常会在QEMU/KVM中部署带有rbd网络存储驱动程序的Ceph块设备，其中主机使用librbd向来宾提供块设备服务。许多云计算堆栈使用libvirt与管理程序集成。您可以将精简配置的Ceph Block Devices与QEMU和libvirt一起使用，以支持OpenStack、OpenNebula和CloudStack等解决方案。

虽然我们目前不向其他管理程序提供librbd支持，但您也可以使用Ceph Block Device内核对象向客户端提供块设备。Xen等其他虚拟化技术可以访问Ceph块设备内核对象。这是通过命令行工具rbd完成的。

CEPH文件系统

Ceph文件系统（CephFS）提供了一个符合POSIX的文件系统作为一种服务，它分层在基于对象的Ceph存储集群之上。CephFS文件被映射到Ceph存储在Ceph存储集群中的对象。Ceph客户端将CephFS文件系统安装为内核对象或用户空间（FUSE）中的文件系统。

Ceph文件系统服务包括与Ceph存储集群一起部署的Ceph元数据服务器（MDS）。MDS的目的是将所有文件系统元数据（目录、文件所有权、访问模式等）存储在高可用性Ceph元数据服务器中，元数据驻留在内存中。MDS（一个称为ceph-MDS的守护进程）的原因是，列出目录或更改目录（ls，cd）等简单的文件系统操作会对ceph OSD守护进程产生不必要的负担。因此，将元数据与数据分离意味着Ceph文件系统可以提供高性能服务，而不会对Ceph存储集群造成负担。

CephFS将元数据与数据分离，将元数据存储在MDS中，并将文件数据存储在Ceph存储集群中的一个或多个对象中。Ceph文件系统旨在实现POSIX兼容性。ceph-mds可以作为单个进程运行，也可以分布到多个物理机器，以实现高可用性或可扩展性。

高可用性：额外的ceph-mds实例可以是备用的，随时可以接管任何活动的失败ceph-md的职责。这很容易，因为包括日志在内的所有数据都存储在RADOS上。转换由ceph mon自动触发。
可扩展性：多个ceph-mds实例可以是活动的，它们将目录树拆分为子树（以及单个繁忙目录的碎片），从而有效地平衡所有活动服务器之间的负载。

备用和活动等的组合是可能的，例如运行3个活动ceph-mds实例以进行扩展，运行一个备用实例以实现高可用性。

本文地址

https://architect.pub/ceph-architecture

登录发表评论
18 次浏览

发布日期

星期二, June 4, 2024 - 09:29

最后修改

星期二, June 4, 2024 - 11:23

热门内容

今日:

总体:

最近浏览：

category