澳门新浦京娱乐场网站-www.146.net-新浦京娱乐场官网
做最好的网站

澳门新浦京娱乐场网站:statd汉语手册,NFS基本使

本人译作集合:http://www.cnblogs.com/f-ck-need-u/p/7048359.html

本人译作集合:http://www.cnblogs.com/f-ck-need-u/p/7048359.html

第3章 NFS基本应用,第3章NFS应用


本文目录:

1.1 概述

1.2 RPC不可不知的原理

1.2.1 RPC原理

1.2.2 RCP工具介绍

1.3 启动NFS

1.4 配置导出目录和挂载使用

1.4.1 配置NFS导出目录

1.4.2 挂载NFS文件系统

1.4.3 NFS伪文件系统

1.5 showmount命令

1.6 NFS身份映射

1.7 使用exportfs命令导出目录

1.8 深入NFS的方向


 NFS应用场景是:A,B,C三台机器上需要保证被访问到的文件是一样的,A共享数据出来,B和C分别去挂载A共享的数据目录,从而B和C访问到的数据和A上的一致性

RPCBIND(8)                           BSD System Manager's Manual                     RPCBIND(8)

NAME
     rpcbind — 通用地址和RCP程序号码(RPC program number)之间的映射器

SYNOPSIS
     rpcbind [-adhiLls]

DESCRIPTION
     rpcbind工具可以将RPC程序号码和通用地址互相转换。要让某主机能向远程主机的服务发起RPC调用,
     则该主机上的rpcbind必须处于已运行状态。

     当RPC服务启动后,它会告诉rpcbind它监听在哪个地址上,还会告诉它为服务准备好提供的PRC程序
     号码。当客户端要向某个给定的程序号码发起RPC调用时,它首先会联系服务端的rpcbind以确定RPC
     请求应该发送到哪个地址上。

     rpcbind工具应该在所有RPC管理的服务(rpc service)启动之前启动。一般来说,标准的rpc服务由端
     口监视器来启动,因此rpcbind必须在端口监视器被调用之前已经启动完成。

     当rpcbind工具已经启动后,它会检查特定的name-to-address的转换调用功能是否正确执行。如果失
     败,则网络配置数据库会被认为过期,由于RPC管理的服务在这种情况下无法正确运行,rpcbind会输
     出这些信息并终止。

     rpcbind工具只能由super-user启动。

OPTIONS
     -a      在调试模式下,遇到错误时强制中断。

     -d      运行调试模式。在此模式下,rpcbind将记录额外的信息,如果指定了"-a"选项,则出现某些
             错误时中断。使用该选项,name-to-address转换的一致性会一直被检测且详细记录相关信息。

     -f      不进行fork且运行在后台。

     -h      指定绑定到UDP请求的特定IP地址。该选项可多次指定,在多宿主主机(multi-homed即具有多
             个网络接口的主机)该选项通常是必须的。如果不给定"-h"选项,rpcbind将绑定到INADDR_ANY
             上,这将导致当多宿主主机上的rpcbind从非UDP数据包接收的地址返回UDP响应包时出错。注
             意,当使用"-h"指定IP地址时,rpcbind将自动向列表中添加127.0.0.1,如果启用IPv6则还添
             加::1。

     -i      以"不安全"(Insecure)模式运行。运行从任何主机上调用SET和UNSET。一般情况下,出于安全,
             rpcbind仅从环回接口上接收请求。若要兼容早期不使用环回接口接收请求的版本,该选项是
             必须的。

     -l      启用libwrap连接日志。

     -s      立即改变rpcbind用户daemon相关权限。这会导致rpcbind使用非特权端口流出数据,阻止非特权
             客户端使用rpcbind连接服务器上特权端口对应的服务。

     -w      在rpcbind启动时,让rpcbind读取state文件做温启动(warm start),state文件是rpcbind上次终
             止时创建的。
             (译者注:冷启动(cold start)是指完全以初始化的状态启动进程,温启动是指以某种方式恢复
             进程的状态。所以冷启动的进程不会继承任何原进程的数据和状态。)

NOTES
     如果rpcbind重启了,所有RPC管理的服务都必须重启。

SEE ALSO
     rpcinfo(8)

LINUX PORT
BSD                                September 14, 1992                                    BSD

rpc.statd程序主要实现NFS锁相关内容,如普通的文件锁(NLM、NSM)、文件委托、租约等,但注意,它和sm-notify组合起来才能实现整个NFS锁机制,具体见下文翻译文档中的说明。

1.1 概述

类似ext家族、xfs格式的本地文件系统,它们都是通过单个文件名称空间(name space)来包含很多文件,并提供基本的文件管理和空间分配功能。而文件是存放在文件系统中(上述名称空间内)的单个命名对象,每个文件都包含了文件实际数据和属性数据。但是,这些类型的文件系统和其内文件都是存放在本地主机上的。

实际上,还有网络文件系统。顾名思义,就是跨网络的文件系统,将远程主机上的文件系统(或目录)存放在本地主机上,就像它本身就是本地文件系统一样。在Windows环境下有cifs协议实现的网络文件系统,在Unix环境下,最出名是由NFS协议实现的NFS文件系统。

NFS即network file system的缩写,nfs是属于用起来非常简单,研究起来非常难的东西。相信,使用过它或学过它的人都不会认为它的使用有任何难点,只需将远程主机上要共享给客户端的目录导出(export),然后在客户端上挂载即可像本地文件系统一样。到目前为止,nfs已经有5个版本,NFSv1是未公布出来的版本,v2和v3版本目前来说基本已经淘汰,v4版本是目前使用最多的版本,nfsv4.1是目前最新的版本。

172.131.1.135  服务器端

以下是NFS相关翻译篇:

RPC.STATD(8)                          System Manager's Manual                       RPC.STATD(8)

NAME
       rpc.statd - NSM服务守护进程

SYNOPSIS
       rpc.statd [-dh?FLNvV] [-H prog] [-n my-name] [-o outgoing-port]
                 [-p listener-port] [-P path]
                 [--nlm-port port] [--nlm-udp-port port]

DESCRIPTION
       文件锁不是持久文件系统状态的一部分。因此当主机重启时锁的状态会丢失。

       当远程主机重启时,网络文件系统必须能够探测到锁状态的丢失。当NFS客户端重启时,NFS服务
       端必须释放该客户端所申请的所有文件锁。在服务端重启后,客户端必须能够提醒服务端它所申
       请的所有文件锁。

       对于NFSv2和NFSv3,使用网络状态监控器Network Status Monitor(NSM)协议来通知NFS对端关于重
       启的事情。在Linux上,NSM服务进程由两个独立的用户空间程序组成:

          ● rpc.statd

              该守护进程用于监听其他主机的重启消息,并管理本地主机重启时需要通知的主机列表。

          ● sm-notify
              一个辅助程序,用于在本地系统重启时通知NFS对端。

        (译者注:也就是说rpc.statd是重启信息的接收者,而sm-notify是信息的通知者)

       本地NFS锁管理器(NFS lock manager,NLM)会它本地的rpc.statd发出警告说列表中的每个远程对端
       状态都需要被监控。当本地系统重启时,sm-notify命令会通知对端上的NSM服务关于自己重启的
       事。当远程主机重启时,远程对端的sm-notify通知本地的rcp.statd,然后将此信息告诉本地NFS
       锁管理器,本地锁管理器将维护与重启端对应文件的锁。

NSM OPERATION IN DETAIL
       NFS客户端和服务端之间的第一个文件锁交互行为会使得两端的NLM都去联系它们本地的NSM服务以
       存储它们对端的信息。在Linux上,也就是让本地所管理器去联系rpc.statd守护进程。

       rpc.statd会将NFS对端信息记录在持久存储上。该信息描述了如果本地系统重启时如何去联系远程
       对端,如何识别对端报告它在重启的信息,以及当对端说它已经重启完成时如何通知NLM。

       每个客户端在每个文件锁请求中都会发送一个称为客户端caller_name的主机名。NFS服务端可以使
       用该主机名向客户端发送异步GRANT调用,或者通知客户端它已经重启完成。

       Linux NFS服务端可以将客户端的caller_name或客户端的网络地址提供给rpc.statd。为了遵守NSM
       协议,该名称或地址被称为对端mon_name。另外,本地锁管理器会告诉rpc.statd它自己的主机名,
       为了遵守NSM协议,该主机名被称为my_name。

       在NFS中,NFS服务端没有通知客户端它的主机名的交互行为。因此NFS客户端实际上不知道服务端
       的mon_name,尽管在SM_NOTIFY请求中会使用的它。Linux NFS客户端是通过使用从挂载命令中获取
       到的服务端主机名或地址来识别正在启动的NFS服务端的。

   Reboot notification
       当本地系统重启时,本地的sm-notify命令从持久存储中读取监控对端列表,并发送SM_NOTIFY请求
       给列表中每个远程对端的NSM服务进程,它使用mon_name字符串来指定发送目标。为了识别哪个主
       机已经重启完成,重启后的主机会使用sm-notify命令发送my_name字符串。远程rpc.statd将使用
       该字符串与其监控列表中的对端相匹配以找出发送SM_NOTIFY请求的主机。

       如果rpc.statd在它的监控列表中未找到能匹配接收到的SM_NOTIFY请求的对端,则通知不会被转发
       给本地锁管理器。另外,每个对端都独有一个32位整数NSM状态码,在每次重启之后,sm-notify命
       令都会让它碰撞重复。rpc.statd使用该号码来区分是重启还是通知重放。

       NFS锁恢复的一部分是重新发现哪个对端需要被再次监控。在每次重启之后,sm-notify命令都会清
       空持久存储上的监控列表。

OPTIONS
       -d, --no-syslog
              若同时指定了"-F"选项,则表示让rpc.statd不再向syslog中写日志,而是输出的stderr中。

       -F, --foreground
              使得rpc.statd附在控制终端上以便NSM操作可以直接被监控到,主要是为了调试。如果不指
              定该选项,则rpc.statd启动后立即进入后台运行。

       -h, -?, --help
              输出rpc.statd命令的使用说明并退出。

       -H, --ha-callout prog
              指定一个高可用callout程序。如果未指定该选项,则不执行任何callout程序。详细说明见
              下面的"High-availability callouts"段落。

       -L, --no-notify
              阻止rpc.statd在其启动时运行sm-notify命令,以及阻止保留已存在的NSM状态号码和监控列
              表。

              注意:sm-notify命令包含了一次检查以确保在每次系统重启后它仅运行了一次。若rpc.statd
              以不带"-L"选项重启时,这可以防止虚假的重启通知。

       -n, --name ipaddr | hostname
              指定RPC监听套接字绑定的地址。如果未指定该选项,rpc.statd使用通配地址(即0.0.0.0)。

              该字符串也会被传递给sm-notify命令,用于作为发送重启通知请求时的源地址。详细内容见
              sm-notify(8)的man文档。

       -N     让rpc.statd执行sm-notify命令然后退出。由于sm-notify命令可直接运行,该选项已废弃。

       -o, --outgoing-port port
              指定当sm-notify命令发送重启通知时使用的源端口号。详细内容见sm-notify(8)的man文档。

       -p, --port port
              指定rpc监听套接字监听的端口号。如果未指定该选项,则rpc.statd会尝试从/etc/services中
              获取,如果获取成功,则为所有监听套接字都设置此端口号,否则将为每个监听套接字都选择
              一个随机端口号。

              该选项在SM_NOTIFY需要穿越防火墙时可以用来调整端口号,防止被防火墙堵住。

       -T, --nlm-port port
              指定监听NLM请求的端口号。除非使用了"-U"单独指定了UDP端口号,否则将同时监听TCP和UDP的
              端口号。

       -U, --nlm-udp-port port
              指定监听NLM请求的UDP端口号。

       -P, --state-directory-path pathname
              指定NSM状态信息保存路径的父目录。如果未指定该选项,则默认为/var/lib/nfs/statd。

              程序启动之后,rpc.statd将尝试为此目录使用UID和GID设置它的所有者和所属组。

       -v, -V, --version
              输出rpc.statd的版本号并退出。

SECURITY
       The rpc.statd daemon must be started as root to acquire privileges needed to create sockets with
       privileged source ports, and  to  access the state information database.  Because rpc.statd mai-
       ntains a long-running network service, however, it drops root privileges as soon as it starts up
       to reduce the risk of a privilege escalation attack.

       During normal operation, the effective user ID it chooses is the owner of the state directory.  
       This allows  it  to  continue  to  access files in that directory after it has dropped its root
       privileges.  To control which user ID rpc.statd chooses, simply use chown(1) to set the owner of 
       the state directory.

       You can also protect your rpc.statd listeners using the tcp_wrapper library or iptables(8).  To
       use  the  tcp_wrapper  library,  add  the hostnames  of peers that should be allowed access to 
       /etc/hosts.allow. Use the daemon name statd even if the rpc.statd binary has a different filename.

       For further information see the tcpd(8) and hosts_access(5) man pages.

ADDITIONAL NOTES
       主机重启后的锁恢复对于维护数据一致性和防止不必要的应用程序挂起至关重要。为了能让
       rpc.statd更高效地匹配SM_NOTIFY请求,应该遵守一些最佳实践,包括:

              系统的UTS名称需要和NFS对端用来做联系的DNS名称相匹配。
              (注:若不知何为UTS名,可以简单地认为UTS名称就是主机名)

              系统的UTS名称应该总是fqdn格式的名称。

              系统的UTS名的正向和反向DNS映射最好要保持一致。

              客户端用来挂载的服务端的主机名最好能匹配它所发送的SM_NOTIFY请求中的mon_name。

       卸载NFS文件系统时无需停止客户端或服务端任意一端的状态监控。两端可能会继续保持监控一段
       时间,以防这两端间后续再次出现新的挂载和额外的文件锁的NFS流量出现。

       在Linux上,如果没有装在内核锁模块,所有的远程NFS对端都不会被监控。这可能会发生在NFS的
       客户端上,例如,自动挂载工具移除了所有NFS挂载点,因为它们处于空闲非活动状态。

   High-availability callouts
       在rpc.statd成功处理SM_MON, SM_UNMOU和SM_UNMON_ALL请求时或接收到SM_NOTIFY时,rpc.statd可以
       执行一个特定的回调(callout)程序。这个程序在高可用NFS(HA-NFS)环境下可用来跟踪锁状态,特别
       是某节点主机重启后资源需要迁移时。

       callout程序的名称由rpc.statd的"-H"选项指定。该程序运行时有4个参数:第一个参数是add-client
       或del-client或sm-notify,这取决于之所以要调用callout的原因。第二个参数是监控对端的mon_name。
       第三个参数是锁管理器要add-client或del-client时的caller_name,否则则是发送SM_NOTIFY请求的IP
       地址。第四个参数是SM_NOTIFY请求中的state_value。

   IPv6 and TI-RPC support
       TI-RPC is a pre-requisite for supporting NFS on IPv6. If TI-RPC support is built into rpc.statd,
       it attempts to start listeners on network transports  marked 'visible' in /etc/netconfig. As
       long as at least one network transport listener starts successfully, rpc.statd will operate.

FILES
       /var/lib/nfs/statd/sm    directory containing monitor list

       /var/lib/nfs/statd/sm.bak
                                directory containing notify list

       /var/lib/nfs/statd/state NSM state number for this host

       /var/run/run.statd.pid   pid file

       /etc/netconfig           network transport capability database

SEE ALSO
       sm-notify(8),nfs(5),rpc.nfsd(8),rpcbind(8),tcpd(8),hosts_access(5),iptables(8),netconfig(5)

       RFC 1094 - "NFS: Network File System Protocol Specification"
       RFC 1813 - "NFS Version 3 Protocol Specification"
       OpenGroup Protocols for Interworking: XNFS, Version 3W - Chapter 11

AUTHORS
       Jeff Uphoff <juphoff@users.sourceforge.net>
       Olaf Kirch <okir@monad.swb.de>
       H.J. Lu <hjl@gnu.org>
       Lon Hohberger <hohberger@missioncriticallinux.com>
       Paul Clements <paul.clements@steeleye.com>
       Chuck Lever <chuck.lever@oracle.com>

                                  1 November 2009                                 RPC.STATD(8)

1.2 RPC不可不知的原理

要介绍NFS,必然要先介绍RPC。RPC是remote procedure call的简写,人们都将其译为"远程过程调用",它是一种框架,这种框架在大型公司应用非常多。而NFS正是其中一种,此外NIS、hadoop也是使用rpc框架实现的。

172.131.1.137  客户端端

翻译:man rpcbind(rpcbind中文手册)
翻译:man nfsd(rpc.nfsd中文手册)
翻译:man mountd(rpc.mountd中文手册)
翻译:man statd(rpc.statd中文手册)
翻译:man sm-notify(sm-notify命令中文手册)
翻译:man exportfs(exportfs命令中文手册)
部分翻译:man nfs

以下是NFS相关翻译篇:

1.2.1 RPC原理

所谓的remote procedure call,就是在本地调用远程主机上的procedure。以本地执行"cat -n ~/abc.txt"命令为例,在本地执行cat命令时,会发起某些系统调用(如open()、read()、close()等),并将cat的选项和参数传递给这些函数,于是最终实现了文件的查看功能。在RPC层面上理解,上面发起的系统调用就是procedure,每个procedure对应一个或多个功能。而rpc的全名remote procedure call所表示的就是实现远程procedure调用,让远程主机去调用对应的procedure。

上面的cat命令只是本地执行的命令,如何实现远程cat,甚至其他远程命令?通常有两种可能实现的方式:

(1).使用ssh类的工具,将要执行的命令传递到远程主机上并执行。但ssh无法直接调用远程主机上cat所发起的那些系统调用(如open()、read()、close()等)。

(2).使用网络socket的方式,告诉远程服务进程要调用的函数。但这样的主机间进程通信方式一般都是daemon类服务,daemon类的客户端(即服务的消费方)每调用一个服务的功能,都需要编写一堆实现网络通信相关的代码。不仅容易出错,还比较复杂。

而rpc是最好的解决方式。rpc是一种框架,在此框架中已经集成了网络通信代码和封包、解包方式(编码、解码)。以下是rpc整个过程,以cat NFS文件系统中的a.sh文件为例。

 澳门新浦京娱乐场网站 1   澳门新浦京娱乐场网站 2

nfs客户端执行cat a.sh,由于a.sh是NFS文件系统内的文件,所以cat会发起一些procedure调用(如open/read/close),这些procedure和对应的参数会发送给rpc client(可能是单个procedure,也可能是多个procedure组合在一起一次性发送给rpc client,在NFSv4上是后者),rpc client会将这些数据进行编码封装(封装和解封装功能由stub代码实现),然后将封装后的数据通过网络发送给rpc server,rpc server会对封装的数据进行解封,于是就得到了要调用的procedures和对应的参数,然后将它们交给NFS服务进程,最终进行procedure的调用。NFS服务发起procedure调用后,会得到数据(可能是数据本身,可能是状态消息等),于是交给rpc server,rpc server会将这些数据封装并通过网络发送给rpc client,rpc client解封于是得到最终的返回结果。

从上面的过程可以知道,rpc的作用是数据封装,rpc client封装待调用的procedure及其参数,rpc server封装返回的数据。

所以注意,rpc的远程procedure调用的概念不是在本地向远程主机发起procedure的调用,而是将要执行的procedure包装后通过rpc发送出去,让远程主机上的对应程序自己去执行procedure并返回数据。也就是说rpc的作用是封装和发送,而不是发起调用。

举个更简单的例子,使用google搜索时,实现搜索功能的procedure和要搜索的内容就是rpc client封装的对象,也是rpc server要解封的对象,搜索的结果则是rpc server封装的对象,也是rpc client要解封的对象。解封后的最终结果即为google搜索的结果。

1.服务器安装

翻译:man rpcbind(rpcbind中文手册)
翻译:man nfsd(rpc.nfsd中文手册)
翻译:man mountd(rpc.mountd中文手册)
翻译:man statd(rpc.statd中文手册)
翻译:man sm-notify(sm-notify命令中文手册)
翻译:man exportfs(exportfs命令中文手册)
部分翻译:man nfs

1.2.2 RPC工具介绍

在CentOS 6/7上,rpc server由rpcbind程序实现,该程序由rpcbind包提供。

[[email protected] ~]# yum -y install rpcbind

[[email protected] ~]# rpm -ql rpcbind | grep bin/
/usr/sbin/rpcbind
/usr/sbin/rpcinfo

其中rpcbind是rpc主程序,在rpc服务端该程序必须处于已运行状态,其默认监听在111端口。rpcinfo是rpc相关信息查询工具。

对于rpc而言,其所直接管理的是programs,programs由一个或多个procedure组成。这些program称为RPC program或RPC service。

如下图,其中NFS、NIS、hadoop等称为网络服务,它们由多个进程或程序(program)组成。例如NFS包括rpc.nfsd、rpc.mountd、rpc.statd和rpc.idmapd等programs,其中每个program都包含了一个或多个procedure,例如rpc.nfsd这个程序包含了如OPEN、CLOSE、READ、COMPOUND、GETATTR等procedure,rpc.mountd也主要有MNT和UMNT两个procedure。

对于RPC而言,它是不知道NFS/NIS/hadoop这一层的,它直接管理programs。每个program启动时都需要找111端口的rpc服务登记注册,然后RPC服务会为该program映射一个program number以及分配一个端口号。其中每个program都有一个唯一与之对应的program number,它们的映射关系定义在/etc/rpc文件中。以后rpc server将使用program number来判断要调用的是哪个program中的procedure并将解包后的数据传递给该program。

例如只启动rpcbind时。

[[email protected] ~]# systemctl start rpcbind.service

[[email protected] ~]# rpcinfo -p localhost
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper

其中第一列就是program number,第二列vers表示对应program的版本号,最后一列为RPC管理的RPC service名,其实就是各program对应的称呼。

当客户端获取到rpc所管理的service的端口后,就可以与该端口进行通信了。但注意,即使客户端已经获取了端口号,客户端仍会借助rpc做为中间人进行通信。也就是说,无论何时,客户端和rpc所管理的服务的通信都必须通过rpc来完成。之所以如此,是因为只有rpc才能封装和解封装数据。

既然客户端不能直接拿着端口号和rpc service通信,那还提供端口号干嘛?这个端口号是为rpc server提供的,rpc server解包数据后,会将数据通过此端口交给对应的rpc service。

[root@localhost~]# yum install -y nfs-utils rpcbind

1.3 启动NFS

NFS本身是很复杂的,它由很多进程组成。这些进程的启动程序由nfs-utils包提供。由于nfs是使用RPC框架实现的,所以需要先安装好rpcbind。不过安装nfs-utils时会自动安装rpcbind。

[[email protected] ~]# yum -y install nfs-utils

[[email protected] ~]# rpm -ql nfs-utils | grep /usr/sbin
/usr/sbin/blkmapd
/usr/sbin/exportfs
/usr/sbin/mountstats
/usr/sbin/nfsdcltrack
/usr/sbin/nfsidmap
/usr/sbin/nfsiostat
/usr/sbin/nfsstat
/usr/sbin/rpc.gssd
/usr/sbin/rpc.idmapd
/usr/sbin/rpc.mountd
/usr/sbin/rpc.nfsd
/usr/sbin/rpc.svcgssd
/usr/sbin/rpcdebug
/usr/sbin/showmount
/usr/sbin/sm-notify
/usr/sbin/start-statd

其中以"rpc."开头的程序都是rpc service,分别实现不同的功能,启动它们时每个都需要向rpcbind进行登记注册。

[[email protected] ~]# systemctl start nfs.service

[[email protected] ~]# rpcinfo -p localhost
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  56229  status
    100024    1   tcp  57226  status
    100005    1   udp  20048  mountd
    100005    1   tcp  20048  mountd
    100005    2   udp  20048  mountd
    100005    2   tcp  20048  mountd
    100005    3   udp  20048  mountd
    100005    3   tcp  20048  mountd
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    3   tcp   2049  nfs_acl
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    3   udp   2049  nfs_acl
    100021    1   udp  48609  nlockmgr
    100021    3   udp  48609  nlockmgr
    100021    4   udp  48609  nlockmgr
    100021    1   tcp  50915  nlockmgr
    100021    3   tcp  50915  nlockmgr
    100021    4   tcp  50915  nlockmgr

可以看到,每个program都启动了不同版本的功能。其中nfs program为rpc.nfsd对应的program,为nfs服务的主进程,端口号为2049。mountd对应的program为rpc.mountd,它为客户端的mount和umount命令提供服务,即挂载和卸载NFS文件系统时会联系mountd服务,由mountd维护相关挂载信息。nlockmgr对应的program为rpc.statd,用于维护文件锁和文件委托相关功能,在NFSv4以前,称之为NSM(network status manager)。nfs_acl和status,显而易见是访问控制列表和状态信息维护的program。

再看看启动的相关进程信息。

[[email protected] ~]# ps aux | grep -E "[n]fs|[r]pc"
root        748  0.0  0.0      0     0 ?        S<   Jul26   0:00 [rpciod]
rpc        6127  0.0  0.0  64908  1448 ?        Ss   Jul26   0:00 /sbin/rpcbind -w
rpcuser    6128  0.0  0.0  46608  1836 ?        Ss   Jul26   0:00 /usr/sbin/rpc.statd --no-notify
root       6242  0.0  0.0      0     0 ?        S<   Jul26   0:00 [nfsiod]
root       6248  0.0  0.0      0     0 ?        S    Jul26   0:00 [nfsv4.0-svc]
root      17128  0.0  0.0  44860   976 ?        Ss   02:49   0:00 /usr/sbin/rpc.mountd
root      17129  0.0  0.0  21372   420 ?        Ss   02:49   0:00 /usr/sbin/rpc.idmapd
root      17134  0.0  0.0      0     0 ?        S<   02:49   0:00 [nfsd4]
root      17135  0.0  0.0      0     0 ?        S<   02:49   0:00 [nfsd4_callbacks]
root      17141  0.0  0.0      0     0 ?        S    02:49   0:00 [nfsd]
root      17142  0.0  0.0      0     0 ?        S    02:49   0:00 [nfsd]
root      17143  0.0  0.0      0     0 ?        S    02:49   0:00 [nfsd]
root      17144  0.0  0.0      0     0 ?        S    02:49   0:00 [nfsd]
root      17145  0.0  0.0      0     0 ?        S    02:49   0:00 [nfsd]
root      17146  0.0  0.0      0     0 ?        S    02:49   0:00 [nfsd]
root      17147  0.0  0.0      0     0 ?        S    02:49   0:00 [nfsd]
root      17148  0.0  0.0      0     0 ?        S    02:49   0:00 [nfsd]

其中有一项/usr/sbin/rpc.idmapd进程,该进程是提供服务端的uid/gid <==> username/groupname的映射翻译服务。客户端的uid/gid <==> username/groupname的映射翻译服务则由"nfsidmap"工具实现,详细说明见下文。

查看端口:

1.4 配置导出目录和挂载使用

root@localhost]# netstat -lntp

1.4.1 配置nfs导出目录

在将服务端的目录共享(share)或者说导出(export)给客户端之前,需要先配置好要导出的目录。比如何人可访问该目录,该目录是否可写,以何人身份访问导出目录等。

配置导出目录的配置文件为/etc/exports或/etc/exports.d/*.exports文件,在nfs服务启动时,会自动加载这些配置文件中的所有导出项。以下是导出示例:

/www    172.16.0.0/16(rw,async,no_root_squash)

其中/www是导出目录,即共享给客户端的目录;172.16.0.0/16是访问控制列表ACL,只有该网段的客户端主机才能访问该导出目录,即挂载该导出目录;紧跟在主机列表后的括号及括号中的内容定义的是该导出目录对该主机的导出选项,例如(rw,async,no_root_squash)表示客户端挂载/www后,该目录可读写、异步、可保留root用户的权限,具体的导出选项稍后列出。

以下是可接收的几种导出方式:

/www1    (rw,async,no_root_squash)  # 导出给所有主机,此时称为导出给world
/www2    172.16.1.1(rw,async)       # 仅导出给单台主机172.16.1.1
/www3    172.16.0.0/16(rw,async) 192.168.10.3(rw,no_root_squash)   # 导出给网段172.16.0.0/16,还导出给单台
                                                                   # 主机192.168.10.3,且它们的导出选项不同
/www4    www.a.com(rw,async)        # 导出给单台主机www.a.com主机,但要求能解析该主机名
/www     *.b.com(rw,async)          # 导出给b.com下的所有主机,要求能解析对应主机名

以下是常用的一些导出选项说明,更多的导出选项见man exports:常见的默认项是:ro,sync,root_squash,no_all_squash,wdelay。

导出选项

(加粗标红为默认)

选项说明

rw、ro

导出目录可读写还是只读(read-only)。

sync、async

同步共享还是异步共享。异步时,客户端提交要写入的数据到服务端,服务端接收数据后直接响应客户端,但此时数据并不一定已经写入磁盘中,而同步则是必须等待服务端已将数据写入磁盘后才响应客户端。也就是说,给定异步导出选项时,虽然能提升一些性能,但在服务端突然故障或重启时有丢失一部分数据的风险。

当然,对于只读(ro)的导出目录,设置sync或async是没有任何差别的。

anonuid

anongid

此为匿名用户(anonymous)的uid和gid值,默认都为65534,在/etc/passwd和/etc/shadow中它们对应的用户名为nfsnobody。该选项指定的值用于身份映射被压缩时。

root_squash

no_root_squash

是否将发起请求(即客户端进行访问时)的uid/gid=0的root用户映射为anonymous用户。即是否压缩root用户的权限。

all_squash

no_all_squash

是否将发起请求(即客户端进行访问时)的所有用户都映射为anonymous用户,即是否压缩所有用户的权限。

对于root用户,将取(no_)root_squash和(no_)all_squash的交集。例如,no_root_squash和all_squash同时设置时,root仍被压缩,root_squash和no_all_squash同时设置时,root也被压缩。

有些导出选项需要配合其他设置。例如,导出选项设置为rw,但如果目录本身没有w权限,或者mount时指定了ro挂载选项,则同样不允许写操作。

至于别的导出选项,基本无需去关注。

在配置文件写好要导出的目录后,直接重启nfs服务即可,它会读取这些配置文件。随后就可以在客户端执行mount命令进行挂载。

例如,exports文件内容如下:

/vol/vol0       *(rw,no_root_squash)
/vol/vol2       *(rw,no_root_squash)
/backup/archive *(rw,no_root_squash)

[root@localhost ~]# netstat -lntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1/systemd
tcp 0 0 0.0.0.0:20048 0.0.0.0:* LISTEN 1783/rpc.mountd
tcp 0 0 0.0.0.0:34099 0.0.0.0:* LISTEN -
tcp 0 0 192.168.122.1:53 0.0.0.0:* LISTEN 2263/dnsmasq
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1344/sshd
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 841/cupsd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 2041/master
tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:40037 0.0.0.0:* LISTEN 1216/rpc.statd
tcp6 0 0 :::60943 :::* LISTEN 1216/rpc.statd
tcp6 0 0 :::111 :::* LISTEN 1/systemd
tcp6 0 0 :::20048 :::* LISTEN 1783/rpc.mountd
tcp6 0 0 :::22 :::* LISTEN 1344/sshd
tcp6 0 0 ::1:631 :::* LISTEN 841/cupsd
tcp6 0 0 ::1:25 :::* LISTEN 2041/master
tcp6 0 0 :::40826 :::* LISTEN -
tcp6 0 0 :::2049 :::* LISTEN -

1.4.2 挂载nfs文件系统

然后去客户端上挂载它们。

[[email protected] ~]# mount -t nfs 172.16.10.5:/vol/vol0 /mp1
[[email protected] ~]# mount 172.16.10.5:/vol/vol2 /mp2
[[email protected] ~]# mount 172.16.10.5:/backup/archive /mp3

挂载时"-t nfs"可以省略,因为对于mount而言,只有挂载nfs文件系统才会写成host:/path格式。当然,除了mount命令,nfs-utils包还提供了独立的mount.nfs命令,它其实和"mount -t nfs"命令是一样的。

mount挂载时可以指定挂载选项,其中包括mount通用挂载选项,如rw/ro,atime/noatime,async/sync,auto/noauto等,也包括针对nfs文件系统的挂载选项。以下列出几个常见的,更多的内容查看man nfs和man mount。

选项

参数意义

默认值

suid

nosuid

如果挂载的文件系统上有设置了suid的二进制程序,

使用nosuid可以取消它的suid

suid

rw

ro

尽管服务端提供了rw权限,但是挂载时设定ro,则还是ro权限

权限取交集

rw

exec/noexec

是否可执行挂载的文件系统里的二进制文件

exec

user

nouser

是否运行普通用户进行档案的挂载和卸载

nouser

auto

noauto

auto等价于mount -a,意思是将/etc/fstab里设定的全部重挂一遍

auto

sync

nosync

同步挂载还是异步挂载

async

atime

noatime

是否修改atime,对于nfs而言,该选项是无效的,理由见下文

 

diratime

nodiratime

是否修改目录atime,对于nfs而言,该挂载选项是无效的,理由见下文

 

remount

重新挂载

 

以下是针对nfs文件系统的挂载选项。其中没有给出关于缓存选项(ac/noac、cto/nocto、lookupcache)的说明,它们可以直接采用默认值,如果想要了解缓存相关内容,可以查看man nfs。

选项

功能

默认值

fg/bg

挂载失败后mount命令的行为。默认为fg,表示挂载失败时将直接报错退出,如果是bg,

挂载失败后会创建一个子进程不断在后台挂载,而父进程mount自身则立即退出并返回0状态码。

fg

timeo

NFS客户端等待下一次重发NFS请求的时间间隔,单位为十分之一秒。

基于TCP的NFS的默认timeo的值为600(60秒)。

 

hard/soft

决定NFS客户端当NFS请求超时时的恢复行为方式。如果是hard,将无限重新发送NFS请求。

例如在客户端使用df -h查看文件系统时就会不断等待。

设置soft,当retrans次数耗尽时,NFS客户端将认为NFS请求失败,从而使得NFS客户端

返回一个错误给调用它的程序。

hard

retrans

NFS客户端最多发送的请求次数,次数耗尽后将报错表示连接失败。如果hard挂载选项生效,

则会进一步尝试恢复连接。

3

rsize

wsize

一次读出(rsize)和写入(wsize)的区块大小。如果网络带宽大,这两个值设置大一点能提升传

输能力。最好设置到带宽的临界值。

单位为字节,大小只能为1024的倍数,且最大只能设置为1M。

 

注意三点:

(1).所谓的soft在特定的环境下超时后会导致静态数据中断。因此,仅当客户端响应速度比数据完整性更重要时才使用soft选项。使用基于TCP的NFS(除非显示指定使用UDP,否则现在总是默认使用TCP)或增加retrans重试次数可以降低使用soft选项带来的风险。

(2).由于nfs的客户端挂载后会缓存文件的属性信息,其中包括各种文件时间戳,所以mount指定时间相关的挂载选项是没有意义的,它们不会有任何效果,包括atime/noatime,diratime/nodiratime,relatime/norelatime以及strictatime/nostrictatime等。具体可见man nfs中"DATA AND METADATA COHERENCE"段的"File timestamp maintainence"说明,或者见本文末尾的翻译。

(3).如果是要开机挂载NFS文件系统,方式自然是写入到/etc/fstab文件或将mount命令放入rc.local文件中。如果是将/etc/fstab中,那么在系统环境初始化(exec /etc/rc.d/rc.sysinit)的时候会加载fstab中的内容,如果挂载fstab中的文件系统出错,则会导致系统环境初始化失败,结果是系统开机失败。所以,要开机挂载nfs文件系统,则需要在/etc/fstab中加入一个挂载选项"_rnetdev",防止无法联系nfs服务端时导致开机启动失败。例如:

172.16.10.5:/www    /mnt    nfs    defaults,_rnetdev    0    0

当导出目录后,将在/var/lib/nfs/etab文件中写入一条对应的导出记录,这是nfs维护的导出表,该表的内容会交给rpc.mountd进程,并在必要的时候(mountd接受到客户端的mount请求时),将此导出表中的内容加载到内核中,内核也单独维护一张导出表。

启动nfs服务

1.4.3 nfs伪文件系统

服务端导出/vol/vol0、/vol/vol2和/backup/archive后,其中vol0和vol1是连在一个目录下的,但它们和archive目录没有连在一起,nfs采用伪文件系统的方式来桥接这些不连接的导出目录。桥接的方式是创建那些未导出的连接目录,如伪vol目录,伪backup目录以及顶级的伪根,如下图所示。

当客户端挂载后,每次访问导出目录时,其实都是通过找到伪文件系统(文件系统都有id,在nfs上伪文件系统的id称为fsid)并定位到导出目录的。

[root@localhost ]# systemctl start nfs

1.5 showmount命令

使用showmount命令可以查看某一台主机的导出目录情况。因为涉及到rpc请求,所以如果rpc出问题,showmount一样会傻傻地等待。

主要有3个选项。

showmount [ -ade]  host
-a:以host:dir格式列出客户端名称/IP以及所挂载的目录。但注意该选项是读取NFS服务端/var/lib/nfs/rmtab文件,
  :而该文件很多时候并不准确,所以showmount -a的输出信息很可能并非准确无误的
-e:显示NFS服务端所有导出列表。
-d:仅列出已被客户端挂载的导出目录。

另外showmount的结果是排序过的,所以和实际的导出目录顺序可能并不一致。

例如:

[[email protected] ~]# showmount -e 172.16.10.5
Export list for 172.16.10.5:
/backup/archive *
/vol/vol2       *
/vol/vol0       *
/www            172.16.10.4

[[email protected] ~]# showmount -d 172.16.10.5
Directories on 172.16.10.5:
/backup/archive
/vol/vol0
/vol/vol2

root@localhost ~]# systemctl status nfs

1.6 nfs身份映射

NFS的目的是导出目录给各客户端,因此导出目录中的文件在服务端和客户端上必然有两套属性、权限集。

例如,服务端导出目录中某a文件的所有者和所属组都为A,但在客户端上不存在A,那么在客户端上如何显示a文件的所有者等属性。再例如,在客户端上,以用户B在导出目录中创建了一个文件b,如果服务端上没有用户B,在服务端上该如何决定文件b的所有者等属性。

所以,NFS采用uid/gid <==> username/groupname映射的方式解决客户端和服务端两套属性问题。由于服务端只能控制它自己一端的身份映射,所以客户端也同样需要身份映射组件。也就是说,服务端和客户端两端都需要对导出的所有文件的所有者和所属组进行映射。

但要注意,服务端的身份映射组件为rpc.idmapd,它以守护进程方式工作。而客户端使用nfsidmap工具进行身份映射。

服务端映射时以uid/gid为基准,意味着客户端以身份B(假设对应uid=Xb,gid=Yb)创建的文件或修改了文件的所有者属性时,在服务端将从/etc/passwd(此处不考虑其他用户验证方式)文件中搜索uid=Xb,gid=Yb的用户,如果能搜索到,则设置该文件的所有者和所属组为此uid/gid对应的username/groupname,如果搜索不到,则文件所有者和所属组直接显示为uid/gid的值。

客户端映射时以username/groupname为基准,意味着服务端上文件所有者为A时,则在客户端上搜索A用户名,如果搜索到,则文件所有者显示为A,否则都将显示为nobody。注意,客户端不涉及任何uid/gid转换翻译过程,即使客户端上A用户的uid和服务端上A用户的uid不同,也仍显示为用户A。也就是说,客户端上文件所有者只有两种结果,要么和服务端用户同名,要么显示为nobody。

因此考虑一种特殊情况,客户端上以用户B(其uid=B1)创建文件,假如服务端上没有uid=B1的用户,那么创建文件时提交给服务端后,在服务端上该文件所有者将显示为B1(注意它是一个数值)。再返回到客户端上看,客户端映射时只简单映射username,不涉及uid的转换,因此它认为该文件的所有者为B1(不是uid,而是username),但客户端上必然没有用户名为B1的用户(尽管有uid=B1对应的用户B),因此在客户端,此文件所有者将诡异地将显示为nobody,其诡异之处在于,客户端上以身份B创建的文件,结果在客户端上却显示为nobody。

综上考虑,强烈建议客户端和服务端的用户身份要统一,且尽量让各uid、gid能对应上。

nfs-server.service - NFS server and services
Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled; vendor preset: disabled)
Drop-In: /run/systemd/generator/nfs-server.service.d
└─order-with-mounts.conf
Active: active (exited) since 四 2017-11-16 15:22:31 CST; 18min ago

1.7 使用exportfs命令导出目录

除了启动nfs服务加载配置文件/etc/exports来导出目录,使用exportfs命令也可以直接导出目录,它无需加载配置文件/etc/exports,当然exportfs也可以加在/etc/exports文件来导出目录。实际上,nfs服务启动脚本中就是使用exportfs命令来导出/etc/exports中内容的。

例如,CentOS 6上/etc/init.d/nfs文件中,导出和卸载导出目录的命令为:

[[email protected] ~]# grep exportfs /etc/init.d/nfs  
        [ -x /usr/sbin/exportfs ] || exit 5
        action $"Starting NFS services: " /usr/sbin/exportfs -r
        cnt=`/usr/sbin/exportfs -v | /usr/bin/wc -l`
                action $"Shutting down NFS services: " /usr/sbin/exportfs -au
        /usr/sbin/exportfs -r

在CentOS 7上则如下:

[[email protected] ~]# grep exportfs /usr/lib/systemd/system/nfs.service      
ExecStartPre=-/usr/sbin/exportfs -r
ExecStopPost=/usr/sbin/exportfs -au
ExecStopPost=/usr/sbin/exportfs -f
ExecReload=-/usr/sbin/exportfs -r

当然,无论如何,nfsd等守护进程是必须已经运行好的。

以下是CentOS 7上exportfs命令的用法。注意, CentOS 7比CentOS 6多一些选项。

-a     导出或卸载所有目录。
-o options,...
       指定一系列导出选项(如rw,async,root_squash),这些导出选项在exports(5)的man文档中有记录。
-i     忽略/etc/exports和/etc/exports.d目录下文件。此时只有命令行中给定选项和默认选项会生效。
-r     重新导出所有目录,并同步修改/var/lib/nfs/etab文件中关于/etc/exports和/etc/exports.d/
       *.exports的信息(即还会重新导出/etc/exports和/etc/exports.d/*等导出配置文件中的项)。该
       选项会移除/var/lib/nfs/etab中已经被删除和无效的导出项。
-u     卸载(即不再导出)一个或多个导出目录。
-f     如果/prof/fs/nfsd或/proc/fs/nfs已被挂载,即工作在新模式下,该选项将清空内核中导出表中
       的所有导出项。客户端下一次请求挂载导出项时会通过rpc.mountd将其添加到内核的导出表中。
-v     输出详细信息。
-s     显示适用于/etc/exports的当前导出目录列表。

例如:

(1).导出/www目录给客户端172.16.10.6。

exportfs 172.16.10.6:/www

(2).导出/www目录给所有人,并指定导出选项。

exportfs :/www -o rw,no_root_squash

(3).导出exports文件中的内容。

exportfs -a

(4).重新导出所有已导出的目录。包括exports文件中和exportfs单独导出的目录。

exportfs -ar

(5).卸载所有已导出的目录,包括exports文件中的内容和exportfs单独导出的内容。即其本质为清空内核维护的导出表。

exportfs -au

(6).只卸载某一个导出目录。

exportfs -u 172.16.10.6:/www

[root@localhost ~]# ps -ef|grep nfs
root 1874 2 0 15:22 ? 00:00:00 [nfsd4_callbacks]
root 1890 2 0 15:22 ? 00:00:00 [nfsd]
root 1891 2 0 15:22 ? 00:00:00 [nfsd]
root 1892 2 0 15:22 ? 00:00:00 [nfsd]
root 1893 2 0 15:22 ? 00:00:00 [nfsd]
root 1894 2 0 15:22 ? 00:00:00 [nfsd]
root 1895 2 0 15:22 ? 00:00:00 [nfsd]
root 1896 2 0 15:22 ? 00:00:00 [nfsd]
root 1897 2 0 15:22 ? 00:00:00 [nfsd]

1.8 深入NFS的方向

本文仅简单介绍了一些NFS的基本使用方法,但NFS自身其实是很复杂的,想深入也不是一件简单的事。例如,以下列出了几个NFS在实现上应该要解决的问题。

(1).多台客户端挂载同一个导出的目录后,要同时编辑其中同一个文件时,应该如何处理?这是共享文件更新问题,通用的解决方法是使用文件锁。

(2).客户端上对文件内容做出修改后是否要立即同步到服务端上?这是共享文件的数据缓存问题,体现的方式是文件数据是否要在各客户端上保证一致性。和第一个问题结合起来,就是分布式(集群)文件数据一致性问题。

(3).客户端或服务端进行了重启,或者它们出现了故障,亦或者它们之间的网络出现故障后,它们的对端如何知道它已经出现了故障?这是故障通知或重启通知问题。

(4).出现故障后,正常重启成功了,那么如何恢复到故障前状态?这是故障恢复问题。

(5).如果服务端故障后一直无法恢复,客户端是否能自动故障转移到另一台正常工作的NFS服务节点?这是高可用问题。(NFS版本4(后文将简写为NFSv4)可以从自身实现故障转移,当然使用高可用工具如heartbeat也一样能实现)

总结起来就几个关键词:锁、缓存、数据和缓存一致性、通知和故障恢复。从这些关键字中,很自然地会联想到了集群和分布式文件系统,其实NFS也是一种简易的分布式文件系统,但没有像集群或分布式文件系统那样实现几乎完美的锁、缓存一致性等功能。而且NFSv4为了体现其特点和性能,在一些通用问题上采用了与集群、分布式文件系统不同的方式,如使用了文件委托(服务端将文件委托给客户端,由此实现类似锁的功能)、锁或委托的租约等(就像DHCP的IP租约一样,在租约期内,锁和委托以及缓存是有效的,租约过期后这些内容都无效)。

由此知,深入NFS其实就是在深入分布式文件系统,由于网上对NFS深入介绍的文章几乎没有,所以想深入它并非一件简单的事。如果有深入学习的想法,可以阅读NFSv4的RFC3530文档的前9章。以下是本人的一些man文档翻译。

 

翻译:man rpcbind(rpcbind中文手册)
翻译:man nfsd(rpc.nfsd中文手册)
翻译:man mountd(rpc.mountd中文手册)
翻译:man statd(rpc.statd中文手册)
翻译:man sm-notify(sm-notify命令中文手册)
翻译:man exportfs(exportfs命令中文手册)

以下是man nfs中关于传输方法和缓存相关内容的翻译。

TRANSPORT METHODS
       NFS客户端是通过RPC向NFS服务端发送请求的。RPC客户端会自动发现远程服务端点,处理每请求(per-request)的
       身份验证,调整当客户端和服务端之间出现不同字节字节序(byte endianness)时的请求参数,并且当请求在网络
       上丢失或被服务端丢弃时重传请求。rpc请求和响应数据包是通过网络传输的。

       在大多数情形下,mount(8)命令、NFS客户端和NFS服务端可以为挂载点自动协商合适的传输方式以及数据传输时
       的大小。但在某些情况下,需要使用mount选项显式指定这些设置。

       对于的传统NFS,NFS客户端只使用UDP传输请求给服务端。尽管实现方式很简单,但基于UDP的NFS有许多限制,在
       一些通用部署环境下,这些限制项会限制平滑运行的能力,还会限制性能。即使是UDP丢包率极小的情况,也将
       导致整个NFS请求丢失;因此,重传的超时时间一般都是亚秒级的,这样可以让客户端从请求丢失中快速恢复,但
       即使如此,这可能会导致无关的网络阻塞以及服务端负载加重。

       但是在专门设置了网络MTU值是相对于NFS的输出传输大小时(例如在网络环境下启用了巨型以太网帧)(注:相对的
       意思,例如它们成比例关系),UDP是非常高效的。在这种环境下,建议修剪rsize和wsize,以便让每个NFS的读或
       写请求都能容纳在几个网络帧(甚至单个帧)中。这会降低由于单个MTU大小的网络帧丢失而导致整个读或写请求丢
       失的概率。

       (译者注:UDP是NFSv2和NFSv3所支持的,NFSv4使用TCP,所以以上两段不用考虑)

       现代NFS都默认采用TCP传输协议。在几乎所有可想到的网络环境下,TCP都表现良好,且提供了非常好的保证,防
       止因为网络不可靠而引起数据损坏。但使用TCP传输协议,基本上都会考虑设置相关防火墙。

       在正常环境下,网络丢包的频率比NFS服务丢包的频率要高的多。因此,没有必要为基于TCP的NFS设置极短的重传
       超时时间。一般基于TCP的NFS的超时时间设置在1分钟和10分钟之间。当客户端耗尽了重传次数(选项retrans的值),
       它将假定发生了网络分裂,并尝试以新的套接字重新连接服务端。由于TCP自身使得网络传输的数据是可靠的,所
       以,可以安全地使用处在默认值和客户端服务端同时支持的最大值之间的rszie和wsize,而不再依赖于网络MTU大小。

DATA AND METADATA COHERENCE
       现在有些集群文件系统为客户端之间提供了非常完美的缓存一致性功能,但对于NFS客户端来说,实现完美的缓
       存一致性是非常昂贵的,特别是大型局域网络环境。因此,NFS提供了稍微薄弱一点的缓存一致性功能,以满足
       大多数文件共享需求。

   Close-to-open cache consistency
       一般情况下,文件共享是完全序列化的。首先客户端A打开一个文件,写入一些数据,然后关闭文件然后客户端B
       打开同一个文件,并读取到这些修改后的数据。

       当应用程序打开一个存储在NFSv3服务端上的文件时,NFS客户端检查文件在服务端上是否存在,并通过是否发送
       GETATTR或ACCESS请求判断文件是否允许被打开。NFS客户端发送这些请求时,不会考虑已缓存文件属性是否是新
       鲜有效的。

       当应用程序关闭文件,NFS客户端立即将已做的修改写入到文件中,以便下一个打开者可以看到所做的改变。这
       也给了NFS客户端一个机会,使得它可以通过文件关闭时的返回状态码向应用程序报告错误。

       在打开文件时以及关闭文件刷入数据时的检查行为被称为close-to-open缓存一致性,或简称为CTO。可以通过使
       用nocto选项来禁用整个挂载点的CTO。

       (译者注:NFS关闭文件时,客户端会将所做的修改刷入到文件中,然后发送GETATTR请求以确保该文件的属性缓存
       已被更新。之后其他的打开者打开文件时会发送GETATTR请求,根据文件的属性缓存可以判断文件是否被打开并做
       了修改。这可以避免缓存无效)

   Weak cache consistency
       客户端的数据缓存仍有几乎包含过期数据。NFSv3协议引入了"weak cache consistency"(WCC),它提供了一种在单
       个文件被请求之前和之后有效地检查文件属性的方式。这有助于客户端识别出由其他客户端对此文件做出的改变。

       当某客户端使用了并发操作,使得同一文件在同一时间做出了多次更新(例如,后台异步写入),它仍将难以判断
       是该客户端的更新操作修改了此文件还是其他客户端的更新操作修改了文件。

   Attribute caching
       使用noac挂载选项可以让多客户端之间实现属性缓存一致性。几乎每个文件系统的操作都会检查文件的属性信息。
       客户端自身会保留属性缓存一段时间以减少网络和服务端的负载。当noac生效时,客户端的文件属性缓存就会被
       禁用,因此每个会检查文件属性的操作都被强制返回到服务端上来操作文件,这表示客户端以牺牲网络资源为代
       价来快速查看文件发生的变化。

       不要混淆noac选项和"no data caching"。noac挂载选项阻止客户端缓存文件的元数据,但仍然可能会缓存非元数
       据的其他数据。

       NFS协议设计的目的不是为了支持真正完美的集群文件系统缓存一致性。如果要达到客户端之间缓存数据的绝对
       一致,那么应该使用文件锁的方式。

   File timestamp maintainence
       NFS服务端负责管理文件和目录的时间戳(atime,ctime,mtime)。当服务端文件被访问或被更新,文件的时间戳也会
       像本地文件系统那样改变。

       NFS客户端缓存的文件属性中包括了时间戳属性。当NFS客户端检索NFS服务端文件属性时,客户端文件的时间戳会
       更新。因此,在NFS服务端的时间戳更新后显示在NFS客户端之前可能会有一些延迟。

       为了遵守POSIX文件系统标准,Linux NFS客户端需要依赖于NFS服务端来保持文件的mtime和ctime时间戳最新状态。
       实现方式是先让客户端将改变的数据刷入到服务端,然后再输出文件的mtime。

       然而,Linux客户端可以很轻松地处理atime的更新。NFS客户端可以通过缓存数据来保持良好的性能,但这意味着
       客户端应用程序读取文件(会更新atime)时,不会反映到服务端,但实际上服务端的atime已经修改了。

       由于文件属性缓存行为,Linux NFS客户端mount时不支持一般的atime相关的挂载选项。

       特别是mount时指定了atime/noatime,diratime/nodiratime,relatime/norelatime以及strictatime/nostrictatime
       挂载选项,实际上它们没有任何效果。

   Directory entry caching
       Linux NFS客户端缓存所有NFS LOOKUP请求的结果。如果所请求目录项在服务端上存在,则查询的结果称为正查询
       结果。如果请求的目录在服务端上不存在(服务端将返回ENOENT),则查询的结果称为负查询结果。

       为了探测目录项是否添加到NFS服务端或从其上移除了,Linux NFS客户端会监控目录的mtime。如果客户端监测到
       目录的mtime发生了改变,客户端将丢弃该目录相关的所有LOOKUP缓存结果。由于目录的mtime是一种缓存属性,因
       此服务端目录mtime发生改变后,客户端可能需要等一段时间才能监测到它的改变。

       缓存目录提高了不与其他客户端上的应用程序共享文件的应用程序的性能。但使用目录缓存可能会干扰在多个客户
       端上同时运行的应用程序,并且需要快速检测文件的创建或删除。lookupcache挂载选项允许对目录缓存行为进行一
       些调整。

       如果客户端禁用目录缓存,则每次LOOKUP操作都需要与服务端进行验证,那么该客户端可以立即探测到其他客户端
       创建或删除的目录。可以使用lookupcache=none来禁用目录缓存。如果禁用了目录缓存,由于需要额外的NFS请求,
       这会损失一些性能,但禁用目录缓存比使用noac损失的性能要少,且对NFS客户端缓存文件属性没有任何影响。

   The sync mount option
       NFS客户端对待sync挂载选项的方式和挂载其他文件系统不同。如果即不指定sync也不指定async,则默认为async。
       async表示异步写入,除了发生下面几种特殊情况,NFS客户端会延迟发送写操作到服务端:

              ● 内存压力迫使回收系统内存资源。
              ● 客户端应用程序显式使用了sync类的系统调用,如sync(2),msync(2)或fsync(3)。
              ● 关闭文件时。
              ● 文件被锁/解锁。

       换句话说,在正常环境下,应用程序写的数据不会立即保存到服务端。(当然,关闭文件时是立即同步的)

       如果在挂载点上指定sync选项,任何将数据写入挂载点上文件的系统调用都会先把数据刷到服务端上,然后系统调
       用才把控制权返回给用户空间。这提供了客户端之间更好的数据缓存一致性,但消耗了大量性能。

       在未使用sync挂载选项时,应用程序可以使用O_SYNC修饰符强制立即把单个文件的数据刷入到服务端。

   Using file locks with NFS
       网络锁管理器(Network Lock Manager,NLM)协议是一个独立的协议,用于管理NFSv2和NFSv3的文件锁。为了让客户端
       或服务端在重启后能恢复锁,需要使用另一个网络状态管理器(Network Status Manager,NSM)协议。在NFSv4中,NFS
       直协议自身接支持文件锁相关功能,所以NLM和NSM就不再使用了。

       在大多数情况下,NLM和NSM服务是自动启动的,并且不需要额外的任何配置。但需要配置NFS客户端使用的是fqdn名
       称,以保证NFS服务端可以找到客户端并通知它们服务端的重启动作。

       NLS仅支持advisory文件锁。要锁定NFS文件,可以使用待F_GETLK和F_SETLK的fcntl(2)命令。NFS客户端会转换通过
       flock(2)获取到的锁为advisory文件锁。

       当服务端不支持NLM协议,或者当NFS服务端是通过防火墙但阻塞了NLM服务端口时,则需要指定nolock挂载选项。
       当客户端挂载导出的/var目录时,必须使用nolock禁用NLM锁,因为/var目录中包含了NLM锁相关的信息。
       (注,因为NLM仅在nfsv2和nfsv3中支持,所以NFSv4不支持nolock选项)

       当仅有一个客户端时,使用nolock选项可以提高一定的性能。

   NFS version 4 caching features
       NFSv4上的数据和元数据缓存行为和之前的版本相似。但是NFSv4添加了两种特性来提升缓存行为:change attributes
       以及delegation。(注:nfsv4中取消了weak cache consistency)

       change attribute是一种新的被跟踪的文件/目录元数据信息。它替代了使用文件mtime和ctime作为客户端验证缓存内
       容的方式。但注意,change attributes和客户端/服务端文件的时间戳的改变无关。

       文件委托(file delegation)是NFSv4的客户端和NFSv4服务端之前的一种合约,它允许客户端临时处理文件,就像没有
       其他客户端正在访问该文件一样。当有其他客户端尝试访问被委托文件时,服务端一定会通知服务端(通过callback请
       求)。一旦文件被委托给某客户端,客户端可以尽可能大地缓存该文件的数据和元数据,而不需要联系服务端。

       文件委托有两种方式:read和write。读委托意味着当其他客户端尝试向委托文件写入数据时,服务端通知客户端。而
       写委托意味着其他客户端无论是尝试读还是写,服务端都会通知客户端。

       NFSv4上当文件被打开的时候,服务端会授权文件委托,并且当其他客户端想要访问该文件但和已授权的委托冲突时,
       服务端可以在任意时间点重调(recall)委托关系。不支持对目录的委托。
       (译者注:只有读委托和读委托不会冲突)

       为了支持委托回调(delegation callback),在客户端初始联系服务端时,服务端会检查网络并返回路径给客户端。如果
       和客户端的联系无法建立,服务端将不会授权任何委托给客户端。

 

回到系列文章大纲:

 [root@iZbp1a7wyzv7b3ujsfphj2Z nfsdir]# netstat -lntp

转载请注明出处:

[root@localhost ~]# netstat -lntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1/systemd
tcp 0 0 0.0.0.0:20048 0.0.0.0:* LISTEN 1783/rpc.mountd
tcp 0 0 0.0.0.0:34099 0.0.0.0:* LISTEN -
tcp 0 0 192.168.122.1:53 0.0.0.0:* LISTEN 2263/dnsmasq
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1344/sshd
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 841/cupsd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 2041/master
tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:40037 0.0.0.0:* LISTEN 1216/rpc.statd
tcp6 0 0 :::60943 :::* LISTEN 1216/rpc.statd
tcp6 0 0 :::111 :::* LISTEN 1/systemd
tcp6 0 0 :::20048 :::* LISTEN 1783/rpc.mountd
tcp6 0 0 :::22 :::* LISTEN 1344/sshd
tcp6 0 0 ::1:631 :::* LISTEN 841/cupsd
tcp6 0 0 ::1:25 :::* LISTEN 2041/master
tcp6 0 0 :::40826 :::* LISTEN -
tcp6 0 0 :::2049 :::* LISTEN -

注:若您觉得这篇文章还不错请点击下右下角的推荐,有了您的支持才能激发作者更大的写作热情,非常感谢!

NFS基本应用,第3章NFS应用 本文目录: 1.1 概述 1.2 RPC不可不知的原理 1.2.1 RPC原理 1.2.2 RCP工具介绍 1.3 启动NFS 1.4 配置导出目录和挂载...

 rpc的服务也跟着带起来:

[root@localhost ~]# ps -aux|grep rpc
root 397 0.0 0.0 0 0 ? S< 15:22 0:00 [rpciod]
root 540 0.0 0.0 17148 392 ? Ss 15:22 0:00 /usr/sbin/rpc.idmapd
rpcuser 1216 0.0 0.0 44448 1824 ? Ss 15:22 0:00 /usr/sbin/rpc.statd
rpc 1695 0.0 0.0 64948 1436 ? Ss 15:22 0:00 /sbin/rpcbind -w
root 1783 0.0 0.1 42992 2124 ? Ss 15:22 0:00 /usr/sbin/rpc.mountd
root 4011 0.0 0.0 112668 972 pts/0 R 15:42 0:00 grep --color=auto rpc

开机自启动:

[root@localhost nfsdir]# systemctl enable rpcbind
[root@localhost  nfsdir]# systemctl enable nfs
Created symlink from /etc/systemd/system/multi-user.target.wants/nfs-server.service to /usr/lib/systemd/system/nfs-server.service.

 准备共享的文件夹

root@localhost nfsdir]# chmod 777 /nfs/nfsdir

最关键的就是修改nfs的配置文件:

[root@localhost ~]# cat /etc/exports
/nfs/nfsdir 172.31.1.0/24(rw,sync,no_澳门新浦京娱乐场网站,root_squash)

相关参数:

rw 读写
ro 只读
sync 同步模式,内存数据实时写入磁盘  速度很快但是会降低磁盘效率
async 非同步模式 能保证磁盘效率  但是如果服务器断电,会造成数据丢失
no_root_squash 客户端挂载NFS共享目录后,root用户不受约束,权限很大
root_澳门新浦京娱乐场网站:statd汉语手册,NFS基本使用。squash 与上面选项相对,客户端上的root用户收到约束,被限定成某个普通用户
all_squash 客户端上所有用户在使用NFS共享目录时都被限定为一个普通用户
anonuid/anongid 和上面几个选项搭配使用,定义被限定用户的uid和gid

 

2.NFS服务器端的配置:

[root@localhost~]# yum install nfs-utils
[root@localhost~]# systemctl start rpcbind
[root@localhost~]# systemctl status rpcbind
rpcbind.service - RPC bind service
Loaded: loaded (/usr/lib/systemd/system/rpcbind.service; indirect; vendor preset: enabled)
Active: active (running) since 四 2017-11-16 13:24:06 CST; 5s ago

[root@localhost python_practice]# showmount -e 172.31.1.135

clnt_create: RPC: Port mapper failure - Unable to receive: errno 113 (No route to host)
这是因为开启了防火墙
[root@localhost python_practice]# systemctl status firewalld
firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
Active: active (running) since 二 2017-09-26 21:42:06 CST; 1 months 20 days ago
root@localhost python_practice]# systemctl stop firewalld
需要关闭两边的防火墙和getenforce
[root@localhost python_practice]# getenforce
Enforcing
[澳门新浦京娱乐场网站:statd汉语手册,NFS基本使用。root@localhost python_practice]# setenforce 0
[root@localhost python_practice]# getenforce
Permissive

[root@localhost python_practice]# showmount -e 172.131.1.135
clnt_create: RPC: Port mapper failure - Timed out
原因是2台机器都叫默认名localhost.localhost
修改2台服务器的名:
[root@localhost ~]# hostnamectl set-hostname "centos7-137"
另外一台是类似的命令

再进行查看:

oot@localhost nfsdir]# showmount -e 172.31.1.135
Export list for 172.31.1.135:
/nfs/nfsdir 172.31.1.0/24

最关键的是这一步:
[root@localhost nfsdir]# mount -t nfs 172.31.1.135:/nfs/nfsdir /pubdir/nfsdir

其中/nfs/nfsdir是135准备共享的目录,/pubdir/nfsdir是137上对应查看的目录
[root@localhost nfsdir]# df -h
文件系统 容量 已用 可用 已用% 挂载点
/dev/sda3 38G 5.9G 32G 16% /
devtmpfs 898M 0 898M 0% /dev
tmpfs 912M 0 912M 0% /dev/shm
tmpfs 912M 9.0M 903M 1% /run
tmpfs 912M 0 912M 0% /sys/fs/cgroup
/dev/sda1 197M 156M 41M 80% /boot
tmpfs 183M 24K 183M 1% /run/user/0
/dev/sr0 4.1G 4.1G 0 100% /run/media/root/CentOS 7 x86_64
172.31.1.135:/nfs/nfsdir 38G 13G 25G 35% /pubdir/nfsdir

测试:

在135上新建一个文件:

[root@localhost nfsdir]# touch kingleoric.txt
[root@localhost nfsdir]# pwd
/nfs/nfsdir

在137上查看该文件已生成:

[root@localhost nfsdir]# cd /pubdir/nfsdir
[root@localhost nfsdir]# ls
kingleoric.txt

 

本文由澳门新浦京娱乐场网站发布于澳门新浦京娱乐场网站,转载请注明出处:澳门新浦京娱乐场网站:statd汉语手册,NFS基本使