一种面向用户数据的主备机倒换方法转让专利

申请号 : CN200710077196.4

文献号 : CN101394641B

文献日 :

基本信息:

PDF:

法律信息:

相似专利:

发明人 : 李群黄亚达贾清亮王茂华杨鹏举唐发明

申请人 : 中兴通讯股份有限公司

摘要 :

本发明公开了一种面向用户数据的主备机倒换方法,该方法为:a、归类需备份用的用户数据,并为其控制的用户在主机和备机建立对等用户核心数据区管理队列;b、主机侧用户进入稳定业务服务状态时,更新核心数据区队列中其所属核心数据区,标注变更标识;c、定时检索变更标识,将用户核心数据区队列中有变更的用户核心数据区备份到主机的备板上;d、备机收到用户核心数据区后,更新备机侧用户核心数据区队列,并对等恢复主机侧用户协议实例进程状态管理;e、主备机倒换,新主机将实例进程的状态转为主机状态。本发明选择用户进入稳定业务服务状态时刻为备份数据时机,保证用户协议实例进程状态一致性和稳态用户的平滑迁移,并快速回收暂态用户占用的系统资源。

权利要求 :

1.一种面向用户数据的主备机倒换方法,其特征在于,所述方法包括以下步骤:a、系统归类出需要备份用的用户数据,并为其控制的所有用户在主机和备机建立对等用户核心数据区管理队列;

b、在主机侧用户进入稳定业务服务状态时,更新核心数据区队列中其所属核心数据区,并且标注变更标识;

c、主机定时检索变更标识,将所述用户核心数据区队列中有变更的用户核心数据区备份到主机的备板上;

d、备机接收到变更的用户核心数据区后,更新备机侧用户核心数据区队列,并立刻对等恢复主机侧用户协议实例进程状态管理;

e、主备机倒换,新主机将上述实例进程的状态转换为主机状态;

所述用户核心数据队列采用主备系统内数据库子系统的表结构管理方法,以用户为单元,并对这些数据采用集中管理方式,由所述数据库子系统统一管理和调度;

所述步骤b中确定用户进入稳定业务服务状态时刻的方法为:

b1、在所述用户核心数据区队列的每个用户核心数据区单元中添加一个事务标识队列,该队列中每个事务标识都携带一把状态记录锁,将状态记录锁的值初始化为0;

b2、触发系统控制的用户状态发生迁移的流程开始,收到第一条流程入口消息的主机参与流程处理的用户协议实例进程在用户核心数据区队列的相应用户核心数据区单元中申请一个空闲的事务标识;

b3、用户流程过程中,参与流程处理的用户协议实例进程对上述事务标识携带的状态记录锁进行操作,当实例进程进入暂态时状态记录锁加1,当实例进程回到稳态时状态记录锁减1;

b4、用户流程结束,各个实例进程分别检测事务标识的记录锁的值是否为0,若为0,则表明参与流程处理的用户协议实例进程全部进入稳定业务服务状态。

2.如权利要求1所述的面向用户数据的主备倒换方法,其特征在于,步骤c中所述备份数据的同步采用增量定时同步方式,定时间隔根据话务模型来设置。

3.如权利要求1所述的面向用户数据的主备倒换方法,其特征在于,所述步骤c中,对于暂态用户,备机只需同步用户核心数据区队列中该暂态用户单元的事务标识队列。

4.如权利要求3所述的面向用户数据的主备倒换方法,其特征在于,所述步骤e中还包括:新主机查询用户对应的事务标识队列所携带的状态记录锁是否为0,若不为0表明是暂态用户,则立即释放该暂态用户,回收系统为用户分配的资源。

5.如权利要求1所述的面向用户数据的主备倒换方法,其特征在于,所述步骤e之后还包括:主备机倒换成功,主备系统的通信控制进程开放缓存的外部消息到新主机,新主机开始处理外部消息。

6.如权利要求1所述的面向用户数据的主备倒换方法,其特征在于,步骤a中所述用户数据为用户迁入系统控制管理的稳态时的特征数据,包括静态数据和动态数据。

7.如权利要求1所述的面向用户数据的主备倒换方法,其特征在于,步骤b中还包括:主机侧用户初始进入暂态时标注变更标识。

说明书 :

一种面向用户数据的主备机倒换方法

技术领域

[0001] 本发明涉及移动通信系统中设备的主备倒换方法。

背景技术

[0002] 1+1主备系统是通过设备冗余的方式实现系统可靠性、稳定性和安全性的重要措施。现代移动通信系统中,为了保证系统稳定、可靠的运行以及移动在线用户状态连续,大多采用主备保护的设计方法。在通常情况下,主设备处于正常的工作状态,从设备处于备用状态,一旦满足一定的触发条件(如操作维护人机命令倒换、主用设备出现故障或异常等)就会使原备机设备成为主机设备,原主设备则转为备用状态,这种双机状态的改变过程就是所谓的系统主备倒换的过程。
[0003] 触发主备倒换的事件可分为两类:1)版本升级,先在备用设备上实现版本升级,然后主设备主动要求倒换,从而平滑地完成版本升级;2)主设备故障引起系统的主备倒换,使系统不至于因为某个设备的意外故障而瘫痪。
[0004] 移动通信领域内主备倒换的原则应遵循:1)倒换时底层不丢消息;2)倒换时需保证在线用户能够顺利进行。一般地,完成主备平滑倒换需要主机和备机一定预处理:主机数据备份->备份数据同步到备机->备机根据数据恢复主机状态->倒换后平滑过渡到主机态。
[0005] 主备系统中的系统低层支撑主控进程负责双方进程(应用进程和通信进程)的控制和倒换时序,同时也决定数据同步操作的时序;主备系统的通信控制进程负责链路切换和通信链路上缓存消息的处理。
[0006] 目前数据备份到备板及同步到备机的方法为:分散式设计方法和集中式设计方法。分散式设计的思想是将主备数据同步分散到各个应用进程来实现,这种方法降低了统一管理同步数据的负荷,但是一旦某个应用进程信令交换某个传输发生异常,用户数据很难保持主备机状态一致。集中式数据同步设计的思想是将数据同步的工作交由系统内数据库子系统统一管理和调度,操作系统可通过一个数据同步进程集中管理和调度数据同步请求。
[0007] 数据同步时机的选择也有多种:数据及时同步、数据定时同步和倒换过程数据集中同步。1)数据及时同步是指当数据在主机上一产生马上转发给备机。若采用这种方式,为了实现动态数据的同步,要求系统有更高的消息处理能力;2)数据定时同步是指系统对主设备产生的数据,进行周期检查,看是否有数据需要同步,有则进行同步数据操作。3)倒换过程数据集中同步是指系统不采取数据及时同步,而是将数据同步全部放到主备倒换时进行,这样大大增加了倒换的时间开销。
[0008] 目前,移动通信系统中用户数据的产生依赖于参与管理的协议实例进程,而用户数据在主机板备份时机选择,以及备份到主机的备板上数据恢复主机板用户协议实例进程状态管理,通常很难确保主备机上用户各参与协议实例进程保持用户数据一致性。因而,不能确保在主备机倒换中在线用户平滑迁移到新主机上,即在线用户状态的连续性,导致在线用户在主备倒换后由于参与用户管理协议实例进程间的用户数据匹配失败而释放用户。

发明内容

[0009] 本发明所要解决的技术问题是提供一种面向用户数据的主备机倒换方法,实现在主备机倒换过程中将在线用户平滑迁移到新主机上,保证在线用户状态的连续性。
[0010] 为解决上述技术问题,本发明是通过以下技术方案实现的:
[0011] 一种面向用户数据的主备机倒换方法,所述方法包括以下步骤:
[0012] a、系统归类出需要备份用的用户数据,并为其控制的所有用户在主机和备机建立对等用户核心数据区管理队列;
[0013] b、在主机侧用户进入稳定业务服务状态时,更新核心数据区队列中其所属核心数据区,并且标注变更标识;
[0014] c、主机定时检索变更标识,将所述用户核心数据区队列中有变更的用户核心数据区备份到主机的备板上;
[0015] d、备机接收到变更的用户核心数据区后,更新备机侧用户核心数据区队列,并立刻对等恢复主机侧用户协议实例进程状态管理;
[0016] e、主备机倒换,新主机将上述实例进程的状态转换为主机状态。
[0017] 其中,所述用户核心数据队列采用主备系统内数据库子系统的表结构管理方法,以用户为单元,并对这些数据采用集中管理方式,由所述数据库子系统统一管理和调度。
[0018] 其中,所述步骤b中确定用户进入稳定业务服务状态时刻的方法为:
[0019] b1、在所述用户核心数据区队列的每个用户核心数据区单元中添加一个事务标识队列,该队列中每个事务标识都携带一把状态记录锁,将状态记录锁的值初始化为0;
[0020] b2、触发系统控制的用户状态发生迁移的流程开始,收到第一条流程入口消息的主机参与流程处理的用户协议实例进程在用户核心数据区队列的相应用户核心数据区单元中申请一个空闲的事务标识;
[0021] b3、用户流程过程中,参与流程处理的用户协议实例进程对上述事务标识携带的状态记录锁进行操作,当实例进程进入暂态时状态记录锁加1,当实例进程回到稳态时状态记录锁减1;
[0022] b4、用户流程结束,各个实例进程分别检测事务标识的记录锁的值是否为0,若为0,则表明参与流程处理的用户协议实例进程全部进入稳定业务服务状态。
[0023] 其中,步骤c中所述备份数据的同步采用增量定时同步方式,定时间隔根据话务模型来设置。
[0024] 其中,所述步骤c中,对于暂态用户,备机只需同步用户核心数据区队列中该暂态用户单元的事务标识队列。
[0025] 其中,所述步骤e中还包括:新主机查询用户对应的事务标识队列所携带的状态记录锁是否为0,若不为0表明是暂态用户,则立即释放该暂态用户,回收系统为用户分配的资源。
[0026] 其中,所述步骤e之后还包括:主备机倒换成功,主备系统的通信控制进程开放缓存的外部消息到新主机,新主机开始处理外部消息。
[0027] 其中,步骤a中所述用户数据为用户迁入系统控制管理的稳态时的特征数据,包括静态数据和动态数据。
[0028] 其中,步骤b中还包括:主机侧用户初始进入暂态时标注变更标识。
[0029] 本发明具有如下有益效果:
[0030] 本发明采用集中式和分散式结合管理模式:主机用户备份数据队列、用户数据定时同步通知备机采用集中式管理模式;备机用户数据对等恢复用户协议实例进程采用分散式管理模式,选择用户进入稳定业务服务状态时刻为备份用户数据时机,保证备份用户数据时用户协议实例进程状态一致性。有效保护主备倒换后稳态用户平滑迁移,并尽最大可能地快速回收暂态用户所占用的系统资源。

附图说明

[0031] 图1是本发明的方法流程图;
[0032] 图2是本发明的实施例主备交换方法示意图;
[0033] 图3是系统重配流程示意图;
[0034] 图4是本发明中事务记录锁算法流程图。

具体实施方式

[0035] 下面结合附图和具体实施例对本发明作进一步详细的描述:
[0036] 本发明是通信系统中设备1+1式的热备份方法,主要解决用户级数据的1+1热备,使得系统发生主备倒换后在线用户最大可能不受影响,保持正常工作状态。
[0037] 为达到上述目的,本发明主要通过以下几步来实现(如图1示意方法流程图):
[0038] A、归类出需要备份的用户数据,这些用户数据是指用户迁入系统控制管理的稳态(简称:稳态用户,与此相反就称为暂态用户)时的特征数据,它包括静态数据和动态数据。这些数据总称为用户的核心数据,系统为其控制的所有用户在主机和备机建立对等用户核心数据区管理队列;
[0039] 静态数据一般是储存在系统数据库中,可以采用在主机侧带一定主键标识同步到备机检索系统数据库而获取的。动态数据,是主机侧系统用户协议实例进程控制用户状态变迁进入稳态后产生的特征数据,由各用户的协议实例进程自己保存。
[0040] 稳态用户指用户一直处于在线服务连接状态,除了用户移动状态监视测量控制消息外,系统所有参与控制用户的协议实例进程都处于服务稳态-服务时连续保持的状态;暂态用户是指系统参与控制用户的协议实例进程处于状态跃迁过程中。
[0041] 系统用户核心数据区数据完全可以恢复一个用户的网内无线特征、网元间传输特征以及设备系统内通信的特征,并且能反映用户在主机侧控制用户协议实例进程状态。本发明对这些数据采用集中管理方式,通过表结构管理,由数据库子系统申请用户核心数据管理队列区,以用户为单元,用户标识作为表记录索引,数据库系统为协议应用进程提供的接口,包含创建用户实例进程时申请用户核心数据区、实例进程状态进入稳态修改用户核心数据区记录时进行查询用户核心数据区、系统释放控制用户的实例进程时删除记录通知等接口。
[0042] B、在用户进入稳定业务服务状态时将用户核心数据区备份到主机的备板。
[0043] 备份用户数据时机是以用户进入稳定业务服务状态为写入时刻。从系统侧看就是参与用户协议处理实例进程全部进入服务稳态,而实例进程进入稳态有先有后的,因此本发明规定最后一个参与信令交换的协议处理实例进程进入服务稳态的时刻为写入时刻。如果各个导致用户状态变化信令流程消息交换对参与用户的协议实例进程状态符合串行化(即:最后一条确认消息发送到单一进程迁移状态),很容易确定写入时刻;然而这一写入时刻在系统内信令交互流程设计中往往不易判定进入稳态的实例进程,例如图3所示一个系统重配流程设计:
[0044] 301、实例进程3触发请求对UE(User Equipment用户设备,以下简称UE)进行资源重配置,请求消息发送至实例进程2;
[0045] 302、实例进程2判决后转发请求消息给实例进程1;
[0046] 303、实例进程1收到消息,检测资源重配置可以执行,给实例进程2发出重配执行命令;
[0047] 304、实例进程2组织网元间标准消息发送至UE进行重配置,成功后发送响应消息;
[0048] 305、实例进程2收到UE配置完成消息,实例进程2分发配置成功证实消息6给实例进程1和成功证实消息7给实例进程3;
[0049] 306、重配置结束。
[0050] 从信令流程看实例进程2首先进入稳态,发送证实消息给实例进程1和实例进程3,当两个进程收到消息进入稳态时就是用户核心数据队列更新时刻。但是消息6和消息7谁最后收到消息取决于底层支持系统消息调度机制,应用进程只能通过查询才能确认,这就需要在实例进程间增加消息交互,显然延迟了更新和信令处理效率。同时当出现并发信令流程时,依靠查询难以辨别是实例进程状态迁移是由哪个流程导致的。
[0051] 为了解决该问题,本发明提出了一种事务锁算法,如图4所示:在用户核心数据区队列的每个用户单元内添加一个TransactionID(事务标识)队列,每一个TransactionID都携带一把CountLock(状态记录锁),该锁负责记录参与流程处理的用户协议实例进程状态迁移。CountLock初始值设为0。UE流程开始时,收到第一条流程入口消息的系统协议处理实例进程在UE核心数据队列的相应用户单元中申请一个空闲TransactionID,该TransactionID就是本次流程的事务号,将伴随系统流程消息传递,让每一个参与流程处理的实例进程对TransactionID携带的CountLock进行状态登记(操作同一事务状态锁)。当实例进程因消息触发迁移到暂态时CountLock加1,收到响应消息后状态迁移到稳态时CountLock减1,这样在流程交互过程参与处理的用户协议实例进程状态随着收发消息,最终CountLock因为所有参与处理的实例进程都进入稳态而回到初始值0,这时就唯一确定了用户核心数据区写入更新时刻。
[0052] C、将上述备份的用户核心数据同步到备机。
[0053] 主机侧用户核心数据与备机侧的同步采用增量定时同步方式,定时间隔按照话务模型设定(即:间隔时间内用户核心数据发生改变和新增的粒度)。用户核心数据的定时同步包括变为稳态的用户和初始进入暂态的用户。暂态用户数据定时同步到备板,使得备机在主备倒换过程知道当前暂态用户信息,转为新主机后及时作系统资源回收处理,即使主机出现拔板、掉电等异常状况,备机也能对暂态用户及时处理。暂态用户数据只同步其核心数据区中的TransactionID。如果发生主备倒换,备机侧查询UE核心数据TransactionID,只要CountLock不为0表明是暂态用户,就立即作资源回收处理(即:将系统为暂态用户分配的资源立即释放)。
[0054] D、备机接收到变更的用户核心数据后,更新备机侧用户核心数据区队列,并立刻对等恢复主机侧用户协议实例进程状态管理
[0055] E、主备机倒换时,备机恢复用户协议实例进程的主机状态,稳态用户平滑迁入新主机管理控制,不受设备异常影响;对于倒换中的暂态用户(在线的状态正在变更或新接入用户),其中那些不影响系统无线资源、不会导致传输资源阻塞的用户,倒换后做状态保护处理,除此之外,考虑到判别参与处理应用进程状态复杂而且代价大,采取立即将这些用户释放,尽快回收系统资源。
[0056] F、主备倒换成功后,主备系统的通信控制进程开放缓存的外部消息到新主机,新主机开始处理外部消息。
[0057] 下面为本发明的一个实施例,其实现方法如图2所示:
[0058] 设定场景:
[0059] TD-SCDMA(Time Division-Synchronous Code Division MultipleAccess时分同步码分多址)系统中的RNC(RADIO NETWORKCONTROL,无线网络控制器,简称RNC)设备,RNC ID 1001系统内用户呼叫处理单板M;UE通过RNC系统呼叫建立连接后处于服务稳态,M板上建立用户协议处理实例进程1、2和3;RNC系统为UE生成标识UEId=1。
[0060] 具体实现步骤如下:
[0061] 步骤201:UE在M主机板请求接入建立呼叫连接时,系统收到请求消息后为用户建立相应的协议实例进程1、2和3,生成UEId=1,并且以UEId为索引在核心数据队列中申请备份用户核心数据区;
[0062] 步骤202:RNC的资源管理(Radio Resource Mangerment,以下简称RRM)或外部网元消息触发系统内UE相关实例进程状态变更流程,因此影响了用户核心数据区改变。本例为RRM触发对UE的无线资源进行重新配置流程(如图2所示),重配流程开始,收到第一条流程入口消息的实例进程3在用户核心数据区申请空闲TransactionID,实例进程3发信令1请求消息且状态迁移到暂态CountLock++,信令1请求消息携带TransactionID;
[0063] 步骤203:实例进程2收到信令1判决后,发送信令2给实例进程1且迁移至暂态CountLock++,信令2请求消息携带TransactionID。
[0064] 步骤204:实例进程1收到信令2请求消息,检测系统资源是否满足重配置需求,如果满足给实例进程2发出重配执行命令信令3消息且迁移至暂态CountLock++,信令3判决响应消息携带TransactionID。
[0065] 步骤205:实例进程2收到信令3判决响应消息,组织Uu口RRC信令PHYSICAL CHANNEL RECONFIGURATION发送至UE进行重配置,实例进程2状态迁移暂态CountLock++,消息中不携带TransactionID。
[0066] 步骤 206:UE配 置成 功 发送 RRC信令 PHYSICAL CHANNELRECONFIGURATION COMPLETE给实例进程2,实例进程2状态迁移至稳态CountLock--,同时分发配置成功证实消息6给实例进程1和成功证实消息7给实例进程3;
[0067] 步骤207:实例进程1和实例进程3分别收到证实消息,将状态迁移至稳态CountLock--。实例进程1和实例进程3由于都处于流程截至点,先后取决于底层支撑消息调度机制,故他们需要各自检查CountLock是否为0。等于0说明是该实例进程最后一个进入稳态,它就具有更新核心数据区权力(即核心数据写入时刻),本例为实例进程3。
[0068] 步骤208:实例进程3执行完UE核心数据区更新后,给数据库表打上失步标签。数据库子系统定时查询失步标签,进行备机同步操作。
[0069] 步骤209:M备机收到来自主机侧定时同步的用户核心数据后,如果是稳态用户,立刻对等恢复备机侧参与用户协议实例进程(实例进程1、实例进程2和实例进程3);如果是暂态用户,在暂态队列中保存标识信息。
[0070] 步骤210:如果UE再次被触发进入状态变更流程,重复按照步骤202-步骤209数据更新设计模型;如果发生主备倒换执行步骤310。
[0071] 步骤211:一旦发生倒换备机侧参与用户协议实例进程的状态转换为主机状态。在线稳态用户不受设备异常影响平滑迁移新主机,暂态用户被立刻发起释放处理,尽快进行系统为其分配的资源回收。
[0072] 步骤212:主备倒换成功通信控制进程开放缓存的外部消息到新主机。系统用户协议实例进程迁移到主机状态开始处理外部消息,不处理备机消息了。
[0073] 以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等,均应包含在本发明的保护范围之内。