面向未来的同城双活中心网络架构建设

2013年,光大银行在保持“同城双活”数据中心的灾备模式下,进一步完成了面向未来大型数据中心的新一代网络架构改造。除有效解决大型数据中心实现“同城双活”灾备模式的技术瓶颈外,光大银行新一代网络架构更多面向应用的创新特性也使得数据中心网络具备了更好的业务适应性、可扩展性和业务交付效率,     

持续完善灾备体系建设，为业务拓展和服务创新保驾护航

为进一步提升信息系统灾难恢复能力,工商银行积极研究、利用先进技术,启动了“两地三中心”程建设。根据规划,2014年将在上海嘉定建立同城数据中心,与上海外高桥数据中心构成同城双中心,同城双中心整体与北京异地灾备中心组成异地灾备模式,     

基于超融合架构同城灾备的建设探索

随着商业银行经营规模的不断扩展,IT基础环境抗灾能力和业务系统的连续性级别将成为未来数据中心建设中的重要工作。本文从技术实现和成本投入的角度入手,介绍了中国民生银行郑州分行基于超融合架构建设同城双活数据中心的方案,为广大同业建设同城灾备提供参考。     

灾备建设与TIA942标准的应用

正杨兵兵:光大银行将继续坚持以数据零丢失和"本地双活、异地灾备"为原则,以TIA-942 Tier4标准为依据,高标准、高质量地建设远期数据中心,在现有基础上进一步完善灾备体系,提高灾备中心的灾难恢复能力。灾难备份建设是一项复杂的系统工程,不仅涉及技术和业务方案,还涉及应对特殊事件的组织、协调、管理等方面内容。为防范灾难和风险,国内商业银行相继建立了同城和异地灾备中心,"两地     

人民银行省级单位灾备中心网络设计

本文基于对所在单位现有同城通信转接中心的现状分析,提出了实现应用级灾备目标的网络方案.该方案考虑了各种设计要素,包括数据中心高层模式、数据复制技术、客户端切换技术以及灾备中心互联技术.其中,数据中心高层模式采用双活或者热备的方式,客户端切换技术采用智能化DNS设备切换技术,灾备中心互联技术采用前端客户端访问和后端存储互联分开.     

构建“两地三中心”科技新架构工商银行业务连续性实现新飞越

2014年6月,中国工商银行股份有限公司（以下简称＂工商银行＂）上海嘉定同城数据中心正式投产启用,并在全球同业率先成功开展数据中心同城双中心全业务切换运行,所有核心主机业务可实现分钟级从生产中心切换至同城中心,并在平稳运行24小时后成功回切。＂两地三中心＂科技新架构的建成,是工商银行数据中心建设史上的一个重要里程碑,实现了从传统信息系统灾备恢复模式向双中心同时运行的业务连续模式转型。     

从实际出发建设具有特色的灾备体系——访中国光大银行股份有限公司信息科技部副总经理史展

随着新技术的不断发展，特别是“云”概念的广泛应用，未来银行灾备体系的建设策略将打破传统思路，数据中心可以考虑向“多活”和“分布式”方向发展。数锯“大集中”可以从物理集中走向逻辑集中，即把全国各地数据中心虚拟化整合到一起。当然，这不仅有赖于与“云”相关技术的不断成熟，同时更需要银行在应用软件技术架构上的转型。     

思科:数据中心容灾架构的两种新方案

随着虚拟化和云计算等技术在数据中心的广泛应用,目前国内外很多企业和IT厂商都在探索双活数据中心和新一代基于云计算的分布式虚拟化数据中心架构及相关技术,以应对传统数据中心容灾架构所面临的挑战。1.双活数据中心整体架构双活数据中心的建设从技术层面主要可分为四个层面:网络、存储、数据库、客户端切换。(1)网络①数据中心的二层扩展:在双活数据中心架构下存     

银行数据中心灾备体系建设与管理的思考

随着近年来数据中心的建设和发展,越来越多的行业加强了对灾难备份技术的研究。银行在人们日常生活中充当着重要角色,目前银行数据中心建设仍然处于多活动中心的初级阶段,在进行银行数据中心灾备体系建设的下一个建设目标是有序的开展银行数据中心灾备体系建设系统的升级改造,促使银行生产办公系统能够长效稳定运行,促进银行数据中心灾备体系能够稳步的进行建设与管理。     

银行多活数据中心网络关键技术研究

目前,传统的银行数据中心正在进行变革,加速从＂两地三中心模式＂（生产中心、同城灾备中心和异地灾备中心）向多活中心转变。多活中心是指多中心之间没有明确的主备之分,每个中心都有生产并互为灾备的任务。这种转变可以解决传统模式存在的问题。一是提高设备利用率。灾备中心只做数据备份不接管业务,投资回报率低;多活中心不再设置专用的灾备资源,不同中心的资源同时承担生产和灾备人物。二是实现最高级别的可用性。     

基于VXLAN的央行省级数据中心大二层网络探索与研究

<正>目前,省级人民银行数据中心通常由主中心和同城通信转接中心组成,所有业务系统均由主中心承载,转接中心仅实现了网络级"双活"。随着人民银行信息化建设的不断发展及分布式架构转型战略规划的持续推进,各省级人民银行服务器虚拟化技术广泛应用,大量业务系统已由传统物理机向虚拟化平台迁移,而要实现基于虚拟化平台的业务"双活"建设,满足重要业务系统容灾需要,构建真正意义上的"双活"数据中心已迫在眉睫。     

大型数据中心＂双活＂应用探析

随着信息技术在金融业的深化应用,国家和社会公众对金融信息系统的业务连续性及数据安全提出r了很高要求。近年来各金融机构不断加大投资和建设力度,在灾备中心建设方面取得了很大进展。随着同城、异地灾备中心的建成,新的问题也逐渐出现：传统主备模式的容灾中心设计资源利用率不高、切换难以较高保证成功率、人员不能得到充分锻炼等问题一直困扰着大家。随着虚拟化和“云计算”从概念走向成熟应用,双运营中心和双活中心的设计逐步受到关注,并开始在这个方向上进行探索和尝试。下面笔者从建设双活应用系统入手,以探求双活数据中心的可行性和建设路径。     

同城备份中心运行应常态化

交通银行数据中心近年来致力于打造服务集团、境内外一体化、业界领先、设施完善的灾难备份体系。数据中心规划中明确定位了“两地三中心”一体化灾备体系。“两地三中心”包括：张江数据中心、漕河泾同城副中心和武汉异地灾备中心,三个中心的功能定位如下。     

优化布局保安全

邮储银行非常重视灾备系统建设工作.早在2006年,在邮储银行成立前就建成了北京牛街同城灾备中心,先后建设了储蓄全国中心、电子汇兑、国际业务、代理基金等同城应用级灾备系统. 2011年,我行开始建设北京亦庄数据中心,2014年5月正式投入使用,主要作为我行同城灾备中心,同时兼顾部分生产中心功能.2014年10月,完成储蓄逻辑集中等7个核心系统的同城应用双活灾备建设.     

青云北京3区正式运营

本刊讯日前,企业级基础云服务商青云QingCloud在北京举行22016新年发布会,宣布采用区域多活网络架构的北京3区正式上线运营,并发布SDN／NFV2．0网络技术,青存QingStor对象存储服务也于同期启动公测。北京3区是青云第五个自营公有云区域,它由三个独立的数据中心构成,采用多路环形BGP骨干网,能够轻松实现同城双活或多活、异地备份与容灾等实用功能。配合SDN／NFV2．0技术,帮助用户实现超大规模、超高性能、功能完备的组网能力。     

汉口银行西安数据中心建成开展异地灾备应急演练

本刊讯近日,汉口银行西安数据中心建成,并开展了全行系统灾备应急演练.此次演练全面检验了汉口银行西安数据中心的可用性和数据的完整性,同时有效提高了该行应对系统突发事件的综合能力.汉口银行的灾备数据中心建设于2010年启动.采用国际先进的数据同步技术,按国家容灾规范的5级标准建设.灾备恢复指标达到了国内银行的一流水平,基本...     

深圳农商行打造武汉数据中心

正灾备中心建设涉及基础环境、技术、网络和生产管理等因素,是银行业务持续性和信息安全应急工作的重要环节,对于保障国家经济、金融安全有重大意义。早在2010年9月,深圳农村商业银行就启动了武汉异地灾备中心的规划建设,经过3年的持续努力和工作推进,2013年5月武汉数据中心建成投产,基本实现了"深圳生产中心+深圳同城灾备中心+武汉异地数据中心"的"两地三中心"运维格局,提     

国家外汇管理局省分局网络升级技术实现方案

根据国家外汇管理局推广“外汇管理信息系统”(SAFE—MIS)的技术要求，各省分局需建立省级数据中心，对省域外汇管理数据信息进行集中。新的系统运行模式改变了以往省、地市两级外汇管理部门应用系统在技术架构上的对称性，对网络传输平台在传输总带宽、应用系统对网络带宽占用的可管理性和传输可靠性等方面提出了更高的技术要求。     

构建同城“双活”灾备体系,推动农商行业务创新发展——访昆山农村商业银行科技管理部总经理吴雪华

随着利率市场化加速推进,金融业竞争也日趋加剧,中小银行迫切需要利用自身优势,通过业务创新,获得发展先机。而业务创新的推动,也对银行IT系统的可用性、连续性和安全性提出了越来越高的要求。为此,越来越多的商业银行开始采用双活数据中心,希望在成本可控的情况下,进一步提高系统的可用性和灵活性,完善灾备体系。从早前的双热备到现在的双活数据中心,双活技术在银行数据系统的应用越来越普遍,不仅仅是工商银行、光大银行等大中型银行,     

灾备一体化系统全覆盖

华夏银行已完成以北京亦庄为生产中心、西三旗为同城灾备中心,苏州为异地灾备中心的"两地三中心"灾备建设,目前正在实施灾备架构优化,从"大异地"向"多中心并重"的方向持续优化演进. 目前,我行异地灾备中心实现了支撑全部重要业务的38套系统的应用级灾备及其余全部系统的数据级灾备(系统恢复时间RTO＜1小时、数据保护级别RPO＜5分钟);同城灾备实现了总行19套关键重要系统的应用级灾备和全部系统的数据"零丢失"保护(系统恢复时间RTO＜30分钟、数据保护级别RPO=0).