第 1 章 概述
从 Ceph 客户端的视角，与 Ceph 存储集群交互非常简单：
- 连接到集群
- 创建池 I/O 上下文
这种显著简单的界面是 Ceph 客户端如何选择您定义的某一个存储策略。存储策略对 Ceph 客户端在存储容量和性能并不可见。
下图显示了从客户端开始到 Red Hat Ceph Storage 集群的逻辑数据流。
1.1. 什么是存储策略？
存储策略是一种存储服务特定用例的数据的方法。例如，如果您需要为 OpenStack 等云平台存储卷和镜像，您可以选择以合理方式存储数据并使用基于 SSD 的日志的 SAS 驱动器。相反，如果您需要为与 S3 或 Swift 兼容的网关存储对象数据，您可以选择使用更经济的设备，例如 SATA 驱动器等。Ceph 可以在同一 Ceph 集群中同时容纳这两个场景，但您需要为云平台（如 OpenStack 中的 Glance 和 Cinder）提供 SAS/SSD 存储策略，以及为您的对象存储提供 SATA 存储的方法。
存储策略包括存储介质（硬驱动器、SSD 和 rest）, CRUSH 映射为存储介质设置性能和故障域、放置组数量和池接口。Ceph 支持多种存储策略。用例、成本/受益性和数据持久性是驱动存储策略的主要考虑因素。
- 使用案例： Ceph 提供巨大的存储容量，它支持多种用例。例如，Ceph 块设备客户端是云平台（如 OpenStack）提供无限存储的领先存储后端，它提供了一个高性能功能的高性能功能（如 copy-on-write 克隆）。同样，Ceph 可以为 OpenShift 环境提供基于容器的存储。相比之下，Ceph 对象网关客户端是适用于云平台的领先存储后端，为音频、位图、视频和其他数据等对象提供 RESTful S3 兼容对象存储和 Swift 兼容对象存储。
- 成本/性能优势： 更高的性能更好。越大越好。越耐用越好。但是，每种出色的质量、相应的成本与收益权衡都有价格。从性能角度考虑以下用例：SSD 可以为相对较小的数据和日志量提供非常快速的存储。存储数据库或对象索引可能会从非常快速的 SSD 池中受益，但对其他数据来说过于昂贵。带有 SSD 日志的 SAS 驱动器以经济的价格为卷和图像提供快速性能。没有 SSD 日志地 SATA 驱动器可提供低成本存储，同时整体性能也较低。在创建 OSD 的 CRUSH 层次结构时，您需要考虑用例和可接受的成本/性能权衡。
-
持久性：在大规模集群中，硬件故障是期望的，而不是例外。但是，数据丢失和服务中断仍然不可接受。因此，数据的持久性非常重要。Ceph 通过对象的多个深度副本解决数据持久性问题，或使用纠删代码和多个编码区块来解决数据持久性。多个副本或多个编码区块会带来额外的成本与好处权衡：存储更少的副本或编码区块会更便宜，但可能会导致在降级状态中为写入请求提供服务。通常，带有两个额外副本（即
size = 3）或两个编码块的对象允许集群在集群恢复时以降级状态进行写入。CRUSH 算法通过确保 Ceph 在集群中的不同位置存储额外副本或编码区块来协助此过程。这样可确保，在单个存储设备或节点出现故障时，不会丢失为了防止数据丢失所需的所有副本或编码区块。
您可以规划一个存储策略来实现用例、性能成本/收益的平衡，以及数据的持久性，然后将它作为存储池呈现给 Ceph 客户端。
重要
Ceph 的对象副本或编码区块使 RAID 过时。不要使用 RAID，因为 Ceph 已经处理数据持久性，降级的 RAID 对性能有负面影响，并且使用 RAID 恢复数据比使用深度副本或纠删代码区块要慢得多。
