金融行业系统灾备建设白皮书.docx

金融行业系统灾备建设白皮书目 录 金融行业灾备建设特点及案例剖析696.1 金融行业灾备建设特点及案例剖析806.1.1 行业概述806.1.2 行业现状与需求836.1.3 应用场景与解决方案846.1.4 典型用户案例906.2.5 小结94 灾备市场与行业趋势1377.1 灾备市场概况1377.1.1 市场高速增长1377.1.2 市场多元发展1387.2 未来五年（2020-2025）趋势1397.2.1 信创推动核心技术自主研发1397.2.2 合规性仍是推动行业发展主因1407.2.3 平台化推进灾备产业化发展1417.2.4. 灾备人才和用户群体持续增长142 金融行业灾备建设特点及案例剖析数字化转型加速了行业的信息化建设，如何保障信息化建设安全，国家已经从法律层面制定了一系列的法规条文，并明确了信息运营主体的职责。在这个大背景下，灾备建设落实到具体的建设工具，无外乎数据的容灾备份、迁移、恢复等技术产品。但每个行业的信息系统和数据特点不同， 也造就了不同的灾备解决方案。为了更真实地展现重点行业的灾备建设特点，本章节涉及的行业概述、应用场景和典型案例， 主要来自英方软件近百位一线技术工程师的实践。这些内容几乎全面覆盖了各个行业的灾备特点和需求，在具体的应用场景和方案剖析中，也可以作为大家参考的重要的实践内容。6.1 金融行业灾备建设特点及案例剖析6.1.1 行业概述金融是指经营金融商品的行业，它包括银行业、保险业、信托业、证券业、租赁业、基金业、期货业。金融系统和数据具有全行业高标准的业务连续性和监管安全要求，超重大的系统与数据安全事件，甚至可能引发局部的系统性市场风险。为此，对市场盈利性金融机构的监管，是我国金融主管部门的主要职责之一。当前，我国的金融监管部门简称“一行三会”。一行是指中国人民银行， 三会是指中国银行保险监督管理委员会（银监会）、中国证券监督管理委员会（证监会）和中国保险监督管理委员会（保监会）。当银行、证券、保险等金融机构发生包括系统运行的安全事故时， 会由上级管理机构进行通报、警告和惩罚。图 6.2-1 中国金融体系结构金融行业具备信息化程度高和信息安全要求高两大特征。金融科技化是推动金融业务快速增长的引擎之一，金融信息化程度越高，业务覆盖面越广，业务效率越高，与此同时，机构信息系统和数据遭受网络攻击、逻辑错误、自然灾害的挑战也越大。进入云计算和大数据时代的到来，金融信息化程度更高，其中以互联网金融业务的快速普及和高频交易最为突出，这也使得部分金融 IT 系统处于 7*24 小时超负荷运载状态。业务应用场景的变化演进，也给系统运维带来更大挑战，例如留给运维人员系统升级、迁移和补丁修复等计划性停机的时间窗口越来越小。那么，如何保障金融机构信息系统安全高效的运行，不仅要选择适合自身生产环境的技术方案， 还要考虑不同信息系统采用不同灾备方案，以达到 TCO 的最优化。例如，针对系统的热备和冷备 模式，如何突破传统的 1:1 配置方式，实现灾备中心软硬件资源利用最大化，就是现在很多证券机构需要突破的难题。此外，针对信息安全的监管要求，监管单位会对银行、证券等金融机构提出具体的建设要求。例如，银监会在 2011 年出台的 BCM 监管指引，就对商业银行的 RTO 和 RPO 提出了明确的量化指标，运维人员需要根据业务重要程度实现差异化管理，明确各业务恢复的优先顺序和恢复指标。原则上，重要业务恢复时间目标不得大于 4 小时，重要业务恢复点目标不得大于 0.5 小时。同时， 商业银行应当至少每三年开展一次全面的业务影响分析；应当识别重要业务，明确重要业务归口管理部门、所需关键资源及对应的信息系统，识别重要业务的相互依赖关系，分析、评估各项重要业务在运营中断事件发生时，可能造成的经济损失和非经济损失。（1）信息安全等级保护建设自主保护级、指导保护级、监督保护级、强制保护级、专控保护级，作为我国信息系统安全等级保护的五大经典分类级别，为金融机构在进行等保建设时，提供非常清晰的建设指引。在综合其他金融机构等级保护建设特点，我们总结了金融机构信息安全等级保护的三大阶段。一是系统等级划分阶段。根据等保五级分类，运维人员需要全盘统计和分析所有运行系统的重要程度，对于复杂庞大的综合性信息系统，运维人员需要在横向和纵向两个维度将其分解为多个子系统，清晰描述和定义主系统与子系统的结构关系，再按照等级保护要求将其分类。二是规划与设计阶段。在第一阶段的基础上，通过对业务信息系统进行安全域划分、保护对象分类，建立信息系统的分域保护框架，进行安全体系和安全技术体系两方面的安全方案设计，包括系统分域保护架构建立、选择和调整所选等级的基本安全要求、安全规划和方案设计，制定安全技术解决方案和安全管理解决方案。三是实施、等级评估与改进阶段。在规划与设计完成之后，运维部门开始着手安全方案的选择， 包括总的实施方案的目标、时间、方法，以及第三方供应商技术产品的甄选等。对于实施完成的技术方案，按照等级保护的标准要求，邀请外部的评估机构对系统方案进行评估，如果等级标准不达标， 需要改进或重新建设；如果等级标准达标，则对最终结果进行验收，并在一定周期内，对系统的安全风险进行评估，如果评估发现系统不达标，则需要进行系统重新定级和建设。目前，银行、证券、保险、基金等金融机构在等级保护建设方面，引领了整个行业的业务连续性和数据安全的发展。同城灾备、异地灾备、私有云灾备、两地三中心等多种方案综合交叉部署应用， 在符合等级保护要求的同时，最大限度确保各类系统和业务数据的安全性。（2）金融机构信息安全的法律法规金融机构分类较多，不同行业发布的法律法规各不相同，本内容以信息安全要求最为严格的银行和证券为代表，列举相关重要的现行法律法规：证券期货业数据分类分级指引 2018 年 9 月 27 日同日公布实施，数据分类是按照 GB/T101132003 中的线分类法和 GB/T 222402008 中的定级方法为基础进行分类的。目的是在数据分类基础上，对已分类数据按照数据泄露或损坏造成的影响进行分级，形成统一的分类分级方法。同时，在数据用语的使用过程中，也强调予以统一。证券期货业信息安全保障管理办法（证监会令2012第 82 号）第四条规定：证券期货业信息安全保障的责任主体应当执行国家信息安全相关法律、行政法规和行业相关技术管理规定、技术规则、技术指引和技术标准，开展信息安全工作，保护投资者交易安全和数据安全，并对本机构信息系统安全运行承担责任。银行业信息系统灾难恢复管理规范（JR/T 00442008）第八章灾难备份系统建设时明确： 根据灾难恢复策略制定灾难备份系统技术方案，包含数据备份系统、备用数据处理系统和备用网络系统，技术方案中所涉及的系统应获得同生产系统相当的安全防护水平和具有可扩展性；其次，为满足灾难恢复策略的要求，应对技术方案中关键技术应用的可行性进行验证测试，并记录和保存验证测试的结果；最后，应制定灾难备份系统集成与测试计划并组织实施，通过技术和业务测试，确认灾难备份系统的功能与性能达到设计指标要求。本章节整理了证券和银行机构的业务连续性和数据安全建设的法律法规及文件，供大家参考：“关于证券信息安全政策法规”证券期货业信息安全保障管理办法（证监会令 2012 第 82 号）证券期货经营机构信息系统备份能力标准（证监会公告201110 号）证券期货业信息安全事件报告与调查处理办法（证监会公告201246 号）证券期货业信息系统安全等级保护基本要求（试行）（JR/T 0060-2010）证券期货业数据分类分级指引（JRT 0158-2018）“关于银行信息安全政策法规”银行业金融机构信息系统风险管理指引（银监会 2006）银行业重要信息系统突发事件应急管理规范（试行）（银监会 2008）商业银行信息科技风险管理指引（银监会 2009）商业银行业数据中心监管指引（银监会 2010）商业银行业务连续性监控指引（银监会 2011）网上银行系统信息安全通用规范（JR/T 00682020）银行业信息系统灾难恢复管理规范（人民银行 2008）关于进一步加强银行业金融机构信息安全保障工作的指导意见（人民银行 2006）“其他涉及金融类信息安全政策法规”保险信息系统上线运行基本要求 JR/T 01792019金融行业信息系统信息安全等级保护实施指引(JR/T 0071-2012)随着我国金融市场的进一步开放和外资准入门槛降低，以及科创板、注册制、港股通等金融改革举措的推进，金融信息系统的安全性和规范性建设，将迎接更大的挑战。其中，确保系统的业务连续性将是重中之重，它关系到广大投资者和用户日常的投资行为和经济消费行为，任何非计划性的停机，都可能引起极大的经济损失和非经济性影响，并可能由此遭受监管部门的处罚。6.1.2 行业现状与需求金融行业分门别类繁多，不同领域的金融机构或相同机构的不同系统，根据等级保护的要求， RPO 与 RTO 的要求都不尽相同。但金融机构对数据零丢失和业务连续性要求高是冠绝全行业的， 特别是银行和证券机构，丢失一个数字 0，账面上的金额可能就是天壤之别。为此，金融机构要尽可能接近于国际标准 SHARE78 的 Tier-6 级别。其中，以银行架构最为严格，它要求采用两地三中心或主备等多种模式构建灾备系统，在对各个数据中心的基础架构进行规划时，也要做好数据同步复制和数据中心双活的规划，通过裸光纤 /DWDN 实现数据中心与各个营业网点的数据同步，同时同城数据中心应距离大于 50 公里，异地数据中心大于 300 公里，保障机房不会因为地震、洪水等区域性灾难受到全面的破坏，确保银行的数据不丢，业务不停。除了银行，其他金融机构也会依据行业监管要求，构建自身的灾备系统，而金融机构的灾备应用场景也最为丰富。例如，从规模庞大的两地三中心、异地灾备、同城灾备、云灾备，到同机房内的双活、双机双柜、集群高可用、传统备份等场景，可以说是包罗万象。但是这也给运维带来极大挑战，以证券公司为例，各大券商的灾备中心的架构通常采用虚拟化技术，实现生产端物理机 + 虚拟机，灾备端以虚拟机为主的配置。其中，生产端物理机和虚拟机存在两种形态：一种是应用和数据是前后端分离部署，如银行三方存管的中间件类型（无状态、无数据），数据存放在专用的数据库系统中；一种是应用和数据一体化部署，数据在本机或以 SAN/NAS 等形式存储。证券生产中心当前主要以第一种前后端分离部署为主。如果按照行业法规和监管要求，每增加一个生产系统，灾备中心就对应建立一个备份系统， 那么灾备中心最终形成与生产环境主备 1:1 的资源配置策略。这就给运维人员带来极大挑战，据统计，一个中型券商的实际生产应用系统已超过 200 套，按照 1:1 的资源配置，灾备中心的备份系统就堆积成山，并由此带来一系列的运维管理问题。例如，在备机普遍采用冷备、高可用和组等运营模式下，备机系统已经存在重复建设、冷备虚拟机使用率低，系统处于空转待命状态等问题，日积月累，就造成灾备中心的硬件设备、网络资源浪费严重。同时，根据行业监管的要求，运维人员要进行周期性应急演练确保备机系统的可用性， 以保证应急时的业务连续性。但是，传统的冷备方式，第一在资源上备机会占用跟生产系统一样的资源；第二在实际生产应急或者应急演练时，运维人员需进行一系列复杂操作进行紧急主备切换， 此时备机是否可用，以及人为操作失误等问题都会影响整个应急过程以及业务连续性，且生产系统两三百套，其可用性验证如果通过手动操作，那是一个浩大的人力工程。为此，基于云架构的智能云灾备中心，正在被更多的证券机构所关注，它要解决资源复用、系统备份与恢复、演练自动化、快速搭建测试 / UAT 环境等问题，实现灾备中心的智能运维，减轻运维人员的工作量。其他的金融机构，也会面临上述问题，但是可能由于底层基础架构不同，所应对的系统规模不一样，而等级保护要求的不同，也会造成系统和数据灾备方案的千差万别。我们综合分析银行、证券、保险、基金等主要金融机构，发现主要需求包括：海量数据的备份、CDP、实时复制数据库数据跨平台迁移和读写分离海量业务系统 / 虚拟机跨平台迁移主备业务系统的应用高可用提升灾备中心的智能运维水平大规模灾备系统可用性验证的自动化两地三中心、同城 / 异地、云灾备的规划咨询综上，金融机构灾备系统建设，是一项严格且浩大的技术工程，它涉及应用层、网络层和数据层的各种环境架构，因此它对供应商的产品性能、功能、兼容性以及技术服务团队都提出了非常高的要求。6.1.3 应用场景与解决方案金融机构不断变化的应用场景，将推动灾备技术方案进行持续地创新，这是新灾备方案区别于传统灾备方案的显著特征。但是，对于金融机构而言，业务系统和数据的保护，这个总体目标是不变的，只是业务系统的重要程度会发生变化，这也迫使运维人员重新规划灾备系统的建设方案。为了解决系统复杂度问题，通常运维人员会先进行系统属性的划分。我们一般会将其划分为业务系统和非业务系统，根据这个属性和等级保护要求进行应用场景的识别和资源配置，并最终落地部署。下面，针对金融行业细分领域对安全等级的不同，以及不同客户生产环境存在的差异化，灾备解决方案也会有所不同，下面列举部分灾备方案系统供大家参考。（1）银行两地三中心及异地多活方案首先，银行两地三中心模式，是指有两个数据中心在同城作为生产中心机房，它们之间采用同步数据复制方式，两边数据中心完全一致。但是，由于两个数据中心距离会超过 50 公里，所以即使两边的网络采用了裸光纤 /DWDN 的传输模式，还是会存在数据延时的情况，因此也不是距离越远越好，最好不要超过 100 公里，否则同步复制的延时可能超过上限的数值（一般 5 毫秒）时，可能导致数据库系统出现故障。作为两地三中心的异地数据中心，与生产中心的距离一般超过 300 公里，目的是保障业务数据的多一份保障，为了节省成本，通常可以采用异步数据复制的方式来实现数据的同步。一般情况下，只有发生极端事件才会导致同城双活数据中心停止提供服务，所以异地灾备中心多半不作为关键应用宿主地，某些情况下是完全冷备，即使部分机构的异地灾备中心部署的应用，但通常不对外提供服务，所以用户不会访问到异地的点。原因是数据从生产级数据中心到异地灾备中心是异步数据复制，延时会比较大。相比于其他金融机构，银行在早期的基础架构规划时，就会将灾备作为必选项纳入方案中，后期更多是以数据同步、数据库读写分离、虚拟机备份等建设为主。英方软件i2COOPY 实时数据同步软件、i2Move 系统热迁移软件、i2Active 数据库同步软件，可以为用户提供数据实时同步复制和系统热迁移，且适合远距离、窄带宽、跨平台的环境；i2VP 则可以提供无代理的虚拟机备份。图 6.2-2 两地三中心架构其次，部分大型银行会采用异地多活的模式，这是一种需要投入巨额费用的灾备模式，个别银行的某些关键应用已经在此模式下得到了验证。异地多活首先是要做到同城双活或者同城多活， 就是数据在同城网络环境下进行高速同步。真正的异地多活需要多个跨地域的数据中心，距离达到1000 公里以上，在这么远的距离下，对技术架构和网络传输是一个巨大的挑战。（2）证券机构智能云灾备中心方案智能云灾备中心是近来非常突出的创新方案，它通过在灾备端以虚拟化技术，实现存储和计算资源的池化管理，然后通过构建智能云（VMware）灾备平台，实现生产端物理机、虚拟机以 VMDK 文件备份到 VMware 平台。正常情况下，备份文件只占存储资源，不占用计算资源。当系统需要恢复时，可以通过 NFS 协议挂载瞬时恢复，然后通过虚拟机启动进行接管，为生产持续对外提供服务。图 6.2-3 智能云灾备中心架构它解决了传统备份中心在前后端分离部署的环境下，生产系统与备份系统 1:1 配置所带来的运维难题。同时它提供在隔离网络环境下，进行大规模备份系统可用性验证自动化的功能，以及帮助生产人员快速搭建测试或 UAT 环境，大大地降低了运维人员的工作量，实现了灾备中心资源复用和共享的目标。它通过基于 B/S 架构的管控平台，对灾备中心的设备、系统、状态、资源使用和运行情况做统一的量化管理和资源调配，实现灾备中心的智能化运维。在智能云灾备中心的运行过程中，英方软件 i2FFO 全服务器备份可以实现物理机到虚拟文件的备份，i2VP 可以实现虚拟机到虚拟文件的备份，i2CDM 则通过块变化实时复制技术，将变化的数据实时同步到灾备中心，确保两边数据的一致性。（3）证券行情分发与高可用切换方案证券行情一般是指股票价格、涨跌幅、成交量、成交额、市盈率等股票行情。天下行情，速度为王，唯快不破，为此行情分发也分为极速行情和普通行情。极速行情是从交易所机房出来，直接连接到券商机构在交易所同一机房的行情服务器，不走外部网络，时延可以低至微妙级。2019 年上半年，整个证券市场引发了一场行情比速的对比，各家券商随之对极速行情的转发需求越来越强烈。普通行情则是从交易所出来，通过网络传输分发到券商各营业网点，然后传输到投资者终端，这种环境下的行情时延主要考虑网络时延。证券行情按格式又可分为流行情和文件行情。相同环境下，流行情是要比文件行情要快，同时流行情可以转文件行情，但不能反过来，这主要是与行情格式的发展历史有关。从深交所和上交所两大交易所看，深交所 2016 年之前是 V4DBF 文件行情，2016 年至今则是 V5 流行情（BINARY 协议、STEP 协议）为主；上交所 2018 年前是 FAST 文件行情，2018 年是 FAST 文件行情 +FAST 流行情+EZSR 组播流( 过渡阶段)，2019 年下半年至今是 FAST 文件行情+ 上交所流行情(MDGW 流行情 )（BINARY 协议、STEP 协议）。图 6.2-4 行情分发高可用架构英方软件可以将流行情和文件行情分发集成在同一个软件产品 i2Distributor 中，根据客户需求自定义配置。i2Distributor 支持多级行情分发；允许指定多个父节点，以达到负载均衡、高可用性； 支持文件分发和流行情在同一个节点中同时运行；支持上海 FAST 流行情、LDDS 流行情不落地转发；支持多实例部署，节省服务器资源；支持流行情转换老版行情 DBF 落地转发；支持组播流转发， 可以更好地节省总部出口带宽；支持 LZMA 压缩技术，支持多级别的压缩选择（6 个级别的压缩）， 最高压缩率达到 98%。（4）证券其他系统灾备方案 1）中间件系统多对多池化高可用迭代接管证券行业的业务系统有很多以前后端分离部署的方式，实现应用和数据库的分离部署，为此产图 6.2-5 多对多池化高可用迭代接管架构生了大量无状态、无数据的应用系统。针对这种生产环境，通常采用主备一对一的方式，实现生产服务器到灾备服务器的故障接管。这种传统的高可用方法，存在两大问题：一是备端存在单点故障风险，即备端如果挂了，整个系统就挂了；二是采用 1:1 的高可用配置，造成资源浪费，即当系统都正常运行时，灾备端服务器就处于空跑状态。针对这种情况，英方软件可以提供备端多对多池化高可用迭代接管的方案，实现备端服务器资源的池化迭代管理。例如，可以通过设置 5%-20% 的接管率，即允许最大同时在线故障服务器数量是 20 台，可以节省 80% 的服务器资源。当生产端的服务器出现故障时，控制平台会优先指定资源池里具备接管条件的备用服务器进行接管，依次类推，最终实现多对多池化管理。2）同城交易系统 HA 自动切换同城交易系统为证券机构重要的生产系统，多采用 Window+MSSQL 结构，在数据量变化方面， 场景变化可以设为总容量约 500G，每天增量 30G 左右，同时清算操作会删减近 20G。同城交易系统目前多采用冷备系统，即灾备机日常处于冷备的状态，当程序运行所在机器发生故障后，通过另外一台机器人工操作重开报盘程序的方式完成故障切换，从而重新对外服务。此方案故障切换完全依赖手工，增加了切换过程中人为失误的风险，如果能实现全自动切换则能大大减少 RTO 和 RPO 值。英方软件 i2Availibility 是一种自动切换的灾备解决方案，它提供针对多种应用、任何距离内的高可用性服务。即当生产系统出现异常时，它将生产系统上的应用按需自动切换到灾备服务器上， 实现应用级快速切换，减少服务的中止时间，保持业务应用的高度可用性。3）自营资管系统两地三中心灾备自营资管系统为证券行业一个关键应 用，系统架构常用 Window+MSSQL 或者 Linux+Oracle，用户通过灾备技术方案进行应用保护，可以实现异地机房数据库的远距离实时同步和两地三中心的灾备保护。图 6.2-6 自营资管系统两地三中心灾备架构4）融资融券交易系统多策略灾备司提融资融券交易又称证券信用交易或保证金交易，是指投资者向具有融资融券业务资格的证券公供担保物，借入资金买入证券（融资交易）或借入证券并卖出（融券交易）的行为。它包括券商对投资者的融资、融券和金融机构对券商的融资、融券。图 6.2-7 融资融券交易系统多策略灾备架构针对融资融券交易系统，英方软件可以提供多策略的灾备方案，可以进行数据的实时复制，实现数据实时同步到备端数据库；可以进行数据库的高可用，实现数据库高可用的秒级切换；可以进行数据库数据任意时间点的数据恢复，实现数据库数据的 CDP 保护；可以进行多点数据容灾，提供同 LAN 及同城异地数据容灾。5）PB 投资系统 HA+CDP 保护PB 指平均市净率，是每股股价与每股净资产的比率。PB 是股票投资基本分析最常见的参考指标之一，与市盈率、市销率、现金流量折现等指标一样。PB 投资系统是为投资市净率而设的系统， 英方软件可以提供 HA+CDP 为主的灾备方案，可以进行数据的实时复制，实现生产端数据到目标端的实时同步；可以进行应用的高可用，实现生产端服务切换秒级转移到目标端；可以进行数据库数据任意时间点的数据恢复，实现数据库数据的 CDP 保护。图 6.2-8 PB 投资系统 HA+CDP 保护架构6）资产管理系统同城与异地灾备资产管理属于证券机构业务，可以为机构和个人提供限定性和非限定性集合资产管理、单一资产管理和专项资产管理，以及其他金融类资产管理业务。针对资产管理系统，英方软件可以提供同城及异地灾备方案，可以进行同城资产管理系统的应用高可用，实现应用系统秒级故障切换接管； 可以进行异地数据库同步及数据级灾备。图 6.2-9 资产管理系统同城及异地灾备架构7）个股期权报盘口库同城与异地灾备期权是交易双方关于未来买卖权利达成的合约。就个股期权来说，期权的买方（权利方）通过向卖方（义务方）支付一定的费用（权利金），获得一种权利，即有权在约定的时间以约定的价格向期权卖方买入或卖出约定数量的特定股票或 ETF。针对个股期权报盘口数据库，英方软件可以提供同城及异地灾备方案，可以进行数据库应用高可用，实现数据库生产端和目标端的实时同步和容灾；可以进行本地到异地机房的远距离同步和通知，实现 A-B-C 三地数据库灾备模式。 i2Availability图 6.2-10 个股期权报盘口库同城或异地灾备架构8）影像系统非结构化数据实时同步影像系统会存储投资者的开户视频、语音及电子凭证图形等非结构化数据。针对影像系统数据， 英方软件可以提供非结构化数据的实时同步和异地灾备，可以在客户的纸质凭证转换成电子凭证图像时，从各分支机构获得的各类文件（影像文件、电子文档）上传至本地系统服务器，然后实时同步到本地目标端文件服务器，对于有异地灾备需求的机构，可以通过网络实时同步到异地目标端服务器。A H6.1.4 典型用户案例图 6.2-11 影像系统非结构化实时同步架构（1）海通证券两地三中心多策略灾备项目亮点：针对开户系统 Oracle RAC 集群架构下数据库数据，实现主备数据库的读写分离， 减轻了主库压力，同时通过过滤 DML 删除语句，实现历史库数据全部保留；针对开户系统 NAS 数据， 通过增加一台同步主机服务器，实现 NAS 数据的准实时同步；这两种备份策略军实现了业务数据从本地到同城（上海），然后同城到异地（东莞南方中心机房）的多重保障。项目需求：开户系统核心为 Oracle RAC 集群架构，负责数据写入和内部人员查询使用。第三方厂商采集数据信息不允许从 RAC 架构上取，只能从目标端采集上数据，且实时性要求较高。同时 RAC 为了保持良好的性能，每年都需要把三年前的数据进行拆分，并保存到本地的历史库中。历史库保留从该系统上线以来所有数据，生产库数据也会同时保护到南方中心，进行异地的数据保护。开户系统 NAS 存储中存放着所有的开户资料，包含个人信息图片和视频录像，数据量约30T，前端 Nginx 负载均衡对所有的业务服务器进行负载调度，中间 Tomcat 服务器对数据进行采集并上传，统一集中存放在 NAS 存储中，需要对 NAS 数据进行实时保护，因生产服务器压力大， 对数据进行保护时不能对服务器产生较大影响。RHEL6.5RRAHCE1L160.254RRAHCE1L160.254图 6.2-12 开户系统 Oracle RAC 保护架构NginxTomcat图 6.2-13 开户系统 NAS 数据保护架构解决方案：1. 针对 Oracle RAC 集群架构，开户系统数据实时同步到广东路机房备机，生产库删除历史数据，备机也执行相同操作；同时备机实时同步至历史库，备机删除数据，历史库不删除数据，保留所有已同步数据；然后广东路机房生产库和历史库数据实时同步到南方中心机房；2. 针对 NAS 数据，对数据进行本地实时保护，本地准备一台大容量的服务器对 NAS 存储中的数据进行实时保护，只保留近三个月的近线数据，当 NAS 存储发生未知原因宕机，由本地 NAS 备份服务器进行接管，防止业务中断；同时异地对 NAS 存储的数据进行准实时级保护，保存一份完整的数据副本，同时满足灾备等级的要求。为满足用户要求，增加一台服务器同步主机，进行压力转移，生产主机捕获数据写入消息发给同步主机，由同步主机对数据进行实时同步。（2）国泰君安证券统一数据管理平台项目亮点：统一数据管理平台全面展示了业务系统内各种物理机、虚拟机、异构数据库、多种应用的数据实时同步和管理，助力国泰君安各类业务数据、系统实现各类数据实时同步、 CDP（持续数据保护）、各类数据库实时同步、各类虚拟机保护、异地容灾、多副本快速交付和多应用数据全面统一管理。项目需求：国泰君安当前各种业务和管理 IT 系统有 200 多个，这些系统每天新增的各种结构化和非结构化的数据达几个 TB，而且呈现加速之势。针对多地多中心各个 IT 系统数据保护存在的问题，结合公司数据治理的要求和数字化转型的方向，国泰君安提出了按照全域、多层次、多策略的理念，构建了业内首个统一数据管理平台。AOPSP AOPSP AOPSP AOPSPAPP APPOSOSAPP APPOSOSSQL ServerOracel mySQL 图 6.2-14 数据管理平台架构（部分）解决方案：1. 在本地到同城的数据中心，通过数据实时同步软件和数据库同步软件，实现业务系统内各类物理机、虚拟机、异构数据库、多种应用的数据实时同步和统一的运营管理；2. 针对关键的业务数据，通过 CDP 技术实现数据从本地到同城到异地的持续保护，当发生逻辑错误、硬件故障及自然灾害等潜在风险事件时，可根据需求将数据恢复到任意时间点；3. 针对关键的应用系统和数据库系统，通过高可用方案实现本地到同城的连续性保护，实现数据不丢，业务不停。（3）安信证券多对多池化高可用集群项目亮点：安信证券多对多池化高可用集群可实时监控应用系统的运行状态，侦测到故障时执行高可用切换，实现业务的秒级接管和迭代接管，具备应用的快速无缝切换、分组切换、图形化管理、独立于软硬件平台、简单灵活的部署方式、满足国产化需求等特点。项目需求：安信证券对接银行、交易所、登记公司等的三方存管业务和银衍业务等应用程序（或直接由对方机构提供的应用程序），在技术架构设计上受限于对方接口规范，大多无法实现高可用冗余部署的需求，导致了应用单点的出现，而且这些单点往往呈现数量较多、难以改造的特点，运维团队需投入大量的人力物力来保障这类应用服务的连续性。为此，需要将备端的资源组成资源池， 实现生产故障在备端的迭代接管功能。CTL CTL解决方案：图 6.2-15 多对多池化高可用集群架构1. 在银行中间件集群中，生产部署了 9 台主用服务器和 4 台备用服务器，当某主服务器发生故障时，将由 4 台备用服务器中优先具备接管条件服务器进行接管，以此类推；2. 在三方存管业务的三方交易网集群中，部署 2 主 2 备；在银衍业务的三方交易网关集群中， 部署 1 主 1 备，接管方案同上；3. 针对该方案的 VIP 功能管理，硬件资源的管理可通过物理 IP 实现，对于有 IP 绑定需求的服务器，系统可增加虚拟 IP 来承载业务入口；如果没有就不需要增加，节省 IP 资源；4. 针对服务器资源的维护，在无须停机的情况下，可将系统应用切换至资源池的服务器集群中， 待新机替换旧机，或系统升级、补丁修复后，再切换回来，整个过程无须停机，对业务不影响，可满足 724 小时服务应用程序的业务连续性保障需求。（4）珠峰保险多策略云灾备项目亮点：珠峰保险本地到云端的多策略灾备方案，不仅通过业内领先的华为云平台，实现了容灾资源的弹性扩容和低成本投入，还全面、高效、稳定地保障业务数据安全，降低因单数据中心故障而导致的数据丢失的风险。同时，也为珠峰保险的数字化运营体系的研发和推广，提供安全保障， 助力珠峰保险数字化的转型升级。i2COOPYi2COOPY项目需求：随着业务范围的不断拓展，以及消费群体的不断壮大，珠峰保险本地生产中心存储的业务数据成倍增长，为强化海量核心数据的安全管理，避免单数据中心潜在的安全威胁，保障业务的正常有序地开展，珠峰保险计划构建一个异地灾备中心，主要挑战和需求包括异地灾备中心的选址、规划、建设、链路设计等时间周期长；异地灾备无论是前期的建设投入，还是后期的运维成本， 都非常高；本地生产中心存储海量的 NAS 数据，需要在带宽有限的情况下，实现数据的实时传输。解决方案：图 6.2-16 珠峰保险云灾备架构1. 在华为云上构建一个灾备中心，通过 i2COOPY 对数据备份服务器和 NAS 文件服务器采用不同的备份策略。珠峰保险通过账号购买计算、存储、安全、容灾等 IT 资源，在华为云上搭建灾备中心，即买即用；2. 在远距离、窄带宽、平台异构的情况下，通过基于字节级增量数据实时同步技术，实现珠峰保险重要数据从本地到云端的实时复制和同步；3. 针对本地 NAS 共享存储中的文档、图片、视频等海量信息，通过 i2COOPY 实现本地到云端的定时同步备份，达到数据级异地灾备目的。6.1.5 小结随着金融科技的快速发展和机构数字化转型的推进，金融业务互联化正在成为趋势，在这个快速发展演进过程中，金融机构的竞争力，将逐渐从传统的业务渠道、管理和销售能力，延伸到以数据管理和数据运营的能力。未来，如果一家金融机构没有数据管理和运营的能力，它可能就没有定价权，因为它失去了这个行业最根本的风险定价和信用识别的能力。所以对于数据安全和业务连续性的保障，已经不仅仅是关乎监管合规的问题，它已经上升到可以帮助机构提升业务竞争力的高度。7.1 灾备市场概况第七章 灾备市场与行业趋势2020 年受新冠疫情的影响，以餐饮、旅游和娱乐为代表的行业，受到了严重的冲击。上半年， 全世界主要经济体的 GDP 更是遭到重创。但是我们也可以看到，机构数字化转型的速度并没有受到太大的影响，反而在应对疫情造成的社交困境时，线上业务展示了非常强大的灵活性和韧性，这也极大地促进了文件同步、数据流动和业务连续性在安全合规方面的发展。2020 年国际安全形势也是推动市场发展的原因之一，包括以国家安全为借口对业务合规性的审查，蓄意挑起地区冲突，利用网络技术渗透攻击机构的重要系统和数据，以及对关键技术和制造业资源的争夺，都促使相关机构加大对数据和业务安全的保护将重要数据和系统进行多重保护， 以备机系统构被攻击时，可以有最新的数据进行业务的恢复。譬如，以半导体芯片为例，一些机构就加大了生产系统和业务数据的异地备份的保护力度。从中国第三方灾备技术服务商的市场营收分析，市场强劲的需求一直存在，但是第一季度因疫情采取的社交限制，确实给一线的销售带来挑战。不过随着疫情被控制，第二季度以后，销售的拜访及营销活动走出 V 字型的反弹。这表明中国灾备市场也具备强劲的发展韧性，而推动市场需求发展的两大因素：一个是中国经济的高速发展，市场主体充满活力，特别是今年提出的“新基建”战略，极大地提振了科技企业、资本和市场研究机构的信心，继续推动企业的数字化转型；一个是中国长期坚持的将信息安全纳入国家安全战略，并出台了“网络安全法”、“等保 2.0”、“数据安全（草案）”等一系列的法律， 以国家实行网络安全等级保护制度明文规定所有运营主体，需要对所辖的信息系统严格按照要求进行保护。7.1.1 市场高速增长各类研究机构对中国灾备市场的增长预估都非常乐观。智研咨询的报告显示：中国灾备行业市场规模从 2010 年的 49.8 亿元，增长至 2018 年近 180 亿元的市场规模，预计至 2022 年中国灾备行业市场规模可达 300 亿元以上。前瞻产业研究院的报告重点提到云灾备将成未来主流趋势，其中云灾备市场规模从 2013 年的1 亿元快速增长到 2018 年的 10 亿元，预计到 2022 年我国云灾备市场规模可达 70 亿元。信息技术研究和分析机构 Gartner 预计，到 2020 年存储安全（尤其是云存储安全）支出将继续攀升。如今复杂的地缘政治环境将法规遵从性推到了企业的首要任务，2019 年整体安全支出增长10.5%，预计未来 5 年云安全将增长 41.2%。同时，Gartner 也预计到 2021 年，使用备份而非归档方式来管理企业长期数据的比例将从 2017 的 30% 上升到 50%。根据白皮书内容编委的调查，在中国经济高速发展的三十多年中，特别是从 2010 年互联网开始进入高速发展