银行灾备方案.docx

银行灾备方案.docx

《银行灾备方案.docx》由会员分享，可在线阅读，更多相关《银行灾备方案.docx（34页珍藏版）》请在冰豆网上搜索。

银行灾备方案

银行灾备方案

云存储项目

大数据平台解决方案

1概述

1.1建设背景

随着银行数据集中处理的实施，银行业务运作、经营管理将越来越依赖于计算机网络系统的可靠运行。

银行所提供金融服务的连续性以及业务数据的完整性、正确性、有效性，会直接关系到银行的生产、经营与决策活动。

一旦因自然灾害、设备故障或人为因素等原因引起计算机网络系统停顿导致信息数据丢失和业务处理中断，将会给银行造成巨大的经济损失和声誉损害，受到致命的打击。

生产运行系统的灾难备份系统就显得格外重要。

我们认为，一旦实施银行数据集中，灾难备份系统应该与生产运行应用系统同步投入使用，保证银行数据集中处理系统的运行安全。

1.2设计范围

本技术解决方案针对海量数据集中存储与共享，提供从系统软硬件技术架构、原理、硬件选型、网络接入以及软件与应用之间的接口等方面的全面设计阐述。

1.3总体设计原则

针对本次工程的实际情况,充分考虑系统建设的建设发展需求，以实现系统统一管理、高效应用、平滑扩展为目标，以“先进、安全、成熟、开放、经济”为总体设计原则。

1.3.1先进性原则

在系统总体方案设计时采用业界先进的方案和技术，以确保一定时间内不落后。

选择实用性强产品，模块化结构设计，既可满足当前的需要又可实现今后系统发展平滑扩展。

1.3.2安全性原则

数据是业务系统核心应用的最终保障，不但要保证整套系统能够7X24运行，而且存储系统必须有高可用性，以保证应用系统对数据的随时存取。

同时配置安全的备份系统，对应用数据进行更加安全的数据保护，降低人为操作失误或病毒袭击给系统造成的数据丢失。

在进行系统设计时，充分考虑数据高可靠存储，采用高度可靠的软硬件容错设计，进行有效的安全访问控制，实现故障屏蔽、自动冗余重建等智能化安全可靠措施，提供统一的系统管理和监控平台，进行有效的故障定位、预警。

1.3.3成熟性原则

为确保整个系统能够稳定工作，软件平台将使用先进、完善、易于管理和稳定可靠的云存储资源管理系统，对于与应用的集成接口，提供统一的通用稳定访问接口。

1.3.4开放性原则

系统建设具有开放性的标准体系，提供符合POSIX标准的通用文件系统访问接口，开放的应用API编程接口，提供人性化的应用和管理界面，以满足用户需求。

遵循规范的通用接口标准，使全系统中的硬件、通信、软件、操作平台之间的互联共享。

充分考虑系统的升级和维护问题，维护采用在线式的，即在系统不停止工作的情况下，能够更换单元备件。

系统的维护和升级操作由系统管理员即可完成。

1.3.5经济性原则

现有业务系统存储数据量较大，且数据的增长速度较快。

因此在建设系统存储架构时，应从长远的角度考虑，建设一个长期的存储架构，除了能够应对存储硬件设备的升级速度外，还必须考虑到对前期存储设备的投资保护，在保证不断提供功能和性能提高的同时，存储架构在较长的时间内能够保持相对稳定。

结合先进的云平台技术架构优势，根据本次项目建设的实际容量需求设计，同时充分考虑应用发展需求，实现系统可弹性在线平滑升级。

经过软件实现在较廉价普通服务器上实现高度容错，同时能够在较低冗余度的情况下实现高度可靠容错，大大节约和降低系统建设的硬件成本。

1.41项目建设目标

建立灾难备份中心的目的是：

以最合理的代价保护应用数据的完整性与安全性，在灾难发生后尽快恢复运行，减少业务停顿时间，尽可能不中断或不影响业务的正常进行，使灾难造成的损失降到最小。

即不论两个系统相离多远，当一个数据中心出现问题时，另一个数据中心就应能迅速接替运行，既要保证业务数据的完整性，又要保证关键业务的连续性。

随着商业银行的业务发展及竞争的日益加剧，国外商业银行又提出了业务连续性的要求。

这种要求的产生背景是：

（1）商业银行承诺向客户提供“3A”服务（即任何时间Anytime，任何地点Anywhere，任何方式Anyways）。

由于家庭银行、企业银行、网络银行、电话银行、ATM/POS等电子银行的出现，客户不受银行终端用户的上下班时间及位置的限制，享受银行提供的金融服务。

（2）随着银行金融服务和金融市场的拓展，商业银行比较注重银行间相互联网。

这样，当客户外出时，无需携带大量现金，也无需在当地银行、外币找换店及酒店兑换外币，可直接在当地自助设备上提取当地货币，还可办理各种存取款、转帐、申请结单或支票等业务，既节省时间，又极大方便了客户。

要求银行服务具有连续性。

（３）在开放的金融市场环境下，为适应市场需求，发达国家的商业银行从注重规模效益转为重视深度效益。

注重客户关系及客户价值是变革的关键，而深度效益的内涵是对详细客户信息和市场信息的组织和分析，利用数据仓库（DATAWAREHOUSE）、数据采掘（DATAMINING）技术从业务数据中提取可供辅助决策用的信息。

数据仓库是将银行各自分散的原始数据（如主机中的帐务数据）汇集和整理成为单一的管理信息数据库、客户信息数据库，面向专题和时间组织数据，并对数据进行集成。

使用数据采掘技术从数据仓库中提取隐藏的预测性信息，为银行提供完整、及时、准确的商业决策信息，为银行经营决策人员提供辅助决策支持。

它要求原始数据具有实时性、连续可用性，并具有较好的完整性与长时间延续性。

保持业务的连续性要求灾难恢复系统实现更高的目标：

除了以最合理的代价保护应用数据的完整性与安全性，在灾难发生后尽快恢复运行，减少或尽可能消除业务停顿时间外，还应做到：

（1）保证业务的连续性与延续性，即保证业务数据的连续性，为银行的决策支持系统提供连续完整的基本数据；

（2）缩小或取消应用系统用于批处理和数据备份（如磁带备份）的时间，保证关键业务服务24小时不中断，使应用系统的服务时间达到7X24，满足银行互联及客户的需求；

2云存储系统平台设计

2

2.1项目需求

2.1.1灾难类型需求

常见的银行灾难主要包括以下几个方面：

（1）自然灾害：

造成计算机灾难的自然灾害有：

火灾、水灾、雷击、台风、地震、鼠害等。

根据有关资料，XXXX地区发生毁坏性地震的可能性不大，而且，现有生产运行中心所在地--XXXX大厦，在修建时作了抗7级以下地震的设计。

XXXX地区附近无大江大河，不会出现洪涝。

因此对我们生产运行系统来讲，自然灾害主要是指水灾、火灾、雷击和鼠害。

（2）计算机系统故障：

引起计算机系统故障的因素有下述几点：

a.主机系统故障：

　主要指：

数据库系统故障、系统软件故障、硬盘损坏、网卡故障、电源故障、应用系统缺陷、其它故障

b.主机房故障：

主要指：

主机房电源故障、主机房通讯故障、主机房水灾、主机房火灾、主机房鼠害

c.整幢楼房故障：

主要指：

整幢楼房电源故障、整幢楼房火灾或水灾、整幢楼房其它灾害

（４）人为因素：

由于应用系统缺陷、误操作、人为蓄意破坏、外来暴力事件等都将直接影响系统的安全运行。

。

2.1.2吞吐量需求

为满足多用户或应用整体吞吐带宽需要，确保数据访问流畅，系统需提供多用户或应用并发访问高吞吐带宽设计，系统能够有效利用网络带宽，性能可经过规模增加实现平滑增长。

2.1.3扩展性需求

未来根据业务应用的变化和发展，需要快速实施系统资源的升级，能够在业务服务不间断的状态下平滑扩展，不会导致架构发生根本性变化，为不断产生和变化的业务需求提供持续的支持，支持业务系统的快速整合和部署对核心系统基础架构的特别要求。

2.1.4低成本需求

要求系统能够以低硬件成本、低维护成本实现高可靠高性能应用要求，充分提高资源利用率，简化管理，并能灵活、可持续扩展。

2.1.5可维护性需求

要求系统具有自适应管理能力，安装、维护、升级简易方便，提供统一易用的WEB配置管理监控平台，实现智能化管理。

2.1.6接口需求

要求能够提供通用的文件系统接口，方便用户及应用系统访问，减少与应用集成或开发工作量，实现系统快速部署与集成。

2.2设计思想

采用业界成熟先进的云平台架构思想，采用软件实现对大量普通商用服务器存储空间资源进行虚拟化整合，实现软硬件故障高度容错，将系统控制流与数据流分离，同时使得数据在逻辑上集中、物理上分散，每台服务器同时对外提供服务，以达到多并发高吞吐量的性能要求，采用自注册机制、故障自动屏蔽、自动冗余重建技术实现系统自我维护和平滑扩展，系统服务7×24小时不间断。

系统采用先进的编解码容错技术，可根据数据可靠性要求设置适当的冗余编解码策略进行系统部署，能够以极小的磁盘和硬件冗余度，实现高度的可靠性数据容错。

2.3云存储系统方案

采用业界已经成熟的cStor云存储资源管理系统，在多台普通商用服务器上构建高性能高可靠云存储系统，作为本次系统云数据中心存储平台，其应用部署示意图如下图所示。

cStor云存储资源管理系统部署示意图

2.4系统优势和特点

cStor云存储系统是一套软件与硬件相结合的系统，其中专有技术和软件是高附加值部分，能够广泛应用于需要存储大量数据的应用场合（如安防、广电、电信、互联网、银行等领域）。

该系统相比传统存储系统有如下技术优势：

2.4.1高度可靠

存储系统采用云架构，数据被分块存储在不同的存储节点上，数据采用先进的1:

1容错机制进行容错，可在任意损坏一个存储服务器节点的情况下实现数据完整可靠，系统对外存储访问服务不间断。

云存储的管理节点采用了主备双机镜像热备的高可用机制，在主管理节点出现故障时，备管理节点自动接替主管理节点的工作，成为新的主管理节点，待故障节点修复并重启服务后，它则成为新的备管理节点，保障系统的7×24小时不间断服务。

2.4.2优异性能

cStor采用控制流与数据流分离的技术，数据的存储或读取实际上是与各个存储节点上并行读写，这样随着存储节点数目的增多，整个系统的吞吐量和IO性能将呈线性增长。

同时，cStor采用负载均衡技术，自动均衡各服务器负载，使得各存储节点的性能调节到最高，实现资源优化配置。

2.4.3无限容量

系统容量仅受限于卷管理服务器内存，可支撑的容量接近无限，经推算，理论容量为1024×1024×1024PB（1G个PB容量）。

2.4.4在线伸缩

cStor云存储资源管理系统扩容非常方便，支持不停止服务的情况下，动态加入新的存储节点，无需任何操作，即实现扩容；同时，无需人为干预，也能够摘下任意节点，系统自动缩小规模而不丢失数据，存储在此节点上的数据将会重新备份到其它节点上。

2.4.5通用易用

cStor云存储系统提供符合POSIX标准的通用文件系统接口，无论是哪种操作系统下的应用程序，都能够不经修改将云存储当成自己的海量磁盘来使用。

同时，也提供专用的API接口，供开发人员调用。

2.4.6智能管理

提供基于WEB的管理控制平台，所有的管理工作均由cStor管理模块自动完成，使用人员无需任何专业知识便能够轻松管理整个系统。

经过管理平台，能够对cStor中的所有节点实行实时监控，用户经过监控界面能够清楚地了解到每一个节点和磁盘的运行情况；同时也能够实现对文件级别的系统监控，支持损坏文件的查找和修复功能。

系统提供用户安全认证及对不同用户进行配额设置与权限管理功能，满足应用的日常维护和安全管理需求。

3系统架构

在本次系统建设中，云存储系统属于基础平台支撑层，以用于数据集中存储和共享，实现对数据的统一管理和高效应用。

将数据逻辑集中物理分散，以提供多并发高吞吐带宽，最大程度降低系统访问瓶颈。

下面具体说明cStor云存储资源管理系统的基本组成和主要功能。

3

3.1系统基本组成

cStor云存储资源管理系统采用分布式的存储机制，将数据分散存储在多台独立的存储服务器上。

它采用包括卷管理服务器、元数据管理服务器（MasterServer）、数据存储节点服务器（ChunkServer）和挂接访问客户端以及管理监控中心服务器的结构构成虚拟统一的海量存储空间。

在每个服务器节点上运行cStor云存储资源管理系统的相应的软件服务程序模块。

系统架构框图如下图所示。

cStor云存储资源管理系统架构

其中，MasterServer保存系统的元数据，负责对整个文件系统的管理，MasterServer在逻辑上只有一个，但采用主备双机镜像的方式，保证系统的不间断服务；ChunkServer负责具体的数据存储工作，数据以文件的形式存储在ChunkServer上，ChunkServer的个数能够有多个，它的数目直接决定了cStor云存储系统的规模；挂接访问客户端即为服务器对外提供数据存储和访问服务的窗口，一般情况下，客户端能够部署在ChunkServer上，每一个块数据服务器，既能够作为存储服务器同时也能够作为客户端服务器。

由一对元数据服务器及其管理的存储服务器节点所提供的存储空间称为一个卷空间，不同的卷空间由卷管理服务器虚拟化统一管理，对外可提供统一的海量存储空间。

管理监控中心提供统一易用的WEB配置管理监控平台，提供设备监控、空间监控、文件监控、服务监控、用户认证管理、配额管理、故障告警及预警等功能，实现智能化管理。

这种分布式系统最大的好处是有利于存储系统的扩展和实现，在小规模的数据扩展时，只需要添加具体的ChunkServer即可，而不需要添加整套设备。

在实现大规模扩展时也可方便地添加整个卷设备。

3.2系统功能描述

cStor云存储资源管理系统从功能上划份为三大部分：

1）cStor分布式文件系统

分布式文件系统实现文件数据存储、可靠性容错、可伸缩性保证、高可用保证、负载均衡和流量分担等功能。

2）存储访问接口

cStor提供符合POSIX规范的文件系统访问接口，经过cStor访问挂接程序可将云存储空间挂接为本地目录或磁盘。

同时可提供专用的API接口，支持业务应用层程序对云存储系统的直接访问。

3）管理监控中心

管理监控中心提供帐户管理、设备管理、系统监控、卷管理、告警管理、故障管理等功能。

下面逐一详细介绍各部分系统功能。

3.2.1cStor分布式文件系统

cStor分布式文件系统包括卷管理、元数据管理、块数据管理服务。

参考上面系统架构框图左侧部分。

元数据是指文件的名称、属性、数据块位置信息等，元数据管理经过元数据服务程序完成。

因元数据访问频繁，故系统将元数据加载缓存至内存中管理，提高访问效率。

由于元数据的重要性，元数据损坏或丢失则相当于文件数据丢失，因此实现了元数据服务器主备双机高可用，确保７×２４小时不间断服务。

经过元数据远程多机冗余备份功能，实现在多台其它机器上备份元数据，当元数据服务器损坏，能够经过备份的元数据重新恢复服务，切保数据能够完整找回。

块数据是指文件数据被按照一定大小（默认64MB）分割而成的多个数据块，分布存储到不同的存储节点服务器上，并经过编解码容错算法产生相应的冗余块。

块数据服务是运行在每个存储节点服务器上的块数据管理程序，负责使用存储服务器上的磁盘空间存储文件数据块，并实现相应的编解码功能。

相比较传统业界的云存储采用块数据简单备份冗余容错机制，编解码容错方式大大降低了硬件资源冗余度，提高了磁盘利用率。

由一对主备元数据服务器及其所管理的块数据服务器管理节点设备及其所提供的存储空间称为一个卷。

卷管理服务器负责将多个卷虚拟化整合，对外提供统一的整体访问云存储空间。

文件系统采用中心服务器模式分布式存储架构，控制流与数据流分离，经过增加存储节点

系统采用自动注册机制，实现系统高可伸缩性，增加或减少存储节点规模，不影响系统正常提供存储访问服务。

该系统架构实现了统一调度，负载均衡和流量自动分担功能，多个存储节点同时对外提供数据流服务，系统根据磁盘空间使用比例进行资源优化配置。

同时在多个不同的存储节点之间实现根据空间比例进行优化配置，数据优先存储的空间利用比例相对较低的磁盘或存储服务器上。

cStor分布式文件系统具有自动冗余重建功能，确保损坏的数据块能够被解码或编码后存储到在线的正常的存储服务器节点上。

3.2.2存储访问接口

cStor分布式文件系统提供符合POSIX规范的文件系统访问接口。

支持Linux、Windows、MaxOSX等操作系统平台。

可将云存储系统提供的存储空间挂接为本地目录或本地盘符来使用。

用户操作云存储空间和操作本地文件相同。

另外cStor提供专用的高速存取访问API接口，供性能要求很高的高端应用程序对接使用。

3.2.3管理监控中心

管理监控中心为系统管理员配置和维护cStor云存储资源管理系统的有效工具，充分体现了系统的可维护性。

管理监控中心提供帐户管理、设备管理、系统监控、卷管理、告警管理、故障管理等功能。

以下为部分系统管理界面。

●设备管理

●系统监控

●告警信息

●告警配置

●告警日志

●故障处理

●卷管理

●帐户管理

●添加帐户

4系统安全性设计

4

4.1安全保障体系框架

NSA提出的信息安全保障技术框架（IATF），如下图所示。

IATF依据“深度防护战略”理论，要求从整体、过程的角度看待信息安全问题，强调人、技术、操作这三个核心原则，关注四个层次的安全保障：

保护网络和基础设施、保护边界、保护计算环境、支撑基础设施。

图表基于深度防护战略的IATF模型

IATF模型从深度防护战略出发，强调人、技术和操作三个要素：

人：

人是信息的主体，是信息系统的拥有者、管理者和使用者，是信息保障体系的核心，是第一位的要素，同时也是最脆弱的。

正是基于这样的认识，安全组织和安全管理在安全保障体系中是第一位的，要建设信息安全保障体系，首先必须建立安全组织和安全管理，包括组织管理、技术管理和操作管理等多个方面。

技术：

技术是实现信息安全保障的重要手段，信息安全保障体系所应具备的各项安全服务就是经过技术机制来实现的。

当然IATF所指的技术是防护、检测、响应、恢复并重的、动态的技术体系。

操作：

也可称之“运行”，它体现了安全保障体系的主动防御，如果说技术的构成是被动的，那操作和流程就是将各方面技术紧密结合在一起的主动过程，运行保障至少包括安全评估、入侵检测、安全审计、安全监控、响应恢复等内容。

信息安全保障体系的实现就是经过建立安全组织、安全管理和防护技术体系，协调组织、技术、运作三者之间的关系，明确技术实施和安全操作中技术人员的安全职责，从网络和基础设施、区域边界、计算环境、支撑基础设施等多层次保护，从而达到对安全风险的及时发现和有效控制，提高安全问题发生时的反应速度和恢复能力，增强网络与信息的整体安全保障能力。

对于云计算安全参考模型，云安全联盟CSA（CloudSecurityAlliance）提出了基于3种基本云服务的层次性及其依赖关系的安全参考模型,并实现了从云服务模型到安全控制模型的映射。

该模型显示PaaS位于IaaS之上,SaaS位于PaaS之上。

该模型的重要特点是供应商所在的等级越低,云服务用户所要承担的安全能力和管理职责就越多。

根据资源或服务的管理权、所有权和资源物理位置的不同,CSA也给出了不同的云部署模型的可能实现方式及其不同部署模式下共享云服务的消费者之间的信任关系,如下图所示。

图表云部署模型的实现

此图显示,对于私有云和社区云,有多种实现方式,能够和公共云一样,由第三方拥有和管理并提供场外服务（off-premises）,所不同的是共享云服务的消费者群体之间具有信任关系,局限于组织内部和可信任的群体之间。

对于每一种云部署实现方式,都能够提供3种基本的云服务。

云部署实现的不同方式和基本云服务的组合构成不同的云服务消费模式。

结合云服务安全参考模型,能够确定不同的云服务消费模式下供应商和用户的安全控制范围和责任,用户评估和比较不同云服务消费模式的风险及现有安全控制与要求的安全控制之间的差距,做出合理的决策。

4.2云计算平台的多级信任保护

云计算可信平台实现系统平台（计算环境）认证、应用系统完整性认证、分布式资源信任认证和用户身份认证4个层次。

多层信任保护的具体结构如下图所示。

图表多级信任保护

在上图中，平台认证是基础，为其它3种认证提供一个可靠的计算环境。

平台认证、应用认证、资源认证和用户认证都经过统一的证书机制来实现。

（1）云平台信任保护

由于TPM（trustplatformmodule）规范能够支持现有的公钥基础设施，而且TPM内部的认证密钥和64位物理唯一序列号都能很好地实现自身和平台的绑定。

因此可信平台之间的信任关系能够借助基于可信第三方的证书机制来保障。

即每一个节点将能够代表自身特征的关键信息以可靠地方式提交到可信第三方（如CA中心），可信第三方在核实这些数据的真实性和完整性后对其签名，并为其颁发一个平台证书。

此后，该平台在和其它平台通信时能够出示该证书，以表明自己的合法身份。

平台在向可信第三方提交平台信息和验证其它平台证书合法性时，都需要借助TPM的硬件支持。

在下图所示的实例中，云平台A和B都从证书颁发中心获得自己的平台证书。

当B请求与A建立连接并向A出示自己的证书后，A借助TPM验证B出示的证书的有效性。

图表基于可信第三方的平台认证

为了确保云端用户访问云平台的可信性，并确保远程节点具有期望的完全保障条件，基于可信计算平台的多级信任保护方法构造包含下表中各种主要因素的平台证书。

数据名称

数据类型

数据说明

Cert_Num

Char

证书编号

Cert_Type

Short

证书类型

Cert_DistributeTime

Byte[20]

颁发时间

Cert_LimitTime

Byte[20]

有效期限

TPM_ID

Byte[8]

TPM序列号

Hardware_Code

Byte[20]

平台硬件标识

Software_Code

Byte[20]

平台软件标识

SecureComponent_Code

Byte[20]

安全组织组件标识

…

…

…

CA_Signature

Byte[128]

CA签名信息

图表主要因素平台证书

在图中，TPM和端系统唯一绑定；硬件标识码代表了端系统中各种硬件设备的完整性信息，包括CPU序列号、主板型号、硬盘序列号、内存容量等；软件标识码代表了端系统中包含操作系统版本、补丁、主要服务等软件完整性信息；安全组件标识码是各种安全组件的完整性度量结果，包括防火墙类型、安全补丁、防病毒软件名称等。

为了获取这些数据的完整性度量结果，采用Hash函数对系统中的硬件标识信息、软件版本信息或安全组件描述信息进行计算，得出一个代表该系统相关信息完整性的度量值。

此处，选择SHA-1算法作为完整性度量函数。

签名信息是可信第三方对证书内容的数字签名，签名信息的存在确保了证书的合法性和不可篡改性。

（2）应用信任保护

有了云平台认证，用户就能断言远程协作者在确定的节点和环境中进行工作。

但在网络计算等复杂应用中，一个节点可能承载了多个应用系统、担负着多个计算任务。

因此，需要确保单个应用系统不同部分间（如客户端和服务器端）的可信。

Seshadri等人研究了代码的远程完整性验证方法。

该方法从数据完整性的角度解决了授权执行的远程应用的可信性。

借鉴她的思想，采用认证应用系统中进程完整性的办法对应用系统进行信任保护。

即端系统控制各个应用的进程，只有经过完整性认证并授权执行的进程才能被启动。

为此，系统为每个重要的分布式应用定义若干个进行完整性证书，证书的主要内容如下表所示。

数据名称

数据类型

数据说明

……

……

……

Process_ID

Byte[20]

进程ID

Process_Integrity

Byte[20]

完整性度量值

……

……

……

TPM_S