2018/04/27

摆脱网关，让双活存储真正平民化！

唐僧

点击“戴尔企业级解决方案”快速订阅

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

存储极客

这是一群存储偏执狂

为存储而生，跟存储死磕

各具独家秘笈

有观点，有碰撞，有干货

从2015年8月18起

做客存储极客栏目

与你分享存储里的那点事儿

在写这一篇之前，我们先回顾一下去年的《存储极客：大话“双十一”与经济适用型双活》，其中主要讨论了以下话题：☟☟☟

互备算不算双活？

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

数据库复制与双活

1000公里多活是如何实现的？

多企业经济适用的双活

年纪大了记性容易不好

列出这些供大家参考的同时，也是为了避免自己再写重复的东西。那么这次我有哪些新话题跟大家分享呢？

双活的技术

和非技术因素

上图引用自元鼎时代资深Oracle技术专家李德鹏的分享资料《数据中心双活的前生今世》

几乎每次和同行朋友们讨论双活时，都会有人提出应用层实现更好。从某种角度上讲这没有错，但理想很丰满现实却骨感，一说到要重新开发/调整应用许多用户就开始摇头了。更多的人还是愿意动数据库、存储层，这样简单、牵涉的方面较少，而且在数据层面拆成2份也比较好理解。

不排除有一部分用户是为了“双活”而双活的，而同城乃至本地双存储（双柜）也有其存在的价值。传统中高端企业级阵列普遍能达到99.999%的可用性，但也有人“抽中过彩票”——遇到背板故障之类的小概率问题。尽管这些情况数据恢复的概率比较大（加上有还有备份什么的），但停机时间长了损失受不了。

Salesforce故障

给我们的启示

对于数据库保护和业务连续性，现在不少DBA推崇基于日志的复制（比如的Oracle ADG），而存储复制和双活的适用范围可以更宽。在《Salesforce曝数据丢失原因：存储阵列固件bug？》一文中，我们也能看出DataGuard不是万能的——在容灾规划考虑不够充分的情况下，存储压力过大导致I/O超时可能造成数据库文件损坏；另外，在没有打开Flashback时主库坏块被复制到从库也是无法回滚的。

上图同样来自李德鹏老师的分享资料，里面提到了DataGuard擅长应对的故障，ADG加入了准实时备库只读查询功能，但它还不是真正的双活。因此我们看到越来越多的人推荐同时部署DataGuard和Oracle Extended RAC，虽然后者也不是没有技术上的前提和限制，比如底层存储双活的需求，但RPO=0和最小化RTO的吸引力还是蛮大的。

在Salesforce的例子中我们还看出不同品牌存储的差别，如果有高效的Near-CDP、数据库一致性快照技术，此类故障RPO应该有很大机会缩短至4小时以内。

分布式存储

带来的挑战

随着SDS（软件定义存储）的流行，借助多副本和纠删码技术的分布式集群可以支持节点级的容错。存储服务器节点断网、断电已经成为常规的POC测试项目。对于传统双控存储阵列而言，只能拔一侧的控制器或者电源，当然这并不代表Server SAN的可靠性和可用性就会更高。

上图引用自Veritas资深架构师黄海峰的分享资料《Server SAN的数据保护和容灾》

随着VMware VSAN延伸集群的推出， Server SAN也开始支持真正的双活。从技术角度来看，多副本的机制对于将集群扩展到同城数据中心有些先天便利。尽管只能应用在虚拟化环境，VSAN此举还是显著拉低了存储双活的门槛，使该特性不再一味“高大上”。

没有双活都不好意思出去讲，这大概也是存储双活市场不断扩大的原因吧。

摆脱网关

让双活存储真正平民化

不可否认，EMC凭借VPLEX在存储厂商中率先提出双活数据中心的概念，并且让更多人认识到Oracle Extended RAC这种方案。正如上面的结构图，VPLEX将RAC表决磁盘放到虚拟卷上，简化了数据库体系结构。

使用ASM镜像的存储方案，也就是ASM的Normal和High冗余方式。“ASM Mirror的一个问题是：怎样保证RAC集群的仲裁盘满足投票规则？…即使非超融合的双机双柜也要考虑这个问题。对此有一种解决办法是把仲裁盘放在外部NFS上。”

这份资料描述的就是依赖ASM来搭建远程RAC数据库。A、B、C三个站点各有一套戴尔SC（Compellent Storage Center）阵列，没有使用存储自身的双活。中间的站点C存储上只放OCR和仲裁盘，以满足Oracle RAC防止脑裂的最小需求。

如果使用VPLEX或者存储自身的双活，则无需第三套阵列，对仲裁站点的要求大为降低，而两对VPLEX Metro网关的价格不菲，并且使存储网络变得复杂。如今流行的趋势是阵列自带双活功能，比如VMAX3上基于同步复制发展而来的SRDF/Metro，还有性价比较高的戴尔SC系列Live Volume双活等，都可以配合实现Oracle Extended RAC。

vMSC的Uniform

和Non-Uniform连接方式

除了Oracle之外，VMware是存储双活的另一个主流应用场景。

对于Dell SC而言，防止脑裂、判断“谁活谁死”的第三站点仲裁无需采用SAN或者NAS，只要一个物理服务器，或者运行在云中的虚拟机都可以。

上图引用自VMwrae网站KB文章《Implementing vSphere Metro Storage Cluster（简称vMSC） using Dell Storage Live Volume (2144158)》。在vSphere延伸集群环境中，Dell SC存储双活有两种主机连接方式，这里列出的是Uniform方式，如果去掉红圈部分的两条交叉链路就变为Non-Uniform方式。

在Non-Uniform双活连接方式下，VMware主机可以通过本地Dell SC阵列的控制器来访问另一站点SC阵列Onwer的Live Volume活动卷。这就是存储双活所特有，也是传统同步复制所不具备的技术。

Windows/Hyper-V

双活存储自动切换

Hyper-V虚拟化在追赶VMware大家都是知道的，我们也看到VMware支持的一些存储、高可用特性会不断被微软采纳。戴尔在SCOS 7.1 新版存储软件中，增加了Live Volume双活对Windows、Hyper-V和集群环境的支持。

上图引用自戴尔技术白皮书《Dell SC Series Storage: Synchronous Replication and Live Volume》。配置Live Volume之后的LUN，经过两套存储（Compellent A、B）同时映射到主机后，可以由MPIO多路径软件整合。实际运行中的连接状态，应该可以Active/Standby或者Active/Active的方式。

这两张图截自Dell TechCenter网站上的视频，我们不难看出用于第三站点仲裁的主机（或虚拟机）上安装有Dell Storage Manager管理软件。上面还有LV-AFO支持微软环境的最低网络要求：

▌大于等于1Gb/s连接

▌小于等于5-10ms延时

▌作为仲裁的第三站点到每套Dell SC阵列的往返延时小于200ms

虽然这里的Windows/Hyper-V双活是依赖Dell存储实现，而链路条件与VMware VSAN延伸集群的差别并不大，可见相关技术已经比较成熟。

如上图，Hyper-V集群中的Cluster Disk数据盘和Quorum Disk仲裁盘，都是放在CSV集群共享卷上的VHDX文件，集群共享卷底下就是Live Volume。与VMware环境相似的是，此时Hyper-V虚拟机也可以轻松地在不同站点之间的Windows主机间进行迁移等操作。

两地三中心

双活不等于全部

同城双活，Oracle Extended RAC目前普遍推荐的站点间距离（光纤长度）是不超过40公里；VMware和Hyper-V最远可达100-300公里。网络延时不可避免，规律还是距离越远性能越差。

在两地三中心容灾方案中，除了同城之外一般还需要1000公里以外的灾备站点。这时就需要远程复制或者备份，由于延时和昂贵的带宽基本上只能做到异步。以上图中的Dell SC存储为例，除了黄色区域的两套阵列采用同步复制/双活之外，还可以选择在不同位置添加异步复制。一种是“级联式复制”，从明尼阿波利斯的同城容灾中心复制到圣保罗（这里是用近距离来举例）；另一种则是“一对多复制（含双活）”，直接从明尼阿波利斯主站点复制到东海岸的新泽西。

当然，除了数据保护特性之外，用户一定也不希望双活与存储的其它高级功能互斥，比如快照、自动分层优化等等。

在线咨询

项目咨询

采购咨询专线400-884-6610

热门评论

暂无相关评论