xSAN高可用—XDFS与SAN融合焕发新生命力

一、背景

在存储领域中，存储系统的高可用性一直是关注的重点。随着用户对于存储系统的可用性需求不断变化，高可用技术在不断发展演变。高可用的方案与技术,可分为如下三种：

磁盘级的高可用

这是指部分磁盘的损坏不影响集群的可用性。常用的实现方法有：RAID、SAN磁盘阵列。

服务器级的高可用

这是指单台服务器的失效，不影响整个系统的可用性。

常用的实现方法为：双机热备；软件层面实现的数据副本（比如SDS中的多副本冗余策略）。

共享级的高可用

集群存储，通常都是通过共享协议的方式将其存储提供给用户，例如SMB、NFS、FTP、S3等。共享级的高可用就是指：在冗余范围内一定数量的服务器在宕机、断电、断网等导致不可用的情况下，整个集群的存储服务仍然能够正常可用。

例如分布式文件系统实现共享服务的高可用的办法通常是：

A)指定好虚拟IP、物理IP，部署好高可用系统，比如CTDB。

B)存储系统运行在HDD/SSD等直联存储设备上，创建副本卷或者纠删卷。

C)在集群每一个节点上对称式启动共享服务，所有节点均可访问共享数据。

只要同一组副本（或者纠删组）中的主机，不可用数量没有超出冗余范围，相应的共享服务就是可用的。

这种服务级别的高可用，一般不能支持SAN共享磁盘。

二、xSAN的优势

xSAN是为XDFS分布式文件系统专门设计的高可用系统，在分类上，属于前述的“服务级高可用”。xSAN综合利用传统SAN存储阵列的磁盘高可用，以及XDFS分布式存储的服务高可用，获得存储高可用的同时，有效提升了存储利用率。

与现有技术相比，xSAN有如下优势：

·XDFS分布式文件系统运行在共享的SAN磁盘上(FC SAN或IP SAN均可)，不需要 设置多副本、纠删码，创建单副本卷即可，基于RAID保证数据安全性。

a）不需要维护副本的一致性, 性能更加优异；

b）不需要做节点级冗余，存储利用率大幅提升；

c）存储架构简单，而且可以利旧SAN存储。

· 系统可用性更高，允许宕机的节点数更多，最多允许宕机N-2个节点。

· 系统稳定性更好，节点故障进行高可用切换，不需要进行数据修复。

· 系统运维更简便，硬盘发生故障，直接更换硬盘即可。

三、xSAN的工作原理

xSAN高可用功能,设计优化了多数高可用无法实现的领域，即后端使用SAN存储的文件系统。

CTDB集群系统监控整个XDFS集群中各个节点的网络状态；通过定时器来触发事件，定时对本节点的服务、设备等进行监控，若状态发生改变，则会将信息与其他节点进行同步，并触发相应的事件进行处理。

xSAN高可用的总体框架如下图所示：

上图示意的XDFS集群是基于SAN存储的2节点集群。

CTDB系统的作用是定期触发各种事件，比如monitor事件、takeip事件、releaseip事件等。xSAN系统根据CTDB系统触发的各种事件，采取适当的动作，比如接管失效服务器、释放服务器等。

01 接管模块

在集群的任何一服务器上，收到CTDB系统发送的事件以后，通过ctdb status命令，xSAN系统可以获知当前的集群中每一个服务器的状态是正常，还是失效。当得知存在失效服务器的时候，xSAN系统根据如下的流程去接管失效服务器:

A)CTDB服务通过事件脚本通知高可用服务去处理事件。

B)高可用服务，挂载SAN存储。即通过iscsi协议把san磁盘挂载到文件系统上。

C)修改XDFS部分配置文件。

D)重启XDFSD（XDFS的管理服务）。XDFSD服务程序随后把失效服务器的存储服务，在本机启动起来。

E)集群中的各个服务器更新配置信息。

02 释放模块

故障节点在修复后，重新加入集群，系统需要将备份节点上接管的资源再恢复到该节点。恢复过程主要步骤如下：

A)修复后的节点，向备份节点发送消息，请求释放资源。

B)备份节点收到消息后，将之前接管的资源释放，并回应释放完毕。

C)修复后的节点,运行接管模块，将备份节点接管的资源重新接管到本节点。

D)向集群中其他节点更新配置信息。

处理流程如下图：

四、难点与挑战

xSAN实现中的真正的挑战主要有两个方面：

01 高可用自身的复杂性

重点是必须保证在任何时间，同一个SAN磁盘，在整个系统中只能被一个节点（服务器）的服务所接管。同一个SAN磁盘，如果被多个节点的服务所使用，那么可能会该磁盘的数据损坏，极端情况下，可能会丢失该磁盘的所有数据。

故此，有如下问题需要解决：集群中每一个正常的服务器都会去接管失效的服务器，但是同一个服务器上的服务，不能被多个服务器接管，如何实现唯一性？

另一方面，当有多个服务器宕机的时候，如何实现负载均衡？比如某个曾经接管过失效服务器服务器，如果它失效了，使用什么样的接管策略才能让负载尽可能的均衡？

xSAN的解决途径：使用XDFS创建了一个全副本的数据卷（也就是说，如果集群有n台服务器，就是n副本），然后挂载到每一台服务器上。在挂载点中，创建一个名为map的相当于数据库的特殊文件。map文件记录了失效服务器被哪一个服务器所接管。

任一个节点通过都map文件来获得自己可以接管的失效节点，其算法如下图：

02 CTDB系统本身功能缺陷与各种bug

CTDB作为一个著名的开源软件，业界有诸多知名的用户。不过它本身仍然存在一些缺陷，比如：事件处理脚本在处理CTDB的事件（比如前述的takeip事件）过程中，随着程序的执行，ctdb status命令输出”集群中每一个节点的状态”实际上是变化的。也就是说事件处理脚本运行中，ctdb系统仍然在跟集群中的其它节点通信，并改变状态。这一特性给事件处理脚本带来很大的挑战。

另外，重启CTDB集群，CTDB服务有可能一直处在start recovery的状态，无法达到正常的状态，当然也就是无法其它的事件，整个集群的高可用也无法正常工作。甚至，偶尔CTDB进程会异常崩溃。

诸如此类，xSAN高可用构建在CTDB之上，它本身的问题影响到xSAN的稳定性。因此，我们需要自己在xSAN内部通过增强开发解决或规避这些问题，才能保证系统的稳定高效。