NFS网络文件系统

NFS网络文件系统

NFS是Network File System的缩写，中文意思是网络文件系统。它的主要功能是通过网络（一般是局域网）让不同的主机系统之间可以共享文件或目录。NFS客户端（一般为应用服务器，例如web）可以通过挂载（mount）的方式将NFS服务器端共享的数据目录挂载到NFS客户端本地系统中（就是某一个挂载点下）。从客户端本地看，NFS服务器端共享的目录就好像是客户端自己的磁盘分区或者目录一样，而实际上却是远端的NFS服务器的目录。
NFS在企业中的应用场景

NFS系统原理介绍

### NFS server端的设置
nfs-utils:
NFS服务的主程序，包括rpc.nfsd,rpc.mountd这两个daemons和相关文档说明，以及执行命令文件等。
rpcbind:
CentOS6.X下面RPC的主程序。NFS可以视为一个RPC程序，在启动任何一个RPC程序之前，需要做好端口和功能的对应映射工作，这个映射工作就是由rpcbind服务来完成的。因此，在提供NFS服务之前必须先启动rpcbind服务才行。
本地NFS数据同步

1.安装下面的软件包

2.启动rpcbind

3.启动NFS服务

3.NFS服务的默认配置文件路径为：/etc/exports，并且编写

4.给共享目录更改属组属主为nfsnobody

5.进行本地挂载测试

6.进行文件写入测试

实战配置NFS客户端配置过程-web01

1.客户端必须安装nfs-utils软件

2. 检查远端showmount

3.客户端挂载

4.进行文件读写及同步测试

配置开机自动挂载nfs共享目录（/etc/fstab）
配置客户端mount挂载命令使挂载开机自动执行，这里有两种方法，如下：
第一种方法：将挂载命令放在/etc/rc.local里
缺点：偶尔开机挂载不上，工作中除了开机自启动配置，还要对是否挂载做监控
echo “mount -t nfs 172.16.1.31:/data /mnt”
第二种方法，将挂载命令放在/etc/fstab里
[root@web01 ~]# tail -1 /etc/fstab
172.16.1.31:/data /mnt nfs defaults 0 0
其实所谓配置方法，这里有一个误区，如下：
fstab会优先于网络被Linux系统加载。网络没启动时执行fstab会导致连不上NFS服务器端，无法实现开机挂载。而且，即使是本地的文件系统，也要注意，fstab最后两列要设置0 0，否则有可能导致无法启动服务器的问题。
因此，nfs网络文件系统最好不要放到fstab里实现开机挂载。
但是，如果是在开机自启动服务里设置并启动了netfs服务，放入fstab里也是可以开机挂载的。
例如：
[root@web01 ~]# chkconfig --list netfs
netfs 0:关闭 1:关闭 2:关闭 3:关闭 4:关闭 5:关闭 6:关闭
[root@web01 ~]# chkconfig netfs on
[root@web01 ~]# chkconfig --list netfs
netfs 0:关闭 1:关闭 2:启用 3:启用 4:启用 5:启用 6:关闭
如此一来，我们也可以通过fstab进行开机挂载了nfs网络文件系统了
客户端系写入的都是程序用户（属组，属主）
exports配置文件相关参数应用领域的详细解释 （NFS精华重点）
1）（rw,sync） :可读可写，同步传输
2）（ro,async）:只读，异步传输。
详细说明：
rw或者ro，主要控制的是所有客户端用户（包含root）的读写权限。如果设置成ro，就算root也只有读权限。它是NFS权限设置的第一道总闸阀门。
sync：同步传输，实时进行。
async:异步传输：攒一会在传输。

详细说明：

匿名者身份默认情况下就是NFS服务器端的虚拟账户角色，也就是nfsnobody。这是最低的身份，所有NFS客户端共享目录的访问者都被附加了这个身份，这也就意味者，如果文件的属主属组是nfsnobody的话，所有访问者对该文件都拥有全部所有权。
所谓身份并不是访问权限，而是用户在共享目录里创建的文件的属主和属组。
一旦身份被降低那么在共享目录里创建的文件的属主和属组就是变成了默认情况下的nfsnobody。这也就意味着，权限系统对你所创建的文件不做任何保护（任何访问者都可以查看，修改，删除）

所谓root_squash:

使用这个参数意味着root在共享目录里创建的任何文件都不受保护，任何人（所有用户）都可以读取，修改，删除)。
而非root用户则不降低权限，在共享目录里创建的文件的属主和属组统一为nobody（身份隐藏了），这种情况下，所有普通用户之间只能互相查看文件，并不能任意修改和删除并且你还无法知道是谁创建的文件，每个普通用户只能修改或删除自己创建的文件。
root用户虽然被降低了身份，但是并没有降低他的管理者权限，也就是说它仍旧能对所有共享目录里的所有文件进行查看，修改，删除操作。
如果这类参数默认为空的话，那么NFS将默认使用这个参数。
所谓no_root_squash:
使用这个参数意味着不对root进行降低身份的操作，也就是说root在共享目录里创建的文件的属主属组仍旧为root（不能被普通用户修改和删除）。
非root用户同root_squash一样，并不降低权限。

所谓all_squash:

使用这个参数意味着对所有访问NFS共享目录的用户进行降低身份的操作。也就是说，所有用户只要在共享目录里创建文件，那么文件的属主属组就是默认情况下的nfsnobody。
在这个模式下，任何nfs客户端的任何访问用户都可以对共享目录里的任何文件进行查看，修改，删除操作

anonuid和anongid：指定NFS虚拟账户的uid或gid

这两个参数主要用来修改NFS默认的虚拟账户nfsnobody。可以通过指定虚拟账户的uid和gid的方式修改默认的虚拟账户的账户名称和所属组。
NFS系统应用的优缺点说明
NFS服务可以让不同的客户端挂载使用同一个共享目录，也就是将其作为共享存储使用，这样可以保证不同节点客户端数据的一致性，在集群架构环境中经常会用到。如果是windows和Linux混合环境的集群系统，可以用samba来实现。
优点：
简单，容易上手，容易掌握
NFS 文件系统内数据是在文件系统之上的，即数据是能看得见的。
部署快速，维护简单方便，且可控，满足需求的就是最好的。
可靠，从软件层面上看，数据可靠性高，经久耐用。数据是在文件系统之上的。
服务非常稳定
局限：
存在单点故障，如果NFS Server宕机了，所有客户端都不能访问共享目录。这个需要负载均衡及高可用来弥补
在大数据高并发的场合，NFS效率，性能有限（2千万/日以下PV(page view)的网站不是瓶颈，除非网站架构设计太差。）
客户端认证是基于IP和主机名的，权限要根据ID识别，安全性一般（用于内网则问题不大）。
NFS数据是明文的，NFS本身不对数据完整性做验证。
多台客户机器挂载一个NFS服务器时，连接管理维护麻烦（耦合度高）。尤其NFS服务端出问题后，所有NFS客户端都处于挂掉状态（测试环境可使用autofs自动挂载解决，正式环境可修复NFS服务或强制卸载）
涉及了同步（实时等待）和异步（解耦）的概念，NFS服务端和客户端相对来说就是耦合度有些高。网站程序也是一样，尽量不要耦合度太高，系统及程序架构师的重要职责就是为程序及架构解耦，让网站的扩展性变得更好。
应用建议：
大中小型网站（参考点2000万/日PV以下）线上应用，都有用武之地。门户站也会有应用，生产场景应该多把数据的访问往前推，即尽量把静态存储里的资源通过CDN或缓存服务器提供服务，如果没有缓存服务或架构不好，存储服务器数量再多也是扛不住压力的，而且用户体验会很差。