WO2006081953A1

WO2006081953A1 - Method for mirroring relational data

Info

Publication number: WO2006081953A1
Application number: PCT/EP2006/000488
Authority: WO
Inventors: John Curran; Sushil Kulkarni; Stephen Lorusso; Srinivasan Subbaiyan; Medha Vedaprakash; Jun Xu
Original assignee: Nokia Siemens Networks Gmbh & Co. Kg
Priority date: 2005-02-01
Filing date: 2006-01-20
Publication date: 2006-08-10
Also published as: EP1846823A1

Abstract

Currently, software systems which require the simultaneous mirroring of relational data to a backup processor (BKP) have the drawback that the involved modules (M1, M2, M3, M4) get tightly coupled. The method according the present invention comprises an additional module (RDM) for managing the mirroring of the relational data to the backup processor (BKP); and by the additional module (RDM) : assigning to the group of modules (M1, M2, M3, DB) a key (K&lowbar;A) to an hyper-frame (HF&lowbar;A); bundling the relational data as hyper-elements (HE1, HE2, HE3, HE4) within the hyper-frame (HF&lowbar;A); and triggering said bundled data hyper-frame (HF&lowbar;A) to said back-up processor (BKP).

Description

Method for mirroring relational data

The present invention relates to a method according the preamble of claim 1.

In datacom networks , the delivery of a service may be interrupted due to hardware or software failures . In order to ensure quality of service, service providers require systems to be as reliable as possible and as failure- safe as possible . Since the failure of an entity is an event impossible to be avoided, widely used methods make use of redundancy.

Known methods for redundancy employ a standby or backup processor that gets updated and synchronized with the data coming from an active or primary processor . Data is replicated from the primary processor to the backup processor through a mirroring process . The backup processor is configured to have enough knowledge to take over and resume operations seamlessly in an event of failure of the primary processor .

As embedded CPUs have become more powerful , solutions that involve very large software developments have become widely spread. The natural choice in designing large software systems is to take advantage of obj ect-oriented software design principles .

Unfortunately, the use of object-oriented architectures is problematic in software redundant systems since such systems have the need of mirroring spatially dispersed data that may be relational in nature.

In general , object-oriented designs have data structures contained within and spread across many software modules .

Such data structures are purposely hidden from other modules as a way to protect the data . However, these pieces of data in different modules may be related and may need to be mirrored simultaneously to the back-up processor.

For example, a group of software modules , each one performing a different specific rule, may be required as a whole to perform a giant rule (e. g. a telephone call , an update to a database) . In such an example, the data structures required by such group of modules may become related to each other and, consequently, in a mirroring operation, such relational data need to be moved in a simultaneous manner to the back-up processor .

In a mirroring operation, it is inherently important to move over spatially dispersed pieces of data in a one-shot operation and present to the backup processor a reliable snapshot of the entire data representation, which may be, for example, required for the performance of the giant rule.

If a simultaneous bundled mirror operation is not performed, complicated cleanup procedures need to be evolved on the backup processor to regain sanity of the relationship of data on events of processor switchovers .

Unfortunately, in known methods for mirroring relational data, the requirement of simultaneous mirroring leads to the tight coupling of the different modules that use the same relational data .

The coupling of software code creates a breakdown of the modularization and independent layering of the original system design.

It is therefore the aim of the present invention to overcome the above mentioned drawback, in particular by providing a method for mirroring relational data in a simultaneous operation while keeping the involved modules de-coupled and independent . The aforementioned aim is achieved by a method defined by the steps of claim 1.

The proposed method may be utilized in small to large software systems requiring the mirroring of relational data .

Moreover, the proposed method may be utilized in software systems employing object oriented design principles .

Embodiments of the present method, having certain advantages , are given in the dependent claims .

The invention will now be described in preferred but not exclusive embodiments with reference to the accompanying drawing, wherein:

Figure 1 a block diagram illustrating the method for mirroring data to a backup processor in an example embodiment according to the present invention.

Figure 1 shows different generic modules Ml , M2 , M3 , DB which contain relational data to be mirrored to a backup processor BKP . Examples of modules Ml , M2 , M3 , DB may be applications , services , layers and databases .

Element RDM is a relational data manager that enables a general function and/or its internal elements Ml , M2 , M3 , DB to create a relational data bundle also called hyper-frame HF_A to generate a reliable snapshot of pertinent data to be transmitted to the backup processor BKP . An example of a general function may be a telephony application that handles voice over IP protocols , an airline reservation application, a stock market trading application or any other function of a software system which requires data redundancy. Examples of internal elements Ml , M2 , M3 , DB may be software modules such as databases , services , layers that perform distinct specific functions , inside the general function, and contain relational data to be replicated to the backup processor BKP .

The relational data manager RDM creates the relational hyper- frame HF_A having at least one hyper-element HEl . The hyper- frame HF_A holds the representation of relational data by collecting each relational data provided by each independent software module Ml , M2 , M3 , DB .

Each relational data coming from each module Ml , M2 , M3 , DB HF_A gets attached to one of the hyper elements HEl , HE2 , HE3 , HE4 of the relational bundle hyper-frame HP_A.

In a further embodiment of the present invention, additional modules Ml , M2 , M3 , DB may attach to the hyper frame HF_A seamlessly. In fact, the relational data manager RDM may accept additional data coming from other additional software modules and dynamically allocate an additional data part of a hyper-frame HF_A. Thus , the number of hyper-elements HEl , HE2 , HE3 , HE4 attached to the hyper-frame HF_A may be increased in a scalable way. For example, as the code base grows , other hyper-elements may be attached to the hyper- frame HF_A without affecting the already existing hyper- elements HEl , HE2 , HE3 , HE4.

The relational data manager RDM uses a key based mechanism to tie the data bundle HF_A together . A key K_A, K_B, K_C uniquely identifies a chosen hyper-frame HF_A, HF_B, HF__C, and is used by independent software modules Ml , M2 , M3 , DB to access the same hyper frame HF_A.

The relational data manager RDM may provide APIs or functions to perform tasks such as setup, get a key K_A to the hyper- frame HF_A, update hyper-element HEl , HE2 , HE3 , HE4 to provide relational data and trigger the data bundle HF_A for transmission to the backup processor BKP . In a setup task, the relational data manager RDM initializes a relational data mirroring instance by allocating memory and setting up an initial context .

In a get a key task, the relational data manager RDM provides a new key K_A that indexes to a new hyper-frame HF_A, see in Figure 1 arrow rgk_f which represents the function RDM get a key.

In a further embodiment according the present invention, the relational data manager RDM may be advantageously instantiated to support several concurrent sessions from several groups of modules Ml , M2 , M3 , DB that perform several general functions , each of such group utilizing one hyper frame HF_A, HF__B, HF_C indexed by a key K_A, K_B, K_C . In

Figure 1 , it is shown an example of a single group of modules Ml , M2 , M3 , DB performing a single general function and thus linking to a single hyper-frame HF_A. In case a new general function is performed, the relational data manager RDM, when requested through the get key instance rgk_f, provides the requesting module with another key K_B, K_C from its pool of keys PK so that the new related group of modules is able to access the new free hyper-frame HF_B, HF_C .

In a update hyper-element HEl task, a specific software module belonging to the group of modules Ml, M2 , M3 , DB, performing the general function, may invoke the API RDM add data rad_f for bundling the relevant data of the module into the hyper-frame HF_A as hyper-element HEl , HE2 , HE3 , HE4.

In a trigger operation, the data bundle is triggered for transmission to the backup processor BKP when all independent software modules Ml, M2 , M3 , DB, which are all related to the same particular general function, have completed to add their concerned data into the hyper frame HF_A. The invoked RDM trigger function rtd_f mirrors the bundled hyper-frame HF_A all together. Such trigger operation transmits the hyper frame HF_A in a single operation to the backup processor BKP . The trigger API rtά_f may be invoked by any of the specific modules Ml , M2 , M3 , DB . In a further embodiment of the present invention, the API rtd_f may be invoked by an audit function running in the background.

The proposed invention advantageously frees the software modules Ml , M2 , M3 , DB from being tight inter-coupled. In fact, as data coming from layers , modules or databases Ml, M2 , M3 , DB that need to be mirrored get added, they merely add on to the bundle HF_A using the relational data manager RDM without disrupting other existing entities . Tight inter- coupling exist when, for example, three modules containing data that need to be mirrored at the same time, and, when it is time for mirroring in the code path of the first module, the first module has to grab data from the other two modules before performing the mirror operation. Instead, with the proposed invention, each module Ml, M2 , M3 , DB adds data to the hyper-frame HF_A independently and, advantageously, the churn in proven and tested code is reduced.

Moreover, with the proposed invention, when in a new module Ml , M2 , M3 , DB it is added code to allow data bundling, the other existing modules Ml , M2 , M3 , DB do not have to be changed.

In a further embodiment of the present invention, the relational data manager RDM may comprise a built in ageing manager to handle, log and cleanup any un-triggered lingering key K_A, K_B, K_C that may be left in the relational data manager RDM due to bugs in the application software . Lingering keys K_A, K_B, K_C are keys that were obtained by a user of relational data manager RDM and that were not returned back to the relational data manager RDM. If lingering keys are not cleaned up, the pool of keys PK of the relational data manager RDM may get exhausted and this may prevent further mirroring operations . Un-triggered keys K_A, K_B, K_C may be recognized by periodically auditing the relational data manager RDM data and by determining the age of a key K_A, K_B, K__C . A key K_A, K_B, K_C which is persisting beyond the auditing criteria is freed up .

Conveniently, the present invention allows to efficiently override data provided by a specific module Ml , M2 , M3 , DB prior to a trigger operation using the same key K_A. In fact, the fact that the proposed inventive mirroring method comprises two distinct steps , one for data bundling and one for data triggering, leads to the advantage that several bundling sessions , in which the snapshot of the relational data is updated, may be invoked without incurring in an expensive mirror operation . In fact, the mirroring to the backup processor BKP occurs only when the triggering function is performed (which is a CPU/time expensive process ) . Thus , frequent updates of the bundle HF_A do not result in a complete mirror operation but just in a refresh of the relational data bundle HF_A to be mirrored.

In addition, the proposed invention advantageously enables calls to the relational data manager RDM APIs rgk_f, rad_f, rtd_f , to be placed in a common location within one module Ml , M2 , M3 , DB instead of being placed, in a scattered way, throughout the code base . Such common locations may be central places of the module code structure from where other logic conditions branch out . This further advantage leads to a more readable, maintainable and predictable way of designing the software modules Ml , M2 , M3 , DB .

The skilled in the art easily understand that that present invention may be utilized in various modes of redundant systems , such as in 1 : 1 redundant systems ( i . e. one backup processor for one primary processor) or in 1 :N redundant systems (i . e . one backup processor for N primary processors) .

List of reference signs

BKP backup processor HEl ..HE4 hyper element

HF_A..HF_C hyper-frame, relational data bundle

M1..M3 , DB module, generic software module

PK pool of keys rad_f RDM add data function, RDM add data API

RDM relational data manager rgk_f RDM get key function, RDM get key API rtd_f RDM trigger data function,

RDM trigger data API

List of acronyms

API application program interface CPU central processing unit

Claims

1. A method for mirroring relational data in a software system, wherein, in said software system, a group of specific modules (Ml , M2 , M3 , DB) perform a general function running on a primary processor; wherein said group of modules (Ml , M2 , M3 , DB) make use of relational data to perform said general function; wherein said relational data are mirrored from said primary processor to a backup processor (BKP) ; said mirroring method characterized in that it comprises :

- an additional module (RDM) for managing the mirroring of said relational data to said backup processor (BKP) ; and - by said additional module (RDM) , assigning (rgk_f) to said group of modules (Ml , M2 , M3 , DB) a key (K_A) to an hyper-frame (HF_A) ; said mirroring method further comprising the steps of :

- by said additional module (RDM) , bundling (rad_f) said relational data as hyper-elements (HEl , HE2 , ^'HE3 , HE4 ) within said hyper-frame (HF_A) ; and

- by said managing module (RDM) , triggering (rtd_f) said bundled data hyper-frame (HF_A) to said back-up processor (BKP) .

2. The method according to claim 1 , wherein said software system is a redundant system.

3. The method according to claim 2 , wherein the mode of said software redundant system is a 1 : 1 or a 1 :N redundant mode .

4. The method according to any of the preceding claims , wherein at least one module of said group of modules (Ml , M2 , M3 , DB) is selected from the group consisting of :

- applications ;

- services ; - layers ;

- databases .

5. The method according to any of the preceding claims , further comprising the step of :

- by said additional module (RDM) , dynamically defining the number of said hyper-elements (HEl , HE2 , HE3 , HE4 ) within said hyper-frame (HF_A) .

6. The method according to any of the preceding claims , further comprising the step of :

- initializing a relation data mirroring instance by allocating memory and by setting up an initial context .

7. The method according to any of the preceding claims , wherein, in said software system, more than one groups of specific modules (Ml , M2 , M3 , DB) perform more than one general functions .

8. The method according to claim 7 , further comprising the step of :

- by said additional module (RDM) , supporting several concurrent session from said more than one groups of specific modules (Ml , M2 , M3 , DB) by assigning a different key to a different hyper-frame (HF_A, HF_B , HF__C) for each different group of modules (Ml , M2 , M3 , DB) .

9. The method according to any of the preceding claims , wherein said additional module (RDM) comprises an ageing manager for cleaning un-triggered lingering keys (K_A, K_B, K_C) .