下载文档原格式
某商业银行应用双活架构设计方案2018 年 8 月一、设计原则重要业务系统应用双活项目是单位业务支撑系统建设中极为重要的一环，既要考虑系统平台的双活切换能力和系统架构的高可用,又要考虑数据层次的业务连续性，同时也要考虑单位信息系统今后几年的业务发展需求。
针对单位信息系统系统将保证业务系统的连续性来(支持 7x24 不间断运行)的特点，在此次重要业务系统双活项目中，要把系统的可靠性、稳定性、安全性和可扩展性作为本次规划的重点考虑因素。
在进行系统设计时，遵循以下原则：稳定性：稳定性是系统运行的关键，也是系统维护管理的关键因素，更是充分发挥科技骨干技术储备的关键。
安全性：系统软、硬件需具有可信赖的安全性，软件系统安全性方面应满足单位信息系统安全策略的要求，系统有严格的用户权限和密码保护设计和办法。
可靠性/可用性：系统软、硬件平台应稳定、可靠，能够满足业务系统 7x24 不间断的运行要求；具备成熟的高可用性和双活解决方案。
对数据的完整性和准确性有可靠的保证机制。
可持续发展性：所提供的技术是可持续发展的，是目前的主流技术并有长期发展的目标，能满足单位业务支撑信息系统未来几年业务发展的需求。
可扩展性：随着单位业务的不断发展、壮大，系统平台必须提供足够的可扩展能力以满足未来几年业务增长和系统扩展的需要。
可扩展性是保护用户投资的重要方面之一。
另外在系统设计时，应选择业界相关领域的主流产品，确保产品旺盛的生命力，以便充分地保护用户的投资。
易用性：系统软件平台应提供丰富的、简单的管理工具，便于管理及系统问题诊断。
开放的标准：系统软件需支持业界通用的开放式标准，降低因兼容性问题造成的问题发生率。
可维护性：系统维护需要简便快捷、不需要太多的管理人员和维护。
系统可维护性十分重要，它直接决定了系统的效能、产出和用户的总体拥有成本。
系统可维护性差会导致系统效能下降、产出降低，维护成本增加，后患无穷。
售后服务技术支持：厂家能提供足够、及时的技术支持与响应，来保证应用系统良好运行状态。
城商行核心业务系统存储跨中心双活建设方案随着互联网金融的快速发展，金融企业数据中心建设面临着新的挑战，那就是对RTO和RPO的极限追求，从而也就诞生了近年来的热点话题——双活数据中心建设，其作为灾备方案中高级别的解决方案，逐渐成为了应对传统灾备难题的一把利剑。
它能够解决传统的灾备方案中资源利用率低、可用性差、出现故障时停机时间长、数据恢复慢、风险高等问题，但同时也带来了性能、链路稳定性、数据一致性、脑裂和数据同步逻辑错误等众多在规划设计、实施和运维阶段的难点问题。
1、如何做到读写分离，提升IO读写效率？如何设计双活存储高可用，防止仲裁防脑裂？1.存储双活后，有一个难点就是热点数据的跨站访问，实施了数据库和存储层同时双活，会出现数据竞争的问题，这样也降低了IO效率。
这时候就要通过锁预取和缓存策略，通过较小的控制报文，向锁权限缓存节点申请写权限，并利用锁预取将部分区间的写权限缓存到本地。
这样，后续的连续写I/O操作可快速的命中在本地，减少跨站点的数据传输和交互，做到读写分离，从而提升IO读写性能。
2.AA模式的双活存储，在某些特定的多重故障下，仲裁机制会优先保证数据的一致性，可能会将双活存储上的所有LUN都停止主机访问。
所以，在设计仲裁模式的时候，强烈建议建立选择独立的第三方站点作为仲裁机，但也不能完全避免上述情况，所以，还要考虑强制启动，而强制启动端的存储作为同步源端，会在链路恢复后同步增量差异数据。
@邓毓江西农信系统工程师：双活的两个存储都可以同时对主机提供读写服务，也可以选择一个存储作为写存储服务，另一个存储作为读存储服务，实现读写分离，这样的好处可以减少双活存储的写I/O竞争，降低写I/O时延。
双活存储高可用的话，需要设置第三仲裁站点，可以用磁盘或者虚拟机来做仲裁，仲裁机制根据存储双活方案可以选择静态优先+动态仲裁双重机制来保障脑裂或者故障后的双活存储。
读写分离，可以采用存储复制技术完成，也可以采用数据库软件复制技术完成，为保证数据的较高实时性，需要用两个不同的服务器挂载双活lun或者采用数据库集群，或者adg方案实现，为了保证好的IO读写效率，需要保障双活存储间的网络带宽和低延时。
商业银行应用双活架构设计方案在商业银行的信息技术架构中，双活架构是一种旨在提高系统可用性和容错能力的方案。
它基于分布式架构原理，通过将数据和业务逻辑同时部署在两个独立的数据中心或机房，以实现高可用性、高可靠性和高性能。
双活架构的设计方案主要包括以下几个关键要素：1.双机房部署：商业银行需要选择两个地理位置相距较远的机房或数据中心进行部署。
这样可以避免单点故障，提高系统的容错能力。
两个机房之间应该采用高速可靠的网络连接，以保证数据的实时同步。
2.数据同步和复制：双活架构下，数据的同步和复制是实现高可用性的关键。
商业银行需要选择合适的数据同步技术和策略，确保两个机房之间的数据实时同步和一致性。
常用的数据同步方式包括基于日志的增量同步、基于快照的全量同步和异步同步等。
3.负载均衡和故障切换：商业银行需要采用负载均衡技术将用户请求分发到两个机房中的可用服务器。
当一个机房出现故障时，另一个机房可以接管用户请求，实现系统的高可用性和容错能力。
常用的负载均衡算法包括轮询、加权轮询和最少连接数等。
4.异地容灾和故障恢复：商业银行需要实现异地容灾和故障恢复机制，以应对自然灾害、网络故障和硬件故障等异常情况。
这包括备份和恢复数据、搭建冷备和热备系统、定期进行灾难恢复演练等手段，确保在极端情况下系统能够迅速恢复。
5.监控和运维：商业银行需要建立完善的监控和运维体系，及时监测双活架构下各个组件的运行状态和性能指标。
这包括实时监控系统的可用性、负载情况和数据同步状态，定期进行巡检和性能调优，确保系统的稳定性和可靠性。
总结起来，商业银行在应用双活架构的设计方案中需要考虑到双机房部署、数据同步和复制、负载均衡和故障切换、异地容灾和故障恢复以及监控和运维等关键要素。
通过合理设计和实施双活架构方案，商业银行可以提升系统的可用性和容错能力，为客户提供更加稳定可靠的金融服务。
双活数据中心方案双活数据中心方案一、介绍双活数据中心方案是一种高可用性解决方案，通过将数据和应用同时部署在两个数据中心，实现数据和应用的双向同步，提供业务连续性，降低系统故障风险。
本文档将详细介绍双活数据中心方案的各个方面。
二、架构设计1、数据中心选择- 硬件条件：选择具备足够硬件资源的数据中心，包括服务器、存储等设备。
- 网络条件：确保数据中心之间的网络带宽和延迟满足业务需求。
- 电力条件：确保数据中心具备稳定可靠的电力供应。
2、数据同步- 数据同步技术：选择合适的数据同步技术，如数据库复制、文件同步等，使两个数据中心的数据保持一致性。
- 数据同步策略：确定数据同步的频率和方式，如同步延时要求和同步方式（异步或同步）等。
3、应用部署- 应用集群化：将应用部署在多个服务器上，实现负载均衡和故障切换。
- 应用同步部署：将应用同时部署在两个数据中心，实现两地的业务连续性。
4、故障切换与容灾- 故障切换策略：定义故障触发条件和切换流程，确保故障时能够快速切换到备用数据中心。
- 容灾测试：定期进行容灾测试，验证容灾方案的可行性和有效性。
三、监控与报警1、监控系统- 监控指标：确定需要监控的指标，如服务器负载、网络流量、存储空间等。
- 监控工具：选择合适的监控工具，实时监控数据中心的各项指标。
- 监控策略：设置监控策略，包括告警阈值、告警通知方式等。
2、报警系统- 报警方式：选择适合的报警方式，如邮件、短信、方式APP等。
- 报警接收人：确定接收报警信息的人员，包括运维团队、管理人员等。
四、数据备份与恢复1、数据备份- 备份频率：确定数据备份的频率，如每天、每周等。
- 备份策略：定义备份策略，包括全量备份和增量备份等。
- 备份验证：定期验证备份数据的完整性和可用性。
2、数据恢复- 恢复时间目标（RTO）：定义数据恢复的时间目标，即从故障发生到数据恢复的时间。
- 恢复点目标（RPO）：定义数据恢复的点目标，即恢复到哪个时间点的数据。
应用级双活建设方案嘿，各位看官，今天咱们来聊聊应用级双活建设方案，这可是个技术活儿。
我这就开始给大家梳理一下，让你们看看这方案是怎么个玩法。
一、方案背景随着企业业务的发展，对信息系统的高可用性要求越来越高。
应用级双活建设方案就是在这样的背景下应运而生。
简单来说，就是让两个数据中心同时运行，互为备份，当一个数据中心出现问题时，另一个数据中心能够立刻接替它的工作，保证业务不中断。
二、方案目标1.提高系统可用性：通过应用级双活，实现99.999%的系统可用性，让业务运行更加稳定。
2.提高数据安全性：实现数据的实时备份，确保数据不丢失。
3.提高运维效率：通过自动化运维，降低运维成本。
4.提高业务连续性：在发生灾难时，能够快速切换到备用数据中心，保证业务连续性。
三、方案架构1.双活数据中心：建设两个数据中心，一个主数据中心，一个备用数据中心。
两个数据中心之间通过专线连接，实现数据的实时同步。
2.应用负载均衡：通过负载均衡技术，将用户请求分发到两个数据中心，实现负载均衡。
3.数据库双活：采用数据库双活技术，实现数据库的实时同步。
4.存储双活：采用存储双活技术，实现存储设备的实时同步。
5.网络双活：采用网络双活技术，实现网络的实时同步。
四、方案实施1.硬件部署：在两个数据中心分别部署服务器、存储、网络等硬件设备。
2.软件部署：在服务器上部署操作系统、数据库、中间件等软件。
3.数据同步：配置数据同步软件，实现数据的实时同步。
4.负载均衡：配置负载均衡设备，实现用户请求的负载均衡。
5.监控与运维：部署监控软件，实时监控双活系统的运行状况，通过自动化运维工具，实现运维工作的自动化。
五、方案优势1.高可用性：通过双活架构，实现系统的高可用性。
2.数据安全性：实时备份，确保数据不丢失。
3.灵活扩展：根据业务需求，可灵活扩展数据中心规模。
4.运维简化：自动化运维，降低运维成本。
5.业务连续性：快速切换，保证业务连续性。
六、方案实施注意事项1.充分评估业务需求，确保方案能够满足业务发展。
银行跨数据中心数据库双活架构设计难点一：数据库双活，如何解决几十公里延时带来的性能问题？分享一：几十公里的延时主要表现在两方面，一个是存储双写延迟，一个是节点通信延迟。
从存储延时来说首先要做到本地读。
这个在GPFS文件系统里是可以做到的。
其次是增大缓存，减少同步写的次数。
对于数据库里的大对象，最好使用inline的方式放在常规表空间里，或者存放在开启了文件缓存的表空间里。
对于数据库日志，一定要设置足够的日志缓冲池，避免因为缓冲池不够发生的同步写。
在通信的延迟上，我们需要做到的是尽量减少通信。
所以要想办法解决热点数据问题。
同时能够本地访问和缓冲的都要想办法实现。
例如推荐采用客户端偏好链接。
基于current member来组织表和数据等等。
（孔再华）有个问题，由于CF节点只有一个，对于写来说，必然存在两个站点的DB2 MEMBER都同时需要通过RDMA访问CF节点GBP，本地来说，问题不存在，跨站点RDMA访问的话，这个通信耗时和性能是否需要重点关注？（邓毓）你说的非常正确，跨站点的member和CF通信需求是双活环境调优的关键。
所以这个就是重点关注的对象，要减少这种交互。
数据库提供了mon_get_cf等相关表函数能够抓取CF的功能和耗时，进而分析是什么操作最慢，能不能减少或者调整。
（孔再华）分享二：我从Oracle数据库层RAC说一下吧，个人比较喜欢用ASM，用ASM可以解决一部分性能问题，之所以说一部分是因为ASM也只能解决"读"的问题；由于距离产生的延迟，那么最好的办法就是不缩短距离，这个好像是废话，但是对于Oracle ASM的 redundancy来说其实是可以做到的，比如创建Oracle ASM的磁盘组的时候选择的是Normal redundancy的方式，那么磁盘组就会至少有2个failure group ，而我们可以把2个failure group里的物理盘手工的划分到不同的物理位置，一般双活都有2个机房，那么一个failure group里放一个机房的磁盘，另外一个fialure group里放置另外一个机房的磁盘，这样双活也就实现了，但是随即而来的问题就是物理距离的增加和光信号的衰减和传输的性能降低，Oracle ASM考虑到提升一部分功能，在参数里提供了asm_preferred_read_failure_groups这个参数，也就是说当做物理读的时候每一个机房里的节点（RAC节点）都可以配置自己优先读的“机房” ，这样可以保证“读”不受“距离”的影响，但是“写” 是必须要在双节点都完成的，所以对于ASM来说对于“写”也没有特别好的办法解决距离产生的延迟。
商业银行应用双活架构设计方案双活架构是指商业银行采用两个数据中心，并同时运行，以实现业务的高可用性和灾备能力。
在双活架构中，两个数据中心之间通过高速网络进行数据同步和交互，当一个数据中心发生故障时，另一个数据中心可以顶替其工作，确保业务的连续性。
1.数据中心的选址与建设：商业银行需要选择两个不同的地理位置作为数据中心的建设地点，以避免自然灾害和其他突发事件对两个数据中心同时造成影响。
每个数据中心应具备必要的硬件和软件设施，包括服务器、存储设备、网络设备、备用电源和灭火系统等。
2.数据同步和交互：商业银行应采用高速、可靠的网络连接两个数据中心，以实现数据的实时同步和交互。
可以使用光纤通信或者专线连接两个数据中心，确保数据的快速传输和可靠性。
同时，还要建立良好的数据备份机制，确保数据的完整性和可恢复性。
3.业务切换和故障转移：当一个数据中心发生故障时，商业银行需要快速切换到另一个数据中心继续提供业务。
为了实现业务的快速切换，商业银行应使用负载均衡器来分发流量，确保用户的请求被正确地转发到可用的数据中心。
同时，商业银行还需要建立事前制定的故障转移计划，明确各个业务系统在发生故障时应采取的恢复措施和时间目标。
4.安全性保障：商业银行应加强对双活架构的安全性保障，防止恶意攻击和数据泄露。
可以使用防火墙、入侵检测系统和安全监控工具等技术手段来加强对数据中心的安全防护。
同时，商业银行还需要制定和实施严格的安全政策和数据保护措施，加密和备份关键数据，确保数据的隐私和安全。
5.持续改进和演练：商业银行应定期对双活架构进行演练和测试，以验证其可用性和容错性。
演练和测试应包括正常业务场景和各种故障模拟，以确保在实际应急情况下能够有效地应对和处理。
商业银行还应定期评估和优化双活架构的性能和效果，并根据实际情况进行持续改进，以保持架构的高可用性和灾备能力。
总之，商业银行应用双活架构设计方案的目标是提高业务可用性和数据安全性。
商业银行应用双活架构设计方案双活架构是一种商业银行应用系统设计方案，它的特点是系统部署在两个或多个不同的数据中心，同时工作，确保系统的高可用性和灾备能力。
下面是一个关于商业银行应用双活架构设计方案的详细说明，包括架构设计、关键技术和实施步骤。
一、架构设计1.双数据中心部署：商业银行应用系统部署在两个或多个地理位置相隔较远的数据中心中。
每个数据中心都有自己的硬件设备、网络设备和存储设备，可以独立工作。
2.数据同步技术：为了保证数据的一致性，双活架构需要使用数据同步技术将主数据中心的数据实时同步到备份数据中心。
常用的数据同步技术包括异步复制和同步复制等。
3.双机热备：商业银行应用系统在主数据中心和备份数据中心都部署有完全相同的硬件和软件配置。
主数据中心发生故障时，备份数据中心可以立即接管业务。
4.负载均衡：为了提高系统的性能和可靠性，商业银行应用需要使用负载均衡设备将网络流量均匀地分发给主备数据中心。
负载均衡设备可以实时监测主备数据中心的健康状态，当主数据中心发生故障时，它可以自动将流量切换到备份数据中心。
二、关键技术1.虚拟化技术：商业银行应用可以使用虚拟化技术将服务器、存储设备和网络设备虚拟化成多个虚拟实例。
这样可以提高资源利用率，降低系统成本，并且方便进行系统迁移和扩展。
2.分布式数据库：商业银行应用需要使用分布式数据库来支持数据同步和数据一致性。
分布式数据库可以将数据分布在多个节点上，并提供统一的查询接口和事务管理机制。
3.高可用存储设备：商业银行应用需要使用高可用存储设备来保证数据的可靠性和安全性。
高可用存储设备可以提供实时数据同步、数据冗余和热备份等功能，避免数据丢失和系统中断。
4.网络安全技术：商业银行应用需要使用网络安全技术来保护系统的机密性、完整性和可用性。
网络安全技术包括防火墙、入侵检测系统和安全监控系统等。
三、实施步骤1.架构设计和规划：商业银行应该根据自身的需求和预算，制定一套适合的双活架构设计方案，并规划每个数据中心的硬件和软件配置。
商业银行应用双活架构设计方案目录一、设计原则 (3)二、充分理解目标 (4)2.1. 我们充分理解目标： (4)2.2. IT 行业发展的需求 (4)三、应用系统架构现状分析 (6)四、应用双活实现方案 (7)4.1. 不同数据中心应用双活方案 (7)4.2. 同数据中心应用双活方案 (11)一、设计原则重要业务系统应用双活项目是单位业务支撑系统建设中极为重要的一环，既要考虑系统平台的双活切换能力和系统架构的高可用,又要考虑数据层次的业务连续性，同时也要考虑单位信息系统今后几年的业务发展需求。
针对单位信息系统系统将保证业务系统的连续性来(支持 7x24 不间断运行)的特点，在此次重要业务系统双活项目中，要把系统的可靠性、稳定性、安全性和可扩展性作为本次规划的重点考虑因素。
在进行系统设计时，遵循以下原则：稳定性：稳定性是系统运行的关键，也是系统维护管理的关键因素，更是充分发挥科技骨干技术储备的关键。
安全性：系统软、硬件需具有可信赖的安全性，软件系统安全性方面应满足单位信息系统安全策略的要求，系统有严格的用户权限和密码保护设计和办法。
可靠性/可用性：系统软、硬件平台应稳定、可靠，能够满足业务系统 7x24 不间断的运行要求；具备成熟的高可用性和双活解决方案。
对数据的完整性和准确性有可靠的保证机制。
可持续发展性：所提供的技术是可持续发展的，是目前的主流技术并有长期发展的目标，能满足单位业务支撑信息系统未来几年业务发展的需求。
可扩展性：随着单位业务的不断发展、壮大，系统平台必须提供足够的可扩展能力以满足未来几年业务增长和系统扩展的需要。
可扩展性是保护用户投资的重要方面之一。
另外在系统设计时，应选择业界相关领域的主流产品，确保产品旺盛的生命力，以便充分地保护用户的投资。
易用性：系统软件平台应提供丰富的、简单的管理工具，便于管理及系统问题诊断。
开放的标准：系统软件需支持业界通用的开放式标准，降低因兼容性问题造成的问题发生率。
商业银行应用双活架构设计方案目录一、设计原则 (3)二、充分理解目标 (4)2.1. 我们充分理解目标： (4)2.2. IT 行业发展的需求 (4)三、应用系统架构现状分析 (6)四、应用双活实现方案 (7)4.1. 不同数据中心应用双活方案 (7)4.2. 同数据中心应用双活方案 (11)一、设计原则重要业务系统应用双活项目是单位业务支撑系统建设中极为重要的一环，既要考虑系统平台的双活切换能力和系统架构的高可用,又要考虑数据层次的业务连续性，同时也要考虑单位信息系统今后几年的业务发展需求。
针对单位信息系统系统将保证业务系统的连续性来(支持 7x24 不间断运行)的特点，在此次重要业务系统双活项目中，要把系统的可靠性、稳定性、安全性和可扩展性作为本次规划的重点考虑因素。
在进行系统设计时，遵循以下原则：稳定性：稳定性是系统运行的关键，也是系统维护管理的关键因素，更是充分发挥科技骨干技术储备的关键。
安全性：系统软、硬件需具有可信赖的安全性，软件系统安全性方面应满足单位信息系统安全策略的要求，系统有严格的用户权限和密码保护设计和办法。
可靠性/可用性：系统软、硬件平台应稳定、可靠，能够满足业务系统 7x24 不间断的运行要求；具备成熟的高可用性和双活解决方案。
对数据的完整性和准确性有可靠的保证机制。
可持续发展性：所提供的技术是可持续发展的，是目前的主流技术并有长期发展的目标，能满足单位业务支撑信息系统未来几年业务发展的需求。
可扩展性：随着单位业务的不断发展、壮大，系统平台必须提供足够的可扩展能力以满足未来几年业务增长和系统扩展的需要。
可扩展性是保护用户投资的重要方面之一。
另外在系统设计时，应选择业界相关领域的主流产品，确保产品旺盛的生命力，以便充分地保护用户的投资。
易用性：系统软件平台应提供丰富的、简单的管理工具，便于管理及系统问题诊断。
开放的标准：系统软件需支持业界通用的开放式标准，降低因兼容性问题造成的问题发生率。
可维护性：系统维护需要简便快捷、不需要太多的管理人员和维护。
系统可维护性十分重要，它直接决定了系统的效能、产出和用户的总体拥有成本。
系统可维护性差会导致系统效能下降、产出降低，维护成本增加，后患无穷。
售后服务技术支持：厂家能提供足够、及时的技术支持与响应，来保证应用系统良好运行状态。
在系统运行中存在着很多不确定因素，包括人为因素、自然因素等多方面原因，系统可能出现不同程度上的故障，这就要求系统用户与原厂商有着良好的配合，原厂商能够在事故发生后最短响应时间内排除故障，给系统用户以更加坚实的信心。
因此原厂商的售后服务水平和响应时间同样是系统建设的一个重要考虑因素。
成熟性：采用的技术、产品应经过实践检验，被证明是成熟可靠的，以规避风险。
在技术上要到达当前的国际先进水平。
系统的软、硬件技术是经过市场考验的，证明是成熟的技术，在相关应用中有较多的成功案例。
同时要采用先进的技术，既要满足目前的业务需求，又要充分考虑未来的发展，保证系统建成后 3 至 5 年不落后，选用符合国际标准的系统和产品，以及保证系统具有较长的生命力和扩展能力，满足将来系统升级的要求。
二、充分理解目标2.1. 我们充分理解目标：实现同机房与机房之间的应用双活，任何一个重要应用系统的服务器、磁盘阵列、交换机故障，都不会影响业务的正常运行。
任何一个重要应用系统应用的服务器、磁盘阵列、交换机故障，对该重要业务影响控制在 1 分钟以内。
2.2. IT 行业发展的需求一方面随着用户业务发展，业务层次对 IT 系统业务连续性（保证业务系统 7*24 不间断）的要求程度越来越高。
另一方面企业需要一个符合成本效益的解决方案来优化数据管理和提高数据中心对于前端业务的支持水平，而不是通过单纯地增加存储和设备去解决问题。
最后达到用户业务层次所需的动态型全天候不间断数据访问和业务数据中心的支持。
为了有效地解决这些问题，企业需要寻找一个新的更有效的数据管理方法。
这种新方法的数据管理需要具有解决几个关键问题的能力：.提高文件管理- 帮助汇集信息孤岛，冗余数据和未充分利用的分段存储。
提高性能–规划您的存储并整合新兴技术，以帮助保护您的投资。
增强可用性- 帮助满足目前每天 24 小时不间断的市场需求，缩减整个系统的停机和维修时间为“零”。
更好的自动化- 提供无缝的工作负载流程和数据管理，提高性能和应用可靠性及最终用户体验并促进生产力。
向外扩展- 改善硬件和基础设施利用率，最大限度地提高您的投资回报和保障业务在预算范围内增长。
双活系统软件能使 IT 基础架构保持灵活性、稳定性和高可用性，能够简单、动态地访问和管理硬件资源，提高资产使用率，同时利用更为智慧和简化的新方法来实现上述目标。
双活系统软件带来整合数据中心的力量，带来更高的客户价值：提供全面的数据中心愿景——智慧的业务基础架构，包括服务管理及自动化，快速实现投资价值；将关注点从基础架构效率转向业务结果：加快数据中心整合，帮助客户把更多精力集中到关键业务目标上，以便改善服务、降低成本、管理风险；通过整合及资源池的管理方式，使原本孤立的系统协同工作，释放投资价值；充分拓展并利用合作伙伴生态系统，提供完整的解决方案。
三、应用系统架构现状分析上图是当前某商业银行当前核心系统架构的现状，存在以下几个方面的问题：1、重要业务系统服务器出现问题后，切换到备用服务器需要一定的时间。
2、数据中心机房 A 出现问题后，由于数据中心机房 B 服务器平常无法打开使用，无法实现无缝接管。
3、随着业务量的增长，当重要业务系统应用服务器的压力越来越大时，无法进行横向扩展。
4、资源严重浪费，数据中心机房 2 的资源（尤其是存储）平时无法打开使用。
5、切换时间长，一般需要 1－3 小时以上才能切换到灾备中心。
6、故障情况下切换决策难，有时切换时间＋决策时间>＝灾难修复时间，难以决策，期间无法办理业务。
7、流程复杂，维护难，系统切换需要一系列管理和技术流程，维护复杂，生产、容灾端都需要维护四、应用双活实现方案4.1. 不同数据中心应用双活方案根据当前某商业银行重要应用系统系统架构的现状，同时结合某商业银行对重要应用系统双活项目的需求，该商业银行采用GPFS(General Parallel FileSystem，通用并行文件系统)的高可用方案实现此功能和目标。
结合当前应用系统以及硬件、网络环境的现状，其中共采用以下两种实现方式：不同数据中心应用双活和同数据中心应用双活。
在满足跨机房实现应用双活的硬件、网络等条件下，结合该商业银行的应用系统现状，设计了实现应用双活的系统拓扑图和功能逻辑图。
此方案实施完成后，我们可以实现以下目标：1、任何一个数据中心的应用服务器、存储、网络出现故障，另外一个数据中心可以无缝接管，应用基本不受影响。
2、两个数据中心的应用服务器同时对外提供服务，提高了应用系统整体的处理能力，同时由于灾备数据中心资源也可以同时对外提供服务，减少了资源的浪费。
3、实现了在线进行应用服务器的横向扩展。
4、系统切换演练以及维护较之前的双中心主备模式简单。
此方案简述：1、通过操作系统内的 GPFS 文件系统实现，最大程度不改变传统的物理拓扑，增加整2、体方案的安全性、可用性；3、在操作系统层次，通过 GPFS 文件系统的 failure group 功能模块将生产、灾备两个中心的两台存储虚拟为一台存储使用；4、重要应用系统构建在 GPFS 文件系统上，应用系统的其它要求和环境需求按照应用本身的实际情况设计、实施。
在存储实际情况满足的前提下，GPFS 均可满足应用服务器存储的要求；实现不同数据中心应用双活需要考虑的因素构建不同数据中心应用的双活有许多因素需要考虑，依赖于用户是否具备了实现的条件：双活数据中心之延迟和稳定性：由于光速限制，每约 120km 所产生的数据来回延迟约为 1ms。
因此，会对实际应用性能构成影响, 特别是两数据中心数据交互密切的业务。
另外，数据中心之间的网络是否容易维护和掌控。
Quorum / Tie-Breaker 之需求：为了避免双活数据中心产生脑裂(Split Brain)的状况，解决方案需要提供有效的 Quorum / Tie-Breaker 方式来保证数据完整性，最好将仲裁放在第三个数据中心。
工作负载之考虑：业务交易中，应用所产生之写操作 (INSERT, UPDATE,DELETE)比例越高，则越多数据需要跨数据中心传送。
这类型业务交易不利于双活数据中心设计。
推荐业务划分，读写分离等, 有效规避数据中心间交互的架构。
在满足构建不同数据中心应用双活的实现条件下，要实现应用的双活需要完成以下步骤：（1）现状分析：调研某商业银行重要应用系统现有的主机系统、存储系统、SAN、网络系统等的架构、配置、部署情况、关键的参数设置，以及近期的 IT 规划；通过现状分析明确基础架构、可恢复能力、应用关联关系等，评估当前环境与目标之间的差距，工作内容包括：1、对操作系统版本等系统信息进行调研和分析；2、对应用系统使用的硬件以及存储信息进行调研和分析；3、对两个数据中心之间的网络、带宽等进行调研和分析；4、对当前应用系统架构进行调研和分析；5、对应用系统使用的文件系统的容量以及每天产生的日志总量进行调研和分析。
6、对每月月初、月中、月末的系统负载进行调研和分析；7、对心跳站点的网络带宽，本地磁盘或者存储现在进行调研和分析。
（2）风险评估通过风险分析梳理在实施过程中所面临的风险场景，对可能的风险进行评估，按照风险的严重性和可能性，定义风险级别，形成风险矩阵，并提出风险应对建议。
不同数据中心应用双活架构设计结合系统现状以及高可用性需求，编制《不同数据中心应用双活总体建设策略规划建议》。
GPFS 双活实施根据双活的总体建设测试规划，完成不同数据中心机房的应用双活。
应用双活可用性测试由于不同数据中心应用双活需要第三个站点作为心跳站点，实现方式以及双活故障测试场景都比较复杂，因此我们需要根据应用双活的要求，设计各种灾难场景，完成相应的测试，形成测试报告，例如：模拟任何一台服务器宕机模拟任何一台存储宕机模拟两个数据中心之间网络故障模拟任何一台服务器的网卡故障模拟 SAN 交换机故障模拟网络交换机故障演练规划以及组织根据灾难场景与技术架构设计，制定灾难演练场景的定义、演练方式、演练范围、演练计划、演练组织架构、灾难恢复流程、操作手册及应急措施等。
4.2. 同数据中心应用双活方案如果当前的硬件环境以及重要应用系统架构无法满足不同数据中心双活的实现条件，建议采用同机房的应用双活解决方案。
以下是我们结合某商业银行的系统现状设计的同机房应用双活架构图：实现同数据中心应用双活需要考虑的因素构建同数据中心应用双活较不同数据中心应用双活需要考虑的因素较少。
