作者jampg·2019-06-04 17:22

系统运维工程师·某大型保险

某大型金融保险企业异地灾备建设的实践经验分享

字数 7069阅读 6359评论 6赞 23

## 摘要
本文介绍了某保险企业异地灾备建设的实践经验，以解决保险企业当前面临的关于灾备系统建设滞后、设备老化、资源紧张及架构升级等现实问题。通过介绍企业现状，分析当前遇到的问题以及行业监管要求等，充分把握企业实际需求，最终确定LinuxONE作为承载该公司新架构转型及异地灾备建设方案的基础设备。在此基础上，进一步分享该保险企业的灾备中心建设经验，给读者提供一定的参考及避免雷区。

## 一、综述
灾难备援，也称之为灾备，是指利用科学的技术手段和方法，提前建立系统化的数据应急方式，以应对灾难的发生。灾备的目的和实质就是保持信息系统的业务持续性。

随着金融行业的快速发展，保险行业的信息化进程也在不断加快，保险公司的信息数据量急剧膨胀，并已成为宝贵的资产。在业务快速发展的同时，对应的信息系统也正在由分散到集中，保险业务对系统的可用性和业务的持续性要求越来越高。如何使业务系统平稳运行，成为保险公司的头等大事。 随着客户风险意识的增强，保证关键核心业务系统持续成功运作的需要，将发生风险的损失降到最低，保证企业的核心竞争力，保险公司对业务系统的可靠性提出了更高的要求，除了满足自身发展的需要，也是为了满足监管机构的要求。从当前大多数灾备系统现状来看，还存在诸多问题，不仅有技术层面的缺陷，也有流程和人员方面的不足。这些问题可能导致的直接后果就是当灾难发生时，根本无法实现应用系统的快速恢复，甚至可能导致业务运转的长时间灾难性中断。

一是容灾意识有待进一步加强。有关人士剖析国内保险公司的信息安全观时曾指出："保监会对全国的保险企业作出了数据容灾的规范化要求，但国内企业对此并不重视。和国外同类企业相比，中国保险业不仅在容灾、备灾的意识方面较为落后，投入方面更是远远不够。当前，有些保险公司抱有侥幸心理，认为灾难离自己很远，为此大量投资有些得不偿失"。

二是容灾建设方法应进一步完善。目前，虽然大部分保险公司都开始重视起灾备系统的建设，陆续完成了基本容灾系统的IT基础架构建设，但如果没有相应的灾难恢复计划，也没有针对灾难发生后的应对、决策、详细的灾难恢复步骤，容灾系统将难以发挥真正功效。

## 二、需求分析
目前该公司拥有两个集中式数据中心，南方数据中心和北京数据中心机房；以及各省级机构各自独立的机房，以此来构成核心生产环境的1主36备架构。如下图所示，南方数据中心包括大集中应用、核心总部应用、总部分析应用、总部测试及电网销灾备等；北京数据中心包括核心总部应用、总部集中部署的核心总部应用的灾备、电网销及总部测试等；各省分公司机房包含大集中应用灾备、影像系统及本地的查询分析等。
![18pyx25np0r](/home/attachment/201906/04/1218623_155963916359280.png)
 　　　　　　　　　　　　　　**图一：当前数据中心情况**
 
该公司于2012年底实现以南方数据中心为依托的全国信息系统大集中，以当时的信息系统承载当时的业务不费吹灰之力，形成大马拉小车的局面。但是随着该公司业务的迅速发展和规模的急剧扩大，公司IT系统的数量、规模以及复杂度都呈几何级增长，业务对IT系统的安全性、可用性及持续性的依赖程度也越来越高，提出的要求也越来越苛刻。从2012年完成大集中后，一直延续至今，现有的IT模式面临了严峻的挑战。
**主要问题重点体现在**：
1）系统运行风险越来越高；
2）IT环境越来越复杂；
3）新业务调整，对于敏态需求的支持显得力不从心。

## 三、选型分析
众所周知，IT系统无论多么重要，最终都要通过业务来体现他的价值，即技术为业务服务。因此在进行基础架构规划及灾备建设方案时应该充分考虑实际业务的增长情况。如下图所示，该公司一个下属分公司，2018年“双十二”的CPU利用率情况，大部分时间在80%以上高负荷运行，甚至有突破当前资源处理能力上限的迹象。按当前业务发展趋势，系统资源肯定无法支撑该省下一年的业务高峰，而该省已经独立使用了单台SD2(128Core)，基本达到目前业内小机系统的上限。
![02m124sr46xx](/home/attachment/201906/04/1218623_155963923076035.png)
　　　　　　　　　　　　　**图二：某省双十二CPU利用率**

为应对上述问题，公司专门成立了优化项目组，搭建了该省全套的核心业务系统测试环境，进行专项优化测试。优化主要从应用系统和硬件两个方面着手，以2017年业务高峰作为压力基线，所有的测试压力均以该基数为倍数进行调整，以便模拟业务的自然增长情况。同时，通过调整压力，也可以模拟双十一、双十二等业务高峰的情况。经过项目组的努力，资源瓶颈的问题得到一定的缓解。但是对于快速发展的业务来说，单纯对应用系统进行优化的效果，无法有效的支撑业务快速增长带来的处理能力的爆发性增长需求。

现实情况是该公司不仅遇到单台硬件资源瓶颈的问题，还有诸如设备老化、机房空间不足、机房电力不足、南方数据中心与北京数据中心互联网络带宽成本巨大、软硬件维护成本高等一些列问题。以设备老化为例，当前生产环境运行的设备大多数为2012年采购，已运行6-7年，故障率居高不下。据不完全统计，仅数据库小型机这一平台，2018年四季度就发生故障18次，约1/3的故障导致宕机或者需要停机维护。作为业务支撑部门的压力日趋上升，运维团队急需改变救火员的角色。

同时，随着行业技术的发展和新架构、新平台的不断涌现。该保险公司当前也正处于传统架构和新架构的关键转型期，拟定了未来以传统稳态与新型敏态相结合的模式，构建两地四中心的多活多中心基础架构。如下图所示，同城两中心采用拆分双活中的读写拆分模式，进行读写分离。异地中心采用拆分双活中的地域拆分模式，进行以地域为特征的交易拆分。从灾备角度分析，同城RPO为零，RTO为分钟级；异地RPO不为零，RTO为小时级。
![nll8ujzf2k](/home/attachment/201906/04/1218623_155963927695592.png)
　　　　　　　　　　**图三：两地四中心数据库架构图**

由于当前生产核心系统依然运行在稳态架构上，未来很长一段时间期内，均需要依靠传统架构支撑每年业务的持续增长，在技术选型及基础架构规划的时候，还需要充分考虑以下几个方面：
1)	支撑业务持续增长的能力，即单机纵向扩展能力。至少在可见的未来，单机支撑能力必须跑赢单省分公司的业务规模，避免出现巧妇难为无米之炊的局面。
2)	保障业务系统连续性的能力，即高可用性。所选设备必须有不亚于小机的稳定性，能够支撑核心交易系统，确保系统的连续性。
3)	其他限制条件，如成本的问题。作为金融企业的IT部门，换句话就是只会花钱的部门，成本问题一直是痛点，在保证业务的前提下缩小成本是我们努力的方向。
4)	支持未来架构转型，实现设备复用。即转型前能支撑传统稳态业务，转型后也能支撑敏态业务。

**基于以上考量，从传统解决方案入手，发现并不能很好的解决问题，如：**
1)	采用分布式新架构。该方案涉及重写应用,开发周期长，无法解决当前设备问题，排除;
2)	小机架构全部用x86服务器替换。当前x86设备的稳定性较差，RAS性能有待考验（Reliability、Availability、Serviceability)；纵向扩展能力也不够，无法保证业务系统的连续性，排除;
3)	选择传统小机。当前国内应用趋势逐渐被Linux平台主导，传统小机无法支持公司未来架构的选型，创新力不足，排除.

在传统解决方案无法有效解决问题的情况下，团队开始思考是否有足够大的、足够稳定的、足够开放的硬件平台。经过大量的测试选型及综合考虑，发现LinuxONE即支持云化的方式，又支持传统的方式；即能集中部署，也能分布式部署；既能承载传统稳态架构，也能承载新型敏态架构。同时，其强大的单台处理能力能够很好的规避传统平台可能面临的处理能力上限问题，发挥大资源池削峰填谷的作用，再结合技术选型时考虑的几点，最终选取LinuxONE作为承载该公司新架构转型及异地灾备建设方案的基础设备。

## 四、LinuxONE的应用
确定设备选型后，组建了专门的测试项目组，耗时约半年时间，进行了大量的测试。涉及灾备项目的测试包括灾备项目应用服务器资源池相关兼容性测试、灾备项目应用服务器资源池相关性能测试。
灾备项目应用服务器资源池相关兼容性测试分为云平台兼容性测试及应用兼容性测试。考虑到LinuxONE资源池规模较传统资源池规模大很多（我们的案例是在一个集群环境里分了1000多台虚拟机），如果没有云平台的自动资源分配和自动管理，整个后期运维工作必将成为一个灾难，因此，应用服务器资源池云平台兼容性的测试，非常有必要。为了验证云平台兼容性，测试项目组搭建了如图四所示的测试环境，通过ICO云管理平台，成功纳管LinuxONE资源池，并通过运管平台进行资源分配，实现了与现有资源池的无缝对接。
![2w9oo0naquc](/home/attachment/201906/04/1218623_155963931622335.png)
　　　　　　　　　　**图四：云管平台纳管LinuxONE**

此外，由于LinuxONE本身硬件、虚拟化层、操作系统和JDK与传统的架构不一样，所有的应用在迁移到新的平台时，都会需要进行应用兼容性的测试，以保证大规模上线时整个变更过程的可控。因此，需要将如图五所示，所有的应用环境配置进行逐一的测试，以保证最终所有业务均能正常使用。
![45zfdd4z7o](/home/attachment/201906/04/1218623_155963936459461.png)
　　　　　　　　　　**图五：应用兼容性测试**

灾备项目应用服务器资源池相关性能测试选取了某省的核心交易系统，如下如图所示，以业务高峰的2.7倍压力值为测试标准，实现交易响应时间49s，整体CPU利用率为75%，交易出错率<1%，通过压力测试。

![z122ege3o6c](/home/attachment/201906/04/1218623_155963940557489.png)
　　　　　　　　　　**图六：灾备项目性能测试**

通过上述测试并经相关专家评审后，项目团队一致认为采用LinuxONE作为服务器资源池的技术方案是完全可行的，并且在可用性、可管理性和总拥有成本（TCO）方面具有明显的优势。基于这一结论，该公司在进行北备项目（一期）建设项目过程中，开始采用LinuxONE服务器搭建灾备应用资源池。该资源池目前已分配近1000台虚拟机，用来运行部分总部应用的灾备及13个省分公司应用的灾备任务，如下图所示。

![9vdsm9tv7s](/home/attachment/201906/04/1218623_155963947370939.png)
　　　　　　　　　　**图七：灾备资源池**

与此同时，项目组借助灾备资源池进行了核心系统的国产数据库测试、容器（ICP）测试、Tbase分布式数据库测试以及其他一些开源产品的测试。如下图所示，结合LinuxONE的成本及能力，标识出其所适合的场景。
![nd0jc7wp72b](/home/attachment/201906/04/1218623_155963950994303.png)
　　　　　　　　　　**图八：能力匹配决策图**

○1核心数据库，即传统稳态数据库，国产数据库；
○2应用服务器，支持高密度整合，能充分利用LinuxONE削峰填谷的能力；
○3分布式数据库，即新型敏态架构，PostgreSQL、Tbase等；
○4容器化应用，支持k8s，与容器管理平台兼容较好；
○5Windows相关应用，不支持；
○6大数据平台及相关应用，其兼容性效果较好，但性价比极低。

## 五、案例分享
目前，公司已成功在北京灾备中心建设（一期）和核心数据库试点两个项目中上线了LinuxONE服务器。

**5.1北京灾备中心建设（一期）**
北备一期项目是为解决该公司当前生产环境超期运行和灾备环境接管能力不足等现状，保障当前生产系统的安全稳定运行，而全新筹建的备份中心。北京备份中心为依照金融业灾备建设参考模式，如下图所示，对重点关注的灾备应用服务、灾备数据服务、灾备接入服务、共享支撑服务、网络服务、基础设施服务和灾备系统管理服务领域逐块进行展开设计。
![04sc8fwyteba](/home/attachment/201906/04/1218623_155963955140397.png)
　　　　　　　　　　**图九：灾备建设模型**

灾备应用服务需完整部署该项目所涉及的119个应用系统，为实现应用部署的标准化、满足可能的调整变更和业务增长需求导致的扩展性、以及实现应用系统基础架构的高可用性，设计应用部署需满足一下要求：
1.	以应用系统为单位，同一个应用系统每个虚拟机的资源分配、受管参数配置一致；
2.	一台虚拟机只运行一个分公司的一种应用，不同分公司不共用虚拟机；
3.	资源池物理服务器数量保持一定规模，物理分布保证离散度；
4.	需要每个资源池保留一定冗余，在极端情况下硬件备份或个别公司临时负载及扩容需要； 
5.	为适应快速切换、快速启动需求，实现各应用系统的批量重启功能。

目前已使用了LinuxONE服务器构建灾备应用资源池，该资源池上目前分配了近1000个虚拟机，用来运行部分总部应用灾备及13个省的应用灾备任务，承担灾备应用服务。在此基础上，充分利用了LinuxONE资源复用的特点，在LinuxONE上进行国产数据库，容器云，DEVOPS等测试；目前该项目处于收尾阶段，并成功完成多个省份的灾备演练，LinuxONE平台CPU利用率未超过40%，还有较大提升性能空间，另外也很好的规避了传统平台有可能面临的单台资源瓶颈，同时还可以与当前运管平台完美兼容，实现灵活的资源交付。与传统的x86架构相比，机房空间由13个机柜缩减为6个，电力成本也有所降低。当然，通过该项目，也发现LinuxONE存在一些弊端，如不带内置盘，必须使用SAN存储；CPU资源可超分使用，但是内存超分需谨慎；无法提供windows服务等。

灾备数据服务，选用了存储虚拟化数据复制方案，对底层存储进行虚拟化，保证各系统之间采用相同的数据复制机制，最大化保证了各系统间的数据一致性；降低了部署和后期维护难度；摆脱了存储平台的同平台限制。如下图所示，以存储虚拟化数据复制为技术方案，北京备份中心数据复制示意图如下：
![h41jo4nmoe](/home/attachment/201906/04/1218623_155963958837719.png)
　　　　　　　　　　**图十：数据复制架构示意图**

南中心与北京备份中心建设2条专线实现数据传输，各分公司分别通过专线连接到南中心和北京备份中心，后期将依托网络监控系统对带宽进行实时监控和其它省公司灾备上线的要求进行调整；
通过 SVC技术实现南中心的存储虚拟化改造，提高生产中心的存储管理的灵活性、存储资源利用率；利用SVC异步数据复制技术，实现南中心到北京备份中心数据传输，通过一致性组技术确保复制数据的完整性；
南中心应用服务器日志拆分改造之后，利用SRM技术和DR技术实现南中心与北京备份中心的应用系统的同步升级变更。

**5.2核心数据库试点项目**
核心数据库试点项目为该公司2019年年度重点工作之一，该项目使用LinuxONE分区作为数据库服务器，将试点公司的大集中数据库主备均迁移至LinuxONE。前期经过了大量的压力测试，发现一台满配的LinuxONE服务器1/7的CPU资源可以承载该公司当前规模最大的分公司承保数据库实例所需压力。通过对比压力测试，估算出1颗LinuxONE的CPU的运算能力约为1颗HP-UXCPU的6.42倍；1颗LinuxONE的CPU的运算能力约为1颗Power7CPU的3.33倍。目前该试点分公司已投产两月有余，性能及稳定性等均满足预期。
另外，从成本角度来分析该项目，选择了“新购小型机”、“新购x86”及“新购LinuxONE”三个方案进行TCO对比，结果显示新购LinuxONE的5年成本较新购小型机节约成本约49.2%，此方案更加经济。具体如下表所示。
**表一：TCO成本分析**
![i4ase3lozl](/home/attachment/201906/04/1218623_155963962744311.png)

## 六、注意事项
尽管该公司已成功在多个应用场景上线LinuxONE，验证了LinuxONE既能支持传统稳态架构也能支持新型敏态架构，能够有效助力构建数字化生态系统，达到“快”和“稳”的完美融合。但是在实际的架构转移时，还是需要经过更多的考虑，尤其是每家公司的实际情况不尽相同，请务必进行充分的测试及优化，得出自己的最优参数配置。发挥LinuxONE最大的价值。

异地灾备需求分析容灾建设 LinuxONE

著作权归作者所有

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

添加新评论6 条评论

狼卍魂数据库运维工程师某金融机构
2019-12-26 14:52

期望能再发文介绍下容灾的架构。

zhuoyue项目经理WNtime
2019-06-21 09:56

不错，收藏了

改变自己客户代表计算机
2019-06-10 19:38

没看明白linuxONE如何支持敏态？

huijx系统运维工程师某银行
2019-06-06 12:18

好文章值得学习。虚拟机容灾其实是一个比较麻烦的事，要么RTO无法降低，要么成本比较高。

huijx： @Zerto 是SRM吗？曾经做过测试，遇到不少bug

2020-04-09 09:30

Zerto： @huijx 对于VMware下有比较好的解决方案

2020-04-08 11:32

添加新回复

guangtoudj软件开发工程师和泰人寿保险股份有限公司
2019-06-06 10:32

点赞！请教个问题：双活或者多中心场景下，对各地对数据同步时效要求很高，网络会成为重点问题，在数据高效同步和网络结构方面能否有更细对建议或方案？谢谢！

phoenixlzy

技术经理nci
2019-06-06 09:56

您好，有几个问题想咨询下， 1.从目前来看贵公司是否仍在异地双中心模式下？ 2.从描述来看核心总部应用群位于南中心，核心总部应用群的灾备环境位于北中心，假设南中心的核心总部应用群有子系统A、B、C，正常来说会在北中心部署A、B、C的灾备环境，那么想问下，假如南中心核心总部应用群的子系统A出现问题需要将A切换到北中心的灾备环境运行，那么此时是仅核心总部应用群中的子系统A切换至北中心，B、C保留在南中心？还是连带将没有问题正常运行的B、C也切换至北中心运行。 3.其实核心问题是，通常某一类业务会以系统群的方式存在，例如核心业务系统群，各子系统之间关联复杂、交互频繁，那么如果是在南、北异地双中心的数据中心运行模式下，会在南中心建设核心业务系统群的生产换金，在北中心建设灾备环境，那么此时核心业务系统群中的某个关键子系统故障了，在切换策略上是将这个子系统切换，还是将整个系统群切换？谢谢！

Ctrl+Enter 发表

匿名评论

某大型金融保险企业异地灾备建设的实践经验分享

添加新评论6 条评论

本文隶属于专栏

作者其他文章

相关文章

相关问题

相关资料