第 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 恢复数据比使用深度副本或纠删代码区块要慢得多。
