优化的元数据索引服务

时间：2022-03-17 06:33:02 | 来源：行业动态

时间：2022-03-17 06:33:02 来源：行业动态

那么，为什么浪潮软件定义存储能很好地管理海量数据呢？下面我们以文件服务类型为例来进行阐述说明。

对于传统的本地文件系统，当查找一个文件时，先由元数据区找到索引，再定位到数据区，存在深度目录的时候，可能需要在两种区域做多次查询和数据定向，最后才能定位到所需要的文件。对于这种低效率的模式，很多成熟的文件系统大多使用类B树的方式来组织目录，以避免线性方式查找目录项来降低文件索引冗余度；此外还有多种技术（如HASH，元数据缓存，C-FFS等）在传统架构上都可以不同程度地给文件索引性能加速，但是在海量数据存储场景下，以上所有努力都会失灵。

究其原因其实也很明确：存储海量数据的时候，一定会有大量的元数据需要存储。在传统文件系统的软件架构（包括集中式NAS存储）中，元数据为集中式存储方式，处理元数据的服务（控制器）也为集中式。由于元数据被存储在了少量固定的磁盘上面，不能随整体容量的增加而任意扩展，使得这块区域对外提供的读写性能因被固化而变得十分有限。与此同时，数据文件在访问IO频繁的时候，元数据索引服务需要消耗大量CPU和内存的资源，而本地文件系统所能依靠的只是本地操作系统上的资源，即使是NAS存储一般也仅仅可以使用两个控制器上的资源。但我们知道，当数据量达到数PB级时对于IO性能的需求会高出很多，读写带宽基本上需要在几十GB以上。因此，传统的集中式元数据部署架构不管在软件算法上如何优化，面对海量数据也于事无补。

此时，再让我们来看看浪潮软件定义存储是如何应对这一难题的：首先，浪潮软件定义存储系统具有良好的Scale-out扩展性能：随着物理节点的扩展，性能、容量也随之呈线性扩展；其次，全局融合的分布式结构设计使得扩展过程中突破了传统NAS元数据瓶颈制约。

浪潮软件定义存储之所以能做到这一点，在于打破了传统文件系统（也包括集中式NAS存储）的元数据集中式存储和管理这一限制，对浪潮软件定义存储集群系统的目录实行分而治之，让集群中所有服务器来一起存储和管理元数据及数据，从而实现负荷分担、负载均衡。目前其实现方式主要有三种，各类浪潮软件定义存储会根据自身交付的场景不同，选择不同的方式：

第一种，静态子树分区。以目录为单位，把各个目录或子目录手工分配给不同节点去存储，并指定不同的元数据服务节点/程序去管理。当某个目录出现访问过热的情况下，再由管理员手工进行迁移。这种处理方式逻辑最为简单，也容易实现，但如果数据目录需要频繁扩容，就需要管理员人为频繁干预。老一点的网络共享文件系统一般采用的是这种方式。

第二种，HASH分区。通过计算来分配数据、元数据存储的位置。这种方式可以把数据和元数据自动均匀地分布在各个节点上，但是突发性热点区域的数据访问可能造成整个系统内部某些元数据服务节点资源吃紧，从而成为整个系统的性能瓶颈。这种方式在一些分布式文件系统里得到了应用，并在IO均匀分布的业务环境中很适用，如Lustre分布式文件系统。

第三种，动态子树分区。大体结构类似上面两种方式，但它可以通过实时监控和分析，把热度数据单位动态地调整到不同的元数据服务节点，从而实现数据索引的动态负载均衡。