标签:ie9 xom nfs共享 访问权限 数据 rfs fmb 文件相关 upnp
在企业集群架构的工作场景中,NFS网络文件系统一般被用来存储共享视频,图片,附件等静态资源文件,通常网站用户上传的文件都会放到NFS共享里,例如:BBS产品的图片,附件,头像(注意网站BBS程序不要放NFS共享里),然后前端所有的节点访问这些静态资源时都会读取NFS存储上的资源。NFS是当前互联网系统架构中最常用的数据存储服务之一,前面说过,中小型网站公司应用频率更高,大公司或门户除了使用NFS外,还可能会使用更为复杂的分布式文件系统,比如Moosefs(mfs),GlusterFS,FastDFS等
在企业生产集群架构中,NFS作为所有前端Web服务的共享存储,存储的内容一般包括网站用户上传的图片,附件,头像等,注意,网站的程序代码不要放NFS共享里,因为网站程序是开发运维人员统一发布的,不存在发布延迟问题,直接批量发布到Web节点提供访问比共享到NFS里访问效率更高。
这里通过图解给大家展示以下集群架构需要共享存储服务的理由。例如:A用户上传图片到Web1服务器,然后让B用户访问这张图片,结果B用户访问的请求分发到了Web2,因为Web2上没有这张图片,这就导致它无法看到A用户上传的图片,如果此时有一个共享存储,A用户上传图片的请求无论是分发到Web1还是Web2上,最终都会存储到共享存储上,而在B用户访问图片时,无论请求分发到Web1还是Web2上,最终也都会去共享存储上找,这样就可以访问到需要的资源了。这个共享存储的位置可以通过开源软件和商业硬件实现,互联网中小型集群架构会用普通PC服务器配置NFS网络文件系统实现。
当及集群中没有NFS共享存储时,用户访问图片的情况如下图所示。
上图是企业生产集群没有NFS共享存储访问的示意图。下图是企业生产集群有NFS共享存储的情况
当访问程序通过NFS客户端向NFS服务端存取文件时,其请求数据流程大致如下:
- 首先用户访问网站程序,由程序在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
- nfs-utils: NFS服务的主程序,包括rpc.nfsd,rpc.mountd这两个daemons和相关文档说明,以及执行命令文件等。
- rpcbind: CentOS6.X下面RPC的主程序。NFS可以视为一个RPC程序,在启动任何一个RPC程序之前,需要做好端口和功能的对应映射工作,这个映射工作就是由rpcbind服务来完成的。因此,在提供NFS服务之前必须先启动rpcbind服务才行。
exports
配置文件相关参数应用领域的详细解释 (NFS精华重点)
详细说明:
- 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
标签:ie9 xom nfs共享 访问权限 数据 rfs fmb 文件相关 upnp
原文地址:https://www.cnblogs.com/ywb123/p/11128977.html