Linux内核工程导论——存储：分布式存储

文件系统

使用

         文件系统是用来存储文件的，而文件一定是有属性的。但是不同文件系统的属性可能不同，但也有共同的（例如创建时间、大小），而很多文件系统的属性（或者说是文件的属性）都是可选的功能，例如atime（access time），访问时更新，很多时候用户都不会用到这个属性所提供的功能，又由于其增加了iowait时间，所以很多优化都会将其关闭。而这个关闭是在文件系统层次上的。

         也就是说，当我们使用一个文件系统时，首先要知道该文件系统都有何属性，哪些是可选的。然后根据自己自己的需求在挂载的时候打开或关闭属性。

         不但是属性，还有文件系统本身提供的机制。例如日志功能，稀疏存储功能，完整性功能。这些很多都是可以打开或关闭，对文件系统驱动的运行有影响。也都是在挂载的时候指定的。文件系统驱动会根据指定的功能开关决定是否在合适的时候执行操作。当然，这些特性也是不同文件系统不同，也有共同的。

         这些属性和特性的打开都是在使用mount程序（或系统调用）时候要按照调用的格式指定的。

存储系统

存储形式

         分布式存储系统与单机存储系统的界限不是特别明显，典型的分布式系统是很多地方拥有很多物理分离的存储设备的网络，并且可以容易的扩展。典型的单机存储是在一个pc上的磁盘。

         目前个人用户见到的扩展磁盘的方法一般是光驱和USB接口的外置移动硬盘，最近市场上出现的比较多的是路由器上带的USB接口，通过路由器上的Samba或ftp软件服务为本机扩展存储能力。前者叫DAS，是直接硬件连接的。后者叫NAS，是文件级的网络共享操作。在这两者之间还有一种叫做SAN。DAS一个read调用会首先被文件系统驱动解析为一系列的scsi命令，然后向下发送给sata或者usb连接的存储设备。NAS中的一个read调用不经过本地的文件系统层，而是直接将文件请求通过网络转发到NAS server（一般为samba、nfs），nas server使用自己的文件系统驱动解析请求转换为scsi指令发送给直接连接在nas server的磁盘设备。而SAN则是一个read调用后，首先使用本机的文件系统驱动解析为一系列的scsi命令，然后将这一系列scsi命令封包通过网络发送给san server。san server将这些scsi命令解包出来发送给与自己直连的磁盘设备。

                                     画图

         也就是说das压根不网络发送，san是文件系统解析完后再发送到网络，nas是不经过文件系统解析就直接发送请求到网络。三种不同的逻辑构成了3种分布式存储结构。这些都是为个人使用拓展个人存储的方式。对应的，还有不是服务于个人使用，而是服务于外部任意用户使用的分布式存储系统（公有云和私有云），这种云存储一般是对用户呈现一个接口，仿佛只有一个硬盘，然而其在后端可以动态的连接很多个跨地域的存储设备，带有负载均衡和数据保护的一整套系统。

         DAS常用的物理链路是SCSI、SAS、SATA、USB，SAN一般是专用的存储网络，使用的网络或者是光纤FC或者是以太网、AoE（其他种类慢慢在被淘汰）传输SCSI命令的机制叫做iSCSI，NAS则是在现有的局域网上（一般是以太网）通过cifs、nfs等网络文件系统提供。

存储格式

         前面讲到的都是数据存储的物理形式，没有涉及到太多数据存储的格式。分布式文件系统是一种兼具形式和格式的存储方式，但是分布式存储系统不一定需要使用分布式文件系统，分布式文件系统也可能使用在SAN网络中。存储数据的格式是根据存储的数据的内容来选择的。有非结构化、半结构化、结构化三种。我们可以将平时使用到的文件存储方式都叫做非结构化，虽然他们也有结构。xml是典型的半结构化存储。结构化就是数据库了。

         数据库有很多种，但都是组织为有特定格式的一系列数据的集合。存在的根本目的是存储、查询和修改。数据库本身可以在一台（或多台电脑）组成单独的服务器，提供数据服务。然而这种服务不属于存储的扩展，而是数据的扩展。这种服务像web服务一样，是一种互联网服务，只是服务内容是数据，不同于DAS、NAS、SAN和云存储这些存储能力的扩展。虽然在很多情况下两者能达到的目的是相同的。DAS、NAS、SAN和云存储的存储介质上一般都有文件系统，对用户提供的服务是存储本身，而数据库系统所存储的存储介质上不一定有文件系统，对用户提供的服务是抽象的数据服务，不涉及硬件相关。

DAS

         将SATA的部分挪过来

SAN

         SAN一般指专用网络：以太网、FC、AoE等，是独立于其他网络的单独存在。但由于也可以使用以太网，你如果要与局域网复用也是可以的，只要你能忍受带宽的挤占。

         SAN网络的最新宠是iSCSI，其将SCSI命令在IP网络上发送，大部分使用以太网介质。由于Linux的sg模块可以发送原生的SCSI命令给磁盘，所以这个机制在linux上是天生支持的。

         Windows7以后都内置原生的iSCSI Initiator，Linux可以安装scsi-target-utils作为iSCSI target ，即可非常简单的使用Windows像访问本地磁盘一样访问Linux的磁盘。

NAS

分布式存储系统

         从存储的意义上讲，分布式的存储系统根据要存储的数据的内容不同分为分布式文件系统、分布式表格系统、分布式键值系统、分布式数据库。其中与DAS、SAN、NAS等位于同一个层次的是分布式文件系统，描述了数据的组织形式。分布式键值系统、分布式数据库、分布式表格系统都是在已有的数据组织形式基础上设计的上层存储和访问方式。是一整套的数据接口和封装。

集群

集群是一组（>2）相互独立的，通过高速网络互联的计算机组成的集合。群集一般可以分为科学集群，负载均衡集群，高可用性集群三大类。

科学集群是并行计算的基础。它对外就好象一个超级计算机，这种计算机内部由十至上万个独立处理器组成，并且在公共消息传递层上进行通信以运行并发应用程序，像中国的银河，曙光超级计算机。

高可用性集群，当集群中的一个系统发生故障时，集群软件迅速作出反应，将该系统的任务分配至集群中其它正在工作的系统上执行，通过消除单一故障点和节点故障转移功能来提供高可用性，次节点通常是主节点的镜像。

负责均衡集群将服务请求分摊处理到集群中的多个节点上。如软件型LVS，硬件型F5。

在实际生产环境中，这三种集群相互交融，如高可用性集群也可以在节点之间均衡用户负载。

分布式文件系统

         由于分布式文件系统具备解析文件系统的能力，又需要组织成一个整体，所以其天然的具备SAN的特性（文件系统逻辑在本机，scsi命令在网络）。所以一般分布式文件系统都运行在SAN网络上。

         在用途上，分布式文件系统一是用于作为典型的文件系统存储非结构化的数据（文件），还有一个很重要的用途就是作为分布式表格系统的持久层。分布式表格系统像表格存储的关系型数据库，但是又不同于分布式的数据库系统。分步式数据库是一个数据库的拓展，一般拓展能力有限，除非是专门为分布式设计的数据库。可见的数据库系统大部分是单机存在的，或者是存在多个，做负载均衡。而分布式表格系统时一个分布式的整体，其分布式本身就是系统的一部分。

         分布式文件系统主要要考虑和解决的问题如下：

l  怎样组织各台电脑（一般为C/S）

l  怎样避免系统访问瓶颈

l  怎样做负载均衡

l  怎样组织数据（例如一个文件拆分同时写入多个节点）

l  怎样处理节点的不可用性和可用性（上线掉线问题）

l  怎样回收存储空间（移动使紧凑，或者垃圾回收）

l  怎样保证数据的完整性（保存多个备份）

l  怎样处理并发访问

         所有的分布式文件系统无非是对这几个问题提出不同的解决方法组合。

GFS

GFS是谷歌文件系统，主要为谷歌的内部使用优化。在谷歌的内部部署了大量的GFS文件系统节点，很多作为底层的存储结构服务于Google Bigtable分布式表格系统。被广泛使用的Hadoop系统的底层就是使用的hdfs文件系统，该文件系统是用户空间用java写的，但是实现的逻辑却是gfs的。也就是说hdfs是gfs的通用版本的实现，gfs是基础。最新的版本时gfs2，运行在san上，后面都说gfs2。还有值得思考的一点是，gfs是一个分布式文件系统，而hdfs则是用来组件云存储系统的云文件系统。虽然本质上差别不大，但是其在可扩展性和跨地域处理等问题的处理上是必然有区别考量的。还有一点就是gfs2是红帽开发的，并不是谷歌，gfs被开源后，任何人都可以修改，红帽在很多人对gfs做了很多改进后，集大成的推出了gfs2，并且提供了一整套用于搭建gfs2可用存储集群的工具，这个套件叫做RHCS（REDHAT CLUSTER SUITE）。

GFS的最显著的特点是可以单机存在。与所有其他文件系统一样，无非就是一系列inode和一系列存储块。一个文件（目录）是一个inode，在gfs2中日志也是以文件的形式存在的（inode），gfs则是专用的存储空间。

本地的大部分文件系统的写操作因为对断电的担心都开始支持日志功能，更何况是不知道另一个节点什么时候会掉线的网络存储架构。所以gfs对日志的支持是必要的。GFS中是3层的架构，master管理文件到chunk server的映射（chunk是64MB大小的数据库，没有格式，但是组合多个chunk为一个连续的文件就具备了文件的格式），chunk server负责管理chunk和备份和查询修改。也就是说用户向master查询到哪里可以找到对应文件的数据，master指定chunk server为用户提供响应，用户之后则可以直接从chunk server那里获得需要的信息了。chunk server具备管理能力必须是在master的授权之后，这个授权有一定的时间限制，到期了就要续租。

画图

解决分布式系统通用问题方法

GFS回答分布式文件系统的需要解决问题的答案是：

l  组织：采用C/S架构，一个chunk master负责维护总体的文件存储信息（目录和chunk基本信息），chunk副本的位置信息、文件到chunk之间的映射。多个chunk server负责持久化的记录chunk副本的位置信息，处理用户的数据请求。更多的存储节点，受chunk server调度，用于存放实际的数据。可以看出是3层的存储架构。其中第三层一般是直接连接在chunk server上的磁盘。

l  瓶颈避免：用户访问向master查询存储信息，然后再向查到的存储数据对应的chunk server直接请求。并且会缓存这种对应关系，之后的访问不需要查询master。chunk server会决定使用主数据或者是哪个副本进行响应（chunk server会维护副本的一致性）。

l  负载均衡

l  组织数据：一份数据完整的存储于一个节点，但可以有多个节点存储该数据的拷贝（并没有将）

l  可用性：每一份数据在多个节点并行保存多份拷贝（默认3份）

l  数据回收：

n  只采用追加操作，极大的精简逻辑，但是会带来很多废旧数据。

n  或者掉电机器再次上电，发现其存储的内容与其他拷贝不一致等很多情况，都会触发整个系统的数据回收机制。数据回收的方法无非就是移动有用数据和清理无用数据。

n  当删除数据时，并不是直接删掉，而是只是标记，待到系统不忙的时候再慢慢启动回收机制回收。

l  数据完整性：

n  保存多个备份容易，维护多个备份困难。如何有效的维护多个备份，例如在写的时候gfs客户端会将要写的数据发送到所有拷贝节点后才出发写操作。多个备份必须要同时写成功。

n  还有就是容错能力，这就需要日志系统的支持，这也是支持原子操作的手段。

n  还有master的备份，叫做shadowmaster

n  提供快照功能使数据容易回朔。这里的快照设计的非常精巧，直接利用写时复制的特性，增加对chunk的引用即可。如此后续对chunk的修改都会发现原始的chunk有人使用，而新建chunk在新的chunk上修改。快照时刻的chunk得以永久保存，随时回朔

l  并发访问：

缺点

         一个文件系统必然服务于创始人的某些目的，谷歌的文件系统设计也就必然服从于谷歌的需求。例如其追加写，延迟删除，64MB的chunk大小，磁盘利用率很低，但显著精简了逻辑，提高了效率，虽然有回收机制，但是这是以空间换时间的做法，不适合小型的分布式系统。

         多少分拷贝的数目可以自己确定，然而分布式系统中节点的断线上线的频率不一样，有的甚至是区域不一样的。这种一刀切的方法无法适应所有的情况。但是却是通过调整这个值可以适用在大部分情况了。虽然多份拷贝会影响速度，但gfs的设计上已经尽量的减小这个影响：适用异步的更新拷贝，chunk server会负责更新拷贝，而用户对数据的操作却不会因此而阻塞。但这都是在预定的机制下进行优化的方法。

         gfs是为通常的不稳定情况设计的。例如在选择初始存储节点时，会选用负载较低的，而副本又会避免在同一个机架（避免同时崩溃），还有可能在使用的过程中重新复制副本（例如损坏）。而这些策略，例如在所有机器都在一个房间放置的分布式系统中是值得商榷的。

         这些也都不能算作是缺点，只是通用就无法最高效的特用，最高效的特用就无法通用，这是所有系统的难题。在使用中要时刻告诉自己：现在的性能不是最好的。

RHCS（REDHAT CLUSTER SUITE）

通过上面的介绍我们可以发现，gfs的使用者不能像使用传统分区一样使用，必须要有专门的知识。谷歌也有这个号召力让用户去专门为使用他的系统更新自己的客户端。其实这也就决定其不是为个人用户使用而开发的文件系统。gfs文件系统的存在必然伴随着存储服务，或者是云存储，或者是云数据服务。

因此就需要配套的以gfs为底层依托提供云存储服务的套件程序。红帽合并优化了对gfs的修改并且创造了配套的程序后推出了RHCS服务套件。

RHCS提供了集群系统中三种集群构架，分别是高可用性集群、负载均衡集群、存储集群。但是不要理解为其包含这三个组件，而只是这个系统实现了这三个概念。其实原始的gfs也内涵了可用性检测、负载均衡的思想，但是做的不够专用的工具优秀。

组件

集群性

高可用性集群

高可用集群是RHCS的核心功能。当应用程序出现故障，或者系统硬件、网络出现故障时，应用可以通过RHCS提供的高可用性管理组件自动、快速从一个节点切换到另一个节点，节点故障转移功能对客户端来说是透明的，从而保证应用持续、不间断的对外提供服务，这就是RHCS高可用集群实现的功能。

负载均衡集群

RHCS通过LVS（LinuxVirtual Server）来提供负载均衡集群，而LVS是一个开源的、功能强大的基于IP的负载均衡技术，LVS由负载调度器和服务访问节点组成，通过LVS的负载调度功能，可以将客户端请求平均的分配到各个服务节点，同时，还可以定义多种负载分配策略，当一个请求进来时，集群系统根据调度算法来判断应该将请求分配到哪个服务节点，然后，由分配到的节点响应客户端请求，同时，LVS还提供了服务节点故障转移功能，也就是当某个服务节点不能提供服务时，LVS会自动屏蔽这个故障节点，接着将失败节点从集群中剔除，同时将新来此节点的请求平滑的转移到其它正常节点上来；而当此故障节点恢复正常后，LVS又会自动将此节点加入到集群中去。而这一系列切换动作，对用户来说，都是透明的，通过故障转移功能，保证了服务的不间断、稳定运行。

存储集群

RHCS通过GFS文件系统来提供存储集群功能，GFS是Global File System的缩写，它允许多个服务同时去读写一个单一的共享文件系统，存储集群通过将共享数据放到一个共享文件系统中从而消除了在应用程序间同步数据的麻烦，GFS是一个分布式文件系统，它通过锁管理机制，来协调和管理多个服务节点对同一个文件系统的读写操作。

配置文件管理（CCS）

Clusterconfiguration system 简称CCS，主要用于集群配置文件管理和配置文件在节点之间的同步。CCS运行在集群的每个节点上，监控每个集群节点上的单一配置文件/etc /cluster/cluster.conf的状态。当这个文件发生任何变化 时，都将些变化更新至集群中的每个节点上，时刻保持每个节点的配置文件同步。

Cluster.conf是一个XML文件，其中包含集群名称，集群节点信息，集群资源和服务信息，fence设备等。

分布式集群管理器（cman）

Cluster manager 简称CMAN，是一个分布式集群管理工具，运行在集群的各个节点上，为RHCS提供集群管理任务。

它用于管理集群成员、消息和通知。它通过监控每个节点的运行状态来了解节点成员之间的有关系。当集群中某个节点出现故障时，节点成员关系将发生改变，CMAN及时将这种改变通知底层，进而做出相应的调整。

CMAN根据每个节点的运行状态，统计出一个法定节点数，作为集群是否存活的依据。当整个集群中有多于一半的节点处于激活状态时，表示达到了法定节点数，此集群可以正常运行，当集群中有一半或少于一半的节点处于激活状态时，表示没有达到法定的节点数，此时整个集群系统将变得不可用。

CMAN依赖于CCS，并且CMAN通过CCS读取cluster.conf文件。

锁管理（DLM）

Distributed LockManager，简称DLM，是一个分布式锁管理器，它是RHCS的一个底层基础构件，同时也为集群提供了一个公用的锁运行机制。DLM运行在每个节点上,GFS通过锁管理器的机制来同步访问文件系统的元数据。CLVM通过锁管理器来同步更新数据到LVM卷和卷组。

DLM不需要设定锁管理服务器，它采用对等的锁管理方式，大大提高了处理性能。同时，DLM避免了单个节点失败需要整体恢复的性能瓶颈。另外，DLM的请求是本地的，不需要网络请求，因此请求会立即生效。最后，DLM通过分层机制，可以实现多个锁空间的并行锁模式。

栅设备（Fence）

通过栅设备可以从集群共享存储中断开一个节点，切断I/O以保证数据的完整性。当CMAN确定一个节点失败后，它在集群结构中通告这个失败的节点，fenced进程将失败的节点隔离，以保证失败节点不破坏共享数据。它可以避免因出现不可预知的情况而造成的“脑裂”（split-brain）现象。“脑裂”是指当两个节点之间的心跳线中断时，两台主机都无法获取对方的信息，此时两台主机都认为自己是主节点，于是对集群资源（共享存储，公共IP地址）进行争用，抢夺。

Fence的工作原理是：当意外原因导致主机异常或宕机时，备用机会首先调用fence设备，然后通过fence设备将异常的主机重启或从网络上隔离，释放异常主机占据的资源，当隔离操作成功后，返回信息给备用机，备用机在接到信息后，开始接管主机的服务和资源。

RHCS的Fence设备可以分为两种：内部Fence和外部Fence。内部fence有IBM RSAII卡，HP的ILO卡，以及IPMI设备等；外部FENCE设备有UPS，SAN switch ，Networkswitch等。

栅设备实例

当节点A上的栅过程发现C节点失效时，它通过栅代理通知光纤通道交换机将C节点隔离，从而释放占用的共享存储。

当A上的栅过程发现C节点失效时，它通过栅代理直接对服务器做电源power on/off，而不是去执行操作系统的开关机指令。

rgmanager管理

它主要用来监督、启动、停止集群的应用、服务和资源。当一个节点的服务失败时，高可用集群服务管理进程可以将服务从这个失败节点转移至其点健康节点上，这种服务转移能力是自动动，透明的。

RHCS通过rgmanager来管理集群服务，rgmanager运行在每个集群节点上，在服务器上对应的进程为clurgmgrd。

在RHCS集群中，高可用生服务包括集群服务和集群资源两个方面。集群服务其实就是应用，如APACHE，MYSQL等。集群资源有IP地址，脚本，EXT3/GFS文件系统等。

在RHCS集群中，高可用性服务是和一个失败转移域结合在一起的。由几个节点负责一个特定的服务的集合叫失败转移域，在失败迁移域中可以设置节点的优先级，主节点失效，服务会迁移至次节点，如果没有设置优先，集群高可用服务将在任意节点间转移。

 

 

总结

我们发现RHCS根本不关心底层使用的文件系统存储结构，其关心的只是每一台机器本身的管理与调度。所以RHCS系统下的文件系统完全可以全部采用ext4，当然也可以采用分布式的gfs。

那么gfs存在的意义在哪？既然分布式存储系统中，都可以使用单机文件系统完成。首先我们要知道gfs本身就可以作为单机文件系统使用。而gfs本身和RHCS的一些特性重合，例如负载均衡。然而gfs提供了单机存储集群提供不了的特性，比如集群快照、高效的追加操作、默认的备份能力。当然你可以可以用RDBD、RAID等其他机制提供备份能力，但是这些特性是gfs自带的，并且从架构上决定了其成本非常低。用外置工具组装一群ext4为集群放佛一个多国联合作战的联盟军，而使用gfs作用集群文件系统相当于一个单一种族的集团军，战斗力还是有差别的。而且使用ext4（或其他文件系统组成的集群，更像一种nas的扩展，而不是一个云存储系统）。