Ceph硬件建议

1 CPU

Ceph被设计为运行在商品硬件上，这使得建立和维护PB级数据集群在经济上是可行的。在规划集群硬件时，您需要平衡许多注意事项，包括故障域和潜在的性能问题。硬件规划应包括在许多主机上分发Ceph守护进程和其他使用Ceph的进程。通常，我们建议在为该类型的守护程序配置的主机上运行特定类型的Cep守护程序。我们建议对其他主机使用您的数据集群（例如OpenStack，CloudStack等）。

Ceph元数据服务器动态重新分配其负载，这是CPU密集型。因此，您的元数据服务器应具有显着的处理能力（例如，四核或更好的CPU）。Ceph OSD运行RADOS服务，用CRUSH计算数据放置，复制数据，并维护自己的集群映射副本。因此，OSD应具有合理的处理能力（例如，双核处理器）。监视器只需维护集群映射的主副本，因此它们不是CPU密集型。您还必须考虑除了Ceph守护进程之外，主机是否将运行CPU密集型进程。例如，如果您的主机将运行计算机虚拟机（例如，OpenStack Nova），则需要确保这些其他进程为Ceph守护程序提供足够的处理能力。我们建议在不同的主机上运行额外的CPU密集型进程。

2 RAM

元数据服务器和监视器必须能够快速地提供数据，所以它们应该有足够的RAM（例如，每个守护程序实例有1GB的RAM）。OSD对于常规操作不需要尽可能多的RAM（例如，每个守护程序实例有500MB的RAM）; 然而，在恢复期间，它们需要显着更多的RAM（例如，每个守护进程每1TB存储约1GB）。通常，更多的RAM是更好的。

3 数据存储

仔细规划数据存储配置。在规划数据存储时需要考虑的重要成本和性能折衷。同时操作系统操作，以及从单个驱动器同时请求多个守护进程的读写操作可能会显着降低性能。

硬盘驱动器

OSD应该有足够的硬盘驱动器空间用于对象数据。我们建议最低硬盘大小为1TB。考虑大型磁盘的每GB成本优势。我们建议将硬盘驱动器的价格除以千兆字节数来达到每GB的成本，因为较大的驱动器可能会对每GB成本产生重大影响。例如，1 TB的硬盘定价为75.00美元，每千兆字节的成本为0.07美元（即75/1024 = 0.0732美元）。相比之下，3 TB的硬盘价格为150.00美元，每千兆字节的成本为0.05美元（即150美元/ 3072美元= 0.0488美元）。在上述示例中，使用1 TB磁盘通常会将每GB的成本提高40％，从而大大降低了您的集群的成本效益。另外，存储驱动器容量越大，您将需要更多的Ceph OSD守护进程，特别是在重新平衡，回填和恢复过程中。对于1TB的存储空间，一般的经验法则是〜1GB的RAM。

存储驱动器受到查询时间，访问时间，读取和写入时间以及总吞吐量的限制。这些物理限制会影响整个系统的性能 - 特别是在恢复期间 我们建议为操作系统和软件使用专用驱动器，并在主机上运行的每个Ceph OSD守护程序使用一个驱动器。由于在同一驱动器上运行操作系统，多个OSD和/或多个日志，所以会出现大多数“慢OSD”问题。由于在小型集群上排除性能问题的成本可能会超出额外的磁盘驱动器的成本，您可以通过避免超负荷OSD存储驱动器的诱惑来加快集群设计规划。

您可以为每个硬盘驱动器运行多个Ceph OSD守护程序，但这可能会导致资源争用并降低整体吞吐量。您可以将日志和对象数据存储在同一个驱动器上，但这可能会增加对客户端进行写入和确认的时间。Ceph必须写入日志才能确认写。

Ceph最佳实践规定您应该在单独的驱动器上运行操作系统，OSD数据和OSD日志。

固态硬盘

性能改进的一个机会是使用固态驱动器（SSD）来减少随机访问时间并读取延迟并加速吞吐量。与硬盘驱动器相比，固态硬盘的每千兆字节通常的成本要高出10倍，但固态硬盘的访问时间往往比硬盘驱动器至少要快100倍。

SSD没有移动的机械部件，因此它们不一定受到与硬盘驱动器相同类型的限制。SSD确实有很大的局限性。在评估SSD时，考虑顺序读写的性能很重要。具有400MB / s连续写入吞吐量的SSD可能比在多个OSD存储多个日志时具有120MB / s连续写入吞吐量的SSD具有更好的性能。

由于SSD没有移动的机械部件，因此在Ceph区域使用它们并不使用大量存储空间（例如期刊）是有意义的。相对廉价的SSD可能吸引您的经济感。小心使用 选择与Ceph一起使用的SSD时，可接受的IOPS是不够的。日志和SSD有一些重要的性能注意事项：

• **写入密集型语义：**日记记录涉及写入密集型语义，因此您应该确保选择部署的SSD在写入数据时将与硬盘驱动器相同或更好。即使在加速访问时间的情况下，廉价的SSD也可能会引入写入延迟，因为有时高性能硬盘驱动器可以像市场上可用的一些更经济的SSD一样快速或快速地写入！
• **顺序写入：**当您将多个期刊存储在SSD上时，您必须考虑到SSD的顺序写入限制，因为它们可能会同时处理写入多个OSD期刊的请求。
• 分区对齐： SSD性能的一个常见问题是人们喜欢将驱动器分区为最佳做法，但它们往往忽略了与SSD的正确分区对齐，这可能导致SSD传输数据更慢。确保SSD分区正确对齐。

虽然SSD对对象存储成本过高，但OSD可以通过将OSD日记存储在SSD上，并将OSD的对象数据存储在单独的硬盘驱动器上来显着提高性能。所述配置设置默认为。您可以将此路径安装到SSD或SSD分区，以使其不仅仅是与对象数据在同一磁盘上的文件。osd journal``/var/lib/ceph/osd/$cluster-$id/journal

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

控制器

磁盘控制器也对写入吞吐量有重大影响。仔细考虑您选择的磁盘控制器，以确保它们不会创建性能瓶颈。

其他注意事项

您可以为每个主机运行多个OSD，但您应确保OSD硬盘的总吞吐量之和不超过客户端读取或写入数据所需的网络带宽。您还应该考虑集群存储在每个主机上的整体数据的百分比。如果特定主机的百分比较大，并且主机出现故障，则可能会导致诸如超出全部比例的问题，这导致Ceph停止运行，以防止数据丢失的安全预防措施。

当您每个主机运行多个OSD时，还需要确保内核是最新的。有关注意事项的操作系统建议，请参阅操作系统建议书glibc， syncfs(2)以确保您的硬件在每个主机运行多个OSD时按预期执行。

具有大量OSD的主机（例如，> 20）可能会产生大量线程，特别是在恢复和重新平衡期间。许多Linux内核的最大线程数默认为相对较小（例如32k）。如果在主机上启动具有大量OSD的OSD时遇到问题，请考虑设置kernel.pid_max为更高数量的线程。理论上限为4,194,303个线程。例如，您可以将以下内容添加到/etc/sysctl.conf文件中：

1

kernel.pid_max  =  4194303

4 网络

我们建议每个主机至少有两个1Gbps网络接口控制器（NIC）。由于大多数商用硬盘驱动器的吞吐量大约为100MB /秒，因此您的网卡应能够处理主机上的OSD磁盘的流量。我们建议至少使用两个NIC来解决公共（前端）网络和集群（后端）网络。集群网络（最好不连接到互联网）处理额外的数据复制负载，并有助于阻止拒绝服务攻击，防止集群实现active + clean作为OSD的放置组的状态在集群中复制数据。考虑从机架中的10Gbps网络开始。通过1Gbps网络复制1TB的数据需要3个小时，3TB（典型的驱动器配置）需要9个小时。相反，使用10Gbps网络，复制时间分别为20分钟和1小时。在一个PB级的集群中，OSD磁盘的故障应该是一种期望，而不是例外。系统管理员将会欣赏从degraded状态恢复的PG active + clean状态尽可能快地考虑到价格/性能的折衷。此外，一些部署工具（例如，戴尔的Crowbar）部署了五个不同的网络，但采用VLAN可以使硬件和网络布线更易于管理。使用802.1q协议的VLAN需要支持VLAN的NIC和交换机。添加的硬件费用可能被网络设置和维护的运营成本节省抵消。当使用VLAN来处理集群和计算堆栈之间的VM流量（例如OpenStack，CloudStack等）时，也值得考虑使用10G以太网。每个网络的机架顶部路由器还需要能够与具有更快吞吐量的脊柱路由器通信，例如40Gbps至100Gbps。

您的服务器硬件应具有底板管理控制器（BMC）。管理和部署工具也可以广泛使用BMC，因此考虑管理带外网络的成本/效益折衷。虚拟机管理程序SSH访问，虚拟机映像上传，操作系统映像安装，管理套接字等可能会对网络造成重大负担。运行三个网络可能看起来像是过度的，但是每个流量路径代表在部署大规模数据集群之前应仔细考虑的潜在容量，吞吐量和/或性能瓶颈。

5 故障域

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

6 最低硬件建议

Ceph可以运行在便宜的商品硬件上。小型生产集群和开发集群可以通过适度的硬件成功运行。

7 生产群集示例

用于PB级数据存储的生产集群也可能使用商品硬件，但是应该具有相当多的内存，处理能力和数据存储以应付大量流量负载。

戴尔示例

最近（2012）Ceph集群项目正在为Ceph OSD使用两个相当强大的硬件配置，并为显示器配置了较轻的配置。