2.2. Red Hat Ceph Storage 的基本注意事项
使用 Red Hat Ceph Storage 的第一个考虑因素是为数据制定存储策略。存储策略是一种存储服务特定用例的数据的方法。如果您需要为 OpenStack 等云平台存储卷和镜像,可以选择将数据存储在带有 Solid State Drives (SSD) 的快速 Serial Attached SCSI (SAS) 驱动器上。相反,如果您需要存储 S3 或 Swift 兼容网关的对象数据,您可以选择使用更经济的方式,如传统的 SATA 驱动器。Red Hat Ceph Storage 可以在同一存储集群中同时容纳这两种场景,但您需要一种方式为云平台提供快速存储策略,并为对象存储提供更传统的存储方式。
一个成功的 Ceph 部署中的最重要的一个步骤是,找出一个适合存储集群的用例和工作负载的性价比配置集。为用例选择正确的硬件非常重要。例如,为冷存储应用程序选择 IOPS 优化的硬件会不必要地增加硬件成本。然而,在 IOPS 密集型工作负载中,选择容量优化的硬件使其更具吸引力的价格点可能会导致用户对性能较慢的抱怨。
Red Hat Ceph Storage 可以支持多种存储策略。用例、成本与好处性能权衡以及数据持久性是帮助开发合理存储策略的主要考虑因素。
使用案例
Ceph 提供大量存储容量,它支持许多用例,例如:
- Ceph 块设备客户端是云平台的领先存储后端,可为具有写时复制(copy-on-write)克隆等高性能功能的卷和镜像提供无限存储。
- Ceph 对象网关客户端是云平台的领先存储后端,为音频、位映射、视频和其他数据等对象提供 RESTful S3 兼容和 Swift 兼容对象存储。
- 传统文件存储的 Ceph 文件系统.
成本比较性能优势
越快越好。越大越好。越耐用越好。但是,每种出色的质量、相应的成本与收益权衡都有价格。从性能角度考虑以下用例:SSD 可以为相对较小的数据和日志量提供非常快速的存储。存储数据库或对象索引可以从非常快的 SSD 池中受益,但对于其他数据而言成本过高。带有 SSD 日志的 SAS 驱动器以经济的价格为卷和图像提供快速性能。没有 SSD 日志地 SATA 驱动器可提供低成本存储,同时整体性能也较低。在创建 OSD 的 CRUSH 层次结构时,您需要考虑用例和可接受的成本与性能权衡。
数据持续时间
在大型存储集群中,硬件故障是预期的,而非例外。但是,数据丢失和服务中断仍然不可接受。因此,数据的持久性非常重要。Ceph 通过对象的多个副本解决数据持久性问题,或使用纠删代码和多个编码区块来解决数据持久性。多个副本或多个编码区块会带来额外的成本与好处权衡:存储更少的副本或编码区块会更便宜,但可能会导致在降级状态中为写入请求提供服务。通常,一个具有两个额外副本的对象(或两个编码区块)可以允许存储集群在存储集群恢复时服务降级状态的写入。
在出现硬件故障时,复制存储在故障域中的一个或多个数据冗余副本。但是,冗余的数据副本规模可能会变得昂贵。例如,要存储 1 PB 字节并带有三倍复制的数据,将需要至少具有 3 PB 存储容量的集群。
纠删代码将数据存储为数据区块和编码区块。如果数据区块丢失,纠删代码可以使用剩余的数据区块和编码区块来恢复丢失的数据区块。纠删代码比复制更经济。例如,使用带有 8 个数据区块和 3 个编码区块的纠删代码提供与 3 个数据副本相同的冗余。但是,与复制相比(使用 3 倍的初始数据),此类编码方案使用约 1.5 倍的初始数据。
CRUSH 算法通过确保 Ceph 将额外的副本或编码区块存储在存储集群内的不同位置来协助这个过程。这样可确保单个存储设备或主机的故障不会丢失防止数据丢失所需的所有副本或编码区块。您可以规划一个成本取舍存储策略,以及数据持久性,然后将它作为存储池呈现给 Ceph 客户端。
数据存储池可以使用纠删代码。存储服务数据和存储桶索引的池使用复制。
与 Ceph 的对象复制或编码区块相比,RAID 解决方案已变得过时。不要使用 RAID,因为 Ceph 已经处理数据持久性,降级的 RAID 对性能有负面影响,并且使用 RAID 恢复数据比使用深度副本或纠删代码区块要慢得多。
其它资源
- 如需了解更多详细信息,请参阅 Red Hat Ceph Storage 安装指南中的 Red Hat Ceph Storage 的最低硬件注意事项 部分。
2.2.1. Colocating Ceph 守护进程及其优点
您可以在同一主机上并置容器化 Ceph 守护进程。以下是并置某些 Ceph 守护进程的优点:
- 显著提高规模较小的总拥有成本(TCO)。
- 可以提高整体性能。
- 减少物理主机数量以实现最低配置。
- 更好的资源利用率。
- 升级 Red Hat Ceph Storage 更加简单。
通过使用容器,您可以将以下列表中的一个守护进程与 Ceph OSD 守护进程(ceph-osd
)并置。此外,对于 Ceph 对象网关(radosgw
)、Ceph 元数据服务器(ceph-mds
)和 Grafana,您可以将它与 Ceph OSD 守护进程并置,以及以下列表中的守护进程。
-
Ceph 元数据服务器 (
ceph-mds
) -
Ceph Monitor (
ceph-mon
) -
Ceph 管理器(
ceph-mgr
) -
NFS Ganesha (
nfs-ganesha
) -
Ceph 管理器(
ceph-grafana
)
主机名 | Daemon | Daemon | Daemon |
---|---|---|---|
host1 | OSD | 监控和管理器 | Prometheus |
host2 | OSD | 监控和管理器 | RGW |
host3 | OSD | 监控和管理器 | RGW |
host4 | OSD | Metadata Server | |
host5 | OSD | Metadata Server |
由于 ceph-mon
和 ceph-mgr
协同工作,因此它们不会被视为两个独立的守护进程,以满足 colocation 的目的。
可以在命令行界面中使用 --placement
选项对 ceph orch
命令执行 Ceph 守护进程,也可以使用服务规格 YAML 文件。
命令行示例
[ceph: root@host01 /]# ceph orch apply mon --placement="host1 host2 host3"
服务规格 YAML 文件示例
service_type: mon placement: hosts: - host01 - host02 - host03
[ceph: root@host01 /]# ceph orch apply -i mon.yml
红帽建议将 Ceph 对象网关与 Ceph OSD 容器共存以提高性能。要在不增加硬件成本的情况下获得最高的性能,请每个主机使用两个 Ceph 对象网关守护进程。
Ceph 对象网关命令行示例
[ceph: root@host01 /]# ceph orch apply rgw example --placement="6 host1 host2 host3"
Ceph 对象网关服务规格 YAML 文件示例
service_type: rgw service_id: example placement: count: 6 hosts: - host01 - host02 - host03
[ceph: root@host01 /]# ceph orch apply -i rgw.yml
下图显示了具有并置守护进程和非并置守护进程的存储集群之间的区别。
图 2.1. colocated Daemons
图 2.2. 非并置守护进程
其他资源
-
有关使用
--placement
选项的更多详细信息 ,请参阅 Red Hat Ceph Storage Operations 指南中的使用 Ceph Orchestrator 管理服务 章节。 - 如需更多信息,请参阅 Red Hat Ceph Storage RGW 部署策略和大小指南。