同城的灾备切换是每半年一次,我行是所有系统统一进行切换,如果是负载均衡系统需要进行停单边一周进行业务检验。异地灾备切换目前是重要信息系统进行切换,每季度进行一次连通性测试。
应用的灾备切换,这个还是要提前做好应用标准化,比如我行所有系统目前都支持在指定的标准目录使用标准命名脚本实现分步骤或者一键式启停,在实现应用标准化后也能方便接入运维自动化系统方便进行统一的管理
补充回答下第一个问题,不知道贵行整体架构中是否有总前或者总线系统,我行核心系统的多活负载均衡实际是由总前/分布式总线系统通过tuxedo中间件实现的,总前/总线系统多个app通过tuxedo域连接和核心系统多个app通信,核心系
我行核心系统数据库目前是RAC,通过ADG做了双机房的读写分离,两个读库是RAC双活,业务由3个数据库同时对外服务。灾备方面: 主库跨机房是通过存储SRDF做了同城和异地的数据同步;存储通过BCV备份T+1数据,同事为了防止数据文件
我理解你的问题文件共享的高可用性吧?我行目前文件共享做了分级,普通文件使用了NAS,支付大小额类账务文件使用了NAS并且通过scp拷贝到了文件服务器一份(交易耗时增加300ms),重要文件确保NAS异常不会丢失,目前使用情况因性
分布式核心系统肯定是未来主要的发展方向,优点很多,但目前难点在于数据库层面,数据库跨中心多活比较难实现,数据一致性,分布式事物,跨中心的多节点性能和稳定性都没有达到比较完美的状态;另外分布式中文件共享也是一个小技术
故障状态检查需要分层部署监控: 基础设施、操作系统、中间件、应用标准监控、业务类监控等;通过BPC等软件通过网络包做交易码级监控。对各项监控点梳理应急预案,定期进行预案的重检和演练。生产系统每半年进行一次切换
Extend RAC对基础设施要求较高,在发生存储抖动的时候会影响双中心的应用服务,而存储抖动发生概率较高。我行目前是通过ADG做了读写分离,分担主库60%的查询交易,数据是三中心6副本。ADG同城双机房的延时是小于1秒,app自动检
核心系统目前APP基本都是负载均衡的,很容易实现分布式部署。DB限于当前技术没办法完美实现分布式,目前第三代分布式数据库比如Oceanbase,TiDB还都处于探索中,完美的分布式部署一定要数据库支持分布式事物,确保强一致性。
银行核心系统最重要的就是稳定性,从同业多次技术交流结果看,各家银行核心系统没有大规模使用云平台的,如果一定要使用云平台,建议部署多台app在云平台上,由总前/总线系统实现负载均衡,方便app进行故障切换,DB按正常架构部署,
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30