【转自中科蓝鲸】集群NAS与集群文件系统的区别

集群NAS与集群文件系统的区别

发布日期：2011-08-17

 

集群NAS：
集群（Cluster）是由多个节点构成的一种松散耦合的计算节点集合，协同起来对外提供服务。集群主要分为高性能集群HPC(High Performance Cluster)、高可用集群HAC(High Availablity Cluster)和负载均衡集群LBC(Load Balancing Cluster)。集群NAS是指协同多个节点（即通常所称的NAS机头）提供高性能、高可用或高负载均衡的NAS（NFS/CIFS）服务。
集群NAS是横向扩展（Scale-out NAS），集群NAS具有独立升级、线性扩展（容量增加不会带来性能瓶颈）的优势。集群NAS是指可扩展NAS，可在文件系统级进行存储扩展。通常集群NAS通过集群文件系统完成。

集群NAS的三种主流技术架构
从整体架构来看，集群NAS由存储子系统、NAS集群(机头)、客户端和网络组成。存储子系统可以采用存储区域网络SAN、直接连接存储DAS或者面向对象存储设备OSD的存储架构，SAN和DAS架构方式需要通过存储集群来管理后端存储介质，并以SAN文件系统或集群文件系统的方式为NAS集群提供标准文件访问接口。在基于OSD架构中，NAS集群管理元数据，客户端直接与OSD设备直接交互进行数据访问，这就是并行NAS，即pNFS/NFSv4.1。NAS集群是NFS/CIS网关，为客户端提供标准文件级的NAS服务。对于SAN和DAS架构，NAS集群同时承担元数据和I/O数据访问功能，而OSD架构方式仅需要承担元数据访问功能。根据所采用的后端存储子系统的不同，可以把集群NAS分为三种技术架构，即SAN共享存储架构、集群文件系统架构和pNFS/NFSv4.1架构。

(1)SAN共享存储架构
这种架构(如图1所示)后端存储采用SAN，所有NAS集群节点通过光纤连接到SAN，共享所有的存储设备，通常采用SAN并行文件系统管理并输出POSIX接口到NAS集群。SAN并行文件系统通常需要元数据控制服务器，可以是专用的MDC，也可以采用完全分布的方式分布到SAN客户端上。NAS集群上安装SAN文件系统客户端即可实现对SAN共享存储的并发访问，然后运行NFS/CIFS服务为客户端提供服务。这里前端网络采用以太网，后面存储连接则采用SAN网络。

 

由于采用了高性能的SAN存储网络，这种集群NAS架构可以提供稳定的高带宽和IOPS性能，而且可以通过增加存储盘阵或NAS集群节点实现存储容量和性能单独扩展。客户端可以直接连接具体的NAS集群节点，并采用集群管理软件来实现高可用性；也可以采用DNS或LVS实现负载均衡和高可用性，客户端使用虚拟IP进行连接。SAN存储网络和并行文件系统成本都比较高，因此这种集群NAS架构的缺点就是成本较高，同时也继承了SAN存储架构的缺点，比如部署管理复杂、扩展规模有限等。采用这种架构的集群NAS典型案例是IBM SONAS(图2)和Symantec FileStore。

(2)集群文件系统架构
这种架构后端存储采用DAS，每个存储服务器直连各自的存储系统，通常为一组SATA磁盘，然后由集群文件系统统一管理物理分布的存储空间而形成一个单一命名空间的文件系统。实际上，集群文件系统是将RAID、Volume、File System的功能三者合一了。目前的主流集群文件系统一般都需要专用元数据服务或者分布式的元数据服务集群，提供元数据控制和统一名字空间，当然也有例外，如无元数据服务架构的GlusterFS。NAS集群上安装集群文件系统客户端，实现对全局存储空间的访问，并运行NFS/CIFS服务对外提供NAS服务。NAS集群通常与元数据服务集群或者存储节点集群运行在相同的物理节点上，从而减少物理节点部署的规模，当然会对性能产生一定的影响。与SAN架构不同，集群文件系统可能会与NAS服务共享TCP/IP网络，相互之间产生性能影响，导致I/O性能的抖动。诸如ISILON等集群文件系统存储节点之间采用InfiniBand网络互联，可以消除这种影响，保持性能的稳定性。

 

在这种架构下，集群NAS的扩展通过增加存储节点来实现，往往同时扩展存储空间和性能，很多系统可以达到接近线性地扩展。客户端访问集群NAS的方式与第一种架构方式相同，负载均衡和可用性也可以采用类似的方式。由于服务器和存储介质都可以采用通用标准的廉价设备，在成本上有很大优势，规模可以很大。然而，这类设备是非常容易发生故障的，服务器或者磁盘的损坏都会导致部分数据不可用，需要采用HA机制保证服务器的可用性，采用复制保证数据的可用性，这往往会降低系统性能和存储利用率。另外，由于服务器节点比较多，这种架构不太适合产品化，可能更加适合于存储解决方案。用这种架构的集群NAS典型案例包括EMC ISILON、龙存LoongStore、中科蓝鲸BWFS、九州初志CZSS、美地森YFS和GlusterFS等。

(3)pNFS/NFSv4.1架构
这种架构实际是并行NAS，即pNFS/NFSv4.1，RFC 5661标准已于2010.01获得批准通过。它的后端存储采用面对对象存储设备OSD，支持FC/NFS/OSD多种数据访问协议，客户端读写数据时直接与OSD设备相互，而不像上述两种架构需要通过NAS集群来进行数据中转。这里的NAS集群仅仅作为元数据服务，I/O数据则由OSD处理，实现了元数据与数据的分离。这种架构更像原生的并行文件系统，不仅系统架构上更加简单，而且性能上得到了极大提升，扩展性非常好。

 

 

显而易见，这种架构与上述两种有着本质的区别，pNFS采用元数据集群解决了传统NAS的单点故障和性能瓶颈问题，元数据与数据的分离则解决了性能和扩展性问题。这才是真正的并行NAS，pNFS才是集群NAS的真正未来。然而，毕竟pNFS标准获得批准才一年，目前还没有成熟的产品实现，OSD存储设备发展多年也没有得到市场广泛认可和普及。Panasas公司的PanFS(图6)应该是最接近于这种集群NAS架构，当然Panasas也是pNFS标准的主要制定者之一。目前很多存储公司都在研发pNFS产品，比如BlueArc，笔者预测到2012年就会有产品陆续推出。

3 开源解决方案
上述提到的集群NAS存储产品或者解决方案，大多都是商业实现，而且成本比较昂贵。可能有些用户想利用开源软件来实现集群NAS，有没有这样的开源解决方案呢？集群NAS的核心是底层的并行文件系统、集群文件系统或pNFS协议，下面就简单介绍开源在集群NAS方面的支持和实现。
(1)SAN共享存储架构：Redhat GFS是开源SAN共享文件系统，它也支持DAS连接方式，然后整合NFS/Samba服务即可实现集群NAS。
(2)集群文件系统架构：Lustre, Gluster, PVFS2, Ceph，这些都是优秀的集群文件系统，Gluster本身就是一个完整的集群NAS系统。类似Gluster实现，集群文件系统通过NFS/Samba网关提供NAS服务，实现集群NAS。
(3)pNFS/NFSv4.1架构：Linux内核当前已经集成了pNFS源码，但处于实验阶段。另外开源OSD实现很少，GFS2可以支持pNFS。想尝新的用户可以一试，实际应用还是要谨慎。

 

集群文件系统：
文件系统是保存和组织数据的一种数据结构和一组程序方法。通常使用的本地文件系统有NTFS、EXT3、FAT等，都是用户首先创建出目录结构，然后设定一定的访问权限，之后在目录中保持文件。文件系统都是创建在一个或多个磁盘上，这些磁盘可能是服务器内部的物理磁盘，也可能是来自FC SAN或IP SAN的LUN。通常对于本地文件系统，在一个时刻只能由一台服务器挂载并访问。
上述使用方式尽管可以满足服务器快速读写数据的需求，但却导致磁盘空间只能由一台服务器访问。在多服务器处理环境中这会带来三个问题：1、存储空间闲置：尽管本服务器还有存储空间，但其他服务器无法直接访问。2、导致一些应用无法有效运行：因为许多应用需要多台甚至是大量服务器并行或协作处理，如果每台服务器都保持有自己独立的数据拷贝，会使并行处理无法进行，使得协作处理效率低下。3、基于文件的工作流类应用无法有效开展：文件不得不在处理工作流上不同环节的工作站上来回复制，浪费空间且效率低下。
这种情况下，传统的做法是让环境中的一台服务器使用网络文件系统协议，如NFS(Linux/UNIX)或CIFS(Windows)，把自己本地文件系统共享给其他的服务器、用户或应用程序访问。这种方法解决了存储空间整合的问题，使得存储空间和数据很容易在多台服务器和多个应用间共享。作为普通NAS设备/文件服务器中使用的文件共享协议，NFS和CIFS的特点是实现和部署成本较低（已经出现了几十年，有成熟的开源代码实现，基于IP网络部署），性能不高（在千兆以太网链路上，NFS通常在70MB/s，CIFS在40MB/s左右），可以满足普通办公环境文档共享的需求。但对于存储容量巨大，需要低延时，高IO吞吐量的应用场合，上述的应用方案难以满足需求，需要有创新的共享文件系统解决方案出现，其基本的出发点有以下两条：
1. 共享文件系统要充分利用主机端的代理程序，使之能够尽量快速地直接地访问后端的磁盘阵列。这就需要共享文件系统具有创新的体系结构，因为传统的共享文件系统，如：NFS和CIFS都是所有的客户端访问集中的NFS/CIFS Server（NAS设备/文件服务器），然后由该文件服务器将IO请求转发给磁盘阵列。文件服务器的存在，使得客户端到后端磁盘阵列的路径增加，必然导致延时增大。并且文件服务器的对外带宽和IO能力也难以和后端的磁盘阵列匹配（典型的例子：1G x2 vs. 4G x4 ），导致文件服务器成为性能瓶颈。
2. 共享文件系统要充分利用主机端的代理程序，使得大量主机尽量并发数据读写到后端的磁盘阵列。这也需要共享文件系统具有创新的体系结构，因为传统的共享文件系统，如：NFS和CIFS都是串行访问NFS/CIFS Server（NAS设备/文件服务器），即使文件服务器后端连接了多台磁盘阵列，具有很强的并发处理的能力和带宽优势，在传统的文件服务器方式下，也发挥不出来。
此外，对于当前的应用环境，异构多操作系统平台支持和系统容量、性能的可扩展能力方面的需要也日益突出，特别是在媒体、政府、科研和大型工程、数据中心等环境中，Windows和Linux混合使用，以及存储容量和IO性能逐年增长已经成为必然需求。

BWFS蓝鲸文件系统介绍
BWFS（BlueWhale File System）是一种支持异构多操作系统平台的共享文件系统，它允许多台服务器并发访问同一组磁盘和文件而不必关心各自的文件系统类型。目前，BWFS支持多种企业级Linux平台、Windows平台和Mac平台。BWFS针对不同的操作系统有不同的客户端程序，这些客户端程序能够识别并提供对BWFS共享文件系统的访问，并且确保文件系统在不同的操作系统平台上表现一致，IO请求能够得到正确的处理。
当多台服务器并发访问同一个文件系统时，需要有某种机制防止两台服务器同时写到同一个磁盘位置，并且要保证某台服务器读取文件内容时不会因为有其他服务器在更新该文件而读到不一致的内容。在BWFS中这种机制和功能是由元数据控制器MDC（MetaData Controller）提供的。
MDC负责协调服务器对BWFS文件系统的访问，其位于文件数据的读写路径之外。客户端通过独立的IP链接和MDC进行通信，以获取文件的位置和数据块资源分配信息，而后通过SAN网络以块级读写方式直接读写磁盘。这种体系结构的设计在专业术语中被称做“带外(out-of-band)传输架构”或“非对称体系结构”。

数据访问过程可以分解如下：
1. 应用程序发出一个写请求。
2. BWFS 客户端通过LAN发送一个写操作请求给MDC。
3. MDC处理该请求，并通过LAN回应客户端哪些磁盘块可以写入数据。
4. BWFS客户端将数据以线速直接写入文件系统。
BWFS是以SAN环境为基础设计的，允许大量连接在FC SAN或IP SAN（iSCSI）上的服务器或工作站直接访问相同的文件系统。从原理上讲，这是目前技术上能够实现的最高数据吞吐量和最低数据延迟的方法。BWFS可以利用一条或多条FC链路访问磁盘资源，这使得只需简单地增加FC HBA卡，单台服务器的IO性能就可以从100多MB/s扩展到几GB/s。
当然，系统的整体性能不仅与主机和网络的性能相关，也受组成文件系统的磁盘的性能影响。正式因为如此，BWFS文件系统可以通过来自多台盘阵的LUN构建。这相当于在多个磁盘阵列间又构建了一层RAID，从而最大程度地发挥磁盘阵列的性能。
另外一个需要考虑的性能因素是元数据的位置。一个文件由实际数据和元数据组成。实际数据是文件的内容，而元数据包括文件的属性、权限等等。当一个文件被创建、修改或删除时，需要修改元数据信息。这就是说当处理一个文件时，读写的不仅是文件的数据，还有文件的元数据。对于大文件的读写，文件内容的读写通常是连续的，而元数据的读写通常需要磁盘磁头移动到其他位置，对磁盘来讲其读写模式是随机程度要高很多。如果将数据和元数据存放在相同的磁盘上（大多数文件系统的模式），会加大文件读写的随机程度，从而降低文件读写的性能。因为这个原因，BWFS文件系统布局上将元数据存放在不同的磁盘或卷上，使得文件的连续读写和元数据的随机读写分开，互不影响，尽可能提供更高的IO带宽。
此外，数据和元数据分离后，数据和元数据可以独立在不同的主机上进行处理，可以不占用数据通道的带宽，并提高数据和元数据处理的并发度，从而进一步提高文件系统的性能。

转载于:https://my.oschina.net/uvwxyz/blog/175663