在企业集群架构的工做场景中,NFS网络文件系统通常被用来存储共享视频,图片,附件等静态资源文件,一般网站用户上传的文件都会放到NFS共享里,例如:BBS产品的图片,附件,头像(注意网站BBS程序不要放NFS共享里),而后前端全部的节点访问这些静态资源时都会读取NFS存储上的资源。NFS是当前互联网系统架构中最经常使用的数据存储服务之一,前面说过,中小型网站公司应用频率更高,大公司或门户除了使用NFS外,还可能会使用更为复杂的分布式文件系统,好比Moosefs(mfs),GlusterFS,FastDFS等css
在企业生产集群架构中,NFS做为全部前端Web服务的共享存储,存储的内容通常包括网站用户上传的图片,附件,头像等,注意,网站的程序代码不要放NFS共享里,由于网站程序是开发运维人员统一发布的,不存在发布延迟问题,直接批量发布到Web节点提供访问比共享到NFS里访问效率更高。前端
这里经过图解给你们展现如下集群架构须要共享存储服务的理由。例如:A用户上传图片到Web1服务器,而后让B用户访问这张图片,结果B用户访问的请求分发到了Web2,由于Web2上没有这张图片,这就致使它没法看到A用户上传的图片,若是此时有一个共享存储,A用户上传图片的请求不管是分发到Web1仍是Web2上,最终都会存储到共享存储上,而在B用户访问图片时,不管请求分发到Web1仍是Web2上,最终也都会去共享存储上找,这样就能够访问到须要的资源了。这个共享存储的位置能够经过开源软件和商业硬件实现,互联网中小型集群架构会用普通PC服务器配置NFS网络文件系统实现。node
当及集群中没有NFS共享存储时,用户访问图片的状况以下图所示。linux
上图是企业生产集群没有NFS共享存储访问的示意图。下图是企业生产集群有NFS共享存储的状况ios
当访问程序经过NFS客户端向NFS服务端存取文件时,其请求数据流程大体以下:vim
- 首先用户访问网站程序,由程序在NFS客户端上发出存取NFS文件的请求,这时NFS客户端(即执行程序的服务器)的RPC服务(rpcbind服务)就会经过网络向NFS服务器端的RPC服务(rpcbind服务)的111端口发出NFS文件存取功能的询问请求。
- NFS服务端的RPC服务(rpcbind服务)找到对应的已注册的NFS端口后,通知NFS客户端的RPC服务(rpcbind服务)
- 此时NFS客户端获取到正确的端口,并与NFS daemon联机存取数据
- NFS客户端把数据存取成功后,返回给前端访问程序,告知给用户存取结果,做为网站用户,就完成了一次存取操做。
- 由于NFS的各项功能都须要向RPC服务(rpcbind服务)注册,因此只有RPC服务(rpcbind服务)才能获取到NFS服务的各项功能对应的端口号(port number),PID,NFS在主机所监听的IP等信息,而NFS客户端也只能经过向RPC服务(rpcbind服务)询问才能找到正确的端口。也就是说,NFS须要有RPC服务(rpcbind服务)的协助才能成功对外提供服务。从上面的描述,咱们不难推断,不管是NFS客户端仍是NFS服务器端,当要使用NFS时,都须要首先启动RPC服务(rpcbind服务),NFS服务必须在RPC服务启动以后启动,客户端无需启动NFS服务,但须要启动RPC服务。
注意: NFS的RPC服务,在CentOS5.X下名称为portmap,在CentOS6.x下名称为rpcbind
windows
- nfs-utils: NFS服务的主程序,包括rpc.nfsd,rpc.mountd这两个daemons和相关文档说明,以及执行命令文件等。
- rpcbind: CentOS6.X下面RPC的主程序。NFS能够视为一个RPC程序,在启动任何一个RPC程序以前,须要作好端口和功能的对应映射工做,这个映射工做就是由rpcbind服务来完成的。所以,在提供NFS服务以前必须先启动rpcbind服务才行。
exports
配置文件相关参数应用领域的详细解释 (NFS精华重点)
详细说明:centos
- rw或者ro,主要控制的是全部客户端用户(包含root)的读写权限。若是设置成ro,就算root也只有读权限。它是NFS权限设置的第一道总闸阀门。
- sync:同步传输,实时进行。
- async:异步传输:攒一会在传输。
root_squash
:将root帐户在共享目录里的身份下降为匿名者(默认nfsnobody)身份no_root_squash
:不下降root帐户在共享目录的身份,身份仍是rootall_squash
:将全部访问用户在共享目录里的身份都下降为匿名者(默认nfsnobody)身份详细说明:缓存
- 匿名者身份默认状况下就是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客户端的任何访问用户均可以对共享目录里的任何文件进行查看,修改,删除操做
这两个参数主要用来修改NFS默认的虚拟帐户nfsnobody。能够经过指定虚拟帐户的uid和gid的方式修改默认的虚拟帐户的帐户名称和所属组。
服务端
与客户端
都安装nfs-utils
和rpcbind
两个安装包[root@root ~]# yum -y install nfs-utils rpcbind
NFS
服务端配置文件路径NFS服务的默认配置文件路径为:
/etc/exports
,而且默认是空的
解析:
(ro):只可看,不能写
NFS
未启动状态下的rpcinfo
NFS
启动状态下的rpcinfo
注:
nfsnobody
为NFS
的程序用户
/etc/ssh/sshd_config
[root@yangwenbo /]# vim /etc/ssh/sshd_config
nfs-utils
和rpcbind
两个安装包问题:
(1)NFS客户端挂载后,往共享目录写入数据时卡住了
(2)NFS服务端,重启restart服务,客户端若是写入数据卡住了。
解答:
1.nfs
服务端重启以后,共享文件夹进入grace time
(无敌时间)
2.客户端在服务端重启后写入数据大概要等90秒
3.nfs
配置文件:/etc/sysconfig/nfs
在NFS服务端能够经过cat /var/lib/nfs/etab 查看服务端配置参数的细节。在NFS客户端能够经过cat /proc/mounts查看mount的挂载参数细节。
经过以下命令在NFS客户端测试挂载获取的默认挂载参数:
NFS Client mount
挂载参数列表
mount -o
参数对应的选项:|参数|参数意义|系统默认值|
提问:在企业生产环境中,NFS客户端挂载有没有必需要加的参数,好比,加noexec,nosuid,nodev,bg,soft,rsize,wsize等参数。
解答:这个问题属于mount挂载优化内容(有些参数也适合其余文件系统),通常来讲要适当加挂载参数,可是,最好是先作好测试,用数据来讲话,才能更好的肯定究竟是挂载仍是不挂载。
在企业工做场景,通常来讲,NFS服务器共享的只是普通静态数据(图片,附件,视频),不须要执行suid,exec等权限,挂载的这个文件系统只能做为数据存取之用,没法执行程序,对于客户端来说增长了安全性,例如:不少木马篡改站点文件都是由上传入口上传的程序到存储目录,而后执行的。
所以在挂载的时候,用下面的命令颇有必要:mount -t nfs -o nosuid,noexec,nodev,rw 172.16.1.31:/data /mnt
mount
挂载性能优化参数选项下面介绍几个在企业生产环境下,NFS性能优化挂载的例子
mount -t nfs -o noatime,nodiratime 172.16.1.31:/data /mnt
mount -t nfs -o nosuid,noexec,nodev,noatime,nodiratime,intr,rsize=131072,wsize=131072 172.16.1.31:/data /mnt
mount -t nfs 172.16.1.31:/data /mnt
mount /dev/sdb1 /mnt -o defaults,async,noatime,data=writeback,barrier=0
注意:若是本地文件系统挂载时,若是加入
nodiratime
会报错
mount -t nfs -o noatime,nodiratime,nosuid,noexec,nodev,rsize=131072 172.16.1.31:/data /mnt
mount -t nfs 172.16.1.31:/data /mnt
注意:非性能的参数越多,速度可能会变慢
下面是优化选项说明:
- /proc/sys/net/core/rmem_default:该文件指定了接收套接字缓冲区大小的默认值(以字节为单位),默认设置:124928 建议:8388608
- /proc/sys/net/core/rmem_max:该文件指定了接收套接字缓冲区大小的最大值(以字节为单位) 建议:16777216
- /proc/sys/net/core/wmem_default:该文件指定了发送套接字缓冲区大小的默认值(以字节为单位),默认设置:124928 建议:8388608
- /proc/sys/net/core/wmem_max:该文件指定了发送套接字缓冲区大小的最大值(以字节为单位)。默认设置:124928. 建议:16777216
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或缓存服务器提供服务,若是没有缓存服务或架构很差,存储服务器数量再多也是扛不住压力的,并且用户体验会不好。
NFS客户端实现fstab开机自启动挂载
现象:在/etc/fstab中配置了nfs开机自动挂载,结果没法开机自动挂载nfs
解答:
1.nfs客户端挂载命令放在/etc/rc.local
实现自动挂载
2.开机自启动netfs服务,而后才能实现fstab的开机自动挂载nfs文件系统(linux开机时在加载网络以前就会加载/etc/fstab)
mount -o remount,rw/
的意思是将整个根目录已可读可写rw的方式从新挂载一边remount