硬件要求：

ceph是设计运行在商品硬件上，这样使得搭建和维护PB级别的集群在经济上可行。在计划选择集群硬件时，需要均衡一系列的条件，包括故障域和潜在的性能问题。硬件计划包含分布式的ceph进程和其他很多使用ceph进程的主机。

CPU

CPU

ceph元数据服务器会动态调整负载，属于CPU密集应用。所以元数据服务器需要在计算能力方面比较强（四核或者更强的CPU）。Ceph OSD节点运行RADOS服务，需要使用CRUSH计算数据存放位置、复制数据和维护集群map信息。因此，OSD节点需要合理的计算资源（例如双核CPU）。monitors主要维护集群map，不属于CPU密集应用。也需要考虑当前主机运行其他CPU密集型应用，例如VM的计算节点（nova）。建议运行在其他主机上运行ceph以外的CPU密集应用。

ceph元数据服务：4 core以上；OSD：2 core以上

RAM

RAM：

元数据服务器和monitors需要有快速检索数据的能力，因此他们需要更多的内存（1G RAM每个实例）。OSD节点不需要这么多内存（500M每个实例），但是在数据恢复期间他们需要更多的内存（每个进程每1T数据需要1G内存）。总体上来说，内存越大越好。

ceph元数据服务、monitors：每个实例1G     OSD：每个实例500M  但是在恢复期间要求内存较多。

DATA STORAGE

数据存储：

需要小心配置存储。这需要在费用和性能之间进行权衡。同时运行的操作系统以及不同进程同时的读写操作对单块磁盘的性能是不利的。这里同样需要考虑文件系统的限制：btrfs在生产环境中不是足够稳定，但是他有具有xfs和ext4不具备的日志和同时写的能力。

重要：因为ceph在确认写入前会将数据写入到日志journal中（对于xfs、ext4），对日志和OSD性能的平衡非常重要

硬盘：

OSD需要大了的硬盘来存储数据。ceph推荐硬盘大小为1T以上。单块硬盘的大小和每GB的费用是有关系的，需要进行均衡。对于越大硬盘，单个ceph OSD进程所需的内存也越大，特别是在重新负载均衡、回填和恢复的时候。一个简单的规则时，对于1TB的存储，通常需要1G RAM。

提醒：不建议在同一个硬盘的不同分区上运行多个OSD实例。同样不建议在同一个硬盘的不同分区上运行OSD和monitor或者元数据服务

硬盘受限于以下因素：寻道时间（seek time）、存取时间（access time）、读和写时间（read and write times）、吞吐量( total throughput).这些物理上的限制会影响整个系统的性能，特别是在恢复的时候。建议使用一块专用的磁盘用来安装操作系统和软件，另外每块磁盘建立一个OSD进程。很多osd慢的问题是因为在一块磁盘上运行系统、OSD实例和日志。因为在小型集群中排查性能问题的成本会大于额外磁盘的成本，在设计集群的时候要尽量避免OSD磁盘负载过重。

在同一块磁盘上运行多个OSD进程可能会导致资源争用并降低总吞吐量。同样的，在同一块磁盘上存储日志和数据对象可能会导致花费更多的时间在写入日志、更长的时间返回ACK到客户端。ceph必须在写完日志后才确认写完成。btrfs可以同时进行写日志和数据的操作，但是xfs、ext4不行。

ceph最好的建议是运行操作系统、OSD数据盘、OSD日志盘在不同的磁盘上。


SSD

一个改善性能的机会是使用SSD来减少随机访问时间、读取等待时间来提高吞吐。SSD在每GB单位上成本大约10倍与硬盘，但是带来的性能提升往往是100倍。

SSD没有机械结构，因此和机械硬盘的限制因素不同。SSD也有自己的局限性。当评估SSD时，一个重要考虑的性能因素是顺序读和写。当多个SSD用作多个OSD的日志时，一个400MB/S顺序写入的SSD在性能表现上会比具备120MB/S顺序读写的SSD性能要好。

重要：建议使用SSD来提高性能。但是在SSD上投入大量成本之前，强烈建议评估SSD的性能指标并且在测试时配置SSD来测试性能。

因为SSD没有物理结构，在ceph不用于存储大量的数据（例如存储日志）。使用相对便宜的SSD可能会节省下比较多的开资。但是需要注意，在ceph中仅仅考虑IOPS时不够的。下面是一少部分关于日志和SSD的性能考虑指标：

  • 写密集型（Write-intensive semantics）：日志包含密集型写，所以你选择部署的SSD在写入数据方面应该等同或者优于磁盘。便宜的SSD虽然可以加速读取时间，但是可能会增加写的延时，因为高性能的硬盘可能比某些便宜的SSD写入性能要好。

  • 顺序写（Sequential Writes）：当你在同一块SSD上存储多个日志时，你必须考虑SSD的顺序读写限制，因为多个日志可能会同时写。

  • 分区对齐（Partition Alignment）：一个通常的性能问题是由于人们在SSD上进行分区，但是他们经常忽略了正确的分区对齐，这样会导致SSD性能下降。确保SSD的分区是正确的。

虽然SSD在对象存储上的花费是很高昂的，但是通过制定OSD的日志在一个SSD上，数据存储在硬盘上，可以很明显提高OSDs的性能。osd journal配置默认是/var/lib/ceph/osd/$cluster-$id/journal。你可以在这个路径下挂载一个SSD或者一个SSD分区。

一个提高CephFS文件系统的方法是分离CephFS metadata和CephFS文件内容。Ceph提供一个默认的metadata池来存储CephFS metadata。你不需要为CephFS metadata创建一个池，但是你可以为CephFS metadata创建一个CURSH map，将他存放在SSD上。

控制器

磁盘控制器对写吞吐也有着很大影响。在选择磁盘控制器时，需要确保控制器不会造成性能瓶颈。

额外的考虑

你可能会在每个节点运行多个OSDs，但是你需要确保OSD磁盘的总吞吐不要超过为客户端提供读写的网络带宽。你同样需要考虑每个节点可以存储的空间。如果某一个节点空间很大，这个节点离线了，这可能会导致集群超过full ratio的限制，导致ceph丢失数据。

当每个节点运行多个OSDs时，还需要保证内核是最新的。查看OS要求章节对于glibc和syncfs的要求，确保硬件性能可以达到期望。

当一个主机有较多数量的OSD（例如大于20）可能会产生大量的进程，特别是在恢复和均衡过程中。很多Linux主机默认限制进程数量在一个较小的值（例如32k）。如果你在启动OSD的时候需要问题，可以考虑设置kernel.pid_max到一个较大的值。理论最大值是4,194,303。你可以在/etc/sysctl.conf加入以下配置：

kernel.pid_max=4194303

NETWORKS

网络

我们要求每个节点至少有2块1G网卡。因为大多数商业硬盘大约都会有100MB/s的吞吐，网卡需要能够提供足够的带宽。我们要求最小两个网卡来承载public网络和cluster网络。一个集群网络（cluster network，不需要连接到互联网）是承载额外的负载，进行数据复制、阻止其他因素让集群pg状态保持active+clean状态。考虑使用10G网卡。通过1G网卡复制1TB数据需需要3小时，3TB可能需要9小时。相对的，如果使用10G网卡，复制花费的时间是20分钟和1小时。在一个PB级别的集群中，一个OSD磁盘的异常是一个正常情况。系统管理员会期望尽快从degraded状态到active+clean状态（在性价比考虑的情况下）。另外，有许多部署工具（Dell Crowbar）会部署5个不同的网络，可以通过使用VLAN使网络更好管理。VLAN要求网卡和交换机可以使用802.1q协议。当使用VLANs来运行VM网络和存储集群网络时（例如OpenStack），需要考虑使用10G网卡。核心交换机需要更好的吞吐，例如使用40Gbps或者100Gbps的交换机。

硬件服务器需要有BMC（Baseboard Management Controller）。管理和部署都可能需要使用到BMC。

FAILURE DOMAINS

失效域

一个失效域是任意可以阻止访问一个或者多个osd。这可能是一个停止的进程；一个损坏的硬盘；一个系统崩溃；故障的网卡；电源失效；网络中断；电源中断等。当计划硬件时，需要平衡硬件增加的费用和失效域。

MINIMUM HARDWARE RECOMMENDATIONS