时代和技术在变，但数控分离的架构设计理念未曾改变

谈起数据和控制分离架构，耳熟能详的就是例如Lustre、StorNext、BeeGFS等一样的文件系统。但除了文件系统外，还有存储架构(SDS)、数据服务化/存储云化软件(如 Vipr)、云计算平台(如 OpenStack)和软件定义网络(SDN)等也采用这种架构，今天我们就逐个简单聊一下。

先从文件系统开始。但对大多数人来说，接触的比较多还是传统的文件系统，如NFS、CIFS等，所有的数据和元数据存放在一起，通过单一的存储服务器提供。这种模式称之为带内模式(In-band Mode)。随着客户端数目的增加，服务器就成了整个系统的瓶颈。因为系统所有的数据传输和元数据处理都要通过服务器，不仅单个服务器的处理能力有限，存储能力受到磁盘容量的限制，吞吐能力也受到磁盘I/O和网络I/O的限制。

在数据增长、并发要求极高(如 HPC等)的需求面前，当今对数据吞吐量要求越来越大的互联网应用中，传统的文件系统已经很难满足应用的需要。必须要采用分布式文件系统(如 Isilon、OceanStor 9000等)，或高性能SAN文件系统来应对此类需求。

于是，一种新的高性能SAN文件系统的结构出现了，那就是利用存储区域网络(SAN)技术，将应用服务器直接和存储设备相连接，大大提高数据的传输能力，减少数据传输的延时。这种文件系统就是经典的数控分离架构，所有的应用服务器都可以直接访问存储在SAN中的数据，只有关于文件信息的元数据才经过元数据服务器处理，减少了数据传输的中间环节，提高了传输效率，减轻了元数据服务器的负载。每个元数据服务器给应用服务器提供文件系统元数据服务，这种模式也称之为带外模式(Out-of-band Mode)。

如上提到的文件系统、CXFS、Lustre、BWFS等都采用这样的结构，因此它可以取得更好的性能和扩展性。区分带内模式(In-of-band Mode)和带外模式(Out-of-band Mode)的主要依据是: 关于文件系统元数据操作的控制信息是否和文件数据一起通过服务器转发传送，后者需要服务器转发，前者是直接访问。

下面再看看存储架构设计，传统高端存储的一个典型设计架构就是数据、控制Cache分离。而在高端存储中，具备数据、控制分离Cache架构设计的典型代表厂商是HDS和HPE。HDS VSP的内存在物理上分为两大类，一类是由DCA提供的Memory(全局共享)，另一类是由VSD提供的独享内存。

VSP的Cache分为Data Cache与Control Memory(即数控分离)。Data Cache即为用户数据的缓存，完全保存在DCA的Memory上，新写入存储的数据进行一一镜像。Control Memory即为运行业务所需的控制数据。实际上，控制数据包括所有内部运行元数据(Internal Operational Metadata)和系统状态信息(State Information of The System)，元数据除了包含LUN、Pool的元数据等信息外，还包括执行时间表、映射关系、安装的各种软件的数据、系统运行时需要存储、引用、执行需要的全部状态信息。

Control Memory在VSD内存(每个VSD自带内存)、DCA上各存一份。其中在DCA上的Control Memory是以优化后可恢复的格式写入的，属于备份而不是纯粹的镜像。VSP专门在控制框的第一对DCA上预留空间，用于存放Control Memory的备份。

VSP的实现更像是全局Cache和专有Cache架构，但在实际业务访问时，由于对元数据的访问，读请求为主且仅发生在VSD内部，和全局Cache无关。因此VSP的Cache设计，可以认为是数控分离架构，可实现元数据访问的快速访问、减少DCA的访问冲突，从而保证性能。

3PAR也实现了数控分离架构，并且明确由数据Cache和控制Cache之分。从3Par的宣传文档看，数控分离的其主要客户价值在于: 对并发的事务型小I/O负载与带宽型大I/O负载，可以做到高效处理，使其相互之间影响最小，其原理如下图所示。

如未实现数控分离，则处理小I/O所需的控制数据访问请求有较大概率与大I/O数据传输过程相冲突。这个冲突表现在两个方面:

一是对用户数据与控制数据所在公共内存的访问存在总线上的冲突；

二是公共计算资源CPU对SCSI命令的处理指令与数据传输过程中Parity、CRC计算指令之间的冲突。

对于前一种冲突场景，当内存总线成为系统瓶颈时对系统性能有较大影响；对于后一种冲突场景，则是CPU的计算能力成为系统瓶颈时对系统性能有较大影响。

实现数控分离后，SCSI指令的处理(含元数据的访问)与用户数据的传输过程在计算资源、总线通道上实现了物理隔离，互不干扰，有利于事务型小I/O负载与带宽型大I/O负载的并发高效处理。

总的来说，数控分离架构在内存带宽不足、CPU计算能力不足的情况下有性能优势，且能够很好规避数据和控制信息访问冲突问题。然而在CPU计算能力过剩、典型业务场景或内存带宽过剩的情况下，优势和价值可能就不太明显。

大家熟悉的OpenStack云计算平台，在存储管理上就是采用数据和控制分离的架构，存储设备通过Cinder、Malina等Restful API透传存储能力，通过Nova给VM挂载卷服务，但VM真正的数据访问还是直接从OpenStack底层的存储设备上去读取。

ProphetStor作为SDS厂商，其Federator是个数据服务平台和SDS存储平台，采用数据和控制分离架构。提供了存储发现、抽象、池、分类和配置的核心功能，无论是对接不同上层应用形态还是OpenStack云平台，所呈现的就是一个Federator平台，Federator之下对接了哪些设备是不对外体现的。Federator提供了与OpenStack无缝集成，如集成了OpenStack Cinder、Nova和Horizon等组件。

存储设备通过API发现和注册后作为Federator的存储资源，对客户而言，只需要关注Federator。ProphetStor在控制面提供的API如下。

在数据面，Federator支持NetApp、Nexenta、Ceph和FalconStor等多种存储系统适配接入能力，通过冗余链路支持应用对数据存储的访问能力。

在控制面上，Federator的存储联邦技术支持从异构物理存储环境中的多个池在抽象层中协同工作，同时抽象了各种底层存储资源的内置功能，提供了无缝的存储集成层、Rest API和Web UI，允许定义和满足用户或单个应用程序的存储需求。

OceanStor DJ也是类似的一款控制面SDS存储控制软件，统一管理存储资源，提供业务驱动、自动化的数据服务。其核心是基于OpenStack相关服务的增强，实现存储资源统一管理，按需分配和数据保护服务。将存储和数据保护等能力以XaaS的方式提供，实现存储价值链向软件服务转移。

在控制面上，OceanStor DJ将存储的功能特性从物理阵列中抽象出来，把具备相同或近似能力的多个物理存储池在逻辑上组成资源池。用户在请求存储资源的时候，基于资源池的SLA(Service Level Agreement)能力而无需关心后端由哪台阵列为其应用提供存储服务。

在数据面上，OceanStor DJ具备集成所有类型的数据服务的能力，以及支持应用程序访问块存储、文件存储的能力。同时由于它始终具有并继续使用底层存储阵列独特的功能，OceanStor DJ的存储服务也保留了存储阵列的增值特性，例如远程复制等，不会增加用户的购置成本。

总结:这种控制和数据分离的架构很好的利用了数据旁路技术，在现网部署时，不需要改变现网环境，防止在现网加入设备到存储和服务器之间，防止中断业务。在SDS产品中，更重要的是不会成为整个存储系统的性能瓶颈，防止存储数量很多时，网关方案成为性能瓶颈。

技术热文

求知若渴, 虚心若愚—Stay hungry,Stay foolish