下载文档原格式
某商业银行应用双活架构设计方案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 不间断的运行要求；具备成熟的高可用性和双活解决方案。
对数据的完整性和准确性有可靠的保证机制。
可持续发展性：所提供的技术是可持续发展的，是目前的主流技术并有长期发展的目标，能满足单位业务支撑信息系统未来几年业务发展的需求。
可扩展性：随着单位业务的不断发展、壮大，系统平台必须提供足够的可扩展能力以满足未来几年业务增长和系统扩展的需要。
可扩展性是保护用户投资的重要方面之一。
另外在系统设计时，应选择业界相关领域的主流产品，确保产品旺盛的生命力，以便充分地保护用户的投资。
易用性：系统软件平台应提供丰富的、简单的管理工具，便于管理及系统问题诊断。
开放的标准：系统软件需支持业界通用的开放式标准，降低因兼容性问题造成的问题发生率。
城市商业银行双活数据中心建设方案v1.0一、背景随着金融科技的快速发展，数字化转型已成为银行业发展的必然趋势。
建设数据中心成为银行数字化转型中的核心基础设施之一。
城市商业银行（以下简称“城商行”）也在数字化转型的道路上加速前行，在数据中心建设方面也投入了大量人力和物力资源。
目前，城商行的数据中心全部在本市，为了保障业务的稳定运行，提高业务的可用性和可靠性，城商行需要建设双活数据中心。
二、双活数据中心概述双活数据中心是指银行建立两个或以上的数据中心，并通过网络技术将数据中心实现同步备份。
当一个数据中心出现故障时，其他数据中心能够迅速切换并接替故障中心的功能，保证业务的持续可用性。
同时，双活数据中心能够提高系统的容错能力和安全性。
三、建设目标城商行双活数据中心建设的总体目标是提高业务的可用性和可靠性，保障业务的稳定运行。
具体目标如下：1.建设双活数据中心，实现数据中心的同步备份。
2.提高系统的容错能力和安全性，保障业务的持续可用性。
3.保证数据中心的运行符合监管规定和行业标准。
四、建设方案1. 选址和场地准备城商行将双活数据中心选在本市经济中心区，选址应遵循以下原则：•地理位置优越，便于数据中心之间的网络通信。
•地质构造稳定，地震烈度低。
•环境优雅，无污染源存在。
场地准备应根据数据中心的设计容量和功能需求选择适当的场地，并进行场地设计和改造。
2. 基础设施建设合理的基础设施建设是双活数据中心的基础，包括配电、供电、制冷、制气、照明、安监、灭火、环境监测和机房净化等基础设施建设。
3. 系统集成系统集成是城商行双活数据中心建设的关键环节。
系统集成包括物理层、网络层、存储层、计算层、安全层等部分的集成。
在系统集成方面，城商行需要对设备和软件进行全面的测试和评估，确保系统的性能、可靠性和安全性。
4. 数据迁移和同步备份数据迁移和同步备份是城商行双活数据中心建设的重点。
数据迁移和同步备份需要严格按照规定程序进行，确保数据安全、完整、可靠。
双活数据中心解决方案-通用双活数据中心解决方案-通用一、引言双活数据中心解决方案旨在提供高可用性和容灾性能，确保业务的连续性和数据的安全性。
本文档介绍了一个通用的双活数据中心解决方案，包括设计原则、架构、网络部署、数据同步、故障切换等内容。
二、设计原则1.资源均衡利用：双活数据中心应平衡两个数据中心的负载，确保资源的均衡利用。
2.容灾性能优化：数据中心之间应保持高速、可靠的连接，以确保数据同步的实时性和正确性。
3.快速故障恢复：在数据中心故障发生时，应能够快速切换到备份数据中心并恢复正常运行。
4.数据安全性保障：数据同步时应具备数据一致性和完整性的保障措施，确保数据在传输中不会丢失或损坏。
三、架构设计1.数据中心A：作为主数据中心，负责承载业务的主要运行和数据存储。
2.数据中心B：作为备份数据中心，负责实时备份数据、提供灾难恢复能力。
3.客户端接入：客户端可以通过多种方式接入数据中心A，如私有网络连接、互联网连接等。
四、网络部署1.数据中心连接：数据中心A和数据中心B之间应建立高速、可靠的连接，如光纤链路或专线连接。
2.客户端接入网络：客户端可以通过VPN连接、专线连接等方式接入数据中心A，以实现访问业务的需求。
五、数据同步1.数据同步方式：数据中心A和数据中心B之间应实现实时数据同步，可以采用同步复制或异步复制方式。
2.数据同步工具：可使用常见的数据库同步工具，如Oracle Data Guard、MySQL Replication等，来实现数据的自动同步。
六、故障切换1.故障检测与切换：通过监控系统实时监测数据中心A的故障，并在发生故障时自动切换到数据中心B，以保证业务的连续性。
2.故障恢复流程：一旦故障发生，需要进行故障诊断、数据恢复、服务切换等一系列操作来恢复正常运行。
七、附件八、法律名词及注释1.双活数据中心：指同时运行两个互联的、相互备份的数据中心的解决方案。
2.容灾性能：指系统在面对异常情况和灾害时，仍能保持正常运行的能力。
城商行如何通过存储双活设计提升数据中心级的双活能力？为了满足银行各类新产品业务发展需求，建设可信IT，面向双活或者多活数据中心改造以及核心改造成为各中小银行的重点项目。
双活数据中心建设，需要从应用层、网络层、数据库层、存储层等多方面进行考虑，数据库和存储的双活实现息息相关，均是双活数据中心建设的重点与难点，其中存储双活无疑是双活数据中心建设的基石。
社区最近针对城商行如何实现同城数据中心存储双活以及对数据库双活的支持，邀请专家进行问诊及交流。
以下是参与交流的社区会员提出的10个典型问题，由专家和同行解答及分享经验。
1、双活中心一般建议存储异步还是同步，两种模式对于双中心距离要求为多少？@bbaimm88 某城商行存储架构师：结合非重要业务与重要业务来看，不然领导觉得你是单纯谈技术，脱离了实际。
两种模式各有特色，性价比与安全性各有特色。
@summit 某城商行系统架构师：1 、双活分应用级双活还是数据库也实现双活，如果是全双活的话，建议双中心距离不要超过100KM ，保障裸光纤链路质量不要超过 5ms 延迟。
裸光纤链路质量是双活的关键。
2 、如果只是应用级双活的话，存储和数据库的架构决定你采用什么样的复制关系。
如果采用 ADG ，一般采用最大性能方式，存储复制的话一般同步和异步都可以，如果裸光纤质量不好就采用异步复制方式。
同步方式如果裸光纤发生抖动可能造成 IO 的短暂 hung ，会对业务造成影响。
3 、存储复制异步和同步主要依据你双活的实现方式。
@吕峰戴尔科技金融行业中国西区高级系统工程师：存储双活有三种块、文件和对象。
块和文件双活都是以数据同步为前提的，对象通常是保证metadata 的同步，底层文件数据做异步传输。
同步模式下主要是看业务对延迟的最大容忍度是多少，通常存储要求往返 5ms 延迟是做块存储双活的底线，距离如果按照光速计算就很远了。
实际距离来说，欧洲有超过 500km 的 SAN 双活实施，国内基本都是50km 以内。
城商行核心业务系统同城双活建设关键点分析银行业的核心系统追求极致RPO和RTO的容灾目标，从核心系统的业务层面来看，能够实现核心系统业务在双活数据中心进行分发且自动切换从而保障业务的连续性，我们认为这样的目标就实现了应用级别的双活。
这其中需要基础架构层面很多关键技术体系的支撑，同样也会有很多的关键问题需要解决。
一、核心系统双活方案下的建设思路和方法论方面【Q1】如何从整体上考虑核心系统同城双活？【问题描述】核心系统同城双活，极大缩短了核心系统故障恢复时间，提高业务系统连续性，如何从整体上考虑核心系统同城双活，如主机，存储，数据库，负载设备，共享文件系统，网络，应用程序等？我觉得主要从以下几个层面考虑：1. 从整体架构上来看，通常关注网络层、应用层、数据库层和存储层这几个层面，对于网络层要求双中心间二层打通，实现双中心间业务引流；对于应用层，采用GTM & LTM 联动技术实现跨数据中心保护；对于数据库层，采用跨数据中心集群部署，系统保留ADG等类型的复制模式；对于存储层，通过各家厂商的存储双活技术实现跨数据中心集群部署。
2.从成本角度考虑，主要包含设备购买成本、建设成本、运维成本。
这块比较难估算，因为不同地域，不同公司资源的情况下成本会有较大出入。
设备的购买成本主要包含应用主机、存储、核心以太交换机等；建设成本包括前期规划、实验室确认参数、业务场景下业务测试、安装调试、真实环境压力测试、切换演练等方面，以上均需要人员成本的投入；运维成本取决于自动化程度的高低，通常情况下如果各节点完全可实现自动切换，相对的复杂度也有所提高，对于运维人员的技术要求有一定限制。
3.从技术成熟度和方案及方案健壮性方面来看，刚才在上面第一点中提到的四个层次所使用的关键技术，目前已经非常成熟，各厂商均有成熟的解决方案。
使用如Power上的双活方案，基于存储的双写复制的技术，数据库的基于事务日志回放的数据技术，以及基于系统级逻辑卷镜像技术，这些技术均有成熟的方案，在很多银行也有实际落地的案例，并且已经稳定运行了好多年；4.需要充分的风险评估，比如要解决数据库和存储仲裁不一致，集群发生脑裂的问题，如何解决应用负载会话一致性的问题，如何解决I/O时延，如何应对光纤抖动，如何解决资源高度冗余导致资源浪费问题。
双活数据中心方案一、需求背景：随着数据的大集中，银行纷纷建设了负责本行各业务处理的生产数据中心机房（一般称为数据中心），数据中心因其负担了全行业务，所以其并发业务负荷能力和不间断运行能力是评价一个数据中心成熟与否的关键性指标。
近年来，随着网上银行、手机银行等各种互联网业务的迅猛发展，银行数据中心的业务压力业成倍增加，用户对于业务访问质量的要求也越来越高，保障业务系统的7*24小时连续运营并提升用户体验成为信息部门的首要职责。
商业银行信息系统的安全、稳定运行关系着国家金融安全和社会稳定，监管机构也十分重视商业银行的灾难备份体系建设，多次发布了商业银行信息系统灾难备份的相关标准和指引，对商业银行灾备系统建设提出了明确的要求。
为适应互联网业务的快速增长，保障银行各业务安全稳定的不间断运行，提高市场竞争力，同时符合监管机构的相关要求，建设灾备、双活甚至多活数据中心正在成为商业银行的共同选择。
二、发展趋势：多数据中心的建设需要投入大量资金，其项目周期往往很长，涉及的范围也比较大。
从技术上来说，要实现真正意义上的双活，就要求网络、应用、数据库和存储都要双活。
就现阶段来看，大多数客户的多数据中心建设还达不到完全的双活要求，主流的建设目标是实现应用双活。
目前客户建设多数据中心的模型可以归纳为以下几种：1.单纯的数据容灾：正常情况下只有主数据中心投入运行，备数据中心处于待命状态。
发生灾难时，灾备数据中心可以短时间内恢复业务并投入运行，减轻灾难带来的损失。
这种模式只能解决业务连续性的需求，但用户无法就近快速接入。
灾备中心建设的投资巨大且运维成本高昂，正常情况下灾备中心不对外服务，资源利用率偏低，造成了巨大的浪费。
2.构建业务连续性：两个数据中心（同城/异地）的应用都处于活动状态，都有业务对外提供服务且互为备份。
但出于技术成熟度、成本等因素考虑，数据库采用主备方式部署，数据库读写操作都在主中心进行，灾备中心进行数据同步。
城商行核心业务系统实现同城双活建设及双活切换难点在线探讨众所周知，其实双活数据中心并不是一个行业标准或者规范。
行业的标准是对RTO和RPO约束，银监局和中国人民银行对商业银行业最严格的要求标准是5级容灾标准：RPO=15分钟，RTO=30分钟。
而根据国际标准Share78，六级容灾标准是：RPO=0，RTO=分钟级；七级容灾标准是RPO=0，RTO近似为0。
因此双活的概念也就由此而来，为了达到国际最高标准。
那么决策是否建设双活数据中心的依据也就在于此，首先确定自己企业合适的目标，是不是所有业务都必须追求这个目标？如果不是那么首先要对企业业务进行细分并详细规划每一个业务的容灾目标。
这将决定要不要建设双活数据中心以及建设什么样的双活数据中心。
而银行业的核心系统就是这样一个追求极致RPO和RTO的容灾目标，它是银行最为重要的系统，是生命线和底线，一旦信息科技风险越过了这条底线，银行的整个金融信息系统将全面瘫痪，后果不堪设想。
所以为了牢牢守护住这条命脉，银行一直在不断的寻求更好的技术和更优的解决方案，来对核心系统的优化之路进行探索，这其中之一便是核心系统的同城双活建设。
从核心系统的业务层面来看，能够实现核心系统业务在双活数据中心进行分发且自动切换从而保障业务的连续性。
那么我们认为这样的目标就实现了应用级别的双活。
基本上能够达到6级标准或是我们所述的应用级双活，这其中需要基础架构层面很多关键技术体系的支撑，同样也会有很多的关键问题需要解决：1、如何实现核心系统网络层面的双中心引流架构？故障场合下如何将核心外围渠道或应用系统访问核心切换或引流到同城数据中心？2、如何考量核心系统服务器层面的跨数据中心部署架构和服务器选型？3、如何实现核心系统数据库层面的跨数据中心保护？包括访问连续性保护和数据本身的保护？数据库又如何切换至同城数据中心？4、如何实现核心系统存储层面的跨数据中心复制？采用什么样的复制模式？采用什么样的复制技术等？5、Power HA切换过程中与数据库如何配合？本次活动，twt社区邀请到某城商行和浪潮商用机器的专家分享他们的实践经验，同时会在社区与大家进行线上交流。
银行同城应用级双活建设最佳实践当前核心系统基础架构平台建设中面临着纷繁复杂的技术架构和技术选型，给建设者和领导层造成很多困扰，要更好的建设银行核心架构，需要对一些关键技术以及选型问题进行深入探讨。
为此，社区组织了一系列相关活动，邀请行业专家进行分享交流，为同行在选型以及方案设计方面提供借鉴和参考。
以下是不久前在长沙举办的“银行新核心系统建设技术路线选型及如何实现同城应用级双活线下交流探讨”中，专家同行们针对某银行、某省农信的实践分享和厂商解决方案进行的重点探讨。
1、异构数据库数据同步方式如何选择？答：异构数据库同步根据异构数据库的类型和同步方式而定。
2、应用场景分布式，需要打通双中心大二层后延时多少？答：打通大二层，视两个中心间距而定，同城理论上100KM，往返延时在1MS左右，但实际环境可能会更高些，已经和存储的读写访问时延在同一个数量级了，间距越大，性能影响越大，通常控制在100KM以下。
3、贵行同城双活现状如何？应用哪些技术？同城灾备建设的基本情况？同城灾备自动化切换如何做？双活数据库是两边双写吗？双写系统有哪些？答：目前我行同城应用双活已经应用较为广泛，很多关键渠道类、平台类的业务系统都实现了同城应用双活。
应用负载层采用了两种方式实现生产和同城应用的请求负载均衡，第一种为跨中心应用负载分发的方式，请求从生产数据中心进入，由生产端的应用负载将请求均衡分发到两个数据中心的应用节点，回报文时再原路返回的模式，也就是所谓的单数据中心进，单数据中心出的方式；第二种为跨中心请求负载引流的方式，请求先通过域名解析，按照一定的策略（运营商、地域等）将请求引流至两个数据中心，两个数据中心各自配置独立的网络和负载均衡设备，由本地负载均衡设备负载至本地应用节点，回报文时再原路返回的模式，也就是所谓的两个数据中心进，两个数据中心出的方式。
应用层采用分布式应用集群架构，应用节点分布在生产和同城两个数据中心，对于应用节点间需要共享非结构化数据，可以采用多种方式实现，如存储双活、并行文件系统、双活NAS、对象存储等，根据应用对共享的非结构化数据的性能和数量级需求而定。
商业银行应用双活架构设计方案目录一、设计原则 (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. 同数据中心应用双活方案如果当前的硬件环境以及重要应用系统架构无法满足不同数据中心双活的实现条件，建议采用同机房的应用双活解决方案。
以下是我们结合某商业银行的系统现状设计的同机房应用双活架构图：实现同数据中心应用双活需要考虑的因素构建同数据中心应用双活较不同数据中心应用双活需要考虑的因素较少。
