【51CTO.com快译】近年来，各大主流云计算平台都已经广泛地采用了基础设施分解(Infrastructure disaggregation)的方式，让云服务能够提供完全独立于现有计算实例(compute instances)的存储系统。可以说，通过将数据中心资源里的内存、计算力、以及存储进行解耦，它能够让每个资源都具有独立扩展和配置的能力。据此，云端租户不但可以更加有效地使用计算资源，而且能够达到可扩展性与灵活性。
而分解式存储(Disaggregated storage)则是一种可组合的分解式基础架构。它通过在网络结构上连接各种物理存储设备，以形成逻辑上的存储池，并最终以按需的方式提供可扩展的存储。由于分解式存储能够支持动态环境的创建，因此其中的计算和存储资源可以根据应用程序的实际负载，进行动态调配。此外，它能够像计算实例那样，在不干扰应用服务的可用性的前提下，灵活地实现存储的扩展与管理。
分解式存储架构
从概念上说，分解式存储会通过将多个存储设备组合到一个逻辑池中，进而将存储资源提供给服务器实例，以实现存储与计算的分离。同时，存储设备在连接到网络结构中之后，可以模拟出存储区域网络 (SAN)，以便灵活地扩展出应用所需的存储资源。不过，传统的SAN是在共享存储资源中，将负载紧密地耦合在一起。而分解式存储则可以提供非本地的存储。它既为每个负载提供了直接附加存储(Direct Attached Storage，DAS)的设计，又提高了资源的利用率、可扩展性、可管理性、以及其他非本地存储的优势。
目前，分解式存储的一项突出趋势在于：它使用了高速的NVME-oF(Non-Volatile Memory Express over Fabric)架构、以及通过NVMe over TCP，并网络去连接存储设备。NVMe使用闪存来提高固态存储设备(SSD)的速度和性能，并使用PCI-Express总线将SSD连接到服务器上。也就是说，使用了NVMe-oF的分解式存储，将高性能的SSD与服务器的CPU相隔离，然后通过低延迟、低抖动的协议，将它们提供给远程的计算节点。NVMe over TCP已于2020年秋季被引入Linux内核，并提供了端到端的延迟保证，您可以通过链接—https://blog.mayadata.io/mayastor-nvme-of-tcp-performance，以了解更加详细的信息。
采用分解式存储
如今，以机器学习、Cassandra的NoSql、以及ElasticSearch等日志记录为代表的应用程序，对于高性能和低延迟日益重视，DAS在许多负载中都占据了主导地位。而鉴于上述原因，基于NVMe-oF的分解式存储拥有更为广泛的使用场景。例如：使用共享架构的Kubernetes通过扩展，实现了按需为每个负载分配适量的存储和计算资源。而那种使用了分解式池化存储的软件平台，更可以从优先级较低的应用程序处，借用到存储或CPU资源，以便让高性能的应用程序，按照负载的变化，实现自动化的无缝扩展。
对于分解式存储的性能要求：
分解式存储可以为各种独立的应用程序带来如下性能优势：
1. 高速的网络结构 - 分解式存储能够在访问速度、以及延迟方面，满足严格的服务质量(QoS)需求。此类网络通过池化的网络式存储，以获取高度可扩展性、高性能，并能以非拥塞的方式连接到计算服务器上，以便多台主机快速地访问到存储。
2. 快速存储的网络协议 - 分解式存储通过诸如：NVMe和NVMe-oF之类的高效且快速的传输协议，以比传统的iSCSI协议更低延迟的方式，在SSD直连的计算节点处，实现最大的IOPS(Input Output operations Per Second，IOPS)。
3. 快速、安全、可扩展的I/O控制器 – 此类存储控制器能够快速、安全地在底层SSD上，执行读/写操作，并能根据它们所支持的负载，使用松散耦合的架构，来实现弹性的横向扩展。
分解式存储的类型
目前分解式存储拥有如下三种类型与形式：
配置分解
这是一种非动态形式的分解。由于是在服务级别的配置期间执行存储抽象，因此它不需要持续运行控制器的监视。存储池可以通过重新配置，实现在部署期间、或在为不同的应用程序重建存储架构时，处理不同的工作负载。
故障分解
作为另一种非动态形式的分解，存储驱动器仅在应用出现故障时，被重新分配给不同的主机。虽然重新配置鲜少发生，但是此类分解进一步提高了应用程序的容错能力。
动态弹性分解
在这种形式中，驱动器通常会被池化，并且不连接到多个I/O控制器上。因此，每个服务器都可以一次性连接多个驱动器。随着服务器请求和负载数量的变化，存储的重新配置会频繁发生，它们每隔几个小时就会请求不同的存储驱动器。
由于存储资源被默认为完全抽象的，因此在此类分解形式中，任何主机都可以通过任何I/O控制器，连接到任何存储驱动器上。而且由于服务器与存储的连接，会通过重新调整，来适应每个I/O请求，因此基础设施的重新配置也就会动态发生。例如，Kubernetes会水平扩展成为使用I/O控制器的主机，按需为负载的分解提供算力。
分解式存储的优势：
分解式存储为计算和基础设施提供了如下方面的改进：
1. 提高资源的利用率 - 分解式存储能够根据优先级、以及应用程序的需求，动态地分配存储资源。同时，它能够让用户享用到由SSD提供的快速I/O。这就意味着租户可以将所有可用的存储资源都投入使用，并根据应用程序的实际要求，在设备的I/O、容量、吞吐能力之间，按需实现最佳配置。
2. 使得SSD灵活且可扩展 - 借助分解式存储，用户可以为应用程序分配任意数量的SSD，然后按照应用程序的实际要求增减其容量。
3. 简化扩展 - 分解式存储允许用户创建动态可扩展的存储架构，以满足使用Shared-Nothing架构的资源需求变化。
4. 支持创建高性能的应用程序 - 分解式存储允许用户按需分配吞吐量和读写速度，以满足实际的负载需求。由于应用的执行效率更高，因此用户访问其存储数据的延迟也就更小。
分类存储的发展趋势
在新技术的加持下，分解式存储作为DAS的替代方案，得到了开发与采用。其中，Non-Volatile Memory Express(NVMe)和Non-Volatile Memory Express Over Fabric (NVMe-oF)通过高速的I/O和网络，实现了对于SSD的更好利用。例如，Amazon的EBS和Azure的Blob Storage等公共云的Web Scaler，都能够构建出大量的计算实例。而这些实例通过利用优化的硬件和软件基础设施，为大量分布式的服务器提供了远程的块存储设备。
Kubernetes如何启用分解式存储：
分解式存储能够完美地与Kubernetes相配合。也就是说，Kubernetes通过创建一个灵活且高度可扩展的部署环境，可以实现对负载和存储控制器的编排和扩展。同时，Kubernetes使用Persistent Volumes和Persistent Volume Claims，根据容器存储的需求将各种Pod附加到物理存储的抽象之中，进而为集群提供灵活的存储。此外，通过容器存储接口(Container Storage Interface，CSI)，Kubernetes允许第三方存储提供商通过扩展卷功能的方式，来创建块和文件存储的解决方案。可以说，有了CSI，用户可以虚拟地分离出计算层和存储层，从而为应用程序启用分解式存储。通常，Kubernetes的CSI插件具有如下两种类型：
1. 存储驱动器 – 由于可以在Kubernetes集群之外被维护，因此它允许将应用程序配置为利用存储类(Storage Classes)和持久卷声明(Persistent Volume Claims)，去动态地使用资源。
2. 容器附加存储 (Container Attached Storage，CAS) - 此模型通过按需将容器化的存储控制器，分配给负载，来实现基于负载的存储。存储在集群中运行，各种控制层面元素(control plane elements)位于主节点处，而数据层面的负载则运行在工作节点上。数据层面节点既可以是本地节点，也可以是由主节点中的控制器去独立调度和扩展分解式的存储目标。通过使用CAS模型，每个卷都有一个专用的控制器Pod和一组多个副本的Pod。您可以通过链接--https://www.cncf.io/blog/2018/04/19/container-attached-storage-a-primer/，了解更多有关CAS架构的详细论述。
通过CSI的连接，以及扩展和编排存储软件的能力，Kubernetes很好地支持了分解式存储。
由MayaData OpenEBS提供的容器附加存储(Container Attached Storage，CAS)部署了一个数据管理层面。该层面在架构上映射到Kubernetes的应用程序管理层。OpenEBS将分解的存储统一到Kubernetes应用层的一个组件中。而对于Kubernetes应用程序而言，在那些已部署到企业数据中心的异构硬件和软件之上，OpenEBS创建了统一的存储基础架构。它不但简化了开发人员的工作量，而且让DevOps拥有更大的控制权，甚至为CxO们提供了完整的使用可视性。可以说，OpenEBS能够让用户管理起跨企业数据中心的有状态应用来，更加简单、可预测、更加游刃有余。
最近的一项调查证实，OpenEBS是最受欢迎的CAS存储项目之一。与其他云原生的、适合Kubernetes的项目相似，OpenEBS在界面和功能上，避免了传统存储架构“共享一切”的依赖项和可扩展性。而且，OpenEBS非常易于操作和使用。
OpenEBS依靠控制层面来提供卷，并执行卷的相关操作。它包含了一个PV配置器，能够动态地为正确节点上的卷副本Pod和目标控制器Pod，创建特定的部署要求。同时，OpenEBS数据层面也包含了一个存储引擎，该引擎能够实现集群卷的实际I/O路径。当然，它也可以在LocalPV模式下，启用对存储设备的本地或分解式访问。如下图所示，存储引擎可以在用户空间中作为微服务运行，通过灵活的配置和扩展，以满足负载的需求。
如果您想了解更多有关基于CAS的OpenEBS不同组件的信息，请参见链接--https://docs.openebs.io/docs/next/architecture.html?__hstc=216392137.5bad910047ce69cba4f6eb08bb766f5e.1624011986371.1624024266165.1624031273026.3&__hssc=216392137.3.1624031273026&__hsfp=2402044620。当然，您也可以通过加入OpenEBS社区，以进一步了解OpenEBS如何为Kubernetes实现分解式存储。
小结
分解式存储通过将计算与存储解耦，实现了高速、灵活、且具有高度可扩展的应用程序。借助分解式存储，用户可以利用高速NVMe的SSD，受益于低延迟和增强的负载响应能力。可以说，作为一种独特的存储解决方案，分解式存储的速度、灵活性和低延迟，在优化资源使用的同时，也降低了TCO。
原文标题：A Detailed & Comprehensive Guide to Disaggregated Storage，作者: Sudip Sengupta
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
