硬件指南

Red Hat Ceph Storage 4

Red Hat Ceph Storage 的硬件选择建议

摘要

本文档提供有关选择与红帽 Ceph 存储一起使用的硬件的高级指导。
红帽承诺替换我们的代码、文档和网页属性中存在问题的语言。我们从这四个术语开始： master、slave、blacklist 和 whitelist。这些更改将在即将发行的几个发行本中逐渐实施。详情请查看 CTO Chris Wright 信息。

第 1 章 摘要

许多硬件供应商现在同时提供 Ceph 优化的服务器和为不同工作负载配置文件设计的机架级解决方案。为了简化硬件选择流程并降低组织的风险，红帽已与多个存储服务器供应商合作，为不同的集群大小和工作负载配置文件测试和评估特定的集群选项。红帽精确的方法将性能测试与针对各种集群功能和规模的行之有效的指导相结合。借助适当的存储服务器和机架级解决方案，红帽 Ceph 存储可提供存储池，从吞吐量敏感、成本和容量为导向的工作负载，到新兴 IOPS 密集型工作负载。

红帽 Ceph 存储显著降低了存储企业数据的成本，并帮助企业管理指数级数据增长。该软件是一款强大且现代的 PB 级存储平台，可用于公共云或私有云部署。红帽 Ceph 存储为企业块和对象存储提供了成熟接口，为活动存档、富媒体和云基础架构工作负载提供了最佳解决方案，其特征是与租户无关的 OpenStack® 环境。 [1].红帽 Ceph 存储作为统一、软件定义型横向扩展存储平台提供，让企业能够通过提供以下功能来改进应用程序的创新和可用性，例如：

  • 扩展到数百 PB [2].
  • 集群中没有单点故障。
  • 通过在商用服务器硬件上运行，降低了资本支出(CapEx)。
  • 使用自我管理和自我修复属性降低运营费用(OpEx)

红帽 Ceph 存储可在多种行业标准硬件配置上运行，以满足各种需求。为简化和加快集群设计流程，红帽与参与的硬件供应商进行了广泛的性能和适用测试。此测试允许评估负载下选定的硬件，并为不同工作负载生成基本性能和大小数据大小 - 最终简化了 Ceph 存储集群硬件选择。如本指南中所述，多个硬件供应商现在提供针对红帽 Ceph 存储部署优化的服务器和机架级解决方案，并将 IOPS、吞吐量、成本和容量优化作为可用选项。

对于寻求横向扩展解决方案以满足严苛应用程序和升级存储需求的组织而言，软件定义型存储具有许多优势。通过行之有效的方法论并与多个供应商进行广泛的测试，红帽简化了选择硬件以满足任何环境需求的过程。更重要的是，本文中列出的准则和示例系统并不能取代量化生产工作负载对样本系统的影响。

有关配置服务器以运行红帽 Ceph 存储的具体信息，请参考《 红帽 Ceph 存储存储策略指南》 中记录的方法论和最佳实践。有关详细信息（包括红帽 Ceph 存储测试结果），请参见常见硬件供应商的性能和大小指南。


[1] 根据几年半年 OpenStack 用户调查，Ceph 是 OpenStack 的主要存储。

第 2 章 选择硬件的一般原则

作为存储管理员，您必须选择适当的硬件来运行生产 Red Hat Ceph Storage 集群。在为红帽 Ceph 存储选择硬件时，请按照以下原则回顾以下原则：这些规则有助于节省时间、避免常见错误、节省资金并实现更有效的解决方案。

2.1. 先决条件

  • 红帽 Ceph 存储的计划用途.

2.2. 识别性能使用案例

成功 Ceph 部署中最重要的一个步骤是识别适合集群用例和工作负载的性价比配置集。为用例选择正确的硬件非常重要。例如，为冷存储应用程序选择 IOPS 优化的硬件会不必要地增加硬件成本。然而，在 IOPS 密集型工作负载中，选择容量优化的硬件使其更具吸引力的价格点可能会导致用户对性能较慢的抱怨。

Ceph 的主要用例是：

  • 优化 IOPS：优化 IOPS 的部署适用于云计算操作，如将 MYSQL 或 MariaDB 实例作为 OpenStack 上的虚拟机运行。优化 IOPS 部署需要更高的性能存储，如 15k RPM SAS 驱动器和独立基于闪存的蓝存储，以处理频繁写入操作。一些高 IOPS 情景使用所有闪存存储来提高 IOPS 和总吞吐量。
  • 优化吞吐量：使用优化吞吐量的部署适合服务大量数据，如图形、音频和视频内容。优化吞吐量的部署需要具备可接受的总吞吐量特征的网络硬件、控制器和硬盘。在需要写入性能的情况下，基于闪存的蓝存储元数据设备将显著提高写入性能。
  • 优化容量： 容量优化部署适合以尽可能低的成本存储大量数据。容量优化的部署通常会以更具吸引力的价格点来换取性能。例如，容量优化部署通常使用速度较慢且成本较低的 SATA 驱动器。

本文档提供了适合这些用例的红帽测试硬件示例。

2.3. 考虑存储密度

硬件规划应包括在多个主机之间分发 Ceph 守护进程和其他使用 Ceph 的进程，以便在出现硬件故障时维持高可用性。在出现硬件故障时，平衡存储密度注意事项与需要重新平衡集群。常见的硬件选择错误是在小型集群中使用非常高的存储密度，这可能会在回填和恢复操作中造成网络过载。

2.4. 相同的硬件配置

创建池并定义 CRUSH 层次结构，使得池中的 OSD 硬件是相同的。

  • 相同的控制器.
  • 相同的驱动器大小.
  • 相同的 RPM.
  • 相同的寻道时间.
  • 相同的 I/O.
  • 相同的网络吞吐量.

在池中使用相同的硬件可以提供一致的性能配置集，可以简化调配并简化故障排除。

警告

当使用多个存储设备时（有时在重启过程中），设备顺序可能会改变。有关这个问题的故障排除，请参阅 重启过程中更改存储设备的顺序

2.5. 网络注意事项

仔细考虑集群网络的带宽要求，通过订阅划分网络链接，并隔离客户端到集群流量的集群内部流量。

重要

红帽建议在 Ceph 生产部署中使用 10 GB 以太网。1 GB 以太网不适用于生产存储集群。

如果出现驱动器故障，在 1Gbps 网络中复制 1 TB 数据需要 3 小时，而 3 TB 需要 9 小时。3 TB 是典型的驱动器配置。相比之下，使用 10 GB 网络时，复制时间分别为 20 分钟和 1 小时。请记住，当 OSD 出现故障时，集群将通过将其包含的数据复制到池中的其他 OSD 来恢复。

对于大型环境（如机架）的故障，意味着存储集群将使用的带宽要高得多。存储管理员通常希望集群尽快恢复。

至少，存储硬件应使用 10 GB 的以太网链接。如果 Ceph 节点各自有多个驱动器，请为连接和吞吐量添加额外的 10 GB 以太网链接。

重要

在单独的 NIC 上设置前和后端网络。

Ceph 支持公共（前端）网络和群集（后端）网络。公共网络处理客户端流量以及与 Ceph 监视器的通信。集群（后端）网络处理 OSD 心跳、复制、回填和恢复流量。

注意

红帽建议为集群（后端）网络分配带宽，它是前端网络的倍数，使用 osd_pool_default_size 作为您在复制池上的多个基础。红帽还建议在单独的 NIC 上运行公共和集群网络。

在构建包含多个机架（通常用于大型存储实施）的存储群集时，请考虑在"树形"设计中的交换机之间利用尽可能多的网络带宽，以获得最佳性能。典型的 10 GB 以太网交换机有 48 10 GB 端口和四个 40 GB 端口。使用旋转中的 40 GB 端口获得最大吞吐量。或者，考虑将未使用的 10Gbps 端口与 QSFP+ 和 SFP+ 电缆聚合至 40 GB 端口，以连接到另一个机架和机械路由器。

重要

为了优化网络，红帽建议使用巨型帧来提高 CPU/带宽比，以及一个非阻塞的网络交换机后端。红帽 Ceph 存储在通信路径的所有网络设备中，公共和集群网络需要相同的 MTU 值。在在生产环境中使用 Red Hat Ceph Storage 集群之前，验证环境中所有节点和网络设备上的 MTU 值相同。

其它资源

2.6. 避免使用 RAID 解决方案

Ceph 可以复制或纠删代码对象。RAID 在块级别复制此功能并减少可用容量。因此，RAID 是一个不必要的费用。另外，降级的 RAID 会对性能 造成负面影响。

重要

红帽建议将每个硬盘驱动器与 RAID 控制器分开导出，作为启用了回写缓存的单一卷。

这需要存储控制器上有一个配有电池的电池或者一个非易失性闪存内存设备。确保电池正常工作非常重要，因为如果控制器上的内存可能会因为电源故障而丢失，则大多数控制器都会禁用回写缓存。定期检查电池并在需要时替换它们，因为它们会随时间降级。详情请参阅存储控制器厂商的文档。通常，存储控制器供应商提供存储管理实用程序来监控和调整存储控制器配置，而无需停机。

当使用所有 Solid State Drives(SSD)或每个控制器具有大量驱动器的配置时，支持使用带有 Ceph 独立驱动器模式的 Bunch 驱动器(JBOD)。例如，附加到一个控制器的 60 个驱动器。在这种情况下，回写缓存可能会成为 I/O 争用的来源。由于 JBOD 禁用回写缓存，因此在这种情况下非常适合。使用 JBOD 模式的一个优点是易于添加或替换驱动器，然后在物理插入后立即将驱动器公开给操作系统。

2.7. 选择硬件时常见错误的总结

  • 改变动力不足的传统硬件，用于 Ceph。
  • 在同一个池中使用不同的硬件.
  • 使用 1Gbps 网络而不是 10Gbps 或更高版本.
  • 忽略设置公共和集群网络。
  • 使用 RAID 而不是 JBOD.
  • 在价格基础上选择驱动器，而不考虑性能或吞吐量。
  • 具有吞吐量不足的磁盘控制器。

使用本文档中为不同工作负载测试配置的示例，以避免一些硬件选择错误。

2.8. 其它资源

  • 红帽客户门户网站中支持的配置 文章。

第 3 章 优化工作负载性能域

Ceph 存储的一个主要优点是能够使用 Ceph 性能域支持同一集群中不同类型的工作负载。可以与每个性能域关联显著不同的硬件配置。Ceph 系统管理员可以将存储池部署到适当的性能域中，为应用提供专为特定性能和成本配置文件量身定制的存储。为这些性能域选择适当的大小和优化的服务器是设计红帽 Ceph 存储集群的一个重要方面。

以下列表提供了红帽用于识别存储服务器上最佳红帽 Ceph 存储集群配置的标准。这些类别作为硬件采购和配置决策的一般指南提供，可以调整以满足独特工作负载融合需求。实际选择的硬件配置将根据特定的工作负载混合和供应商功能而有所不同。

优化 IOPS

IOPS 优化存储集群通常具有以下属性：

  • 每个 IOPS 的成本最低。
  • 每 GB 的 IOPS 最高。
  • 99 个百分点延迟一致性.

通常用于 IOPS 优化的存储集群有：

  • 典型的块存储.
  • 用于硬盘 (HDD) 或 2x 复制的 3 倍复制，用于固态硬盘 (SSD)。
  • OpenStack 云上的 MySQL.

优化吞吐量

吞吐量优化存储集群通常具有以下属性：

  • 每 MBps 成本最低（吞吐量）。
  • 每个 TB 的 MBps 最高。
  • 每个 BTU 的 MBps 最高。
  • 每个 Watt 的 MBps 最高。
  • 97% 的延迟一致性.

通常，用于吞吐量优化的存储集群有：

  • 块或对象存储。
  • 3 倍复制。
  • 面向视频、音频和图像的主动性能存储.
  • 流媒体.

优化成本和容量

成本和容量优化存储集群通常具有以下属性：

  • 每 TB 成本最低。
  • 每 TB 的 BTU 最低。
  • 每 TB 的 Watts 最低.

通常用于成本和容量优化的存储集群有：

  • 典型的对象存储.
  • 通用的纠删代码，以最大程度地提高可用容量
  • 对象存档。
  • 视频、音频和图像对象存储库.

性能域的工作原理

在读取和写入数据的 Ceph 客户端接口中，Ceph 存储集群显示为一个客户端存储数据的简单池。但是，存储集群以对客户端接口完全透明的方式执行许多复杂的操作。Ceph 客户端和 Ceph 对象存储守护进程（Ceph OSD 或只是 OSD）都使用可扩展哈希(CRUSH)算法下的受控复制来存储和检索对象。OSD 在 OSD 主机上运行 - 集群内的存储服务器。

CRUSH map 描述了集群资源的拓扑结构，并且 map 存在于客户端节点和群集中的 Ceph monitor(MON)节点中。Ceph 客户端和 Ceph OSD 都使用 CRUSH map 和 CRUSH 算法。Ceph 客户端直接与 OSD 通信，消除了集中式对象查找和潜在的性能瓶颈。利用 CRUSH map 并与其对等方通信，OSD 可以处理复制、回填和恢复，从而实现动态故障恢复。

Ceph 使用 CRUSH map 来实施故障域。Ceph 还使用 CRUSH map 实施性能域，这只需将底层硬件的性能配置文件纳入考量。CRUSH map 描述了 Ceph 存储数据的方式，它作为简单的层次结构（数据图）和规则集来实施。CRUSH map 可以支持多种层次结构，将一种类型的硬件性能配置集与另一类分隔开。在 RHCS 2 和更早版本中，性能域位于单独的 CRUSH 层次结构中。在 RHCS 3 中，Ceph 实施具有设备"类"的性能域。

以下示例描述了性能域。

  • 硬盘 (HDD) 通常适合以成本和容量为导向的工作负载。
  • 吞吐量敏感的工作负载通常使用 HDD，在固态驱动器(SSD)上 Ceph 写入日志。
  • MySQL 和 MariaDB 等 IOPS 密集型工作负载通常使用 SSD。

所有这些性能域都可以在 Ceph 存储集群中共存。

第 4 章 服务器和机架解决方案

硬件供应商通过提供优化的服务器级和机架级解决方案 SKU 响应 Ceph 周围的热情。通过与红帽联合测试进行验证，这些解决方案为 Ceph 部署提供了可预测的价格与性能比，采用便捷的模块化方法为特定工作负载扩展 Ceph 存储。

典型的机架级别解决方案包括：

  • 网络切换： 冗余网络切换互连集群，并提供对客户端的访问。建议至少有一个网络交换机。出于冗余目的，使用两个网络交换机，每个交换机分区以支持两个网络段。
  • Ceph MON 节点： Ceph 监控器是用于整个集群健康的数据存储，包含集群日志。对于生产环境中的集群仲裁，强烈建议至少有三个 monitor 节点。
  • Ceph OSD 主机： Ceph OSD 主机承载集群的存储容量，如果设备是 HDD 或 SSD，则为每个存储设备运行的一个或多个 OSD。对于 NVME 设备，红帽建议为每个存储设备运行两个或多个 OSD。根据工作负载优化和安装的数据设备（HDD、SSD 或 NVMe SSD），选择和配置 OSD 主机会有所不同。
  • 红帽 Ceph 存储： 许多供应商为结合服务器和机架级解决方案 SKU 捆绑的红帽 Ceph 存储提供基于容量的订阅。
注意

红帽建议在提交任何服务器和机架解决方案之前，查阅 Red Hat Ceph Storage: 支持的配置 文章。如需其他帮助，请联系红帽支持团队。

IOPS 优化的解决方案

随着闪存存储的使用不断增长，组织越来越多地在 Ceph 存储群集上托管 IOPS 密集型工作负载，从而使用私有云存储模拟高性能公共云解决方案。这些工作负载通常涉及 MySQL、MariaDB 或 PostgreSQL 应用程序的结构化数据。

典型服务器包括以下元素：

  • CPU： 每个 NVMe SSD 的 6 个内核，假设有 2 GHz CPU.
  • RAM： 16 GB 基准，外加每个 OSD 5 GB.
  • 网络： 每个 OSD 的 10 千兆位以太网、GbE.
  • OSD 介质： 高性能、高端企业 NVMe SSD.
  • OSD： 每个 NVMe SSD 的两个.
  • BlueStore WAL/DB ：高性能、高端企业 NVMe SSD，与 OSD 并置.
  • 控制器： 原生 PCIe 总线.
注意

对于非 NVMe SSD，对于 CPU，请为每个 SSD OSD 使用两个核心。

表 4.1. 按集群大小针对 IOPS 优化的 Ceph 工作负载的解决方案 SKU.

vendor小(250TB)中型(1PB)大(2PB+)

SuperMicro [a]

SYS-5038MR-OSD006P

N/A

N/A

[a] 有关详细信息，请参阅 Ceph 的 Supermicro® 总体解决方案。

吞吐量优化的解决方案

吞吐量优化的 Ceph 解决方案通常围绕半结构化或非结构化数据。大块顺序 I/O 是典型的.OSD 主机上的存储介质通常是 HDD，在基于 SSD 的卷上写入日志。

典型的服务器元素包括：

  • CPU： 每个 HDD 0.5 个内核，假设有 2 GHz CPU。
  • RAM： 16 GB 基准，外加每个 OSD 5 GB.
  • 网络： 每个 12 个 OSD 的 10 GbE 分别用于客户端和面向集群的网络。
  • OSD 介质： 7,200 RPM 企业 HDD.
  • OSD： 每个 HDD 对应一个.
  • BlueStore WAL/DB： 高性能企业串行附加 SCSI(SAS)或 NVMe SSD.
  • 主机总线适配器(HBA)： 只需大量的磁盘(JBOD)。

多个供应商为优化吞吐量的 Ceph 工作负载提供预配置的服务器和机架级解决方案。红帽对 Supermicro 和 Quanta 云技术(QCT)的服务器进行了广泛的测试和评估。

表 4.2. 用于 Ceph OSD、MON 和顶级(TOR)交换机的机架级别 SKU.

vendor小(250TB)中型(1PB)大(2PB+)

Supermicro [a]

SRS-42E112-Ceph-03

SRS-42E136-Ceph-03

SRS-42E136-Ceph-03

表 4.3. 单个 OSD 服务器

vendor小(250TB)中型(1PB)大(2PB+)

Supermicro [a]

SSG-6028R-OSD072P

SSG-6048-OSD216P

SSG-6048-OSD216P

QCT [a]

QxStor RCT-200

QxStor RCT-400

QxStor RCT-400

表 4.4. 可针对吞吐量优化的 Ceph OSD 工作负载配置的其他服务器.

vendor小(250TB)中型(1PB)大(2PB+)

Dell

PowerEdge R730XD [a]

DSS 7000 [b],双节点

DSS 7000,双节点

Cisco

UCS C240 M4

UCS C3260 [c]

UCS C3260 [d]

Lenovo

系统 x3650 M5

系统 x3650 M5

N/A

[d] 详情请查看 UCS C3260

成本和容量优化解决方案

成本和容量优化解决方案通常侧重于更高的容量或较长的归档方案。数据可以是半结构化数据，也可以是非结构化数据。工作负载包括介质存档、大数据分析存档和机器映像备份。大块顺序 I/O 是典型的.为提高成本效益，OSD 通常托管在 HDD 上并存于 Ceph 写入日志的 HDD 上。

解决方案通常包括以下元素：

  • CPU： 每个 HDD 0.5 个内核，假设有 2 GHz CPU。
  • RAM： 16 GB 基准，外加每个 OSD 5 GB.
  • 网络： 每 12 个 OSD 10 GbE（分别用于客户端和面向集群的网络）。
  • OSD 介质： 7,200 RPM 企业 HDD.
  • OSD： 每个 HDD 对应一个.
  • BlueStore WAL/DB： 在 HDD 上并置.
  • HBA： JBOD.

Supermicro 和 QCT 为以成本和容量为中心的 Ceph 工作负载提供预先配置的服务器和机架级解决方案 SKU。

表 4.5. 用于成本和容量优化工作负载的预配置 Rack 级别 SKU

vendor小(250TB)中型(1PB)大(2PB+)

Supermicro [a]

N/A

SRS-42E136-Ceph-03

SRS-42E172-Ceph-03

表 4.6. 用于成本和容量优化工作负载的预配置服务器级 SKU

vendor小(250TB)中型(1PB)大(2PB+)

Supermicro [a]

N/A

SSG-6048R-OSD216P [a]

SSD-6048R-OSD360P

QCT

N/A

QxStor RCC-400 [a]

QxStor RCC-400 [a]

表 4.7. 额外的服务器可配置用于成本和容量优化的工作负载

vendor小(250TB)中型(1PB)大(2PB+)

Dell

N/A

DSS 7000,双节点

DSS 7000,双节点

Cisco

N/A

UCS C3260

UCS C3260

Lenovo

N/A

系统 x3650 M5

N/A

其它资源

第 5 章 最低硬件建议

Ceph 可以在非专有商用硬件上运行。通过使用适度的硬件，可在不优化性能的情况下运行小型生产集群和开发集群。

注意

磁盘空间要求基于 /var/lib/ceph/ 目录下的 Ceph 守护进程默认路径。

Process标准最低建议

ceph-osd

处理器

1x AMD64 或 Intel 64

RAM

对于 BlueStore OSD，红帽通常建议每个 OSD 主机具有 16 GB RAM 的基准，每个守护进程具有额外的 5 GB RAM。

OS Disk

每个主机 1 个 OS 磁盘

卷存储

每个守护进程 1x 存储驱动器

block.db

可选，但红帽建议每个守护进程 1x SSD 或 NVMe 或 Optane 分区或逻辑卷。大小为 BlueStore 的 block.data 的 4%

block.wal

可选，每个守护进程 1x SSD 或 NVMe 或 Optane 分区或逻辑卷。使用小大小（如 10 GB），并且仅在它比 block.db 设备快时才使用。

网络

2 个 1GB 以太网 NIC

ceph-mon

处理器

1x AMD64 或 Intel 64

RAM

每个守护进程 1 GB

磁盘空间

每个守护进程 15 GB（推荐使用 50 GB）

监控磁盘

（可选）1x SSD 磁盘用于 leveldb 监控数据。

网络

2x 1 GB 以太网 NIC

ceph-mgr

处理器

1x AMD64 或 Intel 64

RAM

每个守护进程 1 GB

网络

2x 1 GB 以太网 NIC

ceph-radosgw

处理器

1x AMD64 或 Intel 64

RAM

每个守护进程 1 GB

磁盘空间

每个守护进程 5 GB

网络

1 个 1 GB 以太网 NIC

ceph-mds

处理器

1x AMD64 或 Intel 64

RAM

每个守护进程 2 GB

这个数字高度依赖于可配置的 MDS 缓存大小。RAM 要求通常为insd s_cache_memory_limit 配置设置中设置的数量的两倍。另请注意，这是守护进程的内存，而不是整体系统内存。

磁盘空间

每个守护进程 2 MB，以及日志记录所需的任何空间，这些空间可能因配置的日志级别而异。

网络

2x 1 GB 以太网 NIC

注意这与 OSD 的网络相同。如果您在 OSD 上有一个 10 GB 网络，则应在 MDS 上使用相同的网络，这样 MDS 在涉及延迟时不会产生判断。

第 6 章 容器化 Ceph 的最低硬件建议

Ceph 可以在非专有商用硬件上运行。通过使用适度的硬件，可在不优化性能的情况下运行小型生产集群和开发集群。

Process标准最低建议

ceph-osd-container

处理器

每个 OSD 容器 1 个 AMD64 或 Intel 64 CPU CORE

RAM

每个 OSD 容器最少 5 GB RAM

OS Disk

每个主机 1 个 OS 磁盘

OSD 存储

每个 OSD 容器 1X 存储驱动器。无法与 OS 磁盘共享。

block.db

可选，但红帽建议每个守护进程 1x SSD 或 NVMe 或 Optane 分区或 lvm。大小为 BlueStore 的 block.data 的 4%

block.wal

（可选）每个守护进程 1x SSD 或 NVMe 或 Optane 分区或逻辑卷。使用小大小（如 10 GB），并且仅在它比 block.db 设备快时才使用。

网络

2 个 1 GB 以太网 NIC，建议 10 GB

ceph-mon-container

处理器

每个 mon-container 一个 AMD64 或 Intel 64 CPU 内核

RAM

每个 mon-container3 GB

磁盘空间

推荐每个 mon-container 10 GB，推荐 50 GB

监控磁盘

另外，1x SSD 磁盘用于 monitor rocksdb 数据

网络

2 个 1GB 以太网 NIC，推荐 10 GB

ceph-mgr-container

处理器

每个 mgr-container的 AMD64 或 Intel 64 CPU CORE

RAM

每个 mgr-container3 GB

网络

2 个 1GB 以太网 NIC，推荐 10 GB

ceph-radosgw-container

处理器

每个 radosgw-container 1 个 AMD64 或 Intel 64 CPU 内核

RAM

每个守护进程 1 GB

磁盘空间

每个守护进程 5 GB

网络

1x 1GB 以太网 NIC

ceph-mds-container

处理器

每个 mds-container 一个 AMD64 或 Intel 64 CPU 内核

RAM

3 GB per mds-container

这个数字高度依赖于可配置的 MDS 缓存大小。RAM 要求通常为insd s_cache_memory_limit 配置设置中设置的数量的两倍。另请注意，这是守护进程的内存，而不是整体系统内存。

磁盘空间

2 GB 每个容器，以及可能调试日志记录所需的额外空间，20GB 是个不错的起点。

网络

2 个 1GB 以太网 NIC，推荐 10 GB

请注意，这与 OSD 容器网络相同。如果您在 OSD 上有一个 10 GB 网络，则应在 MDS 上使用相同的网络，这样 MDS 在涉及延迟时不会产生判断。