上个月，Ceph 社区发布了针对 10.2 Jewel 版本的首个错误修复补丁，版本号为 10.2.1。这是个好消息，但 Ceph 究竟是什么？Ceph 是一种软件定义的分布式对象存储解决方案。最初由 Inktank 于 2012 年开发，该解决方案后来于 2014 年被 Red Hat, Inc. 收购。它是开源的，并根据 Lesser General Public License (LGPL) 许可协议发布。

在 Ceph 的世界中，数据被视为对象进行处理和存储。这与传统的（和遗留的）数据存储解决方案不同，在传统方案中，数据通过扇区和扇区偏移量（通常称为块）写入和读取存储卷。当处理大量大型数据时，将它们视为对象是正确的方法。而且也更容易管理。事实上，云功能就是这样运作的——使用对象。这种对象驱动的模型使 Ceph 能够轻松实现简化扩展，以满足消费者需求。这些对象在整个节点集群中复制，赋予 Ceph 容错能力，并进一步减少单点故障。

去年，Ceph 社区发布了对纠删码池的支持。这意味着，通过纠删码的概念，对象不再需要复制数据对象并消耗原始数据的双倍或多倍空间，而是通过一种算法重新计算，并添加额外的填充以处理数据不一致或故障。这确实会带来一些性能成本。无论如何，Ceph 还被设计为能够自我修复和自我管理。所有这些都在较低的级别发生，并且对用户或客户端应用程序是透明的。

为了实现可访问性，Ceph 向用户空间公开了三个接口。第一个是对象存储。此对象存储可通过 RESTful 接口访问，并同时支持 OpenStack Swift 和 Amazon Simple Storage Service (S3)。通过这种方法，Web 应用程序可以直接向对象存储发送 PUT、GET 和 DELETE 方法，而无需重写应用程序代码或担心对象存储在哪里。

第二个接口是精简配置的块设备。这背后的目标是让 Ceph 能够无缝融入现有的计算环境。访问文件/块卷的应用程序和虚拟环境不需要重新架构，但仍然能够利用 Ceph 提供的大部分特性、功能和弹性。Ceph 基于对象的模型的一个优势是，其上的块设备和文件系统接口（见下文）能够很好地支持快照、克隆和更好的负载均衡。

第三个也是最后一个接口是文件系统。虽然最终文件系统将提供与块设备大致相同的可访问性和功能，但在 Ceph 的实现中，内置文件系统确实移除了块设备层（减少了总堆叠层数），并直接连接到对象存储后端。这确实简化了维护和调试。

正如今天发布的 Ceph 一样，它完全通过命令行进行管理。Red Hat 重新发布了 Ceph，并带有一个名为 Calamari 的基于 Web 的管理用户界面。Calamari 简化了 Ceph 的常规管理。它附带服务器和客户端组件。客户端组件提供基于 Web 的仪表板。它通过 RESTful API 直接与服务器通信。

现在，虽然 Ceph 本身解决了许多行业问题，尤其是在数据管理和扩展方面，但它只是更大拼图中的一小块。Ceph 旨在处理两件事：1) 它通过在节点集群中分发数据（复制或纠删码）来实现容错，以及 2) 它为用户提供对相同数据的访问。之上和之下的部分完全取决于存储管理员。例如，在 Ceph 框架之下，硬件是如何监控的？驱动器故障是如何检测和纠正的？在框架之上，块和文件系统卷是如何导出的？如何为这些卷启用高可用性？

这就是软件再分发商发挥作用的地方。诸如 Red Hat、SUSE、Canonical (Ubuntu) 等供应商将所有这些部分粘合在一起，并将它们统一在一个管理空间下。有些供应商在这方面比其他供应商准备得更充分。为了增加可信度，数据存储行业的许多大公司都加入了 Ceph 的行列，包括 SanDisk、SolidFire（现在是 NetApp 的一部分）等等。这些供应商以某种形式或另一种形式使用 Ceph。

Ceph 也面临着一些非常强大且商业化的竞争。例如，在本地云或混合云领域，有 Cleversafe（IBM 公司）、Amplidata（现在是 HGST，西部数据公司）、Scality、Amazon (AWS)、Microsoft (Azure) 和 Google (Google Cloud Storage)。

我看到了 Ceph 强大而有希望的未来。当然，像任何其他数据存储解决方案一样，它并不能满足所有数据存储需求，但它就在这里，并且是软件定义存储领域的又一个竞争者。