为什么需要共享存储

      绝大多数集群都使用共享存储。那why？集群中要保证重要资源的可用性。资源可能运行在任意节点，可能需要访问相同的文件。如果集群资源只处理静态文件，那就不需要共享存储。如果文件改动不频繁，那么可以通过复制或rsync之类的方案来进行节点间同步。而当数据时动态的而且频繁变化，那么就需要共享存储了。

 

通常，集群资源使用三类文件：

 

一、二进制可执行文件，最好分别安装在每个节点上。这样保证每个节点上应用独立运行。

 

二、配置文件，推荐将这类配置文件放置在共享存储上，这样确保集群中的节点访问相同的配置文件。理论上，节点间对配置文件进行人工同步也是可行的，但是实际上会出现问题，可能导致各节点上配置文件版本不一致。

 

三、最重要的一种文件类型，数据文件。这一般是最有价值的数据，一般放在共享存储上，集群中的节点能同时使用，需要通过冗余来保护这些数据。

 

单一操作系统上的文件系统

一般的文件系统包含在系统内核中，来实现文件、文件夹等：

 

文件系统维护FAT（File Allocation Table）：逻辑文件和物理磁盘块编号的关联信息。

 

文件系统维护磁盘block信息，处理应用的读写请求（使用FAT信息）。

 

维护”file cache“，当新信息写到文件后，保存在磁盘同时复制到文件系统的”cache buffers“，应用又需要读取相同文件分区时，文件系统从cache缓冲区进行简单检索，而不是去磁盘重新读取。

 

         

NAS、SAN及集群文件系统

      在选择共享存储解决方案时，通常从NAS和SAN中选择，还有如集群存储，典型集群存储有两种实现方式：一种是硬件+软件，如SAN架构+IBM GPFS；另一种是专用集群存储，如NetApp GX，NetApp GX是构建在NAS基础架构之上的，通过操作系统实现集群存储。

 

NAS

     网络附加存储NAS（Network attached storage）基于网络共享，传统NAS提供文件级别的存储服务。NAS服务器一般由存储硬件、操作系统以及其上的文件系统等几个部分组成。在Linux集群中，NAS通常采用NFS提供文件共享，也可以选用CIFS。NAS的优点是价格合理、设置简单、便于管理。在集群中最重要的是要避免网络中出现单点故障，所以如果计划使用NAS服务器来作为共享存储时，需要考虑冗余。一般NAS具有一定的可扩展性，但是它的可扩展性不是线性的，在某一临界点曲线变为水平后，NAS就无力应付此时的负载。而目前有集群NAS解决方案，它是一种横向扩展（Scale-out）存储架构，具有容量和性能线性扩展的优势。

 

HA集群中使用NAS的原因是NAS可以提供并发访问，而SAN不行，除非在客户端使用OCFS2、GFS2等文件系统。

 

 

 

SAN

     SAN提供块级别的存储服务，能够提供很好的冗余的同时提供高性能，SAN还具有无限扩展能力，但是构建比较复杂。通常采用磁盘阵列，采用一个专用网络来访问这些磁盘，SAN可以使用FDDI、以太网或其他方式实现（后面会介绍FC和iSCSI两种）。典型的场景中，SAN filer中的磁盘阵列通常使用RAID来确保冗余。在阵列之上，创建LUN，集群节点连接到LUN，当做本地磁盘使用。典型环境中所有部件都要保证冗余，节点都分别连接到两个SAN交换机（参见下图），依次连接到SAN存储的两个不同的控制器。

 

 

     SAN提供共享磁盘，但本身无法提供共享文件系统。如果集群节点需要访问同一个共享磁盘（LUN），并使用常规文件系统，磁盘的逻辑结构很快就被破坏了。共享磁盘搭配传统文件系统的两个问题：

 

磁盘空间分配不一致

 

如果一个共享磁盘同时挂载到多个节点，文件系统会加载FAT到每个节点的内存中。当其中一个节点上的应用尝试写文件，此节点上的文件系统会查询FAT和可用block，然后分配供使用，然后修改自己的FAT，但是不会修改其他节点上的FAT。如果其他节点上的应用尝试写文件时，可能会分配和之前相同的block供使用，因为这个节点不知道另一个节点已经占用了这个block。

 

注：文件系统处理数据参见上面。

 

文件数据不一致

 

例如节点A一个进程读取一个block X上的数据，这个block被复制到节点A的文件系统cache中。如果A节点上同一个或另一个进程读取同一个block的数据，A节点的文件系统会直接从cache中复制数据。节点B上的进程修改block X上的数据，而节点A实际上并不知道，会继续使用cache中的数据提供给应用使用，但其实数据已经不可用了。

 

因此，共享磁盘搭配常规文件系统来作为共享文件系统是不可行的。这种方式可以用于如fail-over系统。

 

集群文件系统

   集群文件系统是同时挂载到多个服务器来共享的一种文件系统。集群文件系统可以解决上面那种共享磁盘的不一致的问题。使用服务器间网络来互相通信来进行同步，可以使用以太网、SAN、或一些快速低延迟的集群内联设备。

 

 

 

上面例子中集群文件系统安装在几台服务器上。

 

第一个节点上APP1向集群文件系统请求读取数据（block number 5），集群文件系统将请求发送到包含的常规文件系统。另一个节点上的APP2向集群文件系统请求写入数据（block number 7）。集群文件系统通过inter-server网络来通知其他节点的集群文件系统，block被修改。集群文件系统会清除cache中的相关旧数据。所有节点上的FAT也会通过inter-server网络进行同步。集群文件系统解决了不一致问题并允许多个节点将共享磁盘当做共享文件系统使用。

 

一些常见的集群文件系统有：GFS、GPFS等。

 

iSCSI或光纤通道SAN

采用SAN时，需要决定使用iSCSI还是FC。市场上出现的是光纤SAN，当时LAN网络只能达到百兆。现在LAN网络可以达到千兆、万兆了，所以新的技术标准出现了，即iSCSI。iSCSI的原理很简单，将生成的SCSI包封装上IP报头使之可以在普通以太网上传输。

 

 

光纤SAN号称比iSCSI更可靠、更快，实际上并不尽然。市场上有一些高端iSCSI解决方案，使用专用的iSCSI网络，同时进行优化后，iSCSI可以比FC SAN更快更可靠。同时iSCSI SAN相比FC SAN创建更为简单。实现FC技术的另一种选择是使用FCoE（Fibre Channel over Ethernet）来替代昂贵的光纤硬件设施。这种解决方案使用万兆以上的以太网，同时使用FC协议。现在主流的Linux都支持FCoE。

 

进一步理解iSCSI

配置iSCSI时，需要配置两个部分：iSCSI target和iSCSI initiator。这里我们以SAN为例子，iSCSI target运行在SAN存储上，启用3260端口对client提供服务。iSCSI initiator运行在集群节点上并连接到iSCSI target。这种架构中，通常采用一个专用的SAN网络，是一个特殊的以太网，网络是冗余的。（可能会导致LUN被节点发现四次）

 

 

       在SAN网络上需要进行一些特殊的优化。首先集群节点可以选用iSCSI HBA卡。这种网卡是一种智能网卡，主要是将iSCSI层和TCP/IP协议栈的功能交由HBA来完成，这样，对主机CPU的需求也可减小到最少。一般建议开启巨型帧，MTU设置为9000，来确保处理数据的速度，同时还可以使用带iSCSI减压引擎（TOE）功能的HBA来更有效的处理数据。然而，目前iSCSI HBA可能会被更高速的NIC替代。

 

多路径

SAN通常配置冗余。在典型架构中，集群节点有四条路径到LUN，在节点上会发现/dev/sda、/dev/sdb、/dev/sdc、/dev/sdd，实际上是同一个设备。正如四个/dev/sdx绑定到一个特定的路径，不该连接到其中的任意一个。如果连接的路径断掉了，节点将断开连接。这就是为什么要使用multipath。

 

multipath是一个可加载的驱动，用来分析上面的存储设备，它会发现/dev/sdx其实是同一个LUN，同时创建一个特定的设备供节点连接。当multipath驱动加载后，“multipath -l”可以确认拓扑，可以看到一个新建的设备，在/dev/mapper目录下。

 

 

参考:http://www.stalker.com/notes/SFS.html