一文读懂证券、银行、保险灾备建设特点

时间:2020-09-03 栏目:

导读:本文从金融行业的概况、信息化现状、容灾备份建设要求、系统容灾场景、案例简析等多维度分析金融机构数据安全和业务连续性建设的特点,为你呈现以银行、证券、保险等为代表的金融机构的数据保护和信息系统安全建设的不同。

一、行业概述

金融是指经营金融商品的行业,它包括银行业、保险业、信托业、证券业、租赁业、基金业、期货业。金融系统和数据具有全行业高标准的业务连续性和监管安全要求,超重大的系统与数据安全事件,甚至可能引发局部的系统性市场风险。为此,对市场盈利性金融机构的监管,是我国金融主管部门的主要职责之一。当前,我国的金融监管部门简称“一行三会”。一行是指中国人民银行,三会是指中国银行保险监督管理委员会(银监会)、中国证券监督管理委员会(证监会)和中国保险监督管理委员会(保监会)。当银行、证券、保险等金融机构发生包括系统运行的安全事故时,会由上级管理机构进行通报、警告和惩罚。

▲中国金融体系结构

金融行业具备信息化程度高信息安全要求高两大特征。金融科技化是推动金融业务快速增长的引擎之一,金融信息化程度越高,业务覆盖面越广,业务效率越高,与此同时,机构信息系统和数据遭受网络攻击、逻辑错误、自然灾害的挑战也越大。进入云计算和大数据时代的到来,金融信息化程度更高,其中以互联网金融业务的快速普及和高频交易最为突出,这也使得部分金融IT系统处于 7*24 小时超负荷运载状态。业务应用场景的变化演进,也给系统运维带来更大挑战,例如留给运维人员系统升级、迁移和补丁修复等计划性停机的时间窗口越来越小。

那么,如何保障金融机构信息系统安全高效的运行,不仅要选择适合自身生产环境的技术方案,还要考虑不同信息系统采用不同灾备方案,以达到 TCO 的最优化。例如,针对系统的热备和冷备模式,如何突破传统的 1:1 配置方式,实现灾备中心软硬件资源利用最大化,就是现在很多证券机构需要突破的难题。

此外,针对信息安全的监管要求,监管单位会对银行、证券等金融机构提出具体的建设要求。例如,银监会在 2011 年出台的 BCM 监管指引,就对商业银行的 RTO 和 RPO 提出了明确的量化指标,运维人员需要根据业务重要程度实现差异化管理,明确各业务恢复的优先顺序和恢复指标。原则上,重要业务恢复时间目标不得大于 4 小时,重要业务恢复点目标不得大于 0.5 小时。同时,商业银行应当至少每三年开展一次全面的业务影响分析;应当识别重要业务,明确重要业务归口管理部门、所需关键资源及对应的信息系统,识别重要业务的相互依赖关系,分析、评估各项重要业务在运营中断事件发生时,可能造成的经济损失和非经济损失。

1)信息安全等级保护建设

自主保护级、指导保护级、监督保护级、强制保护级、专控保护级,作为我国信息系统安全等级保护的五大经典分类级别,为金融机构在进行等保建设时,提供非常清晰的建设指引。在综合其他金融机构等级保护建设特点,我们总结了金融机构信息安全等级保护的三大阶段。

一是系统等级划分阶段。根据等保五级分类,运维人员需要全盘统计和分析所有运行系统的重要程度,对于复杂庞大的综合性信息系统,运维人员需要在横向和纵向两个维度将其分解为多个子系统,清晰描述和定义主系统与子系统的结构关系,再按照等级保护要求将其分类。

二是规划与设计阶段。在第一阶段的基础上,通过对业务信息系统进行安全域划分、保护对象分类,建立信息系统的分域保护框架,进行安全体系和安全技术体系两方面的安全方案设计,包括系统分域保护架构建立、选择和调整所选等级的基本安全要求、安全规划和方案设计,制定安全技术解决方案和安全管理解决方案。

三是实施、等级评估与改进阶段。在规划与设计完成之后,运维部门开始着手安全方案的选择,包括总的实施方案的目标、时间、方法,以及第三方供应商技术产品的甄选等。对于实施完成的技术方案,按照等级保护的标准要求,邀请外部的评估机构对系统方案进行评估,如果等级标准不达标,需要改进或重新建设;如果等级标准达标,则对最终结果进行验收,并在一定周期内,对系统的安全风险进行评估,如果评估发现系统不达标,则需要进行系统重新定级和建设。

目前,银行、证券、保险、基金等金融机构在等级保护建设方面,引领了整个行业的业务连续性和数据安全的发展。同城灾备、异地灾备、私有云灾备、两地三中心等多种方案综合交叉部署应用,在符合等级保护要求的同时,最大限度确保各类系统和业务数据的安全性。

2)金融机构信息安全的法律法规

金融机构分类较多,不同行业发布的法律法规各不相同,本内容以信息安全要求最为严格的银行和证券为代表,列举相关重要的现行法律法规:

《证券期货业数据分类分级指引》 2018 年 09 月 27 日同日公布实施,数据分类是按照 GB/T 10113—2003 中的线分类法和 GB/T 22240—2008 中的定级方法为基础进行分类的。目的是在数据分类基础上,对已分类数据按照数据泄露或损坏造成的影响进行分级,形成统一的分类分级方法。同时,在数据用语的使用过程中,也强调予以统一。

《证券期货业信息安全保障管理办法》(证监会令〔2012〕第 82 号)第四条规定:证券期货业信息安全保障的责任主体应当执行国家信息安全相关法律、行政法规和行业相关技术管理规定、技术规则、技术指引和技术标准,开展信息安全工作,保护投资者交易安全和数据安全,并对本机构信息系统安全运行承担责任。

《银行业信息系统灾难恢复管理规范》(JR/T 0044—2008)第八章灾难备份系统建设时明确:根据灾难恢复策略制定灾难备份系统技术方案,包含数据备份系统、备用数据处理系统和备用网络系统,技术方案中所涉及的系统应获得同生产系统相当的安全防护水平和具有可扩展性;其次,为满足灾难恢复策略的要求,应对技术方案中关键技术应用的可行性进行验证测试,并记录和保存验证测试的结果;最后,应制定灾难备份系统集成与测试计划并组织实施,通过技术和业务测试,确认灾难备份系统的功能与性能达到设计指标要求。

本章节整理了证券和银行机构的业务连续性和数据安全建设的法律法规及文件,供大家参考:

“关于证券信息安全政策法规”

《证券期货业信息安全保障管理办法》(证监会令 [2012] 第82号)

《证券期货经营机构信息系统备份能力标准》(证监会公告〔2011〕10号)

《证券期货业信息安全事件报告与调查处理办法》(证监会公告〔2012〕46号)

《证券期货业信息系统安全等级保护基本要求(试行)》(JR/T 0060-2010)

《证券期货业数据分类分级指引》(JRT 0158-2018)

“关于银行信息安全政策法规”

《银行业金融机构信息系统风险管理指引》(银监会 [2006])

《银行业重要信息系统突发事件应急管理规范(试行)》(银监会 [2008])

《商业银行信息科技风险管理指引》(银监会 [2009])

《商业银行业数据中心监管指引》(银监会 [2010])

《商业银行业务连续性监控指引》(银监会 [2011])

《网上银行系统信息安全通用规范》(JR/T 0068—2020)

《银行业信息系统灾难恢复管理规范》(人民银行 [2008])

《关于进一步加强银行业金融机构信息安全保障工作的指导意见》(人民银行 [2006])

“其他涉及金融类信息安全政策法规”

《保险信息系统上线运行基本要求》 JR/T 0179—2019

《金融行业信息系统信息安全等级保护实施指引》(JR/T 0071-2012)

随着我国金融市场的进一步开放和外资准入门槛降低,以及科创板、注册制、港股通等金融改革举措的推进,金融信息系统的安全性和规范性建设,将迎接更大的挑战。其中,确保系统的业务连续性将是重中之重,它关系到广大投资者和用户日常的投资行为和经济消费行为,任何非计划性的停机,都可能引起极大的经济损失和非经济性影响,并可能由此遭受监管部门的处罚。

二、行业现状与需求

金融行业分门别类繁多,不同领域的金融机构或相同机构的不同系统,根据等级保护的要求,RPO 与 RTO 的要求都不尽相同。但金融机构对数据零丢失和业务连续性要求高是冠绝全行业的,特别是银行和证券机构,丢失一个数字 0,账面上的金额可能就是天壤之别。为此,金融机构要尽可能接近于国际标准 SHARE78的Tier-6 级别。其中,以银行架构最为严格,它要求采用两地三中心或主备等多种模式构建灾备系统,在对各个数据中心的基础架构进行规划时,也要做好数据同步复制和数据中心双活的规划,通过裸光纤/DWDN 实现数据中心与各个营业网点的数据同步,同时同城数据中心应距离大于 50 公里,异地数据中心大于 300 公里,保障机房不会因为地震、洪水等区域性灾难受到全面的破坏,确保银行的数据不丢,业务不停。

除了银行,其他金融机构也会依据行业监管要求,构建自身的灾备系统,而金融机构的灾备应用场景也最为丰富。例如,从规模庞大的两地三中心、异地灾备、同城灾备、云灾备,到同机房内的双活、双机双柜、集群高可用、传统备份等场景,可以说是包罗万象。但是这也给运维带来极大挑战,以证券公司为例,各大券商的灾备中心的架构通常采用虚拟化技术,实现生产端物理机+虚拟机,灾备端以虚拟机为主的配置。

其中,生产端物理机和虚拟机存在两种形态:一种是应用和数据是前后端分离部署,如银行三方存管的中间件类型(无状态、无数据),数据存放在专用的数据库系统中;一种是应用和数据一体化部署,数据在本机或以 SAN/NAS 等形式存储。证券生产中心当前主要以第一种前后端分离部署为主。如果按照行业法规和监管要求,每增加一个生产系统,灾备中心就对应建立一个备份系统,那么灾备中心最终形成与生产环境主备 1:1 的资源配置策略。这就给运维人员带来极大挑战,据统计,一个中型券商的实际生产应用系统已超过 200 套,按照 1:1 的资源配置,灾备中心的备份系统就堆积成山,并由此带来一系列的运维管理问题。

例如,在备机普遍采用冷备、高可用和组等运营模式下,备机系统已经存在重复建设、冷备虚拟机使用率低,系统处于空转待命状态等问题,日积月累,就造成灾备中心的硬件设备、网络资源浪费严重。同时,根据行业监管的要求,运维人员要进行周期性应急演练确保备机系统的可用性,以保证应急时的业务连续性。但是,传统的冷备方式,第一在资源上备机会占用跟生产系统一样的资源;第二在实际生产应急或者应急演练时,运维人员需进行一系列复杂操作进行紧急主备切换,此时备机是否可用,以及人为操作失误等问题都会影响整个应急过程以及业务连续性,且生产系统两三百套,其可用性验证如果通过手动操作,那是一个浩大的人力工程。

为此,基于云架构的智能云灾备中心,正在被更多的证券机构所关注,它要解决资源复用、系统备份与恢复、演练自动化、快速搭建测试/ UAT 环境等问题,实现灾备中心的智能运维,减轻运维人员的工作量。

其他的金融机构,也会面临上述问题,但是可能由于底层基础架构不同,所应对的系统规模不一样,而等级保护要求的不同,也会造成系统和数据灾备方案的千差万别。我们综合分析银行、证券、保险、基金等主要金融机构,发现主要需求包括:

  • 海量数据的备份、CDP、实时复制
  • 数据库数据跨平台迁移和读写分离
  • 海量业务系统/虚拟机跨平台迁移
  • 主备业务系统的应用高可用
  • 提升灾备中心的智能运维水平
  • 大规模灾备系统可用性验证的自动化
  • 两地三中心、同城/异地、云灾备的规划咨询

综上,金融机构灾备系统建设,是一项严格且浩大的技术工程,它涉及应用层、网络层和数据层的各种环境架构,因此它对供应商的产品性能、功能、兼容性以及技术服务团队都提出了非常高的要求。

三、应用场景与解决方案

金融机构不断变化的应用场景,将推动灾备技术方案进行持续地创新,这是新灾备方案区别于传统灾备方案的显著特征。但是,对于金融机构而言,业务系统和数据的保护,这个总体目标是不变的,只是业务系统的重要程度会发生变化,这也迫使运维人员重新规划灾备系统的建设方案。

为了解决系统复杂度问题,通常运维人员会先进行系统属性的划分。我们一般会将其划分为业务系统和非业务系统,根据这个属性和等级保护要求进行应用场景的识别和资源配置,并最终落地部署。下面,针对金融行业细分领域对安全等级的不同,以及不同客户生产环境存在的差异化,灾备解决方案也会有所不同,下面列举部分灾备方案系统供大家参考。

▼ 银行两地三中心及异地多活方案

首先,银行两地三中心模式,是指有两个数据中心在同城作为生产中心机房,它们之间采用同步数据复制方式,两边数据中心完全一致。但是,由于两个数据中心距离会超过 50 公里,所以即使两边的网络采用了裸光纤/DWDN 的传输模式,还是会存在数据延时的情况,因此也不是距离越远越好,最好不要超过 100 公里,否则同步复制的延时可能超过上限的数值(一般 5 毫秒)时,可能导致数据库系统出现故障。

作为两地三中心的异地数据中心,与生产中心的距离一般超过 300 公里,目的是保障业务数据的多一份保障,为了节省成本,通常可以采用异步数据复制的方式来实现数据的同步。一般情况下,只有发生极端事件才会导致同城双活数据中心停止提供服务,所以异地灾备中心多半不作为关键应用宿主地,某些情况下是完全冷备,即使部分机构的异地灾备中心部署的应用,但通常不对外提供服务,所以用户不会访问到异地的点。原因是数据从生产级数据中心到异地灾备中心是异步数据复制,延时会比较大。相比于其他金融机构,银行在早期的基础架构规划时,就会将灾备作为必选项纳入到方案中,后期更多是以数据同步、数据库读写分离、虚拟机备份等建设为主。英方软件 i2COOPY 实时数据同步软件、i2Move 系统热迁移软件、i2Active 数据库同步软件,可以为用户提供数据实时同步复制和系统热迁移,且适合远距离、窄带宽、跨平台的环境;i2VP则可以提供无代理的虚拟机备份。

▲两地三中心架构

其次,部分大型银行会采用异地多活的模式,这是一种需要投入巨额费用的灾备模式,个别银行的某些关键应用已经在此模式下得到了验证。异地多活首先是要做到同城双活或者同城多活,就是数据在同城网络环境下进行高速同步。真正的异地多活需要多个跨地域的数据中心,距离达到 1000 公里以上,在这么远的距离下,对技术架构和网络传输是一个巨大的挑战。

▼ 证券机构智能云灾备中心方案

智能云灾备中心是近来非常突出的创新方案,它通过在灾备端以虚拟化技术,实现存储和计算资源的池化管理,然后通过构建智能云(VMware)灾备平台,实现生产端物理机、虚拟机以 VMDK 文件备份到 VMware 平台。正常情况下,备份文件只占存储资源,不占用计算资源。当系统需要恢复时,可以通过 NFS 协议挂载瞬时恢复,然后通过虚拟机启动进行接管,为生产持续对外提供服务。

▲智能云灾备中心架构

它解决了传统备份中心在前后端分离部署的环境下,生产系统与备份系统 1:1 配置所带来的运维难题。同时它提供在隔离网络环境下,进行大规模备份系统可用性验证自动化的功能,以及帮助生产人员快速搭建测试或 UAT 环境,大大地降低了运维人员的工作量,实现了灾备中心资源复用和共享的目标。它通过基于 B/S 架构的管控平台,对灾备中心的设备、系统、状态、资源使用和运行情况做统一的量化管理和资源调配,实现灾备中心的智能化运维。

在智能云灾备中心的运行过程中,英方软件 i2FFO 全服务器备份可以实现物理机到虚拟文件的备份,i2VP 可以实现虚拟机到虚拟文件的备份,i2CDM 则通过块变化实时复制技术,将变化的数据实时同步到灾备中心,确保两边数据的一致性。

▼ 证券行情分发与高可用切换方案

证券行情一般是指股票价格、涨跌幅、成交量、成交额、市盈率等股票行情。天下行情,速度为王,唯快不破,为此行情分发也分为极速行情和普通行情。

极速行情是从交易所机房出来,直接连接到券商机构在交易所同一机房的行情服务器,不走外部网络,时延可以低至微妙级。2019 年上半年,整个证券市场引发了一场行情比速的对比,各家券商随之对极速行情的转发需求越来越强烈。普通行情则是从交易所出来,通过网络传输分发到券商各营业网点,然后传输到投资者终端,这种环境下的行情时延主要考虑网络时延。

证券行情按格式又可分为流行情和文件行情。相同环境下,流行情是要比文件行情要快,同时流行情可以转文件行情,但不能反过来,这主要是与行情格式的发展历史有关。从深交所和上交所两大交易所看,深交所 2016 年之前是 V4DBF 文件行情,2016 年至今则是 V5 流行情(BINARY 协议、STEP 协议)为主;上交所2018 年前是 FAST 文件行情,2018 年是 FAST 文件行情+FAST 流行情+EZSR 组播流(过渡阶段),2019 年下半年至今是 FAST 文件行情+上交所流行情(MDGW 流行情)(BINARY 协议、STEP 协议)。

▲行情分发高可用架构

英方软件可以将流行情和文件行情分发集成在同一个软件产品 i2Distributor 中,根据客户需求自定义配置。i2Distributor 支持多级行情分发;允许指定多个父节点,以达到负载均衡、高可用性;支持文件分发和流行情在同一个节点中同时运行;支持上海 FAST 流行情、LDDS 流行情不落地转发;支持多实例部署,节省服务器资源;支持流行情转换老版行情 DBF 落地转发;支持组播流转发,可以更好地节省总部出口带宽;支持 LZMA 压缩技术,支持多级别的压缩选择(6 个级别的压缩),最高压缩率达到 98%。

▼ 证券其他系统灾备方案

1.中间件系统多对多池化高可用迭代接管

证券行业的业务系统有很多以前后端分离部署的方式,实现应用和数据库的分离部署,为此产生了大量无状态、无数据的应用系统。针对这种生产环境,通常采用主备一对一的方式,实现生产服务器到灾备服务器的故障接管。这种传统的高可用方法,存在两大问题:一是备端存在单点故障风险,即备端如果挂了,整个系统就挂了;二是采用 1:1 的高可用配置,造成资源浪费,即当系统都正常运行时,灾备端服务器就处于空跑状态。

▲多对多池化高可用迭代接管架构

针对这种情况,英方软件可以提供备端多对多池化高可用迭代接管的方案,实现备端服务器资源的池化迭代管理。例如,可以通过设置 5%-20% 的接管率,即允许最大同时在线故障服务器数量是 20 台,可以节省 80% 的服务器资源。当生产端的服务器出现故障时,控制平台会优先指定资源池里具备接管条件的备用服务器进行接管,依次类推,最终实现多对多池化管理。

2.同城交易系统HA自动切换

同城交易系统为证券机构重要的生产系统,多采用 Window+MSSQL 结构,在数据量变化方面,场景变化可以设为总容量约 500G,每天增量 30G 左右,同时清算操作会删减近 20G。同城交易系统目前多采用冷备系统,即灾备机日常处于冷备的状态,当程序运行所在机器发生故障后,通过另外一台机器人工操作重开报盘程序的方式完成故障切换,从而重新对外服务。此方案故障切换完全依赖手工,增加了切换过程中人为失误的风险,如果能实现全自动切换则能大大减少 RTO 和RPO 值。英方软件 i2Availibility 是一种自动切换的灾备解决方案,它提供针对多种应用、任何距离内的高可用性服务。即当生产系统出现异常时,它将生产系统上的应用按需自动切换到灾备服务器上,实现应用级快速切换,减少服务的中止时间,保持业务应用的高度可用性。

3.自营资管系统两地三中心灾备

自营资管系统为证券行业一个关键应用,系统架构常用 Window+MSSQL 或者 Linux+Oracle,用户通过灾备技术方案进行应用保护,可以实现异地机房数据库的远距离实时同步和两地三中心的灾备保护。

▲自营资管系统两地三中心灾备架构

4.融资融券交易系统多策略灾备

融资融券交易又称证券信用交易或保证金交易,是指投资者向具有融资融券业务资格的证券公司提供担保物,借入资金买入证券(融资交易)或借入证券并卖出(融券交易)的行为。它包括券商对投资者的融资、融券和金融机构对券商的融资、融券。

▲融资融券交易系统多策略灾备架构

针对融资融券交易系统,英方软件可以提供多策略的灾备方案,可以进行数据的实时复制,实现数据实时同步到备端数据库;可以进行数据库的高可用,实现数据库高可用的秒级切换;可以进行数据库数据任意时间点的数据恢复,实现数据库数据的 CDP 保护;可以进行多点数据容灾,提供同 LAN 及同城异地数据容灾。

5.PB 投资系统 HA+CDP 保护

PB 指平均市净率,是每股股价与每股净资产的比率。PB 是股票投资基本分析最常见的参考指标之一,与市盈率、市销率、现金流量折现等指标一样。PB 投资系统是为投资市净率而设的系统,英方软件可以提供 HA+CDP 为主的灾备方案,可以进行数据的实时复制,实现生产端数据到目标端的实时同步;可以进行应用的高可用,实现生产端服务切换秒级转移到目标端;可以进行数据库数据任意时间点的数据恢复,实现数据库数据的 CDP 保护。

▲PB 投资系统 HA+CDP 保护架构

6.资产管理系统同城与异地灾备

资产管理属于证券机构业务,可以为机构和个人提供限定性和非限定性集合资产管理、单一资产管理和专项资产管理,以及其他金融类资产管理业务。针对资产管理系统,英方软件可以提供同城及异地灾备方案,可以进行同城资产管理系统的应用高可用,实现应用系统秒级故障切换接管;可以进行异地数据库同步及数据级灾备。

▲资产管理系统同城及异地灾备架构

7.个股期权报盘口库同城与异地灾备

期权是交易双方关于未来买卖权利达成的合约。就个股期权来说,期权的买方(权利方)通过向卖方(义务方)支付一定的费用(权利金),获得一种权利,即有权在约定的时间以约定的价格向期权卖方买入或卖出约定数量的特定股票或 ETF。针对个股期权报盘口数据库,英方软件可以提供同城及异地灾备方案,可以进行数据库应用高可用,实现数据库生产端和目标端的实时同步和容灾;可以进行本地到异地机房的远距离同步和通知,实现 A-B-C 三地数据库灾备模式。

▲个股期权报盘口库同城或异地灾备架构

8.影像系统非结构化数据实时同步

影像系统会存储投资者的开户视频、语音及电子凭证图形等非结构化数据。针对影像系统数据,英方软件可以提供非结构化数据的实时同步和异地灾备,可以在客户的纸质凭证转换成电子凭证图像时,从各分支机构获得的各类文件(影像文件、电子文档)上传至本地系统服务器,然后实时同步到本地目标端文件服务器,对于有异地灾备需求的机构,可以通过网络实时同步到异地目标端服务器。

▲影像系统非结构化实时同步架构

四、典型用户案例

▼ 海通证券两地三中心多策略灾备

项目亮点

针对开户系统 Oracle RAC 集群架构下数据库数据,实现主备数据库的读写分离,减轻了主库压力,同时通过过滤 DML 删除语句,实现历史库数据全部保留;针对开户系统 NAS 数据,通过增加一台同步主机服务器,实现 NAS 数据的准实时同步;这两种备份策略军实现了业务数据从本地到同城(上海),然后同城到异地(东莞南方中心机房)的多重保障。

用户介绍

海通证券股份有限公司成立于 1988 年,截至 2019 年 12 月末,公司总资产突破6300 亿元、归属母公司净资产突破 1200 亿元,分别排名行业第二、第三位。公司拥有卓越的综合性业务平台和成熟的海外业务平台,经营网点遍及全球 14 个国家和地区;在境内拥有 340 家证券及期货营业部,正式员工过万人,在境内外拥有近 1550 万名客户。2019 年,公司实现营业收入 344 亿元,归属母公司净利润 95.2 亿元,排名行业第二。分类评价结果继续保持行业最高水平 A 类 AA 级。

项目需求

开户系统核心为 Oracle RAC 集群架构,负责数据写入和内部人员查询使用。第三方厂商采集数据信息不允许从 RAC 架构上取,只能从目标端采集上数据,且实时性要求较高。同时 RAC 为了保持良好的性能,每年都需要把三年前的数据进行拆分,并保存到本地的历史库中。历史库保留从该系统上线以来所有数据,生产库数据也会同时保护到南方中心,进行异地的数据保护。开户系统 NAS 存储中存放着所有的开户资料,包含个人信息图片和视频录像,数据量约 30T,前端 Nginx 负载均衡对所有的业务服务器进行负载调度,中间 Tomcat 服务器对数据进行采集并上传,统一集中存放在 NAS 存储中,需要对 NAS 数据进行实时保护,因生产服务器压力大,对数据进行保护时不能对服务器产生较大影响。

▲开户系统 Oracle RAC 保护架构

▲开户系统 NAS 数据保护架构

实施过程:海通团队联合英方软件进行多策略灾备的部署:

1. 针对 Oracle RAC 集群架构,开户系统数据实时同步到广东路机房备机,生产库删除历史数据,备机也执行相同操作;同时备机实时同步至历史库,备机删除数据,历史库不删除数据,保留所有已同步数据;然后广东路机房生产库和历史库数据实时同步到南方中心机房;

2. 针对 NAS 数据,对数据进行本地实时保护,本地准备一台大容量的服务器对 NAS 存储中的数据进行实时保护,只保留近三个月的近线数据,当 NAS 存储发生未知原因宕机,由本地 NAS 备份服务器进行接管,防止业务中断;同时异地对 NAS 存储的数据进行准实时级保护,保存一份完整的数据副本,同时满足灾备等级的要求。为满足用户要求,增加一台服务器同步主机,进行压力转移,生产主机捕获数据写入消息发给同步主机,由同步主机对数据进行实时同步。

▼ 国泰君安证券统一数据管理平台

项目亮点

统一数据管理平台全面展示了业务系统内各种物理机、虚拟机、异构数据库、多种应用的数据实时同步和管理,助力国泰君安各类业务数据、系统实现各类数据实时同步、 CDP(持续数据保护)、各类数据库实时同步、各类虚拟机保护、异地容灾、多副本快速交付和多应用数据全面统一管理。

用户介绍

国泰君安是中国证券行业长期、持续、全面领先的综合金融服务商。2011 到 2018 年,国泰君安的营业收入连续八年名列行业前三,在致力于实现高质量增长、规模领先的同时,注重盈利能力和风险管理。自 2008 年以来,国泰君安连续十二年获得中国证监会授予的 A 类 AA 级监管评级,该评级是迄今为止中国证券公司获得的最高评级。

项目需求

国泰君安当前各种业务和管理 IT 系统有 200 多个,这些系统每天新增的各种结构化和非结构化的数据达几个 TB,而且呈现加速之势。针对多地多中心各个 IT 系统数据保护存在的问题,结合公司数据治理的要求和数字化转型的方向,国泰君安提出了按照全域、多层次、多策略的理念,构建了业内首个统一数据管理平台。

▲数据管理平台架构(部分)

实施过程:国泰君安团队联合英方软件进行统一数据中心平台架构的部署:

1. 在本地到同城的数据中心,通过数据实时同步软件和数据库同步软件,实现业务系统内各类物理机、虚拟机、异构数据库、多种应用的数据实时同步和统一的运营管理;

2. 针对关键的业务数据,通过 CDP 技术实现数据从本地到同城到异地的持续保护,当发生逻辑错误、硬件故障及自然灾害等潜在风险事件时,可根据需求将数据恢复到任意时间点;

3. 针对关键的应用系统和数据库系统,通过高可用方案实现本地到同城的连续性保护,实现数据不丢,业务不停。

▼ 安信证券多对多池化高可用集群

项目亮点

安信证券多对多池化高可用集群可实时监控应用系统的运行状态,侦测到故障时执行高可用切换,实现业务的秒级接管和迭代接管,具备应用的快速无缝切换、分组切换、图形化管理、独立于软硬件平台、简单灵活的部署方式、满足国产化需求等特点。

用户介绍

安信证券股份有限公司成立于 2006 年 8 月,注册资本 70 亿元,并先后于 2006 年 9 月、12 月以市场化方式收购了原广东证券、中国科技证券和中关村证券的证券类资产。公司现为全牌照综合类券商,多项业务排名进入全国前列。2009 年至2018 年,公司连续 10 年获得 A 类 A 级以上行业分类评级,其中 2011 年至2013 年达到行业最高的 A 类 AA 级。

项目需求

安信证券对接银行、交易所、登记公司等的三方存管业务和银衍业务等应用程序(或直接由对方机构提供的应用程序),在技术架构设计上受限于对方接口规范,大多无法实现高可用冗余部署的需求,导致了应用单点的出现,而且这些单点往往呈现数量较多、难以改造的特点,运维团队需投入大量的人力物力来保障这类应用服务的连续性。为此,需要将备端的资源组成资源池,实现生产故障在备端的迭代接管功能。

▲多对多池化高可用集群架构

实施过程:安信证券团队联合英方软件进行三方存管业务和银衍业务多对多池化高可用集群的部署:

1. 在银行中间件集群中,生产部署了 9 台主用服务器和 4 台备用服务器,当某主服务器发生故障时,将由 4 台备用服务器中优先具备接管条件服务器进行接管,以此类推;

2. 在三方存管业务的三方交易网集群中,部署 2 主 2 备;在银衍业务的三方交易网关集群中,部署 1 主 1 备,接管方案同上;

3. 针对该方案的 VIP 功能管理,硬件资源的管理可通过物理 IP 实现,对于有 IP 绑定需求的服务器,系统可增加虚拟 IP 来承载业务入口;如果没有就不需要增加,节省 IP 资源;

4.针对服务器资源的维护,在无须停机的情况下,可将系统应用切换至资源池的服务器集群中,待新机替换旧机,或系统升级、补丁修复后,再切换回来,整个过程无须停机,对业务不影响,可满足 7×24 小时服务应用程序的业务连续性保障需求。

▼ 珠峰保险多策略云灾备

项目亮点

珠峰保险本地到云端的多策略灾备方案,不仅通过业内领先的华为云平台,实现了容灾资源的弹性扩容和低成本投入,还全面、高效、稳定地保障业务数据安全,降低因单数据中心故障而导致的数据丢失的风险。同时,也为珠峰保险的数字化运营体系的研发和推广,提供安全保障,助力珠峰保险数字化的转型升级。

用户介绍

珠峰财产保险股份有限公司是经原中国保险监督管理委员会(保监许可【2016】371 号)批准设立的全国性财产保险公司,积极倡导“对客户负责,对员工负责,对伙伴负责,对社会负责,对股东负责”的经营理念,建设矩阵式扁平化管理的组织架构体系,以大数据、云计算为基础的精益运营体系、客制化的产品配置及核保定价体系、自动核赔快速理赔体系和体验为先的客户服务体系,铸造珠峰保险品牌。

项目需求

随着业务范围的不断拓展,以及消费群体的不断壮大,珠峰保险本地生产中心存储的业务数据成倍增长,为强化海量核心数据的安全管理,避免单数据中心潜在的安全威胁,保障业务的正常有序的开展,珠峰保险计划构建一个异地灾备中心,主要挑战和需求包括异地灾备中心的选址、规划、建设、链路设计等时间周期长;异地灾备无论是前期的建设投入,还是后期的运维成本,都非常高;本地生产中心存储海量的 NAS 数据,需要在带宽有限的情况下,实现数据的实时传输。

▲珠峰保险云灾备架构

实施过程:珠峰保险选择采用英方和华为云联合推出的云灾备解决方案:

1.在华为云上构建一个灾备中心,通过 i2COOPY 对数据备份服务器和 NAS 文件服务器采用不同的备份策略。珠峰保险通过账号购买计算、存储、安全、容灾等 IT 资源,在华为云上搭建灾备中心,即买即用;

2.在远距离、窄带宽、平台异构的情况下,通过基于字节级增量数据实时同步技术,实现珠峰保险重要数据从本地到云端的实时复制和同步;

3.针对本地 NAS 共享存储中的文档、图片、视频等海量信息,通过 i2COOPY 实现本地到云端的定时同步备份,达到数据级异地灾备目的。

五、小结

随着金融科技的快速发展和机构数字化转型的推进,金融业务互联化正在成为趋势,在这个快速发展演进过程中,金融机构的竞争力,将逐渐从传统的业务渠道、管理和销售能力,延伸到以数据管理和数据运营的能力。未来,如果一家金融机构没有数据管理和运营的能力,它可能就没有定价权,因为它失去了这个行业最根本的风险定价和信用识别的能力。所以对于数据安全和业务连续性的保障,已经不仅仅是关乎监管合规的问题,它已经上升到可以帮助机构提升业务竞争力的高度。

及时响应,快速服务,为您保驾续航

立即注册

请先完成图形验证

验  证  码:

请先完成图形验证

验  证  码:

隐私声明
当您在本网站进行合作伙伴注册登记,本网站将收集您的相关信息,并保存记录。本网站收集的个人信息包括但不限于:姓名、地址、公司、所在地区、电话号码以及电子邮件地址等。您主动提供的信息越多及越准确,我们就能够更好地为您提供有关服务。
咨询·购买