第一十零章 三足鼎立——DAS、SAN 和NAS

10.2  龙争虎斗——NAS与SAN之争

10.2.1  SAN快还是NAS快

    很多人都在问，到底SAN快还是NAS快？要解答这个问题，方法非常简单，和百米赛跑一样，只要计算起点到终点的距离、耗时、开销就可以了。

    SAN的路径图如图10-32所示。

 

图10-32  SAN方式路径图

    NAS的路径图如图10-33所示。

 

图10-33  NAS方式路径图

    显然，NAS架构的路径在虚拟目录层和文件系统层通信的时候，用以太网络和TCP/IP协议代替了内存，这样做不但增加了大量的CPU指令周期（TCP/IP逻辑和以太网卡驱动程序），而且使用了低速传输介质（内存速度要比以太网快得多）。而SAN方式下，路径中比NAS方式多了一次FC

访问过程，但是FC的逻辑大部分都由适配卡上的硬件完成，增加不了多少CPU开销，而且FC访问的速度比以太网高。所以我们很容易得出结论。

 

    如果后端磁盘没有瓶颈，那么除非NAS使用快于内存的网络方式与主机通信，否则其速度永远无法超越SAN架构。但是如果后端磁盘有瓶颈，那么NAS用网络代替内存的方法产生的性能降低就可以忽略。比如，在大量随机小块IO、缓存命中率极低的环境下，后端磁盘系统寻道瓶颈达到最大，此时前端的IO指令都会处于等待状态，所以就算路径首端速度再快，也无济于事。此时，NAS系统不但不比SAN慢，而且由于其优化的并发

 

    IO设计和基于文件访问而不是簇块访问的特性，反而可能比SAN性能高。既然NAS一般情况下不比SAN快，为何要让NAS诞生呢？既然NAS不如SAN速度快，那么它为何要存在呢？具体原因如下。

    NAS的成本比SAN低很多。前端只使用以太网接口即可，FC适配卡以及交换机的成本相对以太网卡和以太交换机来说是非常高的。

    NAS可以解放主机服务器上的CPU和内存资源。因为文件系统的逻辑是要靠CPU的运算来完成的，同时文件系统还需要占用大量主机内存用作缓存。所以，NAS适合用于CPU密集的应用环境。

    由于基于以太网的TCP/IP传输数据，所以NAS可扩展性很强。只要有IP的地方，NAS就可以提供服务，且容易部署和配置。

    NAS设备一般都可以提供多种协议访问数据。网络文件系统只是其提供的一种接口而已，还有诸如HTTP、FTP等协议方式。而SAN只能使用SCSI协议访问。

    NAS可以在一台盘阵上实现多台客户端的共享访问，包括同时访问某个目录或文件。而SAN方式下，除非所有的客户端都安装了专门的集群管理系统或集群文件系统模块，否则不能将某个LUN共享，强制共享将会损毁数据。

    经过特别优化的NAS系统，可以同时并发处理大量客户端的请求，提供比SAN方式更方便的访问方法。多台主机可以同时挂接NFS上的目录，那么相当于减少了整个系统中文件系统的处理流程，由原来的多个并行处理转化成了NFS上的单一实例，简化了系统冗余度。

10.2.2  SAN好还是NAS好

    关于IO密集和CPU密集说明如下。

    CPU密集：指的是某种应用极其耗费CPU资源，其程序内部逻辑复杂，而且对磁盘访问量不高。如超频爱好者常用的CPU测试工具就是这种应用，这种程序在运行的时候，根本不用读取磁盘上的数据，只是在程序载入的时候，读入一点点程序数据而已。进程运行之后便会使CPU的核心处于全速状态，这会造成其他进程在同一时间内只获得很少的执行时间，影响了其他程序的性能。在必要时，可以将多台机器组成集群来运行这种程序。

    IO密集：指的是某种应用程序的内部逻辑并不复杂，耗费的CPU资源不多，但是要随时存取硬盘上的数据。比如FTP服务器之类程序就是这种。

    IO和CPU同时密集：这种应用程序简直就是梦魇。为了获得高性能，大部分这类程序都不适合用单台机器运行，必须组成集群系统来运行这种应用程序，包括前端运算节点的集群和后端存储节点的集群。

   显然，NAS对于大块连续IO密集的环境，要比SAN慢一大截，原因是积累效应。经过大量IO积累之后，总体差别就显现出来了。不过，如果要使用10Gb/s以太网这种高速网络，无疑要选用NAS，因为底层链路的速度毕竟是目前NAS的根本瓶颈。此外，如果是高并发随机小块IO环境或者共享访问文件的环境，NAS会表现出很强的相对性能。如果SAN主机上的文件系统碎片比较多，那么读写某个文件时便会产生随机小块IO，而NAS自身文件系统会有很多优化设计，碎片相对少。CPU密集的应用可以考虑使用NAS。SAN与NAS有各自的优点和缺点，需要根据不同的环境和需求来综合考虑。

10.2.3  与SAN设备的通信过程

    对于SAN方式来说，应用程序必须通过运行在服务器本机或者NAS设备上的文件系统与磁盘阵列对话。应用程序对本机文件系统（或NAS）说：“嗨，兄弟，帮我把/mnt/SAN目录下的SAN.txt文件传到我的缓冲区。”文件系统开始计算SAN.txt文件占用的磁盘扇区的LBA地址，计算好之后向SAN磁盘阵列说（用SCSI语言）：“嗨，哥们，把从LBA10000开始之后的128个扇区内容全部传送给我！”

    SAN磁盘阵列接收到这个请求之后，便从它自身的众多磁盘中提取数据，通过FC网络传送给运行着文件系统程序的节点（服务器主机或NAS设备）。文件系统接收到扇区内容之后，根据文件系统记录截掉扇区多余的部分，将整理后的数据放入请求这个数据的应用程序的缓冲区。

10.2.4  与NAS设备的通信过程

    应用程序通过操作系统的虚拟目录层直接与NAS设备对话：“嗨，兄弟，帮我把/mnt/NAS目录下的NAS.txt文件传过来。”或 “嗨，兄弟，帮我把/mnt/NAS目录下的NAS.txt文件的前1024字节传递过来。”这些话被封装成TCP/IP数据包，通过以太网传递到NAS设备上。NAS接到这个请求之后，立即用自己的文件系统（NTFS、JFS2、EXT2、EXT3等）计算NAS.txt文件都占用了磁盘的哪些扇区，然后从自己的磁盘上用ATA语言或者SCSI语言向对应的磁盘存取数据（或自己安装FC适配卡，从SAN存储设备上存取数据）。

    显然，NAS将文件系统逻辑搬出了主机服务器，成为了一个单独的文件系统逻辑运行者。如图10-34所示为从主机到NAS设备的IO全流程示意图，牵扯到了整个系统的IO路径以及路径上的每种元素和角色。关于系统IO路径的详细阐述请参考本书后面章节。

 

图10-34  网络文件系统IO全流程图

    首先，主机客户端通过NFS Client对NAS上的一个输出目录/nas/export进行Mount操作，将其Mount到了本地的/mnt/nas路径下。之后，主机客户端上某应用程序发起了对/mnt/nas/nas.txt文件的读取操作，读取从偏移量0字节开始往后的1024字节，也就是这个文件的前1024字节。这个动作是通过调用操作系统提供的文件操作API执行的，比如Read()。这个IO请求被传送到了NFS Client处，NFS Client知道/mnt/nas路径对应的其实是NAS服务端的/nas/export这个输出目录，所以NFS Client将上层下发的这个读取请求封装成NFS协议规定的标准格式通过网络传送到NAS服务端。

    NAS服务端接收到这个读请求之后，将请求通过操作系统API传送给文件系统模块处理。

    文件系统模块接收到针对/nas/export/nas.txt文件的读请求之后，首先查询缓存内是否有对应的数据，如果有，则直接返回结果；如果没有，则需要将这段字节所落入的底层存储空间的块信息取回，这个动作通过查询inode表等元数据获得。当得到底层块地址之后，文件系统通过调用OS提供的API将对这些块的读请求发送给下游模块，也就是卷管理层。卷管理层是将底层物理磁盘设备进行虚拟化封装的层次。当卷管理层收到针对某个卷某段LBA地址的请求之后，它要进行翻译，将目标虚拟卷的地址翻译为对应着底层物理磁盘块设备的地址；翻译完后，卷管理层将对应目标地址的请求再次通过调用OS API的方式发送给下游，也就是驱动程序层了。块设备驱动是负责对相应块设备进行IO的角色，它将这些IO发送给SCSI CDB Generator，也就是SCSI指令的翻译中心。

    SCSI CDB Generator的职责是将对应的IO请求描述为SCSI协议的标准格式。之后，这些指令被发送到SCSI/FC适配器的驱动程序处。设备驱动程序接收到这些SCSI指令之后，将其封装到对应的链路帧中通过内部总线网络或者外部包交换网络传送到目标。SCSI指令传送到目标设备，目标设备执行相应指令并返回结果。

10.2.5  文件提供者

   NAS可以看作一个Filer。Filer这个词是著名NAS设备厂商NetApp对其NAS产品的通俗称呼。它专门处理文件系统逻辑及其下面各层的逻辑，从而解放了服务器主机。服务器主机上不必运行文件系统逻辑，甚至也不用运行磁盘卷逻辑，只需运行目录层逻辑（UNIX系统上VFS层、Windows系

统上的盘符及目录）即可。把底层的模块全部交由一个独立的设备来完成，这样就节约了服务器主机的CPU资源和内存资源，从而可以专心地处理应用层逻辑了。

    NAS网关就是这样一种思想。NAS网关其实就是一台运行文件系统逻辑和卷逻辑的设备，可以把它想象成一个泵，这个泵可以从后端接收一种格式（以LBA地址为语言的指令和数据格式），经过处理后从前端用另一种格式（以文件系统为语言的指令和数据格式）发送出去，或执行反向的过程。可以把这个泵接入任何符合条件的网络中，以实现它的功能。我们可以称它为文件系统泵，或者Filer。可以把SAN设备称为Disker（专门处理磁盘卷逻辑），把服务器主机称为Applicationer（专门处理应用逻辑）。如果某个设备集成了Filer和Disker的功能，并将其放入了一

个机箱或者机柜，那么这个设备就是一个独立的NAS设备。如果某个设备仅仅实现了Filer，而Disker是另外的独立设备，那么这个只实现了Filer的设备就称为NAS网关或NAS泵。图10-35显示了这个泵接入网络之后发生的变化。

 

图10-35  NAS泵

    然而，目前NAS的用途并不如SAN广泛，主要原因是NAS的前端接口几乎都是千兆以太网接口，而千兆以太网的速度也不过100Mb/s，除去开销之后所剩无几。而SAN设备的前端接口目前普遍都是4Gb/s的速度，可以提供400Mb/s的带宽。FC现在已有8Gb/s速率的接口出现，而10Gb/s以太网也初露端倪。不久的将来，NAS必定会发起另一轮进攻。

10.2.6  NAS的本质

    本地文件系统负责将硬盘上的数据包装、展现，以及提供调用接口。文件系统将数据展现为文件和目录的形式，调用接口包括读、写、删、创建等。

    一般情况下，应用程序是在内存中调用这些接口从而让文件系统实现对应功能的。如Read()、Write()、API等。如果应用程序不在本机运行，而是运行在网络的另一端，同时依然想保留原有的访问文件的方式。此时就需要允许远程机器上的应用程序可以把这些调用指令通过网络打包传送过来，这些指令必须双方都能够识别，为此，NFS和CIFS协议诞生了。二者统称NAS协议或者NAS。多个远程的应用程序可以同时对本地文件系统发起IO请求。这样，本地这台服务器就变成了一台文件服务器了，NAS设备就这么诞生了。

    所以NFS和CIFS又被称为“网络文件系统”，其实它们只是一种规定如何将文件操作指令及结果在双方之间传送和控制的协议。网络上只有协议，没有文件系统，文件系统都在本地。“通过外部网络而不是计算机内部总线来传递文件读写指令的系统“是对网络文件系统最准确和最本质的描述。