城商行基于VPLEX+RecoveryPoint的存储灾备方案
商业银行容灾系统建设方案
Ｗ ＡＮ Ｇ Ｇａ ｎ ｇ
（ Ｔ ｈ ｅ ｐ ｏ ｓ ｔ ａ ｌ ｂ ｕ ｒ ｅ ａ ｕ ｏ ｆ ｈ ａ ｎ ｚ ｈ ｏ ｎ ｇ ， ｓ ｈ ａ ｎ ｎ ｘ ｉ ｔ ｈ ｅ ｂ ｕ ｒ ｅ ａ ｕ ｏ ｆ Ｉ ｎ ｆ ｏ ｒ ｍａ ｔ ｉ ｏ ｎ ｔ ｅ ｃ ｈ ｎ ｏ ｌ ｏ ｇ ｙ ， Ｈ ａ ｎ ｚ ｈ ｏ ｎ ｇ ７ ２ ３ ０ ０ ０ ， Ｃ ｈ ｉ ｎ ａ ）
计 算 机 系 统 应 用
ｈ ｔ ｔ ｐ ： ｌ ｌ ￣ ｗ ． ｃ － Ｓ ・ ａ ． ｏ ｒ ｇ ． ｃ ｎ
２ ０ １ ３年 第 ２ ２卷 第 １ １期
商业 银行 容 灾系统建 设 方案①
王 刚
（ 陕西省汉 中市 邮政局 信息技术局，汉 中 ７ ２ ３ 对容灾中心 的定位描述，容灾系统不仅具有基本 的容灾功能，而且是连接 生产核心系统与
前 容灾中心所采 用的技术 方案主要有 两类，即基 于存
辅助 系统的桥梁．因此，建设容灾 系统具有 十分重要的现实意义．鉴于容灾系统建设是一个涉及 面广、专业性 强 的系统工程， 本 文对 容灾系统建 设的总体原则和思路进行 了研究，探讨各种容灾可用 技术，并进 行分析对 比，提 出了系统构架，对商业银行容灾系统 的建设具有参考价值． 关键 词： 商业银行；容灾系统；总体原则；系统构架；建设方案
ｄｉ ｓ ａ ｓ ｔ ｅ ｒ ｒ ｅ ｃ ｏｖ ｅ ｒ ｓ ｙｓ ｔ ｅ ｍ ｃ ｏ ｎ ｓ ｒｕ ｔ ｃ ｔ ｉ ｏ ｎ ．
Ｋｅ ｙ ｗｏｒ ｄ ｓ ： ｃ ｏ ｍｍｅ ｒ ｃ ｉ ａ ｌ ｂ ｎｋ ａ ； ｄ ｉ ｓ ａ ｓ ｔ ｅ ｒ ｒ ｅ ｃ ｏ ｖ ｅ ｒ ｓ ｙｓ ｔ ｅ ｍ； ｇ ｅ ｎ ｅ ｒ ａ ｌ ｐ ｒ ｉ ｎ ｃ ｉ ｐ ｌ ｅ ； ｓ ｙｓ ｔ ｅ ｍ ｒｃ ａ ｈ ｉ ｔ ｅ ｃ ｔ ｕ ｒ ｅ ； ｃ ｏ ｎ ｓ ｔ ｒ ｕ ｃ ｔ ｉ ｏ ｎ ｐ ｌ ａ ｎ
城商行核心业务系统存储跨中心双活建设方案
城商行核心业务系统存储跨中心双活建设方案随着互联网金融的快速发展，金融企业数据中心建设面临着新的挑战，那就是对RTO和RPO的极限追求，从而也就诞生了近年来的热点话题——双活数据中心建设，其作为灾备方案中高级别的解决方案，逐渐成为了应对传统灾备难题的一把利剑。
它能够解决传统的灾备方案中资源利用率低、可用性差、出现故障时停机时间长、数据恢复慢、风险高等问题，但同时也带来了性能、链路稳定性、数据一致性、脑裂和数据同步逻辑错误等众多在规划设计、实施和运维阶段的难点问题。
1、如何做到读写分离，提升IO读写效率？如何设计双活存储高可用，防止仲裁防脑裂？1.存储双活后，有一个难点就是热点数据的跨站访问，实施了数据库和存储层同时双活，会出现数据竞争的问题，这样也降低了IO效率。
这时候就要通过锁预取和缓存策略，通过较小的控制报文，向锁权限缓存节点申请写权限，并利用锁预取将部分区间的写权限缓存到本地。
这样，后续的连续写I/O操作可快速的命中在本地，减少跨站点的数据传输和交互，做到读写分离，从而提升IO读写性能。
2.AA模式的双活存储，在某些特定的多重故障下，仲裁机制会优先保证数据的一致性，可能会将双活存储上的所有LUN都停止主机访问。
所以，在设计仲裁模式的时候，强烈建议建立选择独立的第三方站点作为仲裁机，但也不能完全避免上述情况，所以，还要考虑强制启动，而强制启动端的存储作为同步源端，会在链路恢复后同步增量差异数据。
@邓毓江西农信系统工程师：双活的两个存储都可以同时对主机提供读写服务，也可以选择一个存储作为写存储服务，另一个存储作为读存储服务，实现读写分离，这样的好处可以减少双活存储的写I/O竞争，降低写I/O时延。
双活存储高可用的话，需要设置第三仲裁站点，可以用磁盘或者虚拟机来做仲裁，仲裁机制根据存储双活方案可以选择静态优先+动态仲裁双重机制来保障脑裂或者故障后的双活存储。
读写分离，可以采用存储复制技术完成，也可以采用数据库软件复制技术完成，为保证数据的较高实时性，需要用两个不同的服务器挂载双活lun或者采用数据库集群，或者adg方案实现，为了保证好的IO读写效率，需要保障双活存储间的网络带宽和低延时。
银行双活容灾建设方案技术手册-规划篇
银行双活容灾建设方案技术手册——规划篇目录1、应用层数据复制架构选型规划 (3)2、存储层数据复制架构选型规划 (10)3、整体架构各功能层分解规划设计 (16)4、核心系统双活基础架构规划设计 (19)随着全球IT产业的飞速发展，金融行业的IT建设逐步成为主导金融企业业务发展的核心驱动力，基于金融行业IT系统建设的各种行业标准以及监管标准也相应提高。
IT系统架构的扩展性、灵活性以及容灾能力就成为衡量企业IT建设很重要的标准。
本手册以某银行同城双数据中心建设过程为背景，详细从系统架构集成、资源云化、存储整合以及数据容灾等多个关键方面阐述其规划思路以及建设过程，旨在为同业在此类项目规划和建设过程中提供一些启示和帮助。
1、应用层数据复制架构选型规划1.1 应用事务日志回放技术下图是Oracle数据库层面的数据复制技术（ADG）的架构原理图。
对于该架构原理图，本文从其实现的基本条件、数据复制原理、数据复制的模式以及数据复制的关键因素等几个方面来进行深度剖析。
Oracle Active Data Guard1.1.1 前提条件容灾站点之间需要有三层以太网连通，软件层面需要数据库的集群软件模块（Oracle Active Data Gurard）或者是db2 purscale hadr。
服务器层面需要至少两套服务器系统分别部署于两个数据中心。
存储层面需要两套存储空间分别部署于两个站点作为主库存储和备库存储，他们互相之间独立。
1.1.2 复制原理对于主站点的数据库来讲，客户端的数据更新请求首先要由日志写入进程写到重做日志当中，然后由数据写进程再周期性地写入数据文件当中。
重做日志当中以SCN为数据库独有的时间搓序列来记录所有数据库更新的先后顺序，从而保障数据库恢复能够按照正确的顺序执行保障数据一致性和完整性。
那么对于配置了Active Data Guard的数据库读写的完成在以上所述过程中，日志写进程在本地日志文件写入过程的同时，日志传输进程会将缓存里面的重做日志通过ADG传输给灾备站点的备库实例，备库实例的日志接收进程根据接受到的重做日志在备库上重新执行数据库的更新操作，从而保证主库和备库的事务性更新行为一致性，最终保证数据的一致。
商业银行应用级灾备规划和建设经验
商业银行应用级灾备规划和建设经验1 、灾备定义灾备顾名思义，就是灾难备份，对于银行业来说，无论是监管机构的规定，还是出于银行重要业务的可靠性要求，都是一件必须要考虑的事情。
银行业的灾备建设，从原始的灾难备份要求，逐渐演变为灾难快速响应及快速切换要求。
通俗来讲，就是从数据级灾备过渡到应用级灾备的需求。
灾备建设主要有以下几个要点。
数据：无论是哪种灾备建设要求，都是基于数据出发的，数据保护是灾备建设的基本。
数据级灾备是要求灾备数据的存在性，当然，还需要定期的验证计划来保证这部分数据时可用的。
应用级灾备就要求在保证数据存在前提下，向灾备数据持续可用性转变的过程。
相对地对系统建设的要求和成本，也就要高很多。
数据同步：保证数据同步的一致性和实时性才能使灾备应用的接管有效。
目前主要的数据同步方式有两种，应用层同步和存储阵列同步。
考虑到目前城商行规模和实际场景，大部分都已经实现了共享的开放平台存储，所以基本上都采用了各存储厂商提供的数据复制技术来实现（同步异步可选），如 EMC 的 SRDF、IBM 的 metro mirror、HDS 的true copy 等，使用下来可以说同步复制技术几乎没有差别，都是基于一致性写实现的；异步复制技术区别也不大。
存储：简单来说，存储是所有数据的载体，是现在灾备建设基础设备。
实践经验告诉我们，对于有建设同城灾备甚至两地三中心需求的机构，尽量能够采用各型存储中的高端型号，避免在中端存储的复制稳定性和 license 限制上受局限。
网络：网络环境是灾备建设最底层的需求。
灾备网络需要满足这么几个要点：生产隔离＋网络联通性，网络对称性＋适量冗余，安全访问＋自动分发。
2 、灾备建设原则2.1、数据一致性。
实时检验数据复制的状态，保证数据传输链路的稳定。
并建立应用校验机制，定期验证数据的一致性2.2、完善的流程。
建设灾备，就必须同步建设相应的灾备切换流程和应用同步流程，这有助于降低日常灾备维护压力，提高灾备中心规范化同步，保证双中心的系统能够同步上线。
城商行新一代核心平台高可用设计方案
城商银行新一代核心基础平台高可用设计方案目录1.银行核心系统架构设计背景与原因 (3)1.1中小银行核心系统基础架构现状 (3)1.2中小银行核心系统基础架构现有问题 (4)2银行新一代核心架构方案设计 (5)2.1. 新一代核心架构设计目标 (5)2.2. 新一代核心基础架构数据库模块 (7)2.2.1数据库模块部署设计方案 (7)2.2.2数据库模块技术要点 (8)2.3. 新一代核心基础架构应用模块 (9)2.2.3应用模块部署设计 (9)2.2.4应用模块虚拟化技术特点 (10)2.4. 新一代核心基础架构总体部署方案 (11)3新一代核心系统基础架构建设 (12)3.1. 新核心基础平台建设实施与经验分享 (12)3.2. 新核心基础环境平台测试验收 (13)3.3. 新核心基础平台高可用架构故障应急方案 (14)4结语 (16)1.银行核心系统架构设计背景与原因1.1 中小银行核心系统基础架构现状伴随着信息技术的发展历程，城商银行的 IT 系统建设在银监、人行等监管单位的指导下逐步形成里两地三中心的基础架构格局。
这里主要介绍笔者所在城商银行上一代基于同城主备双中心的核心系统基础架构。
本行核心系统即综合业务系统建设于08 年开始上线运行，并于13 年实现同城双中心容灾模式改造。
综合业务系统主要包括前置系统、渠道系统、核心后台系统三套应用系统组成，是全行最重要的业务生产系统，是管理核心客户信息、处理客户账户及核心总账、提供存贷款业务、支付结算业务、中间业务、进行产品创新的主要信息平台。
在多年的运行过程中有效的支撑了银行业务的运营与发展。
上一代核心系统基础架构拓扑图如下：核心群业务应用采用高端PC 服务器冷备模式核心1 机和核心2 机组成一套冷备环境；核心前台渠道1 机和核心前台渠道2 机组成一套冷备环境；核心数据库系统运行在IBM Power 小型机上，核心数据库1 机和核心数据库1机组成一套 HA 环境，通过使用 PowerHA 高可靠集群软件，利用冗余配置，消除单点故障，保证整个系统连续可用性和安全可靠性。
银行灾难备份与恢复技术
银行灾难备份与恢复技术灾难备份是为了灾难恢复而对数据、数据处理系统、网络系统、基础设施、专业技术支持能力和运行管理能力进行备份的过程。
灾难恢复是为了将信息系统从灾难造成的故障或瘫痪状态恢复到可正常运行状态、并将其支持的业务功能从灾难造成的不正常状态恢复到可接受状态而设计的活动和流程。
衡量灾备系统的两个重要指标是：1）恢复时间目标（Recovery Time Objective，RTO）：灾难发生后，信息系统或业务功能从停顿到必须恢复的时间要求。
RTO标志着系统能够容忍的服务停止的最长时间。
系统服务的紧迫性要求越高，RTO的值越小，灾备能力就越高。
2）恢复点目标（Recovery Point Objective，RPO）：灾难发生后，系统和数据必须恢复到的时间点要求。
RPO标志着系统能够容忍的最大数据丢失量。
系统容忍丢失的数据量越小，RPO的值越小。
若RPO等于0，相当于没有任何数据丢失。
否则，就需要进行业务回复处理，对丢失数据进行修复。
RPO针对的是数据丢失，RTO针对的是服务丢失，两者必须在进行风险分析和业务影响分析之后根据业务的需求来确定（表22-1）。
表22-1灾备等级要求与灾备技术表22.1技术与发展趋势一般来讲，灾备系统可以分为数据级容灾、应用级容灾和业务级容灾。
1）数据级容灾是指通过建立异地容灾中心，做数据的远程备份，在灾难发生之后要确保原有的数据不会丢失或者遭到破坏；但在数据级容灾这个级别，发生灾难时应用是会中断的。
在数据级容灾方式下，所建立的异地容灾中心可以简单地理解成一个远程的数据备份中心。
数据级容灾的恢复时间比较长，但是相比其他容灾级别来讲，它的费用比较低，而且构建实施也相对简单。
2）应用级容灾是在数据级容灾的基础之上，在备份站点同样构建一套相同的应用系统，通过同步或异步复制技术，这样可以保证关键应用在允许的时间范围内恢复运行，尽可能减少灾难带来的损失，让用户基本感受不到灾难的发生，这样就使系统所提供的服务是完整的、可靠的和安全的。
银行灾备实施方案
银行灾备实施方案一、前言。
随着信息技术的不断发展，银行业在日常运营中越来越依赖于信息系统。
然而，信息系统的稳定性和安全性往往受到各种自然灾害和人为因素的威胁，一旦发生灾害，可能对银行业务造成严重影响。
因此，建立健全的银行灾备实施方案显得尤为重要。
二、灾备方案的重要性。
银行作为金融机构，其业务具有高度的复杂性和敏感性，一旦遭受灾害，将对客户的资金安全和日常交易产生重大影响。
因此，建立完善的灾备实施方案，可以最大程度地减少灾害对业务的影响，保障银行业务的持续稳定运营。
三、灾备方案的内容。
1. 风险评估与规划。
首先，银行需要对可能影响业务的各类灾害进行风险评估，包括自然灾害（如地震、洪水等）和人为灾害（如网络攻击、恶意破坏等）。
在风险评估的基础上，制定相应的灾备规划，明确各类灾害发生时的处置流程和责任人，确保在灾害发生时能够迅速有效地应对。
2. 数据备份与恢复。
银行业务的核心是数据，因此数据备份和恢复是灾备方案中至关重要的一环。
银行需要建立完善的数据备份体系，包括定期备份和异地备份，确保数据的安全性和可靠性。
同时，需要建立快速、高效的数据恢复机制，以便在灾害发生后能够迅速恢复业务数据，保障业务的正常运营。
3. 硬件设施与应用系统。
除了数据备份外，银行还需要对硬件设施和应用系统进行灾备规划。
这包括建立备用的数据中心和服务器设备，以及制定应用系统的灾备恢复方案。
在灾害发生时，可以通过切换到备用设施和系统，确保业务的连续性和稳定性。
4. 人员培训与演练。
最后，银行需要对员工进行灾备意识培训，确保员工能够在灾害发生时迅速有效地应对。
同时，需要定期组织灾备演练，检验灾备方案的可行性和有效性，及时发现和解决存在的问题，保障灾备方案的实施效果。
四、总结。
银行灾备实施方案是保障银行业务持续稳定运营的重要保障措施。
通过对各类灾害进行风险评估和规划，建立完善的数据备份和恢复机制，以及对硬件设施和应用系统进行灾备规划，银行可以有效应对各类灾害，保障业务的连续性和稳定性。
商业银行的灾备恢复计划
PART 06
案例研究
国际知名银行的灾备恢复计划
摩根大通银行
摩根大通银行拥有全球化的灾备恢复体系，其在美国、欧洲 和亚洲均设有数据中心，以确保在灾难发生时能够快速恢复 服务。该计划包括数据备份、灾难检测和恢复流程等多个方 面。
花旗银行
花旗银行采用多层次灾备技术，包括数据备份、远程镜像和 快速恢复等。该计划还特别注重业务连续性，通过在多个地 区部署业务处理中心，确保在灾难发生时能够维持核心银行 业务的运营。
镜像备份
将整个系统或磁盘镜像到另一个存储设备 上，数据完整性和恢复速度较高，但需要 较大存储空间。
恢复站点选择与建设
本地恢复站点
在本地建立恢复站点，数据恢复 速度快，但需要投入大量资金和
资源。
异地恢复站点
在异地建立恢复站点，可以避免本 地灾害对数据的影响，但需要考虑 数据传输速度和安全性问题。
云端恢复站点
人员培训与组织文化
挑战
商业银行的员工可能缺乏灾备恢复 的专业知识和经验，同时组织文化 也可能影响灾备恢复计划的实施。
2. 应急演练
定期进行应急演练，模拟真实 灾难场景，提高员工的应急响 应能力。
1. 培训与认证
定期组织灾备恢复相关的培训 和认证课程，提高员工的专业 技能。
3. 组织文化培养
通过宣传和教育，培养员工对灾 备恢复的重视程度和责任感，形 成良好的组织文化氛围。
灾备恢复计划是商业银行为应对突发 事件或灾难性事件而制定的全面、系 统的恢复计划，旨在确保业务连续性 、数据安全和关键资源的可用性。
目标
最大限度地减少灾难对银行业务的影 响，尽快恢复服务，保障客户资金安 全，维护银行声誉和利益。
灾备恢复的重要性
某省银行灾备方案
1、概述随着计算机技术和通讯技术的高速发展，以计算机和通讯技术为基础的金融电子化系统得到了飞速发展。
XXXX银行XXXX省分行为了发挥计算机城市综合网系统的最大优势，在市场竞争中保持XXXX银行现有的科技优势，能够给大行业大企业提供全省范围内的优质服务，加强城市综合网系统的安全运行。
规划将XXXX银行XXXX省分行全省范围内的客户数据帐务信息，集中到省分行运行中心统一处理，这是计算机应用技术发展的必然，也是XXXX银行XXXX省分行业务发展的需要。
随着数据集中处理的实施，可以预计，XXXX的业务运作、经营管理将越来越依赖于计算机网络系统的可靠运行。
XXXX银行所提供金融服务的连续性以及业务数据的完整性、正确性、有效性，会直接关系到我们XXXX的生产、经营与决策活动。
一旦因自然灾害、设备故障或人为因素等原因引起计算机网络系统停顿导致信息数据丢失和业务处理中断，将会给XXXX银行XXXX省分行造成巨大的经济损失和声誉损害，受到致命的打击。
将全省客户帐务数据集中统一处理，因数据集中处理伴随而来的运行风险将因为灾难发生大大增加。
生产运行主机系统及其配套设备一旦发生故障，就会导致在全省XXXX银行范围内所有营业柜台停止营业的风险。
会计、储蓄、信用卡等XXXX银行的三大主营业务的停业，XXXX银行XXXX省分行面临的将是灾难性打击。
因此，生产运行系统的灾难备份系统就显得格外重要。
我们认为，一旦实施全省数据集中，灾难备份系统应该与生产运行应用系统（全省集中）同步投入使用，保证全省数据集中处理系统的运行安全。
根据XXXX银行XXXX省分行数据集中处理领导小组的统一安排，1999年10月10日到10月20日，分行科技处组织人员在XXXX市龙泉，进行封闭式工作，制定城市综合网系统全省数据集中处理规划，本应用系统灾难备份系统XXXX规划是其中很重要的分部。
1.1 计算机系统灾难备份概念简介1.1.1 计算机系统灾难定义计算机系统灾难是指造成重要业务数据丢失，使业务中断了不可忍受的一段时间的计算机系统事故，这些事故导致银行丧失了全部或部分业务处理能力，引起企业营业收入下降、信誉降低和形象受损，甚至威胁其生存。
城商行基于VPLEX+RecoveryPoint的存储灾备方案
城商行基于VPLEX+RecoveryPoint的存储灾备方案目录1. 概述 (3)1.1. 项目背景 (3)1.2. 建设目标 (3)2. 方案规划设计 (3)2.1. 原系统架构 (3)2.2. 方案总体设计 (4)2.2.1. 第一阶段规划设计 (6)2.2.2. 第二阶段规划设计 (18)3. 关键问题 (21)3.1. 仲裁一致性问题 (21)3.1.1. VPLEX 仲裁 (21)3.1.2. Oracle 仲裁 (24)3.1.3. VPLEX 和 Oracle 仲裁一致性 (25)3.2. 同城双活中心间链路抖动问题 (25)3.3. 性能下降问题 (26)3.4. 运行维护问题 (26)l 用户自身人员的维护能力必须加强，才具备能力维护跨站点的双活系统。
(26)l 双活容灾解决方案供应商的售后服务能力 (26)l 需要结合运维监控和运维自动化完成双活数据中心的运行管理。
(26)4. 总结 (27)摘要：伴随着城市商业银行业务的快速发展，信息技术在金融业应用日渐深入，信息系统安全稳定运行的重要性日益突出。
银行业信息系统的灾备体系建设是保障银行业务连续性的重要防线，是维护银行业信息和网络安全的重要保障机制。
2007 年以来 , 监管机构陆续发布了保障业务连续稳定运行、规范商业银行信息系统灾难恢复管理的规章制度，明确了商业银行在灾难情况下开展信息系统恢复的要求 , 对商业银行开展灾备体系建设具有重要的指导意义。
本文结合某城商银行的实际案例着重介绍城商银行基于集中式存储实现两地三中心灾备建设的方案设计。
1. 概述1.1. 项目背景长期以来，由于监管导向和业务连续性要求，国内银行业信息系统普遍强调业务系统的高可用性和高稳定性。
经过十多年的建设发展，我行现有系统规模逐渐扩大，在当前的发展趋势下，我行应用系统大量采用 X86 架构服务器， Power 小型机主要用于关键业务数据库，此外 Power 小型机架构平台上还运行着数十套老旧的业务生产系统。
商业银行灾备体系建设方法分析
商业银行灾备体系建设方法分析一、需求分析商业银行灾备体系建设的首要任务是进行需求分析。
首先要明确银行所面临的灾备需求，包括业务持续性需求和数据安全性需求。
其次，要考虑灾备体系的规模和范围，例如是否需要建设多个数据中心或灾备中心。
同时还需要分析银行的业务流程和数据流动，确定关键业务、关键数据和关键系统，以便有针对性地进行灾备体系建设。
二、风险评估在灾备体系建设之前，商业银行需要进行风险评估，确定可能会遇到的各种灾害和紧急情况，并评估对银行业务和数据的潜在影响。
这些风险包括自然灾害、人为事故、设备故障等。
在评估的基础上，商业银行可以制定相应的预防和应急措施，以减轻潜在的风险。
三、架构设计灾备体系的架构设计是商业银行灾备体系建设的核心环节。
架构设计应该符合银行的业务需求和风险评估的结果，确保在灾害或紧急情况下能够实现业务的持续性运行和数据的安全性。
架构设计应该包括数据中心的布局、灾备设备的选择和配置、网络拓扑设计、灾备流程的设计等。
四、设备选型灾备体系的设备选型是商业银行灾备体系建设的重要环节。
在设备选型过程中，商业银行应该考虑设备的可靠性、性能、扩展性和兼容性等因素。
同时还要考虑设备的投资成本和运维成本，以确保投资回报率。
设备选型应该综合考虑商业银行的业务需求、架构设计和风险评估的结果。
五、数据备份商业银行灾备体系建设的关键环节之一是数据备份。
商业银行需要制定完善的数据备份策略，包括备份的频率、备份的存储介质、备份的存储位置等。
同时还要考虑数据备份的恢复性和可靠性。
商业银行还需要定期测试数据备份方案，以确保备份的完整性和可恢复性。
六、应急响应商业银行在灾备体系建设之后，还需要建立完善的应急响应机制。
这包括灾备演练、应急预案的编制、人员培训等。
商业银行需要定期进行灾备演练，以验证灾备体系的有效性和可行性。
应急预案应该涵盖各类灾害和紧急情况的应对措施和流程，并确保相关人员熟悉和掌握应急预案。
七、监控与管理商业银行灾备体系建设完成后，需要建立健全的监控与管理系统。
银行应用级灾备建设方案
银行应用级灾备建设方案目录1项目背景及建设需求 (3)2各系统数据备份概况 (4)3灾备端应用部署规划 (5)4灾备网络通信系统 (7)5各业务系统应用级部署工作计划 (8)6各业务系统应用部署工作分解 (9)6.1系统部署 (9)6.1.1AIX平台 (9)6.1.2虚拟机平台 (9)6.2FTP环境构建 (10)6.3系统验证 (11)6.3.1验证前准备 (11)6.3.2单系统验证 (15)6.3.3系统集成验证 (16)7项目主要风险点 (17)1项目背景及建设需求目前，我行灾备项目已完成核心业务域和城商业务域数据级同城备份，通过两台IBM中端磁盘阵列实现了两大业务域关键数据从生产中心到灾备中心的同城复制。
其中：✧DS5100承载ESB、加密平台、图形前端数据库三个系统数据复制，未实现数整报表系统的数据复制✧DS5020承载PCSP（综合前置）、ATMP、虚拟化平台数据复制，未实现财务系统（NC）数据复制按山东省银监局相关要求：2013年三季度，需要完成国际结算、信贷、图形前端、票据、手机银行、NC、ATMP、数整报表、加密平台、综合前置、ESB等十一个重要业务系统的应用级灾备建设。
2各系统数据备份概况十一个业务系统数据存储及异地备份概况统计如下表：从上表可知，ESB、加密平台、图形前端、ATMP、综合前置（PCSP）等五个系统数据通过磁盘阵列实时复制到灾备端，数整报表、国际结算、信贷、票据、手机银行、财务系统等六个系统数据则通过每日全备、定时FTP传送至灾备端。
3灾备端应用部署规划目前，灾备中心网络链路已就绪，各业务系统应用服务器硬件已完成上架、加电测试等相关工作。
各系统部署规划如下表：系统名称系统平台数据库应用灾备端服务器配置ESB AIX6100-07 DB2 9.1 P740一台加密平台AIX6100-07 P720一台SQLServer虚拟机图形前端Windows20082008ATMP AIX5300-12 Oracle10g P720一台综合前置AIX6100-07 P720一台数整报表AIX6100-07 DB2 9.1 P740一台国际结算Windows2003 虚拟机信贷系统Windows2003 虚拟机票据系统SLES10 虚拟机手机银行SLES11 虚拟机财务系统AIX5300-12 P720一台（NC）其中：✧虚拟机平台物理服务为四台IBM 3850 X5✧图形前端数据库服务器、应用服务器均部署在虚拟机平台✧国际结算、信贷、票据、手机银行四个系统也部署在虚拟机平台上✧加密机为独立硬件✧加密平台、ATMP、PCSP、NC四个系统分别部署在4台P720小机内✧ESB、数整报表两个系统分别部署在两台P740小机内4灾备网络通信系统网络通信系统详见《我行灾备中心建设方案》。
城商行如何通过存储双活设计提升数据中心级的双活能力？
城商行如何通过存储双活设计提升数据中心级的双活能力？为了满足银行各类新产品业务发展需求，建设可信IT，面向双活或者多活数据中心改造以及核心改造成为各中小银行的重点项目。
双活数据中心建设，需要从应用层、网络层、数据库层、存储层等多方面进行考虑，数据库和存储的双活实现息息相关，均是双活数据中心建设的重点与难点，其中存储双活无疑是双活数据中心建设的基石。
社区最近针对城商行如何实现同城数据中心存储双活以及对数据库双活的支持，邀请专家进行问诊及交流。
以下是参与交流的社区会员提出的10个典型问题，由专家和同行解答及分享经验。
1、双活中心一般建议存储异步还是同步，两种模式对于双中心距离要求为多少？@bbaimm88 某城商行存储架构师：结合非重要业务与重要业务来看，不然领导觉得你是单纯谈技术，脱离了实际。
两种模式各有特色，性价比与安全性各有特色。
@summit 某城商行系统架构师：1 、双活分应用级双活还是数据库也实现双活，如果是全双活的话，建议双中心距离不要超过100KM ，保障裸光纤链路质量不要超过 5ms 延迟。
裸光纤链路质量是双活的关键。
2 、如果只是应用级双活的话，存储和数据库的架构决定你采用什么样的复制关系。
如果采用 ADG ，一般采用最大性能方式，存储复制的话一般同步和异步都可以，如果裸光纤质量不好就采用异步复制方式。
同步方式如果裸光纤发生抖动可能造成 IO 的短暂 hung ，会对业务造成影响。
3 、存储复制异步和同步主要依据你双活的实现方式。
@吕峰戴尔科技金融行业中国西区高级系统工程师：存储双活有三种块、文件和对象。
块和文件双活都是以数据同步为前提的，对象通常是保证metadata 的同步，底层文件数据做异步传输。
同步模式下主要是看业务对延迟的最大容忍度是多少，通常存储要求往返 5ms 延迟是做块存储双活的底线，距离如果按照光速计算就很远了。
实际距离来说，欧洲有超过 500km 的 SAN 双活实施，国内基本都是50km 以内。
银行双活容灾建设方案技术手册-分析篇
银行双活容灾建设方案技术手册——分析篇目录1、双活数据中心的驱动力 (3)2、定义符合自己的双活模式 (4)3、实现双活需要考虑的关键因素 (14)随着全球IT产业的飞速发展，金融行业的IT建设逐步成为主导金融企业业务发展的核心驱动力，基于金融行业IT系统建设的各种行业标准以及监管标准也相应提高。
IT系统架构的扩展性、灵活性以及容灾能力就成为衡量企业IT建设很重要的标准。
本手册以某银行同城双数据中心建设过程为背景，详细从系统架构集成、资源云化、存储整合以及数据容灾等多个关键方面阐述其规划思路以及建设过程，旨在为同业在此类项目规划和建设过程中提供一些启示和帮助。
1、双活数据中心的驱动力近年来，随着互联网金融的快速发展，金融企业数据中心建设面临着新的挑战。
那就是对RTO和RPO的极限追求。
从而也就诞生了近年来的热点话题——双活数据中心建设。
那么我们为什么要建设双活数据中心，它能给我们带来什么样的价值？什么样的数据中心架构叫做双活数据中心？如何认识适合自己业务模式的双活模式？建设阶段我们应该以什么样的原则来指导我们的建设工作？具体的建设思路以及具体的建设方案应该如何把握？基于这些问题，本文将进行深入研究并展开探讨。
从科技工作层面来讲，其实双活数据中心并不是一个行业标准或者规范。
行业的标准是对RTO和RPO约束，银监局和中国人民银行对商业银行业最严格的要求标准是5级容灾标准，RPO=15分钟，RTO=30分钟。
而根据国际标准share78，六级容灾标准是RPO=0，RTO=分钟级；七级容灾标准是RPO=0，RTO近似为0。
双活的概念也就由此而来，为了达到国际最高标准。
那么决策是否建设双活数据中心的依据也就在于此，首先确定自己企业合适的目标，是不是要必须追求7级标准？是不是所有业务都必须追求这个目标？如果不是，那么首先要对企业业务进行细分并详细规划每一个业务的容灾目标。
这将决定要不要建设双活数据中心以及建设什么样的双活数据中心。
银行灾备方案
银行灾备方案一、引言随着现代金融业务的不断发展和数字化的加速推进，银行系统的高可用性和数据安全性成为重中之重。
为了确保持续的服务和保护客户利益，银行需要建立完备的灾备方案。
本文档将详细介绍银行灾备方案的设计和实施。
二、灾备需求分析2.1 灾备目标1.数据可靠性：保证数据的完整性、一致性和可恢复性。
2.业务连续性：确保银行业务在灾难事件后能够持续运行，降低中断时间。
3.系统可用性：提供高可用的系统和网络基础设施，确保服务的稳定性。
4.安全性：保护客户敏感信息和关键业务数据的安全性。
2.2 灾备策略1.数据备份和恢复策略：定期备份和存储关键数据，确保数据可靠性。
同时，建立快速恢复机制，实现数据的快速恢复。
2.冗余策略：通过建立冗余系统和设备，提高系统可用性。
包括主备站点的建设、冗余网络设备、电力设备等。
3.灾难恢复策略：制定针对各类灾难事件的应急预案，包括火灾、地震、网络攻击等，确保业务的持续运行。
4.安全保障策略：建立完善的安全体系，包括网络安全、数据安全和设备安全等方面，保护客户信息和关键业务数据。
三、银行灾备方案设计3.1 灾备组织结构为有效实施银行灾备方案，需要建立灾备组织结构。
组织结构包括：1.灾备总负责人：负责统筹规划和决策灾备工作。
2.灾备团队：由各部门的专业人员组成，负责具体的灾备工作。
3.灾备委员会：定期召开会议，讨论重大决策和问题。
3.2 灾备设施建设1.主备站点建设：在不同地理位置建立主备站点，实现数据的实时同步和服务的快速切换。
2.电力和网络设备冗余：建立冗余的电力和网络设备，确保系统可用性。
3.数据备份和存储：建立定期备份和存储机制，确保数据的可靠性和可恢复性。
4.灾备测试环境：建立灾备测试环境，定期进行灾备演练，确保应急预案的可行性。
3.3 灾备计划制定和调整1.灾备计划制定：根据灾备目标和策略，制定详细的灾备计划，包括数据备份计划、灾难恢复计划和应急预案等。
2.灾备计划调整：定期评估灾备计划的有效性，并根据需求和技术发展情况进行相应的调整和优化。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
城商行基于VPLEX+RecoveryPoint的存储灾备方案目录1. 概述 (3)1.1. 项目背景 (3)1.2. 建设目标 (3)2. 方案规划设计 (3)2.1. 原系统架构 (3)2.2. 方案总体设计 (4)2.2.1. 第一阶段规划设计 (6)2.2.2. 第二阶段规划设计 (18)3. 关键问题 (21)3.1. 仲裁一致性问题 (21)3.1.1. VPLEX 仲裁 (21)3.1.2. Oracle 仲裁 (24)3.1.3. VPLEX 和 Oracle 仲裁一致性 (25)3.2. 同城双活中心间链路抖动问题 (25)3.3. 性能下降问题 (26)3.4. 运行维护问题 (26)l 用户自身人员的维护能力必须加强，才具备能力维护跨站点的双活系统。
(26)l 双活容灾解决方案供应商的售后服务能力 (26)l 需要结合运维监控和运维自动化完成双活数据中心的运行管理。
(26)4. 总结 (27)摘要：伴随着城市商业银行业务的快速发展，信息技术在金融业应用日渐深入，信息系统安全稳定运行的重要性日益突出。
银行业信息系统的灾备体系建设是保障银行业务连续性的重要防线，是维护银行业信息和网络安全的重要保障机制。
2007 年以来 , 监管机构陆续发布了保障业务连续稳定运行、规范商业银行信息系统灾难恢复管理的规章制度，明确了商业银行在灾难情况下开展信息系统恢复的要求 , 对商业银行开展灾备体系建设具有重要的指导意义。
本文结合某城商银行的实际案例着重介绍城商银行基于集中式存储实现两地三中心灾备建设的方案设计。
1. 概述1.1. 项目背景长期以来，由于监管导向和业务连续性要求，国内银行业信息系统普遍强调业务系统的高可用性和高稳定性。
经过十多年的建设发展，我行现有系统规模逐渐扩大，在当前的发展趋势下，我行应用系统大量采用 X86 架构服务器， Power 小型机主要用于关键业务数据库，此外 Power 小型机架构平台上还运行着数十套老旧的业务生产系统。
随着使用年限的增加，计算存储资源已经饱和，设备老化严重，进入故障高发期，相关问题亟待解决。
另外随着新一代核心系统项目群的上线，对计算和存储的资源的需求快速增加，并需要重新构建新系统的容灾体系，满足业务连续性的监管要求。
1.2. 建设目标通过新购服务器和存储设备，采用新的架构进行容灾的设计，有望达成本次项目目标：一是对部分老旧设备升级换代，为业务系统提供安全稳定的生产资源；二是满足新一代核心系统项目群系统的上线计算资源、存储资源需求；三是满足两地三中心的容灾规划建设，最终实现同城双活 + 异地容灾体系，增强业务连续性保护，较好的满足监管要求。
2. 方案规划设计2.1. 原系统架构原生产环境分为以 X86 虚拟化为主的资源区和以 Power 小型机为主的资源区，两个资源区资源相对独立，如下图所示：目前 Power 小型机资源区存在的问题主要集中在以下几点：1 、需要提供足够的资源满足新一代核心系统项目群的系统上线，而 Power 小型机资源区计资源和存储资源严重不足，急需进行扩容。
2 、IBM DS8000 的存储设备老化严重，故障率增高，需要更新换代。
3 、新系统上线后需要重新进行容灾系统的规划设计。
为了解决以上问题，基于 Dell EMC VPLEX+Recovery Point 的架构重新进行小型机资源区的容灾设计，以满足新一代核心系统项目群系统上线的资源需求，并建立新系统的灾备体系，满足业务连续性的需求。
2.2. 方案总体设计考虑到同城灾备机房和异地灾备机房建设进度，整个项目分两个阶段进行。
第一阶段，完成存储设备的更新换代，并将原有系统平滑迁移到新的存储，并支撑新一代核心系统项目群系统上线。
第二阶段，完成同城双活 + 异地容灾的灾备体系建设。
最终方案采用 Dell EMC VPLEX Metro+Recovery Point 方案来构建两地三中心数据存储方案。
VPLEX 的关键能力 AccessAnywhere 是通过分布式一致性缓存技术 (Distributed Cache Coherenece) 来实现，在集群内及跨区域的另一集群间完成缓存数据的一致性；实现跨主机、跨集群、跨数据中心的访问和在节点之间同步镜像。
VPLEX 通过把控制器的单个内存系统进行合并以形成分布式缓存。
分布式设计可以跨 VPLEX Metro 和 Geo 系统进行扩展，以提供全局系统的缓存连贯性和一致性。
分布式一致性缓存技术在实现上面，并没有强求所有的 Cache 都保持统一，而是基于目录形式来跟踪细小的内存块通过锁的粒度来加强扩展能力。
每个引擎的 cache 分为本地 Cache ( Cachelocal ) 和全局 Cache (Cache global) 。
读的时候先读 Director 的 Local Cache ，如命中直接读取；如在 Global 中命中，则从对应的引擎 Cache 中将其读取到 Local Cache ，再反馈主机；如没有命中，则从本地后端的存储中读取到Local 中，并同时修改 Local 和 Global Cache 中的信息与索引信息。
写数据时， VPLEX Local 和 Metro 都采用透写方式。
VPLEX Local 待数据写入后端的磁盘阵列后，才会向主机回应写完成，而 VPLEX Metro 需要待数据写入两地的磁盘阵列后，才会向主机回应写完成。
VPLEX Metro 架构下写操作处理如下：1.主机发送写操作到 VPLEX 的 Director2.Director 收到写请求时，将写操作发送给另外一个站点的 VPLEX3.Director 先判断是否在 Local 、 Global Cache 中有对应的旧数据，如没有直接写入后端存储的 cache ；如有旧数据，先废除 Local 、 Global Cache 中旧数据再写入后端存储 cache4.写入后端存储 cache ，反馈写操作完成5.远端站点的 VPLEX 将写操作结果返回给本地站点的 VPLEX6.只有 VPLEX Metro 的两边的存储都写成功，才会返回主机写操作成功2.2.1. 第一阶段规划设计第一阶段需要将新购的 VPLEX 、 VMAX100K 进行安装并接入 FC 网络，完成数据的迁移。
如下图所示：在实施前需要对原有环境进行调研，梳理 FC SAN 网络，并分析原来 IBM DS8000 存储的 IOPS 和带宽使用情况，规划好 FC 交换机级联的带宽并做到充分的冗余。
另外需要梳理 IBM DS8000 上各个系统 volume 的映射情况。
考虑到银行关键业务系统 7*24 小时提供服务，故如何减少停机时间并平滑的进行数据迁移是关键。
采用 Dell EMC VPLEX 存储网关来进行 DS8000 存储系统的磁盘封装，将应用系统和数据库接入 VPLEX 的环境，这样 VPLEX 完成磁盘封装和映射给操作系统后，经过重新识别磁盘可快速恢复业务系统缩短停机时间，经过前期的论证和测试，可在人行的 8 小时停机窗口完成该操作并恢复业务系统的正常运行。
之后再利用 VPLEX 的 Mobility 功能进行存储上数据的无缝切换。
下面对整个过程分别进行说明：2.2.1.1. 存储网关接管应用 IO在 VPLEX 环境中，对后端存储系统的磁盘设备采用整盘封装的方式下，可以将应用系统完整的迁移到 VPLEX 环境中，迁移步骤简述如下：1.在主机上，停止应用系统的运行。
并进行数据库及重要文件系统内容的备份2.停止数据库。
3.在主机上，停止 HACMP 运行。
停止后建议在主机上重新启动 HACMP 进行验证，如存储单机或 VG 没有加入 HA 资源组，需单独将 VG varyon 检查，验证 VG 是否正常，以免封装后出现异常的情况下排错较为繁琐，必要由此造成实施过程中需要进行回退。
4.在主机上，删除相应的原存储系统的磁盘设备和 VG 信息5.在主机上，安装支持 VPLEX 的 Dell EMC ODM 软件包（ Dell EMC.Invista.aix.rte 、 DellEMC.Invista.fcp.rte ）和 Powerpath 软件，必要时卸载原阵列的多路径软件6.在原 DS8000 存储系统上，取消主机对磁盘设备的访问（可选）7.在 SAN Switch 上，删除主机 HBA 卡与原存储系统前端之间的 ZONE 。
并增加主机 HBA卡与 VPLEX 前端口之间的 ZONE 。
8.在 DS8000 存储系统上，赋予 VPLEX 对磁盘设备的访问9.VPLEX 扫描新分配的后端 DS8000 存储磁盘设备10.VPLEX“ 封装” 新分配的后端存储磁盘设备。
识别（ Claim ）新分配的后端存储磁盘设备。
创建“Ex t ent ” 。
将每个新分配的后端存储磁盘设备，“ 整盘封装” 成一个Extent 。
11.使用 DS8000 封装后的“ Extent ” 在 VPLEX 上创建“ 1:1 Mapping of Extents toDevice” 的 Device12.在 VPLEX 上使用“ 1:1 Mapping of Extents to Device” 的 Device 创建 virtual volume13.主机 HBA 在 VPLEX 进行 Initiator 的注册。
Host Type ： AIX 主机选择 aix ， Windows主机选择 default14.创建 Storage View 。
在 VPLEX Cluster 上创建 Storage View ，添加 VPLEX 前端口、Initiator 及 virtual volume 。
15.在主机上，识别和配置 VPLEX 的磁盘设备。
在 VIOS 主机或 HACMP 上，调整 VPLEX 的磁盘设备的 reserve_lock/reserve_policy16.在主机上，启动应用系统和数据库完成以上步骤后， VPLEX Local 中 virtual volume 逻辑结构如下所示：通过 VPLEX 封装 DS8000 的 volume ，不改变原来 DS8000 上的任何数据，同时原来的两套DS8000 之间的 Metro Mirror 保持同步状态，始终保持在两套 DS8000 上各有一份完整的数据。
VPLEX 接入存储环境后， IO 读写方式发生了变化，但该变化对于主机来说是透明的。
2.2.1.2. 存储数据迁移在上一步已经完成 VPLEX 接管主机的 IO ，要完成存储数据的迁移，需要使用 VPLEX 的另一项功能 Mobility 。