340 likes | 599 Views
第 9 章 数据大集中和灾难备份技术. 顾浩 胡乃静 董建寅等编著. 第 9 章 数据大集中和灾难备份技术. 数据集中带来了风险的集中,而风险的集中又让我们无法回避另一个话题 —— 灾难备份。 本章将介绍当前银行信息化中这两个热点技术 —— 数据大集中和灾难备份技术。. 9.1 数据大集中. 9.1.1 数据大集中的含义 ● 银行数据大集中可以的内涵可以用八个字来概括 : - 数据集中 : 集中是数据的 “ 相对 ” 集中,不是绝对集中; - 系统整合 : 整合是在数据集中基础上的应用整合和系统整合。. 9.1.2 国内银行数据大集中的进展情况.
E N D
第9章数据大集中和灾难备份技术 顾浩 胡乃静 董建寅等编著
第9章 数据大集中和灾难备份技术 • 数据集中带来了风险的集中,而风险的集中又让我们无法回避另一个话题——灾难备份。 • 本章将介绍当前银行信息化中这两个热点技术——数据大集中和灾难备份技术。
9.1 数据大集中 9.1.1 数据大集中的含义 ●银行数据大集中可以的内涵可以用八个字来概括: -数据集中: 集中是数据的“相对”集中,不是绝对集中; -系统整合: 整合是在数据集中基础上的应用整合和系统整合。
9.1.2 国内银行数据大集中的进展情况 ●1994年,工商银行最早提出来“大集中”的概念,叫“大机 延伸”。并率先在京、沪两地建立互为备份的数据中心。 2004年9月25日,工行成功地将全国业务集中到上海处理中心。 同时,工商银行还完成了澳门、新加坡、东京、汉城、香港等 亚洲地区分行的数据集中上挂工作,实现了中国工商银行亚洲 地区省外分支机构数据的集中处理。 ●农行在2003年完成全国数据处理中心的基本建设; 2004~2005年实施省级数据中心的合并,到2005年底全面完成大集中工程. ●中行于2004年已实现华北、华东、华南、西南、西北五大中心的区域数据集中,同时进行系统平台与应用软件版本的统一,目前西北和西南中心的核心系统已实现逻辑集中。
9.1.2 国内银行数据大集中的进展情况 ●建行计划在2001年9月完成一级分行业务数据集中处理,并完成全行一、二级骨干网络的重组优化工作,再用二年半到三年的时间实现大集中的目标。 ●交通银行已抓紧实现全行对公、对私业务处理系统的数据集中处理,并启动了海外数据中心的建设,其东京分行计算机系统于2004年4月1日正式挂接香港分行综合业务处理系统。同时完成了总行数据中心与海外数据中心的互联。 ●光大银行已在2004年6月底完成了全国的大集中,实现了业务的全行集中处理。 ●目前,国内的各家银行都在走大集中的发展之路,只是进程各有不同。那些能及早完成大集中工程的银行必将在激烈的竞争中占得先机。
9.1.3 数据大集中的必要性 1.银行信息化的四个阶段 • 从基于数据处理的业务来看,目前银行业信息化的发展经历了4个阶段: • 20世纪80年代中期:中国银行业开始电子化基础设施建设, 从手工业务处理流程逐步过度到计算机处理流程; • 进入90年代:以国有商业银行为主的银行电子化已经初具规模, 大多数银行营业网点已经走向业务处理电子化; • 到90年代中期以后:在单机应用基础上,并行多任务分布计算和分级处理渐趋成熟, 部分发达地区银行已经开始走向网络化发展阶段。 • 2000年以后:银行业进入到数据大集中的阶段 2.大集中前的问题 : (1)数据管理维护困难,不利于全行集约化经营 ; (2)风险大:中心多、数据分散, 随着业务量的加大, 风险越来越大, 管理难度加大。 (3)可扩充性差, 不利于保护投资。
3.大集中的优势 (1)将所有的客户数据与处理数据集中到一个数据库中, 不仅克 服了分散系统信息零散、交叉和重复的弊端, 更可为客户信息 资源事后分析处理提供完整依据。 (2)使大总行、小支分行的管理体制成为可能。 (3)电子化业务集中处理后, 软、硬件、人员等费用投资明显降 低 。 (4)为中国银行业适应国内竞争、参与国际竞争打下良好基础 、 克服了分散系统信息零散、交叉和重复的弊端 。
9.1.4 大集中的模式 1.机器设备集中模式 :指简单地将原来多个信息处理中心的设备集中.是最低层次的集中, 在信息化的初级阶段经常出现。 2.物理数据集中模式 :指部门内部数据集中到同一台主机或多台主机构成的集群系统中, 实现数据的集中存储和管理 . 3.应用处理集中模式 :指在部门软件体系架构中实现一体化设计, 以覆盖所有业务。物理数据集中模式和应用处理集中模式是目前采用最多的两种模式。 应用处理集中模式是最高 层次的“集中”,在应用处 理集中模式中, 跨国或全国 性部门一般都有多个数据 中心, 如工行的南北数据中 心。
管理数据集中 管理数据集中:针对数据分散情况,原有分散在各地或各部门的业务数据可通过网络方式,集中存储到同一个主机(主机群),以便于管理,这种集中模式与业务应用无关,在这个集中模式下可以相应地开发管理应用.国外的大银行目前基本上采用的是应用处理集中模式. 如:花旗银行在全球共有3个数据中心, 分别为CEEMEA中心(拉美部分地区、中/东欧、中东、非洲)和拉美中心、亚洲中心, 在基于统一的数据中心的基础上,按对公业务应用、客户应用和公共应用实现业务处理系统的整合,并通过规定路径提供给银行员工及客户使用。
9.1.5 数据大集中的应用案例 ●中国银行系统大集中的目标是:将二级行的数据集中到省行的 数据处理中心, 加强省行的金融监管力度 ;实现主要业务的全省联网;同时将各地市二级分行的主机逐渐变成网络节点机, 承担网络节点设备和本地特色业务 。 系统的设计原则如下: ●主机系统采用总行推广的ES/9000。 ●网点运行Sm@rtACE平台实现主机的各项业务功能。 ● 中间节点机采用AS/400作为网络设备,连接前端ACE和后台ES/9000。 ● AS/400能够实现本地特色业务。 ● 通过前端进行会计和储蓄等业务系统的整合, 实现统一的会计和储蓄系统, 同时实现综合柜员制。
Sm@rtACE 是一个针对金融行业前台系统的开发和运行软件平台,它能够实现前台系统所需要的人机交互界面控制、设备驱动、通讯传输及数据库操作等功能。 • Sm@rtACE 的前身是LXBS,它们都是在金融行业广泛应用数年的成熟产品,是神州数码行业解决方案的关键部分。其中ACE3.0则是国内第一个正式登记注册的金融软件产品。2004年Sm@rtACE产品发布ACE4.2版本,增加了更加强大的功能。 • 典型应用模式:
9.1.5 大集中的应用案例 ● 通过前端提供的一台服务器带 多个机构的功能,实现前端的地 区集中。 ● 系统具有良好的可扩展性和可 维护性,同时具有良好的可推广 性。系统的设计原则要求中间节 点机可以是AS/400、RS/6000或 CISCO路由器,保证系统可以应 用于其他系统结构下。 系统总体架构:采用ES/9000直接连 接CT方式运行,其他二级行地区 采用ES/9000穿透AS/400连接 Sm@rtACE 的方式实现。
ES9000、 RS6000和 AS400 • ES9000:作为大机,其性能和价格都高, 且大机的维护相对复杂, 需要人员较多, 在大机上的软件开发周期相对长些。国内可以做大机开发的软件公司相对而言是最少的。 但ES/6000使用C语言. • RS6000系列:现在IBM称其为“小深蓝”, 因为是基于Unix, 所以现在可使用RS6000进行软件开发的公司以及从事此方面的软件人员数量应该是三者种最多的。 • AS400:是纯粹的自成体系的计算机,IBM称其为iService, 其中i也就是integration(集成)。因为AS400的操作系统OS/400、数据库DB2/400以及许多软件都是随着机器集成的。 • 应用情况:ES9000这样的大型机, 一般都是中农工建此类的大银行才用, 另外有些制造业也用, 如武汉神龙,但因价格和维护等因素,普通的中小型企业与银行都没有用,但AS/400的高端产品功能也很强大, 一些中小银行(招商、广发银行)与一些中小型的企业也用,AS/400的应用范围在国内还是比较广泛的。AS/400相对也比较难,因为在400上以前用RPG开发比较多,而使用此语言的人当然是少数。
9.2灾难备份系统9.2.1灾难备份技术 1 .灾难备份的定义 ●灾难备份就是指利用技术、 管理手段以及相关资源确保 既定的关键数据、关键数据 处理系统和关键业务在灾难 发生后可以恢复的过程。 一旦灾难发生,灾难备份中 心就必须要在确定的时间内接替生产中心的运营、 恢复既定范围内的业务运作、保障企业业务连续 。 2005年我国国务院颁布的《重要信息系统灾难恢复 指南》中的定义,灾难是指由于人为或自然的原 因,造成系统运行严重故障或瘫痪,使信息系统支 持的业务功能停顿或服务水平不可接受、达到特定 的时间的突发事件。
关于灾难备份和灾难恢复技术 《指南》把灾难恢复定义为:“将信息系统从灾难造成的故障或瘫痪状态恢复到可正常运行状态,并将其支持的业务功能从灾难造成的不正常状态恢复到可接受状态,而设计的活动和流程”。 把灾难备份定义为:“为了灾难恢复而对数据、数据处理系统、网络系统、基础设施、技术支持能力和运行管理能力进行备份的过程。” 显而易见,灾难恢复比灾难备份的外延要大。因此,对国内惯用的“灾难备份”一词,今后要搞清其所指的确切涵义后再准确应用。例如,现在人们所说的“灾难备份”,如果是指既包括技术,也包括业务、管理的周密的系统工程,则应改为“灾难恢复”才更为精确。
2 .灾难备份的主要技术 ●一个完整的灾难备份系统主要由: –数据备份系统 –备份数据处理系统 –备份通信网络系统和完善的灾难恢复计划组成。 ●在灾难备份系统建设中,数据备份是关键,如何将数据(包括系统、应用和业务等数据)完整、实时地复制到灾难备份中心, 是灾难备份系统建设中首先要考虑的重点。 典型灾难备份系统 客户端 应用服务器 磁带机 备份 服务器 应用服务器
2 .灾难备份的主要技术1.数据备份技术 ●基于磁盘系统的灾难备份技术: 采用硬件数据复制技术,借助磁盘控制器提供的功能,通过专线实现物理存储器之间的数据交换。 –同步数据复制模式:来自处理器的更新数据在写入本地连接的磁盘系统之前,通过磁盘镜像技术, 将更新数据转发至异地的磁盘系统, 只有更新数据在两个磁盘系统完成写操作后, 本地磁盘系统才会向处理器返回写完成指令, 从而确保了两地磁盘系统数据的一致性和完整性, 即无数据丢失。这种模式的远端数据与本地数据的实时性强, 灾难发生时远端数据与本地数据完全同步.此法传输距离较短(<60km). –异步数据复制模式:本模式在软件灾难备份技术中广泛使用,来自处理器的更新数据首先被写入本地连接的磁盘系统, 并立即向处理器返回一个I/O写完成指令, 之后磁盘镜像系统在很短的时间内, 将更新数据发送至异地的磁盘系统。 优点:对应用程序的运行性能影响较小, 不影响本地的交易, 传输距离可长达1000公里以上, 受远程网络的影响较小. 缺点:远程磁盘系统的数据比本地磁盘系统的数据略有时间延迟, 若远程网络带宽较小, 网络阻塞较大。
1.数据备份技术 ●基于软件方式(操作系统级)的灾难备份技术 特点:与操作系统平台相关,对应用程序透明。此方式通过通 信网络,实现数据在两个不同地点之间的实时备份。 – S/390平台:异地并行耦合系统(Geographically Dispersed Parallel Sysplex, GDPS)是目前较为完善的灾难备份系统。GDPS将IBM S/390的并行Sysplex技术与磁盘系统远程复制技术PPRC(Peer to Peer RemoteCopy, PPRC)集成在一起, 并通过多系统耦合技术, 组成一个完整的灾难备份和恢复整体解决方案, 使客户的生产系统在发生灾难的情况下能快速恢复。
1.数据备份技术 –AS/400平台:一般用AS400的数据库日志和目标日志,通过数据备份技术将更新的日志实时地传送到远程异地的AS/400小型机上, 不断更新异地AS/400上的数据库和目标, 而使灾难备份中心可实时拥有一套完整的可供灾难恢复的数据库和应用系统。 –Unix平台:特点是, 它独立于硬件存储设备, 利用软件的复制功能, 提供逻辑卷级和文件系统级的远程数据复制能力。它可通过IP网络将数据及时地复制到异地灾难备份中心, 确保用户备份数据的及时性和完整性。 ●其它灾难备份技术的解决方案 –通过磁带库技术实现数据远程备份解决方案。 – Oracle、Sybase的数据库镜像技术解决方案。
2.数据的存储备份技术 ● DAS(又称SAS)存储结构 –是目前大部分园区网(例校园网)采用的存储方式。在DAS中,数据被存储在各服务器的磁盘族或磁盘阵列等存储设备中它适合小型企业,不适合数据吞吐量较大、并发用户数量较多的园区网的资源共享。 优点:存取速度快、建立方便 。 缺点:单点错误问题,扩展困难。 适用场合:适合小型企业,不适合数据吞吐量较大、并发用户数量较多的园区网的资源共享。 LAN 应用程序 文件系统 存储系统 服务器 存储设备 服务器存储设备 用户 用户
2.数据的存储备份技术 ●网络连接存储NAS存储结构 –以不消耗大量网络带宽而实现存储功能,这种存储结构可完全脱离服务器就能直接上网。数据的存储与处理功能分离,文件服务器只用于存储数据,主服务器只用于处理数据。 优点:实现简单,因数据的存储和处理功能分离,可消除网络的带宽并颈、建立方便.NAS设备不信赖于OS. 应用程序 LAN LAN 文件系统 文件服务器 存储设备 主服务器存储设备 用户 用户 存储系统
存储区域存储SAN存储结构 –用于连接服务器和存储装置( 大容量磁盘阵列和备份磁带库) 的专用网络。采用先进的光纤通道FC( Fiber Channel )和SCSI技术。 SAN的特点: ● SAN使用光纤通道调节技术, 及支持存储器与服务器之间 进行大容量数据块传递软件, 减少了发送对数据块的分割和 和对通信节点的预处理,实现了 数据块的高密度传递. ●光纤通道技术大大提高了服 务器与存储器的距离,最大距离 可长达150km。 ● 集中化的存储备份给企业的 数据带来了完整性,可靠性和安 全性。 ●虚拟存储的可伸缩性简化了网 络服务的使用和可扩展性 故障恢 复高效,提高了应用软件的 可用 性. 客户机 终端 终端 LAN 应用程序 文件系统 服务器 FC SAN 存储系统 存储器
三种模式的比较 • DAS的应用程序与存储系统是一体的, 通过系统总线可访问存储设备; • 传统的NAS是应用与存储分离的系统, 应用服务器通过LAN访问文件存储系统, 通常NAS以标准化协议(如NFS)提供服务; • 在SAN中, 文件系统与存储系统完全分离, 存储系统实际上成为运行应用程序的数据服务器,两者以高速光纤通道FC连接。 • 综上所述,SAN和NAS是当今两种主流的网络存储技术,它们克服了传统存储技术的缺点,为企业和银行的存储系统提供了可靠的解决方案,网络存储必将占有未来存储系统的主导地位。
9.2.2 灾难备份建设的基本流程 1.建立灾难备份的专门机构 (1)分析灾难备份需求,制定灾难备份方案; (2)确定工程预算,监督工程实施; (3)明确各部分的职责,协调各部分的关系; (4)定期测试和评估灾难恢复计划; (5)对测试和评估的结果进行审核、存档并做出相应的改进。 2.分析灾难备份需求 (1)数据处理中心风险分析 (2)业务分析 (3)确定灾难恢复目标
9.2.2 灾难备份建设的基本流程 3.制定灾难备份方案 灾难备份方案可分为七个等级。 0级——无异地异地备份、1级——实现异地备份、 2级——热备份站点备份、3级——在线数据恢复、 4级——定时数据备份、 5级——实时数据备份、 6级——零数据丢失(详见表9.2)。 各业务系统灾难恢复目标,主要包括数据备份方案、备份处理 系统、灾难备份中心建设、规程与管理制度。 4.实施灾难备份方案 5.制定灾难恢复计划 6.保持灾难恢复计划持续可用
9.2.3银行业灾难备份系统的建设案例 1.我国银行业灾难备份系统的建设情况 (1)与发达国家相比,中国银行业的灾难备份建设起步较晚。但 鉴于银行业在国民经济中的重要地位和银行业务对数据实时性 的高要求,我国银行业对数据备份一直比较重视。 (2) “9.11”事件后,国内银行业经历了信息化基础建设及数据大集中阶段,开始积极着手灾难备份建设。目前,各大银行大都有数据级的备份措施,一些银行的备份数据能做到异地存放。根据各行数据集中进程的不同,灾难备份中心建设进展情况也有所差别。央行先行,各商业银行紧紧跟上。
2.建行总行资金清算灾难备份系统方案介绍 (1)建设背景: 资金清算系统是建行应用高科技电子化手段自行设计、自行开发 的人民币多边净额资金清算系统。它集汇划、对帐、查询查复、 监控、账务核算等多项功能于一体,汇划与清算同步进行,是建 行内部的资金枢纽,是资金流动的大动脉,而建行总行的资金清 算系统更是这个资金枢纽的核心,它的安全稳定运行是保障建行 核心业务顺利开展的关键。 ·为进一步增强中国建设银行总行资金清算系统抵御灾难的能力, 使该行清算业务在发生计算机系统灾难后能快速恢复,保证清算 业务的连续性,建行总行决定建设资金清算系统的灾难备份系统, 以使资金清算系统成为一个安全可靠的信息系统。
系统方案 (2)总体方案 系统由网络备份,远程数据备份,系统备份和应用数据检查与恢复部分组成. · HP9000/T600作为生产系统主机 · HP9000/T500作为灾难备份系统主机, ·采用EMC公司的智能存储系统的SRDF远程磁盘镜像技术作为数据备份技术 (3)网络设计方案:为了达到容灾备份的目的,建行总行在相距20公里的生产中心和备份中心各使用一台EMC Symmetrix 3430智能企业存储系统,两者间通过高速光纤连接,采用ATM和楼间VLAN技术,利用EMC的远程磁盘镜像技术SRDF来实现生产中心到备份中心数据的实时同步备份。
(4)远程数据备份 系统的主机、磁盘、通讯设备、通讯线路全部采用了硬件冗余。EMC设计的独特的容错结构,不但提供了最全面的数据保护,使得建行资金清算系统的业务连续性得以保证,并且充分满足了建行对资金清算系统高可靠性和清算业务数据安全性的高要求。 (5)系统备份 系统备份由两地的HP9000系列主机实现。
3.银联数据异地灾难备份架构设计 (1)发卡系统架构 ①主机系统 两台UNIX系统服务器通过两台SAN交换机与一台企业级存储服 务器相连,采用集中存储方式进行数据存储;存储服务器磁盘 采用RAID0+1方式;主机端通过多通道负载均衡软件实现两条 光纤通道的负载均衡,无单点故障。 ②网络系统 银联数据与客户机构之间采用两条广域网通信线路(1条为主 干线路,另一条为备份线路)进行连接。
(2)异地灾难备份架构设计 因银联数据发卡系统采用UNIX平台,故在建设异地灾难备份时 主要考虑“两地两中心”和“两地三中心”这两种模式。 “两地两中心”灾难备份 两地两中心”建设模式,就是在异地建立一个灾难备份中心。 异地灾难备份中心与生产中心数据实时复制,确保数据的一致 性和安全性。 “两地三中心”灾难备份 两地三中心”建设模式,即在异地建立一个灾难备份中心的基 础上,在同城建立一个备份中心。同城备份中心与生产中心数 据实时同步,异地灾难备份中心与同城备份中心数据实时复制. 当生产中心发生灾难时,因同城备份中心与生产中心是同步的, 数据不会丢失;当生产中心和同城备份中心同时发生灾难时, 由于异地数据复制有一定的延时,数据将有一定的丢失。