Ceph 硬件建议

Ceph 设计为在商用硬件上运行，这使得构建和维护PB级数据集群在经济上可行。在规划集群硬件时，您需要平衡许多考虑因素，包括故障域和潜在的性能问题。硬件规划应包括将 Ceph 守护进程和其他使用 Ceph 的进程分布在多台主机上。通常，我们建议在为该类型的守护进程配置的主机上运行特定类型的 Ceph 守护进程。我们建议将另外的其他主机用于使用您的数据集群的进程（例如，OpenStack、CloudStack 等）。

CPU

CephFS 元数据服务器是 CPU 密集型的，因此它们应该具有强大的处理能力（例如，四核或更好的 CPU）并受益于更高的时钟频率（频率以 GHz 为单位）。Ceph OSD 运行RADOS服务，使用CRUSH计算数据位置，复制数据，并维护自己的集群映射副本。因此，OSD 节点应具有合理的处理能力。要求因用例而异；一个起点可能是每个 OSD 一个核心用于轻型/归档使用，每个 OSD 两个核心用于繁重的工作负载，例如连接到 VM 的 RBD 卷。监视器/管理器节点对 CPU 的要求不高，因此可以为它们选择适中的处理器。还要考虑主机是否会运行除 Ceph 守护进程之外的 CPU 密集型进程。例如，如果您的主机将运行计算虚拟机（例如，OpenStack Nova），您将需要确保这些其他进程为 Ceph 守护进程留下足够的处理能力。我们建议在单独的主机上运行额外的 CPU 密集型进程以避免资源争用。

内存

通常，RAM 越多越好。适度集群的监视器/管理器节点可能在 64GB 上运行良好；对于具有数百个 OSD 的大型集群，128GB 是一个合理的目标。BlueStore OSD 的内存目标默认为 4GB。考虑到操作系统和管理任务（如监控和指标）的谨慎余量以及恢复期间增加的消耗：建议为每个 BlueStore OSD 配置约 8GB。

监视器和管理器（CEPH-MON 和 CEPH-MGR）

监视器和管理器守护程序的内存使用量通常随集群的大小而变化。请注意，在启动时以及在拓扑更改和恢复期间，这些守护程序将需要比在稳态操作期间更多的 RAM，因此请为高峰使用做好计划。对于非常小的集群，32 GB 就足够了。例如，对于多达 300 个 OSD 的集群，使用 64GB。对于使用（或将增长到）更多 OSDS 构建的集群，您应该配置 128GB。您可能还需要考虑调整设置，例如仔细研究mon_osd_cache_size 或rocksdb_cache_size。

元数据服务器 (CEPH-MDS)

元数据守护程序内存利用率取决于配置其缓存以消耗多少内存。对于大多数系统，我们建议至少 1 GB。见 mds_cache_memory。

OSD (CEPH-OSD)

Bluestore 使用自己的内存来缓存数据，而不是依赖于操作系统的页面缓存。在 bluestore 中，您可以使用osd_memory_target配置选项调整 OSD 尝试使用的内存量。

• 通常不建议将 osd_memory_target 设置为低于 2GB（它可能无法将内存保持在如此低的水平，并且还可能导致性能极慢）。

• 将内存目标设置在 2GB 和 4GB 之间通常可行，但可能会导致性能下降，因为元数据可能会在 IO 期间从磁盘读取，除非活动数据集相对较小。

• 4GB 是当前默认的 osd_memory_target 大小，并设置为尝试平衡典型用例的内存需求和 OSD 性能。

• 当处理许多（小）对象或大（256GB/OSD 或更多）数据集时，将 osd_memory_target 设置为高于 4GB 可能会提高性能。

重要：OSD 内存自动调整是“尽力而为”。虽然 OSD 可能会取消映射内存以允许内核回收它，但不能保证内核会在任何特定时间范围内实际回收释放的内存。在旧版本的 Ceph 中尤其如此，其中透明的大页可以防止内核回收从碎片化的大页中释放的内存。现代版本的 Ceph 在应用程序级别禁用透明大页面以避免这种情况，尽管这仍然不能保证内核会立即回收未映射的内存。OSD 有时仍可能超出其内存目标。我们建议在您的系统上预算大约 20% 的额外内存，以防止 OSD 在临时峰值期间或由于内核回收释放页面的任何延迟而进入 OOM。

使用legacy FileStore后端时，页面缓存用于缓存数据，一般不需要调优，OSD内存消耗一般与系统中每个daemon的PG数有关。

数据存储

仔细规划您的数据存储配置。在规划数据存储时，需要考虑重大的成本和性能权衡。同时的操作系统操作，以及来自多个守护进程对单个驱动器的读取和写入操作的同时请求会显著降低性能。

硬盘驱动器

OSD 应该有足够的硬盘空间来存储对象数据。我们建议的最小硬盘驱动器大小为 1 TB。考虑较大磁盘的每 GB 成本优势。我们建议将硬盘驱动器的价格除以 GB 数得出每 GB​​ 成本，因为更大的驱动器可能会对每 GB 成本产生重大影响。例如，价格为 75.00 美元的 1 TB 硬盘的成本为每 GB 0.07 美元（即，75 美元 / 1024 = 0.0732）。相比之下，价格为 150.00 美元的 3 TB 硬盘的成本为每 GB 0.05 美元（即 150 美元 / 3072 = 0.0488）。在前面的示例中，使用 1 TB 的磁盘通常会使每 GB 的成本增加 40%，从而显着降低集群的成本效率。

提示：在单个 SAS / SATA 驱动器上运行多个 OSD不是一个好主意。但是，NVMe 驱动器可以通过拆分为另外两个 OSD 来提高性能。

提示：在单个驱动器上运行 OSD 和监视器或元数据服务器也不是一个好主意。

存储驱动器受到寻道时间、访问时间、读写时间以及总吞吐量的限制。这些物理限制会影响整体系统性能，尤其是在恢复期间。我们建议为操作系统和软件使用专用（理想情况下的镜像）驱动器，并为您在主机上运行的每个 Ceph OSD 守护程序使用一个驱动器（上述模数 NVMe）。许多不是由硬件故障引起的“慢速 OSD”问题是由于在同一驱动器上运行操作系统和多个 OSD 而引起的。由于在小型集群上解决性能问题的成本可能超过额外磁盘驱动器的成本，因此您可以通过避免过度使用 OSD 存储驱动器来优化集群设计规划。

您可以在每个 SAS / SATA 驱动器上运行多个 Ceph OSD 守护程序，但这可能会导致资源争用并降低整体吞吐量。

固态硬盘

提高性能的一个机会是使用固态驱动器 (SSD) 来减少随机访问时间和读取延迟，同时加快吞吐量。与硬盘驱动器相比，SSD 每 GB 的成本通常高出 10 倍以上，但 SSD 的访问时间通常比硬盘驱动器快至少 100 倍。

SSD 没有可移动的机械部件，因此它们不一定受到与硬盘驱动器相同类型的限制。SSD 确实有很大的局限性。在评估 SSD 时，重要的是要考虑顺序读取和写入的性能。

重要的，我们建议探索使用 SSD 来提高性能。但是，在对 SSD 进行大量投资之前，我们强烈建议您查看 SSD 的性能指标并在测试配置中测试 SSD 以衡量性能。

相对便宜的 SSD 可能会吸引您的经济意识。谨慎使用。在选择用于 Ceph 的 SSD 时，可接受的 IOPS 是不够的。

SSD 历来成本高昂，但新兴的 QLC 驱动器正在缩小这一差距。通过将 WAL+DB 卸载到 SSD 上，HDD OSD 可能会看到显着的性能提升。

Ceph 加速 CephFS 文件系统性能的一种方法是将 CephFS 元数据的存储与 CephFS 文件内容的存储分开。Ceph为 CephFS 元数据提供了一个默认池metadata。您永远不必为 CephFS 元数据创建池，但您可以为仅指向主机的 SSD 存储介质的 CephFS 元数据池创建 CRUSH 映射层次结构。有关详细信息，请参阅 CRUSH 设备类。

控制器

磁盘控制器 (HBA) 会对写入吞吐量产生重大影响。仔细考虑您的选择，以确保它们不会造成性能瓶颈。值得注意的是，RAID 模式 (IR) HBA 可能比简单的“JBOD” (IT) 模式 HBA 表现出更高的延迟，并且 RAID SoC、写入缓存和电池备份会大大增加硬件和维护成本。一些 RAID HBA 可以配置 IT 模式“personality”。

提示 Ceph 博客通常是有关 Ceph 性能问题的绝佳信息来源。有关更多详细信息，请参阅Ceph 写入吞吐量 1和Ceph 写入吞吐量 2。
https://ceph.com/community/blog/
http://ceph.com/community/ceph-performance-part-1-disk-controller-write-throughput/
http://ceph.com/community/ceph-performance-part-2-write-throughput-without-ssd-journals/

其他注意事项

您通常会在每台主机上运行多个 OSD，但您应该确保 OSD 驱动器的总吞吐量不超过满足客户端读取或写入数据需求所需的网络带宽。您还应该考虑集群在每台主机上存储的总体数据的百分比。如果特定主机上的百分比很大并且主机发生故障，则可能会导致超出 full ratio 等问题，这会导致 Ceph 停止操作，作为防止数据丢失的安全预防措施。

当您在每个主机上运行多个 OSD 时，您还需要确保内核是最新的。请参阅OS Recommendations以获取有关说明glibc并 syncfs(2)确保您的硬件在每个主机运行多个 OSD 时按预期执行。

网络

在您的机架中配置至少 10Gbps+ 的网络。跨 1Gbps 网络复制 1TB 数据需要 3 小时，而 10TB 需要 30 小时！相比之下，对于 10Gbps 网络，复制时间将分别为 20 分钟和 1 小时。在 PB 级集群中，OSD 驱动器发生故障是一种预期，而不是例外。系统管理员会欣赏 PG 从一个degraded状态恢复到一个active + clean尽可能快地状态，同时考虑到价格/性能的权衡。此外，一些部署工具使用 VLAN 来使硬件和网络布线更易于管理。使用 802.1q 协议的 VLAN 需要支持 VLAN 的 NIC 和交换机。增加的硬件费用可能会被网络设置和维护的运营成本节省所抵消。当使用 VLAN 处理集群和计算堆栈（例如，OpenStack、CloudStack 等）之间的 VM 流量时，使用 10G 以太网或更好的以太网还有额外的价值；自 2020 年起，40Gb 或 25/50/100 Gb 网络对于生产集群来说很常见。

每个网络的架顶式路由器还需要能够与具有更快吞吐量（通常为 40Gbp/s 或更高）的主干路由器通信。

您的服务器硬件应该有一个基板管理控制器 (BMC)。管理和部署工具也可能广泛使用 BMC，尤其是通过 IPMI 或 Redfish，因此请考虑管理带外网络的成本/收益权衡。管理程序 SSH 访问、VM 映像上传、操作系统映像安装、管理套接字等可能会给网络带来很大的负载。运行三个网络可能看起来有点矫枉过正，但每条流量路径都代表一个潜在的容量、吞吐量和/或性能瓶颈，在部署大规模数据集群之前应该仔细考虑。

故障域

故障域是阻止访问一个或多个 OSD 的任何故障。那可能是主机上的已停止守护进程；硬盘故障、操作系统崩溃、网卡故障、电源故障、网络中断、断电等等。在规划您的硬件需求时，您必须平衡通过将太多职责置于太少的故障域中来降低成本的诱惑，以及隔离每个潜在故障域的额外成本。

最低硬件建议