城商行核心业务系统同城双活建设及切换与存储跨中心双活建设难点.docx

《城商行核心业务系统同城双活建设及切换与存储跨中心双活建设难点.docx》由会员分享，可在线阅读，更多相关《城商行核心业务系统同城双活建设及切换与存储跨中心双活建设难点.docx（26页珍藏版）》请在课桌文档上搜索。

1、银行业的核心系统追求极致RPO和RTO的容灾目标，从核心系统的业务层面来看，能够实现核心系统业务在双活数据中心进行分发且自动切换从而保障业务的连续性，我们认为这样的目标就实现了应用级别的双活。这其中需要基础架构片面很多关键技术体系的支撑，同样也会有很多的关键问题需要解决。内容包括：建设思路和方法论、数据保护和存储层麓制、链路和负我引流、服务器选型、容灾切换等。、核心系统双活方案下的建设思路和方法论方面QI如何从整体上考虑核心系统同城双活？【问题描述】核心系统同城双活，极大缩短了核心系统故障恢豆时间，提高业务系统连续性，如何从整体上考虑核心系统同城双活，如主机，存储，数据库,负载设备，共享文件系

2、统，网络，应用程序等？AI商用机器企业云创新中心令前技术支持：我觉得主要从以下几个层面考虑：I.从整体架构上来看，通常关注网络层、应用层、数据库层和存储层这几个层面，对于网络层要求双中心间二层打通，实现双中心间业务引流：对于应用层,采用GTM&1.TM联动技术实现跨数据中心保护：对于数据库房，采用路数据中心集群部署，系统保留ADG等类型的复制模式：对于存储层，通过各家厂商的存储双活技术实现跨数据中心集群部署。2 .从成本角度考虑，主要包含设务WJ买成本、建设成本、运维成本。这块比较难估算，因为不同地域，不同公司资源的情况下成本会有较大出入“设备的购买成本主要包含应用主机、存储、核心以太交换机等

3、：建设成本包括前期规划、实验室确认参数、业务场景卜.业务测试、安装调试、真实环境压力测限、切换演练等方面，以上均需要人员成本的投入：运维成本取决于自动化程度的高低，通常情况下如果各节点完全可实现自动切换，相对的兔杂度也有所提高，对于运维人员的技术要求有一定限制。3,从技术成熟度和方案及方案健壮性方面来看，刚才在上面第一点中提到的四个层次所使用的关键技术，目前已经非常成熟，各厂商均有成熟的解决方案。使用如POWer上的双活方案，基F存储的双与复制的技术，数据库的基石事务日志回放的数据技术，以及博于系统级逻辑卷镜像技术,这些技术均有成熟的方案,在很多银行也有实际落地的案例，并且已经桎定运行了好多年

4、；4 .需要充分的风险评估,比如要解决数据库和存储仲裁不一致，集群发生脑裂的问题，如何解决应用负我会话一致性的问题，如何解决I/O时延，如何应对光纤抖动，如何解决资源高度冗余导致资源浪费问题.这些都需要在企业架构范国内考虑，也并不是所有问题都能在技术层面解决：5 .除此之外，还需要考虑功能拓展性问题，对于功能的拓展性，以业务功能拓展性来说，当前设计的双活架构应不仅仅适用于核心系统，也适合支持未来其他不要的业务系统使用.A2商用机器企业云创新中心系统架构师:这问题比较宏观，同城双活概况上来讲要号虑的层次仃：1、网络层：2、应用乂：3、数据库层-存储13这几层的实现难度是不同的,通常网络U和应用屋

5、比较容易实现，成熟的产品和方案也比较多，因为这两层只分发请求，不处理请求，比较容易横向扩展，也基本不存在相比间需要同步数据的问题。问题中的负效均衡设备，网络DNS调度、应用横向部署等基本都在这层解决。数据库层双活，就涉及到问题中提到的数据库和共享文件系统等问题，这些也有成熟的解决方案，比如数据的EX1.CndRAC、分布式文件系统、GPFS等数据同步，但从这层开始就设计节点间数据同步的问题了，就需要根据实际的需求和成本的评估进行技术的取舍。比如线路不稳定、带宽不够等因素就不适合做同步双活和复制。存储展的数据复制，在各厂家的中高端存储中是都能实现的，也要根据线路，距离等因素抉择豆制的方式。【Q2

6、】俗话说：“三分技术，七分管理”，在规划、架构核心系统同城双活时，对运维、管理人员有哪些要求？AI某省金融系统工程师：在技术转为自动化、智能化的今天，对人员要求也是越来越高，虽然部分工作机器能进行咨代，但无法全部杵代，因此对于运维、管理人员来说，明獭此趋势，还是要从以下儿点进行考虑：1、明确队伍组成，分工、人才储备、确定管理人分，一个队伍合适的管理是关键：2、技术的储备，运维人员从运维出发，相关的技术都需要了解，以及快速处理相应的故障；管理人员则需对顶层规划、业务流程、相关技术进行了解，把握趋势：3、排好计划，什么时间点做什么事情，进行相应的时间和进度管理。A2银行系统环境管理：对于管理人员，

7、需要根据项目的时间要求做好任务的分配和实施进度的把控，尽量让自己的人能做到技术上集体讨论，群策群力，不区分专业全流程参与。建议运维的人从架构设计的时候就全程参与，包括后续的详细规划例如分区的安装、网口和网络的规划、操作系统数据阵的安装，参数优化，容盘的规划，只有对架构和实施都比较熟悉的人，才能做好整体的运维，临危不乱。Q3双活带来连续性提升的同时，可能某些场竞I，降低系统可用性，同时增加系统笈杂性和提供运行成本。双活如何建设，如何黄捏好各系统平衡点？AI银行系统环境管理：双活带来连续性提升的同时，往往因为需要对远端进行数据复制造成一定的性能损耗，这个性能损耗视不同的发制方式会有区别，如果采用异

8、步模式则基本可以忽略。对于重要的应用系统,需要把数据安全性和系统连续性摆在第位的，宁愿多花一些成本去强化硬件平台、优化软件设计和代码以提高系统性能，补足双活带来的性能消耗。A2商用机器企业云创新中心系统架构师：双活是个建设目标，但从城商行用户的实现角度来看，并不是步到位的，平衡点一方面是建设和维护成本与希里达到的RTO和RPO间的平衡，另一方面是技术复杂性带来的衍生不确定性增多和人为可控之间的平衡。目前看，双中心实现数据级主备中心或者双中心在不同业务上互为主备实现起来相对成熟，成木也可控。真正的业务层面双活，对业芬读写比类型以及线路要求都较高，客户处于探索阶段的比例较大.【04】核心业务系统同

9、城双活建设如何解决业务裔并发与双活带来的性能影响之间的矛盾？【问题描述】如题,核心业务系统日间高峰期业务并发高，压力大,响应时间耍求离，日终批量业务时数据库的增删改操作多，如果建设核心业务系统双活，势必带来一定的性能影响，如何有效解决或者缓解该问题是建设核心业务系统同城双活的重要问题。(A1.J银行系统环境管理：双中心架构如果采用ex1.endrac,则关键在乎减少跨中心节点间的gc,要做好应用功能的区分，尽量避免出现应用向两个不同数据中心玳节点读写同一张友的的情况。对于跑批类的应用，应当尽量指定连接固定的Vip,而不是SCaniP，这样能提高跑批的效率，也能避免出现gc,从而提高整体响应速度

10、。A2商用机器企业云创新中心系统架构师：考虑业务建设双活架构，有几个需要注意或规避的问题，其中之一就是写操作特别多的业务是不太适合做双活的。至少在当前普遍的线路成本和线路质量的条件下，不是很适合。大量频繁的写操作，在双活的需求下需要实时同步到同城中心，即使是在线路带宽够的情况下，临时的抖动也会因为时湍确认不及时带来业务的响应时效增加而性能下降，这个问题非常依赖于稳定的线路质量。Q5分布式架构的系统如何双活？【问题描述】随着互联网业务的发展，分布式架构在银行业信息系统应用越来越广泛，分布式架构双活如何考虑？单套扩展还是双套并行，单套扩展是否会有网络流量压力，并行如何解决缓存问题等等？AI某省金融

11、系统工程师：双机房网络侦量还是需要保障的,目前我中心双机房为80J（X）公里，延时大概为5定杪左右，相应的双活如对延时比较敏感，实现效果较差。A2银行系统环境管理：个人感觉一套还是两套运行，主要需要考虑的还是网络质量，如果网络质量有保证，单套扩展的架构属于双中心的紧耦合架构，架构上比较简单清晰,双中心间的业务分发策略、业务间的访问关系配理也相对比较简单，但是单集群的风险在于如果网络出现明显抖动，可能带来的是整个集群的性能下降或者卡顿。双中心松耦合，部署两套集群的缺点就在于部署比较麻烦，双中心的业务间访问关系配置较为更杂，负载均衡分发策略相对更杂，优势就在于即使个集群出现问题，也还有一个集群能继

12、续提供服务.A3商用机器企业云创新中心软件架构设i骈：分布式架构卜.，多副本数据读写各节点之间传输本身会有很大的网络传输要求。所以般分布式建设双活时，也是建同城双活，把其中1个或少数副本同步到双活备中心，同城备中心一般只承载少量查询业务你说的双套并行一般是一套主生产中心，远程建一套异步（非同步）更制的容灾环境.A4商用机器企业云创新中心系统架构师：分布式架构的双活，目前看更多的还是依赖于其自身的多副本部署策略看各家的方案中，单套拉伸距掰进行扩展的居多.对两中心之间的网络质量需求比较高。二、核心系统双活方案卜的数据保护和存储层豆制方面Q6如何实现核心系统数据库层面的跨数据中心保护？包括访问连续性

13、保护和数据本身的保护？数据库又如何切换至同城数据中心？【AI】城商行系统架构如：苜先这个问题标题覆盖不全。1、首先数据库的保护无非几种，I）通过备份软件进行数据定期备份。2）通过存储底层数据夏制进行灾备数据保护。3）通过数据库本身的备份机制进行数据保护（比如OraCIeADGoGG、MySQ1.的副本方式）。4）数据库双活灾备保护（此方式不能防止数据庠逻辑损害，一般结合备份进行数据保护）。2、切换同城数据中心（你的核心是双活或者读写分离还是主备方式，这个很重要，不同的应用灾备方式切换的步骤都不样）结合应用和数据库部署方式有N种组合和切换步骤.A2商用机器企业云创新中心系统工程如：以POWCrH

14、ASyStemMiITorHypCrSW叩双活方案为例：PowcrHASystcmMiaor企业版提供HyperSwap功能实现数据中心双活功能。PowerHAHyperSwap是基TPOWER平台及DSBKMeiroMirror同步更制技术，当主存储系统不可访问时，AIX透明地符磁盘I/O切换到备存储.并且不影响正在运行的应用，从而提供数据中心之间（或数据中心内）存储高可用及应用高可用的一种容灾方案,也是PoWERAetiVe-ACtiVe解决方案的重要组成部分。POWerHAHyPerSWaP能与OraC1.eRAC完美结合，实现数据库无中断的快速切换，与传统解决方案相比，其切换更加自动化

15、、RTO更短，RPO为O,PowcrHAHvpcrSwap双活解决方案具有明显的优势：监控从应用到存储各个层面，并提供每个层面故障处理方案：结合DS8KMetrOMi1.TOr.保证高性能及数据传输稳定可靠：支持部署Orae1.eEXtendRAC,实现真正意义的双活中心：充分利用双中心的服务器、存储资源：RTO为秒级，RPOR;一键完成高端存储容灾演练，应用不受影响：可设巴当脑裂或站点故障发生时自动响应成人为干预策略。【A3】农信系统工程师：1、核心系统数据库匕的路数据中心保护耍建立全面多忆次的保护，包括底层存储级复制、数据库级豆制、数据备份，三位一体，防范各种类型的故障。2,连续性数据保护

16、又叫CDP,属于数据备份的一种，通过一次性全量同步底层存储数据和实时增量捕获数据来实现小间隔时点数据的快到，这是一般的备份做不到的，一般的备份RPO太大，满足不了小间隔时点的恢复耍求，这时就要用到CDP去做。3、数据库切换按照数据史制的方式不同而不同，若是底层存储级豆制，必然是要经历生产端先停止应用和数据库、卸效存储盘、等待生产和同城数据完全一致、史制关系反转、同城湍挂载存储盘、启动数据库和应用等过程：若是数据阵级复制，则要经历停应用、切换数据库主从关系、挂栽对外服务IP、启动应用等过程。IQ7】同城双活核心系统数据致性宜采用数据库同步模式还是底层存储同步模式？是否有必要同时采取两种模式？AI

17、农信系统工程师：作为银行的核心系统，我觉得完全有必要同时采取两种模式：I、底层存储同步是块数据的物理致性保证，保证了数据级容灾需求。但同城端的这份数据不可读不可写，要利用起来需要再对该数据卷进行快照挂载使用.2,数据阵同步模式是通过事务日志的方式再写一份日志到同城端，保证了数据的逻辑一致性，且在同城端是可读的，这也是数据读写分离的经典方式。3、块数据的物理致性无法保证数据的逻辑致性，真正而向业务的数据必须是逻辑致性的，所以为最大限度的保障数据安全性，有必要再做一份数据库级的同步。4、数据库级的复制粒盖面不全，只能涉及到事务级别的数据，其他文件系统中的文件数据瞪盖不了，所以这部分数据就必然要用到

18、底层的块数据同步。5、数据库级的第制需要消耗一定的主机性能，而I1.实施起来麻烦，需要停机。而底层存储史制实施比较简单，可在线实施，不消耗主机性能.A2J商用机器企业云创新中心软件架构设计师：个人完全同意前面专家的说法，同城双活核心系统有必要同时采取数据库同步和存储底层同步两种模式。也还要看数据中心所具备的条件和人员技术储备情况，来选择具体方案.I,如果具有同城几卜公里内非常稳定且带宽足够的网络条件，那可以按照一步到位的真正A-A双活、同城数据中心同时读写（EXtendedRACorPUreSCa1.eGDPC）各承担部分业务来建设。这种情况下，可以优先考虑数据库同步模式的数据库双活方案。而底

19、U存储同步模式作为更远距离的备份容灾方案，至丁是做成同步还是异步的存储级备份容灾方案，同样取决于传输延迟和带宽条件（当然这里用DG或HA/DR等数据库方案取代底层存储复制也是可行的）。当然数据库上droptab1.ede1.ete数据误操作之类的逻辑错误，首先得弁制度保障，K次得依赖数据库U面的闪回技术来做为一道保障”2.如果同城带宽和延迟达不到生产数据库高峰时产生日志和变化数据量需求，那应该优先选择存储底层同步技术，主生产中心负力全部业务，同城中心作为务中心随时待命准备接管可能发生故障的生产中心。此时数据库同步技术也可以做为辅助手段（DG或HA/DR）,多做一个数据库同步或者准同步的日志备份

20、，万一底层存储复制技术因为数据逻辑一致性问题（出现概率低，但理论上有潜在可能），可以用作第3个应急接管预案.【Q8】生产同城相距30公里，数据库层，能否实现双中心同时读写体化？【问题描述】读写一体双活，拿OraCIe来做解择，是OraC1.e中大家比较熟悉的OnIdCCX1.CndRAC。这种方案很多存储厂商曾经推广过，OrHCIC厂商最近很少推荐。这种方案也被很多用户认为是一种理想化的双活解决方案。很多人认为这才是真正意义上的“双活”。人民银行发布“金网行业信息系统信息安全等级保护实施指引”中对T：.级等保的系统提出了：对于同城数据备份中心，应与生产中心直线距离至少达到30公里,可以接管所有

21、核心业务的运行：对于异地数据备份中心,应与生产中心直线距离至少达到I（M）公里：RT;光被目的端“镜子”反射回源端的延时。相对论定律：宇宙最而速度一一真空光速恒定30万公里.光纤折射率15光纤光速=3OO.OOO,15=2OO.OOO公里/秒。30公里.光纤RTT=2X30200,000=0.3ms,1延时受物理定律限制，不可缩短，和钱无关，和技术进步无关。我们通过OraCIe数据库环境下的测试可以发现，Orac1.e数据库中，链路每增加0.5ms的延迟，查询会增加4倍差距。身OraC1.e远距离集群举例：OraCIe桀群远程双活部署会引起“块争抢”的问题：一个块含很多记录,即便两节点（眼务器

22、）同时访问不同记录,也可能出现访问同一个块的“块争抢”，引起锁、等待、块属主变更、更新本地缓存等操作。节点和存储分布在远程时，网络延时ImS数量级，争抢解决慢，影响性能非常大.（若节点和存储都在本地,网络延时O-O1.tns数量级,争抢影响性能小）通常通过“分割”解决“块争抢”，例如：常用分割方法是按应用或衣分割。每个站点只访问自Ci的数据，减少块争抢。但是这并不能完全避免争抢问题，通常为提高可用性OmC1.eJ.商推荐“读写分离双活的方案，把所有数据在每个站点本地存放一份，更新本地数据，并在另一站点第制出副本.这样，一站点故障，另一站点都能迅速负担全部负载。副本数据可以用于且仅用于读取。例如

23、ADG、OGG等方案，目的是各部分松耦合，简洁，可用性和性能易于管理。远程不同于本地，本地集群部署的成功案例比比皆是,但是远程并行集群通过集群信息连续同步复制，将遥远的东西紧耦合，复杂,可用性和性能难于管理，可靠性低于本地并行集群。光速有限，造成：同步更制+远程=慢动作，所以能否实现远程“读写一体双活”呢？A1商用机器企业云创新中心软件架构设计时i：完全赞同您说的“光速有限，造成：同步复制+远程=慢动作”说法。人民银行这个三级等保的系统要求，同城数据备份中心至少30公里.，异地数据备份中心与主生产至少100公里，也许正式是考虑到这方面因素。让大家可以有这样的可行方案选择：同城儿卜公里距离内,建

24、真EU;活数据中心。其中查询业务可以利用数据阵双活方案中优先读本地存储的亲和性策略，从哪侧发起的SQ1.三询就从哪一侧存储上查询数据；但增/删/改因为是同步写双中心，必然后链路距离影响，但从今年已实施案例来看，30-70公里距离的居多，写延迟带来的交易延迟也一股也在可接受范用内：异地（100公里）建议异步备份容灾中心，利用数据库日志异步复制的方式，或者底乂存储同步方式，熨制到远端.为降低对主生产中心的冲击，可以考虑从同城备中心舁步豆制到异地中心。A2银行系统架构师：生产相距3（）公里了，光纤挖地施工长度肯定远大于30公里吧,（沿路街道、桥梁），传统数据库真心做不好双活。EXIendRAC更新频

25、繁情况下集群CaChe太难受了；长距离很难避免链路抖动，频繁抖动DBA只能被动挨打，难一体化读写。分布式数据库二阶段提交完全可能。长距离EXtCndRAC我的构想是主中心两个节点通过负载均衡来写，主中心加的是写锁，备中心节点仪做做读取,备中心加的是读锁“这种伪双活可以尝试.长距离是个难活的生意.A3银行系统环境管理：当数据库节点之间出现较多gc等待事件的时候，表现慢的不光是跨节点访问的那些表，数据库的整体表现都是受影响的。因此在extendrac架构下即使边是纯写入操作，另一个中心纯粹的读操作，如果造成的gc很高的话，仍然是会有数据库性能下降的问即的。之前有运营商的朋友用过类似架构，后面改成直

26、接关闭另个一中心的数据库，减少跨中心gc,这个架构主要就用于做切换演练的时候用了。A4商用机器企业云创新中心系统架构师：您说的非常对，光速有限。完全的读写双活一体，是应用双活+数据库双活+数据存储双活，目前影响这种架构实现的比较大的困难就是数据库双活和数据存储双活。距离过远，即使线路稳定，也会仃较大的延时,就会对数据库的双活造成影响，也会对读写一体双活造成影响.三、核心系统双活方案下的链路及负载引潦方面Q9同城双活链路抖动的时候会不会丢数据？如何解决这个问题？A1银行系统环境管理：这个要看采用的是什么更制技术，比较成熟的例如存储间史制，或者adg的第制，链路的抖动都会带来豆制的卡顿和延迟，但是

27、不会造成数据的丢失，在链路恢发正常后，延迟同步的数据还是会继续同步到备库或者存储的目的端去的。链路抖动比较严重时，反应在数据库的土库或者存储主节点上，可能会出现无法写入的情况，从某种程度上来说，系统管理员在遇到链路的抖动的时候宇建选择直接把豆制链路断开，变成异步复制模式，来换取主库或者:储读写节点的平安。A2商用机器企业云创新中心传前技术支持：抖动通常是不可避免的，即便是运营商提供质量再好的裸光纤连接，还是或多或少会存在抖动,如果频率不是很而，不至引起网络长时间超时的话，都属于在可控范围内。理论上每K）OKM距离，RTT往返延迟为IMS,但一次通讯，往往会存在多次RTT，所以带来的延迟是不可避

28、免的。网络上最好还是基于TCP协议的数据同步，利用重传机制，保证数据的在定时间窗口还是能够传输过去。A3商用机器企业云创新中心系统架构师：存储夏制过程中链路的抖动不会丢数据，抖动结束后数据会追齐！QIO双活环境DWDM配置经验，如何配置防止运营商线路抖动影响波分承教线路？AI银行系统环境管理：关于DWDM配刊没法阐述的很细致，大体方案有两个，如下图：1、f波分设备接2条裸光纤，由波分自动到新选择网络质IB较优的线路.2、采用思科San交换机连接两个运营育波分,在San上将两条磴做绑定，由San交换机自动选择质是较优的因8,一个运营育道踣抖动，双中心网络不受影响.-W交换机Q11双中心如何解决脑

29、裂问题，有哪些常用的措施？AI银行系统环境管理：不管是数据库集群脑裂还是存储集群脑裂，所有的脑裂主要都是把握好仲裁方案，比较笨的办法就是在面临有风险的仲裁决策时，强制指定其中一边为主，并且完全关闭另外边，强制所有的应用都连接到被强制设置为主服务的节点。另外一边关闭后断开网络修好，等确保完全修延后才开启网络.(A2J商用机器企业云创新中心系统工程师：为了避免双活数据中心产生脑裂(SP1.itBrain)或场地分割(SiteiSOIation)状况，需要提供有效的仲裁方式来保证数据完整性，通常是建立第三个中心作为仲裁。有部分双活方案中可以设置当脑裂或站点故障发生时的自动响应或人为干预策略，比如Po

30、wcrHASysicmMirTor企业版提供HypcrSwap功能。PoWCrHAHVPCrSWaP基于POWER平台及DSSKMctroMirror同步复制技术，提供数据中心之间(或数据中心内)存储高可用及应用高可用的种容灾方案.也是POWERActive-Active解决方案的重要组成部分.【QI2如何实现核心系统网络层面的双中心引流架构？故障场合下如何将核心外围渠道或应用系统访问核心切换或引流到同城数据中心？A1某省金融系统工程师：目前核心一般都为主备方式，前台的应用可以实现双活，通过流量分发的形式实现双机房潦量的引流，当某一机房发生问即时可将相应的流量引潦至另一机房，实现业务的无物。【

31、A2】商用机器企业云创新中心系统架构如：我理解这个问题有两种可能：第一，对于任意一个应用系统而言，都仍然是部署在一个中心，另一个中心是数据或应用级的备份。这样的话，是通过故障时DNS的重新指向引流到备中心的，或手工或通过策略。第二，如果应用层已经是双中心部署，同时对外提供服务。则是利用GTM根据负载和设置的策略进行双中心的导流.【A3】银行系统环境管理：可以通过跨中心的负载均衡GTM实现，策略配置成双中心的应用同时双活或者配置成本中心的应用全部故障时将业务转发到同城的应用服务器上。四、核心系统双活方案下的服务器选型及Power平台优势方面QI3J如何考量核心系统服务器层面的跨数据中心部署架构和

32、服务器选型？(A1.J银行系统环境管理：主要是考虑清是平台的选择，是UniX还是IinUX,如果是IinUx,可选择面很广例如普通X86和数据库一体机都可以，如果追求稳定性，建议就在中端小型机里面选择，故障率相对还是低一些。银行业的核心数据库服务器，还是建议选择比较稳定的平台，少折腌。A2银行系统架构师：你这个要的结合你的核心应用来定。核心是单体的，还是集群的，或者分布式。单体集中式架构，就选UniX平台吧，稳定性好，非集中式的架构，你的数据库建议选高端服务器，应用可选性比较强了，在X86平台，可以物理机堆叠部署，也可以虚拟化部署，应用调度上建议上负载均衡，能够很轻松实现切换调度。【A3】商用

33、机器企业云创新中心系统架构师：目前我们看到城商行级别最核心的类和二类服务器，选择成熟稳定UNIX小型机的用户还是占大多数。原因在了小型机架构部署核心应用，安全稔定且成功案例丰富。考虑到跨数据中心的容灾和双活，小型机配合存储及数据库层的解决方案也众多，可以比较全面地满足用户从本地高可用、到数据同步、再到应用双活的需要。从性能和稳定性上来说,小型机也都优于X86或生机的1.inux平台。A4商用机器企业云创新中心系统工程师：核心系统特别是核心数据库对业务连续要求高，建议考虑两地三中心方案，有条件的话采用同城双活，但是注意同城中心间的网络延迟和稳定性，延迟高会影响性能，另外要防范脑裂，建议有第一：中

34、心作为仲裁“不具备条件或不需要双活的，可以做站点间的互备，提高资源利用率。服务器选型上来说，核心系统对性能、高可靠性都有比较高的要求，这方面KIPOWCr比X86还是有明显优势的，另外POWer上的高可用、容灾方案比较多,案例也多，更成熟可苑。【A5】商用机器企业云创新中心令前技术支持：Power架构经过几十年的不断完善，目前已经形成了以PowcrHASystcniMirror和VMRCCoVCryManagCr为基础，兼顾关键业务和非关键业务的高万用/灾备解决方案。PowerHASysteniMirror.POWer平台上稳定、可匏的HADR方案，可满足多种高可用、容灾需求（主备/同城异地容

35、灾/双活）。适用于关键工作负载。Power平台上支持PowerHAHypcrSwap,DB2purcsca1.cGDPC、OracIcExtcndRAC,基于存储的双活、IBMDb2Mirrorfori等多种成熟的双活方案。都仃实际落地的案例可以供其他银行参考。Q4PoWer平台在建设核心业务系统同城双活方案中有何独特优势？【问题描述】POwer平台的方案，相较于非Power平台的方案，在应用层、数据库层、虚拟化资源池层或者与存储的相互结合方面，有何独特的优协所在？（银行系统环境管理：应该说power平台目前最为适合还是在数据库U使用，关键优势是其稳定性，小型机内关键组件的在线维护能力，相比x

36、86服务器还是1出不少，故障率相对较低，并且多数故障可以在线维护，降低停服风险。应用层面现在使用x86进行虚拟化后部署集群已经是非常成熟的方案了。A2某省金融系统工程师：一般POwcr平台主要用在数据库上，优势主要体现在：I、节省设备上，之前POWer主备两台实现数据库，现在换成x86需一主一备两从的方式，还要分底分表，下了设备就上去了，带来的管理和维护的难度加大：2、设备稳定上，相比x86来说，POWer设备较稳定，出现故障几率也较小A3商用机器企业云创新中心售前技术支持：PowcrH/XSystcniMirror企业版提供HypcrSwap功能实现数据中心双活功能。PoWerHAHyper

37、SwaP是基于POWER平台及DS8KMetroMiror同步发制技术，当主存储系统不可访问时,AIX透明地将磁盘I/O切换到备存储,并且不影响正在运行的应用，从而提供数据中心之间（或数据中心内）存储高可用及应用高可用的一种容灾方案,也是PowERActivc-Activc解决方案的重要组成部分。POwerHAHyPerSWaP能与OracIeRAC完美结合，实现数据库无中断的快速切换，与传统解决方案相比，其切换更加自动化、RTo更短，RPo为0“PriMrvSiwaasM(HM*a*1IUI)I*MMdIaparttuVar7mVCOrac1.eRACwithHyperSwapI.W11*W

38、R2.imP.4X61.3.UKtf1.UirHI介i本中ftt1.0rc!WIJUUJ.2t!F1.&用公IAttgOrecIeRACwithHyprSwAp1.orXIatAe邕踵Dn此中2.TAFOWi三，三n.*fo4w-QI5PowerHA切换过程中与数据库如何配合？AI)商用机器企业云创新中心系统架构如：聘数据库的启停命令分别写到启动脚本和停止脚本中，在PowcrHA中调用启停脚本来执行数据库的启件。(.2商用机器企业云创新中心售前技术支持：一般是配置Power1.iA的后停脚本，另外PowerIIA也支持通过InOni1.Or脚本时数据库和应用的状态进行监控，当发现异常时也可以进

39、行切换。【A3】银行系统环境管理：个人认为只要应用支持短连接或者自动重连，数据库的RAC方案在连续性方面相对优于HA.HA切换必然有数据库的关闭和启动过程，特别是对于体量比较大的数据库，建启一次可能时间会更长。A4农信系统工程师：PowerHA切换过程中在释放资源组前后，可以通过设置停止脚本和启动脚本，脚本里分别编写停止和启动数据库的命令，并在POWERHA的应用资源中设置好启停脚本的路径等内容，这样在P0WERHA切换时，就会按照运行停止脚本，择放资源组，切换资源组，接管资源组，运行启动脚本的步骤，和数据库完美衔接。A5某省金融系统工程师：对于PowcrHA结合db2数据库来说，将启停应用的

40、步骤进行脚本化，并招脚本路径配置在HA之中，一旦发生.切换会结合脚本进行相应的应用后停。五、核心系统双活方案下的容灾切换方面Q16核心业务双活切换需要考虑哪些因素？城商行核心业务切换需要考虑哪些因素？AI银行系统环境管理：个人理解双中心切换前可能需要注意的点包含如下：切换的系统范国、网络分发策略、域名解析、安全策略、切换相关系统在切换到后另一个中心后的硬件资源情况、系统并发能力、切换后一些特定的定时任务、备份任务。A2J商用机器企业云创新中心系统架构师：您谈到了双活，同时还有业务切换,那么我理解还是主备的模式,不然完全的双活系统就不存在切换的问题.核心业务切换，前提一定是业务的分级和分组之后的

41、切换，不然只是某个业务切换了，其他的相关业务还留在原中心，这样的切换也没什么意义。至少要保证一组相关的业务一起切换。如果是两中心距离不远，SAN可以直接打通，两边件自可以看到对端的存储。风险把控涉及的方面比较多，如提前准备好必要的切换策略、切换潦程、以及切换后验证文档.城商行核心业务系统存储跨中心双活建设的10个难点陵者互联网金融的快速发展，金融企业数据中心建设面临若新的挑战，那就是对RTO和RPO的极限追求,从而也就诞生了近年来的热点话题一一双活数据中心建设，其作为灾备方案中高级别的解决方案，逐渐成为/应对传统灾备难题的一把利剑。它能够解决传统的灾备方案中资源利用率低、可用性差、出现故障时停

42、机时间长、数据恢更慢、风险高等问廖但同时也带来了性能、链路稳定性、数据致性、脑裂和数据同步逻辑错误等众多在规划设计、实施和运维阶段的琲点问题。I、如何做到读写分离，提升IO读写效率？如何设计双活存储而可用，防止仲裁防脑裂？银行股份有限公司基础架构组长：1.存储双活后，有一个难点就是热点数据的跨站访问，实施J数据库和存储层同时双活，会出现数据竞争的问题，这样也降低了IO效率。这时候就要通过锁预取和缓存策略，通过较小的控制报文，向锁权限缓存节点申请写权限，并利用锁预取将部分区间的写权限缓存到本地。这样，后续的连续写1/0操作可快速的命中在本地，减少跨站点的数据传输和交互，做到读写分离，从而提升IO

43、读写性能。2.AA模式的双活存储，在某些特定的多重故障F.仲裁机制会优先保证数据的致性，可能会将双活存储上的所有1.UN都停止主机访问。所以，在设计仲裁模式的时候，强烈建议建立选择独立的第:方站点作为仲城机，但也不能完全避免上述情况，所以，还要考虑强制启动，而强制启动端的存储作为同步源端,会在链路恢史后同步增量差异数据。农信系统工程师：双活的两个存储都可以同时时主机提供读写服务，也可以选择一个存储作为写存储服务，另一个存储作为读存储服务，实现读写分离，这样的好处可以减少双活存储的写I/O竞争，降低写UO时延。双活存储高可用的话，需要设置第三仲裁站点，可以用磁盘或者虚拟机来做仲裁，仲裁机制根据存

44、储双活方案可以选择静态优先+动态仲战双重机制来保障脑裂或者故障后的双活存储。银行系统环境管理：读写分离，可以采用存储发制技术完成，也可以采用数据库软件更制技术完成,为保证数橱的较高实时性，需要用两个不同的服务器挂载双活IUn或者果用数据库集群，或者adg方案实现，为f保证好的K）读写效率，需要保障双活存储间的网络带宽和低延时。为避免脑裂，存储建议采用化和ip网络多种仲裁探活机制，利用第三方站点进行检测判决。数据存储解决方案中心技术总监：要做读写分离首先要明确为什么要做读写分离“读写分离是一种技术手段，而单纯的依赖技术手段是无法解决所有问题的，如果应用的读写比例严重失调，那么需要和应用开发部门相

45、比协调。读写分离的重点和本质，其实就是数据的同步。为了实现数据的实时同步，现有的技术可以在多个U面实现读写分离”例如，基于操作系统以、基丁存储乂进行复制或者堪于应用分发或者基于数据库自身的能力的技术，都可以实现数据的读写分离。由于在数据同步的过程中，通常会涉及业务数据选择以及源端多种类型整合的问题，因此通常不建议使用操作系统层和存储层的第制来实现，在金融行业，比较多的是用数据库来实现读分离。例如OmCIe基丁日志的兔制技术等等2,两个数据中心间数据同步逻辑错误问题如何有效避免呢？【问题描述】存储层面的宓制技术基本以存储块为单位进行的数据发制，假设数据块发生/逻辑错误，那么存储是无法检测到的，它

46、会继续将坏的数据块儿同步到灾备端，如果因此数据库发生宕机，那么灾备端的数据库也同样无法正常启动。某城市商业银行系统/灾备工程师：虽然发生几率比较小，但这个问题确实存在.个人建议是采用磁带库或者CDP进行再次备份，若我的遇到逻辑问题还是亚新恢员数据。或者干脆采用分布式存储。华为产品总监：无论复制方式是同步、异步、双活还是连续性数据保护，都是基于存储数据块级别的复制技术，复制源端在可读时，会将块中的数据原样的拷贝一份至FI标端，当源端数据出现误删、误改、磁区退化数据异变、数据库事物层逻辑错误等数据逻辑性错误时，发制目标端无法检测到这些错误，依旧发制“错误”的数据，导致两份副本都无法正常使用.所以要

47、设出多层次的防范机制，保障数据的可靠性和安全性，存储双活技术只是其中的一个层次，要辅以备份技术、数据库发制技术，连续性数据保护，建立了完善的数据保障体系。(I)备份系统按照一定的时间频率对数据库做全员和增量备份，在遇到数据逻辑错误时，通过恢复将数据回退到最后一个备份版本。如TSNkNBU,COMMVAU1.Tt(2)数据库史制技术有实时同步、准同步、异步等方式，保障主数据库逻辑错误无法正常运行时，切至备数据库，网退到着库前一个日志CoMMn后的版本.1DB2HADR,ORAC1.EADG.MYSQ1.主从竟制等。(3)连续性数据保护技术也是准/实时对存储数据块做快照，源端数据无法继续使用时，通过快照回退至前个数据可用版本。如CDP。为不影响源端数据的访问性能或者单个系统无法满足需求时，可以考虑多种方式结合，比如备份系统在备份超大数据库时，没有充足的带宽或者备份时间窗口，可以用数据库的异步史制方式来做为备份方式的补充；连续性数据保护技术需要通过1.VM镜像源端数据，增加了写延迟,可以通过数据库准实时同步或者异步的方式复制数据到备库节点，备库节点的后端存储为连续性数据保护的存储节点，如DB2HADR+CDP的组合。银行股份有限公司基础架构组长：无论是adg数据库比制技术还是存储及制技术都无法预防逻辑错误，预防逻辑错误最好的办