近年来城商银行进入了核心系统升级改造的高峰期，在核心业务系统升级改造的同时，也是基础架构平台改造升级的重要契机。

如今互联网金融迅猛发展，互联网公司的开发模式与体系架构，强调敏捷与快速迭代，采用PAAS、DEVOPS等高效能价值交付工具，为城商行核心基础架构建设提供了新的可借鉴模式。

而银行业在人民银行、银监会等监管部门的指导下，又有着完善的 “两地三中心”等业务连续性要求。就监管压力而言，重要业务系统的全天候持续性、稳定性、安全性是第一位的。每家城商行核心基础架构建设要面临结合自身的现有基础平台建设情况，如何有效融合互联网模式下基础平台优势，打造属于自己的新核心基础平台，实现新核心基础架构升级，成为摆在中心银行信息从业人员面前的现实问题。

本次活动特邀了三位嘉宾从“城商行新一代核心基础平台建设经验”、“城商行同城容灾建设案例”、“城商行核心业务系统升级改造服务器选型”等几个方面分享了相关技术文档。

同时在活动过程中收集到了很多同行提出的交流问题，也得到了大家的踊跃回复。这些问题中既有宏观角度的架构设计，也有某些技术细节的问题讨论。下面就这些热点问题和精彩回复做了一些集锦：

Q1、核心应用层能够实现多节点多活的情况下，城商行如何考虑实现双中心双活或者多中心多活模式？

目前城商行的基础架构，正在从本地高可用向同城容灾（双节点）的方式演进，还没有到多站点多活的程度，银监会也没有类似规范要求。

在两站点的情况下，对于应用层，不管是否核心，其实都可以资源池的方式承载，采用负载均衡的方式实现，通过IP打通、存储虚拟化、计算资源虚拟化实现两站点的双活部署。

在有第三方站点做仲裁的情况下，可以实现真正的双活，但现实中，有第三站点的确实是比较少。

在没有第三方站点的情况下，发生脑裂是，通过人工干预，快速恢复生产，实现准双活。

双中心双活建设，是个逐渐的过程，要充分考虑人员技能储备、方案的演练和优化、链路的稳定和优化、业务的分批双活等各种因素带来的限制和影响。

双中心双活或者多活的AA模式有很多种，有的要求双中心同时对外提供全部业务-真正意义上的双活。

有的要求实现一中心提供全部业务，另一中心提供查询类业务-即对于数据库来说是只读模式，也是一种双活模式。

两种情况对于数据库层和存储层的要求有所不同，对于底层资源的依赖程度也不同。

需要建设者根据自身实际条件衡量取舍。

Q2、核心数据库层选型Oracle ExtendRAC模式实现双活和oracle RAC+ADG模式实现准双活有哪些优势和劣势？

Extend RAC对基础设施要求较高，在发生存储抖动的时候会影响双中心的应用服务，而存储抖动发生概率较高。我行目前是通过ADG做了读写分离，分担主库60%的查询交易，数据是三中心6副本。ADG同城双机房的延时是小于1秒，app自动检测到ADG数据延时较大时可以在1秒内完成只读回切读写库。

未来发展我们是预研Oceanbase和TiDB，真正的分布式数据库才是解决分布式核心的发展方向。

extend rac成本高，环境条件要求苛刻，并且需要存储双活配合，但这是真正意义上的数据库双活。

rac + adg严格意义不是双活是高可用容灾，adg端实现写操作还需人工干预，好处是成本低一点，只读操作就算是鸡肋也能有点用。

Q3、新一代银行核心数据库底层如何实现高可用？灾备数据库是何种架构支持？

目前看，核心数据库的本地高可用主要有以下几种：

1） 系统级别HA软件，如PowerHA，一主一备；
2） 数据库级别的双节点方案，如Oracle RAC；
3） 数据库的逻辑备用方案，实时传输数据库日志数据，如Oracle DG;

如果讲到灾备，那一般是同城或异地之间，常用的有以下几种架构：

1.依赖于存储的数据复制技术
(1) 如果是同城的话(理论值小于100公里)，一般采用同步数据复制
(2) 如果是异地的话，一般采用异步数据复制
2.数据库逻辑灾备方案，通过IP传递日志数据，这个与本地高可用类似。

Q4、新一代核心银行系统基础架构平台文件数据如何高可用？

IBM的GPFS共享文件系统可以集群方式部署在AIX或者linux平台，实现共享文件的高可用。或者netapp、华为厂家的NAS存储也可以实现双活集群，提供高可用的文件共享。

我理解你的问题文件共享的高可用性吧？

我行目前文件共享做了分级，普通文件使用了NAS，支付大小额类账务文件使用了NAS并且通过scp拷贝到了文件服务器一份(交易耗时增加300ms)，重要文件确保NAS异常不会丢失，目前使用情况因性能问题，以及NAS可靠性问题，还是计划把小文件通过blob字段(小于64k的报文)存数据库。

批量交易是指的联机批量还是夜间批量？这两个处理方式还是有点差异，总结来说目前我们的做法是NAS来处理低重要度的文件，scp之类处理高重要度的文件，低频小文件存数据库完成共享。

Q5、power小型机在双活模式下如何部署？

在数据中心已经建成双活的模式下,Power设备可以构建跨越两数据中心的资源池，以PowerVC作为管理控制平台，实现跨越两个数据中心的系统部署和资源调度。从逻辑上将两个中心的资源一体化。

但实际上，如何建成双活，却是首先必须探讨的问题。

Q6、云平台故障恢复能力是否满足核心系统应用要求？

1）对于城商行的核心系统，现在还没看到部署在哪个公有云平台上；
2）如果是部署在城商行的私有云上/资源池，那么在建设云平台/资源池平台是时，这个平台与核心系统应该是彻底解耦的，应该只负责资源的分配何调度，这个平台是否运行都不能影响核心系统的生产
3）此外，还必须有其他介入机制，即：在云平台/资源池平台彻底瘫痪时，应该有其他方式介入资源的管理和调度。

银行核心系统最重要的就是稳定性，从同业多次技术交流结果看，各家银行核心系统没有大规模使用云平台的，如果一定要使用云平台，建议部署多台app在云平台上，由总前/总线系统实现负载均衡，方便app进行故障切换，DB按正常架构部署，保障核心系统数据的可靠性 。

Q7、同城双活架构下，仲裁节点的位置选择和设计原则是什么？

通常关注的因素有：

1）与同城的两个数据中心保持一定距离，确保任意一个数据中心的中心级意外事件不会影响到第三站点；
2）根据容灾方式和仲裁方式，应该保证数据带宽和规范内的通信延迟，例如：
在SVC Stretched Cluster的同城双活中，对第三方站点的要求是：
Quorum disk storage controllers must be Fibre Channel or FCIP-attached. They must be able to provide less than 80 ms response times, with a guaranteed bandwidth of greater than 2MB.

Q8、目前主流的存储双活方案支持的双中心距离是多少公里？

存储的同步容灾一般在100公里的范围内实现。这是常规的规则。

该规则的计算理论依据为：

1）同步容灾需要任何一个I/O要同时写到生产节点和灾备节点，任何一个I/O写成功都需要返回ACK确认;
2）通常系统的I/O有严格的时延要求，磁盘I/O不能超过1ms才能确保SLA。---这个1ms最大不能放大到5ms
3）光速是30万公里/秒，但这是光在真空中的速度。但是光在光纤中的速度大概要损失31%，也就是只剩下大约20万公里/秒。
4）根据1-3，可以计算一下同步容灾的距离如下：1ms* 20万km/s /2=100km.

以EMC存储为例子，厂商推荐是30km以内，主要是为了保证SRDF同步复制数据延时，目前使用EMC数据中心多在30km以内，同城数据复制延时最大在5ms-10ms量级。同城复制有可能是裸光有可能是FC转IP，这个网络延时都有时间限制，否则系统的写响应时间没办法保障。

Q9、新一代核心银行系统基础架构平台设备选型，是采用Power小型机设备还是采用x86设备？

目前市场上X86服务器不适合作为核心基础架构。

是否可行主要看银行是否能够承担相关的风险以及为此付出的成本代价。

从宁夏银行采用飞康存储这个案例-----也许不是太适合，但也说明了一个问题： 采用RAS不高的产品作为核心的组件，一旦出问题，所付出的成本代价将数百倍于所谓的“节约的架构成本”

• X86架构的总体RAS特性与Power架构有着巨大的差距。RAS包含从硬件、微码、驱动程序、操作系统等所有堆栈，对于城商行而言，技术人员相对较少，需要RAS特性高的基础架构作为其核心平台，同时规模和预算相对有限，不可能选择大机系统，因此Power小机平台是业界这么多年的明智选择。
• 资源弹性不足：Power小型机物理CPU可达16路、192核，每核处理处理能力相当于X86平台的2~3倍，为核心提供了充足的资源弹性可能。
• 从安全角度出发，X86平台的安全漏洞层层出不穷，特别是云计算的趋势上，Power平台基于硬件层面的虚拟化，显然全面优于借助软件虚拟化的X86平台。

Q10、当城商行考虑云平台基础架构方案时对于信息科技从业人员有哪些挑战？

当前城商行考虑IT系统云平台的演进，确实对信息科技人员提出了众多的挑战。作为基础架构的建设者、维护者，最大的挑战跟人认为：需要知晓多维、多个领域的知识。

简单而言：在此之前运维可能分为网络组、服务器组、存储组等。在云计算年代，这三方面的资源是融合在一起调配管理的。所以，基础架构的技术人员需要知晓这三个领域的统筹知识。

例如，在物理机的情况下，服务器组负责安装操作系统、建立用户、创建文件系统、设置权限、配置IP等OS知识，网络组负责调配网络交换机，存储组负责划分lun、配置zone+mapping等。在云平台虚拟化环境下，相关技术人员，上述运维的整个流程在云平台方式下一气呵成，相关技术人员需要“跨界”了解相关技术领域，进行知识的“融合”。

“城商行新一代核心银行系统基础架构平台高可用方案设计线上交流探讨”精彩回顾，请前往：http://www.talkwithtrend.com/Activity/index/op/question/id/1317