浅谈业内各种主流双活存储技术，以及开源的HA/DR方案
浅谈业内各种主流双活存储技术，以及开源的HA/DR方案
声明
本文为笔者根据自身的项目经验，以及参考大量文档书写而成。文中提到很多厂商的解决方案和概念，第一不方案之间的优劣评判，第二不进行厂商间的相互攻击，第三文中仅代表个人观点，不代表任何厂商的官方立场。
目前业内主流的双活存储技术
双活这个概念，2013年前后比较火热，那时候笔者有幸参与了IBM的一些双活项目，如GPFS A-A，PowerHA/HyperSwap等。因此本文也是有感而发，经验之谈。
谈到双活，首先这是一个很宽泛的概念。广义上说，双活是两个或多个数据中心，每个都具有独立运行生产应用所需要的所有资源。此架构下所有的应用请求会被动态负载均衡到两个数据中心，当其中一个数据中心故障时，另外一个数据中心接管所有的应用请求。
而双活方案在落地的时候，通常是狭义的双活，也就是数据库层的双活，为什么这样呢？首先来讲，随着技术的发展，WEB/APP很多情况下都已经实现了甚至多活；其次，传统意义上的双活方案，通常成本比较高，而用较高成本保护的业务系统，当然是很重要的业务系统。因此，业内主推的双活方案，通过是做数据库的双活。
在线网环境，最主流的数据库毋庸置疑当然是Oracle数据库。而市面上通常的双活方案实现的是Oracle extended RAC。RAC本身就是双活的，只是默认安装在一个共享存储上，不能规避存储的整体故障。Oracle extended RAC是将数据库部署在具有同步复制功能的存储上，这样当一个存储出现故障时候，数据库asm对应的虚拟LUN的路径会实现快切换，指向到另外一个存储，在切换过程中，数据库的数据不会丢失，I/O会hang 20秒左右（看到20s这个数字能默默点点头的读者都是老司机），然后继续。因此通常我们可以称这种方案RTO和RPO都为0。
而如果数据库的数据文件安装在并行文件系统上，当一个节点的存储down以后，那么I/O会迅速切换到该文件系统的另外一个副本上。切换过程中，I/O hang的时间也是类似的。
“双活”方案通常三个数据中心，提供正常服务的站点A，站点B，和提供仲裁作用的站点C，站点C上不保存和提供任何的数据服务。目前市场上所有的双活方案都是如此。
主流的存储双活技术
目前市场上常见的双活EMC vPlex, HP 3Par，GPFS A-A，SVC的双活。对OS而言，要么提供block设备，要么提供共享文件系统，本质上讲，都是某种存储虚拟化技术或者存储复制技术。
我们看一个基于块设备的双活存储方案---vPLEX
基于HP 3PAR的Oracle extended RAC方案：
基于并行文件系统的双活方案----GPFS A-A：
最后看一下基于VMware VSAN的双活存储方案，这也是基于块设备的：
以上几种方案里，孰优孰劣，笔者不做品评，应该说每种方案都有其优缺点。既然存在，就有理由。
Gluster的HA/DR
最近笔者在研究开源的产品。那么基于开gluster有没有类似的AA/DR的方案呢？AA目前暂时没有正式有，但HA/DR是有的。
关于Gluster的基本概念，笔者此前的公众号文章《SDS那么火，你家有没有？》有过一定的介绍，关注gluster操作细节的朋友，可以进行查看。本文后面内容不会过多介绍gluster的基本概念，因此不了解的朋友请自行阅读其他文章。
我为什么提gluster这个方案呢？（https://www.gluster.org/），首先它有很多个好处：
1.支持容量大，扩展性强：
Gluster集群节点数最多可到数千，其总容量在PT级。实际上，gluster作为开源的SDS解决方案，在很多行业都有实际应用的案例，目前Gluster使用范围很广，如存放石油行业，用于存放勘探数据；电视台用于存放影音文件；多媒体超算领域用于存放海量数据。由于gluster是没有元数据的，因此它的扩展性也是非常强的。
2.配置简单、方便、灵活
Gluster作为存储集群，它利用多台X86服务器的本地文件系统，通过服务器之间的以太网络，组成统一对外命名空间（说接地气点就是一个统一mount点，方便用户或应用访问）。本地文件系统类型可以是ext4或者xfs等。Brick的文件系统可以位于一整块本地磁盘/一个分区、本地磁盘组成的Lun/一个分区，甚至也可以是JBOD上的单块磁盘或者共享存储上的LUN，因此配置起来十分灵活。。至于说配置简单方便，读者可以参考笔者以前的文章中：的《SDS那么火，你家有没有？》“6条命令卷配好，8条命令卷可用（被客户端）”的部分。
3.使用场景广泛
Gluster提供多种连接方式，Samba、NFS、FUSE等，linux原生支持FUSE。
gluster既可以给Linux提供共享存储空间，也可以给windows提供共享存储空间；既可以给物理机提供存储空间，还可以给虚拟机提供共享存储空间，并且可以给容器和AWS公有云提供共享存储空间。
Gluster的HA（同步复制）
与传统共享存储一样，本地高可用/双活的基础是数据的同步复制技术。对Gluster有一定了解，或者读过我文章的朋友，应该了解gluster可以设置带副本的卷，副本之间的数据是实时同步的。通过设置gluster卷的数据副本，可以实现本地高可用。
那么Gluster目前是否可以做本地双活存储呢？关于这点，红帽官方还没有发布。但从目前技术上，是可以实现的。笔者相信在不远的将来，该功能能实现。
那么双活关键要解决什么问题呢？有常见的几个（但不限于）：
- 故障域设置问题
- 本地读问题
- 脑裂问题
故障域的设置问题
与vSAN的延伸集群类似，一个Gluster也可以设置不同的故障域，然后将不同的副本放到不同的故障域中。实现这种配置是通过开源项目Heketi来实现的，目前该技术在红帽的Gluster 3.1.3中属于TP的状态。
Heketi（https://github.com/heketi/heketi），是一个基于RESTfulAPI的GlusterFS卷管理框架Heketi的优势在于可以自动在GlusterFS集群确定GlusterFS bricks的位置以保证bricks和它对应的副本均匀分布在集群中的不同可用区，另外Heketi提供的一套RESTful API来实现对GlusterFS集群的各类操作，可以方便的和云平台进行整合，实现容器编排和卷管理的自动化衔接。
Gluster在创建volume的时候，可以设置副本数量。并将不同的副本放到一个集群不同的Zone中，也就是故障域。
本地读问题
主流的双活存储都是能够实现数据本地读的，如HP 3PAR、SVC，软件方式实现如VSAN、GPFS也可以实现本地读。
Gluster作为一个开源的SDS方案，也不例外，通过设置如下参数实现：
#mount -t glusterfs -oxlator-option=cluster.read-subvolume=gv0-client
也可以通过Gluster的storage console的图形化界面实现：
脑裂问题
常见的双活存储，通常是给存储集群设置仲裁。而gluster不仅可以设置存储集群中server端（gluster）的Quorum，还能设置client端的Quorum。
首先，我们知道gluster集群实际上有一个trusted storage pool的概念，所有创建的volume都属于一个trusted storage pool。
Server端仲裁
集群中以设置Quorum比率。gluster的Quorum是通过glusterd服务实现的，这个服务在gluster集群的节点上都会运行。我们设置Quorum比率以后，所有节点的glusterd都会检查好的节点是够高于这个比率。
# gluster volume set all cluster.server-quorum-ratio 51%
设置51%的意思很明显，就是集群中必须有大于50%的gluster节点是好的，trusted storage pool才是正常的，否则这个trusted storage pool会处于offline的状态。
接下来，还有最重要的一个步骤，就是让某个volume参与到server端仲裁机制：
#gluster volume set VOLNAME cluster. server-quo rum-type server
那么问题来了，如果一个集群是偶数个节点，比如两个节点的gluster，我们将仲裁比率设置为51%，那么当一个节点down了，另外一个节点也就须down，数据也就必须必能访问，这样也是必须不成的。
因此，需要设置dummy node。这个节点不包含任何bricks，只参与投票。
dummy node设置也非常简单：
# gluster peer probe DummyNodeName
读到这里，可能有读者会问，通常存储集群的仲裁比率都是设置为大于半数，那么设置比率的参数不就没有意义了么？
这是不对的。
仲裁比率，我们通常设置为51%，但是也可以更高。
我们设想一个场景，三个节点的gluster集群，我们将仲裁比率设置为77%。这种情况，当有一个节点down以后，好的节点数量只有66%，存储池一定会处于offlne的状态，那么怎么办？
很简单，增加两个dummy node。那么现在，存储节点依然是3个，但是仲裁节点是5个。当有1个存储节点down，剩余比率是80%，存储池依然可以访问，当有两个存储节点down，那么存活节点比率变为60%,小于77%，存储池offline。
至于说将仲裁比率设置为多少合适，那需要根据客户现场的实际情况以及业务的中业务重要性进行区分，gluster只是给了用户更多的接口，让用户看到更多的东西，而这点也恰恰是开源的魅力之一。
接下来我们看看client端的仲裁。
Client端的仲裁
这里我们先解释一个概念：复制组 replicate group。它是什么呢？我们举个例子，有一个volume，类型是分布式复制卷，副本数是3。每份数据存在于一个物理服务器的两个bricks上。那么这个volume就有三个复制组，每个复制组有两个bricks，一共有6个bricks。
Client仲裁的作用是什么？在默认情况下，当一个复制组里只有一个bricks是好的的时候，gluster还是允许client修改数据。当出数据中心之间出现网络中断以后，不同的client能够访问到不同的bricks，这时候，不同的client有可能会同时修改不同bricks上相同的文件。这就会造成数据不一致，而当网络修复以后，两边的数据都被修改过，很短判断以哪份为准。
是不是有点绕？举个例子说明一下，有一个两副本的卷，叫volume1，它有两个副本，每个副本有一个bricks，因此这个volume1一共有两个bricks。分别存放在node1和node2两个server上。这个卷有两个客户端可以访问，一个是大卫，一个是小卫。我们知道，当大卫写数据的时候，必须两个bricks的数据都写了，才提示写成功。当node1和node2之间失联以后，这时候大卫向node1上的bricks写了数据，写完以后，node1无法通知node2，本节点上的数据写完了；而同样，如果小卫在node2上写了数据，写完以后，node2也无法通知node1本节点上的bricks写完了，这就会造成数据的不一致。而node1和node2都认为自己是正常的，自己的数据是准确的，要用自己的这份数据去同步到对方的节点上。
那么怎么避免这种情况呢，一个卷有三个副本，每个副本有1个bricks，我们将客户端仲裁的数量设置为3，只有当大卫这个节点能够成功往2个bricks上写数据时，gluster才认为这个写是成功有效的，否则写入失败，返回read only的错误。
这里补充重要一点，在当前版本的gluster下，通过NFS和SMB协议共享的卷，它的写副本是在gluster server端完成的。而通过FUSE协议共享的卷，写副本是在client完成的。而无论是哪种方式，我们都应该避免出现脑裂。
设置最少需要能否写bricks的数量，例如我们设置为3.
# gluster volume set VOLNAME cluster.quorum-count=4而在RHEV和openstack的环境下，这个数据设置成自动即可：
# gluster volume set VOLNAME cluster.quorum-type=auto关闭客户端仲裁的方法：
#gluster volume reset VOLNAME cluster.quorum-typeGluster的异步复制
Gluster的异步复制可以通过Local Area Networks (LANs), Wide Area Networks(WANs), 甚至 Internet进行数据增量复制。
Gluster的同步复制和异步复制对比如下：
异步复制不仅可以实现两个站点之间的卷复制，还可以实现多个站点之间的复制，多份复制有两种方式：
方式1：
方式2：
卷的异步复制配置起来并不复杂：
# gluster volume geo-replication volume1example.com::slave-vol create push-pem 其中volume1是主卷，slave-vol是远端的卷。
配置好以后，启动复制：
# gluster volume geo -replication volume1example.com::slave-vol start
到这里，一定会有读者问，那么异步复制的时间间隔是多少？这个间隔受一些参数的影响：rollover-time、fsync-interval。在gluster中，我们无法直接调整一个参数来修改数据更新时间间隔，geo-replicate默认是以最快的速度进行同步，但如果网络距离较长的话，数据传输要经过互联网，那么同步时间可能会比较长，期间Geo-replication会一直保持Starting的状态。状态由Starting转为OK表示数据同步过程结束。通过调整这两个参数，可以影响同步的性能：
一个红帽客户使用gluster做异步复制的案例，我们可以进行参考：
总结：
截止到目前，读者应该大致了解了Gluster的同步复制和异步复制的机制。如本文开明宗义所述，任何一个方案，都有其适应场景，笔者希望能有更多的朋友一起来研究此项技术，为开源事业一起做出贡献。