认识 Shared-Nothing 存储系统
Source: Howard Marks, Exploring Shared-Nothing Storage, Sep 13, 2021
如今，很多扩展性存储系统都基于Shared-Nothing架构，其中每个节点都独占其拥有的数据盘，包括HDD和SSD。厂商已经构建了几乎覆盖存储领域中各个方面的Shared-Nothing系统。SolidFire的全闪存块阵列，和面向高性能计算的并行文件系统（如BeeGFS）通过Shared-Nothing集群实现高性能。而像Ceph、Swift、Scality以及Hadoop的HDFS这样的对象存储系统则更侧重于容量而非性能。Nutanix和Scale Computing将每个节点放在虚拟化主机上，与用户虚拟机一起创建了又一个Shared-Nothing的用例。
从许多方面来看，如今的Shared-Nothing存储延续了2000年代初期的软件定义存储运动。一旦服务器处理器的性能足够强大，能够在软件中提供存储服务，而无需RAID协处理器和定制ASIC芯片，x86服务器就成为了存储系统控制器的主力军，即使像Nimble和Tintri这样的厂商提供的是存储设备。
因此，当存储开发人员将注意力转向规模问题时，他们自然会使用x86服务器作为构建块。然后，他们可以开发软件来将网络集群中许多硬盘的存储聚合成一个存储池，并将该存储抽象为文件系统、对象存储或块存储。
Shared-Nothing节点的封装形式几乎与其基于的x86服务器一样多样。供应商提供标准的1U和2U机箱式、高密度服务器以及刀片式，类似于计算服务器。就像服务器一样，每种封装形式都有其优点和缺点。
Shared-Nothing群集
虽然Shared-Nothing节点通常配备了冗余电源和网络连接，但服务器主板有多个单点故障，因此Shared-Nothing系统必须保护其数据免受节点和硬盘故障的影响。为了防止节点和硬盘故障，Shared-Nothing系统会在多个节点之间复制（多副本）或进行纠删码编码。然后，如果出现硬盘或节点故障，系统可以使用存活的副本或纠删码条带进行重建。由于这基本上是将RAID从硬盘驱动器扩展到集群节点的技术，包括单重和双重奇偶校验作为纠删码，因此早期的Shared-Nothing厂商将他们的架构称为“RAIN”（独立节点的冗余阵列）。
Shared-Nothing系统以各种方式和不同粒度在集群的节点之间划分和保护数据。例如，某些对象存储仅在两个或三个节点之间复制每个对象。一些简单的系统直接将节点A上硬盘3的数据镜像到节点B上的硬盘3，而更复杂的系统则使用分布式Reed-Solomon编码对逻辑块进行编码。
Shared-Nothing的延迟难题
无论具体细节如何，将数据复制或纠删码编码到多个节点故障中会增加至少一个网络往返的传输时间，从而增加写入的延迟。
Shared-Nothing的写入流程
当用户或计算服务器访问Shared-Nothing集群时，它们仅连接到一个集群节点。当用户写入数据时，用户所连接的节点必须在确认写入之前，将数据复制或纠删码编码到一个或多个其它节点以保护该数据。
由于服务于写入的节点必须等待来自参与该写入的所有其它节点的确认，任何给定写入的延迟取决于最慢的节点。因此，如果一个节点由于任何原因繁忙，比如连接到它的用户也在写入数据，该节点的响应时间可能会比较长，从而增加写入的延迟。
Shared-Nothing系统可以通过复制写缓存来减轻这种不确定性。它们在写入时不对数据进行纠删码编码，而是将新的写入数据存储在NVRAM中，并将新写入的数据复制到另一个节点的NVRAM缓存中，然后才确认写入。在将数据迁移到持久性硬盘（无论是HDD还是SSD）时，再进行纠删码编码。然而，写入缓存的问题在于，除了NVDIMM的成本之外，维护跨多个节点的一致缓存是复杂的，并且在节点之间会产生大量的东西向网络流量，这可能会影响性能，特别是在运行并行应用程序时。
读也是如此
使用纠删码的Shared-Nothing系统在读取时也会受到网络延迟的影响。想象一个将文件划分为128KB条带的系统，分布在各个节点上。当用户发出一个1MB的读取请求时，接收节点必须检索8个128KB的条带并将它们重新组合成1MB的回复。如果一个节点繁忙，用户就必须等待。
这在使用分散编码将纠删码条带分布到多个集群或数据中心的对象存储系统中变得更加糟糕。这些分散编码可以从纠删码条带的18个条带中的任意12个条带中恢复数据。但由于分散编码不像Reed-Solomon的本地解码编码那样使用独立的数据和校验条带，因此这些系统在进行小规模读取时也必须具有12个18个条带来解码数据。当每个数据中心存储6个条带时，WAN延迟必须包含在读取延迟中。
超越Shared-Nothing系统
从其普及程度可以看出，Shared-Nothing体系结构是解决2000年代和2010年代规模问题的良好解决方案。用户可以使用当时的行业标准构建块构建PB级存储系统，但这些系统从未成为Shared-Nothing倡导者所承诺的“设定并忘记的独立节点冗余阵列”。只有在我们确保在睡前检查并妥善安置它们时，它们才能正常工作。
===-===-===
在世纪之交，Shared-Nothing存储架构对帮助组织实现超越当时规模上限的存储以及管理数据爆炸和对简单可扩展存储容量的需求起到了至关重要的作用。这些系统是对之前的双控制器、小容量存储系统的完美回应……帮助客户实现了突破性的速度、弹性和扩展性。
Shared-Nothing存储的采用产生的影响简直是地壳运动般的，它的影响可以在当今许多流行的存储技术中感受到，包括：
世界上许多网络和云存储基础设施，如AWS和Dropbox
文件系统：如Dell EMC Isilon和Pure Storage的FlashBlade
Shared-Nothing的存储：Ceph和IBM Cleversafe等解决方案
大数据架构：Apache Hadoop和Splunk等
虚拟化中的应用：Nutanix和vSAN等产品
现代备份设备：Rubrik和Commvault Hyperscale等
在过去的20年里，数十亿美元的基础设施已经部署为Shared-Nothing的集群。这些产品的成功也揭示了它们没有解决的问题。随着每一EB的部署，Shared-Nothing存储集群架构的初始目标变得越发混乱。让我们从高层次来看一下：
性能可扩展性
承诺：通过向集群添加更多节点（CPU + 硬盘），Shared-Nothing集群可以轻松扩展性能。
现实：由于每个集群节点必须与其它集群节点协调数据和元数据活动，与集群一致性和存储重建相关的交互限制了有效性能规模，仅限于几十个节点。随着系统变得越来越大，集群内部的交互也随之增加。大多数商业化的分布式存储设备在几十个节点之外无法继续扩展，因为性能递减法则限制了客户看到线性性能增益的能力。
容量可扩展性
承诺：通过在节点之间聚合存储，Shared-Nothing产品消除了双控制器架构产生的存储孤岛，通过添加更多节点来增加容量变得简单。
现实：Shared-Nothing存储与节点的CPU紧密耦合，且Shared-Nothing专注于HDD，导致基础设施的池和层次不具备全局可扩展性。数据在一个层次和卷、目录以及数据管理操作之间受到限制，通常不会在这些池之间发生交互。结果，Shared-Nothing系统内仍存在数据分割和效率低下，尽管它们被开发用于消除基础设施孤岛。在经典Shared-Nothing架构中存在存储分层，这仍然迫使客户在解决容量和性能大小问题时进行权衡。
多租户云存储基础设施
承诺：Shared-Nothing存储系统采用了世界领先云服务中使用的概念，并设计为同时托管多个应用程序的要求。
现实：由于Shared-Nothing系统将对任何节点进行的I/O请求广播到集群中的多个节点，强大的应用程序可以对多租户环境造成严重影响。因此，许多组织将为不同的用户或不同的目的部署不同的Shared-Nothing集群……从而创建了这些系统旨在消除的基础设施孤岛。
“全局”存储逻辑
承诺：“一”。一个命名空间，一个简单的管理体验，一个适用于整个集群的算法集合。一切都是简单、可扩展和高效的。
现实：CPU与硬盘的紧密耦合导致存储算法的规模限制，这些算法在本质上限制了这些产品能够适应现代应用程序需求的能力：
没有任何系统被构建为在1,000多个耐用性低、容量高的SSD上全局缓冲写入和管理磨损——这迫使供应商使用昂贵的闪存。
纠删码条带不会扩展到10-20个数据块以上，导致开销通常在累积集群容量的20-40%。
没有任何Shared-Nothing系统构建全局数据减少字典，因为这需要将数据减少索引与节点的DRAM紧密耦合。因此，存储供应商必须解决规模问题，因为集群节点上每个索引副本的成本变得极高。
由此产生的结果：Shared-Nothing的闪存解决方案对于广泛采用来说太昂贵，仍然比HDD存储成本高出20倍，迫使客户继续在性能和容量之间取舍。
简易性
承诺：通过添加CPU和硬盘节点来轻松扩展，性能和容量都是线性增长的，无需选择。
现实：通过在节点架构中紧密耦合CPU、RAM和硬盘，Shared-Nothing集群创建了各种各样的节点类型，客户被迫在IOPS、吞吐量和容量需求之间权衡。大多数Shared-Nothing产品提供5-10种不同的节点选项，这迫使客户在性能和容量大小上做出硬编码和妥协的决策……随后他们必须希望将来不需要更多的性能来满足容量需求，因为他们购买的容量成为特定CPU的“人质”。
---【本文完】---
近期受欢迎的文章：
数据中心以太网和RDMA：超大规模环境下的问题 颠覆性创新？存储界已有所耳闻 CXL内存池：容量到底有多大？展望未来的可能性 《Persistent Memory; CXL; and Memory Tiering》讲座问题解答 探寻文件系统的本质：技术突破与市场变革
我们正处于数十年未见之大机遇中
新技术爆发式发展，催生新产品
然而，颠覆式创新并非简单的技术堆叠
而是异常复杂的系统工程
需要深度洞察
欢迎一起分享思考和见解