材料七 容灾仲裁中间件的设计原理.pptVIP

中国电信集团公司 2010年04月23日 传统容灾的不可靠性 传统容灾的最大不可控因素－数据库软件bug/应用系统的硬件环境。 如果数据库生成了损坏的或缺损的日志文件，或者应用系统硬件环境出现了问题，此期间实行容灾切换，切换会失败。 不能过滤人为误操作带来的影响 应用级容灾方案 仲裁平台仲裁服务 容灾仲裁平台的模式切换控制 仲裁平台信号灯管理设计 系统状态信号灯是主系统、主仲裁、备仲裁、备系统之间状态变化的实时信息。系统状态信号灯有如下状态，1正常　0系统堵塞失去同步　2异常　3同步成功　4同步追赶中。 主备系统的值的变化范围为1,0,2,3,4。 严肃认真 周到细致 稳妥可靠 万无一失 应用级容灾 仲裁平台中间件设计原理 计费结算处 2009.11.16 主题 容灾平台中间件设计 容灾维护管理与实例 容灾建设的必要性 中国电信容灾现状 * 中国电信总部在 2007年建成容灾双中心,涉及系统包括总部计费账务,国内结算,国际清算等系统;目前已运行多年,并进行了多次演练。 应用级容灾现状 （2009） 各省公司计费类系统基本都还没有建设异地容灾系统,仅做到了本地数据定期备份；有部分省份已经开始着手规划容灾系统。 现状：目前各省采用的多是传统灾备技术，传统的数据备份技术和服务器集群技术足以避免由于各种软硬件故障、人为操作失误和病毒侵袭所造成的破坏，保障数据安全，但当面临大范围灾害性突发事件，如地震、火灾、恐怖袭击时，上述技术就无能为力了。若想迅速恢复应用系统的数据和业务运行，就必须建立异地的灾难备份系统(即容灾系统) 。 中国电信容灾现状与国际标准对标 * 费 用 恢复所需时间 (RTO) 15 Min. 1-4 Hr.. 4 -8 Hr.. 8-12 Hr.. 12-16 Hr.. 24 Hr.. Days Tier 4 – 批量/在线的数据库镜像或日志传输 Tier 3 -电子链接 ( Electronic Vaulting ) Tier 2 - PTAM + Hot Site Tier 7 – 业务系统可实现自动的系统接管 Tier 6 – 远程数据镜像, 保证数据的完整性和一致性 Tier 5 – 软件级的两地点, 两阶段提交(交易完整性) 最关键的应用 重要的应用 不重要的应用 Tier 1 - PTAM 零数据丢失 或接近零数据丢失 数分钟或数小时的数据丢失 接近24 小时 数据丢失 24-48 小时 数据丢失 总部现状 Tier 6-7之间 省公司现状 Tier 4 国际容灾的标准定义(Share 78) 启动容灾数据库 X 时间 系统下线 容灾失败 主题 容灾建设的必要性 容灾维护管理与实例 容灾平台中间件设计 * 容灾仲裁中间件平台 容灾仲裁平台功能架构 容灾仲裁平台功能介绍 按模式仲裁：根据仲裁平台的模式决定生产系统的容灾模式，而不是由生产系统自身切换模式 索引收发模块：负责主备中心多个生产系统的文件型索引文件和仲裁结果文件的收发，以及消息型索引文件的收发。 容灾CLIENT/API：由容灾仲裁平台提供的应用程序调用的API、状态初始化（角色、仲裁状态，等待仲裁平台），以及负责仲裁信息的发送。 进程管理：管理仲裁平台的仲裁进程、传输进程、切换进程等。 切换监控：根据生产系统主备中心的状况判断是否需要做切换动作 切换管理：根据切换监控的信息和人工指令自动切换主备系统的容灾模式 共享内存参数：存储参数的区域 容灾模式 仲裁服务有三种运行模式： 1、同步模式：双中心容灾运行，主中心与备中心同时开始处理业务数据，主备处理结果要仲裁成功后才能提交。同步模式能保证主备处理的业务数据及其处理结果完全一致。 2、跟随模式：双中心容灾运行，主中心先开始处理业务数据，不等备中心处理结束且不仲裁即提交业务结果；备中心后开始处理业务数据，必须与主系统处理结果进行仲裁，仲裁成功后才能提交业务结果。 3、单点模式：单系统运行，生成容灾idx和仲裁信息。单点模式无法自动形成双中心运行态，单点变容灾（同步、双边跟随、单边跟随）必须人工进行数据同步后，才能启动容灾运行，或者不同步数据，待备系统启动后通过追赶同步。 控制主系统的运行模式：同步、跟随、单点 控制备系统的运行模式：一直以同步模式运行。 容灾模式控制的演变 A：生产系统根据参数决定容灾模式，仲裁系统只负责仲裁，容灾模式控制复杂，牵涉面广。 B：生产系统只负责处理数据，仲裁平台负责仲裁和模式控制，模式控制简单，牵涉面小。 3 2 1 1 4 2 1 1 2 2 1 1 0 2 1 1 1 2 1 1 备仲裁异常，备系统堵塞 3 1 1 1 备系统追赶成功 4 1 1 1 备系统追赶中 2 1 1 1 备系统异常 0