注意

本文档适用于 Ceph 开发版本。

硬件推荐

Ceph 设计用于在商用硬件上运行，这使得构建和维护 petabyte 级数据集群既灵活又经济可行。

一个 Ceph 集群的要求与另一个集群的要求并不相同，但以下是某些一般性指南。

提示

查看ceph 博客也。

CPU

CephFS 元数据服务器 (MDS) 是 CPU 密集型的。它们是单线程的，并且在高时钟频率（GHz）的 CPU 上表现最佳。除非它们也在托管其他服务（例如 CephFS 元数据池的 SSD OSD），否则 MDS 服务器不需要大量的 CPU 核心。OSD 节点需要足够的处理能力来运行 RADOS 服务、使用 CRUSH 计算数据放置、复制数据并维护它们自己的集群映射。

在 Ceph 的早期版本中，我们会根据每个 OSD 的核心数提出硬件建议，但这个每个 OSD 的核心数指标不再像每个 OSD 的 IOP 周期数和每个 OSD 的 IOPS 数那么有用。

提示

当我们提到 CPU核心时，我们的意思是线程当超线程启用时。超线程通常对 Ceph 服务器有益。

监控节点和管理节点对 CPU 的需求不高，只需要适度的处理器。如果您的主机除了 Ceph 守护进程之外还要运行 CPU 密集型进程，请确保您有足够的处理能力来同时运行 CPU 密集型进程和 Ceph 守护进程。（OpenStack Nova 是 CPU 密集型进程的一个例子。）我们建议您在单独的主机（即您的监控节点和管理节点）上运行非 Ceph 的 CPU 密集型进程，以避免资源争用。

RAM

通常，更多的 RAM 会更好。对于适度的集群，监控 / 管理节点可能可以很好地使用 64GB；对于拥有数百个 OSD 的大型集群，建议使用 128GB。

提示

当我们提到 RAM 和存储需求时，我们通常描述给定类型的一个守护进程的需求。因此，整个服务器将至少需要它所托管的所有守护进程的需求之和以及日志和其他操作系统组件的资源。请记住，服务器的 RAM 和存储需求在启动时以及组件失败或添加和集群重新平衡时会更大。换句话说，允许超出您在小初始集群足迹上看到的平静时期的使用量。

有一个osd_memory_targetBlueStore OSD 的设置默认为 4GB。请为操作系统和管理任务（如监控和指标）以及恢复期间的增加消耗考虑一个谨慎的边距：为每个 BlueStore OSD 提供 ~8GB因此建议。是

监控器和管理器 (ceph-mon 和 ceph-mgr)

监控和管理守护进程的内存使用量随集群的大小而变化。请注意，在启动时以及在进行拓扑更改和恢复期间，这些守护进程将需要比它们在稳定状态下运行时更多的 RAM，因此请为峰值使用量做准备。对于非常小的集群，32 GB 足够。对于最多有 300 个 OSD 的集群，请选择 64GB。对于构建或将要增长到更多 OSD 的集群，您应该提供 128GB。您还可以考虑调整以下设置：

元数据服务器 (ceph-mds)

CephFS 元数据守护进程的内存利用率取决于其配置的缓存大小。我们建议大多数系统使用 1 GB 作为最低值。参见mds_cache_memory_limit.

内存

Bluestore 使用它自己的内存来缓存数据，而不是依赖操作系统的页面缓存。在 Bluestore 中，您可以通过更改osd_memory_target configuration option.

  • 设置osd_memory_target低于 2GB 不建议。Ceph 可能无法将内存消耗保持在 2GB 以下，并且性能可能会非常慢。

  • 将内存目标设置在 2GB 和 4GB 之间通常可以正常工作，但可能会降低性能：除非活动数据集相对较小，否则元数据可能需要在磁盘上进行 IO 时从磁盘读取。

  • 4GB 是当前默认值osd_memory_target这个默认值是根据典型用例选择的，旨在平衡 RAM 成本和 OSD 性能。

  • 设置osd_memory_target高于 4GB 可以在有许多（小）对象或处理大型（256GB/OSD 或更多）数据集时提高性能。这在使用快速 NVMe OSD 时尤其如此。

重要

OSD 内存管理是“尽力而为”。虽然 OSD 可能会取消映射内存以允许内核回收它，但没有保证内核实际上会在特定时间范围内回收释放的内存。这特别适用于 Ceph 的旧版本，其中透明大页可以防止内核回收从碎片化大页释放的内存。Ceph 的现代版本在应用程序级别禁用透明大页以避免这种情况，但这并不能保证内核会立即回收未映射的内存。OSD 可能仍然会超出其内存目标。我们建议在您的系统上预算至少 20% 的额外内存，以防止 OSD 在临时峰值期间或由于内核回收释放的页面延迟而耗尽内存（O内存）。那 20% 的值可能更多或更少，具体取决于系统的确切配置。Of Memory) during temporary spikes or due to delay in the kernel reclaiming freed pages. That 20% value might be more or less than needed, depending on the exact configuration of the system.

提示

通过使用交换空间配置操作系统以提供额外的虚拟内存给守护进程不被建议用于现代系统。这样做可能会导致性能降低，您的 Ceph 集群可能会更高兴看到一个崩溃的守护进程，而不是一个缓慢的守护进程。

当使用传统的 FileStore 后端时，操作系统页面缓存用于缓存数据，因此通常不需要调整。当使用传统的 FileStore 后端时，OSD 内存消耗与系统中每个守护进程的 PG 数有关。

数据存储

仔细规划您的数据存储配置。在规划数据存储时，需要考虑重大的成本和性能权衡。同时的 OS 操作和来自多个守护进程对单个驱动器的读写操作的并发请求会影响性能。

OSD 需要大量的存储驱动器空间来存储 RADOS 数据。我们建议最小驱动器大小为 1 太字节。小于 1 太字节的 OSD 驱动器会使用其容量的很大一部分来存储元数据，而小于 100 吉字节的驱动器将完全无效。

建议至少为 Ceph 监控器、Ceph 管理器主机、CephFS 元数据服务器元数据池和 Ceph 对象网关 (RGW) 索引池提供（企业级）SSD，即使为批量 OSD 数据提供 HDD。strongly suggested that (enterprise-class) SSDs are provisioned for, at a minimum, Ceph Monitor and Ceph Manager hosts, as well as CephFS Metadata Server metadata pools and Ceph Object Gateway (RGW) index pools, even if HDDs are to be provisioned for bulk OSD data.

为了从 Ceph 中获得最佳性能，请在单独的驱动器上提供以下内容：

  • 操作系统

  • OSD 数据

  • BlueStore WAL+DB

更多关于如何在您的 Ceph 集群中有效地使用快速驱动器和慢速驱动器的信息，请参阅 Bluestore 配置参考的块和块.db section of the Bluestore Configuration Reference.

硬盘驱动器

仔细考虑较大驱动器的每 GB 成本优势。我们建议将驱动器的价格除以 GB 数以得出每 GB 的成本，因为较大驱动器可能会对每 GB 的成本产生重大影响。例如，一个价格为 75.00 美元的 1 太字节硬盘驱动器，每 GB 的成本为 0.07 美元（即 75 / 1024 = 0.0732）。相比之下，一个价格为 150.00 美元的 3 太字节驱动器，每 GB 的成本为 0.05 美元（即 150 / 3072 = 0.0488）。在前面的例子中，使用 1 太字节驱动器通常会提高每 GB 的成本 40%--使您的集群的效率大大降低。

提示

在单个 SAS / SATA 硬盘上托管多个 OSD 是不好的主意。 a good idea.

提示

在单个驱动器上托管 OSD 以及监控器、管理器或 MDS 数据也是不好的主意。 a good idea.

提示

对于旋转磁盘，SATA 和 SAS 接口在较大容量时越来越成为瓶颈。另请参阅存储网络行业协会的总体拥有成本计算器.

存储驱动器受寻道时间、访问时间、读写时间和总吞吐量的限制。这些物理限制会影响整体系统性能--尤其是在恢复期间。我们建议为操作系统和软件使用专用（最好是镜像）驱动器，并为主机上运行的每个 Ceph OSD 守护进程使用一个驱动器。

固态驱动器

使用固态驱动器 (SSD) 可以显著提高 Ceph 性能。这减少了随机访问时间并减少了延迟，同时提高了吞吐量。

SSD 每 GB 的成本比 HDD 高，但 SSD 的访问时间至少比 HDD 快 100 倍。

SSD 没有移动机械部件，因此它们不受 HDD 许多限制的影响。然而，SSD 也有重大的限制。在评估 SSD 时，重要的是要考虑顺序和随机读写的性能。

重要

我们建议探索使用 SSD 来提高性能。但是，在投资 SSD 之前，我们强烈建议审查 SSD 的性能指标并在测试配置中测试 SSD，以评估性能。

相对廉价的 SSD 可能会吸引您的经济意识。请谨慎使用。在选择用于 Ceph 的 SSD 时，可接受的 IOPS 不是唯一要考虑的因素。与 Ceph 一起使用的廉价 SSD 往往是一种虚假的经济效益：它们可能会经历“悬崖”，这意味着在初始突发之后，当有限缓存填满时，持续性能会大幅下降。还要考虑耐用性：一个额定为每天 0.3 个驱动器写入（DWPD 或等效）的驱动器可能适合专门用于某些类型顺序写入的只读数据的 OSD，但它们不适合 Ceph 监控任务。企业级 SSD 对 Ceph 最适合：它们几乎都具备电源丢失保护 (PLP)，并且不会像客户端（台式机）型号那样经历剧烈的悬崖。

当使用单个（或镜像对）SSD 同时用于操作系统启动和 Ceph 监控器 / 管理器目的时，建议最小容量为 256GB，至少推荐 480GB。建议选择 1+ DWPD（或 TBW（TeraBytes Written）的等效值）的驱动器型号。然而，对于给定的写入工作负载，比技术上需要的更大的驱动器将提供更多的耐久性，因为它实际上具有更大的过度配置。我们强调，对于生产使用，企业级驱动器最佳，因为它们比旨在用于非常轻的和间歇性工作周期的客户端（台式机）SKU 具有更好的电源丢失保护和更高的耐用性。

历史上，SSD 对对象存储的成本过高，但 QLC SSD 正在缩小差距，提供更高的密度、更低的功耗和更少的用于冷却的功耗。此外，通过将 WAL+DB 转移到 SSD，HDD OSD 可能会看到写入延迟的显著改善。许多 Ceph OSD 部署不需要比 1 DWPD（即“只读优化”）具有更高耐久性的 SSD。3 DWPD 类中的“混合使用” SSD 通常对此目的来说过于奢侈，并且成本显著更高。

要更好地了解决定存储总成本的因素，您可能会使用存储网络行业协会的总体拥有成本计算器

分区对齐

当使用 SSD 与 Ceph 一起使用时，请确保您的分区正确对齐。未正确对齐的分区比正确对齐的分区数据传输速度慢。有关正确分区对齐的更多信息以及显示如何正确对齐分区的示例命令，请参阅Werner Fischer 的关于分区对齐的博客文章.

CephFS 元数据隔离

Ceph 加速 CephFS 文件系统性能的一种方法是通过将 CephFS 元数据的存储与 CephFS 文件内容的存储分离。metadata池用于 CephFS 元数据。您永远不会需要手动为 CephFS 元数据创建池，但您可以创建一个仅包含 SSD 存储媒体的 CephFS 元数据池的 CRUSH 映射层次结构。参见CRUSH 设备类 for details.

控制器

磁盘控制器 (HBAs) 对写入吞吐量有显著影响。仔细考虑您对 HBAs 的选择，以确保它们不会创建性能瓶颈。值得注意的是，RAID 模式（IR）HBAs 可能比简单的“JBOD”（IT）模式 HBAs 表现出更高的延迟。RAID SoC、写入缓存和电池备份可以显著增加硬件和维护成本。许多 RAID HBA 可以配置为 IT 模式“个性”或“JBOD 模式”以进行简化操作。

您不需要 RoC（RAID 能力）HBA。ZFS 或 Linux MD 软件镜像对于启动卷的持久性很有用。当使用 SAS 或 SATA 数据驱动器时，放弃 HBA RAID 功能可以缩小 HDD 和 SSD 媒体成本之间的差距。此外，当使用 NVMe SSD 时，您不需要任何HBA。这此外减少了 HDD 与 SSD 成本差距，当考虑整个系统时。一个带有板载缓存和电池备份（BBU 或超级电容器）的时尚 RAID HBA 的初始成本即使打折后也可能超过 1000 美元——这些钱可以大大缩小 SSD 成本平价。无 HBA 系统也可能每年便宜数百美元，如果您购买年度维护合同或延长保修。

提示

The Ceph 博客通常是 Ceph 性能问题信息的绝佳来源。参见Ceph 写入吞吐量 1和Ceph 写入吞吐量 2以获取更多详细信息。

基准测试

BlueStore 以O_DIRECT频繁地打开存储设备并发出fsync()确保数据安全地持久化到媒体。您可以使用fio来评估驱动器的低级写入性能。例如，4kB 随机写入性能的测量如下：

# fio --name=/dev/sdX --ioengine=libaio --direct=1 --fsync=1 --readwrite=randwrite --blocksize=4k --runtime=300

写入缓存

企业级 SSD 和 HDD 通常包括电源丢失保护功能，可在操作时丢失电源时确保数据持久性，并使用多级缓存来加快直接或同步写入。这些设备可以在两种缓存模式之间切换——一个易失性缓存被刷新到持久媒体，使用 fsync，或者一个非易失性缓存同步写入。

这两种模式通过“启用”或“禁用”写入（易失性）缓存来选择。当易失性缓存启用时，Linux 使用“写入回退”模式的设备，当禁用时，它使用“写入直通”。

默认配置（通常：缓存已启用）可能不是最佳的，禁用此写入缓存可以通过增加 IOPS 和减少提交延迟来显着提高 OSD 性能。

因此，鼓励用户使用fio如前所述的那样对设备进行基准测试，并持久化设备的最佳缓存配置。

可以使用hdparm, sdparm, smartctl或通过读取/sys/class/scsi_disk/*/cache_type中的值来查询缓存配置，例如：

# hdparm -W /dev/sda

/dev/sda:
 write-caching =  1 (on)

# sdparm --get WCE /dev/sda
    /dev/sda: ATA       TOSHIBA MG07ACA1  0101
WCE           1  [cha: y]
# smartctl -g wcache /dev/sda
smartctl 7.1 2020-04-05 r5049 [x86_64-linux-4.18.0-305.19.1.el8_4.x86_64] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

Write cache is:   Enabled

# cat /sys/class/scsi_disk/0\:0\:0\:0/cache_type
write back

可以使用相同的工具禁用写入缓存：

# hdparm -W0 /dev/sda

/dev/sda:
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)

# sdparm --clear WCE /dev/sda
    /dev/sda: ATA       TOSHIBA MG07ACA1  0101
# smartctl -s wcache,off /dev/sda
smartctl 7.1 2020-04-05 r5049 [x86_64-linux-4.18.0-305.19.1.el8_4.x86_64] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF ENABLE/DISABLE COMMANDS SECTION ===
Write cache disabled

在大多数情况下，使用hdparm, sdparm或smartctl禁用此缓存，结果会自动将 cache_type 更改为“写入直通”。如果情况不是这样，您可以尝试直接设置它，如下所示。（用户应确保设置 cache_type 也正确地持久化设备的缓存模式，直到下次启动为止，因为某些驱动器需要在每次启动时重复此操作）：

# echo "write through" > /sys/class/scsi_disk/0\:0\:0\:0/cache_type

# hdparm -W /dev/sda

/dev/sda:
 write-caching =  0 (off)

提示

此 udev 规则（在 CentOS 8 上测试）将所有 SATA/SAS 设备的 cache_types 设置为“写入直通”：

# cat /etc/udev/rules.d/99-ceph-write-through.rules
ACTION=="add", SUBSYSTEM=="scsi_disk", ATTR{cache_type}:="write through"

提示

此 udev 规则（在 CentOS 7 上测试）将所有 SATA/SAS 设备的 cache_types 设置为“写入直通”：

# cat /etc/udev/rules.d/99-ceph-write-through-el7.rules
ACTION=="add", SUBSYSTEM=="scsi_disk", RUN+="/bin/sh -c 'echo write through > /sys/class/scsi_disk/$kernel/cache_type'"

提示

The sdparmutility 可以用于同时查看/更改多个设备的易失性写入缓存：

# sdparm --get WCE /dev/sd*
    /dev/sda: ATA       TOSHIBA MG07ACA1  0101
WCE           0  [cha: y]
    /dev/sdb: ATA       TOSHIBA MG07ACA1  0101
WCE           0  [cha: y]
# sdparm --clear WCE /dev/sd*
    /dev/sda: ATA       TOSHIBA MG07ACA1  0101
    /dev/sdb: ATA       TOSHIBA MG07ACA1  0101

其他考虑因素

Ceph 运营商通常在每个主机上配置多个 OSD，但您应确保您的 OSD 驱动器的总吞吐量不超过服务客户端读写操作所需的网络带宽。您还应考虑每个主机占集群总容量的百分比。如果位于特定主机上的百分比很大并且主机发生故障，它可能会导致问题，例如恢复导致 OSD 超过full ratio，这反过来又会导致 Ceph 停止操作以防止数据丢失。

当您在每个主机上运行多个 OSD 时，您还需要确保内核是最新的。参见操作系统推荐关于glibc和syncfs(2)的注释，以确保当您在每个主机上运行多个 OSD 时，硬件按预期执行。

网络

在您的数据中心中至少提供 10 Gb/s 网络连接，无论是在 Ceph 主机之间，还是在客户端和您的 Ceph 集群之间。强烈建议跨不同的网络交换机进行网络链路主动/主动绑定，无论是为了提高吞吐量，还是为了容忍网络故障和维护。请小心，您的绑定哈希策略应将流量分布在链路上。

速度

在 1 Gb/s 网络上复制 1 TB 的数据需要三小时，在 1 Gb/s 网络上复制 10 TB 需要 30 小时。但是，在 10 Gb/s 网络上复制 1 TB 只需 20 分钟，在 10 Gb/s 网络上复制 10 TB 只需一小时。

请注意，40 Gb/s 网络链路实际上相当于四个 10 Gb/s 通道并行，而 100Gb/s 网络链路实际上相当于四个 25 Gb/s 通道并行。因此，并且可能有些反直觉，25 Gb/s 网络上的单个数据包与 40 Gb/s 网络上的延迟略低。

成本

Ceph 集群越大，OSD 故障就越常见。放置组 (PG) 从降级状态恢复到active + clean状态越快，就越好。值得注意的是，快速恢复最大限度地减少了多个重叠故障的可能性，这些故障可能会导致数据暂时不可用甚至丢失。当然，在规划您的网络时，您必须在价格和性能之间进行权衡。

一些部署工具使用 VLAN 来使硬件和网络布线更易于管理。使用 802.1q 协议的 VLAN 要求 VLAN 能力的 NIC 和交换机。这种硬件的额外费用可能会被网络设置和维护的运营成本节省所抵消。当使用 VLAN 处理集群和计算堆栈（例如 OpenStack、CloudStack 等）之间的 VM 流量时，使用 10 Gb/s 以太网或更好的网络的价值更大；截至 2022 年，生产集群通常使用 40 Gb/s 或越来越多的 25/50/100 Gb/s 网络连接。

机架顶部 (TOR) 交换机也需要快速且冗余的上行链路连接到核心 / 脊干网络交换机或路由器，通常至少为 40 Gb/s。

基板管理控制器 (BMC)

您的服务器机架应具有基板管理控制器 (BMC)。众所周知的例子是 iDRAC（戴尔）、CIMC（思科 UCS）和 iLO（惠普）。管理和部署工具也可能广泛使用 BMC，尤其是通过 IPMI 或 Redfish，因此请考虑带外网络的成本效益权衡，以实现安全和管理的目的。虚拟机 SSH 访问、虚拟机镜像上传、操作系统镜像安装、管理套接字等可能会对网络造成很大负担。运行多个网络可能看起来像过度设计，但每个流量路径都代表一个潜在的容量、吞吐量和/或性能瓶颈，在部署大规模数据集群之前，您应仔细考虑。

此外，截至 2023 年，BMC 很少提供比 1 Gb/s 更快的网络连接，因此为 BMC 管理流量使用专用且廉价的 1 Gb/s 交换机可能会通过浪费更少的昂贵端口来降低成本。

故障域

失效域可以被认为是一旦阻止访问一个或多个 OSD 或其他 Ceph 守护进程的任何组件损失。这可能是一个主机上的停止守护进程；一个存储驱动器故障、操作系统崩溃、故障的 NIC、电源供应故障、网络中断、电源中断等等。在规划您的硬件部署时，您必须权衡通过将太多责任放在太少故障域中来降低成本的风险，以及隔离每个潜在故障域所带来的额外成本。

最低硬件推荐

Ceph 可以在廉价的商用硬件上运行。小型生产集群和开发集群可以成功地使用适度的硬件。如上所述：当我们提到 CPU核心时，我们的意思是线程当超线程 (HT) 启用时。每个现代物理 x64 CPU 核心通常提供两个逻辑 CPU 线程；其他 CPU 架构可能会有所不同。

请注意，有许多因素会影响资源选择。一个目的足够的最低资源可能并不足以满足另一个目的。一个在笔记本电脑上基于 VirtualBox 或在三个树莓派上构建的沙盒集群将比一个拥有 1000 个 OSD 并为 5000 个 RBD 客户端提供服务的大型生产部署使用更少的资源。经典的 Fisher Price PXL 2000 捕获视频，IMAX 或 RED 摄像机也是如此。人们不会期望前者能完成后者的工作。我们尤其不能强调使用企业级存储媒体对于生产工作负载的临界重要性。

关于生产集群资源规划的更多见解可以在本文档的其他地方找到。

过程

标准

最小值和推荐值

ceph-osd

处理器

  • 1 核最小，2 核推荐

  • 每 200-500 MB/s 吞吐量 1 核

  • 每 1000-3000 IOPS 1 核

  • 结果是在复制之前。

  • 结果可能因 CPU 和驱动器型号以及 Ceph 配置（如纠删编码、压缩等）而有所不同：

  • ARM 处理器特别可能需要更多核心才能获得性能。

  • SSD OSD，尤其是 NVMe，将受益于每个 OSD 的额外核心。

  • 实际性能取决于许多因素，包括驱动器、网络和

RAM

  • 每个守护进程 4GB+（更多更好）

  • 2-4GB 可能可以工作，但可能会很慢

  • 少于 2GB 不建议

存储驱动器

每个 OSD 1x 存储驱动器

DB/WAL

每个 HDD OSD 1x SSD 分区

网络

1x 1Gb/s（建议绑定 10+ Gb/s）

ceph-mon

处理器

  • 2 核最小

RAM

每个守护进程 5GB+（大型/生产集群需要更多）

存储

每个守护进程 100 GB，推荐使用 SSD

网络

1x 1Gb/s（建议 10+ Gb/s）

ceph-mds

处理器

  • 2 核最小

RAM

每个守护进程 2GB+（生产需要更多）

磁盘空间

每个守护进程 1 GB

网络

1x 1Gb/s（建议 10+ Gb/s）

提示

如果您正在运行具有单个存储驱动器的 OSD 节点，请为您的 OSD 创建一个与包含操作系统的分区分开的分区。我们建议为操作系统和 OSD 存储使用单独的驱动器。

由 Ceph 基金会带给您

Ceph 文档是一个社区资源，由非盈利的 Ceph 基金会资助和托管Ceph Foundation. 如果您想支持这一点和我们的其他工作，请考虑加入现在加入.