「CEPH」- 规划高可用集群

问题描述

投产 Ceph 之前，需要做好充分的集群规划，才能在后续实践中得到满意的集群性能，同时降低运维难度。如果集群规划不当，将可能给集群扩容、升级、维护等带来很多麻烦；

解决方案

Ch.1 需求确认
Ch.2 版本选择
Ch.3 硬件选型
Ch.4 操作系统
Ch.5 服务规划
Ch.6 配置策略

Ch.1 确认场景

根据存储需求和使用场景，来制定 Ceph 的硬件选型需要；

高性能场景（IOPS）

特征：这种配置的类型亮点在于它在低 TCO（ownership 的总消耗）下每秒拥有最高的 IOPS；

实现：典型的做法是使用包含了更快的 SSD 硬盘、PCIe SSD、NVMe 做数据存储的高性能节点；

场景：通常用于块存储；也可以用在高 IOPS 的工作负载上：随着闪存使用的增加，企业越来越多地将 IOPS 密集型工作负载（例如 MySQL、MariaDB 或 PostgreSQL 等等）托管在 Ceph 集群，以便提高私有云存储解决方案性能，并支持结构化数据；

推荐配置：

CPU：假定主频 2GHz，则每个 NVMe SSD 使用 6vCPU，每个非 NVMe SSD 使用 2vCPU；
RAM：16GB + OSD * 5GB（16GB 作为基线，每个 OSD 使用 5GB 内存）
DISK：NVMe SSD
Bluestore WAL/DB：可与 NVMe SSD 同盘；
磁盘控制器：PCIe
OSD 进程数：每个 NVMe SSD 分配 OSD * 2 进程；
网络：每 OSD * 2 使用 10GB 网络；

通用场景（Bandwidth）

特征：亮点在于高吞吐量和每吞吐量的低功耗；

实现：通用的做法是拥有一个高带宽、物理隔离的双重网络，使用 SSD 和 PCIe SSD 做 OSD 日志盘；

场景：这种方法常用于块存储，如果你的应用场景需要高性能的对象存储和文件存储，也可以考虑使用；对于存储非结构化数据的用户，制定吞吐量大的方案即可；

Ceph 集群通常可以存储半结构化数据或非结构化数据，一般是顺序读写较大的文件，需要提供很大的带宽。存储服务器上的磁盘可以使用基础 SSD 做日志加速的 HDD 盘；

推荐配置：
1）CPU：假定主频 2GHz，则每个 HDD 使用 2vCPU，通常不需要使用 SSD 存储；
2）RAM：16GB + OSD * 5GB（16GB 作为基线，每个 OSD 使用 5GB 内存）
3）DISK：HDD (7200 RPM SATA/SAS)
4）Bluestore WAL/DB：使用 SAS SSD / NVMe SSD 进行加速；
5）磁盘控制器：HBA（JBOD）
6）OSD 进程：每个 HDD 分配 OSD * 1 进程；
7）网络：每 OSD * 12 使用 10GB 网络；

大容量场景（Capacity）

特征：亮点在于数据中心每 TB 存储的低成本，以及机架单元物理空间的低成本。也被称为经济存储、廉价存储、存档 / 长期存储；

实现：通用的做法是使用插满机械硬盘的密集服务器，一般是 36~72 台服务器，每台服务器 4~6TB 的物理硬盘空间；

场景：通常用于低功耗、大存储容量的对象存储和文件存储。一个好的备选方案是采用纠删码来最大化存储容量；通常，低成本和高容量的解决方案用于处理存储容量较大、存储时间较长的数据，且按块顺序读写。数据可以是半结构化的，也可以是非结构化的。存储内容包括媒体文件、大数据分析文件和磁盘镜像备份等。为了获得更高的效益，OSD 通常托管在 HDD 上，Ceph 的日志也存储在 HDD 上；

推荐配置：
1）CPU：假定主频 2GHz，则每个 HDD 使用 0.5vCPU
2）RAM：16GB + OSD * 5GB（16GB 作为基线，每个 OSD 使用 5GB 内存）
3）DISK：HDD (7200 RPM SATA/SAS)
4）Bluestore WAL/DB：使用 HDD 同盘即可；
5）磁盘控制器：HBA（JBOD）
6）OSD 进程：每个 HDD 分配 OSD * 1 进程；
7）网络：每 OSD * 12 使用 10GB 网络；

注意事项

另外，Ceph 存储数据是按照 2MB 为基本单位进行读写的，即便是小文件也要按照此种方式进行操作。写入时要组成 2MB 的块一次性写入，读取时一次性读取 2MB 的块。如果用户数据为字节级别，频繁读写将对 Ceph 的性能产生冲击；

因此，在设计原理的限制下，你在投产 Ceph 时必须要考虑清楚其使用场景。如果不满足 Ceph 的使用场景，此类数据建议不要放入 Ceph 中；

Ch.2 版本选择

规划 Ceph Cluter 之前，需要了解和确定将要部署的 Ceph 集群版本、功能、要求、限制条件，这些问题将会对后面的决策（诸如硬件选型、组网规划等等）产生影响，然后再针对这些限制条件做出合理的架构规划；

开源版本

参考 Ceph Releases (index) — Ceph Documentation 文档，以了解 Ceph 的发布历史，以及相关详细信息； 

Quincy 2022-04-19 17.2.5 2024-06-01
Pacific 2021-03-31 16.2.10 2023-06-01
Octopus 2020-03-23 15.2.17 2022-06-01

Nautilus 2019-03-19 14.2.22 2021-06-30
Mimic 2018-06-01 13.2.10 2020-07-22
Luminous 2017-08-01 12.2.13 2020-03-01
Kraken 2017-01-01 11.2.1 2017-08-01
Jewel 2016-04-01 10.2.11 2018-07-01
Infernalis 2015-11-01 9.2.1 2016-04-01
Hammer 2015-04-01 0.94.10 2017-08-01
Giant 2014-10-01 0.87.2 2015-04-01
Firefly 2014-05-01 0.80.11 2016-04-01
Emperor 2013-11-01 0.72.2 2014-05-01
Dumpling 2013-08-01 0.67.11 2015-05-01

企业版本

Red Hat Ceph Storage https://www.redhat.com/en/technologies/storage/ceph

针对 Open-source Ceph 与 Red Hat Ceph 的对应关系，建议阅读官方文档。鉴于我们暂时不使用 Red Hat Ceph，所以我们暂时不关注二者版本对应关系；

Ch.3 硬件选型

硬件选型没有黄金法则，因为它依赖各种因素，比如预算、性能和容量，或者两种的结合、容错性，以及使用场景；

设计原理决定其对网络和硬件设备的依赖较为明显，因此投产 Ceph 的环境必须使用万兆网络，同时配置 SSD 硬盘设备对集群进行写加速；

Ceph 服务器分了几种角色，每种角色都对应集群的一类功能，主要包括 MON（Ceph 集群的 Monitor 节点）、OSD（Ceph 集群的存储节点）、MGR（Ceph 集群的管理节点）、RGW（Ceph 集群的对象网关节点）、MDS（CephFS 元数据节点）、iSCSI 网关、NFS 集群网关和 Ceph 客户端。不同类型角色，其对资源的依赖情况也不相同；

CPU

Ceph MDS 会动态地重新分配负载，它是 CPU 敏感性的，所以 Metadata Server 应该有比较好的处理器性能（比如四核 CPU）；

Ceph OSD 进程来执行最终数据落盘的相关操作，涉及数据的分片和重组，并且每个存储节点上都运行许多（根据磁盘数量决定）Ceph OSD 进程，所以对 CPU 有一定的要求；

Ceph OSD 运行 RADOS 服务，需要通过 CRUSH 来计算数据的存放位置，复制数据，以及维护 Cluster Map 的拷贝。通常建议每个 OSD 进程至少有一个 CPU 核；

追求 Bandwidth 场景，假设 CPU 主频是 2GHz，一般每个 HDD 类型的 OSD 进程需要分配 0.5 ~1core。例如 24 个 OSD 则需要 24 Core 资源；

追求 IOPS 场景，假设 CPU 主频是 2GHz，一般每个 NVMe SSD 类型的 OSD 进程需要分配 10core。此种场景对 CPU 的要求较高；

Ceph Mon 简单地维护了 Cluster Map 的主干信息，所以 Ceph Mon 是 CPU 不敏感的；

Memory

Ceph MDS 以及 Ceph Mon 必须能够快速地提供数据，因此必须有充足的内存（至少每个进程 1GB）；

针对 Ceph OSD 进程，通常来说，内存越多越好

1）在日常操作时，不需要过多的内存（如每进程 500MB，来缓存热数据）；

2）但是，在执行恢复操作时，就需要大量的内存（例如，每进程每 TB 数据需要约 1GB 内存）；

每个存储节点的磁盘数量决定每个存储节点的内存需求量。应该先规划存储容量，然后确定内存容量，配合其他衡量指标得到最后的服务器硬件配置参数；

1GB RAM 对应 1TB 数据

3～6GB RAM 对应 1 HDD OSD 进程

8～12GB RAM 对应 1 SSD OSD 进程

针对 4 * SSD + 20 * HDD 集群，配置 184GB（16+6×20+12×4）内存：

1）16GB RAM（操作系统运行+服务进程）

2）3～6GB RAM×20（每个 HDD 类型的 OSD 进程使用）

3）8～12GB RAM×4（每个 SSD 类型的 OSD 进程使用或做加速）

Network

网络配置对于构建高性能 Ceph 集群至关重要。Ceph 集群不能取代 Ceph 客户端执行请求路由或调度，而是由 Ceph 客户端直接向 Ceph OSD 守护进程发出请求。Ceph OSD 会向 Ceph 客户端执行数据复制，这意味着数据复制会在 Ceph 集群的网络上进行，且必然会带来很大的网络负载；

由于 Ceph 集群最初的设计是为了提高集群的性能，并且考虑到集群网络的带宽要求，因此将集群内部流量与客户端到集群流量进行隔离，从而设计两层网络。如果不配置两个网络，Ceph 的所有流量都会使用同一个网络，这样性能就会相对较低，并且流量高峰时会相互影响；

公网，集群对外通信网络，承载 Ceph 的对外通信及数据交互；

私网，集群内部通信网络，仅承载与 Ceph 集群相关的流量。集群内部网络（最好别连接到外网）用于处理由数据复制产生的额外负载，而且可防止 DOS 攻击，DOS 攻击会干扰 PG 数据，使之在 OSD 数据复制时不能回到 Active+Clean 状态；

我们也可以在该网络中增加一个管理网络，但由于管理数据的流量很小，可将管理网络和公网网络合并；

Ceph 对网络带宽要求高，其 I/O 性能取决于网络性能，所以在 Ceph 项目建设中网络建设是至关重要的一环；

在较小集群中，1G 网络可能适用于正常操作环境。建议每台机器最少有两个千兆网卡，现在大多数机械硬盘都能达到 100MB/s 的吞吐量，网卡能处理所有 OSD 硬盘总吞吐量，所以推荐最少安装 1000Mbps * 2 网卡，分别用于公网（前端）和集群网络（后端）；

在生产环境中部署，建议至少使用 10G 网络。当集群服务器数量较多时，还需要使用高性能交换机降低网络延时，提高网络总线处理能力；

在生产环境中，建议使用 10Gbps * 2 网络，并且尽可能多端口绑定以增加冗余或者并行带宽。假设通过 1Gbps 网络复制 1TB 数据需要耗时 3h，而 3TB（典型配置）就需要 9h，相比之下，如果使用 10Gbps 复制时间可分别缩减到 1h。所以，一般使用 Ceph 都会部署万兆网卡；

集群究竟需要多大网络带宽，这和集群内的硬件资源配置有很大关系，要看追求的是 IOPS 还是 Bandwidth：

1）在追求 IOPS 的全 NVMe SSD 的高性能服务器上，推荐每 2 * NVMe SSD 类型的 OSD 使用 10G 网络；

2）在追求 Bandwidth 的服务器上，可以配置 12 * HDD 类型的 OSD 使用 10G 网络；

关于 Firewall 配置：

针对 Public Network 和 Cluster Network，鉴于 Ceph Client 使用 Public Network 进行连接，而其他 OSD 守护进程将使用 Cluster Network 进行连接。则必须同时为 Public Network 和 Cluster Network 添加规则，所以你需要开放的防火墙端口为 6789（Ceph Mon）、6800:7300（Ceph OSD）；

Disk

规划数据存储时要考虑成本和性能的权衡。Ceph 集群的性能很大程度上取决于存储介质的有效选择。应该在选择存储介质之前了解集群的工作负载和性能需求；

磁盘冗余：

其为数据安全做了软件层面的冗余，通过副本或纠删码实现了数据安全，所以我们不需要额外考虑磁盘的冗余；

RAID 会给 Ceph 的性能带来影响，而且在成本和存储空间上造成了不必要的浪费。所以在硬件层面不推荐配置 RAID，将服务器的磁盘直接配置成 JBOD 模式即可。如果服务器不支持 JBOD 模式，就配置成 RAID0；

磁盘类型：

1）追求 IOPS 的使用者，使用 SSD 作为高性能存储设备，以提高 IOPS，但这在一定程度上也会增加 Ceph 集群的整体造价；

2）追求 Bandwidth 的使用者，使用 HDD+SSD（加速用）进行组合，将降低集群成本。若优化得当，也能得到不错的 IOPS 效果；

存储节点支持的存储磁盘类型包括 HDD、SSD、NVMe SSD；

日志加速：

如果工作环境是通用场景的需求，那么建议使用 SSD 做日志盘。使用 SSD，可以减少访问时间，降低写延迟，大幅提升吞吐量。使用 SSD 做日志盘，可以对每个物理 SSD 创建多个逻辑分区，每个 SSD 逻辑分区（日志），映射到一个 OSD 数据盘。通常 10~20GB 日志大小足以满足大多数场景。如果你有一个更大的 SSD，不要忘记为 OSD 增加 filestore 的最大和最小的同步时间间隔；

在 Ceph 中，作为 Journal 存储的最常见非易失性快速存储类型是 SATA、SAS SSD、PCIe 或 NVMe SSD；

若想在 SATA/SAS SSD 之外获得高性能，SSD 和 HDD 的比例应该是 1:4（或 1:5）；

PCIe 或 NVMe 闪存设备的情况，取决于设备性能，SSD 和 HDD 比例在 1:10 ~ 1:18 之间；

这些比例是非常常见的，能良好工作在大多数场景下。但建议针对具体环境测试 SSD/PCIe 以得到最好的效果；

通过对日志做 RAID1 来解决单个 SSD 故障问题，但这会增加成本。如果希望提升性能，那该投入是值得的；

如果希望降低成本，那么从大容量的机械硬盘中分配少量 GB 的空间给日志盘，其余容量用于 OSD 数据；

磁盘分区：

进行系统操作，同时多个后台程序对单个驱动器进行读写操作会显著降低性能；

副本数量

值得注意的是，在写性能上，副本也是一个重要因素。副本因素通常要在可靠性、性能和 TCO 之间平衡；

Ch.4 操作系统

系统版本

Ceph 需要以 Linux 操作系统为运行环境，建议阅读 OS Recommendations 文档，以获取针对操作系统的详细要求；

Quincy 17.2.z | CentOS 8 | Ubuntu 20.04 | OpenSUSE 15.3 | Debian 11

Filesystem

当前 Bluestore 不再依赖于文件系统，所以针对 Bluestore 没有文件系统的限制考虑；

Ch.5 服务规划

在规划集群时，Ceph 的各种组件应尽量避免复用。虽然复用能节省服务器的数量，但是实践证明，组件角色复用会给集群的运维和性能带来很大的影响。这不是最佳实践该有的设计模式，因此你在规划 Ceph 集群的时候，请尽量避免组件角色复用。—— 《Ceph 企业级分布式存储: 原理与工程实践》，我们并不理解这些组件复用是什么意思，或许是指：例如：将 OSD 节点同时用作 MON 节点，或将 MDS 节点同时用作 RGW 节点等；

同时，正确选择服务器或虚拟机，部分服务无法（或不建议）在虚拟机中运行，以避免给集群运行带来不稳定因素；

在考虑安全性与可靠性的前提下，你必须满足如下限制要求：

组件 裸机 虚机 容器 补充说明
OSD o x o 每个节点至少配置 3 个 OSD；
所有的 OSD 节点配置相同；
仅支持服务器直通存储设备；
不支持外部 SAN 通过 FC/iSCSI 连接到服务器的存储设备；
Monitor (with Mgr) o o o 至少配置 3 个 Monitor（MON）节点；
磁盘数量超过 750 个时，建议 Mon * 5；
Ceph Mon 与 Ceph Mgr 可以运行在同个节点上；
至少配置 2 个 Manger（MGR）节点；
RGW/NFS Gateway o o o 如果要使用 Ceph 对象网关，至少配置 2 个不同的 RGW 节点；
MDS o x o 如果要使用 CephFS，至少配置 2 个节点；
且需要配置完全相同的 MDS 节点；
iSCSI Gateway o x o 针对每个集群，需要部署 2-4 个 iSCSI 网关；
Dashboard o o o  

Ch.6 配置策略

选定的 Ceph 集群版本并不是支持所有的功能特性，或者说不是所有功能特性都是稳定的。你必须选择稳定的功能特性，而在选定的功能特性中，还要按照要求配置集群，否则将给集群的稳定性带来隐患；

如下提到的几种指标及推荐配置是经过企业落地实践检验的，可供参考：

副本策略

SSD，支持 2 副本，最少 1 副本；HDD，支持 3 副本，最少 2 副本；

注意，副本数减少将影响可靠性；

纠删码

支持 RGW / RBD 两种模式使用纠删码，MDS 不支持使用纠删码；

纠删码 K+M 建议取值：8+3 或 8+4 或 4+2，而 OSD 最小数量为 K+M+1；

RGW 多站点

多站点配置中，不支持 Indexless Bucket 特性；

磁盘大小

单盘最大 12T，不支持 SMR1 特性；

最大的 OSD 数量

单节点最多 OSD * 36，集群点最多 OSD * 2500，

快照（Snapshot）

单个 RBD 支持 512 个快照，快照不支持 RGW；

Bulustore

必须使用默认的分配器；

成本规划

根据业务需求，制定合理规划，然后计算成本。如果成本较高，则缩减规模；

服务部署

1）on Kubernetes
2）with Cephadm

在生产环境中，Kubernetes Cluster，我们将使用 Rook Ceph 进行部署；

版本升级

升级顺序：
1）工具升级；
2）MON Daemon
3）OSD Daemon
4）MDS Daemon
5）RWS Daemon

参考文献

《Ceph 分布式存储实战, Ceph 中国社区, 2016》

Filed under: K4NZDROID - @ 2:21 AM