大部分的推荐配置来源于http://docs.ceph.org.cn/。
Ceph为普通硬件设计，这可以让维护构建PB级别的数据集群的费用相对来说更低廉。在搭建集群前最初的硬件架构设计极为重要。你需要均衡几个方面的因素，包括区域实效和潜在的性能问题。硬件规划包含要把使用Ceph集群的Ceph守护进程和其他进程所需要的资源恰当合理分布。
通常只推荐在一台机器上运行一种类型的守护进程。我们推荐把使用数据集群的进程（如 Openstack、CloudStack等）安装在别的机器上。
Ceph元数据服务器对CPU敏感，他会动态地重分布他们的负载，所以你的元数据服务器应该有足够的处理能力（如4核或更强悍的CPU）。Ceph的OSD运行着RADOS服务，用CRUSH算法计算着数据存放位置、复制数据、维护它自己的集群运行图副本，因此OSD需要一定的处理能力（如双核心CPU）。Ceph监视器只简单地维护者集群运行图的副本，因此对CPU不敏感。
但是需要考虑是否未来会在Ceph监视器的机器会运行其他的CPU密集型任务。比如运行用于计算的虚拟机（Openstack NOVA），你就要确保给Ceph进程保留足够的处理能力，所以推荐在其他机器上运行CPU密集型任务。
元数据服务器和监视器必须尽可能快的提供他们的数据，所以元数据服务器与监视器至少每个进程分配1G内存。
OSD的日常运行不需要那么多的内存，但是也要确保每个进程能分配到500M的内存，通常来说在进行数据恢复的期间他们占用的内存比较大，每TB级数据需要1GB的内存。
通常内存越多越好。
谨慎的规划数据和数据存储架构，因为期间涉及明显的成本和性能折衷。
来自操作系统的并行操作和到单个硬盘的多个守护进程的并发读写会极大的降低性能。同时文件系统局限性也要考虑，btrfs尚未稳定到可以用于生产环境的程度，但它可以同时记录日志并写入数据，而xfs和ext4不能。
Ceph发送ACK前必须把所有数据写入日志（至少对xfs和ext4来说是），因此均衡日志和OSD性能相当重要。
OSD应该有足够的空间用于存储对象数据。考虑到大硬盘的没GB成本，建议使用容量大于1TB的硬盘。建议用GB数除以硬盘价格来计算每GB的成本，因为较大的硬盘通常会对每GB成本有较大影响。
值得注意的是，单个驱动器的容量越大，其对应的OSD进程所需要的内存就越大，特别是在重均衡、回填、恢复期间。1TB的存储空间大约需要1GB内存。
在单个硬盘上运行多个OSD，这样不太妙！
在运行了OSD的磁盘上又同时运行着监视器或者云数据服务器这样也不太妙！
磁盘驱动器受限于寻道时间、访问时间、读写时间、还有吞吐量这些磁盘的物理局限影响着整体系统的性能，特别是在出现故障系统恢复期间。因此推荐独立的磁盘用于安装操作系统和软件，避免增加OSD存储磁盘的负担以提升性能。
Ceph可以在每块硬盘上运行多个OSD，但这会导致资源竞争并降低总体吞吐量；Ceph也允许把日志和对象数据存储在相同的磁盘驱动器上，但这会增加记录写日志并回应客户端的延迟，因为Ceph必须先写入日志才会回应确认了写动作。btrfs文件胸能同时写入日志数据和对象数据，而xfs、etx4不能。
Ceph最佳实践指示，应该分别在单独的硬盘运行操作系统、OSD和OSD日志。
一种提升性能的方法是使用固态硬盘SSD来降低随机访问时间和读延时，同时增加吞吐量。SSD和硬盘相比每GB的成本通常要高出10倍以上，但访问时间至少比硬盘快100倍！
SSD没有可移动机械部件，所以不存在和硬盘一样的局限性。但是SSD也有其他的局限性，评估SSD时，顺序读写的性能很重要，在为多个OSD存储日志时，有着400MB/s顺序读写吞吐量的SSD性能远高于120MB/s的。
建议发觉SSD的用法来提升性能，在大量投入SSD前，强烈建议核实SSD的性能指标，并在测试环境下衡量性能。相对廉价的SSD虽然价格很诱人，但是要谨慎使用！一分钱一分货的道理是永恒不变的。
正是因为SSD没有移动机械部件，所以它很适合Ceph里不需要太多存储空间的地方。可接受的IOPS指标对选择用于Ceph的SSD还不够，用于日志和SSD时还有几个重要考量：
SSD用于对象存储太昂贵了，但是把OSD的日志存到SSD、把对象数据存储到独立的硬盘可以明显提升性能。osd journal选项的默认值是/var/lib/ceph/osd/$cluster-$id/journal，所以说可以把目录存储的位置更改到SSD磁盘或SSD的分区上，这样它就不再是和对象数据一样存储在同一个硬盘上的文件了。
提升CephFS文件系统性能的一种方法是从CephFS文件内容中分离出元数据。Ceph提供了默认的metadata存储池来存储CephFS元数据，所以你不需要给CephFS元数据创建存储池，但是可以给它创建一个仅指向某主机SSD的CRUSH运行图。具体详情见OSD与Pool池的常见操作及管理
硬盘控制器也会对吞吐量有显著影响，要谨慎的选择控制器，以免产生性能瓶颈。
建议每台机器最少两个千兆网卡，现在大多数的机械硬盘都能达到100MB/s的吞吐量，网卡应该能处理所有的OSD硬盘总吞吐量，所以推荐最少两个千兆网卡分别用于公网和集群网络。集群网络用来处理数据复制产生的额外负载，而且可以防止拒绝服务攻击，拒接服务攻击会干扰数据归置组，使OSD数据复制时不能回到active+clean状态。所以最好考虑使用两个万兆网卡。
通过 1Gbps 网络复制 1TB 数据耗时 3 小时，而 3TB （典型配置）需要 9 小时，相比之下，如果使用 10Gbps 复制时间可分别缩减到 20 分钟和 1 小时。在一个 PB 级集群中， OSD 磁盘失败是常态，而非异常；在性价比合理的的前提下，系统管理员想让 PG 尽快从 degraded （降级）状态恢复到 active + clean 状态。
增加的硬件成本可用节省的运营（网络安装、维护）成本抵消。使用 VLAN 来处理集群和计算栈（如 OpenStack 、 CloudStack 等等）之间的 VM 流量时，采用 10G 网卡仍然值得。每个网络的机架路由器到核心路由器应该有更大的带宽，如 40Gbps 到 100Gbps 。
可以在同一台主机上运行多个OSD，但是要确保OSD硬盘总吞吐量不超过客户端提供读写服务所需的网络带宽；还要考虑集群在每台主机上所存储的数据占总体的百分比，如果一台主机所占百分比太大而它宕机了，就可能导致诸如超过full ratio的问题，此问题会使Ceph中止运作以防止数据丢失。
保证内核是最新的，确保硬件性能可以达到期望值。
OSD数量比较多的主机会产生大量OSD线程，尤其是在恢复和重均匀期间。很多Linux内核默认的最大线程数较小（如 32K 个），如果遇到了这类问题，可以把kernel.pid_max 值调高些。理论最大值是 4194303 。例如把下列这行加入 /etc/sysctl.conf 文件：
kernel.pid_max = 4194303
故障域指任何导致不能访问一个或多个 OSD 的故障，可以是主机上停止的进程、硬盘故障、操作系统崩溃、有问题的网卡、损坏的电源、断网、断电等等。规划硬件需求时，要在多个需求间寻求平衡点，像付出很多努力减少故障域带来的成本削减、隔离每个潜在故障域增加的成本。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。