【Linux服务器架设】存储服务器篇

第一章 搭建存储服务器-NFS
第二章 存储服务器构建原理(上)-NFS



前言

书承上回,上次写了一篇如何搭建“NFS”存储服务器,未具体刨析底层的原理,下面咱们好好探究一手,小伙伴们一起冲鸭!


一、NFS是什么?

这时有小伙伴问了,小涛小涛,这是我手机那个能刷卡那个东东吗?
不是哦,那个是NFC,NFS全称是Network File System,即网络文件系统,最大的功能呢,即通过网络的方式,让不同的机器,可以共享文件
而对于客户端来说,这个远程的主机目录,就好像自己的磁盘分区,在使用上,相当于远程插U盘
在这里插入图片描述
如同所示,当服务端配置共享的/data/share目录,那么客户端就可以把该目录挂载到任意位置,例如客户端1,当我进入/home/share目录时,即可查看到服务端的所以数据了(前提是权限要足够),进入后,可自由使用Linux指令,特别nice😁

二、RPC

那么问题来了,NFS是借助网络进行传输,那肯定需要占用一些端口,NFS这个服务的默认端口是2049,但文件系统本身很复杂,因此NFS还需要借助其他进程去启动其他端口。这样就造成一个尬尴的局面:随机取用一些未被使用且小于1024端口用于传输

可是,这可难为咱们的客户端了,我不知道你的端口,咋给你开通防火墙的白名单端口号呢?
别急,此时我们借助RPC协议(远程过程调用,Remote Procedure Call)进行辅助。

1.什么是RPC

RPC最主要的功能:指定每个NFS功能所对应的端口号,并且通知客户端,让客户端可以允许访问了。
![在这里插入图片描述](https://img-blog.csdnimg.cn/b94a54829cdd40089820078a61b1b0a9.png
RPC如何知道每个NFS的端口?
当服务器启动NFS时,会随机选取某个端口,并主动向RPC注册,因此RPC可以知道每个端口对于的NFS功能。
然后RPC是固定使用111端口来监听客户端的需求,并向客户端响应正确的端口,依次有了它,NFS的启动更为丝滑了。

注意:
1.在启动NFS前,必须先启动RPC,否则NFS无法向RPC注册。
2.当RPC重启后,原来注册是数据会消失。所以当RPC重启后,它管理的所有服务都需重新启动以向RPC注册。
3.所以,也可以称NFS为RPC server的一种。

如图所示,当客户端请求NFS文件时间,它是这么向服务端请求数据:
1.客户端向服务端RPC(111端口)发出NFS文件访问功能的查询要求
2.服务端找到对应且已注册的NFS端口后,通知给客户端
3.客户端了解正确的端口后,他们就能亲密连接了。
在这里插入图片描述

2.NFS启动RPC守护进程

上面那种图中,在服务端启动时,会有一个NFS守护进程,与之相对应的,RPC也有守护进程,下面咱们继续了解一下。
现在我们知道,NFS服务主要任务是进行文件系统共享,谈到共享,那也就离不开权限问题(安全)。所以,NFS服务器启动至少需2个以上守护进程,一个是管理客户端能否登录,另一个是管理客户端能获取那些权限。如何还想细化,还需要其他守护进程,下面由小涛一一阐述。

rpc.nfsd

管理客户端能否使用服务器文件系统挂载信息,如判断登录用户的ID

rpc.mountd

管理NFS文件系统。当客户端通过nfsd登录服务器后,使用文件系统前,需要经过文件权限的认证,即/etc/exports文件,通过这一关后客户端就可正常使用文件了。

rpc.lockd【非必要】

用于管理文件的锁定(lock)。
为什么需要它呢?
because,共享的NFS必然是多用户连接,那么当多个尝试写入某文件时,可能会对该文件造成一些问题,使用lock则可解决该问题,但lock在客户端和服务端都开启才行。

rpc.statd【非必要】

用于检查文件一致性,与lock,相互。
当客户端同时使用同一文件时,导致文件有所损坏,这是statd可以用来检测并尝试恢复该文件。
lock一样,在客户端和服务端都开启才行。

三、NFS文件访问权限

这时有小伙伴想问了:小涛,我在客户端1用aoao这个用户身份去访问/home/share这个来自NFS服务端提供的文件时,NFS服务端会让我们以什么身份访问呢?也是aoao还是其他角色吗?
小涛:为什么会这么提问呢?
小伙伴:我发现NFS本身的服务并没有进行用户身份验证,验证貌似是RPC干的
小涛:说得非常正确,当aoao想访问服务端的文件系统时,服务端会以客户用户的UID与GID的身份尝试读取
小伙伴:那客户端与服务端的用户身份不一致怎么办呢?
小涛:emm。。。咱们看图,这是NFS的客户端与服务端用户连接机制过程
在这里插入图片描述
小涛:当我们以aoao身份去访问服务端时,需注意,文件系统的inode所记录的属性为UID、GID,而非账号与属组名
小伙伴:哦哦,那就是Linux主机会去查看/etc/passwd、/etc/group进行查询对应的用户名等,所以当aoao进入该目录文件后,会参照NFS客户端1的用户名与组名是吧?
小涛:正确,但由于该目录的文件是来自服务端,所以会出现以下几种情况,咱们要具体问题具体分析。

1.服务端/客户端 都有相同的账号与用户组
此时用户以aoao身份访问服务端文件

2.服务端 520这个UID账号对于为tao用户
若服务端的/etc/exports里面UID 520用户名称为tao,则客户端的aoao可以访问tao用户的文件,因为两者具有相同的UID,这个需要注意。

3.服务端没有520这个UID
那么aoao就会压缩成匿名用户,而一般会匿名成65534作为其UID,在CentOS 7里,该UID为nfsnobody用户

4.用户身份是root
在默认情况下,root身份会被压缩成匿名用户

小涛:总结一下,当满足以下三个条件,客户端最终具备写入权限。
①用户账号,UID相互的身份;
②NFS服务端允许写入的权限;【/etc/exports中设置】
③文件系统具有可读权限,才具备可写入权限。


总结

以上就是今天要讲的内容,本文着重介绍NFS和RPC两个基础服务底层原理,期望该系列能继续更新下去。(●’◡’●)
咱们下篇博文再见了😀

Logo

更多推荐