从两地三中心到双活数据中心

从两地三中心到双活数据中心

两地三中心
两地三中心的有几种实现形式,下图是一种典型案例。


从两地三中心到双活数据中心
文章图片
在这一案例中,正常情况下,业务运行在主机房的设备之上。主存储与辅存储存在单向同步关系,即主储存的所有数据变更都会实时同步复制①到次存储上,从而保证两个存储数据完全一致。同时,为防止极端灾害发生,主存储的数据变更也会通过异步复制②的方式同步到远程容灾机房的存储设备上。
当主中心因为各种原因中断服务时,可以通过手工命令或者软件自动切换的方式让业务切换到辅机房。同时建立次存储到荣灾机房存储的异步复制关系,保护数据。
如果极端情况发生,辅机房也不能运行业务,那么远程容灾机房还有一份数据保存,可以用它恢复业务。
注意:上图只是一种两地三中心的实现方式,还有好几种其它方式,比如:
⑴远程容灾中心也配置服务器,当灾害发生时容灾中心可以运行业务;
【从两地三中心到双活数据中心】⑵3个存储的拓扑方式不同。但是基本原理差别不大,在此就不做赘述。
两地三中心的优点是防范了各种危害磁盘阵列硬件数据的风险(不包括软件或者人工误删除数据操作),缺点是成本巨高,且设备使用效率低,特别是辅机房设备不能在业务正常运行时使用,浪费很大。为此,存储设备厂商改进了设计,让次存储和冗灾存储变成可读不可写状态,从而让部分业务如BI等运行在辅机房和冗灾机房,分担了主机房设备的负载。
但是这种做法不够纯粹,实施需要主机应用软件配合。而且主辐机房切换需要业务中断数分钟到数小时的时间,前端业务感知不好。
于是存储设备厂商又发展了双活数据中心技术来改进这个缺点。

①同步复制可以保证数据完全一致,但是对数据传输带宽和时延要求都很高,成本昂贵,适用用于近程。
②异步复制不保证数据完全一致,存在数据丢失的情况,但是对数据传输带宽和时延要求较低,适用于远程。

双活数据中心
下面我们以HP XP7磁盘阵列与ORACLE RAC配合为例,展示这个技术方案。


从两地三中心到双活数据中心
文章图片
这个方案里,主辅机房里面的主机可以同时访问主辅机房的存储,这样两个机房的主机和存储与ORACLE RAC技术配合,共同为业务提供服务。
那么两个存储的数据一致性又如何保证呢?XP7技术方案的核心在于:两个存储配合,虚拟出一个磁盘阵列(类似于主机集群软件的浮动软件包技术),主机向虚拟磁盘阵列发出IO请求,主存储和辅存储合作,共同完成主机对虚拟磁盘阵列的IO请求。主辅存储数据双向同步,通过阵列内部机制保证数据一致性。
当主辅存储任一出现问题时,幸存的阵列会继续支持虚拟阵列服务,主机感受不到虚拟阵列的后台状态变化。再配合oracle RAC提供的数据库集群功能,可以实现应用无中断运行,前端基本无故障感知。
这个方案的优点在于两个机房的主机都只看到一个虚拟磁盘阵列,两台存储的内部同步机制完全对主机透明,主机应用配置简单。
由于主辅存储有一定的物理距离,如果数据同步链路故障,比方说国内常见的修路挖断光纤的状况,就会出现“脑裂”的情况,这时候,仲裁磁盘起作用的时候到了。
仲裁盘是独立于主辅存储的第三个磁盘设备(不建议用容灾机房的存储),通过FC链路与主辅存储连接。当主辅存储的数据链路出现异常时,主辅存储会通过仲裁盘决定哪一个存储继续提供服务,不提供服务额存储会进入锁定状态,一直等到数据链路恢复,两个阵列数据同步完成之后再恢复正常。
那么,如果仲裁盘失效时,会出现什么情况呢?很简单,两个存储都锁定,不提供服务。毕竟数据的完整性是最重要的。
图中的仲裁服务器又是做什么的呢?顾名思义,它是一台服务器或者虚拟机,上面运行专用程序为主辅存储提供基于IP协议的仲裁服务。
对于HP XP7或者HDS G系列阵列而言,是不需要图2中的仲裁服务器的。但是,有些设备厂商基于各方面考虑,不使用磁盘仲裁,而是仲裁服务器,比如EMC Vplex或者netapp。
此外,有些厂商的方案没有使用虚拟存储的技术,而是把两台物理存储暴露给主机,然后在阵列上通过其它办法实现两个阵列的数据同步。这种办法我有一些疑问,希望以后能得到高人指点
还有,市场上不仅有基于存储实现的双活,还有基于主机软件实现的双活,如果做得好,都是可以满足需求的。但是有一点需要特别注意:就是“脑裂”状况的处理,我认为:没有第三方仲裁设备的双活方案都是不够强壮的,可能难以应付现实环境下的复杂状况。
除了“脑裂”,方案设计者还要考虑“锁竞争”问题:当主辅机房链路中断后,存储有仲裁机制,oracle RAC也有自己的仲裁机制,如果出现RAC锁机制判定主机房设备继续提供服务,存储却判定辅机房存储继续提供服务情况,就会导致“双活”变成“双死”。
这种情况对于某些应用软件或者非磁盘仲裁的存储设备可能是一个需要费一番周折才能解决的问题,但是对于本例中的XP7+RAC,我们是可以通过如下配置来避免这种情况的发生:
因为RAC的仲裁机制使用的是磁盘,我们只需把仲裁盘配置在虚拟的磁盘阵列上就可以避免“锁竞争“的情况发生。因为RAC仲裁盘在虚拟阵列上,主或辅存储任意一个被锁定,它对应机房的主机也就不可能访问得了虚拟阵列上的锁盘,自然不可能得到仲裁盘的认可,也就不能继续运行了。
注:本文最早由我与2016.05.02发表于51cto博客

    推荐阅读