mysql双活脑裂_从两地三中心到双活数据中心

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

两地三中心

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

mysql双活脑裂_从两地三中心到双活数据中心_第1张图片

在这一案例中,正常情况下,业务运行在主机房的设备之上。主存储与辅存储存在单向同步关系,即主储存的所有数据变更都会实时同步复制①到次存储上,从而保证两个存储数据完全一致。同时,为防止极端灾害发生,主存储的数据变更也会通过异步复制②的方式同步到远程容灾机房的存储设备上。

当主中心因为各种原因中断服务时,可以通过手工命令或者软件自动切换的方式让业务切换到辅机房。

如果极端情况发生,辅机房也不能运行业务,那么远程容灾机房还有一份数据保存,可以用它恢复业务。

注意:上图只是一种两地三中心的实现方式,还有好几种其它方式,比如:⑴远程容灾中心也配置服务器,当灾害发生时容灾中心可以运行业务;⑵3个存储的拓扑方式不同。但是基本原理差别不大,在此就不做赘述。

①同步复制可以保证数据完全一致,但是对数据传输带宽和时延要求都很高,成本昂贵,适用用于近程。

②异步复制不保证数据完全一致,存在数据丢失的情况,但是对数据传输带宽和时延要求较低,适用于远程。

双活数据中心

两地三中心的优点是防范了各种危害磁盘阵列数据(不包括软件或者人工误操作)的风险,缺点是成本巨高,且设备使用效率低,特别是辅机房设备不能在业务正常运行时使用,浪费很大。

于是存储设备厂商又发展了双活数据中心技术来改进这个缺点。

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

mysql双活脑裂_从两地三中心到双活数据中心_第2张图片

这个方案的核心在于:两个存储配合,虚拟出一个磁盘阵列(类似于主机集群软件的浮动软件包技术),主机向虚拟磁盘阵列发出IO请求,主存储和辅存储合作,共同完成主机对虚拟磁盘阵列的IO请求。主辅存储数据双向同步,通过内部机制保证数据一致性。

这个方案的优点在于两个机房的主机都只看到一个虚拟磁盘阵列,两台存储的内部同步机制完全对主机透明,主机应用配置简单。

由于主辅存储有一定的物理距离,如果数据同步链路故障,就会出现“脑裂”的情况,这时候,仲裁磁盘起作用的时候到了。

仲裁盘是独立于主辅存储的第三个磁盘设备(不建议用容灾机房的存储),通过FC链路与主辅存储连接。当主辅存储的数据链路出现异常时,主辅存储会通过仲裁盘决定哪一个存储继续提供服务,不提供服务额存储会进入锁定状态,一直等到数据链路恢复,两个阵列数据同步完成之后再恢复正常。

那么,如果仲裁盘失效时,会出现什么情况呢?很简单,两个存储都锁定,不提供服务。毕竟数据的完整性是最重要的。

图中的仲裁服务器又是做什么的呢?顾名思义,它是一台服务器或者虚拟机,上面运行专用程序为主辅存储提供基于IP协议的仲裁服务。

对于HP XP7或者HDS G系列阵列而言,是不需要仲裁服务器的。但是,有些设备厂商基于各方面考虑,不使用磁盘仲裁,而是仲裁服务器,比如EMC Vplex或者netapp。

此外,有些厂商的方案没有使用虚拟存储,把两台物理存储暴露给主机,然后在阵列上通过其它办法实现两个阵列的数据同步。这种办法我有一些疑问,希望以后能得到高人指点

还有,市场上不仅有基于存储实现的双活,还有基于主机软件实现的双活,如果做得好,都是可以满足需求的。但是有一点需要特别注意:就是“脑裂”状况的处理,我认为:没有第三方仲裁设备的双活方案都是不够强壮的,难以应付现实环境下的复杂状况。

关于“脑裂”,还有“仲裁竞争”问题:当主辅机房链路中断后,存储有仲裁机制,oracle RAC也有自己的仲裁机制,如果出现RAC锁机制判定主机房设备继续提供服务,存储却判定辅机房存储继续提供服务情况,就会导致“双活”变成“双死”。

这种情况确实是一个问题,可是如果仔细研究RAC的锁定机制,我们是可以通过恰当配置来避免这种情况的发生的,建议如下:

RAC的仲裁机制使用的是磁盘,我们只需把仲裁盘配置在虚拟的磁盘阵列上就可以避免“锁竞争“的情况发生。因为RAC仲裁盘在虚拟阵列上,主或辅存储任意一个被锁定,它对应机房的主机也就不可能访问得了虚拟阵列上的锁盘,自然不可能得到仲裁盘的认可,继续运行。

你可能感兴趣的:(mysql双活脑裂)