网络文件系统

万物归一——网络文件系统微软老道在吸取瓜董的思想之后，终于创立了自己的理论。武当的仓库就像一个大的卷，一个大的磁盘阵列。它可以划分出多个LUN供多个使用者使用。而每个使用者必须有自己的文件系统，因为这个LUN只是一个卷设备，只提供了不计其数的房间存放货物。至于怎么存放货物。需要由使用者自己决定和管理，也就是用文件系统来管理卷，像理货员作货物记录一样。微软老道把瓜董的思想用在了存储上，他把文件系统的功能从使用者处迁移到了磁盘阵列之上，让磁盘阵列自己管理存储空间。而对外提供统一的用户接口（货物存取单据v2.0），使得使用者不用再记录某某文件和卷上扇区或者簇块的对应关系，这个工作统统由盘阵上的集中式文件系统模块处理。使用者只需通过网络告诉这个文件系统需要存取什么文件，长度是多少就可以了。具体存取数据的过程，由集中式文件系统来做，使用者只需等待接收数据就可以了。同样，在存文件的时候，使用者只需告诉文件系统要存哪些数据，提供一些文件名、长度、哪个目录下等信息就可以了，至于文件存到卷的哪些空余扇区完全由盘阵上的文件系统逻辑来处理，使用者不必关心。位于盘阵上的集中式文件系统得益于包交换网络，可以同时处理多个使用者的请求。它可以给每个使用者提供各自的文件夹目录，并且可以为这些目录限定允许存放的最大数据量。总之，文件系统可以实现的任何功能都可以在盘阵上实现。1．网络文件系统使用者如何与盘阵上的集中式文件系统进行交互呢？当然是通过网络来传递数据。由于一直以来的习惯，以太网加TCP/IP成为了首选的网络方式。除了底层传输网络，还必须定义上层的应用逻辑。针对上层逻辑，微软定义了自己的一套规范，叫做CIFS（CommonInternetFileSystem），意思是Internet范围的FS。Linux和UNIX系统用了另一种方式，称为NFS（NetworkFileSystem），这些上层协议都是利用TCP/IP协议进行传输的。以上描述的模型统称为“网络文件系统”。这种文件系统逻辑不是在本地运行，而是在网络上的其他节点运行，使用者通过外部网络将读写文件的信息传递给运行在远端的文件系统，也就是调用远程的文件系统模块，而不是在本地内存中调用文件系统的API来进行。所以网络文件系统又叫做远程调用式文件系统，也就是RPCFS（RemoteProcedureCallFileSystem）。相对于SAN来说，这种网络文件系统不仅磁盘或卷在远程节点上，连文件系统功能也搬运到了远程节点上。本地文件系统可以直接通过主板上的导线访问内存来调用其功能。而网络文件系统只能通过网络适配器上连接的网线而不是主板上的导线来访问远端的文件系统功能。网络文件系统在网络上传递的是些什么内容呢？下面用抓包的方式来分析一下。1）CIFS协议网络包分析在某个用CIFS访问方式的目录下新建一个文本文档，然后将它删除。此过程中抓取网络流量。在CIFS方式下，仅仅上述两个动作，就引发了网络上数百个包的流量（如图10-10所示），可见CIFS是一个开销非常大的NAS协议。这里就不一一分析每个包了。2．NFS协议网络包分析图10-10CIFS协议交互的数据包在一台Linux客户端上使用NFSv3来Mount一台NFS服务器上的某个目录到本地的/mnt目录下。进入这个目录，然后用toucha命令来创建一个名为a的文件，然后执行via，进入编辑模式，不作到任何修改，退出，之后用rma命令来删除这个文件。其间抓取网络上的流量。提示10.128.132.45是NFS客户端的IP地址，10.128.132.175是NFS服务器端的IP地址。分析结果已经去除了不必要的TCP包以及TCP_ACK等包。图10-11显示的是这个过程中网络上双方所交互的主要数据包。图1可以看到，NFS协议的开销远远小于CIFS协议。完成相似动作，NFS只需要交互十几个包即可。下面来分析每个包的作用。Frame1（如图10-12所示）：客户端在创建文件之前，首先做了一次lookup操作，来查找当前目录中是否已经有同名文件；如果有，则拒绝创建。图中的DH表示DirectoryHandle，是一个32字节长的字段，这个值用来指代目录名称。在第一次访问某个目录时，NFS服务端会动态分配这个值，将其通知给客户端。随后的访问请求中，客户端将使用这个值而不是目录名称来向NFS服务端发起针对这个目录的请求。图提示图中DH值的hash值为0x98f8d6bb，为了表示方便，抓包软件将其hash成一个4字节的值，这个hash值并不是存在于网络包中的。本例中，/mnt目录被指定的DH值的hash值就是0x98f8d6bb。Frame2（如图10-13所示）：为NFS服务端对Frame1的回应。通过ERR_NOENT可以判断出当前目录并没有名为a的文件。Frame4（如图10-14所示）：客户端随即发起了“CreateCall”，创建“a”文件。Frame5（如图10-15所示）：NFS服务端对客户端Frame4的回应。创建成功，服务端返回FileHandle（FH）的hash值为0xf03ce91c。FH与DH一样，在数据包中实际上也为一个32字节长的字段。为了表示方便，抓包软件将其hash成一个4字节的值。随后的交互中客户端不会用文件名来向服务端请求操作，而全部用这个FileHandle来指代。Frame6（如图10-16所示）：文件“a”创建成功之后，出于保险起见，应用程序一般都会紧接着查询一下文件属性，顺便确认文件是否创建成功。“GetAttrCall”就是用来查询文件属性用的一种RPCcall。从图中可以看到对应的FH值为0xf03ce91c，NFS服务端收到这个值就会自动对应成文件“a”。Frame7（如图10-17所示）：NFS服务端对Frame6的回应。包中可以看到文件的umask访问权限以及atime、mtime、ctime属性。Frame8（如图10-18所示）：紧接着NFS客户端发起了一个查询/mnt目录属性的请求。因为Handle的值为0x98f8d6bb，所以可以判断这个GetAttrCall是针对/mnt目录的。Frame9（如图10-19所示）：NFS服务端对Frame8的回应。Frame10（如图10-20所示）：NFS客户端发起一个在/mnt目录中查找文件“a”的请求。这里由于是查找操作，客户端会假设不知道“a”文件的FH值，而只知道/mnt目录的DH值，所以文件名“a”使用的就是ASCII码的“a”。Frame11（如图10-21所示）：NFS服务端根据Frame10中请求的回应找到这个文件，FH值是0xf03ce91c。Frame12（如图10-22所示）：NFS客户端发起一个SetAttrCall的请求，这个请求的目的是为了改变文件属性。可以看到客户端请求将文件的atime和mtime改为服务端当前的系统时间。Frame13（如图10-23所示）：对Frame12的回应。可以看到atime、ctime在之前和之后的不同，当然，时间差别都在微妙级，因为这一连串的请求其实是在很短的时间里发出去并得到应答的。Frame15（如图10-24所示）：由于在客户端执行了“rma”的命令，所以客户端发起一个对/mnt目录的访问请求。其实客户端在抓包期间一直处于/mnt目录中，至于为何要重新发起Access请求，与具体应用程序的代码有关，可能开发者为了确认/mnt目录的DH值没有过期，所以重新试探访问。Frame16（如图10-25所示）：NFS服务端对Frame15的回应。Frame18（如图10-26所示）：此时，客户端由于输入了“rma”命令，所以客户端首先要查询一下文件“a”的权限，因此客户端发起一个GetAttr的请求来查询文件“a”的权限。Frame19（如图10-27所示）：NFS服务端对Frame18的回应。Frame20（如图10-28所示）：NFS客户端发起对文件“a”的Access请求。至于为何在删除文件之前要发起Access请求，与编码习惯有关。Frame21（如图10-29所示）：NFS服务端对Frame20的回应。Frame23（如图10-30所示）：NFS客户端发起Remove请求。可以看到Remove请求中并没有使用FH，而是直接使用了文件名。Frame24（如图10-31所示）：NFS服务端对Frame23的回应。可以看到，基于NAS的数据访问，客户端并不关心文件存放在磁盘的哪些扇区，这些逻辑全部由NAS服务端处理，客户端向NAS设备发送的只有各种文件操作请求以及实际的文件流式数据。大家可以在本书12.4节看到有关ISCSI的抓包分析，可以作一下对比，两者交互的语言完全不同。