分布式存储和箱内思考

2013年9月12日 sage

我通常会尽量忽略互联网上人们说的所有无聊的事情，但偶尔也会有一些来自可靠来源的信息具有足够的误导性，让我觉得有必要做出回应。 Cloudscaling 首席执行官 Randy Bias 的白皮书融合存储，美好的愿景与现实是一篇值得认真反驳的论文，仅仅因为作者通常会提供敏锐的观察和有趣的观点。 Jeff Darcy（来自 GlusterFS）已经发布了坦率的回应，总结了他对 Randy 的推理的问题（以他一贯的风格），但还有一些我想在这里强调的事情。

首先，在讨论任何实际论点之前，Randy 试图通过将传统环境中的传统存储用例映射到云中来为他的论点建立一些背景。这种映射对我来说毫无意义

Randy 的“云时代的分层存储”

该图表将传统环境中性能要求等同于云中的存储 API。 性能要求并不决定 API；这些是完全正交的概念。传统的 SAN 和 NAS 产品提供块和文件 API，这些 API 可以非常快或非常慢，而分布式云解决方案（无论它们是块、对象还是文件）都具有相同的能力范围，具体取决于它们构建的技术。 S3 恰好是低性能和弱一致性对象存储，但它只是遵循了对象存储学术研究十年的一个实现。所谓软件定义存储的重点在于，你不再受限于设备供应商选择将哪些组件和软件封装在他们的金属外壳中：你可以使用任何满足你的需求的硬件构建对象、文件或块解决方案。

无论如何，Randy 提出了三个反对 Ceph、GlusterFS 和 Sheepdog 等分布式存储系统的论点。让我们从前两个开始

经济性：没有一种技术（SSD、磁盘、磁带）能够涵盖整个成本和性能需求范围（从第一层到第三层）
存储技术：有时人们需要 SSD 来实现高 IOPS，有时他们需要旋转磁盘，有时他们甚至（天哪）需要磁带。有时你可以构建混合系统。

这些陈述显然是正确的，但尚不清楚这与分布式存储解决方案有什么关系。你可以购买使用 SSD 和 HDD 的不同组合的专有和开放系统。更重要的是，而且更直接地与 Randy 的观点相关，你可以构建一个包含所有这些技术的单个 Ceph 集群，以各种组合提供不同的存储池以满足不同的目的。这让你能够在一个集群中捕获对性能和存储 API 的多样化需求，而不受过时观念的限制，例如使用“对象”API 意味着低性能或弱一致性。如果应用程序需要高性能、强一致性对象存储，请使用 SSD 创建 Ceph 池并使用 librados。如果应用程序是低性能的大容量日志存储，请使用 SATA 磁盘构建 Ceph 池并使用 CephFS 或 RBD。使用你喜欢的任何供应商的通用硬件构建它，并将其全部作为一个集群进行管理。

讽刺的是，Cloudscaling 似乎在捍卫的系统正在做同样的事情：现代 SAN 也是分布式系统，其设计基于许多与 Ceph 和 GlusterFS 相同的原理和算法。不同之处在于，它们针对有限的规模以简化扩展需求（通常最多 10 多个节点），被迫围绕标准化的遗留协议进行架构设计，并整齐地封装在带有发票和维护合同的金属外壳中。这种黑盒方法创造了“秘方”的价值幻觉，使设备供应商能够对本质上是商品组件、专有软件和定制铭牌收取他们所收取的费用。它也足以掩盖这样一个事实，即它们存在于与 Cloudscaling 担心会使你更难使用“适合工作的工具”相同的现实中。现实是，Ceph 和其他供应商提供的供应商和技术的选择让你在构建存储云方面拥有更大的灵活性，并且你可以将它们全部组合到一个云中。

最后，第三个论点

关于 CAP 的一些背景，然后/因此：分布式存储系统解决了扩展问题，但它们没有解决故障域问题。相反，它们使故障域变得更大

认为 Ceph 和 GlusterFS 等系统不允许你控制故障域的大小，这完全误解了这些（以及几乎所有其他）分布式系统的作用。故障和对故障的响应实际上是我们的首要任务。在 Ceph 的情况下，例如，我们的数据分布机制（CRUSH）明确赋予系统设计者和管理员控制故障域的大小和布局，并根据它们描述数据放置策略。人们可以选择跨主机、机架或数据中心复制，具体取决于网络弹性以及/或应用程序要求。同样，Ceph 监视器守护程序使用 Paxos 提供一个中央共识来源，以有效地仲裁 Randy 担心的那种网络分区，而无需在数据路径中需要像 Paxos 这样的语义的复杂性和开销。

看看 Cloudscaling 的末日故障示例

CAP “陷阱”

首先，很少有人会构建这种 2 节点或 2 集群系统并称之为分布式；在这种情况下的故障和一致性语义是边际的（由于同样的原因，使用 DRDB 等系统进行纯双向复制非常脆弱）。但是，假设你确实想构建上述系统，一个（称职的）Ceph 管理员会在第三个位置（也许与使用存储的 VM 共置）放置一个监视器，以便在左侧子集群离线时提供可靠的共识，并在上述故障场景中保持一致性和可用性。瞧，一个在整体系统略低于一半离线时仍然可用的 CP 系统。

更现实和更明智的部署可能会决定适当的故障域是机架或一组机架（由于共享电源电路或 PDU、共享顶层交换机等）。分布式存储系统将在机架内的主机之间复制以实现近线故障转移存储选项（就像他所倡导的所谓 EBS 一样），跨机架复制以实现持久性跨故障存储选项（更像 Amazon 的 S3），甚至跨数据中心和地理位置复制以实现持久性跨灾难解决方案。并且它可能在同一个集群中执行所有这些操作，并提供一系列具有不同性能配置文件和 API 的池，具体取决于应用程序要求。

Randy 确实指出了权衡，但没有注意到新一代分布式存储技术旨在让你做出这些艰难选择。对于某些应用程序，AP 系统可能更合适（尽管我认为这通常由应用程序要求决定，这些要求不是性能相关的）。 Swift 可能是一个理想的选择，用于 RESTful 对象存储，例如。块和文件 API 的使用者通常需要强一致性，但将具有各种可用性要求，这些要求决定了为他们的应用程序定义故障域的方式。有些用户只需要存储才能承受磁盘故障；另一些用户即使在整个数据中心离线的情况下也需要一致运行。

与所有强大的工具一样，Ceph 和 GlusterFS 可能会被滥用，并且天真地将云规模存储解决方案应用于任何问题都可能很危险。这些系统的优点在于，你可以架构存储解决方案来满足所有这些用例，并具备对你的要求、分布式共识以及在那种环境中选择 CP 或 AP 的含义的基本理解。遗憾的是，这篇论文在这方面没有提供任何见解。