“存储极客”栏目再次与大家见面啦！在这里，只有一位大咖名叫“存储”，它的粉丝我们称为“存储极客”！

存储极客
这是一群存储偏执狂
为存储而生，跟存储死磕
各具独家秘笈
有观点，有碰撞，有干货
从8月18起
做客存储极客栏目
与你分享存储里的那点事儿

甲：我有容灾备份 
乙：我有双活

甲：我有存储虚拟化
乙：我有双活

甲：我有同步复制
乙：我有双活

甲：我有HA高可用
乙：我有双活

甲：我有两地三中心
乙：我有多活
……

如今做灾备这行的，如果说自己没双活解决方案都有点不好意思见客户了。而不少甲方也对“双活”趋之若鹜，仿佛有了这个就一下子高端了… 双活有没有宣传中的那么好？它到底改进在什么地方，或者说解决了什么问题？我先给大家举几个例子。

背景1：双写也算双活？

在今年的vForum大会上，有位用户朋友跟我讨论存储阵列的单点故障。包括前几年某旅游网站在内的双控阵列故障而导致业务中断，尽管是很小概率的事件，却越来越受到人们重视。大家知道主流企业级存储的可用性通常可达99.999%，除了硬盘/SSD RAID保护，控制器、电源和风扇模块都是冗余无单点故障的，但也有人表示遇到过无源背板的问题。此外，商业存储系统的软件可靠性已经相当高了，但也不能说无懈可击。

接着，这位用户提到旁边展台某厂商的双节点存储虚拟化（容灾）网关，认为这个不错。其实这种方案也是有代价的，除了成本之外，要多占SAN交换机（通常这种环境是FC）端口；改变主机端的多路径；可能带来性能瓶颈；以及浪费阵列上的部分软件功能。

当然存储网关有其存在的道理，而真正使我有些无奈的是，有些厂商把这类方案统统称为“双活”——导致部分用户认为2套阵列在一个数据中心内镜像双写的方式也是双活，觉得这个比传统数据保护要更高端之类的…

背景2：卷管理器的镜像

无独有偶，日前我又接到一位用户朋友的电话。他要求RPO=0，即数据不能有任何丢失。传统的存储同步复制又担心切换之后的数据库一致性。这个问题现在还不算突出，因为是Windows+SQL Server环境，而后续计划上Linux+Oracle。有人给他推荐了EMC几十万的设备（我猜可能是VPLEX Local），但我脑筋一转弯，他这次要解决的是单台阵列故障问题（定时备份估计已经有了），如果用Oracle ASM的Normal冗余同时写2个阵列ok不？

卖设备和License的兄弟别骂我啊，从技术角度看，AIX下的LVM等支持镜像的主机端卷管理器健壮性已经足够，对于相对单一的需求有时可以少花点钱。然而，人们普遍认为Linux下的LVM没有这么靠谱，Oracle ASM“双机双柜”要考虑仲裁盘的问题，而且许多用户还有Windows和VMware虚拟机环境。“本地存储双活”究竟是不是一个伪命题？我在本文最后一段将继续讨论这个。

如果扩展到双活数据中心，Oracle ASM理论上可以支持跨站点存储“双写”，组成Extend RAC集群。但是距离长了，效果嘛… 谁试过谁知道。

背景3：双活已经out？人家都玩异地多活了

在今年双十一的购物狂欢节还没结束时，下面这条微博的出现让人一下感觉“高大上”。去O不说，关键亮点在于1000公里以上“异地多活”。按照传统的理解，像金融系统这类数据一致性要求非常高的应用，通常都是100公里以内同步复制（或镜像）的水平，有几家上了真正的双活都还很难说？

为什么我们没有看到国内外传统金融机构，包括四大行在内宣传过这种距离的双活呢（更不要说三活了）？是技术限制，还是业务上没有这个需要？本文也想从纯技术的角度，参考一些公开信息，简单讨论下A厂的双活实现，与人们所谈论的存储、数据库双活有什么差别。

注：本文只代表作者个人观点，与任何组织机构无关，如有错误和不足之处欢迎批评指正。

互备算不算双活？

上面是我画的一个比较典型的草图。H城市有2个数据中心A和B，相距不超过100公里（理论5ms延时），之间有裸光纤连接。A、B之间为了尽可能缩小RPO（恢复点目标）和RTO（恢复时间目标）可采用存储和/或数据库层面的同步复制。位于S城市的数据中心C可能在1000公里之外，由于延时和线路成本一般采用异步复制或者远程备份。

最初A中心和B中心之间是主备（Active/Standby）的，业务等级决定了它不能做降级容灾，B要部署和A相同的全套软硬件。这时问题来了，空闲的待机设备有没有办法利用起来呢？即A和B之间互备，需要注意的是有依赖的业务应尽量在同一个数据中心里，即做好拆分。其次两边的负载都不应超过50%，以保证在发生故障切换业务都跑在一个中心时能够应付过来。

这一点，让我想起了存储控制器之间的ALUA，不是“真双活”但也算比较实用了。

双活为什么比同步复制更怕“光纤抖动”

上表来自我给用户做过的一个咨询建议，其中如有不够严谨和专业之处请大家谅解。这里我们主要看看存储级“双活”和“同步复制”之间的差别，先按RPO=0这种理想的情况讨论。

同步复制可以用脚本来做自动切换，但实际应用中大多数还是选择更稳妥的手动切换；双活理论上切换更简单更快，但缺点是日常维护工作量大，限制多。同步复制和双活都有距离限制，并在较远距离情况下由于延时而对性能明显影响。像Oracle Extended RAC双活集群还要考虑数据库服务器之间的链路带宽/延时。

对于同步复制，无论主备还是互备，A、B中心存储之间的链路不稳定或者中断，可以按照预设的重试/超时策略来处理，LUN（卷）的镜像关系可以暂停，源端存储新产生的数据变化可以暂存，等链路恢复后再重新回到复制状态。因此，仅2个数据中心间的光纤异常不会引发业务迁移。

双活则不同了。由于两端的主机每一次存储I/O都要写入A、B两个中心的存储，一旦链路中断，只能靠第3站点（可以用第三中心C来做）仲裁一端为“活”、另一端不可访问，以保证数据一致性。这时需要访问存储的数据库和上层业务都要切换到一端。

由于同步双活链路中断的代价，比复制要大得多，因此对于闪断（也就是通俗所说的“抖动”）的容忍度可能要放得更宽。这就带来一个问题，在闪断期间，两边的数据都不让写，这对有些应用是比较致命的。

数据库复制与双活

上图我在《存储极客：多方位全面保护数据库》一文中曾经使用过，在一定的距离内，Oracle Data Guard可以实现数据库的redo log同步复制到物理备库，达到RPO=0。ADG备库可以只读打开，并且不能做到与主库严格状态一致（因为有日志apply的时间，会有一点滞后）。

至于Oracle Golden Gate和戴尔SharePlex这样逻辑复制软件，它们可以实现数据库的双活读写，但会有秒级（通常一端数据库的更改反映在另一端至少要1秒）滞后。这样达不到强一致性，用于金融行业帐户等数据库通常是做复制和迁移，双活就不太合适了。此外由于逻辑复制的灵活性，可靠性方面也没有那么好。

至于长距离RAC集群，前面说到了，在许多情况下并不算太实用。

1000公里多活是如何实现的？（这一段仅供参考，主要为了给大家拓展下思路）

经过上文中的讨论，应该能看出传统存储和数据库的双活有着各种限制，下面我们看看互联网企业是如何突破的。

注：上面这段文字来自今年双11之前，指的应该是taobao的双活而不是alipay，使用的数据库可能不是OB。一同作为参考。

首先我们看到了“切片”，也就是说具体到某一时间点应该都是细分粒度的“互备”，当然这种比传统意义上的互备更加灵活。

注：上述文字来自知乎，在此引用仅供参考。

A厂商的双活/多活，不是单纯靠数据库或者存储层技术来实现，与上层业务逻辑之间有着紧密的联系。这对大多数企业和机构来说是很难复制的。

上图中第一句话的前提应该是“1000公里”这样的距离，考虑到双十一期间巨大的交易量，异步复制做到1分钟RPO已经是相当好的水平了。

关于双十一的多活话题，由于我在数据库和应用方面的知识比较有限，就不谈太多了。最后再提一个思考题，有兴趣的朋友可以在文章下面发表评论。

还是回到我在开头画的图。光纤的延时大家都很难突破，对于最终落到数据库里的记录——可能对应的就是帐户里的钱，如果在A中心提交至少会把日志同步写入到B中心才能返回，远距离的C中心可以异步——银行们也大致是这样。至于在C中心提交的业务呢？数据中心内我相信有足够的冗余，那么同城是否也要有一个容灾站点？如果有的话，它的距离又是多远呢？

对更多企业经济适用的双活

上面谈论了一些关于“双十一”高大上的架构，或许只有BAT级别的互联网巨头才玩得动。那么我们再通过实际案例看看存储双活的价值可以有哪些，拨开迷雾，排除掉那些看上去很美而难于实用的。

这里我们拿几个用户来举例，其中技术并不只局限于某家厂商的某款产品。如上图，在生产机房的核心和外围2台戴尔SC8000之间配置了“本地双活”，生产机房到同城灾备机房之间做异步复制（对线路带宽要求降低）。其中核心存储配置SSD+SAS盘，CDP粒度为1小时，快照恢复点共保留3天；外围存储增加了4周之内、粒度为8小时的历史数据回放点，除了SSD之外，大容量NL-SAS应该就是为了存放快照数据的；同城核心灾备存储保留周期1年、粒度为1天的快照，以达到长期数据备份的效果，这里既有NL-SAS保证容量又有SSD+SAS以备接管业务时的性能之需。

这里面除了同/异步复制、高效的快照和自动分层存储技术之外，主要的特点就是本地双活。与本文开头提到的LVM/ASM这些卷镜像相比有什么好处呢？借助Live Volume，配置在2套戴尔SC阵列之间的一个双活LUN，借助虚拟端口和多路径技术，对前端服务器看来就是一个卷。切换到从另一台阵列控制器访问，以及LUN Owner的改变对于上层业务都是无缝透明的。Live Volume双活的实现更加底层，没有LVM/ASM在操作系统和数据库方面的限制。根据我的理解，针对这个场景EMC VPLEX Local等也能达到同类效果，但直接由阵列实现的双活成本更低。

某用户双活数据中心总体架构

支持同步复制和双活的产品不少，但实际部署中我们发现大多数用户还是选择了异步，前面也说了这是距离和传输链路的原因。那么某市工业园区和公安部门同步双活的前提应该就是政府自己铺设的有质量保证的光纤，比租用运营商的可能靠谱一些哦：）我在几年前曾经拜访过这家用户的IT负责人，了解到他们当时已具备在相隔10公里的生产机房（DC1）和容灾机房（DC2）之间，裸光纤上的DCB（数据中心桥接）无损以太网基础设施。

同步复制和双活对生产存储性能的影响会随着距离增加，记得听朋友说某大厂在国内测试的第一个Mirror项目曾下降过70%。那么支持同步/异步在线转换的一个好处就是减少性能影响。在《深入DellWorld2015：SC9000存储软硬件更新解密》一文中可以看到Live Volume已经通过VMware vMSC（vSphere Metro Storage Cluster）的认证，也就是说虚拟机可以跨数据中心做vMotion迁移和HA高可用。在手动触发虚拟机存储迁移时，就可以先将异步复制转换为同步复制以保证不丢数据。

上图中的小字可能看不清，我把关键点用3个红圈标出来，并分别将文字摘录如下：

“数据库应用层SharePlex同步”
“数据库应用存储、虚拟化存储Live Volume同步 保障两中心双活互备保护”
“LXR数据异步复制至灾备中心存储”

这个也符合我们以前的观点，有了存储复制/双活之后，在一些关键应用中，同时进行数据库层面的逻辑或者物理复制保护也是有必要的。

此外，为了保证跨数据中心双活存储的自动切换和避免脑裂，像第三站点仲裁这样的技术EMC、戴尔等厂商也是支持的。

最后，我还想引用一位资深技术专家朋友的话——“产品和解决方案是为用户需求服务的，任何技术都不是完美，只有适用某些场景”。