【Linux服务器架设】存储服务器构建原理NFS

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

第一章 搭建存储服务器-NFS
第二章 存储服务器构建原理&＃xff08;上&＃xff09;-NFS

前言

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

一、NFS是什么&＃xff1f;

这时有小伙伴问了&＃xff0c;小涛小涛&＃xff0c;这是我手机那个能刷卡那个东东吗&＃xff1f;
不是哦&＃xff0c;那个是NFC&＃xff0c;NFS全称是Network File System&＃xff0c;即网络文件系统&＃xff0c;最大的功能呢&＃xff0c;即通过网络的方式&＃xff0c;让不同的机器&＃xff0c;可以共享文件
而对于客户端来说&＃xff0c;这个远程的主机目录&＃xff0c;就好像自己的磁盘分区&＃xff0c;在使用上&＃xff0c;相当于远程插U盘。

如同所示&＃xff0c;当服务端配置共享的/data/share目录&＃xff0c;那么客户端就可以把该目录挂载到任意位置&＃xff0c;例如客户端1&＃xff0c;当我进入/home/share目录时&＃xff0c;即可查看到服务端的所以数据了(前提是权限要足够)&＃xff0c;进入后&＃xff0c;可自由使用Linux指令&＃xff0c;特别nice&＃x1f601;

二、RPC

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

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

1.什么是RPC

RPC最主要的功能&＃xff1a;指定每个NFS功能所对应的端口号&＃xff0c;并且通知客户端&＃xff0c;让客户端可以允许访问了。

RPC如何知道每个NFS的端口&＃xff1f;
当服务器启动NFS时&＃xff0c;会随机选取某个端口&＃xff0c;并主动向RPC注册&＃xff0c;因此RPC可以知道每个端口对于的NFS功能。
然后RPC是固定使用111端口来监听客户端的需求&＃xff0c;并向客户端响应正确的端口&＃xff0c;依次有了它&＃xff0c;NFS的启动更为丝滑了。

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

如图所示&＃xff0c;当客户端请求NFS文件时间&＃xff0c;它是这么向服务端请求数据&＃xff1a;
1.客户端向服务端RPC&＃xff08;111端口&＃xff09;发出NFS文件访问功能的查询要求
2.服务端找到对应且已注册的NFS端口后&＃xff0c;通知给客户端
3.客户端了解正确的端口后&＃xff0c;他们就能亲密连接了。

2.NFS启动RPC守护进程

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

rpc.nfsd

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

rpc.mountd

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

rpc.lockd【非必要】

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

rpc.statd【非必要】

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

三、NFS文件访问权限

这时有小伙伴想问了&＃xff1a;小涛&＃xff0c;我在客户端1用aoao这个用户身份去访问/home/share这个来自NFS服务端提供的文件时&＃xff0c;NFS服务端会让我们以什么身份访问呢&＃xff1f;也是aoao还是其他角色吗&＃xff1f;
小涛&＃xff1a;为什么会这么提问呢&＃xff1f;
小伙伴&＃xff1a;我发现NFS本身的服务并没有进行用户身份验证&＃xff0c;验证貌似是RPC干的
小涛&＃xff1a;说得非常正确&＃xff0c;当aoao想访问服务端的文件系统时&＃xff0c;服务端会以客户用户的UID与GID的身份尝试读取
小伙伴&＃xff1a;那客户端与服务端的用户身份不一致怎么办呢&＃xff1f;
小涛&＃xff1a;emm。。。咱们看图&＃xff0c;这是NFS的客户端与服务端用户连接机制过程

小涛&＃xff1a;当我们以aoao身份去访问服务端时&＃xff0c;需注意&＃xff0c;文件系统的inode所记录的属性为UID、GID&＃xff0c;而非账号与属组名。
小伙伴&＃xff1a;哦哦&＃xff0c;那就是Linux主机会去查看/etc/passwd、/etc/group进行查询对应的用户名等&＃xff0c;所以当aoao进入该目录文件后&＃xff0c;会参照NFS客户端1的用户名与组名是吧&＃xff1f;
小涛&＃xff1a;正确&＃xff0c;但由于该目录的文件是来自服务端&＃xff0c;所以会出现以下几种情况&＃xff0c;咱们要具体问题具体分析。

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

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

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

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

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

总结

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