CN114297172B - 一种基于云原生的分布式文件系统 - Google Patents

Abstract

本发明公开一种基于云原生的分布式文件系统，通过元数据服务模块将客户端发送的落盘请求信息处理为落盘请求和元数据拓扑数据，生成落盘请求的镜像文件并将落盘请求发送至分布式存储单元，生成元数据拓扑数据的镜像文件并将元数据拓扑数据发送至管理服务模块；数据服务模块将客户端发送的读写请求信息处理为读写请求和读写拓扑数据，生成读写请求的镜像文件并将读写请求发送至分布式存储单元，生成读写拓扑数据的镜像数据并将读写拓扑数据发送至管理服务模块。分布式存储单元包括落盘请求存储单元和读写请求存储单元，分别用于接收落盘请求和读写请求。以上方案，简化了元数据服务和数据服务的逻辑，解决了分布式文件系统中组件间依赖性强的问题。

Description

一种基于云原生的分布式文件系统

技术领域

本发明涉及分布式系统技术领域，特别涉及一种基于云原生的分布式文件系统。

背景技术

随着数字信息技术产品在社会上的推广，用于对存储系统的需求也在逐年提升，部署灵活、弹性管理的文件存储系统正成为各大文件存储厂商重点研究方向。

目前，一些分布式文件系统，大大提升了单个文件系统的容量和性能上限，比如CephFS、GlusterFS、GFS等。然而，这些分布式文件系统存在如下问题：在不同主机硬件或操作系统版本上部署分布式文件系统时，组件依赖不兼容将导致安装失败。分布式文件系统作为基础软件服务，在开发、编译、链接等过程会引入较多的关联依赖，比如内核版本、C/C++运行环境、CPU指令等。所以，业界在实际部署分布式文件系统之前，有两种做法：针对目标机型、目标OS开展兼容性测试；或，选择固定机型、固定操作系统作为产品依赖，其他类别不做支持。上述两种做法都有较大弊端，前者需要投入大量的人力来做测试，会大大增加产品的人力成本；后者对产品的推广限制比较明显，比如选择Debian操作系统作为唯一支持的OS类型，就意味着对CentOS操作系统不友好，可能损失大量的潜在客户。

发明内容

本发明要解决的技术问题是现有分布式存储系统存在的上述问题，提供一种基于云原生的分布式文件系统。

针对上述技术问题，本发明提供如下技术方案：

本发明一部分实施例提供一种基于云原生的分布式文件系统，包括微服务容器管理单元和分布式存储单元；其中：

所述微服务容器管理单元与客户端连接，所述微服务容器管理单元包括元数据服务模块，数据服务模块和管理服务模块；所述元数据服务模块接收客户端发送的落盘请求信息并将所述落盘请求信息处理为落盘请求和元数据拓扑数据，生成所述落盘请求的镜像文件并将所述落盘请求发送至所述分布式存储单元，生成所述元数据拓扑数据的镜像文件并将所述元数据拓扑数据发送至所述管理服务模块；所述数据服务模块接收客户端发送的读写请求信息并将所述读写请求信息处理为读写请求和读写拓扑数据，生成所述读写请求的镜像文件并将所述读写请求发送至所述分布式存储单元，生成所述读写拓扑数据的镜像数据并将所述读写拓扑数据发送至所述管理服务模块；

所述分布式存储单元包括落盘请求存储单元和读写请求存储单元，所述落盘请求存储单元接收所述元数据服务模块发送的所述落盘请求；所述读写请求存储单元接收所述数据服务模块发送的所述读写请求。

本发明一些实施例中所述的基于云原生的分布式文件系统，所述微服务容器管理单元采用K8S平台实现，所述元数据服务模块和所述数据服务模块通过采用Deployment方式生成镜像文件。

本发明一些实施例中所述的基于云原生的分布式文件系统，所述K8S平台配置有单一的操作系统，与所述K8S平台相连的客户端以及所述分布式存储单元配置有单一或多种操作系统。

本发明一些实施例中所述的基于云原生的分布式文件系统，所述K8S平台中的元数据服务模块或管理服务模块定期地向具有连接关系的客户端发送心跳信号；若在设定时间内未收到客户端对于所述心跳信号的反馈信息，则判定该元数据服务模块或管理服务模块为待定状态；

将处于待定状态的元数据服务模块上的客户端的落盘请求信息迁移至其他元数据服务模块；将待定状态的管理服务模块上的读写请求信息迁移至其他元管理服务模块。

本发明一些实施例中所述的基于云原生的分布式文件系统，所述K8S平台中的待定状态的元数据服务模块或管理服务模块继续定期地向具有连接关系的客户端发送心跳信号；若在设定时间内收到客户端对于所述心跳信号的反馈信息，则判定该待定状态的元数据服务模块或管理服务模块恢复为正常状态。

本发明一些实施例中所述的基于云原生的分布式文件系统，当任意元数据服务模块或管理服务模块从待定状态恢复为正常桩体后，其将自身的IP信息同步更新至其他元数据服务模块及管理服务模块。

本发明一些实施例中所述的基于云原生的分布式文件系统，所述管理服务模块，对所述待定状态的客户端的落盘请求信息及读写请求信息的迁移过程进行记录并同步至客户端。

本发明一些实施例中所述的基于云原生的分布式文件系统，所述微服务容器管理单元还包括：

后台管理服务控制模块，用于管理对所述分布式文件系统的安装、卸载及调度操作。

本发明一些实施例中所述的基于云原生的分布式文件系统，所述后台管理服务控制模块，根据所述微服务容器管理单元连接的客户端的数量及带宽需求对所述元数据服务模块和所述数据服务模块的数量进行扩展或删减。

本发明一些实施例中所述的基于云原生的分布式文件系统，所述后台管理服务控制模块，还用于根据所述微服务容器管理单元连接的客户端的数量及带宽需求对所述分布式存储单元的数量进行扩展或删减。

本发明的技术方案相对现有技术具有如下技术效果：

本发明提供的基于云原生的分布式文件系统，通过元数据服务模块将客户端发送的落盘请求信息处理为落盘请求和元数据拓扑数据，生成落盘请求的镜像文件并将落盘请求发送至分布式存储单元，生成元数据拓扑数据的镜像文件并将元数据拓扑数据发送至管理服务模块；数据服务模块将客户端发送的读写请求信息处理为读写请求和读写拓扑数据，生成读写请求的镜像文件并将读写请求发送至分布式存储单元，生成读写拓扑数据的镜像数据并将读写拓扑数据发送至管理服务模块。分布式存储单元包括落盘请求存储单元和读写请求存储单元，分别用于接收落盘请求和读写请求。以上方案，通过将分布式文件系统的数据分布计算和数据存储逻辑分离，简化元数据服务和数据服务的逻辑，实现文件服务的微服务，解决了分布式文件系统中组件间依赖性强的问题。

附图说明

下面将通过附图详细描述本发明中优选实施例，将有助于理解本发明的目的和优点，其中:

图1为现有软件系统架构发展历程；

图2为本发明一个实施例所述基于云原生的分布式文件系统的架构示意图；

图3为本发明一个实施例所述微服务化设计原理的示意图；

图4为本发明一个实施例所述K8S平台配置有单一的操作系统的原理示意图；

图5为本发明一个实施例所述基于云原生的分布式文件系统中单个节点出现故障时对于节点数据重新调度的示意图；

图6为与图5对应的所述基于云原生的分布式文件系统中单个节点出现故障时对于节点数据重新调度的示意图；

图7为本发明一个实施例所述扩展文件系统的原理示意图。

具体实施方式

下面将结合附图对本发明的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本发明的描述中，需要说明的是，术语“中心”、“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。

在本发明的描述中，需要说明的是，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。

此外，下面所描述的本发明不同实施方式中所涉及的技术特征只要彼此之间未构成冲突就可以相互结合。

随着计算机技术的发展，如图1所示，软件系统经历了多次的架构变革，MVC架构、RPC架构、SOC架构到现如今的微服务架构。微服务架构是SOA(面向服务的体系结构)架构的一种变体，微服务架构提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API)。每个服务都围绕着具体业务进行构建，并且能够独立部署，对具体的一个服务而言，根据上下文，选择合适的语言、工具对其进行构建。本发明以下实施例将基础软件的服务程序实现为微服务的模式，增加灵活性，同时在底层引入分布式存储系统，将分布式文件系统的存储逻辑交由分布式存储系统。

本发明以下实施例中出现的各个模块的功能如下表所示：

本发明以下实施例中涉及的技术术语的说明如下表所示：

具体地，如图2所示，本实施例提供的基于云原生的分布式文件系统，包括微服务容器管理单元100和分布式存储单元200；其中，所述微服务容器管理单元100与客户端连接，所述微服务容器管理单元100包括元数据服务模块101(Meta1，Meta2……)，数据服务模块102(Stor1，Stor2……)和管理服务模块103(Mgmtd)；所述元数据服务模块101接收客户端发送的落盘请求信息并将所述落盘请求信息处理为落盘请求和元数据拓扑数据，生成所述落盘请求的镜像文件并将所述落盘请求发送至所述分布式存储单元200，生成所述元数据拓扑数据的镜像文件并将所述元数据拓扑数据发送至所述管理服务模块103；所述数据服务模块102接收客户端发送的读写请求信息并将所述读写请求信息处理为读写请求和读写拓扑数据，生成所述读写请求的镜像文件并将所述读写请求发送至所述分布式存储单元200，生成所述读写拓扑数据的镜像数据并将所述读写拓扑数据发送至所述管理服务模块102。所述分布式存储单元200包括落盘请求存储单元201和读写请求存储单元，所述落盘请求存储单元201接收所述元数据服务模块101发送的所述落盘请求；所述读写请求存储单元202接收所述数据服务模块102发送的所述读写请求。如图所示，元数据服务模块101、数据服务模块102、落盘请求存储单元201和读写请求存储单元202均可以包括多个。

以上方案中，通过元数据服务模块101将客户端发送的落盘请求信息处理为落盘请求和元数据拓扑数据，生成落盘请求的镜像文件并将落盘请求发送至分布式存储单元200，生成元数据拓扑数据的镜像文件并将元数据拓扑数据发送至管理服务模块103；数据服务模块102将客户端发送的读写请求信息处理为读写请求和读写拓扑数据，生成读写请求的镜像文件并将读写请求发送至分布式存储单元200，生成读写拓扑数据的镜像数据并将读写拓扑数据发送至管理服务模块103。分布式存储单元200包括落盘请求存储单元201和读写请求存储单元202，分别用于接收落盘请求和读写请求。以上方案，通过将分布式文件系统的数据分布计算和数据存储逻辑分离，简化元数据服务和数据服务的逻辑，实现文件服务的微服务，解决了分布式文件系统中组件间依赖性强的问题。

另外，结合图3-图5所示，以上方案中，所述微服务容器管理单元100采用K8S平台实现，所述元数据服务模块101和所述数据服务模块102通过采用Deployment方式生成镜像文件。通常情况下，分布式文件系统的IO路径覆盖了网络IO和磁盘IO的完整过程，因此，那么元数据服务模块101以及数据服务模块102就需要与客户端节点和分布式存储单元的磁盘节点进行绑定，形成有状态的服务模块。考虑到更好地支持微服务化的设计，将落盘的存储逻辑拆离出来设计为独立的分布式存储系统，而将元数据服务模块101以及数据服务模块102设计为无状态的服务模块。

如图3所示，以一个元数据服务模块Meta为例，本实施例以上方案中的元数据服务模块Meta，仅接收元数据的请求，并将落盘请求转换为网络请求发送至底层的分布式存储单元的磁盘中。而底层分布式存储单元具有更高的可靠性和可用性，这样，整体分布式系统的灵活性变得更强。同时借助K8S的编排能力，可将元数据服务模块Meta的服务运行依赖的必备配置项以YAML的方式导入Pod。针对数据服务模块Stor也可以采用与元数据服务模块Meta相似的设计。

另外，所述K8S平台配置有单一的操作系统，与所述K8S平台相连的客户端以及所述分布式存储单元配置有单一或多种操作系统。如图4所示，K8S容器的运行是以镜像文件为基础的，其中镜像文件内部是一个精简操作系统，含有必须的文件和依赖包。镜像文件是分层构建的，每一层构建仅叠加一层只读的文件层，所以镜像在生成运行的容器后，所有的改动仅会影响容器层的文件，而不会影响到镜像的本身内容。为了保证文件服务的运行环境相对固定，在K8S容器内选择使用Debian操作系统作为唯一的运行环境，而容器所在宿主机的操作系统可以有更多的选择。而依赖的基础库环境根据文件服务的实际情况进行定制，确保容器运行时不依赖宿主机上的资源或限制。

优选地，如图5和图6所示，所述K8S平台中的元数据服务模块或管理服务模块定期地向具有连接关系的客户端AP发送心跳信号；若在设定时间内未收到客户端AP对于所述心跳信号的反馈信息，则判定该元数据服务模块或管理服务模块为待定状态；将处于待定状态的元数据服务模块上的客户端的落盘请求信息迁移至其他元数据服务模块；将待定状态的管理服务模块上的读写请求信息迁移至其他元管理服务模块。即，基于以上所述的微服务化设计，使用Deployment方式在K8S平台部署Meta/Stor/Mgmtd服务，以此实现文件服务的高可用特性。通过发送心跳信号，K8S平台定期探活集群内所有节点，当出现节点故障或网络故障时，如果节点失联超过规定的最长时间后，平台会将此节点置为NotReady状态，并触发节点上服务Pod的驱逐操作，并进行服务Pod的重新调度。

进一步地，所述K8S平台中的待定状态的元数据服务模块或管理服务模块继续定期地向具有连接关系的客户端发送心跳信号；若在设定时间内收到客户端对于所述心跳信号的反馈信息，则判定该待定状态的元数据服务模块或管理服务模块恢复为正常状态。进一步地，当任意元数据服务模块或管理服务模块从待定状态恢复为正常桩体后，其将自身的IP信息同步更新至其他元数据服务模块及管理服务模块。根据上面提到的K8S迁移Pod方案，以Meta1服务所在节点故障为例进行介绍：当Meta1所在节点Node1发生异常时，客户端AP此时由于连通不上Meta1服务，则短暂阻塞业务IO，待K8S平台触发将Meta1的服务Pod迁移至Node3节点；迁移成功后，Meta1服务上线后，向集群内同步自身新节点IP信息，更新客户端记录的集群拓扑；当客户端后续重试IO过程中即可恢复业务，从而实现文件系统服务高可用的特性。如前所述，所述管理服务模块103对所述待定状态的客户端的落盘请求信息及读写请求信息的迁移过程进行记录并同步至客户端AP。

进一步优选地，以上方案中的基于云原生的分布式文件系统，所述微服务容器管理单元还包括后台管理服务控制模块104，用于管理对所述分布式文件系统的安装、卸载及调度操作。具体地，所述后台管理服务控制模块104根据所述微服务容器管理单元连接的客户端的数量及带宽需求对所述元数据服务模块101和所述数据服务模块102的数量进行扩展或删减。更优选地，所述后台管理服务控制模块104还用于根据所述微服务容器管理单元连接的客户端的数量及带宽需求对所述分布式存储单元的数量进行扩展或删减。也即，本方案能方便地实现分布式文件系统的扩容。

基于上文的微服务化设计原理，分布式文件系统的服务改进为无状态的服务，同时存储逻辑已交由底层的分布式存储单元实现，因此，如图7所示，对系统的扩容可以分成两部分：

(1)扩展文件系统的计算资源，即增加文件系统的元数据、数据服务数目。通过扩展元数据节点，可以更好地提升文件的元数据服务能力，比如创建、删除、、查询等操作，同时可以更好地均衡元数据的分布。通过扩展数据节点，可以更好地均衡客户端的读写请求，从而提升文件的读写能力，比如带宽和IOPS。

(2)扩展文件系统的存储资源，即通过横向和纵向地扩容分布式存储的存储容量。

本发明以上实施例中的方案，通过将分布式文件系统的数据分布计算和数据存储逻辑分离，简化元数据服务和数据服务的逻辑，实现文件服务的微服务化。通过K8S的deployment机制，简化分布式文件系统的高可用机制，提高节点故障的容忍能力，分布式文件系统的服务节点故障后，在不需要人力参与的情况下，达到系统自愈的效果。基于计算与存储分离的架构，实现分布式文件系统的元数据、数据服务在计算侧能力的无感横向扩容。参照Docker镜像标准，生成云原始化分布式文件系统的关键镜像，包括元数据服务、数据服务、管理服务、控制台服务，将文件服务的运行时环境打包为镜像，部署过程中即装即用，而无需做兼容性验证。

显然，上述实施例仅仅是为清楚地说明所作的举例，而并非对实施方式的限定。对于所属领域的普通技术人员来说，在上述说明的基础上还可以做出其它不同形式的变化或变动。这里无需也无法对所有的实施方式予以穷举。而由此所引伸出的显而易见的变化或变动仍处于本发明的保护范围之中。

Claims (10)

1.一种基于云原生的分布式文件系统，其特征在于，包括微服务容器管理单元和分布式存储单元；其中：

所述微服务容器管理单元与客户端连接，所述微服务容器管理单元包括元数据服务模块，数据服务模块和管理服务模块；所述元数据服务模块接收客户端发送的落盘请求信息并将所述落盘请求信息处理为落盘请求和元数据拓扑数据，生成所述落盘请求的镜像文件并将所述落盘请求发送至所述分布式存储单元，生成所述元数据拓扑数据的镜像文件并将所述元数据拓扑数据发送至所述管理服务模块；所述数据服务模块接收客户端发送的读写请求信息并将所述读写请求信息处理为读写请求和读写拓扑数据，生成所述读写请求的镜像文件并将所述读写请求发送至所述分布式存储单元，生成所述读写拓扑数据的镜像数据并将所述读写拓扑数据发送至所述管理服务模块；

所述分布式存储单元包括落盘请求存储单元和读写请求存储单元，所述落盘请求存储单元接收所述元数据服务模块发送的所述落盘请求；所述读写请求存储单元接收所述数据服务模块发送的所述读写请求。

2.根据权利要求1所述的基于云原生的分布式文件系统，其特征在于：

所述微服务容器管理单元采用K8S平台实现，所述元数据服务模块和所述数据服务模块通过采用Deployment方式生成镜像文件。

3.根据权利要求2所述的基于云原生的分布式文件系统，其特征在于：

所述K8S平台配置有单一的操作系统，与所述K8S平台相连的客户端以及所述分布式存储单元配置有单一或多种操作系统。

4.根据权利要求3所述的基于云原生的分布式文件系统，其特征在于：

所述K8S平台中的元数据服务模块或管理服务模块定期地向具有连接关系的客户端发送心跳信号；若在设定时间内未收到客户端对于所述心跳信号的反馈信息，则判定该元数据服务模块或管理服务模块为待定状态；

将处于待定状态的元数据服务模块上的客户端的落盘请求信息迁移至其他元数据服务模块；将待定状态的管理服务模块上的读写请求信息迁移至其他元管理服务模块。

5.根据权利要求4所述的基于云原生的分布式文件系统，其特征在于：

所述K8S平台中的待定状态的元数据服务模块或管理服务模块继续定期地向具有连接关系的客户端发送心跳信号；若在设定时间内收到客户端对于所述心跳信号的反馈信息，则判定该待定状态的元数据服务模块或管理服务模块恢复为正常状态。

6.根据权利要求5所述的基于云原生的分布式文件系统，其特征在于：

当任意元数据服务模块或管理服务模块从待定状态恢复为正常桩体后，其将自身的IP信息同步更新至其他元数据服务模块及管理服务模块。

7.根据权利要求6所述的基于云原生的分布式文件系统，其特征在于：

所述管理服务模块，对所述待定状态的客户端的落盘请求信息及读写请求信息的迁移过程进行记录并同步至客户端。

8.根据权利要求1-7任一项所述的基于云原生的分布式文件系统，其特征在于，所述微服务容器管理单元还包括：

后台管理服务控制模块，用于管理对所述分布式文件系统的安装、卸载及调度操作。

9.根据权利要求8所述的基于云原生的分布式文件系统，其特征在于：

所述后台管理服务控制模块，根据所述微服务容器管理单元连接的客户端的数量及带宽需求对所述元数据服务模块和所述数据服务模块的数量进行扩展或删减。

10.根据权利要求9所述的基于云原生的分布式文件系统，其特征在于：

所述后台管理服务控制模块，还用于根据所述微服务容器管理单元连接的客户端的数量及带宽需求对所述分布式存储单元的数量进行扩展或删减。

Images