X

News, tips, partners, and perspectives for the Oracle Solaris operating system

在 Solaris Cluster 中通过 ZFS 配置 HA-NFS 为什么需要 SUNW.nfs?

Guest Author

Solaris Cluster 环境中配置高可用性 NFS 文件系统的典型方法是使用 HA-NFS 代理 (SUNW.nfs)。SUNW.nfs 代理只是共享文件系统(必须导出)。

由于 SUNW.HAStoragePlus 中支持 ZFS 作为故障转移文件系统,有两种可能的方法可以用来配置高可用性 NFS 文件系统(使用 ZFS 作为底层文件系统)。这两种方法是:

  1. 对 zpool 的文件系统启用 ZFS sharenfs 属性(即 sharenfs=on)而不使用 SUNW.nfs。
  2. 对 zpool 的文件系统禁用 ZFS sharenfs 属性(即 sharenfs=off),并让 SUNW.nfs 执行实际的共享。

在上面的两种方法中,仅当使用 SUNW.nfs 代理(即采用第 2 种方法)时,HA-NFS 才会正常工作,本篇博客文章介绍了需要使用 SUNW.nfs 的根本原因,以便使用 ZFS 在群集环境中配置高可用性 NFS 文件系统。

客户机的锁回收 (NFSv[23])

statd(1M) 跟踪客户机并在服务器上处理保留锁。服务器可以使用此信息使客户机能够在 NFS 服务器重新引导/故障转移后回收该锁。

如果通过将 ZFS sharenfs 属性设置为 on 而不是使用 SUNW.nfs 来共享文件系统,则锁信息将保存在 /var/statmon 下,/var/statmon 是本地文件系统并特定于主机。因此,如果发生故障转移,服务器将要故障转移到的计算机并未提供存储的信息。这使服务器无法向客户机发送请求以回收锁。

SUNW.nfs 代理已通过将监视器信息保存在稳定存储(位于多端口磁盘上)中并能够从所有群集节点访问此信息从而解决了此问题。

客户机的状态信息 (NFSv4)

NFSv4 是一个有状态协议,其中 nfsd(1M) 跟踪稳定存储中的客户机状态(如已打开/已锁定文件)。

如果通过将 ZFS sharenfs 属性设置为 on 来共享文件系统,稳定存储将位于 /var/nfs 下,并且无法从群集的所有节点访问 /var/nfs。这种情况下,在服务器故障转移方案中,客户机回收请求将失败并将导致客户机应用程序退出(除非客户机应用程序捕捉到 SIGLOST 信号)。

SUNW.nfs 代理已通过将状态信息保存在稳定存储(在群集节点之间共享)中从而解决了此问题,这有助于服务器使客户机能够回收其状态。


下面通过图形显示了两种方法的差异。

不使用 SUNW.nfs 的 HA-NFS
 不使用 SUNW.nfs 的 HA-NFS

使用 SUNW.nfs 的 HA-NFS
 使用 SUNW.nfs 的 HA-NFS

 
更确切地说,zfs 文件系统的 ZFS sharenfs 属性并不适用于 Solaris Cluster 环境,因此通过 ZFS 配置 HA-NFS 时必须使用 SUNW.nfs 代理

附言:
SUNW.nfs 用来保存信息的稳定存储位于 ZFS 高可用性文件系统(它是 SUNW.nfs 资源类型的 PathPrefix 扩展属性的值)中。

Venkateswarlu Tella (Venku)
Solaris Cluster 工程部

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.