城商行核心业务系统同城双活建设及切换的16个难点
为此，twt社区邀请到了全国各地20余名银行IT技术专家和架构师，以及来自浪潮商用机器的专家，线上分享他们的实践经验，大家互问互助，共同答疑解惑，可谓十分精彩。本文是对这次交流活动的内容梳理和总结，内容包括：建设思路和方法论、数据保护和存储层复制、链路和负载引流、服务器选型、容灾切换等，希望对大家有所帮助。总结整理：邓毓
一、核心系统双活方案下的建设思路和方法论方面
【Q1】如何从整体上考虑核心系统同城双活？
【问题描述】核心系统同城双活，极大缩短了核心系统故障恢复时间，提高业务系统连续性，如何从整体上考虑核心系统同城双活，如主机，存储，数据库，负载设备，共享文件系统，网络，应用程序等？
【A1】ZTC 浪潮商用机器企业云创新中心 售前技术支持：
我觉得主要从以下几个层面考虑：
1. 从整体架构上来看，通常关注网络层、应用层、数据库层和存储层这几个层面，对于网络层要求双中心间二层打通，实现双中心间业务引流；对于应用层，采用GTM & LTM 联动技术实现跨数据中心保护；对于数据库层，采用跨数据中心集群部署，系统保留ADG等类型的复制模式；对于存储层，通过各家厂商的存储双活技术实现跨数据中心集群部署。
2.从成本角度考虑，主要包含设备购买成本、建设成本、运维成本。这块比较难估算，因为不同地域，不同公司资源的情况下成本会有较大出入。设备的购买成本主要包含应用主机、存储、核心以太交换机等；建设成本包括前期规划、实验室确认参数、业务场景下业务测试、安装调试、真实环境压力测试、切换演练等方面，以上均需要人员成本的投入；运维成本取决于自动化程度的高低，通常情况下如果各节点完全可实现自动切换，相对的复杂度也有所提高，对于运维人员的技术要求有一定限制。
3.从技术成熟度和方案及方案健壮性方面来看，刚才在上面第一点中提到的四个层次所使用的关键技术，目前已经非常成熟，各厂商均有成熟的解决方案。使用如Power上的双活方案，基于存储的双写复制的技术，数据库的基于事务日志回放的数据技术，以及基于系统级逻辑卷镜像技术，这些技术均有成熟的方案，在很多银行也有实际落地的案例，并且已经稳定运行了好多年；
4.需要充分的风险评估，比如要解决数据库和存储仲裁不一致，集群发生脑裂的问题，如何解决应用负载会话一致性的问题，如何解决I/O时延，如何应对光纤抖动，如何解决资源高度冗余导致资源浪费问题。这些都需要在企业架构范围内考虑，也并不是所有问题都能在技术层面解决；
5.除此之外，还需要考虑功能拓展性问题，对于功能的拓展性，以业务功能拓展性来说，当前设计的双活架构应不仅仅适用于核心系统，也适合支持未来其他重要的业务系统使用。
【A2】杨宇 浪潮商用机器企业云创新中心 系统架构师：
这问题比较宏观，同城双活概况上来讲要考虑的层次有：1、网络层；2、应用层；3、数据库层 - 存储层。这几层的实现难度是不同的，通常网络层和应用层比较容易实现，成熟的产品和方案也比较多，因为这两层只分发请求，不处理请求，比较容易横向扩展，也基本不存在相互间需要同步数据的问题。问题中的负载均衡设备，网络DNS调度、应用横向部署等基本都在这层解决。数据库层双活，就涉及到问题中提到的数据库和共享文件系统等问题，这些也有成熟的解决方案，比如数据的Extend RAC、分布式文件系统、GPFS等数据同步，但从这层开始就设计节点间数据同步的问题了，就需要根据实际的需求和成本的评估进行技术的取舍。比如线路不稳定、带宽不够等因素就不适合做同步双活和复制。存储层的数据复制，在各厂家的中高端存储中是都能实现的，也要根据线路，距离等因素抉择复制的方式。
【Q2】俗话说：“三分技术，七分管理”，在规划、架构核心系统同城双活时，对运维、管理人员有哪些要求？
【A1】light_hu86 某省金融 系统工程师：
在技术转为自动化、智能化的今天，对人员要求也是越来越高，虽然部分工作机器能进行替代，但无法全部替代，因此对于运维、管理人员来说，明确此趋势，还是要从以下几点进行考虑：1、明确队伍组成，分工、人才储备、确定管理人员，一个队伍合适的管理是关键；2、技术的储备，运维人员从运维出发，相关的技术都需要了解，以及快速处理相应的故障；管理人员则需对顶层规划、业务流程、相关技术进行了解，把握趋势；3、排好计划，什么时间点做什么事情，进行相应的时间和进度管理。
【A2】zzy3620 北部湾银行 系统环境管理：
对于管理人员，需要根据项目的时间要求做好任务的分配和实施进度的把控，尽量让自己的人能做到技术上集体讨论，群策群力，不区分专业全流程参与。建议运维的人从架构设计的时候就全程参与，包括后续的详细规划例如分区的安装、网口和网络的规划、操作系统数据库的安装，参数优化，容量的规划，只有对架构和实施都比较熟悉的人，才能做好整体的运维，临危不乱。
【Q3】双活带来连续性提升的同时，可能某些场景下降低系统可用性，同时增加系统复杂性和提供运行成本。双活如何建设，如何拿捏好各系统平衡点？
【A1】zzy3620 北部湾银行 系统环境管理：
双活带来连续性提升的同时，往往因为需要对远端进行数据复制造成一定的性能损耗，这个性能损耗视不同的复制方式会有区别，如果采用异步模式则基本可以忽略。对于重要的应用系统，需要把数据安全性和系统连续性摆在第一位的，宁愿多花一些成本去强化硬件平台、优化软件设计和代码以提高系统性能，补足双活带来的性能消耗。
【A2】杨宇 浪潮商用机器企业云创新中心 系统架构师：
双活是一个建设目标，但从城商行用户的实现角度来看，并不是一步到位的。平衡点一方面是建设和维护成本与希望达到的RTO和RPO间的平衡，另一方面是技术复杂性带来的衍生不确定性增多和人为可控之间的平衡。目前看，双中心实现数据级主备中心或者 双中心在不同业务上互为主备实现起来相对成熟，成本也可控。真正的业务层面双活，对业务读写比类型以及线路要求都较高，客户处于探索阶段的比例较大。
【Q4】核心业务系统同城双活建设如何解决业务高并发与双活带来的性能影响之间的矛盾？
【问题描述】如题，核心业务系统日间高峰期业务并发高，压力大，响应时间要求高，日终批量业务对数据库的增删改操作多，如果建设了核心业务系统双活，势必带来一定的性能影响，如何有效解决或者缓解该问题是建设核心业务系统同城双活的重要问题。
【A1】zzy3620 北部湾银行 系统环境管理：
双中心架构如果采用extend rac，则关键在于减少跨中心节点间的gc，要做好应用功能的区分，尽量避免出现应用向两个不同数据中心rac节点读写同一张表的的情况。对于跑批类的应用，应当尽量指定连接固定的vip，而不是scan ip，这样能提高跑批的效率，也能避免出现gc，从而提高整体响应速度。
【A2】杨宇 浪潮商用机器企业云创新中心 系统架构师：
考虑业务建设双活架构，有几个需要注意或规避的问题，其中之一就是写操作特别多的业务是不太适合做双活的。至少在当前普遍的线路成本和线路质量的条件下，不是很适合。大量频繁的写操作，在双活的需求下需要实时同步到同城中心，即使是在线路带宽够的情况下，临时的抖动也会因为对端确认不及时带来业务的响应时效增加而性能下降，这个问题非常依赖于稳定的线路质量。
【Q5】分布式架构的系统如何双活？
【问题描述】随着互联网业务的发展，分布式架构在银行业信息系统应用越来越广泛，分布式架构双活如何考虑？单套扩展还是双套并行，单套扩展是否会有网络流量压力，并行如何解决缓存问题等等？
【A1】light_hu86 某省金融 系统工程师：
双机房网络质量还是需要保障的，目前我中心双机房为80-100公里，延时大概为5毫秒左右，相应的双活如对延时比较敏感，实现效果较差。
【A2】zzy3620 北部湾银行 系统环境管理：
个人感觉一套还是两套运行，主要需要考虑的还是网络质量，如果网络质量有保证，单套扩展的架构属于双中心的紧耦合架构，架构上比较简单清晰，双中心间的业务分发策略、业务间的访问关系配置也相对比较简单，但是单集群的风险在于如果网络出现明显抖动，可能带来的是整个集群的性能下降或者卡顿。双中心松耦合，部署两套集群的缺点就在于部署比较麻烦，双中心的业务间访问关系配置较为复杂，负载均衡分发策略相对复杂，优势就在于即使一个集群出现问题，也还有一个集群能继续提供服务。
【A3】李松青 浪潮商用机器企业云创新中心 软件架构设计师：
分布式架构下，多副本数据读写各节点之间传输本身会有很大的网络传输要求。所以一般分布式建设双活时，也是建同城双活，把其中1个或少数副本 同步到双活备中心，同城备中心一般只承载少量查询业务。你说的双套并行一般是一套主生产中心，远程建一套异步（非同步）复制的容灾环境。
【A4】杨宇 浪潮商用机器企业云创新中心 系统架构师：
分布式架构的双活，目前看更多的还是依赖于其自身的多副本部署策略。看各家的方案中，单套拉伸距离进行扩展的居多。对两中心之间的网络质量需求比较高。
二、核心系统双活方案下的数据保护和存储层复制方面
【Q6】如何实现核心系统数据库层面的跨数据中心保护？包括访问连续性保护和数据本身的保护？数据库又如何切换至同城数据中心？
【A1】 summit 城商行 系统架构师：
首先这个问题标题覆盖不全。1、首先数据库的保护无非几种，1）通过备份软件进行数据定期备份。2）通过存储底层数据复制进行灾备数据保护。3）通过数据库本身的备份机制进行数据保护（比如Oracle ADG OGG、MySQL的副本方式）。4）数据库双活灾备保护（此方式不能防止数据库逻辑损害，一般结合备份进行数据保护）。2、切换同城数据中心（你的核心是双活或者读写分离还是主备方式，这个很重要，不同的应用灾备方式切换的步骤都不一样）结合应用和数据库部署方式有N种组合和切换步骤。
【A2】fengjian 浪潮商用机器企业云创新中心 系统工程师：
以PowerHA SystemMirror HyperSwap双活方案为例：PowerHA SystemMirror 企业版提供 HyperSwap 功能实现数据中心双活功能。PowerHA HyperSwap 是基于 POWER 平台及 DS8K Metro Mirror 同步复制技术，当主存储系统不可访问时 ，AIX 透明地将磁盘 I/O 切换到备存储 , 并且不影响正在运行的应用，从而提供数据中心之间 ( 或数据中心内 ) 存储高可用及应用高可用的一种容灾方案 , 也是 POWER Active-Active 解决方案的重要组成部分。PowerHA HyperSwap 能与 OracleRAC 完美结合，实现数据库无中断的快速切换，与传统解决方案相比，其切换更加自动化、 RTO 更短， RPO 为 0 。PowerHA HyperSwap 双活解决方案具有明显的优势：监控从应用到存储各个层面，并提供每个层面故障处理方案；结合 DS8K Metro Mirror, 保证高性能及数据传输稳定可靠；支持部署 Oracle Extend RAC ，实现真正意义的双活中心；充分利用双中心的服务器、存储资源；RTO 为秒级， RPO=0; 一键完成高端存储容灾演练，应用不受影响；可设置当脑裂或站点故障发生时自动响应或人为干预策略。
【A3】邓毓 江西农信 系统工程师：
1、核心系统数据库层的跨数据中心保护要建立全面多层次的保护，包括底层存储级复制、数据库级复制、数据备份，三位一体，防范各种类型的故障。
2、连续性数据保护又叫CDP，属于数据备份的一种，通过一次性全量同步底层存储数据和实时增量捕获数据来实现小间隔时点数据的恢复，这是一般的备份做不到的，一般的备份RPO太大，满足不了小间隔时点的恢复要求，这时就要用到CDP去做。
3、数据库切换按照数据复制的方式不同而不同，若是底层存储级复制，必然是要经历生产端先停止应用和数据库、卸载存储盘、等待生产和同城数据完全一致、复制关系反转、同城端挂载存储盘、启动数据库和应用等过程；若是数据库级复制，则要经历停应用、切换数据库主从关系、挂载对外服务IP、启动应用等过程。
【Q7】同城双活核心系统数据一致性宜采用数据库同步模式还是底层存储同步模式？是否有必要同时采取两种模式？
【A1】邓毓 江西农信 系统工程师：
作为银行的核心系统，我觉得完全有必要同时采取两种模式：1、底层存储同步是块数据的物理一致性保证，保证了数据级容灾需求。但同城端的这份数据不可读不可写，要利用起来需要再对该数据卷进行快照挂载使用。2、数据库同步模式是通过事务日志的方式再写一份日志到同城端，保证了数据的逻辑 一致性，且在同城端是可读的，这也是数据读写分离的经典方式。3、块数据的物理一致性无法保证数据的逻辑一致性，真正面向业务的数据必须是逻辑一致性的，所以为了最大限度的保障数据安全性，有必要再做一份数据库级的同步。4、数据库级的复制覆盖面不全，只能涉及到事务级别的数据，其他文件系统中的文件数据覆盖不了，所以这部分数据就必然要用到底层的块数据同步。5、数据库级的复制需要消耗一定的主机性能，而且实施起来麻烦，需要停机。而底层存储复制实施比较简单，可在线实施，不消耗主机性能。
【A2】李松青 浪潮商用机器企业云创新中心 软件架构设计师：
个人完全同意前面专家的说法，同城双活核心系统有必要同时采取数据库同步和存储底层同步两种模式。也还要看数据中心所具备的条件和人员技术储备情况，来选择具体方案。
1. 如果具有同城几十公里内非常稳定且带宽足够的网络条件，那可以按照一步到位的真正A-A双活、同城数据中心同时读写(Extended RAC or PureScale GDPC) 各承担一部分业务来建设。这种情况下，可以优先考虑数据库同步模式的数据库双活方案。而底层存储同步模式作为更远距离的备份容灾方案，至于是做成同步还是异步的存储级备份容灾方案，同样取决于传输延迟和带宽条件（当然这里用DG或HA/DR等数据库方案取代底层存储复制也是可行的）。当然数据库上drop table, delete数据误操作之类的逻辑错误，首先得靠制度保障，其次得依赖数据库层面的闪回技术来做为一道保障。
2. 如果同城带宽和延迟 达不到生产数据库高峰时产生日志和变化数据量需求，那应该优先选择存储底层同步技术，主生产中心负责全部业务，同城中心作为备中心随时待命 准备接管可能发生故障的生产中心。此时数据库同步技术也可以做为辅助手段（DG 或 HA/DR），多做一个数据库同步或者准同步的日志备份，万一底层存储复制技术因为数据逻辑一致性问题（出现概率低，但理论上有潜在可能），可以用作第3个应急接管预案。
【Q8】生产同城相距30公里，数据库层，能否实现双中心同时读写一体化？
【问题描述】读写一体双活，拿Oracle来做解释，是Oracle中大家比较熟悉的Oracle extend RAC。这种方案很多存储厂商曾经推广过，Oracle厂商最近很少推荐。这种方案也被很多用户认为是一种理想化的双活解决方案。很多人认为这才是真正意义上的“双活”。
人民银行发布“金融行业信息系统信息安全等级保护实施指引”中对于三级等保的系统提出了：对于同城数据备份中心，应与生产中心直线距离至少达到30公里,可以接管所有核心业务的运行；对于异地数据备份中心,应与生产中心直线距离至少达到100公里；RTT：光被目的端 “镜子”反射回源端的延时。相对论定律：宇宙最高速度——真空光速恒定30万公里。光纤折射率1.5,光纤光速 = 300,000 / 1.5 = 200,000公里/秒。30公里光纤RTT = 2X30 / 200,000 = 0.3ms，此延时受物理定律限制，不可缩短，和钱无关，和技术进步无关。
我们通过Oracle 数据库环境下的测试可以发现，Oracle数据库中，链路每增加0.5ms的延迟，查询会增加4倍差距。拿Oracle 远距离集群举例：Oracle集群远程双活部署会引起“块争抢”的问题：一个块含很多记录,即便两节点(服务器)同时访问不同记录,也可能出现访问同一个块的“块争抢”，引起锁、等待、块属主变更、更新本地缓存等操作。节点和存储分布在远程时，网络延时1ms数量级，争抢解决慢，影响性能非常大。(若节点和存储都在本地,网络延时0.01ms数量级,争抢影响性能小) 通常通过“分割”解决“块争抢”，例如：常用分割方法是按应用或表分割。每个站点只访问自己的数据，减少块争抢。但是这并不能完全避免争抢问题，通常为提高可用性Oracle厂商推荐“读写分离双活”的方案，把所有数据在每个站点本地存放一份，更新本地数据，并在另一站点复制出副本。这样，一站点故障，另一站点都能迅速负担全部负载。副本数据可以用于且仅用于读取。例如ADG、OGG等方案，目的是各部分松耦合，简洁，可用性和性能易于管理。远程不同于本地，本地集群部署的成功案例比比皆是，但是远程并行集群通过集群信息连续同步复制，将遥远的东西紧耦合，复杂，可用性和性能难于管理，可靠性低于本地并行集群。光速有限，造成：同步复制 + 远程 = 慢动作，所以能否实现远程“读写一体双活”呢？
【A1】李松青 浪潮商用机器企业云创新中心 软件架构设计师：
完全赞同您说的“ 光速有限，造成：同步复制 + 远程 = 慢动作 ”说法。人民银行这个三级等保的系统要求，同城数据备份中心至少30公里， 异地数据备份中心与主生产至少100公里，也许正式是考虑到这方面因素。让大家可以有这样的可行方案选择：同城几十公里距离内，建真正双活数据中心。其中查询业务可以利用数据库双活方案中优先读本地存储的亲和性策略，从哪侧发起的SQL查询就从哪一侧存储上查询数据；但增/删/改因为是同步写双中心，必然后链路距离影响，但从今年已实施案例来看，30-70公里距离的居多，写延迟带来的交易延迟也一般也在可接受范围内；异地（>100公里）建议异步备份容灾中心，利用数据库日志异步复制的方式，或者底层存储同步方式，复制到远端。为降低对主生产中心的冲击，可以考虑从同城备中心异步复制到异地中心。
【A2】bbaimm88 银行 系统架构师：
生产相距30公里了， 光纤挖地施工长度肯定远大于30公里吧，（沿路街道、桥梁），传统数据库真心做不好 双活。Extend RAC 更新频繁情况下 集群cache 太难受了；长距离很难避免链路抖动，频繁抖动DBA只能被动挨打，难一体化读写。分布式数据库二阶段提交完全可能。长距离 Extend RAC 我的构想是主中心 两个节点 通过负载均衡来写，主中心 加的是写锁 ， 备中心节点 仅做做读取，备中心加的是读锁 。这种伪双活可以尝试。长距离是个难活的生意。
【A3】zzy3620 北部湾银行 系统环境管理：
当数据库节点之间出现较多gc等待事件的时候，表现慢的不光是跨节点访问的那些表，数据库的整体表现都是受影响的。因此在extend rac架构下即使一边是纯写入操作，另一个中心纯粹的读操作，如果造成的gc很高的话，仍然是会有数据库性能下降的问题的。。之前有运营商的朋友用过类似架构，后面改成直接关闭另个一中心的数据库，减少跨中心gc，这个架构主要就用于做切换演练的时候用了。
【A4】杨宇 浪潮商用机器企业云创新中心 系统架构师：
您说的非常对，光速有限。完全的读写双活一体，是应用双活+数据库双活+数据存储双活，目前影响这种架构实现的比较大的困难就是数据库双活和数据存储双活。距离过远，即使线路稳定，也会有较大的延时，就会对数据库的双活造成影响，也会对读写一体双活造成影响。
三、核心系统双活方案下的链路及负载引流方面
【Q9】同城双活链路抖动的时候会不会丢数据？如何解决这个问题？
【A1】zzy3620 北部湾银行 系统环境管理：
这个要看采用的是什么复制技术，比较成熟的例如存储间复制，或者adg的复制，链路的抖动都会带来复制的卡顿和延迟，但是不会造成数据的丢失，在链路恢复正常后，延迟同步的数据还是会继续同步到备库或者存储的目的端去的。链路抖动比较严重时，反应在数据库的主库或者存储主节点上，可能会出现无法写入的情况，从某种程度上来说，系统管理员在遇到链路的抖动的时候宁愿选择直接把复制链路断开，变成异步复制模式，来换取主库或者存储读写节点的平安。
【A2】 ZTC 浪潮商用机器企业云创新中心 售前技术支持：
抖动通常是不可避免的，即便是运营商提供质量再好的裸光纤连接，还是或多或少会存在抖动。如果频率不是很高，不至于引起网络长时间超时的话，都属于在可控范围内。理论上每100KM距离，RTT往返延迟为1MS，但一次通讯，往往会存在多次RTT，所以带来的延迟是不可避免的。网络上最好还是基于TCP协议的数据同步，利用重传机制，保证数据的在一定时间窗口还是能够传输过去。
【A3】杨宇 浪潮商用机器企业云创新中心 系统架构师：
存储复制过程中链路的抖动不会丢数据，抖动结束后数据会追齐！
【Q10】双活环境DWDM配置经验，如何配置防止运营商线路抖动影响波分承载线路？
【A1】zzy3620 北部湾银行 系统环境管理：
关于DWDM配置没法阐述的很细致，大体方案有两个，如下图：
【Q11】双中心如何解决脑裂问题，有哪些常用的措施？
【A1】zzy3620 北部湾银行 系统环境管理：
不管是数据库集群脑裂还是存储集群脑裂，所有的脑裂主要都是把握好仲裁方案，比较笨的办法就是在面临有风险的仲裁决策时，强制指定其中一边为主，并且完全关闭另外一边，强制所有的应用都连接到被强制设置为主服务的节点。另外一边关闭后断开网络修复，等确保完全修复后才开启网络。
【A2】fengjian 浪潮商用机器企业云创新中心 系统工程师：
为了避免双活数据中心产生脑裂(Split Brain)或场地分割(site isolation) 状况，需要提供有效的仲裁方式来保证数据完整性，通常是建立第三个中心作为仲裁。有部分双活方案中可以设置当脑裂或站点故障发生时的自动响应或人为干预策略，比如PowerHA SystemMirror 企业版提供 HyperSwap 功能。PowerHA HyperSwap 基于 POWER 平台及 DS8K Metro Mirror 同步复制技术，提供数据中心之间 ( 或数据中心内 ) 存储高可用及应用高可用的一种容灾方案 , 也是 POWER Active-Active 解决方案的重要组成部分。
【Q12】如何实现核心系统网络层面的双中心引流架构？故障场合下如何将核心外围渠道或应用系统访问核心切换或引流到同城数据中心？
【A1】light_hu86 某省金融 系统工程师：
目前核心一般都为主备方式，前台的应用可以实现双活，通过流量分发的形式实现双机房流量的引流，当某一机房发生问题时可将相应的流量引流至另一机房，实现业务的无感。
【A2】杨宇 浪潮商用机器企业云创新中心 系统架构师：
我理解这个问题有两种可能：第一，对于任意一个应用系统而言，都仍然是部署在一个中心，另一个中心是数据或应用级的备份。这样的话，是通过故障时DNS的重新指向引流到备中心的，或手工或通过策略。第二，如果应用层已经是双中心部署，同时对外提供服务。则是利用GTM根据负载和设置的策略进行双中心的导流。
【A3】zzy3620 北部湾银行 系统环境管理：
可以通过跨中心的负载均衡GTM实现，策略配置成双中心的应用同时双活或者配置成本中心的应用全部故障时将业务转发到同城的应用服务器上。
四、核心系统双活方案下的服务器选型及Power平台优势方面
【Q13】如何考量核心系统服务器层面的跨数据中心部署架构和服务器选型？
【A1】zzy3620 北部湾银行 系统环境管理：
主要是考虑清楚平台的选择，是unix还是linux，如果是linux，可选择面很广例如普通X86和数据库一体机都可以，如果追求稳定性，建议就在中端小型机里面选择，故障率相对还是低一些。银行业的核心数据库服务器，还是建议选择比较稳定的平台，少折腾。
【A2】bbaimm88 银行 系统架构师：
你这个要的结合你的核心应用来定。核心是单体的，还是集群的，或者分布式。单体集中式架构，就选Unix 平台吧，稳定性好，非集中式的架构，你的数据库建议选高端服务器， 应用可选性比较强了，在X86平台，可以物理机堆叠部署， 也可以虚拟化部署， 应用调度上建议上负载均衡，能够很轻松实现切换调度
【A3】杨宇 浪潮商用机器企业云创新中心 系统架构师：
目前我们看到城商行级别最核心的一类和二类服务器，选择成熟稳定UNIX小型机的用户还是占大多数。原因在于小型机架构部署核心应用，安全稳定且成功案例丰富。考虑到跨数据中心的容灾和双活，小型机配合存储及数据库层的解决方案也众多，可以比较全面地满足用户从本地高可用、到数据同步、再到应用双活的需要。从性能和稳定性上来说，小型机也都优于X86或主机的Linux平台。
【A4】fengjian 浪潮商用机器企业云创新中心 系统工程师：
核心系统特别是核心数据库对业务连续要求高，建议考虑两地三中心方案，有条件的话采用同城双活，但是注意同城中心间的网络延迟和稳定性，延迟高会影响性能，另外要防范脑裂，建议有第三中心作为仲裁。不具备条件或不需要双活的，可以做站点间的互备，提高资源利用率。服务器选型上来说，核心系统对性能、高可靠性都有比较高的要求，这方面K1 Power比X86还是有明显优势的，另外Power上的高可用、容灾方案比较多，案例也多，更成熟可靠
【A5】 ZTC 浪潮商用机器企业云创新中心 售前技术支持：
Power 架构经过几十年的不断完善，目前已经形成了以 PowerHA SystemMirror 和 VM Recovery Manager 为基础，兼顾关键业务和非关键业务的高可用 / 灾备解决方案。PowerHA SystemMirror ， Power 平台上稳定、可靠的 HADR 方案，可满足多种高可用、容灾需求（主备 / 同城异地容灾 / 双活）。适用于关键工作负载。Power 平台上支持 PowerHA HyperSwap 、 DB2 purescale GDPC 、 Oracle Extend RAC 、基于存储的双活、 IBM Db2 Mirror for i 等多种成熟的双活方案。都有实际落地的案例可以供其他银行参考。
【Q14】Power平台在建设核心业务系统同城双活方案中有何独特优势？
【问题描述】Power平台的方案，相较于非Power平台的方案，在应用层、数据库层、虚拟化资源池层或者与存储的相互结合方面，有何独特的优势所在？
【A1】zzy3620 北部湾银行 系统环境管理：
应该说power平台目前最为适合还是在数据库层使用，关键优势是其稳定性，小型机内关键组件的在线维护能力，相比x86服务器还是高出不少，故障率相对较低，并且多数故障可以在线维护，降低停服风险。应用层面现在使用x86进行虚拟化后部署集群已经是非常成熟的方案了。
【A2】light_hu86 某省金融 系统工程师：
一般power平台主要用在数据库上，优势主要体现在：1、节省设备上，之前power主备两台实现数据库，现在换成x86需一主一备两从的方式，还要分库分表，一下子设备就上去了，带来的管理和维护的难度加大；2、设备稳定上，相比x86来说，power设备较稳定，出现故障几率也较小。
【A3】 ZTC 浪潮商用机器企业云创新中心 售前技术支持：
PowerHA SystemMirror 企业版提供 HyperSwap 功能实现数据中心双活功能。PowerHA HyperSwap 是基于 POWER 平台及 DS8K Metro Mirror 同步复制技术，当主存储系统不可访问时 ,AIX 透明地将磁盘 I/O 切换到备存储 , 并且不影响正在运行的应用，从而提供数据中心之间 ( 或数据中心内 ) 存储高可用及应用高可用的一种容灾方案 , 也是 POWER Active-Active 解决方案的重要组成部分。PowerHA HyperSwap 能与 OracleRAC 完美结合，实现数据库无中断的快速切换，与传统解决方案相比，其切换更加自动化、 RTO 更短， RPO 为 0。
PowerHA HyperSwap 双活解决方案具有明显的优势：
监控从应用到存储各个层面，并提供每个层面故障处理方案；结合 DS8K Metro Mirror, 保证高性能及数据传输稳定可靠；支持部署 Oracle Extend RAC ，实现真正意义的双活中心；充分利用双中心的服务器、存储资源；RTO 为秒级， RPO=0; 一键完成高端存储容灾演练，应用不受影响；可设置当脑裂或站点故障发生时自动响应或人为干预策略。
【A4】杨宇 浪潮商用机器企业云创新中心 系统架构师：
可以参照下图，Power平台无论在单数据中心内的高可用，还是双中心容灾，以及双中心双活架构下，都有众多的解决方案。在虚拟化和云的方案中，VM Recovery Manager方案可定制事件触发的自动化脚本，实现自动处理。Live Partition Mobility 和 Remote Restart的结合，可以全面实现计划内和计划外的停机保护，实现RTO为0，RPO秒级。
【Q15】Power HA切换过程中与数据库如何配合？
【A1】杨宇 浪潮商用机器企业云创新中心 系统架构师：
将数据库的启停命令分别写到启动脚本和停止脚本中，在PowerHA中调用启停脚本来执行数据库的启停。
【A2】 ZTC 浪潮商用机器企业云创新中心 售前技术支持：
一般是配置PowerHA的启停脚本，另外PowerHA也支持通过monitor脚本对数据库和应用的状态进行监控，当发现异常时也可以进行切换。
【A3】zzy3620 北部湾银行 系统环境管理：
个人认为只要应用支持短连接或者自动重连，数据库的RAC方案在连续性方面相对优于HA，HA切换必然有数据库的关闭和启动过程，特别是对于体量比较大的数据库，重启一次可能时间会更长
【A4】邓毓 江西农信 系统工程师：
PowerHA切换过程中在释放资源组前后，可以通过设置停止脚本和启动脚本，脚本里分别编写停止和启动数据库的命令，并在POWERHA的应用资源中设置好启停脚本的路径等内容，这样在POWERHA切换时，就会按照运行停止脚本，释放资源组，切换资源组，接管资源组，运行启动脚本的步骤，和数据库完美衔接。
【A5】light_hu86 某省金融 系统工程师：
对于PowerHA结合db2数据库来说，将启停应用的步骤进行脚本化，并将脚本路径配置在HA之中，一旦发生切换会结合脚本进行相应的应用启停。
五、核心系统双活方案下的容灾切换方面
【Q16】核心业务双活切换需要考虑哪些因素？城商行核心业务切换需要考虑哪些因素？
【A1】zzy3620 北部湾银行 系统环境管理：
个人理解双中心切换前可能需要注意的点包含如下：切换的系统范围、网络分发策略、域名解析、安全策略、切换相关系统在切换到后另一个中心后的硬件资源情况、系统并发能力、切换后一些特定的定时任务、备份任务。
【A2】杨宇 浪潮商用机器企业云创新中心 系统架构师：
您谈到了双活，同时还有业务切换，那么我理解还是主备的模式，不然完全的双活系统就不存在切换的问题。核心业务切换，前提一定是业务的分级和分组之后的切换，不然只是某个业务切换了，其他的相关业务还留在原中心，这样的切换也没什么意义。至少要保证一组相关的业务一起切换。如果是两中心距离不远，SAN可以直接打通，两边各自可以看到对端的存储。风险把控涉及的方面比较多，如提前准备好必要的切换策略、切换流程、以及切换后验证文档。
原题：“城商行核心业务系统实现同城双活建设及双活切换难点活动”24个典型问题总结更多交流内容可点击阅读原文 觉得本文有用，请转发、点赞或点击“在看”，让更多同行看到
资料/文章推荐：
欢迎关注社区 "同城双活"技术主题 ，将会不断更新优质资料、文章。地址：
https://www.talkwithtrend.com/Topic/38573
长按二维码关注公众号
*本公众号所发布内容仅代表作者观点，不代表社区立场