注意
本文档适用于 Ceph 的开发版本。
硬件建议
Ceph 旨在运行在商用硬件上，这使得构建和维护 PB 级数据集群变得灵活且在经济上可行。在规划集群的硬件时，您需要平衡多种考虑因素，包括故障域、成本和性能。硬件规划应包括将 Ceph 守护程序和使用 Ceph 的其他进程分散到多个主机上。通常，我们建议在配置用于特定类型守护程序的主机上运行该类型的 Ceph 守护程序。我们建议对利用数据集群的进程（例如 OpenStack、OpenNebula、CloudStack、Kubernetes 等）使用单独的主机。
一个 Ceph 集群的要求与另一个集群的要求不尽相同，但下面是一些一般准则。
重要
请注意，截至 2025 年 12 月，ARM 架构容器提供的守护程序集是有限的。例如，尚不支持 SMB 服务。
提示
也请查看 ceph 博客。
CPU
CephFS 元数据服务器 (MDS) 是 CPU 密集型的。它们是单线程的，在高时钟速率 (GHz) 的 CPU 上表现最佳。MDS 服务器不需要大量的 CPU 核心，除非它们还托管其他服务，例如用于 CephFS 元数据池的 SSD OSD。OSD 节点需要足够的处理能力来运行 RADOS 服务、使用 CRUSH 计算数据放置、复制数据以及维护自己的集群地图副本。
在 Ceph 的早期版本中，我们会根据每个 OSD 的核心数提出硬件建议，但这种“每个 OSD 的核心数”指标不再像“每个 IOP 的周期数”和“每个 OSD 的 IOPS 数”那样有用。例如，对于 NVMe OSD 驱动器，Ceph 在实际集群中可以轻松利用五到六个核心，在单独的单个 OSD 上可以利用多达大约十四个核心。因此，每个 OSD 的核心数不再像以前那样是一个紧迫的问题。选择硬件时，请选择每核心 IOPS。
提示
当我们谈论 CPU 核心 时，如果启用了超线程，我们指的是线程。超线程通常对 Ceph 服务器有利。
监视器节点和管理器节点对 CPU 的要求不高，只需要适度的处理器。如果您的主机除了 Ceph 守护程序之外还将运行 CPU 密集型进程，请确保您有足够的处理能力来同时运行 CPU 密集型进程和 Ceph 守护程序。（OpenStack Nova 是一个 CPU 密集型进程的例子。）我们建议您在单独的主机上运行非 Ceph CPU 密集型进程（即，不在您的监视器和管理器节点上的主机），以避免资源争用。如果您的集群部署了 Ceph 对象网关，如果节点具有足够的资源，RGW 守护程序可以与您的 Mon 和 Manager 服务共存。
RAM
通常，RAM 越多越好。对于适度规模的集群，监视器/管理器节点使用 64GB 可能就足够了；对于拥有数百个 OSD 的大型集群，建议使用 128GB。
提示
当我们谈论 RAM 和存储要求时，我们通常描述给定类型的单个守护程序的需求。因此，作为整体的给定服务器将需要至少承载的守护程序的需求总和，以及用于日志和其他操作系统组件的资源。请记住，服务器对 RAM 和存储的需求在启动时以及组件发生故障或添加时集群重新平衡期间会更大。换句话说，在小型初始集群中平静时期看到的使用量之外留出余量。
BlueStore OSD 有一个 osd_memory_target 设置，默认为 4 GiB。为操作系统和管理任务（如监控和指标）以及恢复期间增加的消耗考虑一个审慎的余量。我们建议确保总服务器 RAM 大于（OSD 数量 * osd_memory_target * 2），这允许操作系统和其他 Ceph 守护程序的使用。因此，一个具有 8-10 个 OSD 的 1U 服务器配备 128 GB 物理内存是绰绰有余的。启用 osd_memory_target_autotune 有助于避免在重负载下或当非 OSD 守护程序迁移到节点上时发生 OOM（Out Of Memory）。至少 6 GiB 的有效 osd_memory_target 有助于减轻 HDD OSD 上的慢速请求。
监视器和管理器 (ceph-mon and ceph-mgr)
监视器和管理器内存使用量随集群大小而扩展。请注意，在引导时以及拓扑更改和恢复期间，这些守护程序需要的 RAM 会比在稳定状态操作期间更多，因此请规划峰值使用量。对于非常小的集群，32 GB 就足够了。对于多达 300 个 OSD 的集群，建议使用 64GB。对于使用（或将增长到）更多 OSD 的集群，您应该配置 128GB。您可能还希望考虑调整以下设置
rocksdb_cache_size
元数据服务器 (ceph-mds)
CephFS 元数据守护程序的内存利用率取决于其配置的缓存大小。对于大多数系统，我们建议最低为 1 GiB。请参阅 mds_cache_memory_limit。
内存
BlueStore 使用自己的内存来缓存数据，而不是依赖操作系统的页面缓存。使用 BlueStore OSD 后端时，您可以通过更改 osd_memory_target 配置选项来调整 OSD 尝试消耗的内存量。
不建议将
osd_memory_target设置低于 2GB。Ceph 可能无法将内存消耗保持在 2GB 以下，并且极有可能导致性能极其缓慢。将内存目标设置在 2GB 到 4GB 之间通常可以工作，但可能会导致性能下降：除非活动数据集相对较小，否则 IO 期间可能需要从磁盘读取元数据。
4GB 是
osd_memory_target的当前默认值。选择此默认值是为了典型的用例，旨在平衡 RAM 成本和 OSD 性能。当有许多（小）对象或处理大型（256GB/OSD 或更多）数据集时，将
osd_memory_target设置高于 4GB 可以提高性能。对于快速的 NVMe OSD 尤其如此。
重要
OSD 内存管理是“尽力而为”的。尽管 OSD 可能会取消映射内存以允许内核回收，但不能保证内核会在特定的时间范围内实际回收释放的内存。这尤其适用于较旧版本的 Ceph，其中透明大页可能阻止内核回收从碎片大页中释放的内存。现代版本的 Ceph 会在应用程序级别禁用透明大页以避免这种情况，但这不能保证内核会立即回收未映射的内存。OSD 有时仍可能超出其内存目标。我们建议在系统上预算至少 20% 的额外内存，以防止 OSD 在临时峰值期间或由于内核回收释放页面的延迟而发生 OOM（Out Of Memory）。这 20% 的值可能多于或少于所需，具体取决于系统的确切配置。
提示
不建议配置操作系统使用交换空间来为守护程序提供额外的虚拟内存。这样做可能会导致性能下降，并且您的 Ceph 集群可能更喜欢崩溃的守护程序，而不是运行缓慢的守护程序。
使用传统的 Filestore 后端时，操作系统页面缓存用于缓存数据，因此通常不需要调整。OSD 内存消耗与工作负载及其服务的 PG 数量相关。BlueStore OSD 不使用页面缓存，因此建议使用自动调谐器以确保充分但审慎地使用 RAM。
数据存储
仔细规划您的数据存储配置：需要考虑重大的成本和性能权衡。常规的操作系统操作以及来自多个守护程序对单个驱动器的同时读写请求可能会影响性能和稳定性。
OSD 需要大量的存储驱动器空间来存储 RADOS 数据。我们建议 OSD 的最小大小为 1 tebibyte (TiB)。远小于此的 OSD 驱动器会将很大一部分容量用于元数据，而小于 100 GiB 的驱动器将根本不起作用。
强烈建议为运行或可能运行 Ceph Monitor 和 Ceph Manager 守护程序的主机配置（企业级）SSD。即使为大容量 OSD 数据配置了 HDD，CephFS 元数据服务器元数据池和 Ceph 对象网关 (RGW) 索引和日志池也需要 SSD 才能在企业规模上有效。值得注意的是，如果 RGW 部署使用 HDD 进行大容量对象存储桶数据，则应将所有其他池配置在 SSD 上。
为了从 Ceph 中获得最佳性能，请在单独的驱动器上配置以下各项：
操作系统
OSD 数据
BlueStore WAL+DB（用于 HDD OSD）
有关如何在 Ceph 集群中有效使用混合快速驱动器和慢速驱动器的更多信息，请参阅 BlueStore 配置参考中的 block 和 block.db 部分。
硬盘驱动器
仔细考虑大容量 HDD 每千兆字节的表面成本优势，以及随之而来的每 TB IOPS 限制。
提示
在单个 SAS / SATA HDD 上托管多个 OSD 不是一个好主意。在大多数情况下，单个 OSD 应该配置在单个介质上，除非是大于 30 TB 的 SSD。
提示
在同一驱动器上将 OSD 与 Monitor、Manager 或 MDS 数据放在一起也不是一个好主意。
提示
对于 HDD，接口在大容量下越来越成为瓶颈。不仅要考虑单个存储驱动器上的接口，还要考虑整个系统。具有 SAS / SATA 端口的服务器机箱通过背板连接多个驱动器，背板本身可能成为瓶颈。对于密集型机箱尤其如此，其中 24、36 甚至 100 个驱动器可能会争用资源。可容纳超过 8 个 SAS / SATA 驱动器的机箱通常通过_扩展器_来实现。过去，这些是带有大量电缆的传统 AIC 卡；如今，扩展器嵌入在驱动器背板中，不太显眼。值得注意的是，这些扩展器可能成为性能瓶颈。
提示
考虑集群使用 HDD 的另一个因素是提前规划。SAS 和 SATA SSD 正在从制造商的产品路线图中消失，在未来几年向当今的 SAS/SATA 机箱添加 SSD 将变得越来越困难。可以购买接受所有三种类型的“通用”机箱，但它们更昂贵，并且通常需要昂贵且繁琐的三模 HBA。此外，为 LFF（3.5 英寸）驱动器构建的机箱在通过适配器放置 SFF（2.5 英寸）驱动器时空间效率相当低。
另请参阅 存储网络行业协会的总拥有成本计算器。
存储驱动器受到寻道时间、访问时间、读写时间、IOPS 和总吞吐量的限制。这些物理限制会影响整体系统性能——尤其是在恢复期间。我们建议为操作系统使用专用的（最好是镜像的）驱动器，并为您在主机上运行的每个 Ceph OSD 守护程序使用一个驱动器。
许多“慢速 OSD”问题（当它们不是由于硬件故障引起时）源于在同一驱动器上运行操作系统和多个 OSD。另请注意，今天的 32 TB HDD 使用的 SATA 接口与 2014 年 3 TB HDD 的接口相同：超过十倍的数据量需要通过相同的接口。一个类比是考虑一座有电梯的三层楼房，然后是一座有相同单部电梯的三十二层楼房。
因此，当使用 HDD 作为 OSD 时，大于 8 TB 的驱动器可能最适合存储对性能不敏感的大文件/对象。机箱管理开销，尤其是数据中心空间是 TCO 的关键输入：大型部署通常使用 SSD 实现比 HDD 更低的 TCO，尤其是当放弃 HDD 繁琐的三模 RAID HBA 的成本和管理成本时。SATA HBA 通常比 SAS HBA 便宜，但它们不支持多路径。NVMe SSD 不需要 HBA。
固态驱动器
使用固态驱动器 (SSD) 时，Ceph 性能会大大提高。这减少了随机访问时间并减少了延迟，同时增加了吞吐量。
SSD 每 TB 的成本高于 HDD，但 SSD 通常提供比 HDD 快至少 100 倍的访问时间。SSD 避免了繁忙集群中的热点问题和瓶颈问题，并且当整体评估 TCO 时，它们可能提供更好的经济效益。值得注意的是，给定 IOPS 数量的摊销驱动器成本在 SSD 上远低于 HDD。SSD 不受旋转或寻道延迟的影响，除了提高客户端性能外，它们还显着提高了集群更改的速度和对客户端的影响，包括添加、删除 OSD 或监视器或发生故障时的重新平衡。更微妙的是，HDD 集群的非常缓慢的恢复可能导致在组件发生故障时出现较长的增强风险期。
SSD 没有移动机械部件，因此它们不受 HDD 的许多限制。然而，SSD 确实有重大的限制。评估 SSD 时，考虑顺序读写和随机读写的性能非常重要。
重要
我们建议探索使用 SSD 来提高性能。但是，在对 SSD 进行重大投资之前，我们强烈建议审查 SSD 的性能指标并在测试配置中测试 SSD，以衡量性能。
相对便宜的 SSD 可能会吸引您的节约意识。请谨慎使用。可接受的 IOPS 不是选择用于 Ceph 的 SSD 时唯一要考虑的因素。便宜的客户端级或非品牌 SSD 是一种错误的节约：它们可能会经历“悬崖效应”，这意味着在初始爆发后，一旦有限的缓存被填满，持续性能就会显着下降。还要考虑耐用性：额定为每天 0.3 次驱动器写入 (DWPD 或等效值) 的驱动器可能适用于专用于某些类型的顺序写入、主要读取数据的 OSD，但对于服务数百个 VM 的 RBD 池来说不是一个好的选择。企业级 SSD 最适合 Ceph：它们具有断电保护 (PLP)，并且不会像客户端（桌面）型号可能经历的那样经历剧烈的悬崖效应。
当为操作系统引导和 Ceph Monitor / Manager 目的配置单个（或镜像对）SSD 时，建议最小容量为 256 GB，推荐至少 960 GB。建议使用额定为 1+ DWPD 或等效 TBW（写入的太字节）的驱动器型号。然而，对于给定的写入工作负载，比技术上要求更大的 SSD 将提供更高的耐用性，因为它有效地具有更大的超额配置。我们强调，企业级驱动器最适合生产用途，因为它们具有断电保护和更高的耐用性，而客户端（桌面）SKU 适用于更轻和间歇性的占空比。我们不能再强调使用企业级介质的重要性，因为监视器数据库、CephFS 元数据池和 RGW 日志/索引池几乎都需要 SSD 才能获得可接受的性能和稳定性。
历史上，SSD 被认为对于对象存储来说成本过高，但 QLC SSD 正在缩小差距，提供更高的密度、更低的功耗和更少的冷却功耗。此外，HDD OSD 通过将 WAL+DB 卸载到 SSD 上，可以显着提高写入延迟。大多数 Ceph OSD 部署不需要耐用性高于 1 DWPD（即“读取优化”）的 SSD。“混合使用”的 3 DWPD 级 SSD 通常对于此目的来说是多余的，并且成本要高得多。
为了更好地了解决定存储总成本的因素，您可以使用 存储网络行业协会的总拥有成本计算器
分区对齐
将 SSD 与 Ceph 一起使用时，请确保您的分区（如果有）已正确对齐。未正确对齐的分区可能导致性能和耐用性下降。有关正确分区对齐以及显示如何正确对齐分区的示例命令的更多信息，请参阅 Werner Fischer 关于分区对齐的博客文章。
CephFS 元数据隔离
Ceph 加速 CephFS 文件系统性能的一种方法是将 CephFS 元数据的存储与 CephFS 文件内容的存储分开。Ceph 为 CephFS 元数据提供了一个默认的 metadata 池。您无需手动为 CephFS 元数据创建池，但您应该为 CephFS 元数据池创建一个 CRUSH map 层次结构，其中只包含 SSD 存储介质。有关详细信息，请参阅 CRUSH 设备类别。
控制器
磁盘控制器 (HBA) 可以对写入吞吐量产生重大影响。仔细考虑您选择的 HBA，以确保它们不会造成性能瓶颈。值得注意的是，RAID 模式 (IR) HBA 可能比更简单的“JBOD” (IT) 模式 HBA 表现出更高的延迟。RAID SoC、写入缓存和电池备份可以显着增加硬件和维护成本。许多 RAID HBA 可以配置为 IT 模式“特性”或“JBOD 模式”以简化操作。
您不需要 RoC（支持 RAID）HBA。ZFS 或 Linux MD 软件镜像足以满足引导卷的耐用性。使用 SAS 或 SATA 数据驱动器时，放弃 HBA RAID 功能可以缩小 HDD 和 SSD 介质成本之间的差距。此外，当使用 NVMe SSD 时，您根本不需要任何 HBA。这在考虑整个系统时进一步缩小了 HDD 与 SSD 的成本差距。一个花哨的 RAID HBA 加上板载缓存加上电池备份（BBU 或超级电容器）的初始成本很容易超过 1000 美元，即使在打折后，这笔钱也足以弥补 SSD 的成本差距。如果购买年度维护合同或延长保修，无 HBA 系统每年可能还会节省数百美元。
提示
Ceph 博客 通常是 Ceph 性能问题信息的绝佳来源。有关更多详细信息，请参阅 Ceph 写入吞吐量 1 和 Ceph 写入吞吐量 2。
基准测试
BlueStore 使用 O_DIRECT 打开存储设备并经常发出 fsync() 以确保数据安全地持久化到介质。您可以使用 fio 评估驱动器的低级写入性能。例如，4 KiB 随机写入性能测量如下：
# fio --name=/dev/sdX --ioengine=libaio --direct=1 --fsync=1 --readwrite=randwrite --blocksize=4k --runtime=300
写入缓存
企业存储驱动器包括断电保护功能，可确保在操作过程中断电时的数据耐用性，并使用多级缓存来加速直接或同步写入。这些设备可以在两种缓存模式之间切换：一种是使用 fsync 刷新到持久介质的易失性缓存，另一种是同步写入的非易失性缓存。
这两种模式通过“启用”或“禁用”写入（易失性）缓存来选择。当启用易失性缓存时，Linux 以“write back”模式使用设备；当禁用时，它以“write through”模式使用设备。
HDD 的默认配置（通常：启用缓存）可能不是最佳的，通过禁用此写入缓存，OSD 性能可以在 IOPS 增加和提交延迟减少方面显着提高。
因此，鼓励用户如前所述使用 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 自动更改为“write through”。如果不是这种情况，您可以尝试直接设置它，如下所示。（用户应确保设置 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 设置为“write through”：
# 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 设置为“write through”：
# 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'"
提示
sdparm 实用程序可用于一次查看/更改多个设备上的易失性写入缓存：
# 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 驱动器的总吞吐量不超过服务客户端读写操作所需的网络带宽。当添加内部复制流量时，密集或 NVMe 节点可能会使 10 GE 甚至 25 GE 网络接口饱和。确保正确的绑定至关重要，而且，更多、更小的节点既提供了较低的爆炸半径/故障域，又降低了网络接口不堪重负的可能性。考虑每个主机占集群总容量的百分比。如果特定主机提供的百分比很大且主机发生故障，集群通常会遇到问题，例如恢复导致 OSD 超过 full ratio，进而导致 Ceph 停止操作以防止数据丢失。
当您在每个主机上运行多个 OSD 时，您还需要确保内核是最新的。请参阅 操作系统建议，了解有关 glibc 和 syncfs(2) 的说明，以确保您的硬件在每个主机上运行多个 OSD 时按预期运行。
网络
在数据中心中配置至少 10 Gb/s 的网络，包括 Ceph 主机之间以及客户端与 Ceph 集群之间。工作负载繁重的集群最好配置 25 Gb/s 网络；密集节点通常需要 100 Gb/s 链路。
强烈建议在不同的网络交换机之间进行网络链路主动/主动绑定，以提高吞吐量并容忍网络故障和维护。请注意，您的绑定哈希策略会将流量分布到各个链路上。
速度
通过 1 Gb/s 网络复制 1 TiB 数据需要三个小时，通过 1 Gb/s 网络复制 10 TiB 数据需要三十个小时。但是通过 10 Gb/s 网络复制 1 TiB 数据只需二十分钟，通过 10 Gb/s 网络复制 10 TiB 数据只需三个小时。
请注意，40 Gb/s 网络链路实际上是四个 10 Gb/s 通道并行，而 100 Gb/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 (Dell)、CIMC (Cisco UCS) 和 iLO (HPE)。管理和部署工具也可能广泛使用 BMC，尤其是通过 IPMI 或 Redfish，因此请考虑用于安全和管理的带外网络的成本/效益权衡。Hypervisor SSH 访问、VM 镜像上传、OS 镜像安装、管理套接字等可能会给网络带来重大负载。运行多个网络可能看起来是多余的，但每个流量路径都代表着潜在的容量、吞吐量和/或性能瓶颈，您在部署大型数据集群之前应仔细考虑这些瓶颈。
此外，截至 2025 年，BMC 很少提供快于 1 Gb/s 的网络连接，因此专用的廉价 1 Gb/s 交换机用于 BMC 管理流量可以减少成本，因为在更快速的主机交换机上浪费的昂贵端口更少。
故障域
故障域可以被认为是任何组件丢失，它阻止了对一个或多个 OSD 或其他 Ceph 守护程序的访问。这些可能是主机上停止的守护程序；存储驱动器故障、操作系统崩溃、NIC 故障、电源故障、网络中断、停电等。在规划硬件部署时，您必须平衡通过将过多职责放在太少的故障域中来降低成本的风险与隔离每个潜在故障域的额外成本。
最低硬件建议
Ceph 可以在廉价的商用硬件上运行。小型生产集群和开发集群可以成功地以适度的硬件运行。正如我们上面指出的：当我们谈论 CPU 核心 时，如果启用了超线程 (HT)，我们指的是线程。对于 Ceph，HT 几乎总是有利的。每个现代物理 x64 CPU 核心通常提供两个逻辑 CPU 线程；其他 CPU 架构可能有所不同。
有许多因素会影响资源选择。满足一个目的的最低资源不一定满足另一个目的。一个在笔记本电脑上使用 VirtualBox 或在三个 Raspberry PI 上构建的沙盒集群，其资源将少于一个拥有数千个 OSD 并服务数千个 RBD 客户端的生产部署。经典的 Fisher Price PXL 2000 拍摄视频，IMAX 或 RED 相机也拍摄视频。人们不会期望前者能完成后者T的工作。我们尤其不能足够强调在生产工作负载中使用企业级存储介质的重要性。
有关生产集群资源规划的其他见解，请参阅上文和本文档中的其他位置。
进程 |
标准 |
最低和推荐 |
|---|---|---|
|
处理器 |
|
RAM |
|
|
存储驱动器 |
在大多数情况下，每个 OSD 1 个存储驱动器。大于 30 TB 的 PCIe Gen 4+ SSD 可能受益于分成两个或更多 OSD。 |
|
DB/WAL 卸载（可选） |
每个 HDD OSD 1 个 SSD 分区 每个 DB/WAL SATA SSD 4-5 个 HDD OSD 每个 DB/WAL NVMe SSD <= 15 个 HDD OSD |
|
网络 |
1x 1Gb/s（推荐绑定 25+ Gb/s） |
|
|
处理器 |
|
RAM |
每个守护程序 5GB+（大型/生产集群需要更多） |
|
存储 |
每个守护程序 100 GB，强烈建议使用 SSD |
|
网络 |
1x 1Gb/s（推荐 10+ Gb/s） |
|
|
处理器 |
|
RAM |
每个守护程序 8+ GiB |
|
网络 |
1x 1Gb/s（推荐 10+ Gb/s） |
提示
在单个存储驱动器上运行 OSD 节点时，请为 OSD 创建一个与包含操作系统的分区不同的分区。我们建议为操作系统和 OSD 存储使用单独的驱动器。