银行业集中备份平台方案建议书.docx

上传人:b****4 文档编号:5439957 上传时间:2022-12-16 格式:DOCX 页数:23 大小:1.01MB
下载 相关 举报
银行业集中备份平台方案建议书.docx_第1页
第1页 / 共23页
银行业集中备份平台方案建议书.docx_第2页
第2页 / 共23页
银行业集中备份平台方案建议书.docx_第3页
第3页 / 共23页
银行业集中备份平台方案建议书.docx_第4页
第4页 / 共23页
银行业集中备份平台方案建议书.docx_第5页
第5页 / 共23页
点击查看更多>>
下载资源
资源描述

银行业集中备份平台方案建议书.docx

《银行业集中备份平台方案建议书.docx》由会员分享,可在线阅读,更多相关《银行业集中备份平台方案建议书.docx(23页珍藏版)》请在冰豆网上搜索。

银行业集中备份平台方案建议书.docx

银行业集中备份平台方案建议书

银行业集中备份平台

方案建议书

一、集中备份平台建设背景

随着我行信息系统的不断发展,IT架构日趋复杂,全面提升系统灾难抵御能力和数据保护水平,是保障众多业务系统运行连续性的基础,也是满足监管部门数据备份要求。

特别是大数据时代的到来,我行数据呈几何式增长,数据占用空间越来越大,且分布在众多系统中,人工误操作风险也随之增大,对我行数据备份与管理提出了更高的运维要求,任何数据风险都将可能给我行带来重大经济损失。

因此如何有效管理金融核心数据日益成为保障我行业务安全平稳运行的关键环节,也是每个银行业重中之重工作。

据国外不完全统计,造成数据丢失的主要原因中,操作失误占80%,软硬件故障占5%,应用及其他原因占15%,可见人工操作失误对数据影响最大,是不能通过存储高可用基于块级别复制去消除,急需通过数据备份集中平台化策略去消除逻辑错误。

二、需求难点

综合考虑我行数据备份现状及监管要求,启动集中备份平台建设迫在眉睫。

主要体现在以下几方面:

1、部分重要的交易类和管理类系统现在尚未建立备份系统问题

我社目前现有外围交易类系统86个,外围管理类系统

45个,外围交易类系统现有备份分为两部分,一部分通过

TSM备份至DCS3700,另一部分通过TSM备份至NAS存储,备份数据通过NAS存储的复制技术实现容灾。

管理类仅部分数据通过TSM备份至NAS存储上,部分重要的交易类和管理类系统现在尚未建立备份系统。

其中,用于数据备份的重要存储NAS已不支持容量扩展,NAS存储的备份也不易做备份数据的容灾。

随着我社业务量的急剧增加,对数据备份的容量需求必然与日俱增,因此,对现有外围交易类与管理类备份系统进行改造迫在眉睫。

2、解决交易类数据缺少异地容灾备份、管理类数据缺少同城容灾备份的安全隐患,提升数据保障安全级别

近几年来,经过同城灾备建设、存储整合/升级/扩容等项目实施,我社已建立较完备的核心系统同城容灾与异地容灾架构,搭建3主机3存储的POWERHA高可用性核心系统平台,核心业务数据高度冗余保护(3份存储数据+2份备份数据)。

但部分重要的交易类和管理类系统现在尚未建立备份系统,已备份的数据也缺少同城和异地容灾备份,一旦生产中心所在城市出现重大灾难,部分交易类与管理类系统数据将丢失且很可能无法恢复,势必造成无可估量的经济损失和社会影响。

3、落实银监会的监管要求

根据《商业银行数据中心监管指引》文件要求,落实2015

年江西省银监局会议精神,省级农村信用联合社必须设立全面同城与异地模式灾备中心。

4、应对逻辑错误导致的数据及文件异常,提高数据保护级别

现有外围系统均采用基于SVC的存储级别镜像方式,后台数据存放于两台存储设备内,实现数据实时保护,但对于逻辑操作错误所造成的数据损坏情况无法应对。

进行数据定期备份保护,可解决系统运维中的逻辑错误,保障业务系统的数据安全。

三、备份平台选型

为做好平台选型工作,我行对企业级备份软件应用场景与效果进行了深入调研,初步确定三家主流商用备份软件

TSM、NBU、NetWorker,对其进行了详细对比,见表1。

 

序号

 

功能/需求

实现方式/满足情况

 

潜在影响

IBMTSM

SymantecNetBackup

EMCLegatoNetWorker

主机厂商备

第三方备份软

第三方备份软

份软件公

件厂商,其备份

件厂商,2003

司,同自己

产品包括低端

年被EMC收购

厂家的主机

BackupExec

后,运作没有起

和磁带库兼

和企业级的

到大公司的效

容性很好,

NetBackup,但

果,反而因为软

技术投入势必

1

公司状况

能提供一体

化解决方

专注数据备份

的NetBackup只

硬件共同由

销售负责,销售

会影响着其产

品扩展性与后

案。

随着主

是其中一小部

有重视硬件销

期维护

机投入,其

分,投入力量远

售忽略软件销

产品研发投

不及市场形象

售的趋势,导致

入也必然增

那么大

支持力度不够。

长。

远不及EMC公司

在存储行业名

气。

2

体系架构

自问世以来

自NBU6.0版模

采用扁平文件

体系架构直接

即采用关系

仿TSM采用

系统这一早已

决定了备份软

型数据记录

Sybase数据库

落后的索引记

件的稳定性、扩

索引,经过

作为索引数据

录方式,在性能

展性和性能

长时间众多

库,但由于之前

和管理粒度上

用户的检

产品架构的原

都存在缺陷

验。

单一的

因存在索引文

索引数据库

件和数据库之

模式保障索

间维护元数据

引信息的一

一致性的新问

致性

3

备份方式

支持永久增

不支持永久增

不支持永久增

永久增量备份

量备份

量备份,采用了

量备份方式,采

最大限度降低

折衷的合成备

用传统的全备+

了备份数据量、

份方式,需要定

增量循环方式

带宽占有和磁

期全备份

备份

带使用量,极其

适用于银行类

似影像系统这

样的大文件,大

数据量备份

4

用户权限管理

非常完善的

不支持

不支持

适用于大型IT

用户权限管

组织的运维管

理,支持各

理,在分工明确

种权限的用

的情况下,保证

户设定分

系统和数据安

配。

备份数

据访问控制

功能。

不同

应用和不同

客户端的备

份数据应具

备独立的访

问权限控

制。

5

存储容量管理

可灵活的在

不支持

不支持

灵活的迁移可

不同类型的

以帮助客户有

或新旧的设

效利用存储设

备介质间根

备特性提高备

据策略迁移

份和恢复的效

数据

6

介质管理

可实现基于

不支持

不支持

可节省存储成

策略的磁带自动回收,和同一应用磁带的自动并置,并实现离线磁带

的跟踪

本,加快恢复速度

7

安全管理

免费提供加

密功能

需购买额外的

加密模块

有限的机密功

最大程度保证

数据安全

8

策略管理

业界最为强大,灵活的策略管理功能,能满足客户所有备份策略的定制,可以定义基于文件级别的备份

策略

策略管理很难做到文件级别

以调度任务为级别设定备份策略

对于复杂的数据中心的备份系统,越细致的备份策略管理越能满足管理的需求

9

容灾管理

提供免费的

DRM模块实现数据容灾管理,自动化地定制容

灾计划

需额外的付费模块

需集成其他产品

以较低成本实现数据的容灾可以帮助客户更好地保护宝贵的数据

10

便利性

许可按照备份主要功能收费,提供跨平台的使用许可,与存储设备无关

使用许可分平台,须对存储设备收取许可费用,需要多个不同模块一起实现TSM的基本功能,软件许可有技术上的限制

使用许可分平台,须对存储设备收取许可费用,需要多个不同模块一起实现TSM的基本功能

方便的使用许可模式可使客户方便地进行扩容和变更,对于较大规模IT系统的客户来说可以减少频繁的变更带来的使用限制。

同时跨平台的使用许可也最大限度地降低了客户的成本保

护了投资

表1

综合表1对比分析,并结合我行主机、数据库分布现状及

将来的横向扩展与维护,我行采用IBMTSM集中备份一体化解决方案。

四、TSM架构

TivoliStorageManager(简称TSM)是IBM公司旗下的一款企业备份软件,支持lan、wan、lan-free等备份方式,也是业界主流数据备份产品之一,主要为大型企事业单位提供可靠的集中数据备份方案,在金融行业应用极为广泛。

同时作为数据资产的最后一道防线,我们更需要理解其逻辑架构,以更好的充分利用其数据备份平台保障数据安全。

TSM逻辑架构如图1、图2所示:

图2

在TSM的架构中,可分为三层:

策略层、存储层、调度层。

1.策略层

策略层主要包含策略域、策略集、管理类。

策略域是相同或相似节点数据保留需求的一个集合体,其下包含策略集。

其关系如图3:

9

策略集由一组管理类组成。

策略集被策略域包含。

只有当策略集被激活时,策略集包含的管理类才能起作用。

每个策略域中只能有一个策略集被激活。

▪每个策略集包含多个管理类,但只有一个作为默认管理类。

▪策略域包含多个策略集,但同时只有一个被激活。

▪策略集应用-首先需要校验(validation),然后激活(activation)。

图4

图4所示,管理类包含至少一个拷贝组,数据与管理类绑定。

除非显式指定数据与管理类的关系,否则数据将与默认管理类绑定。

可以通过将不同类型的数据与不同的管理类绑定来实现数据的分类备份。

图5

图5所示,每个管理类主要有两个拷贝组:

backupcopygroup、archivecopygroup。

拷贝组定义了数据存取的规则。

拷贝组的目标是存储池,真正存放数据的目的地。

多个拷贝组可共用一个存储池。

2.存储层

存储层定义了存储池和存储卷与物理带库及磁带、磁盘之间的对应关系,如图6所示:

图6

▪存储池由一组存储卷组成,每个存储池代表着一种类行的介质

▪存储池有两种主要类别的设备:

随机访问、顺序

10

11

访问

▪存储池是基于某个设备类,设备类定义了存放于存储池中的存储硬件类型

▪库通常是磁带库在系统的映射,库包括驱动器、机械手和磁带

▪驱动器包含在库中,负责磁带的读写。

驱动器的格式通常与设备类相关联

▪路径定义了如何访问驱动器与库的访问方式,把物理连接映射到逻辑连接上来

3.调度层

调度层在策略域中定义,主要包含定执行时间、执行命令以及执行频率等,分两种调度方式:

客户端调度(clientpolling)、服务端调度(server-promted),如图7所示:

图7

客户端调度如图8所示,客户端与服务器端通信,察看是否有为本地节点定义的调度及调度执行的时间。

如果发现有需要执行的调度,客户端则开始计时,进入执行调度倒计时。

如果没有调度需要执行,客户端则进入休眠状态,直到下次轮询时间。

▪如果发现有需要执行的调度,客户端则开始计

时,进入执行调度倒计时。

服务端调度如图9所示,客户端与服务器端联系,通知服务器,本地节点正在运行并可接受新的调度通知。

当服务器端检测到一个调度要准备运行,将通知客户端开始执行调度。

 

图9

这两种调度方式,TSM都支持,它们各有特色,客户端调度支持随机化,即对调度的开始时间的随机分布,造成TSM执行调度的开始时间常晚于定义时间。

由于TSM自动将任务做了随机化,对任务很多的客户机是有益的,有助于减少客户机的压力。

当然管理员也可以控制随机化,通过随机化时间,TSM避免了所有客户机同时尝试启动调度的概率,否则会耗尽服务器的资源。

服务端调度不支持调度的随机化,需要人工对负载进行判断,指定均衡的调度表,但如果经常更改调度的开始时间,服务端调度无需对客户机节点进行任何操作,只需更新服务端调度表,新的开始时间即可生效。

五、关键设计

结合前面章节的需求难点与TSM备份架构特点,本章主要讨论如何利用TSM进行集中备份方案设计,解决我行数据备份需求难点。

1.总体架构设计

新购一套中端存储V7000,作为备份存储,纳入到现有生产存储资源池(SVC)进行统一管理,将原备份至NAS的数据重新备份到V7000,同时新增备份需求部分也备份至

V7000。

为了实现备份数据的同城灾备,在同城灾备机房同步新购一套V7000,作为同城灾备的目标端,通过SVC的GlobalMirrorwithChangeVolume将生产备份数据通过裸光纤异步传输到同城的V7000存储。

2.备份策略设计

通过上述章节TSM逻辑架构图简述,我们对策略层与存储层有个初步了解,备份策略可结合这两个层面,进行详细设计,一是基于业务需求、备份窗口进行设计,例交易类系统白天业务繁忙,为减少生产影响,可放入晚上凌晨进行增量备份,周末进行全备;管理类系统或者非核心24小时业务系统,可权衡放在晚上下班时间点,以错开备份过于集中。

二是基于备份数据容量进行设计,对那些海量数据,通过

lanfree备份的系统,需要考虑物理磁带库,驱动器的个数,以免发生驱动器抢占造成数据备份失败。

三是基于特殊节点特殊需求进行设计,比如信贷系统每天备份保留一周,月初、季度末、年初备份需永久保留,这就需要设置不同的节点,节点分属不同的策略域,或者使用同一个节点,构建多个管理类,通过dsm.sys文件中管理类映射来实现。

根据我行实践,考虑到备份数据存放时间和版本控制。

备份数据存放时间上,采用了永久备份、年备份、半年备份、一周备份、三份备份、八份备份等相结合的方式。

版本控制上,通常数据库备份保存2份全备、7份增备,操作系统备份保存三份备份和重大变更前的一次备份,应用日志备份通常保留两个版本,大型管理类系统备份上保留2个版本等。

3.文件系统备份设计

通过TSMBA接口进行文件系统备份,主要实现了操作系统、数据库日志、应用日志和数据库表数据的备份。

操作系统备份:

对于AIX系统,由于TSM就是主机厂商生产的,兼容结合性已经很好,可通过TSM的Sysback进行在线备份,不需要停机或者停止应用程序,保证应用的高可用性,通过NIM环境实现在线恢复。

对于linux、windows物理机,可采用系统工具生成类似windows的ghost文件,然后基于TSMBA接口进行文件备份。

我行由于x86平台基本完成了虚拟化,因此linux、windows系统都是基于虚机备份,详见下述章节。

数据库日志、应用日志备份:

编写shell脚本定时对日志进行归档,然后通过tsmba对归档的文件系统进行增量备份,保留两个版本。

数据库表备份:

由于TSM基于库级进行备份,因此对表的备份需要编写shell脚本,将数据库表导出成文件,然后通过TSMBA进行文件增量备份,根据应用需要,制定备份策略时间。

4.数据库备份设计

根据数据库容量与性能,我行采用了多种备份方式。

一是对于数据量小于2T的数据库,利用TSMAPI接口调用数

据库接口实现数据库的全量与增量定时备份,例如DB2数据库备份,需要开启归档日志,第一次开启需进行离线全备,然后调用DB2备份接口进行备份;oracle数据库,也要开启归档,调用oraclerman接口进行备份。

二是对于管理类大型分析型数据库,调用SVC接口实现块级数据flash快照。

三是对于交易类中型在线联机型数据库的批前和批后备份,采用了存储快照与数据库API接口相结合的方式进行备份,通过瞬时的存储快照,并挂载至专用的备份客户端,通过TSM调用数据库API进行备份,以充分降低数据性能影响。

如信贷系统。

5.虚拟机备份设计

由于power平台的虚拟化都是AIX系统,TSM已经和AIX在线备份无缝衔接,因此我行对power平台虚机未采用Hyper-V接口进行备份,对于VMware虚机备份,通过Tsmforve实现,支持esx下虚拟机的备份。

Tsmforve是基于VADP技术实现,执行文件级别备份。

如图10所示:

6.lan-free备份设计

图10

由于大数据平台Netezza数据库,数据量近180T,压缩后近45T,可通过TSM实现在线备份,每两周一个全备,每天增备,全备保留1个版本,增备保留15个版本。

lan-free

设计如图11所示:

图11

Lan-free一般需经过以下6个步骤:

1.Backup-ArchiveClient开始一个备份操作.TivoliStorageManagerserver报告策略信息给client。

2.StorageAgent接收由client传送的要备份的文件数据,根据策略设置作相应分配,然后,StorageAgent发送一个volumemount请求给LibraryManagerserver.

3.从LibraryManager发送一个请求到storagedevice,要求mount相应的media.

4.LibraryManager通知StorageAgent,mountedmedia所在的具体位置。

5.client通过StorageAgent,把备份数据直接通过SAN方式写到目标设备上。

6.StorageAgent发送元数据(metadata)信息给TivoliStorageManagerserver通过

六、备份实践经验分享

1.如何配置一个新节点

在TSM使用过程中,随着新系统陆续上线,使用最多的功能,是配置一个新节点,如图12所示:

图12

配置一个新节点需要经过以下流程:

定义策略域—定义管理类副本组—校验策略域—激活策略—配置dsm.opt节点文件—注册节点---关联策略域—定义调度—关联调度

1.定义策略域,也可copy现有的策略域:

definedomaintmppdbackretention=30archretention=365

2.定义策略集:

definepolicysettmppdtmpply

3.定义管理类:

definemgmtclasstmppdtmpplytmpmgtspacemgtechnique=noneautomignonuse=0migrequiresbkup=yes

4.定义管理类拷贝组:

definetmppdtmpplytmpmgtdestination=diskpoolfrequency=0verexists=2verdeleted=1retextra=30

retonly=60

definecopygrouptmppdtmpplytmpmgttype=archivedestination=diskpoolretver=365retinit=creationserialization=shrstatic

5.设置默认管理类:

assigndefmgmtclasstmppdtmpplytmpmgt

6.验证策略有效性:

validatepolicysettmppdtmpply

7.激活策略:

activepolicysettmppdtmpply

8.删除默认管理类:

deletedomainstandard

9.关联策略域:

registernodedb2db1tsmdomain=tmppdcompression=clientbackdelete=yes

10.定义调度,也可拷贝现有的调度:

copyschetmppd

tmpschetmppdtmp2sche

11.关联调度:

defassoctmppddb2db1tmp2sche

2.如何诊断故障

要使用好TSM,就必须知道如何诊断故障及快速解决。

根据我个人使用建议,排查故障一般可分三步曲,第一步分析备份错误日志,第二步根据日志的错误代码查看故障代码含义,然后找出故障原因。

第三步根据日志表述无法定位故障,查看数据库日志以确定故障症结。

一般可通过qevent**查看备份情况,对备份失败的节点,登录客户端进行日志查看,以准确排错。

客户端TSM备份日志一般存放在dsm.sys对应的调度内容上指定的目录中,名称一般是dsmerror.log,调度错误的日志一般是dsmsched.log。

根据错误日志的返回代码,可查看TSM的故障代码表,一般存放在安装目录下

(/usr/tivoli/tsm/client/api/bin64/sample)的

dsmrc.h文件中。

格式如下:

#defineDSM_RC_USER_ABORT

101/*processingabortedbyuser

*/

#defineDSM_RC_NO_MEMORY

102/*noRAMlefttocompleterequest

*/

#defineDSM_RC_TA_COMM_DOWN

2021/*nolongerused

*/

#defineDSM_RC_FILE_NOT_FOUND

104/*specifiedfilenotfound

对那些日志日志表述无法直接定位问题,首先确定是否是网络故障、调度冲突或者系统进行了切换,然后判断备份目录权限是否修改过,最后查看数据库备份日志,例如DB2可通过命令db2diag查看具体时间点数据库是否有报错等等。

3.如何通过数据库表生成统计报表

TSM所有备份信息都记录在DB2数据库中,在字符界面通过q形式的查询,在数据库中都有对应的表,因此要掌握

TSM,TSM数据库必须熟悉。

这样可以方便生成一些备份统计报表,便于领导决策及数据存储扩容。

比如需要统计每个备份节点数据备份容量、备份脚本、备份时间、策略域等,如图13所示:

可通过以下sql语句实现:

 

图13

4.代理节点的妙用

TSM中有两种节点类型,普通节点node与代理节点proxy

node,他们之间关系是怎样的呢?

下面通过一个例子来讲述:

例如网银数据库有两台服务器通过

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 解决方案 > 学习计划

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1