2 硬件要求和建议 #
Ceph 的硬件要求在很大程度上取决于 IO 工作负载。在着手进行详细规划时，应考虑以下硬件要求和建议。
一般情况下，本节所述的建议是按进程提出的。如果同一台计算机上有多个进程，则需要提高 CPU、RAM、磁盘和网络要求。
2.1 多体系结构配置 #
SUSE Enterprise Storage 支持 x86 和 Arm 体系结构。考虑每个体系结构时，请务必注意从每个 OSD 的内核数、频率和 RAM 的角度而言，不同的 CPU 体系结构在大小调整方面并无实际差异。
与较小的 x86 处理器（非服务器）一样，性能较低的基于 Arm 的内核可能无法提供最佳体验，特别是用于纠删码存储池时。
2.2 最低集群配置 #
至少需要四个 OSD 节点，每个节点包含八个 OSD 磁盘。
三个 Ceph Monitor 节点（需要使用 SSD 作为专用 OS 驱动器）
iSCSI 网关、对象网关和元数据服务器需要递增的 4 GB RAM 和四个内核。
Ceph Monitor、对象网关和元数据服务器的节点需要冗余部署。
具有 4 GB RAM、四个内核和 1 TB 容量的独立管理节点，通常是 Salt Master 节点。管理节点上不支持 Ceph Monitor、Ceph Manager、元数据服务器、Ceph OSD、对象网关或 NFS Ganesha 等 Ceph 服务和网关。
2.3 对象存储节点 #
2.3.1 最低要求 #
CPU 建议：
每个旋转磁盘 1x 2GHz CPU 线程
每个 SSD 2x 2GHz CPU 线程
每个 NVMe 磁盘 4x 2GHz CPU 线程
独立的 10 GbE 网络（公共/客户端和后端），需要 4x 10 GbE，建议 2x 25 GbE。
总计所需 RAM = OSD 数量 x (1 GB +
osd_memory_target) + 16 GB有关
osd_memory_target的更多详细信息，请参见第 16.2.1 节 “自动调整缓存大小”。OSD 磁盘采用 JBOD 配置或单独的 RAID-0 配置。
OSD 日记可以驻留在 OSD 磁盘上.
OSD 磁盘应该专门由 SUSE Enterprise Storage 使用。
操作系统专用的磁盘/SSD，最好采用 RAID 1 配置。
如果此 OSD 主机将要托管用于缓存分层的一部分缓存池，请至少额外分配 4 GB RAM。
Ceph Monitor、网关和元数据服务器可以驻留在对象存储节点上.
考虑到磁盘性能，我们建议使用裸机作为 OSD 节点，而不要使用虚拟机。
2.3.2 最小磁盘大小 #
需要在 OSD 上运行以下两种类型的磁盘空间：磁盘日记（针对 FileStore）或 WAL/DB 设备（针对 BlueStore）的空间以及存储数据的主空间。日记/WAL/DB 的最小（默认）值为 6 GB。数据的最小空间为 5 GB，因为系统会自动为小于 5 GB 的分区指定权重 0。
因此，尽管 OSD 的最小磁盘空间为 11 GB，但不建议使用小于 20 GB 的磁盘，即使在测试中也是如此。
2.3.3 BlueStore 的 WAL 和 DB 设备的建议大小 #
我们建议为 WAL 设备预留 4 GB。对于大多数工作负载而言，建议的 DB 大小为 64 GB。
如果您打算将 WAL 和 DB 设备置于同一磁盘，建议您为这两个设备使用一个分区，而不是为每个设备使用单独的分区。这样，Ceph 便可以使用 DB 设备来执行 WAL 操作。这对于磁盘空间的管理也会更有效，因为 Ceph 只会在需要时才会为 WAL 使用 DB 分区。另一个好处是，WAL 分区填满的可能性很小，当该分区未完全利用时，其空间并不会浪费，而是用于 DB 操作。
要与 WAL 共享 DB 设备，请不要指定 WAL 设备，而是仅指定 DB 设备。
有关指定 OSD 布局的详细信息，请参见第 5.5.2 节 “DriveGroups”。
2.3.4 使用 SSD 存储 OSD 日记 #
固态硬盘 (SSD) 不包含移动部件。这可以减少随机访问时间和读取延迟，同时加快数据吞吐量。由于 SSD 的每 MB 价格大大高于旋转型硬盘，SSD 只适用于较小规模的存储。
如果将日记存储在 SSD 上，并将对象数据存储在独立的硬盘上，OSD 的性能会得到大幅提高。
提示：在一个 SSD 中共享多个日记
由于日记数据占用的空间相对较小，因此您可以将多个日记目录装入单个 SSD 磁盘。请注意，每共享一个日记，SSD 磁盘的性能就会有所下降。不建议在同一个 SSD 磁盘中共享 6 个以上的日记，或者在 NVMe 磁盘中共享 12 个以上的日记。
2.3.5 磁盘的最大建议数量 #
您可以在一台服务器上使用所允许的任意数量的磁盘。规划每台服务器的磁盘数量时，需要考虑以下几点：
网络带宽：在一台服务器中使用的磁盘越多，执行磁盘写入操作时必须通过网卡传输的数据就越多。
内存：系统会将超过 2 GB 的 RAM 用于 BlueStore 缓存。当
osd_memory_target设置为默认值 4 GB 时，该起始缓存大小对于旋转介质而言是比较合理的。如果使用 SSD 或 NVME，请考虑增加缓存大小以及分配给每个 OSD 的 RAM，以便最大限度提高性能。容错：整台服务器发生故障时，该服务器包含的磁盘越多，则集群暂时丢失的 OSD 就越多。此外，为了确保复制规则的运行，需要将有故障服务器中的所有数据复制到集群中的其他节点。
2.4 Monitor 节点 #
至少需要三个 Ceph Monitor 节点。Monitor 数量应始终为奇数 (1+2n)。
4 GB RAM。
有四个逻辑内核的处理器。
强烈建议对 Monitor 使用 SSD 或其他速度足够快的存储类型，特别是针对每个 Monitor 节点上的
/var/lib/ceph路径，因为仲裁可能不稳定且磁盘延迟较高。建议提供两个采用 RAID 1 配置的磁盘来实现冗余。建议对 Monitor 进程使用独立的磁盘，或者至少是独立的磁盘分区，以防止日志文件缓增等问题导致 Monitor 的可用磁盘空间不足。每个节点只能有一个 Monitor 进程。
仅当有足够的硬件资源可用时，才支持混用 OSD、Monitor 或对象网关节点。这意味着，对于所有服务需要提高相应要求。
与多个交换机绑定的两个网络接口。
2.5 对象网关节点 #
对象网关节点应有 6 到 8 个 CPU 内核和 32 GB RAM（建议 64 GB）。如果将其他进程共置在同一台计算机上，则需要提高资源的要求。
2.6 元数据服务器节点 #
元数据服务器节点的适当大小取决于特定用例。一般而言，元数据服务器需要处理的打开文件越多，所需要的 CPU 和 RAM 就越多。以下是最低要求：
为每个元数据服务器守护进程分配 3 GB 的 RAM。
绑定网络接口。
2.5 GHz CPU，至少有两个内核。
2.7 Salt Master #
至少需要 4 GB RAM 和四核 CPU。其中包括在管理节点上运行 Ceph Dashboard。对于包含数百个节点的大型集群，建议提供 6 GB RAM。
2.8 iSCSI 节点 #
iSCSI 节点应有 6 到 8 个 CPU 内核和 16 GB RAM。
2.9 网络建议 #
要运行 Ceph 的网络环境最好是至少包含两个网络接口的绑定组合，该组合使用 VLAN 逻辑分割为公共部分和可信的内部部分。如果可能，建议采用 802.3ad 绑定模式，以提供最高的带宽和恢复能力。
公共 VLAN 用于向客户提供服务，而内部部分则用于提供经身份验证的 Ceph 网络通讯。建议采用此模式的主要原因在于，尽管 Ceph 可提供身份验证并在创建秘密密钥后防范攻击，但用于配置这些密钥的讯息可能会公开传输，因而容易受到攻击。
提示：通过 DHCP 配置的节点
如果存储节点是通过 DHCP 配置的，则默认超时可能会不够长，无法保证在各个 Ceph 守护进程启动前正确配置网络。如果发生此问题，Ceph MON 和 OSD 将不会正常启动（运行 systemctl status ceph\* 会导致“无法绑定”错误）。为避免此问题发生，建议在存储集群的每个节点上，将 DHCP 客户端超时增加到至少 30 秒。为此，可在每个节点上更改以下设置：
在 /etc/sysconfig/network/dhcp 中，设置
DHCLIENT_WAIT_AT_BOOT="30"
在 /etc/sysconfig/network/config 中，设置
WAIT_FOR_INTERFACES="60"
2.9.1 将专用网添加到正在运行的集群 #
如果您在部署 Ceph 期间未指定集群网络，则系统假设使用的是单个公共网络环境。尽管 Ceph 可在公共网络中正常运行，但如果您设置了另一个专用集群网络，Ceph 的性能和安全性将会得到提升。要支持两个网络，每个 Ceph 节点上至少需有两个网卡。
需要对每个 Ceph 节点应用以下更改。对小型集群执行此操作的速度相对较快，但如果集群包含数百甚至数千个节点，则此过程可能十分耗时。
在每个集群节点上停止 Ceph 相关的服务。
在
/etc/ceph/ceph.conf中添加一行以定义集群网络，例如：cluster network = 10.0.0.0/24
如果需要指定具体的静态 IP 地址或覆盖
cluster network设置，可以使用可选的cluster addr实现此目的。检查专用集群网络是否在 OS 级别按预期工作。
在每个集群节点上启动 Ceph 相关的服务。
root #systemctl start ceph.target
2.9.2 不同子网中的 Monitor 节点 #
如果 Monitor 节点位于多个子网中，例如，位于不同的机房并由不同的交换机提供服务，则您需要相应地调整 ceph.conf 文件。例如，如果节点的 IP 地址为 192.168.123.12、1.2.3.4 和 242.12.33.12，请将以下几行添加到 global 段落：
[global] [...] mon host = 192.168.123.12, 1.2.3.4, 242.12.33.12 mon initial members = MON1, MON2, MON3 [...]
此外，如果您需要指定每个 Monitor 的公用地址或网络，则需要为每个 Monitor 添加 [mon.X] 段落：
[mon.MON1] public network = 192.168.123.0/24 [mon.MON2] public network = 1.2.3.0/24 [mon.MON3] public network = 242.12.33.12/0
2.10 命名限制 #
一般情况下，Ceph 不支持在配置文件、存储池名称、用户名等内容中使用非 ASCII 字符。配置 Ceph 集群时，建议在所有 Ceph 对象/配置名称中仅使用简单的字母数字字符（A-Z、a-z、0-9）和最少量的标点符号（“.”、“-”、“_”）。
2.11 共享一台服务器的 OSD 和 Monitor #
尽管从技术上讲可在测试环境中的同一台服务器上运行 Ceph OSD 和 Monitor，但强烈建议在生产环境中为每个 Monitor 节点使用独立的服务器。主要原因在于性能 — 集群包含的 OSD 越多，Monitor 节点需要执行的 I/O 操作就越多。另外，在 Monitor 节点与 OSD 之间共享一台服务器时，OSD I/O 操作将会成为 Monitor 节点的限制因素。
另一个考虑要点是，是否要在 OSD、Monitor 节点与服务器上的操作系统之间共享磁盘。答案非常简单：如果可能，请将一个独立的磁盘专门用于 OSD，并将一台独立的服务器用于 Monitor 节点。
尽管 Ceph 支持基于目录的 OSD，但 OSD 应始终包含一个专用磁盘，而不能与操作系统共享一个磁盘。
提示
如果确实有必要在同一台服务器上运行 OSD 和 Monitor 节点，请将一个独立磁盘装入 /var/lib/ceph/mon 目录以在该磁盘上运行 Monitor，这样可以稍微改善性能。
2.12 建议的生产集群配置 #
七个对象存储节点
单个节点不超过总容量的 15% 左右
10 Gb 以太网（与多个交换机绑定的四个物理网络）
每个存储集群有 56 个以上的 OSD
每个 OSD 存储节点包含 RAID 1 OS 磁盘
根据 6:1 的 SSD 日记与 OSD 的比率为日记提供 SSD
在每个对象存储节点上，为每 TB 的原始 OSD 容量提供 1.5 GB RAM
为每个对象存储节点上的每个 OSD 提供 2 GHz
专用的物理基础架构节点
三个 Ceph Monitor 节点：4 GB RAM，四核处理器，RAID 1 SSD 磁盘
一个 SES 管理节点：4 GB RAM，四核处理器，RAID 1 SSD 磁盘
网关或元数据服务器节点的冗余物理部署：
对象网关节点：32 GB RAM，八核处理器，RAID 1 SSD 磁盘
iSCSI 网关节点：16 GB RAM，四核处理器，RAID 1 SSD 磁盘
元数据服务器节点（一个工作/一个热待机）：32 GB RAM，八核处理器，RAID 1 SSD 磁盘