摆脱网关,让双活存储真正平民化!

DataGuard不是万能的——在容灾规划考虑不够充分的情况下,存储压力过大导致I/O超时可能造成数据库文件损坏;另外,在没有打开Flashback时主库坏块被复制到从库也是无法回滚的。

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

☟☟☟

互备算不算双活?双活为什么比同步复制更怕“光纤抖动”数据库复制与双活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存储为例,除了黄色区域的两套阵列采用同步复制/双活之外,还可以选择在不同位置添加异步复制。一种是“级联式复制”,从明尼阿波利斯的同城容灾中心复制到圣保罗(这里是用近距离来举例);另一种则是“一对多复制(含双活)”,直接从明尼阿波利斯主站点复制到东海岸的新泽西。 

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

 摆脱网关,让双活存储真正平民化!

摆脱网关,让双活存储真正平民化!

来源:ZDNet云计算频道

0赞

好文章,需要你的鼓励

2016

11/04

18:18

分享

点赞

邮件订阅
白皮书