CN111125048A - 一种故障通知方法、装置、设备及计算机可读存储介质 - Google Patents

一种故障通知方法、装置、设备及计算机可读存储介质 Download PDF

Info

Publication number
CN111125048A
CN111125048A CN201911243288.4A CN201911243288A CN111125048A CN 111125048 A CN111125048 A CN 111125048A CN 201911243288 A CN201911243288 A CN 201911243288A CN 111125048 A CN111125048 A CN 111125048A
Authority
CN
China
Prior art keywords
target
fault notification
client
notification information
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201911243288.4A
Other languages
English (en)
Other versions
CN111125048B (zh
Inventor
臧林劼
何营
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Inspur Electronic Information Industry Co Ltd
Original Assignee
Inspur Electronic Information Industry Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Inspur Electronic Information Industry Co Ltd filed Critical Inspur Electronic Information Industry Co Ltd
Priority to CN201911243288.4A priority Critical patent/CN111125048B/zh
Publication of CN111125048A publication Critical patent/CN111125048A/zh
Application granted granted Critical
Publication of CN111125048B publication Critical patent/CN111125048B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions
    • G06F16/178—Techniques for file synchronisation in file systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis

Abstract

本发明公开了一种基于用户态网络文件系统的故障通知方法，所述故障通知方法基于目标端，包括：监听对端在重启后发送的故障通知信息，并在本端重启后向对端发送本端的故障通知信息；目标端为客户端或者服务端；若目标端为服务端，则监听到对端的目标客户端发送的故障通知信息后，释放目标客户端已持有的文件锁；若目标端为客户端，则监听到对端的目标服务端发送的故障通知信息后，在宽限期内重新向目标服务端申请已授权的文件锁。可以看出，通过这种故障通知方法，可提高文件锁的可靠性，保证网络文件系统中数据的一致性。本发明还公开了一种基于用户态网络文件系统的故障通知装置、设备及计算机可读存储介质，同样能实现上述技术效果。

Description

一种故障通知方法、装置、设备及计算机可读存储介质
技术领域
本发明涉及，更具体地说，涉及一种基于用户态网络文件系统的故障通知方法、装置、设备及计算机可读存储介质。
背景技术
目前，随着企业数据越来越庞大，用户对数据的传输性能和稳定性要求越来越高，存储服务器将拥有数目庞大的客户端，多个客户端同时对服务器文件进行访问操作，势必会造成文件冲突，各个客户端相互协同、保证文件数据一致性已经成为软件使用者和开发者关注的重点。因此，提供一个高效、可靠、易于实施和维护、具有高度一致性的网络文件系统文件锁显得尤为重要。在网络文件系统文件锁应用中，在故障场景，例如，客户端重启、异常宕机，服务端重启、异常宕机，网络中断异常等故障情况，服务端与客户端往往不知道对方出现故障，这时会出现文件锁释放及申请不及时的问题，从而降低文件锁的可靠性。
发明内容
本发明的目的在于提供一种基于用户态网络文件系统的故障通知方法、装置、设备及计算机可读存储介质，以提高文件锁的可靠性。
为实现上述目的，本发明提供一种基于用户态网络文件系统的故障通知方法，所述故障通知方法基于目标端，包括：
监听对端在重启后发送的故障通知信息，并在本端重启后向对端发送本端的故障通知信息；所述目标端为客户端或者服务端；
若所述目标端为服务端，则监听到对端的目标客户端发送的故障通知信息后，释放所述目标客户端已持有的文件锁；
若所述目标端为客户端，则监听到对端的目标服务端发送的故障通知信息后，在宽限期内重新向所述目标服务端申请已授权的文件锁。
其中，所述监听对端在重启后发送的故障通知信息，并在本端重启后向对端发送本端的故障通知信息，包括：
每个目标端通过NSM服务的rpc.statd进程，监听对端在重启后发送的故障通知信息；每个目标端在重启后通过NSM服务的sm-notify进程，向对端发送本端的故障通知信息。
其中，所述若所述目标端为服务端，则监听到对端的目标客户端发送的故障通知信息后，释放所述目标客户端已持有的文件锁，包括：
若所述目标端为服务端，则接收对端的目标客户端通过sm-notify进程发送的故障通知信息；
根据所述故障通知信息携带的主机名，释放与所述主机名对应的所述目标客户端已持有的文件锁。
其中，所述若所述目标端为客户端，则监听到对端的目标服务端发送的故障通知信息后，在宽限期内重新向所述目标服务端申请已授权的文件锁，包括：
所述若所述目标端为客户端，则接收对端的目标服务端通过sm-notify进程发送的故障通知信息；
在预先设定的宽限期内重新向所述目标服务端申请已授权的文件锁；所述宽限期为所述目标服务端重启后的预定时长。
其中，所述目标服务端在所述宽限期内堵塞除所述目标端发送的文件锁申请之外的其他访问请求。
为实现上述目的，本发明进一步提供一种基于用户态网络文件系统的故障通知装置，所述故障通知装置基于目标端，包括：
监听模块，用于监听对端在重启后发送的故障通知信息；所述目标端为客户端或者服务端；
信息发送模块，用于在本端重启后向对端发送本端的故障通知信息；
第一文件锁处理模块，用于在所述目标端为服务端，监听到对端的目标客户端发送的故障通知信息后，释放所述目标客户端已持有的文件锁；
第二文件锁处理模块，用于在所述目标端为客户端，监听到对端的目标服务端发送的故障通知信息后，在宽限期内重新向所述目标服务端申请已授权的文件锁。
其中，所述监听模块具体用于：通过NSM服务的rpc.statd进程，监听对端在重启后发送的故障通知信息；
所述信息发送模块具体用于：在目标端重启后通过NSM服务的sm-notify进程，向对端发送本端的故障通知信息。
其中，所述第一文件锁处理模块包括：
第一接收单元，用于在所述目标端为服务端时，接收对端的目标客户端通过sm-notify进程发送的故障通知信息；
文件锁释放单元，用于根据所述故障通知信息携带的主机名，释放与所述主机名对应的所述目标客户端已持有的文件锁。
为实现上述目的，本发明进一步提供一种基于用户态网络文件系统的故障通知设备，包括：
存储器，用于存储计算机程序；
处理器，用于执行所述计算机程序时实现上述的故障通知方法的步骤。
为实现上述目的，本发明进一步提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述的故障通知方法的步骤。
通过以上方案可知，本发明实施例提供的一种基于用户态网络文件系统的故障通知方法，所述故障通知方法基于目标端，包括：监听对端在重启后发送的故障通知信息，并在本端重启后向对端发送本端的故障通知信息；目标端为客户端或者服务端；若目标端为服务端，则监听到对端的目标客户端发送的故障通知信息后，释放目标客户端已持有的文件锁；若目标端为客户端，则监听到对端的目标服务端发送的故障通知信息后，在宽限期内重新向目标服务端申请已授权的文件锁。
可以看出，本方案中的服务端在客户端重启后，可及时释放客户端所占用的文件锁，客户端在服务端重启后，可及时重新申请已授权的文件锁，实现文件锁的及时恢复；通过这种故障通知方法，可提高文件锁的可靠性，保证网络文件系统中数据的一致性。
本发明还公开了一种基于用户态网络文件系统的故障通知装置、设备及计算机可读存储介质，同样能实现上述技术效果。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本发明实施例公开的一种基于用户态网络文件系统的故障通知方法流程示意图；
图2为本发明实施例公开的一种基于用户态网络文件系统的文件锁故障通知系统流程示意图；
图3为本发明实施例公开的一种基于用户态网络文件系统的故障通知装置结构示意图；
图4为本发明实施例公开的一种基于用户态网络文件系统的故障通知设备结构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
文件锁是一种机制，在多任务操作系统环境中，如果一个进程尝试对正在被其他进程读取的文件进行写操作，可能会导致正在进行读操作的进程读取到一些被破坏或者不完整的数据；如果两个进程并发对同一个文件进行写操作，可能会导致该文件遭到破坏。因此，为了避免发生这种问题，必须要采用某种机制来解决多个进程并发访问同一个文件时所面临的同步问题，由此而产生了文件加锁方面的技术。
NFS(Network File System)即内核态网络文件系统，是FreeBSD(一种类UNIX操作系统)支持的文件系统中的一种，它允许网络中的计算机之间通过TCP/IP(TransmissionControl Protocol/Internet Protocol，传输控制协议/网际协议)网络共享资源。内核态是指CPU(central processing unit，中央处理器)可以访问内存所有数据，包括外围设备，例如硬盘，网卡等，CPU也可以将自己从一个程序切换到另一个程序。用户态是指只能受限的访问内存，且不允许访问外围设备，占用CPU的能力被剥夺，CPU资源可以被其他程序获取。在NFS的应用中，本地NFS的客户端应用可以透明地读写位于远端NFS服务器上的文件，就像访问本地文件一样。NFS-Ganesha是用户态网络文件系统，属于开源项目，在系统服务故障场景下，相比于内核态NFS具有较好管理性和可维护性，并且用户态NFS-Ganesha易于实施和维护，因此，分布式对象存储NFS-Ganesha应用前景很大。
在网络文件系统文件锁应用中，在故障场景，例如，客户端重启、异常宕机，服务端重启、异常宕机，网络中断异常等，服务端与客户端如何实现可靠的锁的状态通知恢复机制，如何保证数据的一致性在网络文件系统中是一个备受关注的问题。
因此，本发明实施例公开了一种基于用户态网络文件系统的故障通知方法、装置、设备及计算机可读存储介质，以提高文件锁的可靠性。
参见图1，本发明实施例提供的一种基于用户态网络文件系统的故障通知方法流程示意图；该故障通知方法基于目标端，具体包括：
S101、监听对端在重启后发送的故障通知信息，并在本端重启后向对端发送本端的故障通知信息；目标端为客户端或者服务端；
其中，所述监听对端在重启后发送的故障通知信息，并在本端重启后向对端发送本端的故障通知信息，包括：
每个目标端通过NSM服务的rpc.statd进程，监听对端在重启后发送的故障通知信息；每个目标端在重启后通过NSM服务的sm-notify进程，向对端发送本端的故障通知信息。
需要说明的是，本申请所述的故障通知方法为基于目标端的角度执行的，该目标端可以为用户态网络文件系统NFS-Ganesha的服务端或者用户态网络文件系统NFS-Ganesha的客户端，这是因为服务端和客户端均部署NSM(网络状态监控器，Network StatusMonitor)服务，在Linux上，NSM服务进程由两个独立的用户空间程序组成：rpc.statd和sm-notify；其中，rpc.statd该守护进程用于监听其他主机的重启消息，并管理本地主机重启时需要通知的主机列表。sm-notify是一个辅助程序，用于在本地系统重启时通知NFS对端。
具体的，在本实施例中，若目标端为客户端，则每个客户端均通过NSM服务的rpc.statd进程，监听服务端在重启后发送的故障通知信息，同理，若目标端为服务端，则服务端同样通过NSM服务的rpc.statd进程，监听每个客户端在重启后发送的故障通知信息；进一步，若目标端为客户端，则在客户端故障重启后，需要通过NSM服务的sm-notify进程，向服务端发送客户端已重启的故障通知信息，同理，若目标端为服务端，则在服务端故障重启后，需要通过NSM服务的sm-notify进程，向客户端发送客户端已重启的故障通知信息。
需要说明的是，本申请中的rpc.statd还用于管理本地主机重启时需要通知的主机列表，也即：客户端的rpc.statd需要管理客户端重启后需要通知的服务端列表，服务端的rpc.statd需要管理服务端重启后需要通知的客户端列表。因此，在目标端故障重启后，目标端的NSM将遍历notify列表(/var/lib/nfs/statd/sm)，调用sm-notify并通知对端(/var/lib/nfs/statd/sm.bak)。
在本方案中，若NFS-Ganesha服务端是指NFS V3协议版本，则由于V3版本是无状态的协议，所以为文件加锁的RPC操作，需要单独的协议支持，即NLM(Network lock manager，网络加锁管理器)络锁状态监控NSM，以及与之对应的rpc.lockd(用来实现文件锁的功能)、rpc.statd服务。其中，当本地系统重启时，sm-notify命令会通知对端上的NSM服务关于重启的信息。当远程主机重启时，远程对端的sm-notify会通知本地的rcp.statd，然后将此信息告诉本地NFS锁管理器，本地锁管理器将维护与重启端对应文件的锁。
具体的，NFS客户端和服务端之间的第一个文件锁交互行为，会使得两端的NLM管理本地的NSM服务以存储它们对端的信息。在Linux上，也就是让本地NLM锁管理器管理rpc.statd守护进程。rpc.statd会将NFS对端信息记录在/var/lib/nfs/statd目录下。每个客户端在每个文件锁请求中都会发送一个称为客户端caller_name的主机名。NFS服务端可以使用该主机名向客户端发送异步GRANT调用，或者通知客户端它已经重启完成。其中，异步GRANT调用是指异步堵塞调用，即：若客户端请求的文件已被加锁，则堵塞该请求，等待该文件锁被释放后，再给该客户端授权，对该文件加锁访问。
S102、若目标端为服务端，则监听到对端的目标客户端发送的故障通知信息后，释放目标客户端已持有的文件锁；若目标端为客户端，则监听到对端的目标服务端发送的故障通知信息后，在宽限期内重新向目标服务端申请已授权的文件锁。
需要说明的是，无论目标端为客户端还是服务端，都需要将本端重启后的故障通知信息向对端发送，并监听对端在重启后发送的故障通知信息，因此，目标端接收到对端发送的故障通知信息后，需要执行对应的操作来提供可靠的锁状态通知恢复机制。
在本实施例中，分别以目标端为客户端、目标端为服务端这两种情况对该锁状态通知恢复机制进行说明：
一、若目标端为服务端，则接收对端的目标客户端通过sm-notify进程发送的故障通知信息；根据故障通知信息携带的主机名，释放与主机名对应的目标客户端已持有的文件锁。
具体的，在目标客户端异常故障场景，目标客户端会重启，并在重启后通过sm-notify向服务端发送故障通知信息，该故障通知信息中存在标志位reclaim，若该标志位为true，则表示客户端重启过；反之，则未重启。服务端接收到该故障通知信息后，便可根据目标客户端发过来的标志位知道客户端已重启，这时服务端便可释放客户端已经持有的锁，从而实现在客户端重启后，及时释放文件锁。
二、若目标端为客户端，则接收对端的目标服务端通过sm-notify进程发送的故障通知信息；在预先设定的宽限期内重新向目标服务端申请已授权的文件锁；宽限期为目标服务端重启后的预定时长。其中，目标服务端在宽限期内堵塞除目标端发送的文件锁申请之外的其他访问请求。
具体的，在目标服务端异常故障场景，目标服务器重启将导致所有的客户端锁状态失效，而客户端并不知道锁状态失效。因此在本申请中，服务端重启后，服务端会主动通知客户端告知服务已重启，在宽限期即lease period期间内为客户端恢复已授权的锁。在本实施例中，该宽限期lease period可设定为90s，并且，在宽限期内，NFS-Ganesha服务将阻塞所有的读、写、lock等访问请求，目的是防止对外提供服务，从而确保不发生锁冲突。
需要说明的是，为了实现服务端在重启后向客户端发送故障通知信息，需要在服务端增加NFS-Ganesha启动依赖，即在服务端重启服务/usr/lib/systemd/system/ganesha.service中[unit]添加故障通知信息发送服务Requires＝rpc-statd-notify.service，这样服务端在重启后，就会主动通过SM_NOTIFY向各客户端发送故障通知信息，客户端在收到SM_NOTIFY的通知信息后，会在宽限期重新申请已授权的锁，保证了服务端重启后，服务端会主动通知客户端告知服务已重启。
参见图2，为本申请实施例公开的一种基于用户态网络文件系统的文件锁故障通知系统流程示意图，通过该图可以看出，NFS服务端锁管理器NLM管理服务端的rpc.statd服务，通过rpc.statd服务监控对端的故障状态，同理，NFS客户端锁管理器NLM管理客户端的rpc.statd服务，通过rpc.statd服务监控对端的故障状态，并且，服务端或者客户端各自的sm-notify向对端发送本端重启的信息，以让对端了解本端已重新启动。
综上可以看出，本方案提出的这种基于用户态网络文件系统的文件锁故障通知系统，在故障场景中，若服务端故障重启，则服务端发起通知，在约定的宽限期内恢复客户端已申请的锁；若客户端故障重启，则客户端发起通知服务端需要释放客户端所申请的锁，实现了一种可靠的锁状态通知恢复机制，支持多客户端并发访问，保证数据一致性和系统的稳定性，解决了在分布式文件系统中，由于多个客户端并发访问导致数据不一致，系统稳定性差的问题。
下面对本发明实施例提供的故障通知装置进行介绍，下文描述的故障通知装置与上文描述的故障通知方法可以相互参照。
参见图3，本发明实施例提供的一种基于用户态网络文件系统的故障通知装置，所述故障通知装置基于目标端，包括：
监听模块100，用于监听对端在重启后发送的故障通知信息；所述目标端为客户端或者服务端；
信息发送模块200，用于在本端重启后向对端发送本端的故障通知信息；
第一文件锁处理模块300，用于在所述目标端为服务端，监听到对端的目标客户端发送的故障通知信息后，释放所述目标客户端已持有的文件锁；
第二文件锁处理模块400，用于在所述目标端为客户端，监听到对端的目标服务端发送的故障通知信息后，在宽限期内重新向所述目标服务端申请已授权的文件锁。
其中，所述监听模块具体用于：通过NSM服务的rpc.statd进程，监听对端在重启后发送的故障通知信息；
所述信息发送模块具体用于：在目标端重启后通过NSM服务的sm-notify进程，向对端发送本端的故障通知信息。
其中，所述第一文件锁处理模块包括：
第一接收单元，用于在所述目标端为服务端时，接收对端的目标客户端通过sm-notify进程发送的故障通知信息；
文件锁释放单元，用于根据所述故障通知信息携带的主机名，释放与所述主机名对应的所述目标客户端已持有的文件锁。
其中，所述第二文件锁处理模块包括：
第二接收单元，用于在所述若所述目标端为客户端时，接收对端的目标服务端通过sm-notify进程发送的故障通知信息；
文件锁申请单元，用于在预先设定的宽限期内重新向所述目标服务端申请已授权的文件锁；所述宽限期为所述目标服务端重启后的预定时长。
其中，所述目标服务端在所述宽限期内堵塞除所述目标端发送的文件锁申请之外的其他访问请求。
本发明实施例还公开了一种基于用户态网络文件系统的故障通知设备，包括：
存储器，用于存储计算机程序；
处理器，用于执行所述计算机程序时实现上述的故障通知方法的步骤。
在本实施例中，设备可以是PC(Personal Computer，个人电脑)，也可以是智能手机、平板电脑、掌上电脑、便携计算机等终端设备。
参见图4，为本发明实施例公开的一种基于用户态网络文件系统的故障通知设备结构示意图；该设备可以包括存储器11、处理器12和总线13。
其中，存储器11至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、磁性存储器、磁盘、光盘等。存储器11在一些实施例中可以是设备的内部存储单元，例如该设备的硬盘。存储器11在另一些实施例中也可以是设备的外部存储设备，例如设备上配备的插接式硬盘，智能存储卡(SmartMedia Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。进一步地，存储器11还可以既包括设备的内部存储单元也包括外部存储设备。存储器11不仅可以用于存储安装于设备的应用软件及各类数据，例如执行故障通知的程序代码等，还可以用于暂时地存储已经输出或者将要输出的数据。
处理器12在一些实施例中可以是一中央处理器(Central Processing Unit,CPU)、控制器、微控制器、微处理器或其他数据处理芯片，用于运行存储器11中存储的程序代码或处理数据，例如执行故障通知的程序代码等。
该总线13可以是外设部件互连标准(peripheral component interconnect，简称PCI)总线或扩展工业标准结构(extended industry standard architecture，简称EISA)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示，图4中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
进一步地，设备还可以包括网络接口14，网络接口14可选的可以包括有线接口和/或无线接口(如WI-FI接口、蓝牙接口等)，通常用于在该设备与其他电子设备之间建立通信连接。
可选地，该设备还可以包括用户接口，用户接口可以包括显示器(Display)、输入单元比如键盘(Keyboard)，可选的用户接口还可以包括标准的有线接口、无线接口。可选地，在一些实施例中，显示器可以是LED显示器、液晶显示器、触控式液晶显示器以及OLED(Organic Light-Emitting Diode，有机发光二极管)触摸器等。其中，显示器也可以适当的称为显示屏或显示单元，用于显示在设备中处理的信息以及用于显示可视化的用户界面。
图4仅示出了具有组件11-14的设备，本领域技术人员可以理解的是，图4示出的结构并不构成对设备的限定，可以包括比图示更少或者更多的部件，或者组合某些部件，或者不同的部件布置。
本发明实施例还公开了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述方法实施例所述的故障通知方法的步骤。
其中，该存储介质可以包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种基于用户态网络文件系统的故障通知方法，其特征在于，所述故障通知方法基于目标端，包括：
监听对端在重启后发送的故障通知信息，并在本端重启后向对端发送本端的故障通知信息；所述目标端为客户端或者服务端；
若所述目标端为服务端，则监听到对端的目标客户端发送的故障通知信息后，释放所述目标客户端已持有的文件锁；
若所述目标端为客户端，则监听到对端的目标服务端发送的故障通知信息后，在宽限期内重新向所述目标服务端申请已授权的文件锁。
2.根据权利要求1所述的故障通知方法，其特征在于，所述监听对端在重启后发送的故障通知信息，并在本端重启后向对端发送本端的故障通知信息，包括：
每个目标端通过NSM服务的rpc.statd进程，监听对端在重启后发送的故障通知信息；每个目标端在重启后通过NSM服务的sm-notify进程，向对端发送本端的故障通知信息。
3.根据权利要求2所述的故障通知方法，其特征在于，所述若所述目标端为服务端，则监听到对端的目标客户端发送的故障通知信息后，释放所述目标客户端已持有的文件锁，包括：
若所述目标端为服务端，则接收对端的目标客户端通过sm-notify进程发送的故障通知信息；
根据所述故障通知信息携带的主机名，释放与所述主机名对应的所述目标客户端已持有的文件锁。
4.根据权利要求2所述的故障通知方法，其特征在于，所述若所述目标端为客户端，则监听到对端的目标服务端发送的故障通知信息后，在宽限期内重新向所述目标服务端申请已授权的文件锁，包括：
所述若所述目标端为客户端，则接收对端的目标服务端通过sm-notify进程发送的故障通知信息；
在预先设定的宽限期内重新向所述目标服务端申请已授权的文件锁；所述宽限期为所述目标服务端重启后的预定时长。
5.根据权利要求4所述的故障通知方法，其特征在于，所述目标服务端在所述宽限期内堵塞除所述目标端发送的文件锁申请之外的其他访问请求。
6.一种基于用户态网络文件系统的故障通知装置，其特征在于，所述故障通知装置基于目标端，包括：
监听模块，用于监听对端在重启后发送的故障通知信息；所述目标端为客户端或者服务端；
信息发送模块，用于在本端重启后向对端发送本端的故障通知信息；
第一文件锁处理模块，用于在所述目标端为服务端，监听到对端的目标客户端发送的故障通知信息后，释放所述目标客户端已持有的文件锁；
第二文件锁处理模块，用于在所述目标端为客户端，监听到对端的目标服务端发送的故障通知信息后，在宽限期内重新向所述目标服务端申请已授权的文件锁。
7.根据权利要求6所述的故障通知装置，其特征在于，
所述监听模块具体用于：通过NSM服务的rpc.statd进程，监听对端在重启后发送的故障通知信息；
所述信息发送模块具体用于：在目标端重启后通过NSM服务的sm-notify进程，向对端发送本端的故障通知信息。
8.根据权利要求7所述的故障通知装置，其特征在于，所述第一文件锁处理模块包括：
第一接收单元，用于在所述目标端为服务端时，接收对端的目标客户端通过sm-notify进程发送的故障通知信息；
文件锁释放单元，用于根据所述故障通知信息携带的主机名，释放与所述主机名对应的所述目标客户端已持有的文件锁。
9.一种基于用户态网络文件系统的故障通知设备，其特征在于，包括：
存储器，用于存储计算机程序；
处理器，用于执行所述计算机程序时实现如权利要求1至5任一项所述的故障通知方法的步骤。
10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至5任一项所述的故障通知方法的步骤。
CN201911243288.4A 2019-12-06 2019-12-06 一种故障通知方法、装置、设备及计算机可读存储介质 Active CN111125048B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911243288.4A CN111125048B (zh) 2019-12-06 2019-12-06 一种故障通知方法、装置、设备及计算机可读存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911243288.4A CN111125048B (zh) 2019-12-06 2019-12-06 一种故障通知方法、装置、设备及计算机可读存储介质

Publications (2)

Publication Number Publication Date
CN111125048A true CN111125048A (zh) 2020-05-08
CN111125048B CN111125048B (zh) 2022-04-22

Family

ID=70497640

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911243288.4A Active CN111125048B (zh) 2019-12-06 2019-12-06 一种故障通知方法、装置、设备及计算机可读存储介质

Country Status (1)

Country Link
CN (1) CN111125048B (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111680015A (zh) * 2020-05-29 2020-09-18 北京百度网讯科技有限公司 文件资源处理方法、装置、设备和介质
CN114448778A (zh) * 2021-12-29 2022-05-06 中国航空工业集团公司西安航空计算技术研究所 一种标准网络文件系统的网络锁及其故障恢复方法
CN114710976A (zh) * 2020-10-16 2022-07-05 华为技术有限公司 一种锁重申方法、锁管理方法以及服务器

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110099253A1 (en) * 2009-10-26 2011-04-28 International Business Machines Corporation Consolidated notifications to nfs clients
CN102375955A (zh) * 2010-08-17 2012-03-14 伊姆西公司 网络文件系统联合命名空间内文件加锁的系统与方法
US20120259820A1 (en) * 2011-04-08 2012-10-11 Symantec Corporation Method and system for restarting file lock services at an adoptive node during a network filesystem server migration or failover
CN108023939A (zh) * 2014-11-12 2018-05-11 华为技术有限公司 分布式系统中锁服务器故障的处理方法及其系统
CN108833190A (zh) * 2018-07-27 2018-11-16 郑州云海信息技术有限公司 一种nfs服务故障告警方法、装置和存储介质
CN109684285A (zh) * 2018-12-13 2019-04-26 郑州云海信息技术有限公司 一种用户态网络文件系统文件锁方法、装置及设备

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110099253A1 (en) * 2009-10-26 2011-04-28 International Business Machines Corporation Consolidated notifications to nfs clients
CN102375955A (zh) * 2010-08-17 2012-03-14 伊姆西公司 网络文件系统联合命名空间内文件加锁的系统与方法
US20120259820A1 (en) * 2011-04-08 2012-10-11 Symantec Corporation Method and system for restarting file lock services at an adoptive node during a network filesystem server migration or failover
CN108023939A (zh) * 2014-11-12 2018-05-11 华为技术有限公司 分布式系统中锁服务器故障的处理方法及其系统
CN108833190A (zh) * 2018-07-27 2018-11-16 郑州云海信息技术有限公司 一种nfs服务故障告警方法、装置和存储介质
CN109684285A (zh) * 2018-12-13 2019-04-26 郑州云海信息技术有限公司 一种用户态网络文件系统文件锁方法、装置及设备

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
H. KISHIDA等: ""SSDLM: architecture of a distributed lock manager with high degree of locality for clustered file systems"", 《2003 IEEE PACIFIC RIM CONFERENCE ON COMMUNICATIONS COMPUTERS AND SIGNAL PROCESSING (PACRIM 2003) (CAT. NO.03CH37490)》 *
陈丹威等: ""并行网络文件系统中文件锁的设计与DS掉线问题的改进"", 《2011年通信与信息技术新进展——第八届中国通信学会学术年会论文集》 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111680015A (zh) * 2020-05-29 2020-09-18 北京百度网讯科技有限公司 文件资源处理方法、装置、设备和介质
US20210211498A1 (en) * 2020-05-29 2021-07-08 Beijing Baidu Netcom Science And Technology Co., Ltd. File resource processing method and apparatus, device and medium
US11451628B2 (en) * 2020-05-29 2022-09-20 Beijing Baidu Netcom Science And Technology Co., Ltd. File resource processing method and apparatus, device and medium
CN111680015B (zh) * 2020-05-29 2023-08-11 北京百度网讯科技有限公司 文件资源处理方法、装置、设备和介质
CN114710976A (zh) * 2020-10-16 2022-07-05 华为技术有限公司 一种锁重申方法、锁管理方法以及服务器
CN114448778A (zh) * 2021-12-29 2022-05-06 中国航空工业集团公司西安航空计算技术研究所 一种标准网络文件系统的网络锁及其故障恢复方法
CN114448778B (zh) * 2021-12-29 2024-01-23 中国航空工业集团公司西安航空计算技术研究所 一种标准网络文件系统的网络锁及其故障恢复方法

Also Published As

Publication number Publication date
CN111125048B (zh) 2022-04-22

Similar Documents

Publication Publication Date Title
CN111125048B (zh) 一种故障通知方法、装置、设备及计算机可读存储介质
US11829263B2 (en) In-place cloud instance restore
US9612919B2 (en) Methods and apparatus for storing and transmitting historical configuration data associated with information technology assets
US9176786B2 (en) Dynamic and automatic colocation and combining of service providers and service clients in a grid of resources for performing a data backup function
KR100423687B1 (ko) 소결합 노드 클러스터에서의 공유 디스크 파일 시스템용데이터 관리 응용 프로그램의 연속 수행 페일오버
US8533171B2 (en) Method and system for restarting file lock services at an adoptive node during a network filesystem server migration or failover
CN109245962B (zh) 服务器监控方法、系统、计算机设备及存储介质
US9106537B1 (en) Method for high availability of services in cloud computing systems
CN111327467A (zh) 一种服务器系统及其容灾备份方法和相关设备
CN111385296B (zh) 一种业务进程重启方法、装置、存储介质以及系统
CN110990190A (zh) 一种分布式文件锁故障处理方法、系统、终端及存储介质
CN111666134A (zh) 一种分布式任务调度的方法和系统
CN109257396B (zh) 一种分布式锁调度方法及装置
CN108352995B (zh) 一种smb业务故障处理方法和存储设备
CN115220876A (zh) 虚拟资源创建方法、装置、程序产品、介质及电子设备
CN110196749B (zh) 虚拟机的恢复方法及装置、存储介质及电子装置
CN113064602A (zh) 一种基于nfs灌装操作系统的方法、系统及介质
CN111274047A (zh) 信息处理方法、终端、系统、计算机设备和存储介质
CN111939562B (zh) 共享存储方法、电子设备及计算机可读存储介质
US10776134B2 (en) Management of application properties
CN114860505A (zh) 一种对象存储数据异步备份方法及系统
CN110365839B (zh) 关机方法、装置、介质及电子设备
CN112749042B (zh) 一种应用运行方法和装置
CN113094211B (zh) 一种备份数据处理的方法和装置
CN115390997A (zh) 分布式事务处理方法、装置及电子设备

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant