·2021-01-12 10:00

系统架构师·金融

商业银行基于华为存储的双活灾备建设及数据迁移方案

字数 9403阅读 6590评论 12赞 13

# 简介：
对于每一个银行信息系统的建设和维护人员，永远绕不开的是如何保障业务的持续稳定无间断运行，最关注的是系统的稳定性，可靠性和高可用性。而“双活”技术，则是构建一个7*24小时稳定运行系统必不可少的技术手段，本文从双活系统的技术选型出发，详细阐述了基于华为存储双活方案、双活建设要求、数据迁移方法等宝贵实战经验。对于想要构建双活系统，又不知从何入手，期望从理论和实践得到指导的IT从业人员来说，是非常有借鉴意义的！

# 1 方案

## 1.1 项目背景介绍
随着我行业务系统的快速发展以及数据量的急剧增加，现网存储系统无论是在性能、可靠性、扩展性还是效率方面，已无法满足当前业务系统需求和未来快速增长的要求；同时现网存储已使用多年，设备老化严重，进入故障高发期，相关问题亟待解决。急需全方位提高存储架构的可靠性和高性能。因此，为支撑业务发展，所建设的高端存储系统，无论在性能、扩展性、可靠性方面要满足业务的发展需要，更要在数据安全性、存储效率、可管理性等方面有突出的表现，以便满足业务快速发展的同时提供更安全、更高效、更性价比的存储服务。

经过多轮业内调研，POC测试等，最终结合业务发展需要，行内认为华为OceanStor存储的双活容灾技术更加适合我行未来5到10年的信息化发展发展规划，我行针对于核心系统容灾，采用华为解决方案，组网相比行内现有环境更简单，可靠性更高。

## 1.2 现状分析
![](/home/attachment/202101/12/1243539_161041552769682.png)

当前两个数据中心采用双引擎VPLEX 存储虚拟化，每个数据中心外挂1台EMC VMAX和1台VNX，实现本地双存储镜像，双中心实现4台存储双活架构，实现4份数据高可靠性冗余架构。

## 1.3 建设目标和要求
本次项目建设的关键目标如下：
（1）老旧设备升级换代，为业务系统提供安全稳定的存储资源。
（2）提升双活数据中心架构的稳定性和可靠性；
（3）提高存储系统的整体性能；
（4）采用国产化存储，提高基础设施国产化比率；
（5）EMC存储数据逐步迁移到新购存储，数据迁移要求在线迁移，业务不中断和用户无感知。

围绕核心业务系统RPO=0，RTO≈0的建设需求，从应用层、网络层、数据层等多方面进行不同方案的比较分析，综合考虑了同城灾备、异地灾备、两地三中心、双活、云灾备等解决方案。经过对恢复指标要求、技术成熟可靠、成本效益高等多方面的综合考量， 拟继续采用同城双活的总体方案和技术架构。

## 1.4 双活数据中心建设要点
**- 网络接入的全局负载均衡**
双活系统的建设，首先要确保客户端能够访问到业务系统，因此在双活容灾解决方案中，用户在网络层做到网络接入的全局负载均衡，确保数据中心的切换过程中的网络接入的无缝切换，才能保证整体业务服务的不间断运行，达到终极的双活容灾方案的实施效果。

**- 业务会话的同步机制**
当前业务会话的同步机制必须依赖于Oracle RAC、虚拟化主机平台VMware的VMotion、DB2 pureScale集群系统或第三方业务会话管理系统等的支持,才能有效的保证业务会话的同步机制，尤其是传统的集群系统必须支持远距离的心跳监测。防止资源争用、业务I/O冲突、均衡请求接入，达到业务层的监测、切换接管。

**- 跨中心的数据同步机制**
双活容灾解决方案跨跃两个数据中心，无论采用应用层、主机层还是存储虚拟化层，都必须达到数据双写的功能。使得两个中心的业务数据实时一致。才能有效的保证数据不丢失及快速“零”切换。

**- 运营一体化管理**
双活数据中心是对等的两个业务生产中心，对数据中心维护人员的建设及双活解决方案提供者的技术支援在双活容灾解决文案建设中不容忽视，使用者必须将两个数据中心纳入一体化的运营管理，包括人员、流程、操作规范等，在技术传递上，也需提升双活数据中心的维护技能。同时也对双活容灾解决方案提供商的售后服务和响应有一定的要求。

**- 现有业务的改造及支持**
当前业务系统存在多样性，因建设时间，建设要求不同，并非所有业务系统全部支持存储双活架构，故如需建设双活数据中心，需要将不支持双活数据中心的业务系统进行改造，如迁移到虚拟化主机平台或者构建冗余的集群系统等，在改造建设中可能会存在一定的风险，需用户容忍新的风险，做好规避风险的措施及补救方案。

## 1.5 存储双活架构的要求
**- 对同城网络的要求**
采用FC链路实现同城双数据中心间的数据实时同步，采用二层以太网络实现双数据中心间主机应用集群的心跳链路通信。为降低数据双写对业务系统的影响，建议同城链路的往返时延在1ms以内。同城链路带宽需求，与需要在两数据中心间同步的数据量相关，要求链路带宽大于业务系统高峰期的数据写带宽。

**- 对仲裁链路的要求**
为保证各种异常情况下，存储双活集群能够进行仲裁，业界存储双活方案都需要设计第三方仲裁站点，以保证异常情况下的业务连续性。

两个双活数据中心与第三方仲裁站点间的链路选择IP网络，大大增加了方案的灵活性，有利于降低方案的整体成本。

**- 应用系统对时延的要求**
双活数据中心的建设不仅是存储一个层面的双活部署，需要端到端地进行考虑。

以下罗列了双活数据中心解决方案的两种典型应用场景对时延的建议：

Oracle应用时延建议：
![](/home/attachment/202101/12/1243539_161041557328993.png)

VMware应用时延
1）站点之间最大支持VMware ESXi管理网络的网络时延是往返10ms RTT 。
vMotion标准版和企业版要求5ms RTT。
vMotion中10ms RTT的延时只有在具有VMware vSphere Enterprise Plus版本许可中才支持，这个版本许可包括Metro vMotion功能。
2）ESXi vMotion的网络需要最少622Mbps的网络带宽，并且有冗余链路。

## 1.6 双活容灾解决方案
最终方案采用华为OceanStor18500 V5、OceanStor18510 V5、OceanStor 5500 V5设备，双活两地三中心+oracle逻辑备库方案来构建生产数据5副本容灾方案。

## 1.6.1方案整体架构
![方案架构图](/home/attachment/202101/12/1243539_161041560344605.png)

存储双活架构描述

双活数据中心的定义是指两个数据中心共享存储、网络以及服务器资源，两个数据中心同时对外提供服务，整个系统具有业务负载均衡和自动故障切换功能。

存储双活作为整个系统的核心基础架构平台，主要解决以下两个核心问题。一是如何在两个数据中心间实现数据实时同步，从而保证异常情况下，零数据丢失（RPO=0）。二是如何实现存储资源的虚拟化，提供可同时被两个数据中心主机访问的存储共享卷，从而实现主机应用集群的跨站点部署，保证异常情况下，应用的自动切换（RTO≈0）。

本次采用华为双活两地三中心+逻辑备库方案，结合我行业务系统特点，打造最适合生产环境的容灾系统，提供安全可信、弹性高效的容灾环境，并具有节约投资、弹性扩展、高可靠、高效、安全等特点。

两个同城数据中心的两套存储互为双活，且都处于运行状态。当一个数据中心发生设备故障，甚至数据中心整体故障时，业务自动切换到另一个数据中心，解决了传统灾备业务无法自动切换的问题，搭配逻辑备库，将主库将日志传输给备库，一旦主库出现问题，备库切换成主库即可持续保障业务。通过该方案架构，本地两个数据中心在提供高级别的数据可靠性以及业务连续性的同时，提更高存储系统的资源利用率。异地数据中心采用异步复制技术，保障关键数据在第三方城市存取的持续性、可恢复性和高可用性。

## 1.6.2方案概述

**存储层**
两个数据中心各部署1台华为OceanStor18500 V5存储，异地灾备部署一台中端存储，两个数据中心的磁盘阵列利用HyperMetro技术对两中心的磁盘阵列做镜像冗余配置，实现两个数据中心存储数据实时镜像，互为冗余，任意数据中心故障，数据零丢失，实现存储层双活架构。另外在在两个数据中心再分别部署1台华为OceanStor 18510 V5存储，同样实现存储层双活架构，主要用于逻辑备库，实现数据库级保护。
- 两个数据中心各部署1台华为OceanStor 18500 V5存储和2台存储交换机，主要运行生产24小时业务系统。
- 两个数据中心在原双活架构基础上再各部署1台华为OceanStor 18510 V5存储，实现存储层双活架构，主要运行生产24小时业务系统逻辑备库。
- 异地灾备部署一台华为OceanStor 5500 V5存储，与两中心存储一部数据复制，实现异地灾备数据保护。

**网络层**
网络层仍然采用原有的思科OTV技术，双中心之间通过OTV设备的联通实现光纤传输协议的以太转换最终实现网层的联通（L2&L3）。

**数据库层**
生产主库采用采用4节点oracle RAC或者DB2 pureScale，每个中心部署两个主节点，结合华为主机多路径软件UltraPath的IO选路策略，本地主机优先访问本地存储，远端存储路径为Standby 状态，规避主机层带来的远距离延时，为主机提供更好的存储访问性能。
由于数据库集群之间的数据传输量非常大（缓存、锁、心跳等），因此在设计上要避免同一应用双连两个中心数据库节点，减少数据库集群内存缓存区交互的情况。相同的应用优先访问4个节点中1个节点，只有当单个节点故障时，才会平滑的访问其它节点。
生产逻辑备库同样采用上述架构，确保主库异常时，快速单库平滑切换。

**应用层**
主要实现方式F5负载均衡、vMotion自动切换、中间件应用集群、PowerHA等方式实现双中心多节点部署。

**链路层**
这一层通过GTM跨数据中心负载引流来实现负载业务的跨数据中心模式。

## 1.7 方案优势和难点
## 1.7.1方案优势
**双活冗余模式**
双数据中心同时对外提供业务生产的双活模式，两个数据中心是对等的、不分主从、并可同时部署业务，可极大的提高资源的利用率和系统的工作效率、性能，让客户从容灾系统的投资中获得最大的价值。
a. 两个生产中心部署相同的业务系统，结合网络层、主机层或应用的负载均衡技术，实现业务系统在两个数据中心并行工作和负载分担。
b. 两个生产中心部署不同的业务系统，互相实时灾备接管。

**自动化恢复，降低管理成本**
双数据中心的双活方案支持两个数据中心的存储故障、业务系统、虚拟化平台异常、云平台计算节点故障等事件发生时的自动化切换，连续对外提供生产。整个灾难切换及恢复业务的过程均无需人工干预，自动化完成，有效的降低企业客户的管理成本。

**数据中心规模在线扩展**
双活方案同时对外提供生产，降低或规避了客户的系统维护的风险，在业务不宕机的情况下在线维护存储阵列、集群节点、虚拟平台等，包括在线扩容，添加业务节点等，达到用户在线扩展的需求。因此，在系统建设初期，客户可以自主选择系统的建设规模，优先满足当前实际业务需求，随着业务系统的发展和对容灾系统需求的增长，灵活的扩展生产系统和容灾系统的规模，以充分保护客户现有投资。

**“零”切换“零”丢失**
双活容灾解决方案核心思想是将本地的双机双柜的解决方案跨两个数据中心建设实施，不仅达到系统级的冗余，包括硬件、数据冗余等，同时也达到了两数据中心之间的业务级冗余。双活数据中心的业务数据是实时同步，且业务数据的镜像相对上层的业务平台透明，所有业务数据的I/O生产都将同时写入到两个数据中心。达到业务数据两份实时副本及在线切换的功能，以实现双活数据中心的“零”切换“零”丢失。

## 1.7.2方案难点
双活容灾解决方案对于集中式管理的数据中心更大限度的保证了业务生产的在线性及有效的防御了灾难性事件恢复业务生产的能力。但实际双活数据中心的容灾方案中，还有以下几个存在极小概率的难点。

**- 脑裂现象**
双活数据中心方案实现了站点级的冗余的容灾解决方案，但是受限于当前的技术等因素，在建设过程中解决了当前面临的业务连续性问题，同时也产生了新的极小概率问题，就是双活解决方案的脑裂现象，在意外事件发生时（例如双活系统的复制链路和仲裁机制同时宕机），此时会发生由于监测技术不到位，使得两个数据中心一体化的业务系统会分裂成两个独立的数据中心。使用户很难取舍哪一个是唯一的生产数据，哪一个是将要废掉的非生产数据。这种情况可以在华为双活实施过程中合理地采用静态优先和双仲裁模式来规避风险。

**- 非“零丢失”，不具备逻辑错误的保障**
双活容灾解决方案的优势强调在健康的运行平台下，大型灾难事件发生是的“零”数据丢失，但是若双活平台本身不健康或者遭遇逻辑故障时，并不能保障数据零丢失。这种故障发生的数据恢复或渐变式灾难发生的情况下，还需借助备份系统的数据恢复手段或方法。因此，双活容灾方案大多数情况下不具备解决软错误的保障，而恰恰这种事件发生的概率远远超过站点级的灾难及硬件故障事件。这种情况不是传统灾备架构和双活架构解决的问题，还是要做好备份规划来实现。

**- 需容忍高可靠性及性能的下降**
双活容灾解决方案虽然提升了站点级的冗余保护，但是，在实际中降低了整体性能。在可靠性方案，双活容灾解决方案就是把本地的双机双柜的硬件冗余方案跨站点建设，无论是传统的集群系统、虚拟化主机平台VMware,还是Oracle RAC等, 在性能方面，站点间的监测、业务会话的同步确认等的网络延迟数，加上数据同步双写的光纤延迟，都或多或少的影响了整体业务处理的性能。距离越远影响越明显，如果距离较近，也会失去建设双活容灾数据中心的意义。

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

a.      自身人员的维护能力必须加强，才具备能力维护跨站点的双活系统，也就是需用户自身人维护人员必须从维护设备的能力转变为具备维护双活系统架构的能力，才能维稳系统的正常运行，让双活系统实现该有的效果。
b.       提供商的服务能力也直接影响双活容灾系统部署后的效果，出现问题往往是多层次排查，除了收集日志还是收集日志，除了正在后台诊断还是后台诊断，经常让一个小小问题需有好多层次的沟通才能解决。

**- 性价比问题**
我们经常会听到双活容灾方案可以让生产中心和容灾中心都“活”起来，有效的利用资源，面临灾难性事件时，最大化业务系统的在线性，解除原有灾备系统有灾无备等等的不足之处。但是，当我们认真考虑建设双活容灾系统时发现，如果自身IT人员的维护能力不足，很难达到我们期望的效果。双活建设是持续性的，必须要保障持续投入和后续的维护经费，使得双活容灾系统向高大上偏移。

# 2 数据迁移
## 2.1 迁移概述

本项目主要是将VPLEX存储虚拟化数据迁移到华为存储，整体迁移原则：
- 迁移到新存储，对应用透明，应用无需调整；
- 最小化应用停机时间；
- 运行数据迁移在业务运行空闲时间段进行。

相关环境如下：
![](/home/attachment/202101/12/1243539_161041568747736.png)

## 2.2 迁移方案
**本项目存储数据从VPLEX 虚拟化到华为存储，完全在线，对业务无任何影响。迁移方法如下：**

**2.2.1 数据迁移工作原理**
主机层卷管理LVM迁移：基于主机卷管理软件的迁移方案可以在不同厂商的存储阵列产品之间进行数据迁移。在迁移的初始阶段将目标存储的LUN映射给主机并加入包含源存储LUN数据的卷组中，利用卷管理软件提供的镜像功能，使得数据在源存储和目标存储之间进行快速的复制，镜像完成后，将源存储LUN从主机卷组中删除，完成数据迁移，数据复制过程中保持业务在线运行。

ORACLE ASM默认rebalance冗余机制迁移：基于ASM磁盘的迁移方案主要是通过ASM往旧的FAILGROUP中添加磁盘，然后从该旧的FAILGROUP中删除旧的磁盘，通过dg默认rebalance，自动平衡各种数据文件，完成数据迁移。数据复制过程中保持业务在线运行，该方案可以实现迁移过程中系统的零停机，但整个操作进度不可控，数据重组过程中我们无法把握进度和风险，需要将磁盘rebalance调到最低，同时在业务空闲时间段进行。

GPFS数据迁移：利用GPFS本身的数据迁移功能在线迁移，在原GPFS文件系统中加入新的nsd，并将nsd加入到相关的fs中，再从GPFS文件系统中删除原来的磁盘，GPFS自动进行相关的数据迁移工作，整个迁移过程在线。

**2.2.2 迁移步骤**
 步骤 1  迁移前，I/O路径为“服务器主机—源存储”；
 步骤 2  将目标存储加入客户的应用系统中，新增链路为“服务器主机—目标存储”。在目标存储阵列上将新建的LUN分配给服务器主机。此操作不需要中断业务系统。具体包括：
1.       物理链路连接（安装华为多路径软件）；
2.       光纤交换机划zone；
3.       目标存储上建立主机组和主机，添加服务器WWN；
4.       目标存储上添加LUN到服务器主机的映射；
5.       服务器上发现目标存储映射的LUN；
步骤 3  在主机上将目标存储LUN对应的物理卷加入到包含源存储LUN的卷组（主机LVM）；通过ASM将磁盘加入到现有的DG中（ASM磁盘形式），通过GPFS将磁盘加入到现有的文件系统中（GPFS磁盘形式），
步骤 4  在卷组内对源数据阵列和数据迁移目标阵列之间进行镜像操作；
步骤 5  确认卷组内数据镜像完成后，将源存储LUN对应的物理卷从卷组中删除；
步骤 6  完成数据迁移；

## 2.2.3 方案特点
步骤 1  对存储兼容性要求低；
步骤 2  对业务系统拓扑改变小，某些场景下可以无中断或中断时间较短；
步骤 3  数据迁移过程中数据复制通过主机卷管理软件进行，会占用服务器主机的CPU、内存等计算机资源；
步骤 4  数据迁移过程中，业务不会中断，可以持续进行，但性能会有一定影响；
步骤 5  无须在现有环境中安装任何软件或代理，方便快捷的进行数据迁移。

## 2.2.4 停机时间和数据复制时间估算
卷镜像为在线数据迁移方案，此方案数据迁移时间分为数据复制及停机更换多路径时间两部分。数据迁移时间为在线数据复制时间，此时间段内业务继续运行，为在线数据迁移。
**
数据复制、停机时间估算方法：**

数据复制（在线）：此步骤时间可以由总容量/迁移速率来评估，卷管理迁移方案一般可以按60MB/s来估算，例如1TB数据，同步时间为1TB*1024*1024/60MB/s/3600秒每小时=4.854小时。

## 2.2.5 使用建议

- 建议在主机业务非高峰期进行迁移。
- 主机集群为并发集群并使用LVM的场景下，需要在单节点下进行迁移，迁移完成恢复集群正常运行状态。

## 3 存储故障场景
## 3.1 上线前测试场景
**- 单存储故障**
•中心1存储在正常情况下突然掉电，中心2存储提供服务，此场景下不影响主机业务，切换过程中，主机业务IO  hung 12秒（原有产品超16秒）。业务层无需干预，恢复正常。

**- 复制链路故障**
双活复制链路在正常情况下突然断开，数据中心1存储对外提供全部业务，数据中心2存储对外不提供业务，切换过程中，主机业务IO  hung  10秒（原有产品超11秒），业务层无需干预，恢复正常。

**- 仲裁服务器故障**
仲裁服务器在正常情况下突然关闭，双活存储默认将仲裁转为静态优先模式，不影响主机业务，无hung情况。

**- 主机到数据中心1存储链路故障**
主机到数据中心1存储链路在正常情况下突然断开，数据中心2存储对外提供全部业务，数据中心1存储对外不提供业务，切换过程中，主机IO  hung 4秒，业务无需干预恢复正常。

**- 仲裁、两个数据中心存储间复制链路相继故障（极端场景）**
仲裁服务器在正常情况下突然关闭，双活存储默认将仲裁转为静态优先模式（5秒内完成切换），不影响主机业务，无IO悬挂。复制链路在此时突然断开，数据中心1存储对外提供全部业务，数据中心2存储对外不提供业务，切换过程中，主机业务IO hung 10秒，业务无需干预，恢复正常。

**- 仲裁、两个存储间复制链路同时故障（极端场景）**
仲裁服务器在正常情况下突然关闭，同时复制链路突然断开，两个存储、仲裁之间无法互相通信，为保障数据一致性，两个存储将同时停止对外提供业务，将由人工确认主站点（确保数据安全性）后继续提供业务。

**- 控制器模块故障**
B控制器故障，不会导致主机业务中断，主机业务能持续运行，此时业务压力由A控制器接管，发生故障时，IO hung 4秒，业务层无需干预，恢复正常。

**- 接口卡模块故障（卡部署在双控）**
B控制器接口卡故障，不会导致业务中断，主机业务能持续运行，发生故障时，IO hung 4秒，业务层无需干预，恢复正常。

**- 接口卡模块故障（卡部署在单控）**
A控制器外接2张接口卡，当其中1个接口卡故障时，不会导致业务中断，发生故障时，IO hung 4秒，业务层无需干预，恢复正常。

# 4 总结
对于银行核心业务来说，对数据中心的要求也不再只停留在生产中心瘫痪时启动灾备中心，保证关键数据的绝对可靠还远远不够，业务连续运行已经成为普遍性的诉求。双活容灾系统具有站点冗余、自动接管的优势应运而生。

本方案遵循可用性、先进性、开放性、易维护性、扩展性等设计原则，严格按照国家和行业IT规范，兼容各主流设备和业务系统厂商。从双活整体架构出发，对各个模块化组件进行了详细设计，使整个双活体系做到了层次化和组件化，使接管更具备灵活性。同时老旧设备数据迁移过程，完全透明，完全在线，对业务无任何影响，做到了业务连续性最大化。最终华为存储容灾解决方案上线后，既解决了原有系统组网复杂，故障率高的问题，又以新技术、新方案、新产品的角度，提高了核心业务系统，特别是核心数据库的响应速度。在很大层度上满足了我行未来几年的信息化发展。截止到目前，整体设备上线已运行两年有余，帮助完成容灾切换数次，避免了长达数小时的业务宕机风险，充分发挥了双活容灾架构的优势，更大限度的保证了生产业务稳定运行及有效的防御了灾难性事件恢复业务生产的能力。

oceanstor 18500 OceanStor 数据迁移双活灾备

著作权归作者所有

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

添加新评论12 条评论

hfboss技术总监ahzyhl
2021-07-18 14:25

很有指导意义，谢谢

quan客户代表上海昆联
2021-07-17 17:44

非常有用，学习了

quan客户代表上海昆联
2021-07-17 17:44

非常有用，学习了

lunna163售前best
2021-01-27 15:03

可以参考

sxitsxitit技术咨询顾问18M
2021-01-18 09:26

有三个问题哈 1、我们在讨论双活的时候一定是考虑了距离带来的时延。据了解，同城跨数据中心做存储双活，距离最好在50公里以内，否则性能扛不住。请问您们两个数据中心的距离多远？两个数据中心间往返的时延是多少？ 2、您所描述的方案我没有太明白，不知道我这么理解对不对。数据中心DC1 有两台存储18500_1、18510_1 ；数据中心DC2 有两台存储18500_2、18510_2 ；异地数据中心是DC3，采用中端存储。其实是搭建了两个双活环境，给两个不同对业务使用。业务1： 18500_1和18500_2 跨DC做存储双活，数据库层没有做复制。业务2： 18510_1和18510_2 跨DC做存储双活，同时数据库层做了数据复制。数据库复制的方案是：DC1中是一套2节点的ORACLE RAC集群，作为主库；DC2中也是一套2节点的ORACLE RAC集群，作为备库；主库和备库之间通过数据库日志复制，实现跨数据中心的ADG复制。

guwenkuan： @sxitsxit 我们两个数据中心的距离大约70公里，的确已经是双活架构距离的极限了。数据中心间FCping延时大约在1.2ms，网络ping约0.8ms。两台18500实现双活，主要运行主数据库A等等，运行的全部是主库，运行全部业务，对外提供服务。两台18510也是双活架构，是主库A的逻辑备库，运行的全部是逻辑备库，不对外提供服务，主要作用是上面那套双活存储的逻辑保护。

2021-02-05 22:05

添加新回复

guanyang1326

信息科技部网络管理室负责人辽宁农商银行
2021-01-15 12:44

非常详细的介绍了使用华为高端存储建设双活数据中心的方案。因为近些年来，监管部门对金融业的监管越来越严格，尤其是数据的安全和保护方面。自从斯诺登事件以来，各个行业对信息安全越来越重视，尤其是金融业，对于大力推进基础架构的国产化率工作十分迫切。通过作者的方案共享，为我们在使用国产化设备建设双活数据中心方面提供了非常宝贵的经验。我单位也在不断进行基础架构的国产率工作的推进，除核心业务外其它重保信息系统的存储都已经实现了国产化，我本人对这个方案也非常感兴趣，所以对方案中的一个地方我想请教一下，为什么把OceanStor18510 V5作为OceanStor18500 V5复制存储，而没有作为主要的生产存储呢？是担心设备的可用性问题吗？

sxitsxit： @guwenkuan 有三个问题哈 1、我们在讨论双活的时候一定是考虑了距离带来的时延。据了解，同城跨数据中心做存储双活，距离最好在50公里以内，否则性能扛不住。请问您们两个数据中心的距离多远？两个数据中心间往返的时延是多少？ 2、您所描述的方案我没有太明白，不知道我这么理解对不对。数据中心DC1 有两台存储18500_1、18510_1 ；数据中心DC2 有两台存储18500_2、18510_2 ；异地数据中心是DC3，采用中端存储。其实是搭建了两个双活环境，给两个不同对业务使用。业务1： 18500_1和18500_2 跨DC做存储双活，数据库层没有做复制。业务2： 18510_1和18510_2 跨DC做存储双活，同时数据库层做了数据复制。数据库复制的方案是：DC1中是一套2节点的ORACLE RAC集群，作为主库；DC2中也是一套2节点的ORACLE RAC集群，作为备库；主库和备库之间通过数据库日志复制，实现跨数据中心的ADG复制。

2021-01-16 11:14

guwenkuan： @guanyang1326 非常感谢评价，OceanStor18500 V5这个先投产，先购置的，生产数据库主库已运行，OceanStor18500 V5后期采购的，搭建的逻辑备库，与存储的可用性没有关系。

2021-01-15 14:11

添加新回复