如何进行NFS文件锁一致性设计原理解析

62次阅读
没有评论

这篇文章给大家介绍如何进行 NFS 文件锁一致性设计原理解析，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。

文件锁

文件锁是文件系统的最基本特性之一，应用程序借助文件锁可以控制其他应用对文件的并发访问。NFS 作为类 UNIX 系统的标准网络文件系统，在发展过程中逐步的原生地支持了文件锁(从 NFSv4 开始)。NFS 从上个世界 80 年代诞生至今，共发布了 3 个版本：NFSv2、NFSv3、NFSv4。NFSv4 最大的变化是有“状态”了。某些操作需要服务端维持相关状态，如文件锁，例如客户端申请了文件锁，服务端就需要维护该文件锁的状态，否则其他客户端冲突的访问就无法检测。如果是 NFSv3 就需要 NLM 协助才能实现文件锁功能，但是有的时候两者配合不够协调就会容易出错。而 NFSv4 设计成了一种有状态的协议，自身就可以实现了文件锁功能，也就不需要 NLM 协议了。

应用接口

应用程序可以通过 fcntl()或 flock()系统调用管理 NFS 文件锁，下面 NAS 使用 NFSv4 挂载时获取文件锁的调用过程:

如何进行 NFS 文件锁一致性设计原理解析

从上图调用栈容易看出来，NFS 文件锁实现逻辑基本复用了 VFS 层设计和数据结构，在通过 RPC 从 Server 成功获取文件锁后调用 locks_lock_inode_wait()函数将获得文件锁交给到 VFS 层管理，关于 VFS 层文件锁设计的相关资料比较多，在此就不再描述了。

EOS 原理

文件锁是典型的非幂等操作，文件锁操作的重试和 Failover 会导致文件锁状态视图在客户端和服务端间的不一致。NFSv4 借助 SeqId 机制设计了最多执行一次的机制，具体方法如下：

针对每个 open/lock 状态 Client 和 Server 同时独立维护 seqid，Client 在发起会引起状态变化的操作时 (open/close/lock/unlock/release_lockowner) 会将 seqid 加 1，并作为参数发送给 Server，假定 Client 发送的 seqid 为 R，Server 维护的 seqid 为 L，则：
1) 若 R == L +1，表示合法请求，正常处理之；
2) 若 R == L，表示重试请求，Server 将缓存的 reply 返回即可；
3) 其他情况均为非法请求，决绝访问。
根据上述规则，Server 可判断操作是否为正常、重试或非法请求。

该方法能够保证每个文件锁操作在服务端最多执行一次，解决了 RPC 重试带来的重复执行的问题，但是仅靠这一点是不够的。比如 LOCK 操作发送后调用线程被信号中断，此后服务端又成功接受并执行了该 LOCK 操作，这样服务端就记录了客户端持有了锁，但客户端中却因为中断而没有维护这把锁，客户端和服务端间的锁状态视图不一致就发生了。因此，客户端还需配合处理异常场景，最终才能够做到文件锁视图一致性。

异常处理

由上一节分析可知，客户端需要配合处理异常场景才能够保证文件视图一致性，那么客户端设计者主要做了哪些配合的设计呢？目前客户端主要从 SunRPC 和 NFS 协议实现两个维度相互配合解决该问题，下面会分别介绍这两个维度的设计如何保证了文件锁状态视图一致性。

SunRPC 设计

SunRPC 是 Sun 公司专门为远程过程调用设计的网络通讯协议，这里从保障文件锁视图一致性的维度来了解一下 SunRPC 实现层面的设计理念：

1) 客户端使用 int32_t 类型的 xid 标识上层使用者发起的每个远程过程调用过程，每个远程过程调用的多次 RPC 重试使用相同的 xid 标识，这样就保障了多次 RPC 重试中任何一个返回就可以告知上层远程过程调用已经成功，保证了服务端执行远程过程调用执行耗时较长时也能拿到结果，这一点和传统的 netty/mina/brpc 等都需要每个 RPC 都要有独立的 xid/packetid 不同；
2) 服务端设计了 DRC(duplicate request cache)缓存最近执行的 RPC 结果，接收到 RPC 时会首先通过 xid 检索 DRC 缓存，若命中则表明 RPC 为重试操作，直接返回缓存的结果即可，这在一定程度上规避了 RPC 重试带来的重复执行的问题。为了避免 xid 复用导致 DRC 缓存返回非预期的结果，开发者通过下述设计进一步有效地减少复用引起错误的概率:
a) 客户端建立新链接时初始 xid 采用随机值:
b) 服务端 DRC 会额外记录请求的校验信息，缓存命中时会同时校验这些信息；
3) 客户端允许在获得服务端相应前无限重试，保证调用者能够获得服务端确定性的执行结果，当然这样的策略会导致无响应时调用者会一直 hang；
4) NFS 允许用户在挂载时通过 soft/hard 参数指定 SunRPC 的重试策略，其中 soft 模式禁止超时后重试，hard 模式则持续重试。当用户使用 soft 模式挂载时 NFS 实现不保证客户端和服务端状态视图的一致性，在遇到远程过程调用返回超时要求应用程序配合状态的清理和恢复，比如关闭访问出错的文件等，然而实践中很少有应用程序会配合，所以一般情况下 NAS 用户都使用 hard 模式挂载；
总之，SunRPC 要解决的核心问题之一是远程过程调用执行时间是不可控的，协议设计者为此定制化设计，尽量避免非幂等操作 RPC 重试带来的副作用。

信号中断

应用程序等待远程过程调用结果时允许被信号中断。当发生信号中断时由于没有得到远程过程调用的执行结果，所以客户端和服务端的状态很可能就不一致了，比如加锁操作在服务端已经成功执行，但客户端并不知道这个情况。这就要求客户端做额外的工作将状态和服务端恢复一致。下面简要分析获取文件锁被信号中断后的处理说明 NFS 协议实现层面的一致性设计。
通过获取 NFSv4 文件锁的过程可知，NFSv4 获取文件锁最终会调用_nfs4_do_setlk()函数发起 RPC 操作，最终调用 nfs4_wait_for_completion_rpc_task()等待，下面是相关代码:

5684 static int _nfs4_do_setlk(struct nfs4_state state, int cmd, struct file_lock fl, int recovery_type)
5685 {

 ......

5718 task = rpc_run_task(task_setup_data);
5719 if (IS_ERR(task))
5720 return PTR_ERR(task);
5721 ret = nfs4_wait_for_completion_rpc_task(task);
5722 if (ret == 0) {
5723 ret = data- rpc_status;
5724 if (ret)
5725 nfs4_handle_setlk_error(data- server, data- lsp,
5726 data- arg.new_lock_owner, ret);
5727 } else
5728 data- cancelled = 1;

 ......
 }

Copy
通过分析 nfs4_wait_for_completion_rpc_task()实现可知，当 ret 0 时，表明获取锁过程被信号中，并使用 struct nfs4_lockdata 的 cancelled 成员记录。继续查看 rpc_task 完成后释放时的回调函数 nfs4_lock_release():

从上面红色框中代码可知，nfs4_lock_release()检测到存在信号中断时会调用 nfs4_do_unlck()函数尝试将可能成功获得文件锁释放掉，注意此时没有调用 nfs_free_seqid()函数将持有的 nfs_seqid 释放掉，这是为了：

1) 保证订正状态过程中不会有用户新发起的并发加锁或者释放锁操作，简化实现；
2) 保证 hard 模式下 UNLOCK 操作只会在 LOCK 操作返回后才会发送，保障已经获得锁能够被释放掉；
客户端通过上面的方法能够有效地保证信号中断后客户端和服务端锁状态的最终一致性, 但也是在损失一部分可用性为代价的。

文件锁是文件系统原生支持的基础特性，NAS 作为共享的文件系统要面临客户端和服务端锁状态视图一致性的问题，NFSv4.0 在一定程度上解决了这个问题，当然，技术前进的脚步不会停止，NFS 的更新迭代也就不会停止，未来的 NFS 将会有更多的期待。

关于如何进行 NFS 文件锁一致性设计原理解析就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。