作者kayyang·2020-03-26 14:22

系统架构师·银行

某城商行基于VPLEX+RecoveryPoint的存储灾备方案

字数 15161阅读 8279评论 6赞 18

**作者简介：** Kay ，现就职于某城市商业银行运维管理团队。曾长期从事主机、存储系统集成实施工作，对 VMware 服务器虚拟化以及 Dell EMC 、 HDS 和华为等存储较为熟悉，参与过多个灾备建设项目，有着丰富的主机存储系统集成和灾备建设经验。

**摘要：** 伴随着城市商业银行业务的快速发展，信息技术在金融业应用日渐深入，信息系统安全稳定运行的重要性日益突出。银行业信息系统的灾备体系建设是保障银行业务连续性的重要防线，是维护银行业信息和网络安全的重要保障机制。 2007  年以来 , 监管机构 陆续发布了保障业务连续稳定运行、规范商业银行信息系统灾难恢复管理的规章制度，明确了商业银行在灾难情况下开展信息系统恢复的要求 , 对商业银行开展灾备体系建设具有重要的指导意义。本文结合某城商银行的实际案例着重介绍城商银行基于集中式存储实现两地三中心灾备建设的方案设计。

# 1.  概述

## 1.1.  项目背景

****

长期以来，由于监管导向和业务连续性要求，国内银行业信息系统普遍强调业务系统的高可用性和高稳定性。经过十多年的建设发展，我行现有系统规模逐渐扩大，在当前的发展趋势下，我行应用系统大量采用 X86  架构服务器 ， Power  小型机主要用于关键 业务数据库，此外 Power 小型机架构平台上还运行着数十套老旧的业务生产系统。随着使 用年限的增加，计算存储资源已经饱和，设备老化严重，进入故障高发期，相关问题亟待解决。

另外随着新一代核心系统项目群的上线，对计算和存储的资源的需求快速增加，并需要重新构建新系统的容灾体系，满足业务连续性的监管要求。

## 1.2.  建设目标

通过新购服务器和存储设备，采用新的架构进行容灾的设计，有望达成本次项目目标： 一是对部分老旧设备升级换代，为业务系统提供安全稳定的生产资源；二是满足新一代核心系统项目群系统的上线计算资源、存储资源需求；三是满足两地三中心的容灾规划建设，最 终实现同城双活 + 异地容灾体系，增强业务连续性保护，较好的满足监管要求。

# 2.  方案规划设计

## 2.1.  原系统架构

原生产环境分为以 X86 虚拟化为主的资源区和以 Power 小型机为主的资源区， 两个资源区资源相对独立，如下图所示：
![](/home/attachment/202003/26/1237705_158520205693545.jpg)

目前 Power 小型机资源区存在的问题主要集中在以下几点：

1 、需要提供足够的资源满足新一代核心系统项目群的系统上线，而 Power 小型机资源区计资源和存储资源严重不足，急需进行扩容。
2 、IBM DS8000 的存储设备老化严重，故障率增高，需要更新换代。
3 、新系统上线后需要重新进行容灾系统的规划设计。

为了解决以上问题，基于 Dell EMC VPLEX+Recovery Point 的架构重新进行小型机资源区的容灾设计，以满足新一代核心系统项目群系统上线的资源需求，并建立新系统的灾备体系，满足业务连续性的需求。

## 2.2.  方案总体设计

****

考虑到同城灾备机房和异地灾备机房建设进度，整个项目分两个阶段进行。

第一阶段，完成存储设备的更新换代，并将原有系统平滑迁移到新的存储，并支撑新一代核心系统项目群系统上线。

第二阶段，完成同城双活 + 异地容灾的灾备体系建设。

最终方案采用 Dell EMC VPLEX Metro+Recovery Point 方案来构建两地三中心数据存储方案。

VPLEX  的关键能力 AccessAnywhere  是通过分布式一致性缓存技术 (Distributed Cache  Coherenece) 来实现，在集群内及跨区域的另一集群间完成缓存数据的一致性；实 现跨主机、跨集群、跨数据中心的访问和在节点之间同步镜像。 VPLEX  通过把控制器的单 个内存系统进行合并以形成分布式缓存。分布式设计可以跨 VPLEX Metro  和 Geo  系统进 行扩展，以提供全局系统的缓存连贯性和一致性。

分布式一致性缓存技术在实现上面，并没有强求所有的 Cache  都保持统一，而是基于目录形式来跟踪细小的内存块通过锁的粒度来加强扩展能力。 每个引擎的 cache  分为本地 Cache ( Cache local ) 和全局 Cache (Cache global) 。

![](/home/attachment/202003/26/1237705_158520253326835.jpg)

读的时候先读 Director  的 Local Cache  ，如命中直接读取；如在 Global  中命中，则 从对应的引擎 Cache  中将其读取到 Local Cache ，再反馈主机；如没有命中，则从本地后 端的存储中读取到 Local  中，并同时修改 Local  和 Global Cache  中的信息与索引信息。

写数据时， VPLEX Local  和 Metro  都采用透写方式。 VPLEX Local  待数据写入后端的 磁盘阵列后，才会向主机回应写完成，而 VPLEX Metro  需要待数据写入两地的磁盘阵列后， 才会向主机回应写完成。 VPLEX Metro  架构下写操作处理如下：

![](/home/attachment/202003/26/1237705_158520258770387.jpg)

1.  主机发送写操作到 VPLEX  的 Director
2.  Director  收到写请求时，将写操作发送给另外一个站点的 VPLEX
3.  Director  先判断是否在 Local 、 Global  Cache  中有对应的旧数据，如没有直接写入 后端存储的 cache ；如有旧数据，先废除 Local 、 Global  Cache  中旧数据再写入后 端存储 cache
4.  写入后端存储 cache ，反馈写操作完成
5.  远端站点的 VPLEX  将写操作结果返回给本地站点的 VPLEX
6.  只有 VPLEX  Metro  的两边的存储都写成功，才会返回主机写操作成功

### 2.2.1.  第一阶段规划设计

****

第一阶段需要将新购的 VPLEX 、 VMAX100K 进行安装并接入 FC 网络，完成数据的迁移。如下图所示：

![](/home/attachment/202003/26/1237705_158520261959826.jpg)

在实施前需要对原有环境进行调研，梳理 FC SAN  网络，并分析原来 IBM DS8000  存 储的 IOPS  和带宽使用情况，规划好 FC  交换机级联的带宽并做到充分的冗余。另外需要梳 理 IBM DS8000  上各个系统 volume  的映射情况。

考虑到银行关键业务系统 7*24  小时提供服务，故如何减少停机时间并平滑的进行数 据迁移是关键。采用 Dell EMC VPLEX  存储网关来进行 DS8000  存储系统的磁盘封装，将应用 系统和数据库接入 VPLEX  的环境，这样 VPLEX  完成磁盘封装和映射给操作系统后，经过 重新识别磁盘可快速恢复业务系统缩短停机时间，经过前期的论证和测试，可在人行的 8  小 时停机窗口完成该操作并恢复业务系统的正常运行。之后再利用 VPLEX  的 Mobility  功能 进行存储上数据的无缝切换。

下面对整个过程分别进行说明：

#### 2.2.1.1.  存储网关接管应用 IO

****

在 VPLEX  环境中，对后端存储系统的磁盘设备采用整盘封装的方式下，可以将应用系 统完整的迁移到 VPLEX  环境中，迁移步骤简述如下：

1.  在主机上，停止应用系统的运行。并进行数据库及重要文件系统内容的备份
2.  停止数据库。
3.  在主机上，停止 HACMP  运行。停止后建议在主机上重新启动 HACMP  进行验证， 如存储单机或 VG  没有加入 HA  资源组，需单独将 VG  varyon  检查，验证 VG  是 否正常，以免封装后出现异常的情况下排错较为繁琐，必要由此造成实施过程中 需要进行回退。
4.  在主机上，删除相应的原存储系统的磁盘设备和 VG 信息
5.  在主机上，安装支持 VPLEX  的 Dell EMC  ODM  软件包 （ Dell EMC.Invista.aix.rte 、 Dell EMC.Invista.fcp.rte ） 和 Powerpath  软件，必要时卸载原阵列的多路径软件
6.  在原 DS8000  存储系统上，取消主机对磁盘设备的访问 （ 可选 ）
7.  在 SAN  Switch  上，删除主机 HBA  卡与原存储系统前端之间的 ZONE 。并增加主 机 HBA  卡与 VPLEX  前端口之间的 ZONE 。
8.  在 DS8000 存储系统上，赋予 VPLEX  对磁盘设备的访问
9.  VPLEX  扫描新分配的后端 DS8000  存储磁盘设备
10.   VPLEX“ 封装 ” 新分配的后端存储磁盘设备。识别 （ Claim ） 新分配的后端存储 磁盘设备。创建 “Ex t ent ” 。将每个新分配的后端存储磁盘设备 ， “ 整盘封装 ” 成一 个 Extent 。
11.  使用 DS8000  封装后的 “ Extent ” 在 VPLEX  上创建 “ 1:1  Mapping  of  Extents to Device” 的 Device
12.  在 VPLEX  上使用 “ 1:1  Mapping  of  Extents  to  Device” 的 Device  创建 virtual volume
13.  主机 HBA  在 VPLEX  进行 Initiator  的注册。 Host  Type ： AIX  主机选择 aix ， Windows  主机选择 default
14.  创建 Storage  View 。在 VPLEX  Cluster  上创建 Storage  View ，添加 VPLEX  前 端口、 Initiator  及 virtual  volume 。
15.  在主机上，识别和配置 VPLEX 的磁盘设备。在 VIOS  主机或 HACMP 上，调整 VPLEX  的磁盘设备的 reserve_lock/reserve_policy
16.  在主机上，启动应用系统和数据库

完成以上步骤后， VPLEX Local 中 virtual volume 逻辑结构如下所示：

![](/home/attachment/202003/26/1237705_158520269359084.jpg)

通过 VPLEX  封装 DS8000  的 volume ，不改变原来 DS8000  上的任何数据，同时原来 的两套 DS8000  之间的 Metro Mirror  保持同步状态，始终保持在两套 DS8000  上各有一份完整的数据。 VPLEX  接入存储环境后， IO  读写方式发生了变化，但该变化对于主机来说 是透明的。

#### 2.2.1.2.  存储数据迁移

****

在上一步已经完成 VPLEX 接管主机的 IO ，要完成存储数据的迁移，需要使用 VPLEX 的另一项功能 Mobility 。

![](/home/attachment/202003/26/1237705_158520274962568.jpg)

VPLEX Mobility  功能，允许无中断地将数据块或设备上的数据移动到同一集群中的其 他数据块或设备，或从一个集群中的设备移动到另一个集群中的设备。利用该功能可以方便的将 DS8000  上的数据迁移到新购的 Dell EMC VMAX100K  存储中。

提前将 Dell EMC VMAX100K  存储接入到 VPLEX  中，按 DS8000  上的卷的数量和容量大 小信息 1:1  的在 VMAX100K  中分配好 Volume ，并将 VMAX100K  中分配好的 Volume  映射给 VPLEX ，由 VPLEX  进行封装。创建 Raid-1  的 device ，然后使用 Mobility 的功能进行数据的迁移。

![](/home/attachment/202003/26/1237705_158520280892444.jpg)
图 . 开始数据迁移

VPLEX 将数据从 DS8000 在线同步到 VMAX 100K ，在数据完成同步后， DS8000 的 device 将会退出，直接使用 VMAX 100K 的 Device 。整个过程对于主机是透明无感知的， 期间无应用或数据库的中断和数据丢失。

![](/home/attachment/202003/26/1237705_158520283081710.jpg)
图 . 数据迁移完成后

#### 2.2.1.3.  配置本地镜像

****

完成数据迁移后，为保证整个架构中无单点故障设备的存在 （  VPLEX  采用了双引擎 4 个 Director  的配置 ） ，在 VPLEX  中配置 Local Mirror ，在两套 VMAX100K  存储间配置镜像，做到存储设备的冗余。

配置 Local Mirror 后， VPLEX Local 中 virtual volume 逻辑结构如下所示：

![](/home/attachment/202003/26/1237705_158520287097560.jpg)

卷镜像创建完成后，当主机对镜像 LUN  下发写请求时，镜像 LUN  会将主机写 IO  同时 转发给两个镜像副本，即对两个镜像副本进行双写操作。当两个镜像副本都写数据成功后， 将写结果先返回给镜像 LUN ，再由镜像 LUN  将读结果返回给主机。对两个镜像副本进行双 写，保证了两个镜像副本的数据一致性。

![](/home/attachment/202003/26/1237705_158520290895452.jpg)

至此，已经完成了 DS8000 存储更换为 VMAX 100K ，并在本中心配置了存储间的冗余。

#### 2.2.1.4.  配置 CRR  数据保护

****

VPLEX 只提供了存储异构虚拟化和镜像的功能， 快照， 复制等特性需要添加 RecoverPoint 实现，所以 VPLEX 的组网方式常常会考虑配合 RecoverPoint 一起使用。 RecoverPoint 提供以下几种复制功能：

![](/home/attachment/202003/26/1237705_158520293985131.jpg)

•  连续数据保护 （ RecoverPoint CDP ）

连续数据保护持续地抓取变化数据并将其保存到本地，保证了本地数据可以恢复到任何  一个时间点而无数据丢失。 CDP  能够在本地群集内的一个阵列或多个阵列中本地复制 LUN 。 请务必谨记，如果本地系统发生故障，则无法访问本地拷贝。

CDP 的写操作流程：

![](/home/attachment/202003/26/1237705_158520305335660.jpg)

1.  应用服务器向 LUN  发送一个受 RecoveryPoint  保护的写请求。拆分器会截取 这个写请求
2.  拆分器拆分了写请求并将它同时发送到生产卷和 RPA
3.  当 RPA  收到写请求时，将确认信息发送回拆分器
4.  RPA  将数据连同时间戳以及任何与该写操作相关的应用、事件或用户生成的标 签一起写入本地日志卷
5.  RPA  成功的将数据存储在日志卷之后，再将它分发到 CDP  拷贝，在分发过程 中保留原来的写顺序

•  连续远程复制 （ RecoverPoint CRR ）

RecoverPoint 远程复制能够将 LUN  复制到远程阵列或群集。 RecoverPoint  远程复 制在同步和异步模式中均可用 ， 并可根据用户定义的策略进行修改。 RecoverPoint  远程 复制还能够执行双向复制。

CRR 的写操作流程：

![](/home/attachment/202003/26/1237705_158520308487863.jpg)

1.  应用服务器向 LUN  发送一个受 RecoveryPoint  保护的写请求。拆分器会截取 这个写请求
2.  与 CDP  类似，拆分器拆分了写请求并将它同时发送到生产卷和 RPA
3.  当 RPA  收到写请求时，将确认信息发送回拆分器 （启动同步远程复制的情况除外 ） 。在同步复制中，确认信息将被延迟直到恢复站点接收到写请求。
4.  当本地 RPA  接收到一个写请求之后，将它与其他写请求绑定，去除重复数据、 排序、加时间戳并打包压缩，与校验数据一起通过 IP  网络传送到远程 RPA
5.  恢复站点收到数据包之后，远程 RPA  校验数据以确保数据包在传送过程中无损坏，然后解压数据
6.  远程 RPA  将数据写入在恢复站点的日志卷
7.  数据被写入到日志卷后，分发到 CRR  拷贝，并保留原来的写顺序

•  并发本地和远程数据保护 （ RecoverPoint  CLR ）

RecoverPoint CLR 并发本地和远程复制能够进行本地和远程复制。它提供了针对相同 LUN 的同步数据块级别本地和远程复制。可以恢复其中一个拷贝，并且不会影响另一个拷贝。它还支持双向复制和任意时间点恢复能力。

充分考虑设备的冗余，避免 VPLEX  出现故障或者 VPLEX  后端存储全部故障后不能进 行数据的恢复，在生产中心未采用 CDP  的保护方式，而采用了 CRR  的方式，将连续性保护 数据放置在独立的存储 （ 未接入  V P L E X ） ，出于成本的考虑，采用 Dell EMC u n i t y 的存储作为 CRR  保护的数据存储。为避免对生产环境的性能造成影响， Recovery Point 使用异步模式 进行 CRR  数据保护。

![](/home/attachment/202003/26/1237705_158520314158214.jpg)

1.  应用服务器向 LUN  发送一个受 RecoveryPoint  保护的写请求。 VPLEX  拆分 器会截取这个写请求
2.  VPLEX  拆分器拆分了写请求并将它同时发送到生产卷和 RPA
3.  当 RPA  收到写请求时，将确认信息发送回拆分器
4.  RPA  将它与其他写请求绑定，将数据写入在恢复存储的日志卷
5.  数据被写入到日志卷后，分发到 CRR  拷贝，并保留原来的写顺序

### 2.2.2.  第二阶段规划设计

**** 建立同城双活 + 异地容灾的两地三中心容灾体系，并完善数据的保护机制，建立多层次 的防范机制，来保障数据的可靠性和安全性。其中存储双活技术只是一个层面，只能在存储 故障或者站点级的灾难时提供数据保护，对于逻辑错误和误操作却无能为力，故需要在建立同城双活的基础上辅以备份技术、数据库复制技术，连续性数据保护技术，建立了完善的数 据保障体系。

![](/home/attachment/202003/26/1237705_158520317223846.jpg)

#### 2.2.2.1.  同城双活

****

同城中心按照信息系统灾难恢复等级 6  级的标准进行建设，按照相关监管要求，最终设 定一类业务系统的 RPO = 0 ， RTO < 30 分钟。为了尽量的缩短业务恢复时间 RTO ，需要减少 人工进行故障分析、并执行人工切换系统的操作，故最终采用 VPLEX Metro+Oracle Extent Rac  的方式来避免在数据层面花费较多的时间执行数据库故障的判断和切换，而应用层面通过前端的负载引流实现应用的高可用。

VPLEX Metro  能够为主机提供跨站点的共享存储，两个站点都能同时读写同一份数据。 VPLEX Metro  下存储的逻辑结构如下所示：

![](/home/attachment/202003/26/1237705_158520321525726.jpg)

Dell EMC VPLEX Metro  打破了数据中心的物理壁垒，允许用户并发访问位于不同地理位置 的数据。采用 VPLEX Metro  的扩展 Oracle Extent RAC  允许访问单个数据库时在多个站点 之间透明地共享工作负载，同时可以在预见到计划内事件 （例如硬件维护 ） 时灵活地迁移站 点间的工作负载。此外，如果发生的计划外事件导致其中一个数据中心中断服 务，则可使 用 Oracle Transparent Application Failover ( TAF)  自动地将出现故障的客户端连接重定 向到仍正常运行的站点上运行的 Oracle RAC  节点。

![](/home/attachment/202003/26/1237705_158520323889639.jpg)

在同城双中心使用 VPLEX  Metro  构建存储双活，在此基础上实现 Oracle  Extent  Rac 。 并在同一中心部署 ADG  的只读库，进行读写分离，主要用于一些报表和没有时限严格要求 的查询类业务。

同时针对误操作或逻辑错误进行规划设计，使用持续性数据保护 + 长期备份归档的的体 系来保障数据的安全。针对数据库的数据保护，使用 Oracle  数据库的数据复制技术 ADG 并结合闪回功能，能够快速回滚到故障发生点，进行数据的查询和恢复，必要时可以将业务 切换到 ADG  数据库进行运行。同时使用备份系统定期进行长期数据备份归档，以满足间隔 时间较长的数据的恢复需求。而应用系统文件系统中的重要数据，通过 Recovery  Point  的 CRR  进行持续的数据保护，同时辅以备份系统进行长期的数据备份归档，在发生误操作或 逻辑错误时可以通过 CRR  快速恢复近期的数据，而间隔较远的时间点的数据可以通过备份 系统进行恢复。

#### 2.2.2.2.  异地灾备

****

异地灾备按照信息系统灾难恢复等级 5 级的标准进行建设，最终设定一类业务系统的 RPO < 15 分钟， RTO < 300 分钟。

在数据库上，关键业务系统数据库采用 Oracle ADG  进行数据库的灾备建设，从生产中 心的 ADG  数据库将数据复制到异地灾备的数据库。而应用系统和其他的数据库使用 Dell EMC Recovery Point  进行 CRR  的数据保护，通过生产中心的的 Recovery Point 将数据发送到 灾备中心的 Recovery Point  进行数据保护。

同时将同城双活中心的备份数据复制到异地灾备中心，满足备份归档异地存放的需要。

# 3.  关键问题

****

两地三中心的建设，是为业务连续性提供服务，在发生故障后，尽最大可能的保障数据 能够被恢复，业务能够快速的恢复服务。因此在整个方案中需要尽可能多的假设各种故障场 景，考虑各场景的应对方案，才能尽量减少在系统运行中发生的预期外的异常，保障系统的 正常运行。

在整个方案中，重点需要关注以下的几个方面。

## 3.1.  仲裁一致性问题

****

VPLEX Metro+Oracle Extent Rac  的方案，关键在于仲裁一致性的设计以及双活中心间链路带宽和延迟。为防止 VPLEX Metro  的仲裁和 Oracle  的仲裁出现不一致的情况，需 要先了解两种仲裁的机制和情况，在考虑如何避免仲裁不一致。

### 3.1.1.  VPLEX  仲裁

****

VPLEX 有一套自己的防脑裂机制：分离规则和 VPLEX Witness 。

#### 分离规则

分离规则是在与远程群集的连接中断（例如，网络分区或远程群集故障）时，确定一致性组 IO  处理语义的预定义规则。在这些情况下，在恢复通信之前，大多数工作负载需要特定虚拟卷集，才能在一个群集上继续 IO  并在另一个群集上暂停 IO 。

在 VPLEX Metro  配置中， 分离规则可以描述静态首选群集， 方法是设置： w i n ne r :c lu s t e r - 1 、 w inne r :c lu s t e r - 2 或 N o  A u t o m at i c W i nn e r （ 无自动优胜者 ） （ 其中， 最后一项指定无首选群集 ） 。如果部署的系统没有 V P LEX W i t n ess （将在下节中论述 ） ，一 致性组设备 IO  将在首选群集中继续，并在非首选群集中暂停。

#### VPLEX Witness

VPLEX Witness  通过管理 IP  网络连接至两个 VPLEX Metro  群集。 VPLEX Witness  通 过 将其自身的观察与群集定期报告的信息进行协调，让群集可区分群集内网络分区故障和 群集故障，并在这些情况下自动继续相应站点上的 IO 。 VPLEX Witness  仅影响属于 VPLEX Metro  配置中同步一致性组成员的虚拟卷，并且仅当分离规则指明群集 1 或群集 2 是一致 性组首选群集时才会影响。没有 VPLEX Witness  时，如果两个 VPLEX  群集失去联系，生 效中的一致性组分离规则将定义哪个群集继续操作以及哪个暂停 IO ，如上所述。仅使用分 离规则来控制哪个站点是优胜者时，可能会在出现站点故障时增加不必要的复杂性，因为可 能需要手动干预才能恢复仍正常运行的站点 IO 。 VPLEX Witness  会动态地自动处理此类事 件，这也是它成为扩展 Oracle RAC  部署绝对必要项的原因。它提供了以下几项内容：

l  在数据中心之间自动实现负载平衡
l  主动 / 主动使用两个数据中心
l  存储层的完全自动故障处理

为了让 VPLEX Witness 能够正确区分各种故障情况，必须使用互不相同的网络接口在独立于任意群集的故障域中安装它。这将消除单个故障同时影响群集和 VPLEX Witness的可能性。例如，如果将 VPLEX Metro  配置的两个群集部署在同一数据中心的两个不同楼 层，请在不同楼层部署 VPLEX Witness 。另一方面，如果将 VPLEX Metro  配置的两个群 集部署在两个不同的数据中心，请在第三个数据中心部署 VPLEX Witness 。

VPLEX Witness  仲裁的场景如下所示：

1 、 Witness  或 Witnes  网络连接故障

![](/home/attachment/202003/26/1237705_158520349699743.png)

2 、 Cluster2 故障或 Cluster2 与 Witness 通讯故障

![](/home/attachment/202003/26/1237705_158520354598774.png)

3 、 Cluster1 和 Cluster2 之间复制链路故障

![](/home/attachment/202003/26/1237705_158520356857080.jpg)

4 、 Cluster1 和 Cluster2 之间复制链路故障同时 Witness 与 Cluster2 通讯故障

![](/home/attachment/202003/26/1237705_158520358972299.jpg)

### 3.1.2.  Oracle  仲裁

****

#### ⽹络⼼跳

⽹络⼼跳主要是确保集群节点间的连通性，以便节点之间能够了解彼此的状态。 ocssd.bin 进程每秒向其他节点发送⽹络⼼跳，通过⼼跳情况确认节点的连通性，以及当⽹络⼼跳出现问题时做出处理。若某个节点的网络心跳在 misscount  指定的秒数中都没有被收到的话，该节点被认为已经 “ 死亡 ” 。在出现集群分裂的情况下，基于简单多数原则，拥有节点数量多的子集群存活。若是节点数一致则 RAC 会选择保留拥有最低节点号节点的子集群。

#### 磁盘⼼跳

如果由于⽹络⼼跳异常，导致集群出现脑裂的发⽣，磁盘⼼跳则帮助解决该问题。 Oracle  集群的每 ㇐ 个节点每秒都会向集群中所有的表决盘注册本地节点的磁盘⼼跳信息， 也就是说，所有的 Voting  File  的信息是相同的。同时会将⾃⼰能够联系的到的集群中的其 他节点的信息，或者说本地节点认为集群中的成员列表信息填⼊到表决盘中。 ㇐ 旦发⽣脑 裂，  CSS  的重新配置线程就会通过表决盘的信息了解集群节点间的连通性，从⽽决定集群 会分裂成⼏个⼦集群，以及每个⼦集群所包含的节点情况和每个节点的状态。如果发现某个节点在指定的时间内没有写入磁盘心跳，这个节点就被判决为死亡。如果一个节点处于未知状态，其他节点也会通过更新它的 voting  disk  上的 kill  block  状态的方式把它驱逐出 集群。

总的来说，网络心跳每秒都会发起，如果一个节点超出了参数 css_miscount time 设 定的时间没有响应，就会被踢出集群。类似的，集群里的每个节点每秒读写 voting disk 特定区域，出现超时响应的节点也会被踢出集群。发生集群分裂的情况下，根据表决盘中的信息，判断集群分裂情况，按照简单多数原则和最低节点号的原则保留活动节点。

### 3.1.3.  VPLEX  和 Oracle  仲裁一致性

****

为了减少脑裂情况的发生并且在发生脑裂时保持仲裁的一致性，在设计时需要遵循的原则：

1 、在设计时将 VPLEX 的 winner cluster 节点和 Oracle 的 Lowest Cluster ID 节点部署在同一个站点
2 、 Oracle Clusterware 文件（ OCR 和表决文件）应部署在 VPLEX Metro 的分布式卷上，使 Oracle 仲裁的磁盘心跳依赖于 VPLEX 的仲裁，以便能够保持 VPLEX 和 Oracle 仲裁的一致
3 、 Oracle RAC 的 misscount 大于 VPLEX Winner: cluster-x delay_time 。
4 、 Oracle Rac 的心跳网络和 VPLEX Metro 的复制网络需要采用冗余设计，避免单点故障的发生
5 、在第三站点部署 Witness ， Witness 与 VPLEX Metro 的两个 Cluster 采用独立的网络连接

在发生双活中心链路中断问题时， VPLEX  先进行仲裁，保留一个站点的 IO  读写 （此过程  I O  会  h a n g ，默认为  5S ） ，假设为  A  站点。另外一个站点的  I O  将被 S u s p ede d ， 假 设为 B  站点。这时无论 Oracle  心跳网络是否正常，则 B  站点的节点都因为不能访问表决 盘将会被踢出集群并重启，而 A  站点的节点继续提供服务。

而在一些特殊的场景下，会发生两个站点都不能使用的情况，如：在 VPLEX  Metro 链路断开后重新恢复时，两个站点的数据正在进行同步，假设从 A  站点同步到 B  站点，这 时若发生 A  站点的故障，则 B  站点由于 Oracle  节点不能对 B  站点的 VPLEX  进行正常的读 写，导致 B  站点的 Oracle  节点也出现宕机，该情况下可能出现数据不完整导致 B  站点的 Oracle  服务需要进行恢复才能提供服务，并且存储数据丢失的问题。针对此类情况，只能 通过其他的保护机制进行业务连续性的保护，如在本方案中除采用 Oracle Extent RAC  外 还使用了 ADG  进行数据保护。

## 3.2.  同城双活中心间链路抖动问题

若出现链路延迟较大或者频繁出现连接中断，都可能会对系统的运行造成重大影响。双活中心的链路质量需要注意的事项：

1.  在进行链路设计时，需要充分考虑链路的冗余。从波分设备、交换机、存储和主机接入都需要进行详细的规划设计，保证任一环节不存在单点故障。而对于不受控的运营商线路，需要同时租用两家以上的运营商裸纤，有条件的话，对运营商的裸纤的路线和进入数据中心的弱电井等进行详细了解，尽量避免存在物理空间 上的交叉。
2.  对链路质量进行检测，包括光衰、延迟、抖动等。最好在双活建设之前进行链路质量的测试和检测，及时发现问题并与运营商进行沟通处理。
3.  做好链路抖动或延迟大的处理预案。当出现链路抖动或者延迟大的情况下，需要按照设计好的方案断开线路，已保障其中一个站点能够正常的提供服务。结合自动化运维监控，在发生该问题时，能够自动切断链路，一边在一个中心正常提供业务。

## 3.3.  性能下降问题

****

由于在存储双活方案中采用双写保证数据的一致性，故对于数据写操作的延迟会增加， 特别是采用 VPLEX  类似的存储网关方案时较为明显。在系统并发写操作大时，写 IO  的延 迟会明显增加，系统的 TPS  将会受到影响。故需要在投产之前做好性能压力测试，已满足 投产后的正常运行。

另外，在 VPLEX Metro  双站点间链路中断的情况下 ， IO  将会 hang  住 5  秒，在这 5s 内产生的会话连接将会消耗主机 CPU 、内存资源，若是每秒 1000  个数据库并发的情况下， 将会产生 5000  个的会话连接，需要根据实际情况估算数据库主机的相关资源，以免在 IO hang 的期间将主机资源耗尽从而导致宕机 。

## 3.4.  运行维护问题

****

双活容灾解决方案将灾难切换变的较为简单，但在实际的维护方面并不简单，除了要求 用户提升自己的维护能力，还需双活容灾解决方案供应商的售后服务能力。

### l  用户自身人员的维护能力必须加强，才具备能力维护跨站点的双活系统。

用户运维人员必须从维护设备的能力转变为具备维护双活系统架构的能力，需要深入了 解双活架构中的各个环节，才能保障系统的正常运行。

### l  双活容灾解决方案供应商的售后服务能力

供应商的服务能力也直接影响双活容灾系统部署后的效果，在许多的案例中，经常看到 供应商提供了 800  电话，但却不能及时安排技术人员现场服务。整个服务过程重复的在收 集日志进行诊断，在问题出现的时候，难以尽快解决问题，这样的方式如何保障双活容灾系 统的稳定？所以后期的有效沟通和及时的技术支持是需要关注的问题。

### l  需要结合运维监控和运维自动化完成双活数据中心的运行管理。

假设双活中心的中间链路出现抖动，导致 IO  延迟大，若没有完善的监控系统，我们发现的时候可能主机已经由于不能正常进行 IO  读写而导致了宕机。即使有监控系统，并且已 经发送告警给系统管理员，但是系统管理员需要登录相关设备进行问题查看，并按照应急的 方案进行处理，这个过程是需要时间的。若是在业务高峰期发生该情况，将对大量的业务交易造成影响，甚至由于宕机而导致一段时间的业务交易不能正常进行。故需要结合运维监控 和运维自动化系统，由系统快速的做出响应。

# 4.  总结

在实际的灾备建设中，常常会听到双活容灾方案可以让生产中心和容灾中心都 “ 活 ” 起来，有效的利用资源，在发生关站点级的故障时，最大化业务系统的可用性，而异地灾备的 建设满足了发生重大灾难性事件时数据恢复和业务连续性的需求。

但是，当我们认真考虑双活 + 异地容灾系统建设时发现，如果自身信息技术人员的维护 能力不足，很难达到我们期望的效果。双活 + 异地容灾涉及多个厂商的产品和解决方案，方案的规划设计、系统集成较为复杂，若没有一支专业的运维团队支撑后期的运行维护，整个方案将不能达到预期的目标。

recoverypoint 银行存储双活城商行灾备 VPLEX 两地三中心双活

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论6 条评论

hfboss技术总监ahzyhl
2020-04-16 00:02

谢谢

hufeng719

系统工程师某钢铁企业
2020-03-31 16:49

文章写得很棒，跟我们存储升级过程中数据迁移非常类似。同城双活+异地容灾很是高大上。运维人员可以喝茶水去了。

zhuqibs软件开发工程师Adidas
2020-03-31 16:19

首先，看第一阶段的内容，基本上就是个阵列的镜像复制，在生产时段复制，需要2边都完成，才返回成功，代价很高，必然是同机房的光纤连接，减少延时。第二阶段，基本上就是Oracle的远程RAC模式，在两个安装存储并同步，两台主机Rac并光纤连接，成本也相当高，楼主的方案中，应该加入成本的核算，毕竟是疫情期间，每家的日子都不好过，而bat也不会采用这种方案。