作者zzouh·2020-11-09 22:11

存储架构师·某商业银行

某银行核心系统存储升级改造架构方案设计实践

字数 6962阅读 8642评论 13赞 21

## 文章摘要
截至2018年底，我行基于HDS VSP存储复制技术搭建的两地三中心容灾系统已经运行了八年，性能出现瓶颈、切换需要人工干预，不能达到同级银行所需的RPO和RTO,使得我行存储架构改造迫在眉睫。基于此，我们针对老旧设备存在的问题、未来业务发展需要和提供更好的服务、提升我行核心竞争力等多方面进行了分析和总结，经过对存储技术架构的多维度对比后，我们最终选定了华为的同城双活+异地远程复制的两地三中心存储容灾保护方案。本文着重阐述了存储组网设计、故障域设计、网络层设计和应用层设计等，经过近十个月的努力，最终在不影响业务的情况下，我们完成了异构存储的在线迁移，保证了新系统的顺利上线。

## 一、项目背景

2011年初实施完成基于HDS VSP高端存储搭建的3DC方案承载核心业务系统，由生产中心通过DWDM链路同步复制到同城灾备中心、SDH线路异步复制到异地灾备中心构成。核心业务数据量约58TB，主机采用约45台Power物理机承载，主要包括：核心数据库和业务系统(存贷款、支付系统、账务)等。通过阵列复制技术进行容灾，RTO<4H，RPO=0（同城），RPO<15m(异地)。
   ![](/home/attachment/202011/09/1245237_160492959645547.png)
**1、痛点1**
现网存储采用SSD和SAS进行分级，同时承载核心业务和部分A类业务，存储时延抖动较大，高峰期时延超过10ms，读时延最高到15ms，且时延经常出现来回波动，造成业务时常卡顿。
**2、痛点2**
业务连续性方面，现网存储容灾架构满足千亿级银行对于RTO、RPO的基本要求，但是生产存储存在单点故障，切换需要人工干预，且年度容灾演练复杂度高，现网存储架构无法满足未来银行对于数据中心“双活”模式的演进。
**3、痛点3**
TCO高，核心存储使用HDS早期VSP产品，设备老旧，即将过保，后期运维成本高，且扩容难度大。

## 二、需求分析和总结

**1、旧核心设备面临问题**
- 性能出现瓶颈，超时严重，业务卡顿
- 核心设备老旧（即将过保），可靠性降低
- TCO较高，扩容成本高居不下。

**2、未来业务发展需要**
- 产品与制度创新
- 防范系统性风险
- 加强科技监管
- 用户满意度
- 业务需求快速响应

**3、核心系统改造势在必行**
- 更前沿的架构
- 更好的性能表现
- 支持新技术架构创新
- 提供更好的服务
- 提升核心竞争力

## 三、技术选型
**1、存储改造--技术架构对比**
![](/home/attachment/202011/09/1245237_160492981390222.png)
![](/home/attachment/202011/09/1245237_160492984146098.png)
 从上表可以看出，存储容灾具备较强有事，首先，通用性强，适用于数据库及其他类型用，其次，配置简单，对主机资源占用少；另外，方案成熟度高，延展性强。

**2、存储选型原则**
  对于存储选型方面，我们需要高可靠，即，业务连续性支持，架构级高可用和设备级高可靠；高性能，即，高带宽、低时延的架构，满足不用应用系统的性能要求以及支持业务快速上线；易管理和维护，必须具备自动化部署和配置、数字化管理和容灾架构管理；良好的可扩展和可演进性，必须满足未来3~5年的规划，支持向“双活”数据中心演进。因此，最终我们确定使用高端全闪存进行核心系统存储改造。

**3、最终选型--同城双活+异地复制两地三中心容灾方案**
![](/home/attachment/202011/09/1245237_160492991255188.png)

基于对主存储性能保证的考虑，我们最终选用同城双活+异地远程复制的两地三中心存储容灾保护方案。它的优势在于：

1. 高端全闪存满足核心系统对于性能的要求（低于1ms的稳定时延），且满足未来3~5年的业务扩展需求及新业务快速上线的需求；
2. 高端全闪存“四坏三”架构提升单存储可靠性；
3. 同城双活方案RPO=0、RTO≈0，高标准满足监管要求；
4. 基于A-A架构的双活，两端存储都支持数据读写，减少了年度容灾演练步骤，大幅缩短演练变更操作时间和步骤；
5. 后期平滑演进“四副本”等容灾方案，创新方案能力领先。

## 四、两地三中心容灾方案设计
**4.1方案架构图
4.1.1级联组网**
**两地三中心方案架构逻辑组网（级联）**
![](/home/attachment/202011/09/1245237_160493003961627.png)
在级联组网方式中，生产中心与同城灾备中心之间采用同步数据复制技术，而同城灾备中心与异地灾备中心之间采用远程异步数据复制技术。这种方式中，生产中心与同城灾备中心之间有着密切的关系，如果中间的线路或同城灾备中心的存储设备有任何故障时，整个数据复制过程将停止。

同时，当同城容灾中心出现故障时，生产中心和远程容灾中心将失去联系，即生产中心的数据不能及时复制到异地灾备中心，造成生产数据没有容灾保护，容灾中心建设失去意义。因此这种级联容灾架构的容灾防护和适应能力较差。

**4.1.2并联组网**
**两地三中心方案架构逻辑组网（并联）**
![](/home/attachment/202011/09/1245237_160493009659949.png)

在并联组网方式中，生产中心与同城灾备中心之间采用同步数据复制技术，生产中心与异地灾备中心之间采用异步数据复制技术。

这种方式中，生产中心与同城灾备中心之间是相对独立的关系，，如果中间的线路或同城灾备中心的存储设备有任何故障时，异步数据复制不会受到任何影响，数据异步复制正常进行。当数据复制线路或同城灾备中心的存储设备故障排除后，生产中心会将所有更新的数据复制到同城灾备中心。反之异步数据复制链路和远程中心出现故障，同城同步容灾也不会受到影响。提供了较好的数据保护架构。

**4.1.3双活+异步复制组网**
**两地三中心方案架构逻辑组网（同机房双活+异步复制）**
![](/home/attachment/202011/09/1245237_160493015522173.png)
在同机房双活+异步复制组网方式中，生产中心采用两台存储，存储之间数据完全同步，生产中心与异地灾备中心之间采用异步数据复制技术。
这种方式中，生产中心任意一台存储出故障，不会影响生产系统的正常运行。但生产中心整个中心出故障后，需要承担丢失部分数据的损失。

**两地三中心方案架构逻辑组网（跨数据中心双活+异步复制）**
![](/home/attachment/202011/09/1245237_160493020912579.png)

在跨数据中心双活+异步复制组网方式中，生产中心和同城灾备中心的存储是双活的，存储之间数据完全同步，同城灾备中心与异地灾备中心之间采用异步数据复制技术。
这种方式中，生产中心存储出故障，不会影响生产系统的正常运行。它集合了并联组网和同机房双活的优点，同时去除了他们的缺点。

**4.1.4选择说明**
两地三中心为用户提供了灵活的组网方式，用户可根据现有网络情况和对容灾备份RPO及RTO的要求来初步选择组网方式。不同组网方式应用场景对比如下表所示。

**两地三中心不同组网应用场景对比**
![](/home/attachment/202011/09/1245237_160493028194546.png)
![](/home/attachment/202011/09/1245237_160493029414293.png)
除此之外，还有以下几个因素需要考虑：
- **对A站点的性能影响**
并联组网中，由于A站点存储系统承担了两个远程复制数据同步的任务，因此对生产中心存储系统性能影响大于级联组网。

- **同城站点的故障影响**
级联组网中，由于异地容灾的远程复制依赖于B站点，且两地三中心不能支持星型组网（即三个存储系统两两之间互为备份），因此，当B站点发生故障后，A站点将失去所有备份站点。而并联组网中，即使同城B站点发生故障，也不影响A-C之间的数据容灾备份，避免了B站点成为数据备份的单点故障节点。

**4.2 故障域设计**

故障域概念上指具备相同的故障源统称故障域。故障源包括如：电力故障，制冷系统，网关等风、火、水、电、网络源。SAN双活数据中心方案为了确保用户业务连续性，需要根据业务提供相应的基础设施双活和冗余能力。除应用层集群部署防止应用层单点故障业务中断外，还需要考虑的内容主要涉及以下几个方面：
- 故障域：存在单点故障源的区域，例如电源，制冷。
- 组网：主要涉及跨中心网络，主机与阵列间业务网络，仲裁网络及端口规划。
- 应用：跨中心集群部署上的注意事项及其它要求。
- 多路径：路径策略设置原则。
- 存储：存储仲裁优先、一致性组，磁盘和Pool规划原则。
- 仲裁：部署位置及IP网段规划原则。

**设计原则**
**同机房数据中心部署**
双活在同一个数据中心内部署时，由于故障域无法隔离，只能提供设备级或者机架级的可靠性。
为了提供更高的业务连续性，需要注意的有：
- 仲裁服务器和仲裁相关的网络设备，采用独立UPS电源保护。
- 仲裁服务器是虚拟机时，该虚拟机不能运行在该双活方案存储提供的LUN上。仲裁服务器是物理机时，不能使用该双活方案存储提供的LUN作为SAN Boot的OS盘。
- 仲裁网络禁止VRRP主备网关配置。

**跨数据中心部署**
对于跨数据中心双活容灾场景，双活数据中心通常包括两个数据中心，及第三方站点。两个数据中心部署生产业务和双活存储，第三方站点存放仲裁设备。在设计方案时，需要设置三个故障域，即每个站点存在自己的故障域，避免因一个站点出现电力，网关等故障而影响整个系统可靠性。

其中规划要点在于故障源的识别，常见的有：
- 仲裁服务器不能与任意一个数据中心共用相同供电系统，如果无法避免，供电故障时，双活业务将会有中断风险。
- 存储复制网络与仲裁网络要充分考虑网络隔离，不能同时故障。
- 仲裁网络禁止使用VRRP主备网关配置。
- 仲裁服务器是虚拟机时，该虚拟机不能运行在该双活方案存储提供的LUN上。仲裁服务器是物理机时，不能使用该双活方案存储提供的LUN作为SAN Boot的OS盘。

**4.3网络层设计**
目标：规划三个数据中心容灾网络及其服务器及应用、存储阵列关系。

**城域网要求：（同步远程复制，双活）**
容灾网络距离：<300km，双活建议<300km，裸光纤连接。
传输延迟：<10ms （往返）。
网络真实带宽：>业务的峰值读写IO带宽。

**广域网要求：（异步远程复制）**
容灾网络距离：无限制。
传输延迟：<50ms （单向）。
网络真实带宽：>业务的平均写IO带宽。

**管理工作站：**
管理工作站需要三中心间通信。
网络距离要求：无限制。
通信网络带宽要求：10Mb/s。
应用、管理、两地三中心业务、仲裁网络IP规划原则：
- 连续性：为同一个网络区域分配连续的网络地址。
- 可扩充性：为一个网络区域分配的网络地址应该具有一定的容量，便于设备数量增加时仍然能够保持地址的连续性。
- 安全性：网络内应按工作内容划分成不同网段即子网以便进行管理。

**4.4 应用层设计
4.4.1数据库**
Oracle RAC两地三中心部署要求
![](/home/attachment/202011/09/1245237_160493068820870.png)
此图为两地三中心级联组网图，对于并联组网，只需要将图中的同城灾备中心设置为生产中心，将图中的生产中心设置为同城灾备中心。

**4.4.2设计原则**
应用层设计原则如下：
- 为了保持较高资源利用率。正常情况下，生产中心、同城灾备中心同时运营，并共同承载业务/应用。
- 异地灾备中心为容灾中心，正常情况下不接收业务，当发生故障切换时，可容灾接管业务。
- 一般场景下，应用与数据库集群跨DC进行部署和设计，三个数据中心的应用服务器集群均连接跨DC的数据库集群，并要求三个数据中心的主机同构。
- 同一个应用的相关LUN优先站点必须相同。
- 灾备管理平台实现灾备系统的可视化监控，实时查看数据的RTO和RPO指标，数据复制、双活状态等。

**4.4.3多路径设计**

必须配套华为UltraPath多路径。
主机部署华为多路径Ultrapath，存在两种工作模式，可以根据实际场景设置。
**负载均衡模式**
- 适用于近距离如同机房部署场景；
- 该模式实现跨阵列IO负载均衡；
- IO以负载均衡模式在两个阵列下发，最大化利用两台存储资源，提升性能。

**优选访问模式**
- 适用于远距离部署场景
- UltraPath上指定站点A主机优先访问站点A阵列，指定站点B主机优先访问站点B阵列，IO只会在优先阵列下发。
- 该模式可大幅减少跨站点访问，从而减少传输时延。

**4.4.4存储层设计**
双活解决方案中，针对两台存储的要求如下：
![](/home/attachment/202011/09/1245237_160493085061511.png)
**设计原则：**

- 同一个数据库、虚拟机的相关LUN需要放在同一一致性组中，同一个应用的相关LUN的快照要使用一致性组保护。
- 两个数据中心的LUN组都必须同时映射给两个数据中心的主机。
- 两个数据中心创建的LUN类型，如Think LUN，Thin LUN类型必须要保持一致。
- 两个数据中心配置的SmartTier，SmoartQos, 重删压缩策略必须要保持一致。
- 针对OceanStor V3/V5双活，只能对一个数据中心的双活LUN叠加镜像卷，必须先创建镜像卷，再创建双活LUN。
- 针对数据中心距离小于25KM，多路径模式设置为负载均衡模式，针对大于25KM场景，多路径模式需要设置为优先模式。
- 存储快照必须结合BCManager使用，快照的时间策略建议间隔15分钟以上。
- 针对异构虚拟化的双活，针对OceanStor V3/V5双活，只支持单边异构虚拟化，将离线接管的LUN配置双活。针对OceanStor Dorado V3系列，不支持异构虚拟化后配置双活。

**约束与限制：**
两个数据中心存储IP网络要对称建设，但不建议要配置为完全相同。

**4.5 系统RTO/RPO建议**

通过对客户业务系统容灾分析，识别业务系统的风险等级，输出系统容灾RTO/RPO需求，如下表：
![](/home/attachment/202011/09/1245237_160493092964049.png)

## 五、项目实施-数据迁移方案
   在数据迁移方面，基于存储异构虚拟化的数据迁移方案是本次改造方案比较有难度和风险的部分。
   ![](/home/attachment/202011/09/1245237_160493095792627.png)
   
由华为18500F异构接管HDS VSP存储资源(LUN)，启动HDS VSP到华为 18500F的数据迁移任务。迁移完成后，HDS VSP下线；该方案的优势在于：操作简单，存储软件自带功能，不需要安装第三方工具，不占用主机资源；实施高效，数据迁移速度最快可达100MB/s；在线迁移，不影响业务正常访问，可实现0停机。

## 六、本次项目小结
本次华为3DC容灾架构存储改造项目，从2018年底立项到2019年10月新系统上线，历时近一年时间，感触颇深。我们认为，存储改造项目中，首先是前期调研，对于升级改造后所要达到的容量、性能，容灾所要达到的RPO、RTO等一定要有明确目标，例如，我们要求一定满足我行5年间的业务，以防短期内重复进行升级所带来的的再次投入，要让参与项目的所有人都明白这次项目的性质，在既定时间内所要达到的目标；其次，项目实施中严格按照项目进度表进行、每一阶段的工作都要尽量向前赶，避免意外事件的发生而引起项目延误。因为该项目比较大，各个生产系统要分批、分阶段进行割接，每次割接前都要制定详细的割接方案（详细的标准是什么，要具体到每个命令行），每个参与割接人员的职责（确保双人复核）、制定回退方案、割接后24小时内高业务量对系统冲击的应急预案等；
最后，我们为该项目定下六大原则：1、要遵从业务连续性规划；2、实施科技发展战略；3、必须满足客平滑升级需求；4、技术风险平衡；5、依据监管要求，做到合规；6、参照同业经验，最好是从最佳实践中汲取宝贵经验。

核心存储升级 OceanStor 18500F 华为存储 OceanStor 容灾

著作权归作者所有

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

添加新评论13 条评论

Allen_KKLT产品经理H3C
2021-04-19 21:16

很有借鉴意义，传统存储受制硬盘和架构，在数据量暴增的今天确实需要改进和替换，数据迁移过程要是描述的更详尽就更好了，包括数据验证过程等，受教了

imda系统工程师某金融行业
2021-04-19 15:07

文中提及：“一般场景下，应用与数据库集群跨DC进行部署和设计，三个数据中心的应用服务器集群均连接跨DC的数据库集群，并要求三个数据中心的主机同构。”这是网络层面大二层打通？

goober其它cky
2021-04-09 09:13

你们的方案A、B之间带宽多少？

匿名用户
2020-12-11 13:56

写的很好，特别是架构和组网场景类比，给架构设计提供了参考。在同行业进行两地三中心设计提供了充分的参考。收藏了。

chenmingfu

基础架构组长西部某城商银行
2020-12-11 00:02

可以看到作者花了很多心思撰写本文档，从企业现状分析、面临的技术痛点及实际业务需求出发，充分结合当前行业内解决方案并兼顾未来5年业务发展需要一步步引出最终方案架构。近年来国内存储产品（如华为）也得到了各银行的大力推广及实践验证，经过仅6年来的行业应用案列表明：华为存储也具备较好的性能及高可靠性等，能充分满足城商行业务性需求。笔者在设备选型方面，遵循安全可靠的基础上又充分响应了国家安全自主可控战略，是值得各银行充分借鉴的选型思路，在能满足安全可靠及性能要求的前提下，应积极详细国家安全自主可控战略，优先考虑国产品牌设备。该方案以华为的同城双活+异地远程复制的两地三中心存储容灾解决方案，采用主流工具完成了异构存储的在线数据迁移，保证项目顺利上线，数据迁移的方案安全性非常高，非常值得参考借鉴。如果资金投入允许的话，可以考虑在生产中心再增加一台存储设备，建设为“本地存储双活+同城远程复制+异地远程复制”，结合近年来实际灾难厂家，当前容灾解决方案中监管部门提倡以“本地高可用”为主，优先保障生产数据中心内部的高可用。

匿名用户
2020-12-10 16:13

从当前痛点、具体需求出发，兼顾当前问题同时考虑未来的规划，给同业很好的指导经验。很多城商行正面临此问题，从传统的同步复制+异步复制方式升级到双活架构，从技术选型到实施方案，文章介绍的非常详细，同时数据库应用等也进行了设计，很完整的方案。从昂贵的国外产品到国内产品，也给很多同业提供了案例方向。希望此文章更多推广，真的收益颇深。

atpeace331数据库管理员银行
2020-12-09 21:05

从存储架构升级改造的背景、需求到技术对比选型，再到两地三中心的存储复制方案设计规划，方案很有借鉴价值。关于生产中心、同城灾备中心同时运营，并共同承载业务应用实现 “双活”，贵行是如何实现同城双中心业务系统 “双活” 的呢？作者能够分享下具体方案细节，那就更好啦！银行的核心业务系统的风险级别最高，它的灾备，贵行是使用“存储复制”还是“数据库复制”方案，测试时遇到的问题及其经验能否分享下？

wanggeng

系统运维工程师某银行
2020-12-09 17:58

以华为的同城双活+异地远程复制的两地三中心存储容灾保护方案。完成了异构存储的在线迁移，并且保证顺利上线，这个方案已经就是非常好的方案了，非常值得参考借鉴。数据迁移的安全性非常高，作者在数据迁移这块有个方案架构，如果能在具体描述一些细节以及遇到的难点如何解决的坑，就更加完美了。该方案文章很赞！

melody2004

系统架构师某城市商业银行
2020-12-09 17:24

文章写的特别好，能看的出来，作者对双活数据中心的解决方案是做了反复对比，而且分项也特别的详细。考虑的也特别的全面。分层设计理念是解决银行传统核心系统的一个非常巧妙的思路。我有个小问题，“城域网要求：（同步远程复制，双活）”那里提到“双活建议<300km，裸光纤连接”，是否是一个小笔误，还是华为的存储确实支持这么远的传输距离？另外，同城双活是否等存储两边同时落盘后才完成交易？双活数据中心是否采用了Oracle Extend RAC方案？重要交易系统实现双活方案，是依据什么原则将不同的流量分配至同城两个数据中心？不好意思，因为我们也在做这个事情，所以提的问题有点多。如果能得到作者的回复，将不胜感激。