Red Hat CEPH 部署硬件配置指导
参考文档： Red Hat Ceph硬件配置推荐
一 基本原则说明
为Red Hat CEPH系统选择硬件设施之前，首先参考以下基本原则来选择有效方案，以节省成本。
1.1 识别性能适用场景
成功部署CEPH集群首先要确定用户的使用特性，并为之选择合适的硬件。比如，为一个存储不频繁的应用场景选择IOPS优先的硬件是没有必要的；相反，为一个IOPS敏感的场景部署一个存储优先的硬件设施，即使降低价格，也会让用户抱怨性能太慢。
CEPH的主要使用场景有以下三种：
IOPS优先：适用于云计算操作，例如在OpenStack上运行MYSQL或者MariaDB 实例。高IOPS场景对存储有更高的性能要求，比如15000转的SAS盘和独立的SSD日志盘来处理频繁写操作。很多高IO的场景全部使用闪存来提高IOPS和吞吐量。
吞吐量优先：适用于存储大量重要数据并提高服务，比如图片、音频、视频内容等。高吞吐量场景对网络设施、控制器和硬盘能接受的吞吐有更高的性能要求。在对写操作有性能要求的场景下，SSD日志盘可以显著提高写性能。
存储优先：适用于使用最小成本存储大量重要数据。存储优先的部署通常牺牲性能换取更有吸引力的价格。比如，存储优先的部署往往使用更慢更便宜的SATA盘并在同一位置设置journal分区，而不是使用SSD写journal日志。
1.2 考虑存储密度
硬件规划中应该包含Ceph daemons（CEPH 例程）的部署，和很多其他为了保证硬件错误事件时CEPH系统高可用的主机。应该基于集群在硬件错误时发生重平衡的需求权衡存储密度。常犯的错误是在小集群上使用高密度集群，这可能会在集群执行backfill（回填）和recovery（恢复）操作时导致网络过载。
1.3 使用统一的硬件
创建pools并定义CRUSH层级结构，让同一个pool下的OSD硬件保持统一，这个统一包含：
同样的控制器
同样的驱动型号
同样的软件源
同样的寻道时间
同样的I/O效率
同样的网络吞吐
同样的日志配置
在pool内部使用同样的硬件可以提供一致的性能特性，简化配置和帮助问题定位。
1.4 生产环境至少使用万兆网
谨慎考虑集群网络带宽需求，注意网络连接过载，内部网络和用户网络分离。
1Gbps带宽不适用于生产集群
一旦发生设备磁盘异常，在1Gbps带宽条件下，恢复1TB数据需要3小时，恢复3TB数据需要9小时；对比10Gbps带宽条件下，分别只需要20分钟和1小时。当一个OSD不可用时，集群将复制该OSD上的数据到该pool内其他OSD上，来恢复该OSD的数据。而一个大的故障域（比如一个机架）的异常意味着集群需要大得多的带宽。管理员通常希望集群尽可能快的恢复。
至少为存储硬件准备一个10Gbps以太网链路，如果每个节点上带有多个磁盘设备，需要为连接和吞吐开销增加额外的10Gbps以太网链路。
将前端和后端网络设置在独立的网卡上
Ceph同时支持前端网络（public network）和后端网络（cluster network）。public network负责客户端交互，以及和Ceph Monitor通信。cluster network负责OSD心跳，拷贝，回填和恢复的交互.Red Hat建议根据你的pool副本数 osd_pool_default_size 来分配网络带宽使得后端带宽是前端带宽的副本数倍；最好是，让public network和cluster network在独立的网卡上进行通信。
当构建一个包含多机架的集群时，拓扑树的度数往往很胖，建议交换机之间使用尽可能大的网络带宽以获得更好的性能。一个典型的10Gbps 链路交换机有48个10Gbps 端口和4个40Gbps 端口。在最大吞吐的主干网上使用40Gbps 的端口。或者通过QSFP+和SFP+将不用的10Gbps端口聚集成40Gbps端口连到另外一个机架和主干路上。
为了优化网络，RedHat建议使用CPU带宽比更好的大型框架，以及非阻塞网络交换机背板。
1.5 避免使用RAID
Ceph本身可以备份或者通过纠删编码对象。RAID在块级重复了这个功能，并且减少了可用空间。结论是RAID是一种没有必要的浪费。另外一个降级的RAID对性能产生负面作用。
1.6 总结
在选择硬件设备时经常犯的错误是：
重利用低功耗的传统设备，作为Ceph设施。
在同一个pool中使用不一样的硬件。
使用1Gbps网络代替10Gbps或更高网络。
忽视public network和cluster network网络的设置。
使用RAID代替JBOD
只考虑了价格成本而忽略了性能和吞吐需求。
在需要使用SSD作为journal的场景下，使用OSD数据盘做journal
使用不满足吞吐特性的磁盘控制器。
二 负载优先性能域
使用Ceph存储的一个重要益处是可以通过Ceph性能域在同一个集群中支持不同类型的负载需求。各种不同的硬件配置可以通过各自的性能域联合起来。Ceph系统管理员可以在适合的性能域上部署存储pool，从而提供定制的性价比存储。为这些性能域选择合适型号规格的服务，是Redhat Ceph存储设计中一个很重要的方面。
以下列出了Redhat 在优化Ceph存储集群时的服务器标准参考。这些参考项可以作为硬件选择和配置的基本指导，也可以进行调整以满足不同的负载环境。实际的硬件配置需要根据负载场景和厂商能力进行综合权衡。
2.1 IOPS优先
一个IOPS优先的存储集群通常包含以下特性：
单位读写（IOPS）花费成本最低。
单位GB的容量可以支持最高的读写性能（IOPS）。
99百分位的延迟一致性。
典型的应用包括：
典型的块存储。
3副本的机械硬盘。
2副本的固态硬盘使用。
openstack云上的mysql服务。
2.2 吞吐量优先
一个吞吐量优先的存储集群通常包含以下特性：
单位吞吐（MBps）花费成本最低。
单位容量（TB）可以获得最高的MBps。
单位BTU可以获得最高的吞吐量（MBps）。
单位功率可以获得最高的吞吐量（MBps）。
97百分位的延迟一致性。
典型的应用包括：
块存储或者对象存储。
3副本。
针对视频、音频和图片的活跃存储。
流媒体。
2.3 容量优先
一个成本和容量优先的存储集群通常包含以下特性：
单位容量（TB）花费成本最低。
单位容量（TB）的BTU最低。
单位容量（TB）的功耗最低。
典型的应用包括：
典型的对象存储。
使用纠删码以达到最大可用容量。
档案文件。
视频、音频以及图像仓库。
2.4 性能域原理
对向Ceph读写数据的客户端接口来说，一个Ceph集群表现为一个简单的存放数据的池子。然而存储集群在其实有很多复杂的操作，这些操作对客户端接口来说是透明的。Ceph客户端和Ceph对象存储例程都使用CRUSH算法进行存取对象。OSD服务在集群内部的存储主机上运行。
一个CRUSH映射表，描述了集群资源的拓扑结构，这个映射表同时保存在客户端节点和集群的MON节点上。Ceph客户端和OSD都使用CRUSH映射表和CRUSH算法。Ceph客户端直接和OSD进行交互，避免了中心化的对象查询和潜在的性能瓶颈。通过监控CRUSH映射表以及和其他OSD进行通信，OSD自身可以进行备份、回填以及恢复操作--从而实现动态的失败恢复。
Ceph使用CRUSH映射表实现故障域管理。Ceph同样使用CRUSH映射表实现性能域管理，只要考虑底层硬件特性即可。CRUSH映射表向Ceph描述了怎样存储数据，它被实现成一个层级结构以及一个规则集。CRUSH映射表可以支持不同的层级结构从而区分不同类型的硬件性能特性。在RHCS2以及之前的版本中，性能域存储在独立的CRUSH层级结构中，在RHCS 3中，Ceph通过设备“classes”来实现性能域管理。
描述性能域的例子：
HDD盘适合低成本大容量的负载场景。
吞吐量敏感的负载场景通常同时使用HDD和SSD，并将日志写在SSD盘上。
像Mysql数据这样的的IOPS敏感的负载场景通常使用SSD盘。
所有这些性能域都可以在一个Ceph集群中共存。
三 服务器和机架级解决方案
硬件供应商对为Ceph提供包括服务器级和机架级优化方案表现出极大的热情。通过和Redhat进行联合测试，这些方案为Ceph部署提供了可预测的性价比，这些方案可以通过一个方便的模块化方法来为不同的负载场景扩展Ceph集群。典型的机架级方案包括：
网络交换：冗余的网络交换连接集群并且提供客户端访问。
Ceph监控节点：Ceph监控器存储整个集群健康数据，并且包含了整个集群的日志。在生产集群中推荐包含最少法定数量3监控节点。
Ceph OSD主机：Ceph对象存储设备（OSD）主机为集群提供存储容量，每个独立存储设备上运行一个或者多个OSD服务。OSD主机根据负载优化场景以及安装的数据设备（HDD、SSD、NVMe SSD）会有不同的选择和配置。
Redhat Ceph存储：很多供应商为绑定了服务器和机架级方案的Redhat Ceph存储提供基于容量的订购。
3.1 IOPS优先方案
随着闪存应用的增长，用户开始逐渐在Ceph集群上托管这些的IOPS敏感负载场景，从而让他们可以用私有云存储模拟高性能的公有云存储。这些负载场景通常包括基于MySQL、MariaDB、PostgreSQL的应用产生的结构化数据。运行在同一台主机的NVMe 固态存储上的Ceph写日志通常托管到OSD。典型的服务器组成如下：
CPU：对于主频2GHz的CPU，每块NVMe SSD配置10核。
RAM：16GB的基线内存，另外，每个OSD服务需要2GB内存。
网络：每12个OSD需要配置10Gb带宽
OSD 媒介：高性能、高忍耐的商用NVMe SSD。
OSD：每个NVMe SSD可以配置4个OSD。
Journal 媒介：和OSD同一位置的高性能、高忍耐的商用NVMe SSD。
Controller：本地PCIe总线
案例：
| 厂商 | 小集群（256TB） | 中型集群（1PB） | 大集群（2PB以上） |
|---|---|---|---|
| SuperMicro | SYS-5038MR-OSD006P | N/A | N/A |
3.2 吞吐量优先方案
吞吐量优先的Ceph存储方案通常用于半结构化或者非结构化数据的存储。大块连续I/O是经典场景。OSD主机上的存储介质通常包含HDD盘和用于写日志的SSD盘。典型的服务器组成如下：
CPU：对于主频2GHz的CPU，每块HDD盘配置0.5核。
RAM：16GB的基线内存，另外，每个OSD服务需要2GB内存。
网络：每12个OSD需要配置10Gb带宽
OSD 媒介：7200转商用硬盘。
OSD：每个HDD盘一个OSD。
Journal 媒介：高忍耐、高性能的商用SCSI 或NVMe固态硬盘。
OSD比Journal：普通SSD盘，4-5:1；NVMe盘，12-18:1。
主机总线适配器（HBA）：JBOD（硬盘直通）
案例：
| 厂商 | 小集群（256TB） | 中型集群（1PB） | 大集群（2PB以上） |
|---|---|---|---|
| SuperMicro | SRS-42E112-Ceph-03 | SRS-42E136-Ceph-03 | SRS-42E136-Ceph-03 |
3.3 容量优先方案
成本和容量方案通常关注更高的容量或者更长的存档方案。数据可能是半结构化或者非结构化的。负载场景包括媒体存档，大数据分析存档，机器镜像备份。常见于大块连续I/O。为了更好的利用成本，OSD通常托管在HDD盘上，Journal写到同一位置的HHD上。典型的服务器组成如下：
CPU：对于主频2GHz的CPU，每块HDD盘配置0.5核。
RAM：16GB的基线内存，另外，每个OSD服务需要2GB内存。
网络：每12个OSD需要配置10Gb带宽
OSD 媒介：7200转商用硬盘。
OSD：每个HDD盘一个OSD。
Journal 媒介：同一位置的HDD盘。
主机总线适配器（HBA）：JBOD（硬盘直通）
案例：
| 厂商 | 小集群（256TB） | 中型集群（1PB） | 大集群（2PB以上） |
|---|---|---|---|
| SuperMicro | N/A | SRS-42E136-Ceph-03 | SRS-42E172-Ceph-03 |
3.4 总结
| 组成 | IOPS优先方案 | 吞吐量优先方案 | 容量优先方案 |
|---|---|---|---|
| CPU | 20GHz/NVMe SSD | 1GHz/HHD | 1GHz/HHD |
| RAM | 16GB+2GB/OSD | 16GB+2GB/OSD | 16GB+2GB/OSD |
| 网络 | 10Gb/12OSDs | 10Gb/12OSDs | 10Gb/12OSDs |
| OSD媒介 | 商用NVMe SSD | 7200转商用硬盘 | 7200转商用硬盘 |
| OSD | 4*OSD/NVMe SSD | 1*OSD/HDD | 1*OSD/HDD |
| Journal 媒介 | NVMe SSD | SCSI/NVMe SSD | 同一位置的HDD盘 |
| 控制 | PCIe总线 | HBA直通卡 | HBA直通卡 |
四 最小硬件推荐
Ceph可以运行在非专用的商用硬件上。小的生产集群和开发集群可以不考虑优化性能而在最简单的硬件上运行。
| 服务例程 | 指标 | 最小配置推荐 | |
|---|---|---|---|
| ceph-osd | 处理器（Processor） | 1*AMD | Intel64位处理器 |
| 内存（RAM） | FileSore：16GB+2GB/OSD；BlueSore：16GB+5GB/OSD | ||
| 系统盘（OS-disk） | 1*OS disk/host | ||
| 卷存储（Volume Storage） | 1*driver/daemon | ||
| 日志盘（Journal） | 1*SSD/daemon（可选） | ||
| 网络 | 2*1GB链路网卡 | ||
| ceph-mon | 处理器（Processor） | 1*AMD | Intel64位处理器 |
| 内存（RAM） | 1GB/daemon | ||
| 磁盘空间（Disk Space） | 10GB/daemon | ||
| 监控盘（Monitor Disk） | 1*SSD（可选，给leveldb用） | ||
| 网络 | 2*1GB链路网卡 | ||
| ceph-radosgw | 处理器（Processor） | 1*AMD | Intel64位处理器 |
| 内存（RAM） | 1GB/daemon | ||
| 磁盘空间（Disk Space） | 5GB/daemon | ||
| 网络 | 1*1GB链路网卡 | ||
| ceph-mds | 处理器（Processor） | 1*AMD | Intel64位处理器 |
| 内存（RAM） | 2*mds_cache_memory_limit 通常2GB/daemon | ||
| 磁盘空间（Disk Space） | 2GB/daemon + 不同日志级别的存储空间 | ||
| 网络 | 2*1GB链路网卡 | ||
| ceph-rbd |
五 容器化部署最小硬件推荐
Ceph可以运行在非专用的商用硬件上。小的生产集群和开发集群可以不考虑优化性能而在最简单的硬件上运行。
| 服务例程 | 指标 | 最小配置推荐 | |
|---|---|---|---|
| ceph-osd-container | 处理器（Processor） | 1*AMD | Intel64位处理核/container |
| 内存（RAM） | 至少5GB/container | ||
| 系统盘（OS-disk） | 1*OS disk/host | ||
| 卷存储（Volume Storage） | 1*driver/container | ||
| 日志盘（Journal） | 1*SSD/daemon 或 专用NVME盘的一个分区 | ||
| 网络 | 2*1GB链路网卡 | ||
| ceph-mon-container | 处理器（Processor） | 1*AMD | Intel64位处理核/container |
| 内存（RAM） | 3GB/container | ||
| 磁盘空间（Disk Space） | 10GB/container | ||
| 监控盘（Monitor Disk） | 1*SSD（可选，给rocksdb用） | ||
| 网络 | 2*1GB链路网卡 | ||
| ceph-mgr-container | 处理器（Processor） | 1*AMD | Intel64位处理核/container |
| 内存（RAM） | 3GB/container | ||
| 网络 | 2*1GB链路网卡 | ||
| ceph-radosgw-container | 处理器（Processor） | 1*AMD | Intel64位处理核/container |
| 内存（RAM） | 1GB/daemon | ||
| 磁盘空间（Disk Space） | 5GB/daemon | ||
| 网络 | 1*1GB链路网卡 | ||
| ceph-mds-container | 处理器（Processor） | 1*AMD | Intel64位处理核/container |
| 内存（RAM） | 2*mds_cache_memory_limit 通常3GB/container | ||
| 磁盘空间（Disk Space） | 2GB/container + 不同日志级别的存储空间 | ||
| 网络 | 2*1GB链路网卡 | ||
| ceph-rbd-container |
六 总结
软件定义存储（SDS）在横向扩展方面表现出很多优势，满足了应用持续增大的存储需求。Red Hat和多家供应商合作，做了科学有效的测试，以求简化任何环境下选择硬件的过程。。。运行Redhat Ceph服务器的详细配置请参考最佳实践文档
