分布式文件系统的用户配额管理方法、计算机及存储介质

技术领域

本发明涉及系统管理技术领域，尤其涉及一种分布式文件系统的用户配额管理方法、计算机及存储介质。

背景技术

在用户日常使用存储系统时，经常出现个别用户过度使用资源，影响了其他用户的资源使用，管理员需要按需求为用户、用户组、目录合理分配存储空间或文件数量。配额功能，能合理地为用户、用户组、目录分配存储资源，避免因某个用户、用户组、目录的过度使用造成其他用户无法正常工作、系统无法正常运行。场景的配额解决方案即为常规的Client-Server架构下的统计方案，但Client与Server之间很容易由于网络故障或者模块内部代码异常等条件，触发Client进程重启，但进程重启前Client本地是保存着配额增量信息的，重启之后这些信息即失效，如果server无法将client重启前未同步到server的配额信息获取到，则配额信息将会丢失，从而造成故障场景下配额丢失等进度问题，影响客户使用。

发明内容

为了在客户端故障导致配额增量丢失时能够快速准确的恢复服务端侧客户端请求的配额增量，在本发明的第一方面提出了一种分布式文件系统的用户配额管理方法，所述方法包括：在客户端请求配额增量时，先向元数据服务节点发送伴生日志创建请求，所述伴生日志创建请求中包括客户端ID、请求时间以及请求的配额增量；响应于客户端接收到元数据服务节点返回的确收所述伴生日志创建请求的信息，将配额增量写入缓存；根据预设的配额增量上报条件将所述缓存中的配额增量上报至服务器。

在一个或多个实施例中，本发明的方法还包括：响应于所述元数据服务节点接收到来自所述客户端的伴生日志创建请求，生成包含请求信息的伴生日志并持久化所述伴生日志到对象存储中；响应于所述伴生日志落盘成功，向所述客户端返回确收所述伴生日志创建请求的信息。

在一个或多个实施例中，生成所述伴生日志创建请求的方式，包括：将配额增量插入到当前准备发送的且受日志监控的消息中以生成所述伴生日志创建请求。

在一个或多个实施例中，所述将配额增量插入到当前准备发送的且受日志监控的消息中以生成所述伴生日志创建请求，包括：将配额增量插入到当前准备发送的create消息中以生成所述伴生日志创建请求；或者将配额增量插入到当前准备发送的capUpdate消息中以生成所述伴生日志创建请求。

在一个或多个实施例中，所述根据预设的配额增量上报条件将所述缓存中的配额增量上报至服务器，包括：根据预设周期，周期性的将所述缓存中的配额增量上报至服务器。

在一个或多个实施例中，本发明的方法还包括：配置所述服务器监控所述客户端的心跳信息，并根据所述心跳信息判断是否发生客户端故障；响应于所述服务器判断发生客户端故障，从所述对象存储中读取所述伴生日志；根据故障客户端的ID以及最后一次接收到所述故障客户端的心跳信息的时间对所述伴生日志进行筛选；从筛选得到的伴生日志中提取所述故障客户端的配额增量并恢复到所述服务器的内存中。

在一个或多个实施例中，本发明的方法还包括：配置所述服务器监控每个伴生日志对象的持久化进度；当所述伴生日志对象的持久化进度达到预设时间后，通知所述对象存储删除指定时钟之前的伴生日志对象。

在一个或多个实施例中，本发明的方法还包括：配置所述服务器生成客户端列表，并对所述客户端列表进行主备服务器同步。

在本发明的第二方面，提出了一种计算机设备，包括：至少一个处理器；以及存储器，所述存储器中存储有可执行的计算机程序，所述计算机程序被所述至少一个处理器执行时用于实现下述任一方法实施例中的一种分布式文件系统的用户配额管理方法的步骤，包括：

在客户端请求配额增量时，先向元数据服务节点发送伴生日志创建请求，所述伴生日志创建请求中包括客户端ID、请求时间以及请求的配额增量；响应于客户端接收到元数据服务节点返回的确收所述伴生日志创建请求的信息，将配额增量写入缓存；根据预设的配额增量上报条件将所述缓存中的配额增量上报至服务器。

在一个或多个实施例中，本发明的方法还包括：响应于所述元数据服务节点接收到来自所述客户端的伴生日志创建请求，生成包含请求信息的伴生日志并持久化所述伴生日志到对象存储中；响应于所述伴生日志落盘成功，向所述客户端返回确收所述伴生日志创建请求的信息。

在一个或多个实施例中，生成所述伴生日志创建请求的方式，包括：将配额增量插入到当前准备发送的且受日志监控的消息中以生成所述伴生日志创建请求。

在一个或多个实施例中，所述将配额增量插入到当前准备发送的且受日志监控的消息中以生成所述伴生日志创建请求，包括：将配额增量插入到当前准备发送的create消息中以生成所述伴生日志创建请求；或者将配额增量插入到当前准备发送的capUpdate消息中以生成所述伴生日志创建请求。

在一个或多个实施例中，所述根据预设的配额增量上报条件将所述缓存中的配额增量上报至服务器，包括：根据预设周期，周期性的将所述缓存中的配额增量上报至服务器。

在一个或多个实施例中，本发明的方法还包括：配置所述服务器监控所述客户端的心跳信息，并根据所述心跳信息判断是否发生客户端故障；响应于所述服务器判断发生客户端故障，从所述对象存储中读取所述伴生日志；根据故障客户端的ID以及最后一次接收到所述故障客户端的心跳信息的时间对所述伴生日志进行筛选；从筛选得到的伴生日志中提取所述故障客户端的配额增量并恢复到所述服务器的内存中。

在一个或多个实施例中，本发明的方法还包括：配置所述服务器监控每个伴生日志对象的持久化进度；当所述伴生日志对象的持久化进度达到预设时间后，通知所述对象存储删除指定时钟之前的伴生日志对象。

在一个或多个实施例中，本发明的方法还包括：配置所述服务器生成客户端列表，并对所述客户端列表进行主备服务器同步。

在本发明的第三方面，提出了一种可读存储介质，包括：可执行的计算机程序，所述计算机程序被执行器执行时用于实现下述任意一方法实施例中的一种分布式文件系统的用户配额管理方法的步骤，包括：

在客户端请求配额增量时，先向元数据服务节点发送伴生日志创建请求，所述伴生日志创建请求中包括客户端ID、请求时间以及请求的配额增量；响应于客户端接收到元数据服务节点返回的确收所述伴生日志创建请求的信息，将配额增量写入缓存；根据预设的配额增量上报条件将所述缓存中的配额增量上报至服务器。

在一个或多个实施例中，本发明的方法还包括：响应于所述元数据服务节点接收到来自所述客户端的伴生日志创建请求，生成包含请求信息的伴生日志并持久化所述伴生日志到对象存储中；响应于所述伴生日志落盘成功，向所述客户端返回确收所述伴生日志创建请求的信息。

在一个或多个实施例中，生成所述伴生日志创建请求的方式，包括：将配额增量插入到当前准备发送的且受日志监控的消息中以生成所述伴生日志创建请求。

在一个或多个实施例中，所述将配额增量插入到当前准备发送的且受日志监控的消息中以生成所述伴生日志创建请求，包括：将配额增量插入到当前准备发送的create消息中以生成所述伴生日志创建请求；或者将配额增量插入到当前准备发送的capUpdate消息中以生成所述伴生日志创建请求。

在一个或多个实施例中，所述根据预设的配额增量上报条件将所述缓存中的配额增量上报至服务器，包括：根据预设周期，周期性的将所述缓存中的配额增量上报至服务器。

在一个或多个实施例中，本发明的方法还包括：配置所述服务器监控所述客户端的心跳信息，并根据所述心跳信息判断是否发生客户端故障；响应于所述服务器判断发生客户端故障，从所述对象存储中读取所述伴生日志；根据故障客户端的ID以及最后一次接收到所述故障客户端的心跳信息的时间对所述伴生日志进行筛选；从筛选得到的伴生日志中提取所述故障客户端的配额增量并恢复到所述服务器的内存中。

在一个或多个实施例中，本发明的方法还包括：配置所述服务器监控每个伴生日志对象的持久化进度；当所述伴生日志对象的持久化进度达到预设时间后，通知所述对象存储删除指定时钟之前的伴生日志对象。

在一个或多个实施例中，本发明的方法还包括：配置所述服务器生成客户端列表，并对所述客户端列表进行主备服务器同步。

本发明的有益效果包括：为了避免因客户端发生故障后可能出现的配额增量丢失问题，本发明提出了一种分布式文件系统的用户配额管理方法，通过在客户端请求配额增量时，通过伴生日志记录客户端请求的配额增量，使得一旦客户端发生故障且未能及时同步配额增量至服务器时，能够通过读取伴生日志中的配额增量恢复服务器端内存中保存的客户端的最新配额增量，从而提升用户的使用感受。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的实施例。

图1为本发明实施例的一种分布式文件系统的用户配额管理方法的工作流程图；

图2为本发明实施例的伴生日志对象生成过程的节点交互示意图；

图3为本发明实施例的基于伴生日志对象恢复服务器内存数据的节点交互示意图；

图4为本发明实施例的基于持久化进度清除伴生日志对象节点交互示意图；

图5为本发明实施的一种计算机设备的结构示意图；

图6为本发明实施的一种可读存储介质的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本发明实施例进一步详细说明。

需要说明的是，本发明实施例中所有使用“第一”和“第二”的表述均是为了区分两个相同名称非相同的实体或者非相同的参量，可见“第一”“第二”仅为了表述的方便，不应理解为对本发明实施例的限定，后续实施例对此不再一一说明。

为了避免因客户端发生故障后可能出现的配额增量丢失问题，本发明提出了一种分布式文件系统的用户配额管理方法，通过在客户端请求配额增量时，通过伴生日志记录客户端请求的配额增量，使得一旦客户端发生故障且未能及时同步配额增量至服务器时，能够通过读取伴生日志中的配额增量恢复服务器端内存中保存的客户端的最新配额增量，从而提升用户的使用感受。以下将结合附图对本发明的实施方式进行更加详细的阐述。

请参见图1，其示出了本发明实施例的一种分布式文件系统的用户配额管理方法的工作流程，包括：步骤S1、在客户端请求配额增量时，先向元数据服务节点发送伴生日志创建请求，伴生日志创建请求中包括客户端ID、请求时间以及请求的配额增量；步骤S2、响应于客户端接收到元数据服务节点返回的确收伴生日志创建请求的信息，将配额增量写入缓存；步骤S3、根据预设的配额增量上报条件将缓存中的配额增量上报至服务器。

具体的，传统申请配额增量的方式是，客户端(配置有lib库，后续实施例及附图中将使用lib代表客户端)将配额增量请求写入本地的缓存中，本地缓存周期性的上报配额增量请求至服务器，并记录在服务器的内存中，并在服务器侧存在可分配的配额时，再分配给相应的客户端。这种方式的弊端在于，一旦客户端在请求配额增量后不足一个缓存同步周期内发生故障时，该客户端的配额增量将无法被服务器获知，从而造成客户端请求的配额增量丢失，并需要客户端重启后重新申请配额增量，进而导致用户使用感受不佳。请参见图2，本实施例为了避免上述问题的发生，要求lib在请求配额增量时需要先向Mds(元数据服务器)发送伴生日志创建请求以生成伴生日志并保存上述配额增量，并且只有当Mds返回响应后才允客户端将配额增量写入本地缓存，通过这种方式，能够使得在lib故障时，quotaServer(服务器)从Mds中读取伴生日志中的配额增量，并恢复到quotaServer(服务器)的内存中，从而有效的避免了客户端故障后丢失本地缓存的配额增量的问题，且在客户端重启后无需重新申请配额增量，从而大大提升了用户的使用感受。

更具体的，图2中的完整交互过程描述如下：

1)lib向authMds发送create请求；

2)lib在收到authMds响应后，把配额增量写入缓存享；

3)在Lib周期把缓存中的配额增量上报给quotaserver；

4)如果lib配额上报前异常故障，缓存中的配额增量会丢失，导致配额统计错误；

5)所以在lib给authMds发送的create消息中携带配额增量信息，authMds把配额增量信息写入配额日志对象，保证inode元数据与配额增量信息都落盘成功；

6)这样在lib异常故障后，quotaserver读配额日志对象，计算出丢失的配额增量并恢复到内存中。

在进一步的实施例中，本发明的方法还包括：响应于元数据服务节点接收到来自客户端的伴生日志创建请求，生成包含请求信息的伴生日志并持久化伴生日志到对象存储中；响应于伴生日志落盘成功，向客户端返回确收伴生日志创建请求的信息。此外，quotaserver服务器在接收到lib上报的配额增量请求后也会想lib返回确认响应。

在进一步的实施中，本发明生成伴生日志创建请求的方式，包括：将配额增量插入到当前准备发送的且受日志监控的消息中以生成伴生日志创建请求。具体的，分布式文件系统中会通过日志监控元数据交互，而只要分布式文件系统中有事件在执行就存在元数据交互，因此，本实施提出了可以在lib与Mds的元数据交互中插入请求的配额增量，从而与其它元数据一起发送至Mds进行保存。

在一个可选的实施例中，该配额增量在到达Mds节点后，Mds将提取该元数据消息中的客户端ID及时间信息，并与其携带的配额增量保存为一个单独的伴生日志对象，并持久化到OSD(Object-based Storage Device，对象存储设备)中。

在进一步的实施例中，将配额增量插入到当前准备发送的且受日志监控的消息中以生成伴生日志创建请求，包括：将配额增量插入到当前准备发送的create消息中以生成伴生日志创建请求；或者将配额增量插入到当前准备发送的capUpdate消息中以生成伴生日志创建请求。其中，create和capUpdate是最为常见的两种元数据消息。

在进一步的实施例中，根据预设的配额增量上报条件将缓存中的配额增量上报至服务器，包括：根据预设周期，周期性的将缓存中的配额增量上报至服务器；或者根据预设的上报数量，在缓存中的的请求数量达到上报数量时，将缓存中的配额增量上报至服务器。

具体的，第一种方式即为传统的配置增量请求上报方式，第二方式固定上报数量的方式相比于第一种方式能够控制客户端故障时丢失的配置增量数量，避免出现同时丢失过多的请求数据。

上述各实施例公开了本发明持久化配额增量的方式，在以下的实施例中将进一步介绍本发明如何基于持久化的配额增量进行服务端的数据恢复：

在进一步的实施例中，本发明基于持久化的配额增量进行服务端的数据恢复的过程包括：配置服务器监控客户端的心跳信息，并根据心跳信息判断是否发生客户端故障；响应于服务器判断发生客户端故障，从对象存储中读取伴生日志；根据故障客户端的ID以及最后一次接收到故障客户端的心跳信息的时间对伴生日志进行筛选；从筛选得到的伴生日志中提取故障客户端的配额增量并恢复到服务器的内存中。

具体的，请参见图3，本实施中lib、quotaserver与OSD三者之间的交互过程包括：

在一个可选的实施例中，Quotaserver对每条用户/用户组、目录配额，都按lib的clientId(客户端ID)统计最近3个时钟的配额增量，这样一个lib故障，只需要读该lib的伴生日志，对内存中的配额增量做修正；

例如A目录配置了目录配额，系统中有2个Lib，并设当前时钟为10，quotaserver的内存中记录如下：

quotaserver根据lib的心跳消息，判断lib故障，按逻辑时钟收集伴生日志；例如，收集逻辑时钟大于10的伴生日志；

quotaserver对读到的日志按故障Lib的clientId过滤，重新统计该Lib对各配额产生的配额增量；

统计完成后，使用统计值替换内存中记录的该lib对应时钟的配额增量；例如，在下一时钟，lib1的配额增量变为50MB，lib2的配额增量不变，怎逻辑时钟为11时，quotaserver的内存中记录如下：

为了保证OSD存储空间的高效使用，本发明会根据每个OSD对象的持久化对象的持久化进度选择性的清除部分OSD对象，从而释放空间。

在进一步的实施例中，本发明的方法还包括：配置服务器监控每个伴生日志对象的持久化进度；当伴生日志对象的持久化进度达到预设时间后，通知对象存储删除指定时钟之前的伴生日志对象。

具体的，请参见图4，本发明根据持久化进度清除OSD对象的过程，包括：

1)Quotaserver每分钟给mds发送的删除伴生日志消息中携带逻辑时钟。

2)Mds删除该时钟及之前时钟的伴生日志对象。由mds直接删除，而不是通过quotaserver删除，避免出现quotaserver的删除速度低于日志产生速度。其中，mds1和mds2分别表示为不同逻辑时钟下保存的对应不同客户端的伴生日志对象。

在进一步的实施例中，在服务器端因故障发生主、备切换时，本发明配额增量恢复过程为：

1)主quotaserver故障、因升级导致重启时，mon选择一个备quotaserver升主；

a)主Quotaserver升级时，主动通知mon，触发主备切换；

b)Mon选择主quotaserver时，优选与主mon不同的节点，因为lib/内核客户端个数很多时，quotaserver的消息量较大，优选与主mon不同的节点有利于任务的均匀分配；

2)Lib周期(5秒)给主Quotaserver发送心跳，主备quotaserver都维护正常的lib列表；

a)Lib因升级重启前，需要把缓存中的配额上报给quotaserver，然后发送Lib下线消息给主quotaserver；

b)正常lib列表变化时，主quotaserver向备发送消息，携带新的lib列表；

3)升主的quotaserver向正常lib发送消息，收集配额增量和预申请配额；

a)Lib在内存中按时钟统计配额增量和预申请配额；对于配额增量，上报quotaserver收到响应后，才累加到按时钟统计的配额增量；

b)在Lib向quotaserver上报的心跳响应中携带quotaserver完成配额持久化的逻辑时钟；

c)Lib对于完成持久化的时钟，可以删除内存中的统计；

d)Quotaserver切主时，收集持久化时钟之后的各时钟配额增量和预申请配额；

4)Lib在响应中携带按时钟统计的配额增量和预申请配额；

在响应中还携带lib配额上报消息的最大序号，用于lib与新主quotaserver配额上报时消息去重；

5)quotaserver在收齐lib心跳响应前，对于Lib的配额上报和预申请消息，返回“重试”错误码；在收齐lib心跳响应前，不能处理配额上报和预申请消息，避免配额统计不准确；

6)quotaserver从osd查询配额对象，获取配额持久化信息，用于处理管理软件下发的配额查询请求；

7)Lib超时没有响应；

a)Quotaserver重试，重试超过3次(15秒)，按该lib故障处理；

b)Quotaserver对于故障的lib，不再处理该lib的心跳、配额上报、预申请，该lib必须重新向quotaserver重新上报启动消息；

8)Lib同时故障；

a)Quotaserver收集日志，恢复该Lib的配额增量

b)quotaserver与lib同时故障，导致的业务阻塞30秒以内：1)15秒发现lib超时没有响应2)收集3个时钟日志，按一个时钟5秒，共15秒。

通过上述方式，本发明可解决故障场景下配额容量信息不准的问题，通过在文件写的过程中生成伴生日志，当client故障时，server可以通过收集之前保存的伴生日志，将client由于故障丢失的配额信息，通过伴生日志收集上来，从而确保配额信息的及时更新。

在本发明的第二方面，提出了一种计算机设备，请参见图5，包括：

至少一个处理器31；以及存储器30，存储器30中存储有可执行的计算机程序301，计算机程序被301至少一个处理器31执行时用于实现如上述任意一方法实施例中的一种分布式文件系统的用户配额管理方法的步骤。

具体的，存储器30可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器30还可包括高速随机存取存储器，以及非易失性存储器，例如一个或多个磁盘存储设备、闪存存储设备。本实施例中，存储器30至少用于存储以下计算机程序301，其中，该计算机程序被处理器31加载并执行之后，能够实现前述实施例提出的一种分布式文件系统的用户配额管理方法的相关步骤。另外，存储器30所存储的资源还可以包括操作系统302和数据303等，存储方式可以是短暂存储或者永久存储。其中，操作系统302可以包括Windows、Unix、Linux等。数据303可以包括但不限于执行结果对应的数据等。

处理器31可以包括一个或多个处理核心，例如4核心处理器、8核心处理器等。处理器31可以采用DSP(Digital Signal Processing，数字信号处理)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器31也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(Central ProcessingUnit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器31可以在集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器31还可以包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。

在一些实施例中，本发明的计算机设备还可包括有显示屏32、输入输出接口33、通信接口34、电源35以及通信总线36。本领域技术人员可以理解，图5中示出的结构并不构成对本发明的计算机设备的限定，其可以包括比图示更多或更少的组件。

在本发明的第三方案，提出了一种可读存储介质40，包括：可执行的计算机程序，计算机程序被执行器执行时用于实现如上述任意一方法实施例中的一种分布式文件系统的用户配额管理方法的步骤。

具体的，若上述实施例中的一种分布式文件系统的用户配额管理方法以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，执行本发明各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、磁碟或者光盘等各种可以存储程序代码的介质。

以上是本发明公开的示例性实施例，但是应当注意，在不背离权利要求限定的本发明实施例公开的范围的前提下，可以进行多种改变和修改。根据这里描述的公开实施例的方法权利要求的功能、步骤和/或动作不需以任何特定顺序执行。此外，尽管本发明实施例公开的元素可以以个体形式描述或要求，但除非明确限制为单数，也可以理解为多个。

应当理解的是，在本文中使用的，除非上下文清楚地支持例外情况，单数形式“一个”旨在也包括复数形式。还应当理解的是，在本文中使用的“和/或”是指包括一个或者一个以上相关联地列出的项目的任意和所有可能组合。

上述本发明实施例公开实施例序号仅仅为了描述，不代表实施例的优劣。

所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本发明实施例公开的范围(包括权利要求)被限于这些例子；在本发明实施例的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，并存在如上的本发明实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。因此，凡在本发明实施例的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本发明实施例的保护范围之内。