1. Ceph简介
所有的 Ceph 存储集群的部署都始于一个个 Ceph节点、网络和 Ceph存储集群。Ceph 存储集群至少需要一个 Ceph Monitor、一个 Manager和一个Ceph OSD 守护进程。在运行 Ceph 作为文件存储时，还需要 Ceph 元数据服务。
Monitors：Ceph监视器（ceph-mon）维护集群状态的映射，包括监视器映射、管理器映射、OSD映射和 CRUSH 映射。这些映射是Ceph守护进程相互协调所需的关键集群状态。Monitor还负责管理守护进程和客户机之间的身份验证。为了冗余和高可用性，通常至少需要三个监视器。
Managers: Ceph管理进程（ceph-mgr）守护进程负责跟踪Ceph集群的运行指标和当前状态，包括存储利用率、当前性能指标和系统负载。Ceph Manager 守护进程还托管基于python的模块来管理和公开Ceph集群信息，包括基于web的Ceph dashboard 和 REST API 高可用通常需要至少两个管理器。
Ceph OSDs: 对象存储守护进程（ceph-osd）存储数据，处理数据复制，恢复，重新平衡并通过检查其他Ceph OSD 守护进程的心跳来为Ceph Monitor 和 Manager 提供一些监控信息，至少3 Ceph OSDs通常需要冗余和高可用性。
MDSs：Ceph元数据服务器（MDS，ceph-mds）Ceph元数据服务器允许POSIX文件系统用户执行基本命令（如ls、find等）,而不会给Ceph存储集群带来巨大的负担。
Ceph将数据作为对象存储在逻辑存储池中，使用 CRUSH算法，Ceph计算哪个对象应该被放置到哪个PG里，并进一步计算哪个Ceph OSD守护进程应该存放PG，CRUSH 算法使Ceph存储集群能够动态伸缩、再平衡和恢复。
2. 硬件推荐
Ceph 被设计成在普通硬件上运行，这使得建立和维护PB级别的数据集群在经济上可行的。在规划硬件集群时，需要平衡许多考虑事项，包括故障域和潜在的性能问题。硬件规划应该包括在许多主机上分发Ceph守护进程和其他使用Ceph的进程。通常，建议在为该类型守护进程配置的主机上运行特定类型的Ceph守护进程。建议使用其他主机来处理利用你的数据集群的进程。
CPU
Ceph 元数据服务器对 CPU 敏感，它会动态地重分布它们的负载，所以你的元数据服务器应该有足够的处理能力（如 4 核或更强悍的 CPU ）。Ceph 的 monitor 守护进程维护了 clustermap，它不给客户端提供任何数据，因此它是轻量级的，并没有严格的处理器要求。在大多数场景下，一个普通的单核服务器处理器就可以运行 Ceph monitor 服务。Ceph 的 OSD 运行着 RADOS 服务、用 CRUSH 计算数据存放位置、复制数据、维护它自己的集群运行图副本，因此 OSD 需要一定的处理能力（如双核 CPU ）。监视器只简单地维护着集群运行图的副本，因此对 CPU 不敏感；但必须考虑机器以后是否还会运行 Ceph 监视器以外的 CPU 密集型任务。例如，如果服务器以后要运行用于计算的虚拟机（如 OpenStack Nova ），你就要确保给 Ceph 进程保留了足够的处理能力，所以我们推荐在其他机器上运行 CPU 密集型任务。
一个 Ceph OSD 守护进程需要相当数量的处理性能，因为它提供数据给客户端。要评估 Ceph OSD 的 CPU 需求，知道服务器上运行了多少 OSD 上非常重要的。通常建议每个 OSD 进程至少有一个核心。可以通过以下公式计算 OSD 的 CPU 需求：
（（CPU sockets * CPU cores per socket * CPU clock speed in GHz ）/ No.of OSD ） >= 1
比如：
Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz 6 core --> 1 * 6 * 2.40 = 14.4 适合多达 14 个 OSD 的 Ceph 节点
Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz 12 core --> 1 * 12 * 2.50 = 30 适合多达 30 个 OSD 的 Ceph 节点
如果打算使用 Ceph 纠删码特性，最好能有一个更高性能的CPU ，因为运行纠删码需要更强的处理能力。
RAM 内存
元数据服务器和监视器必须可以尽快地提供它们的数据，所以他们应该有足够的内存，至少每进程 1GB 。 OSD 的日常运行不需要那么多内存（如每进程 500MB ）差不多了；然而在恢复期间它们占用内存比较大（如每进程每 TB 数据需要约 1GB 内存）。通常内存越多越好。
网络
Ceph 是一个分布式存储系统，很大程度上依赖于底层的网络基础设施。要让Ceph集群变得可靠、高效，就得确保设计一个良好的网络。建议让所有的集群节点拥有两张冗余独立的网卡用于集群和客户端流量。
一个设计良好的Ceph集群使用两个物理隔离网络：一个是集群网络（内部网络），另一个是客户端网络（外部网络）。两个网络应该从服务器到网络交换机以及它们之间的一切环节都进行物理隔离，如下图：
数据存储
要谨慎地规划数据存储配置，因为其间涉及明显的成本和性能折衷。来自操作系统的并行操作和到单个硬盘的多个守护进程并发读、写请求操作会极大地降低性能。
重要提示：因为 Ceph 发送 ACK 前必须把所有数据写入日志（至少对 xfs 和 ext4 来说是），因此均衡日志和 OSD 性能相当重要。
硬盘驱动器
OSD 应该有足够的空间用于存储对象数据。考虑到大硬盘的每 GB 成本，我们建议用容量大于 1TB 的硬盘。建议用 GB 数除以硬盘价格来计算每 GB 成本，因为较大的硬盘通常会对每 GB 成本有较大影响，例如，单价为 $75 的 1TB 硬盘其每 GB 价格为 $0.07 （ $75/1024=0.0732 ），又如单价为 $150 的 3TB 硬盘其每 GB 价格为 $0.05 （ $150/3072=0.0488 ），这样使用 1TB 硬盘会增加 40% 的每 GB 价格，它将表现为较低的经济性。另外，单个驱动器容量越大，其对应的 OSD 所需内存就越大，特别是在重均衡、回填、恢复期间。根据经验， 1TB 的存储空间大约需要 1GB 内存。
提示：不顾分区而在当个硬盘上运行多个OSD 是不明智的！
提示：不顾分区而在运行了OSD的硬盘上同时运行监视器或元数据服务器也上不明智的！
存储驱动器受限于寻道时间、访问时间、读写时间、还有总吞吐量，这些物理局限性影响着整体系统性能，尤其在系统恢复期间。因此我们推荐独立的驱动器用于安装操作系统和软件，另外每个 OSD 守护进程占用一个驱动器。大多数 “slow OSD”问题的起因都是在相同的硬盘上运行了操作系统、多个 OSD 、和/或多个日志文件。鉴于解决性能问题的成本差不多会超过另外增加磁盘驱动器，你应该在设计时就避免增加 OSD 存储驱动器的负担来提升性能。
Ceph 允许你在每块硬盘驱动器上运行多个 OSD ，但这会导致资源竞争并降低总体吞吐量； Ceph 也允许把日志和对象数据存储在相同驱动器上，但这会增加记录写日志并回应客户端的延时，因为 Ceph 必须先写入日志才会回应确认了写动作。 btrfs 文件系统能同时写入日志数据和对象数据， xfs 和 ext4 却不能。
Ceph 最佳实践指示，你应该分别在单独的硬盘运行操作系统、 OSD 数据和 OSD 日志。
固态硬盘
一种提升性能的方法是使用固态硬盘（ SSD ）来降低随机访问时间和读延时，同时增加吞吐量。 SSD 和硬盘相比每 GB 成本通常要高 10 倍以上，但访问时间至少比硬盘快 100 倍。
SSD 没有可移动机械部件，所以不存在和硬盘一样的局限性。但 SSD 也有局限性，评估SSD 时，顺序读写性能很重要，在为多个 OSD 存储日志时，有着 400MB/s 顺序读写吞吐量的 SSD 其性能远高于 120MB/s 的。
重要提示：建议发掘 SSD 的用法来提升性能。然而在大量投入 SSD 前，我们强烈建议核实 SSD 的性能指标，并在测试环境下衡量性能。
正因为 SSD 没有移动机械部件，所以它很适合 Ceph 里不需要太多存储空间的地方。相对廉价的 SSD 很诱人，慎用！可接受的 IOPS 指标对选择用于 Ceph 的 SSD 还不够，用于日志和 SSD 时还有几个重要考量：
- 写密集语义： 记日志涉及写密集语义，所以你要确保选用的 SSD 写入性能和硬盘相当或好于硬盘。廉价 SSD 可能在加速访问的同时引入写延时，有时候高性能硬盘的写入速度可以和便宜 SSD 相媲美。
- 顺序写入： 在一个 SSD 上为多个 OSD 存储多个日志时也必须考虑 SSD 的顺序写入极限，因为它们要同时处理多个 OSD 日志的写入请求。
- 分区对齐： 采用了 SSD 的一个常见问题是人们喜欢分区，却常常忽略了分区对齐，这会导致 SSD 的数据传输速率慢很多，所以请确保分区对齐了。
SSD 用于对象存储太昂贵了，但是把 OSD 的日志存到 SSD 、把对象数据存储到独立的硬盘可以明显提升性能。 osd journal 选项的默认值是 /var/lib/ceph/osd/$cluster-$id/journal ，你可以把它挂载到一个 SSD 或 SSD 分区，这样它就不再是和对象数据一样存储在同一个硬盘上的文件了。
控制器
硬盘控制器对写吞吐量也有显著影响，要谨慎地选择，以免产生性能瓶颈。
其他注意事项
你可以在同一主机上运行多个 OSD ，但要确保 OSD 硬盘总吞吐量不超过为客户端提供读写服务所需的网络带宽；还要考虑集群在每台主机上所存储的数据占总体的百分比，如果一台主机所占百分比太大而它挂了，就可能导致诸如超过 full ratio 的问题，此问题会使 Ceph 中止运作以防数据丢失。
如果每台主机运行多个 OSD ，也得保证内核是最新的。
OSD 数量较多（如 20 个以上）的主机会派生出大量线程，尤其是在恢复和重均衡期间。很多 Linux 内核默认的最大线程数较小（如 32k 个），如果您遇到了这类问题，可以把 kernel.pid_max 值调高些。理论最大值是 4194303 。例如把下列这行加入 /etc/sysctl.conf 文件：
kernel.pid_max = 4194303
Ceph OSD 节点的密度也是影响集群性能、可用容量和 TCO（Total Cost of Ownership ，即总拥有成本）的一个重要因素。通常，大量的小容量节点 比 少量的大容量节点要好，但这并不是定论，应该选择适当的 Ceph 节点密度，使得三个节点容量小于总容量的 10%。例如：在一个 1PB的ceph集群中，应该避免使用 4 个 250TB 的 OSD 节点，因为每个节点占用了 25% 的集群容量。相反，可以使用 13 个 80TB 的 OSD节点，每个节点容量小于集群容量的 10%。
参考链接：