1 SES 和 Ceph #
SUSE Enterprise Storage 是基于 Ceph 技术的分布式存储系统，旨在提高可伸缩性、可靠性和性能。Ceph 集群可在常见网络（例如以太网）中的市售服务器上运行。该集群能够正常扩展到数千台服务器（后面称为“节点”）以及 PB 量级的处理能力。与使用分配表来存储和提取数据的传统系统相反，Ceph 使用确定性算法来为数据分配存储空间，并且不采用任何集中式信息结构。Ceph 假设在存储集群中，硬件的添加或删除属于惯例，而不是例外情况。Ceph 集群可将数据分布和重新分布、数据复制、故障检测和恢复等管理任务自动化。Ceph 既可自我修复，又可自我管理，因此可以降低管理开销和预算开销。
本章提供 SUSE Enterprise Storage 7.1 的综合概述，并简要介绍一些最重要的组件。
1.1 Ceph 特性 #
Ceph 环境具有以下特性：
- 可伸缩性
Ceph 可扩展到数千个节点，并可管理 PB 量级的存储。
- 市售硬件
无需特殊的硬件即可运行 Ceph 集群。有关详细信息，请参见第 2 章 “硬件要求和建议”
- 自我管理
Ceph 集群可自我管理。添加、删除节点或节点发生故障时，集群可自动重新分布数据。此外，它还能识别过载的磁盘。
- 无单一故障点
重要的信息不会单独存储在集群中的某个节点上。可以配置冗余数量。
- 开放源代码软件
Ceph 是一套开源软件解决方案，独立于特定的硬件或供应商。
1.2 Ceph 核心组件 #
要充分利用 Ceph 的强大功能，需要了解一些基本的组件和概念。本节介绍经常在其他章节中提到的 Ceph 的某些组成部分。
1.2.1 RADOS #
Ceph 的基本组件称为 RADOS （可靠自主分布式对象存储）。该组件负责管理集群中存储的数据。Ceph 中的数据通常以对象的形式存储。每个对象由标识符和数据组成。
RADOS 提供以下方法来访问涉及许多用例的存储对象：
- 对象网关
对象网关是 RADOS 对象存储区的 HTTP REST 网关。使用该网关可以直接访问 Ceph 集群中存储的对象。
- RADOS 块设备
可以像访问任何其他块设备一样访问 RADOS 块设备 (RBD)。例如，可将这些设备与
libvirt结合使用，以实现虚拟化。- CephFS
Ceph 文件系统是符合 POSIX 标准的文件系统。
libradoslibrados是一个库，可与许多编程语言结合使用，以创建能够直接与存储集群交互的应用。
librados 由对象网关和 RBD 使用，而 CephFS 直接与 RADOS 连接。请参见（图 1.1 “与 Ceph 对象存储连接”）。
1.2.2 CRUSH #
Ceph 集群的核心是 CRUSH 算法。CRUSH 是 Controlled Replication Under Scalable Hashing（基于可缩放哈希的受控复制）的缩写。CRUSH 是处理存储分配的函数，所需的参数相对较少。这意味着，只需提供少量的信息就能计算对象的存储位置。参数是集群的现行对照，包括健康状况、管理员定义的某些放置规则，以及需要存储或检索的对象名称。提供这些信息后，Ceph 集群中的所有节点即可计算对象及其副本的存储位置。这使数据写入或读取变得非常有效。CRUSH 会尝试在集群中的所有节点上均匀分布数据。
CRUSH 索引包含所有存储节点，以及管理员定义的有关在集群中存储对象的归置规则。该索引定义了通常对应于集群物理结构的分层结构。例如，包含数据的磁盘位于主机中，主机位于机柜中，机柜位于设备排中，而设备排位于数据中心中。此结构可用于定义故障域。然后，Ceph 可确保将复制项存储在特定故障域的不同分支中。
如果将故障域设置为机柜，则在不同的机柜中分布对象复制项。这样就可以缓解机柜中的交换机发生故障所造成的服务中断。如果某个电源分配单元为一排机柜供电，则可将故障域设置为设备排。当电源分配单元发生故障时，其他设备排中仍可提供复制的数据。
1.2.3 Ceph 节点和守护进程 #
在 Ceph 中，节点是为集群工作的服务器。它们可以运行多种不同类型的守护进程。我们建议在每个节点上只运行一种类型的守护进程，但 Ceph Manager 守护进程除外，此类守护进程可与 Ceph Monitor 共置。每个集群都至少需要运行 Ceph Monitor、Ceph Manager 和 OSD 守护进程：
- 管理节点
管理节点是您在其中运行相应命令来管理集群的一种 Ceph 集群节点。管理节点是 Ceph 集群的中心点，因为它管理着集群的其余节点，它会查询这些节点的 Salt 受控端服务并向其发出指示。
- Ceph Monitor
Ceph Monitor（往往缩写为 MON）节点负责维护有关集群健康状况、所有节点的索引和数据分布规则的信息（请参见第 1.2.2 节 “CRUSH”）。
如果发生故障或冲突，集群中的 Ceph Monitor 节点会根据多数派原则确定哪些信息是正确的。为了构成有效的多数派，建议设置奇数数量的 Ceph Monitor 节点，并至少设置三个这样的节点。
如果使用多个站点，应在奇数个站点之间分布 Ceph Monitor 节点。每个站点的 Ceph Monitor 节点数应满足以下要求：当一个站点发生故障时，50% 以上的 Ceph Monitor 节点可保持正常运行。
- Ceph Manager
Ceph Manager 会从整个集群收集状态信息。Ceph Manager 守护进程与 Ceph Monitor 守护进程一同运行。它提供附加的监视功能，并与外部监视和管理系统连接。它还包含其他服务。例如，Ceph Dashboard Web UI 会在 Ceph Manager 所在的节点上运行。
Ceph Manager 不需要额外的配置，只需确保它在运行即可。
- Ceph OSD
Ceph OSD 是一个守护进程，负责处理属于物理或逻辑存储单元（硬盘或分区）的对象存储设备。对象存储设备可以是物理磁盘/分区，也可以是逻辑卷。此外，该守护进程会处理数据复制，并在添加或删除节点后进行重新平衡。
Ceph OSD 守护进程与 Monitor 守护进程通讯，并为其提供其他 OSD 守护进程的状态。
要使用 CephFS、对象网关、NFS Ganesha 或 iSCSI 网关，还需要其他节点：
- 元数据服务器 (MDS)
CephFS 元数据存储在自己的 RADOS 存储池中（请参见第 1.3.1 节 “存储池”）。元数据服务器充当着元数据的智能缓存层，会根据需要对访问进行序列化。这样，无需显式同步，许多客户端便可实现并发访问。
- 对象网关
对象网关是 RADOS 对象存储的 HTTP REST 网关。它与 OpenStack Swift 和 Amazon S3 兼容，具有自己的用户管理功能。
- NFS Ganesha
使用 NFS Ganesha 可通过 NFS 访问对象网关或 CephFS。该组件在用户空间而不是内核空间中运行，直接与对象网关或 CephFS 交互。
- iSCSI 网关
iSCSI 是一种存储网络协议，可让客户端将 SCSI 命令发送到远程服务器上的 SCSI 存储设备（目标）。
- Samba 网关
Samba 网关提供对 CephFS 上所存储数据的 Samba 访问途径。
1.3 Ceph 存储结构 #
1.3.1 存储池 #
Ceph 集群中存储的对象放置在存储池中。对外部环境而言，存储池代表集群的逻辑分区。对于每个存储池，可以定义一组规则，例如，每个对象必须有多少个复制项。存储池的标准配置称为副本存储池。
存储池通常包含多个对象，但也可以将其配置为充当类似 RAID 5 的作用。在此配置中，对象连同其他编码块一起存储在块中。编码块包含冗余信息。管理员可以定义数据块和编码块的数量。在此配置中，存储池称为纠删码存储池或 EC 存储池。
1.3.2 归置组 #
归置组 (PG) 用于在存储池中分布数据。创建存储池时，会设置特定数目的归置组。归置组在内部用于将对象分组，是影响 Ceph 集群性能的重要因素。对象的 PG 根据该对象的名称确定。
1.3.3 示例 #
本节提供有关 Ceph 如何管理数据的简化示例（请参见图 1.2 “小规模 Ceph 示例”）。此示例并不代表 Ceph 集群的建议配置。硬件设置由三个存储节点或 Ceph OSD（主机 1、主机 2 和主机 3）组成。每个节点包含三个用作 OSD（osd.1 到 osd.9）的硬盘。此示例中忽略了 Ceph Monitor 节点。
尽管 Ceph OSD 或 Ceph OSD 守护进程是指节点上运行的守护进程，但 OSD 一词指的是与守护进程交互的逻辑磁盘。
集群包含两个存储池：存储池 A 和存储池 B。尽管存储池 A 仅复制对象两次，但存储池 B 的恢复能力更重要，该存储池中的每个对象都有三个复制项。
当应用将某个对象放入存储池中时（例如，通过 REST API），将会根据存储池和对象名称选择归置组（PG1 到 PG4）。然后，CRUSH 算法会根据包含对象的归置组，计算要将对象存储到哪些 OSD。
在此示例中，故障域设置为主机。这可确保将对象的复制项存储在不同的主机上。根据针对存储池设置的复制级别，对象将存储在归置组使用的两个或三个 OSD 上。
写入对象的应用只与一个 Ceph OSD（主要 Ceph OSD）交互。主要 Ceph OSD 处理复制过程，并在所有其他 OSD 存储对象后确认写入过程完成。
如果 osd.5 发生故障，osd.1 上仍会提供 PG1 中的所有对象。一旦集群发现某个 OSD 发生故障，另一个 OSD 会立即接管工作。在此示例中，osd.4 用于取代 osd.5。然后，osd.1 上存储的对象会复制到 osd.4，以恢复复制级别。
如果将包含新 OSD 的新节点添加到集群，集群索引将会更改。然后，CRUSH 函数将返回对象的不同位置。接收新位置的对象将被重新定位。此过程将使得所有 OSD 被平衡使用。
1.4 BlueStore #
从 SES 5 开始，使用 BlueStore 作为 Ceph 的新默认存储后端。BlueStore 的性能优于 FileStore，具有全数据校验和及内置压缩功能。
它可管理一至三个存储设备。在最简单的情况下，BlueStore 会使用一个主存储设备。该设备通常被分割成两个分区：
一个名为 BlueFS 的较小分区，用于实施 RocksDB 所需的类似文件系统的功能。
其余部分通常是一个较大的分区，占用了设备的剩余空间。它直接由 BlueStore 管理，包含所有实际数据。此主设备通常通过数据目录中的块符号链接来标识。
还可跨两个额外的设备来部署 BlueStore：
WAL 设备可用于存储 BlueStore 的内部日志或预写日志。它通过数据目录中的 block.wal 符号链接来标识。只有 WAL 设备速度比主设备或 DB 设备快时，使用单独的 WAL 设备才比较实用，例如，下列情况就很适合：
WAL 设备是 NVMe，DB 设备是 SSD，数据设备是 SSD 或 HDD。
WAL 和 DB 设备都是单独的 SSD，数据设备是 SSD 或 HDD。
DB 设备可用于存储 BlueStore 的内部元数据。BlueStore（更确切地说，是嵌入式 RocksDB）会将尽可能多的元数据存放于 DB 设备，以提升性能。再次重申，只有共享 DB 设备速度比主设备快时，供应共享 DB 设备才有所助益。
规划时请考虑充分，以确保为 DB 设备分配足够的大小。如果 DB 设备填满，元数据将溢出到主设备，这会严重降低 OSD 的性能。
您可以使用 ceph daemon osd.ID perf dump 命令来检查 WAL/DB 分区是否即将填满及溢出。slow_used_bytes 值显示即将溢出的数据量：
cephuser@adm > ceph daemon osd.ID perf dump | jq '.bluefs'
"db_total_bytes": 1073741824,
"db_used_bytes": 33554432,
"wal_total_bytes": 0,
"wal_used_bytes": 0,
"slow_total_bytes": 554432,
"slow_used_bytes": 554432,1.5 附加信息 #
作为一个社区项目，Ceph 自身具有丰富的联机文档。对于本手册中未介绍的主题，请参见 https://docs.ceph.com/en/pacific/。
由 S.A. Weil、S.A. Brandt、E.L. Miller 和 C. Maltzahn 撰写的原始文献 CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data（CRUSH：复制数据的受控、可缩放、分布式放置）提供了有关 Ceph 内部工作原理的有用见解。特别是在部署大规模集群时，推荐您阅读此文章。可在 http://www.ssrc.ucsc.edu/papers/weil-sc06.pdf 上找到该文献。
SUSE Enterprise Storage 可与非 SUSE OpenStack 发行套件搭配使用。Ceph 客户端需与 SUSE Enterprise Storage 兼容。
注意SUSE 支持 Ceph 部署的服务器组件，而客户端则由 OpenStack 发行套件供应商提供支持。