了解 Ceph：开源可扩展存储
| 2018 年 8 月 19 日星期日 | 类别：存储 |
介绍
在这篇博文中，我将尝试解释为什么我认为Ceph是一个如此有趣的存储解决方案。阅读完这篇博文后，您应该对 Ceph 有一个很好的高级概述。
我写这篇博文纯粹是因为我是一个存储爱好者，而且我发现 Ceph 技术很有趣。
什么是 Ceph？
Ceph 是一种软件定义的存储解决方案，可以在性能和容量方面进行扩展。Ceph 用于构建多 PB 的存储集群。
例如，Cern已经构建了一个65 PB的Ceph 存储集群。我希望这个数字能引起你的注意。我认为这很神奇。
Ceph 存储集群的基本构建块是存储节点。这些存储节点只是包含大量硬盘驱动器和/或闪存的商品 ( COTS ) 服务器。
存储节点示例
Ceph 旨在扩展。您还可以通过添加额外的存储节点进行扩展。您将需要多台服务器来满足您的容量、性能和弹性要求。当您使用额外的存储节点扩展集群时，容量、性能和弹性（如果需要）都将同时增加。
就是这么简单。
您不需要从 PB 的存储开始。实际上，您可以从很小的地方开始，只需几个存储节点，然后随着需求的增加进行扩展。
我想谈谈一个技术细节，因为它说明了围绕 Ceph 的思维方式。使用 Ceph，您甚至不再需要 RAID 控制器，一个“笨拙”的 HBA 就足够了。这是可能的，因为 Ceph 管理软件中的冗余。其核心的 Ceph 存储节点更像是JBOD。硬件简单而“笨拙”，智能全部存在于软件中。
这意味着硬件供应商锁定的风险大大降低。您不受任何特定的专有硬件的约束。
Ceph 有何特别之处？
Ceph 存储集群的核心是CRUSH算法，由Ceph 的共同创建者Sage Weil开发。
CRUSH 算法允许存储客户端计算需要联系哪个存储节点来检索或存储数据。存储客户端可以自行决定如何处理数据或从何处获取数据。
重申一下：给定存储集群的特定状态，客户端可以计算要联系哪个存储节点来存储或检索数据。
为什么这么特别？
因为没有集中的“注册表”来跟踪集群上数据（元数据）的位置。这样一个集中的注册表可以变成：
- 性能瓶颈，防止进一步扩展
- 单点故障
Ceph 摒弃了用于数据存储和检索的集中式注册表的概念。这就是为什么 Ceph 可以在确保可用性的同时扩展容量和性能的原因。
CRUSH 算法的核心是CRUSH 图。该映射包含有关集群中存储节点的信息。该映射是存储客户端需要执行的计算的基础，以便决定联系哪个存储节点。
这个 CRUSH 图从一个特殊的服务器分布在集群中：“监控”节点。无论 Ceph 存储集群的大小如何，整个集群通常只需要三 (3) 个监控节点。存储节点和存储客户端都联系这些节点。
所以 Ceph 确实有某种集中的“注册表”，但它的用途完全不同。它只跟踪集群的状态，这是一项比运行“注册表”来存储/检索数据本身更容易扩展的任务。
请务必记住，Ceph 监控节点不存储或处理任何元数据。它只跟踪客户端和单个存储节点的 CRUSH 映射。数据总是直接从存储节点流向客户端，反之亦然。
Ceph 可扩展性
存储客户端将直接联系适当的存储节点以存储或检索数据。两者之间没有任何组件，除了网络，您需要相应地调整其大小1。
因为没有可能造成瓶颈的中间组件或代理，Ceph 集群可以真正在容量和性能上水平扩展。
在扩展存储和性能的同时，数据受到冗余保护。
Ceph 冗余
复制
简而言之，Ceph 执行“网络”RAID-1（复制）或“网络”RAID-5/6（擦除编码）。我这是什么意思？想象一个 RAID 阵列，但现在也想象它不是由硬盘驱动器组成的阵列，而是由整个服务器组成。
这就是 Ceph 所做的：它将数据分布在多个存储节点上，并确保一条数据的副本永远不会存储在同一个存储节点上。
如果客户端写入两个数据块，就会发生这种情况：
请注意数据块的副本如何始终复制到其他硬件。
Ceph 超越了常规 RAID 的功能。您可以配置多个副本。您不仅限于只有一份数据备份副本的 RAID-1 2。存储更多副本的唯一缺点是存储成本。
您可能会认为数据可用性非常重要，以至于您可能不得不牺牲空间并承担成本。因为在规模上，简单的 RAID-1 复制方案可能无法再充分涵盖硬件故障的风险和影响。如果集群中的两个存储节点死了怎么办？
这个例子或考虑与 Ceph 无关，这是您在大规模运营时面临的现实。
RAID-1 或 Ceph 等效的“复制”提供了最佳的整体性能，但与“常规”RAID-1 一样，它的存储空间效率不是很高。特别是如果您需要多个数据副本来实现所需的冗余级别。
这就是我们过去使用 RAID-5 和 RAID-6 作为 RAID-1 或 RAID-10 的替代品的原因。Parity RAID 可确保冗余，但以存储性能（主要是写入性能）为代价的存储开销要少得多。Ceph 使用“擦除编码”来实现类似的结果。
擦除编码
使用 Ceph，您不会受到 RAID-5/RAID-6 的限制，只有一两个“冗余磁盘”（在 Ceph 的情况下是存储节点）。Ceph 允许您使用Erasure Encoding，这是一种让您告诉 Ceph 的技术：
“我希望你将我的数据分成 8 个数据段和 4 个奇偶校验段”
然后这些段分散在存储节点上，这允许您在遇到问题之前丢失多达四个完整的主机。您将只有 33% 的存储开销用于冗余，而不是使用复制可能面临的 50%（甚至更多），具体取决于您想要多少副本。
此示例确实假设您至少有 8 + 4 = 12 个存储节点。但是任何方案都可以，你可以只用 8 个主机做 6 个数据段 + 2 个奇偶校验段（类似于 RAID-6）。我想你明白了。
Ceph 故障域
Ceph 是数据中心感知的。我的意思是什么？嗯，CRUSH 图可以代表你的物理数据中心拓扑结构，由机架、行、房间、楼层、数据中心等组成。您可以完全自定义拓扑。
这使您可以创建非常清晰的数据存储策略，Ceph 将使用这些策略来确保集群可以承受某些边界上的故障。
拓扑示例：
如果你愿意，你可能会失去整个机架。或者一整排机架和集群仍然可以完全运行，尽管性能和容量有所降低。
如此多的冗余可能会花费大量存储空间，以至于您可能不想将其用于所有数据。那没问题。您可以创建多个存储池，每个存储池都有自己的保护级别和成本。
你如何使用 Ceph？
Ceph 的核心是对象存储解决方案。Librados 是您可以包含在软件项目中以本地访问 Ceph 存储的库。有以下编程语言的 Librados 实现：
- C(++)
- 爪哇
- Python
- PHP
许多人正在寻找更传统的存储解决方案，例如用于存储虚拟机的块存储、兼容 POSIX 的共享文件系统或兼容 S3/OpenStack Swift的对象存储。
除了原生对象存储格式之外，Ceph 还提供了所有这些特性。
我本人最感兴趣的是块存储（Rados Block Device）（RBD），目的是存储虚拟机。由于 Linux 对 RBD 具有原生支持，因此使用 Ceph 作为 OpenStack 或普通 KVM 的存储后端是完全有意义的。
在最新版本的 Ceph 中，添加了对iSCSI的本机支持，以便向 VMware 或 Windows 等非本机客户端公开块存储。郑重声明，我（目前）还没有使用此功能的个人经验。
对象存储守护进程 (OSD)
在本节中，我们将详细介绍 Ceph 的技术细节。
如果你读过 Ceph，你就会读到很多关于 OSD 或对象存储守护进程的文章。这是在存储节点上运行的服务（守护进程）。OSD 是 Ceph 的实际主力，它提供来自硬盘驱动器的数据或摄取数据并将其存储在驱动器上。OSD 还通过基于 CRUSH 映射将数据复制到其他 OSD 来确保存储冗余。
准确地说：对于存储节点中的每个硬盘驱动器或固态驱动器，都会有一个 OSD 处于活动状态。您的存储节点是否有 24 个硬盘驱动器？然后它运行 24 个 OSD。
当驱动器出现故障时，OSD 也会出现故障，监控节点将重新分发更新的 CRUSH 映射，以便客户端知道并知道从哪里获取数据。OSD 也会响应此更新，因为冗余丢失了，它们可能会开始复制非冗余数据以使其再次冗余（跨更少的节点）。
更换驱动器后，集群将“自我修复”。这意味着新驱动器将再次充满数据，以确保数据均匀分布在集群内的所有驱动器上。
因此，也许有趣的是，存储客户端可以有效地直接与 OSD 对话，而 OSD 又会与单个硬盘驱动器对话。客户端和数据本身之间没有很多组件。
结束语
我希望这篇博文能够帮助您了解 Ceph 的工作原理以及它为何如此有趣。如果您有任何问题或反馈，请随时发表评论或给我发电子邮件。
-
如果您有大量的大容量顺序数据存储流量，您应该意识到拥有大量驱动器的单个主机很容易使 10Gbit 甚至理论上 40Gbit 饱和。我假设每个硬盘驱动器为 150 MB/s。使用 36 个硬盘驱动器，您将面临 5.4 GB/s。即使您只运行该速度的一半，您也需要绑定多个 10Gbit 接口来维持此负载。想象一下您的核心网络的要求。但这真的取决于你的工作量。例如，除非您使用 SSD，否则您永远无法通过大量随机 I/O 达到这种吞吐量。 ↩
-
请注意，在生产设置中，默认情况下共有 3 个数据块实例。所以这意味着“原件”加上两个额外的副本。另请参阅此链接。感谢 Reddit 的 sep76指出默认值是 3 个数据实例。 ↩
注释