第 1 章 概述

从 Ceph 客户端的角度来看，与 Ceph 存储集群交互非常简单：

  1. 连接到集群
  2. 创建池 I/O 上下文

这一极简单的界面是 Ceph 客户端如何选择您定义的其中一个存储策略。存储策略对 Ceph 客户端而言不可见，除了存储容量和性能外。

下图显示了从客户端开始到红帽 Ceph 存储群集的逻辑数据流。

arch 数据流

1.1. 什么是存储策略？

存储策略是一种存储服务特定用例的数据的方法。例如，如果您需要为 OpenStack 等云平台存储卷和镜像，可以选择使用基于 SSD 的日志将数据存储在具有合理性能的 SAS 驱动器上。相反，如果您需要存储 S3 或 Swift 兼容网关的对象数据，您可以选择使用更经济的方式，如 SATA 驱动器。Ceph 可以适应同一 Ceph 集群中的两种情况，但您需要一种向云平台（如 OpenStack 中的 Glance 和 Cinder）提供 SAS/SSD 存储策略的方法，以及为您的对象存储提供 SATA 存储的方法。

存储策略包括存储介质（硬盘、SSD 和 rest）、CRUSH 映射，这些映射为存储介质设置性能和故障域、放置组数量和池接口。Ceph 支持多种存储策略。使用案例、成本/优势性能权衡和数据持久性是推动存储策略的主要考虑因素。

  1. 使用案例： Ceph 提供海量存储容量，并支持众多用例。例如，Ceph 块设备客户端是 OpenStack 等云平台的领先存储后端，为具有高性能功能的卷和镜像提供无限制存储，如写时复制克隆。相比之下，Ceph 对象网关客户端是云平台的领先存储后端，可为音频、位图、视频和其他数据等对象提供 RESTful S3 兼容和 Swift 兼容对象存储。
  2. 成本/性能提升：Faster 更好.越大越好。越耐用越好。但是，每种出色的质量都有价格，并相应地权衡了成本/收益。从性能角度考虑以下用例：SSD 可以为相对较小的数据和日志量提供非常快速的存储。存储数据库或对象索引可能受益于非常快的 SSD 池，但对其他数据而言非常昂贵。带有 SSD 日志的 SAS 驱动器以经济的价格为卷和图像提供快速性能。没有 SSD 日志地 SATA 驱动器可提供低成本存储，同时整体性能也较低。在创建 CRUSH 的 OSD 层次结构时，您需要考虑用例和可接受的成本/性能权衡。
  3. 持久性： 在大型集群中，硬件故障是预期的，而非例外。但是，数据丢失和服务中断仍然不可接受。因此，数据的持久性非常重要。Ceph 通过对象的多个深度副本或纠删代码和多个编码区块来解决数据持久性。多个副本或多个编码区块会带来额外的成本/优势：存储较少的副本或编码区块，但可能会导致服务以降级状态写入请求。通常，一个带有两个额外副本的对象（即 size = 3）或两个编码区块可能会允许集群在集群恢复时以降级状态写入服务。CRUSH 算法通过确保 Ceph 将额外的副本或编码区块存储在群集内的不同位置来协助此过程。这样可确保单个存储设备或节点的故障不会导致丢失防止数据丢失所需的所有副本或编码区块。

您可以在存储策略中捕获用例、成本/优势性能平衡和数据持久性，并将其作为存储池提供给 Ceph 客户端。

重要

Ceph 的对象复制或编码区块使得 RAID 过时。不要使用 RAID，因为 Ceph 已经处理数据持久性，降级的 RAID 对性能有负面影响，并且使用 RAID 恢复数据比使用深度副本或纠删代码区块要慢得多。