为何NFSv3比cifs容易实现高可用

最新推荐文章于 2024-05-14 13:48:35 发布

小-码虫

最新推荐文章于 2024-05-14 13:48:35 发布

阅读量2k

点赞数

分类专栏：存储技术文章标签： NFS cifs CTDB 高可用

本文链接：https://blog.csdn.net/Angel_94/article/details/87370735

版权

存储技术专栏收录该内容

11 篇文章 0 订阅

订阅专栏

声明：个人所写所有博客均为自己在学习中的记录与感想，或为在学习中总结他人学习成果，但因本人才疏学浅，如果大家在阅读过程中发现错误，欢迎大家指正。
微信公众号：
小码虫的公众号
实际操作中，结合CTDB实现内核NFS高可用，比CIFS容易很多。二者都是适用于文件存储，操作的对象是源文件。

综合资料与个人分析：

1.NFS独立于传输层，可使用TCP或UDP协议，恢复快速容易（NFSv4必须使用TCP）。CIFS基于C/S（客户端/服务器模式），面向网络连接的共享协议，对网络传输的可靠性要求高，使用TCP/IP，使用通过类似三次握手的三个交互的交互模式。客户端集成在操作系统内部。
2.NFS属无状态协议（在NFSv4中开始支持有状态），而CIFS属有状态协议；则NFS受故障影响小，可以自恢复交互过程，CIFS不行；但从传输效率上看，CIFS应该优于NFS，没用太多冗余信息传送；

NFS-CTDB高可用：

NFSv2和NFSv3都是无状态协议，服务器端不需要维护客户端的状态信息。无状态协议的一个优点在于灾难恢复，当服务器出现问题后，客户端只需要重复发送失败请求就可以了，直到收到服务器的响应信息。
但是某些操作必须需要状态，如文件锁。如果客户端申请了文件锁，但是服务器重启了，由于NFSv3无状态，客户端再执行锁操作可能就会出错了。NFSv3需要NLM协助才能实现文件锁功能，但是有的时候两者配合不够协调。NFSv4设计成了一种有状态的协议，自身实现了文件锁功能，就不需要NLM协议了

NFS-CTDB模型中，在/etc/exports中添加如下参数，禁用了NFSv4协议。
RPCNFSDARGS="-N 4"
因为NFSv4支持了有状态，NFS在服务器上存储了很多客户端的状态，交互时不会传输状态信息了，这个高可用模型无法生效了。

NFSv4说自己支持HA，支持默认90s的异常，没有测试过。想支持NFSv4版本的高可用，也可以使用nfs-ganesha，一个用户态的NFS服务。

NFSv4和NFSv3的差别：

(1) NFSv4设计成了一种有状态的协议，自身实现了文件锁功能和获取文件系统根节点功能，不需要NLM和MOUNT协议协助了。
(2) NFSv4增加了安全性，支持RPCSEC-GSS身份认证。
(3) NFSv4只提供了两个请求NULL和COMPOUND，所有的操作都整合进了COMPOUND中，客户端可以根据实际请求将多个操作封装到一个COMPOUND请求中，增加了灵活性。
(4) NFSv4文件系统的命令空间发生了变化，服务器端必须设置一个根文件系统(fsid=0)，其他文件系统挂载在根文件系统上导出。
(5) NFSv4支持delegation。由于多个客户端可以挂载同一个文件系统，为了保持文件同步，NFSv3中客户端需要经常向服务器发起请求，请求文件属性信息，判断其他客户端是否修改了文件。如果文件系统是只读的，或者客户端对文件的修改不频繁，频繁向服务器请求文件属性信息会降低系统性能。NFSv4可以依靠delegation实现文件同步。当客户端A打开一个文件时，服务器会分配给客户端A一个delegation。只要客户端A具有delegation，就可以认为与服务器保持了一致。如果另外一个客户端B访问同一个文件，则服务器会暂缓客户端B的访问请求，向客户端A发送RECALL请求。当客户端A接收到RECALL请求时将本地缓存刷新到服务器中，然后将delegation返回服务器，这时服务器开始处理客户端B的请求。
(6) NFSv4修改了文件属性的表示方法。由于NFS是Sun开发的一套文件系统，设计之出NFS文件属性参考了UNIX中的文件属性，可能Windows中不具备某些属性，因此NFS对操作系统的兼容性不太好。NFSv4将文件属性划分成了三类：
a.Mandatory Attributes: 这是文件的基本属性，所有的操作系统必须支持这些属性。
b.Recommended Attributes: 这是NFS建议的属性，如果可能操作系统尽量实现这些属性。
c.Named Attributes: 这是操作系统可以自己实现的一些文件属性。

cifs-CTDB高可用为何困难

cifs是一个有状态的连接协议，cifs结合CTDB，在linux下即samba结合CTDB搭建的高可用模型。
CTDB拥有两种TDB文件，普通的和持久性的。持久性的TDB文件会实时更新，并在每个节点上存储一个最新的副本，为了读写操作更快，持久性的TDB文件都是保存在在本地存储上而不是共享存储中。当想要写入到持久的TDB时，它会锁定整个CTDB数据库，执行读操作、写操作、事务提交操作最终都会被分发到所有节点，并在每个节点的本地写入。普通TDB文件是临时维护的，其原则是，每个节点不必知道数据库中的所有记录。只需道影响它自己的客户端连接的记录就足够了，所以即使某个节点离线了，从而丢失了这个节点上所有的普通TDB记录，但对于其他节点是没有影响的。
服务器保存关于客户端连接的状态信息，所有TCP/IP连接都依赖于状态信息，恰恰是cifs协议的状态信息存到了CTDB下的普通数据库中，也就是节点一离线，集群就无法知道这个数据库中有什么了，也就不知道了这个节点和谁建立过连接。如果只是外部网络断开，还可以通过内部网路读取故障节点的普通数据库内容，实现其他节点接管。为何不将客户端信息放到持久数据库中呢，因为竞争。