同样p750服务器,依据ibm gdpc架构搭建的双活系统,从2012年12月上线至今未宕过机,还成功经历了多次双活切换演练,ibm p系列服务器和db2 purescale还是很牢靠的
双中心脑裂肯定集群软件会通过仲裁来确定那个中心活着或者两个都死的。我所了解的有两种仲裁方式(majority这种请无视),第三方站点仲裁或人工仲裁的方式。第三方站点的好处就是可以自动仲裁,不过需要真的能找的到这个稳定
为了不影响重要交易的性能,对应用负载和路由肯定是要严谨的考虑的。直接说个例子,假设数据库用的是db2集群,距离主要造成以下影响:1、db2节点与两个中心cf的通讯时间增加了,造成sql语录require lock时间增加了,commit时将pa
有些集群软件是支持手工仲裁的,比如rsct,脑裂后可以将仲裁方式修改为人工,然后将某个子集群拉起来。但是有些集群比如gpfs是不支持这种人工仲裁的,它好像就majority一种仲裁方式,不过这也不要紧,依稀记得好像只要子集群里有
谈如何减少距离带来的影响前我想首先需要分析距离具体有哪些影响。以db2集群为例,距离主要造成以下影响:1、db2节点与两个中心cf的通讯时间增加了,造成sql语录require lock时间增加了,commit时将page写入cf中的gbp的时间
数据库层面可以用诸如db2 purescale解决一致性问题,存储可以用诸如gpfs,vplex等产品解决
交行531核心系统用的是soa架构,不敢妄谈soa架构需要注意的问题,只说说我们系统目前的问题。问题1:组件设计大多不合理,因为我们有一个组件复用度的考评,导致有些组件包含的功能太多,反而不容易维护。问题2:性能问题,组件化后,
我觉得副中心不一定要能接管所有业务吧,切换到副中心时考虑关闭一些相对不重要的应用或交易,以交行为例核心系统目前金融类交易只占交易量的10%,副中心接管时可以关闭一些查询交易,只要保证全部金融交易和个别重要的查询
目前集群数据库应该是不行的,以gdpc架构为例,70公里距离一个insert的响应时间就会增长10多倍,commit时间也会大幅度增长
mq的话应该可用通过mq gateway+mq cluster的集群通道和集群对列实现双中心的负载均衡和双活,http倒是有f5负载均衡器什么的现成产品,O(∩_∩)O,还有为何要统一入口?
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30