Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
02200 0 10
Process Management Infrastructure
This invention relates to a process management infrastructure system for use in an
object-oriented progr~mmin~ environment, and in particular for use in a system for
monitoring the compliance with service level agreements in a telecommunications
network,.
There is a need for a system to manage service level agreements (SLAs) between
telecommunications service providers and their business customers. Part of the
management process that relates to SLAs is the comparison of the service providers'
performance vis-à-vis specific guarantees that it may provide to its customer. In packet
switched networks, unlike circuit switched networks, customers are not given a dedicated
circuit; their data is statistically multiplexed with data from other sources. Each customer
pays for a particular level of service, and it is therefore important to ensure that the
customer is receiving the level of service he has paid for. Our co-pending application of
even date describes a system for monitoring network performance relative to customer
service agreements.
The availability requirements for the system is very high. Downtime must be minimi7ecl
at all costs. The system collects time based information from various network
management systems and operation support systems. While the system is down, critical
information can be lost. Various strategies are used within the system to minimi7c the
possibility of losing information. One such strategy is to minimi7e down time.
The system indicates to various parts of the service provider's org~ni7~tion the level of
service they are providing to their customers. Individuals in customer support, sales,
network operations and senior executives rely on this information to make decisions.
The system is also expected to evolve to a point where the service provider's customers
will have access to the system. System downtime can negatively impact the customer's
perception of the quality of the service provider's operation.
To meet the above requirements, it is important that during system failures, the system
automatically attempt to recover. Failing this, the system should notify system operators
of the failure. The system should also have minim~l downtime during deployment of new
system functionality.
~ 0 2 2 0 0 o 1 0
An object of the invention is to provide a process management infrastructure which is
conducive to providing high availability of such a system.
According to the present invention there is provided a process management infrastructure
for use in an object-oriented progr~mming environment comprising process tags for
uniquely identify each instance of a process in the system.
The basic concept underpinning this infrastructure is thus the concept of a ptag or process
tag.
The invention is particularly applicable to a system for monitoring the compliance with
service level agreements in a telecommunications network, but has also application in
other environments.
The invention also provides a method of m:~n~gin~ processes in an object-oriented
progr~mmin~ environment, wherein process tags are used to uniquely identify eachinstance of a process in the system.
The invention will now be described in more detail, by way of example only, withreference to the accompanying drawings, in which the single figure is a block diagram of
a process management infrastructure in accordance with the invention.
Referring to the Figure, the process management infrastructure is composed of the
following components, which are implemented in software: a resolve command interface
( rci ) 1; a deamon process 2 named director; a simple inter process communication
component 3; a process configuration component 4; and a software logging component 5.
The system command interface 1 is the main user command interface to the processmanagement infrastructure. From this interface, a system operator can issue commands to:
start the system. These comm~n~l~ could be:
~ shutdown the system
~ get status on the processes currently running
~ start a specific process
~ stop a specific process
~ tell a process to reread its configuration
- 2 -
~ 0 2 2 0 0 o 1 0
~ tell a process to change its logging level
The main purpose of the director daemon 2 is to startup the system, restart processes that
get termin~te-l and shutdown the system. On startup, director 2 reads in the master process
file which contains the names of the processes that are to be started and monitored by
director.
The master process table has the format:
PTag Executable Narne Start Up Indicator Process Priority Process Args
The format of the configuration file which will specify the processes to start is outlined in
the following table.
Field Description
PTag Process Tag. It is used to uniquely identify each instance of a process
in the system. The PTag is to be used as the name of the config file
(with the extension .cfg) and as the name of the FIFO (with the
extension . fifo)
Executable name The name of the executable without path. The path for executables is
in a variable in the system setup config f1le (systemSetup.cfg).
Start Up Indicator This f1eld indicates whether a process is to be started up by director.
This field contains either a Y or a N. When resolve command
program starts up director, director reads its process table and will
start up all processes that have a Y in this f1eld. If resolve command
program gives director a startup all command, director starts up all
processes which contain a Y in this field. If director gets a specif1c
request to start up a process which contains an N in this field, then it
will start up the process, however it will not restart the process if the
process should exit with a restart code.
Process Priority The nice priority level of the process.
Process The argument string for the process.
arguments Note: director will put the PTag for the process into the argument
f~ 02200 010
string for the process with a -PTag flag. All processes may get the
PTag from the config file class which will parse the comm~n~l line
for process variables.
The inter process communication component 3 is a simple mechanism used to send
messages to various processes in order to control the operation of the system. This
component is implemented using the UNIX FIFO mech~ni~m. The address of a specific
process is determined by the ptag associated with that process. Two components are
provided, one to read messages and one to write them.
A message has the following components:
~ source process - the ptag of the process that is sending the message
~ destination process - the ptag of the process that is receiving the message
~ message id - an integer value which indicates what the message content is to
the receiver
~ response requested - an integer value which indicates whether the process is
expecting a reply to the message
~ size - and integer value which indicates the size of the body
~ body.- the body of the message for the process
The process configuration component is a set of object oriented classes which are
imbedded into each resolve process for the purpose of m~n~ginp configuration parameters
associated with that process. The process configuration component uses the ptag
associated with the process to deterrnine which configuration file should be read.
The software logging component 5 is a set of object oriented classes which are imbedded
into each resolve process for the purpose of providing a status and error logging facility.
The software logging component 5 uses the ptag associated with the process to determine
which file the log data should be written to.
~ specific example will now be described.
In a first scenario, process B2 dies. The following events occur to restart process B2.
~ 0 2 2 0 0 o 1 0
~ the director is notified of the process death via Unix signals.
~ the director finds the ptag associated with the dead process.
~ the director rereads the process information associated with this ptag from the
master process file.
~ the director issues a log message to inform the system operator that process B2
died and that it will be restarted.
~ the director restarts the process.
For the second scenario, assume that the system was configured with process B2 running.
It is desirable to add the functionality provided by process Al without sh~1ttin~ down the
system. The following steps are undertaken.
~ An entry is added to the master process list for the particular ptag.
~ Using rci, a startup command for that ptag is issued. Specifically, the
command is "rci startup Al"
The startup message is sent by the rci command to the director. The director reads the
master process table to obtain the process information associated with the ptag A 1.
The director starts the process Al and issues a log message to this effect using the
software logging component.
In the third scenario, the configuration of process B2 must be modified. As an example,
process B2 has a configuration parameter that specifies a specific data store. The space
rem~inin~ in this data store exceeds a maximum threshold and new information must be
placed in a new data store. The following steps are undertaken.
The parameter in the configuration file associated with process B2 is modified to reflect
the new data store where the new data items must be stored.
Using rci, a reread config command is issued to process B2. Specifically, the following
comm~n(l is issued: "rci rereadConfig B2"
The message is sent along to process B2.
Upon receiving this message, the process configuration component rereads the config file
and issues a log message to this effect using the software logging component.
~ 02200010
In the fourth scenario, the functionality provided by process B2 is no longer desired. It is
desirable to remove the functionality provided by process B2 without shutting down the
system. The following steps are undertaken.
~ The restart flag for this particular ptag in the master process list is set to 'N'
for no restart.
~ Using rci, a shutdown command for that ptag is issued. Specifically, the
comm~ncl is "rci shutdown B2'7
~ The shutdown message is sent by the rci command to process B2
~ Process B2 shuts down.
~ the director is notified of the process death via Unix signals.
~ the director finds the ptag associated with the dead process.
~ the director rereads the process information associated with this ptag from the
master process f1le and notices that the restart flag is set to no.
~ the director issues a log message stating that process B2 died and will not berestarted.
~ the system operator can then delete the entry associated with the process B2
from the master process table.
The described system thus minimi7:es the downtime
