Elektronika 2009-11.pdf - Instytut Systemów Elektronicznych

[4] Bose A., i in.: Analysis of manufacturing blocking systems with
Network Calculus. Performance Evaluation, vol. 63, pp. 1216-
1234, 2006.
[5] Economou A., Fakinos D. Product form stationary distributions
for queuing networks with blocking and rerouting. Queuing Systems,
vol. 30(3/4), pp. 251-260, 1998.
[6] Gomez-Corral A., Matros M. E. Performance of two-stage tandem
queues with blocking: The impact of several flows of signals.
Performance Evaluation, vol. 63, pp. 910-938, 2006.
[7] Gupta U. C., i in. Discrete-time single-server finite-buffer under
discrete Markovian arrival process with vacations. Performance
Evaluation, vol. 64, pp. 1-19, 2007.
[8] Kim C. S., i in. The BMAP/G/1-> ·/PH/1/M tandem queue with
feedback and losses. Performance Evaluation, vol. 64, pp. 802-
818, 2007.
[9] Mei van der R. D., i in. Response times in a two-node queuing
network with feedback. Performance Evaluation, vol. 49, pp. 99-
110, 2002.
[10] Oniszczuk W. Analysis of an Open Linked Series Three-Station
Network with Blocking. In Advances in Information Processing
and Protection, J. Pejaś, K. Saeed (Eds), Springer: New York,
pp. 419-429, 2007.
[11] Stewart W. J. Introduction to the Numerical Solution of Markov
Chains. Princeton University Press: New Jersey, 1994.
A system automating repairs of IT systems
(System automatyzujący naprawy systemów IT)
MSc MAREK KAMIŃSKI
Gdańsk University of Technology Technology, Faculty of Electronics, Telecommunication
Lufthansa Systems Poland, Sp. z o.o., Gdańsk
Very fast and progressive informatization of almost all domains
of our lives became an undisputed fact. Because huge
number of IT systems of various kinds needs supervision and
maintenance 24 hours a day and 365 days a year, many IT
companies provide nowadays to their customers a new service
offer of remote monitoring, technical support and assistance
in taking care of their systems.
Monitoring is relatively easy in realization because lots of
monitoring systems have been already developed [1] and they
usually accomplish their task in a satisfactory way. We distinguish
traditional monitoring systems [2-7] (usually having centralized
monitoring logic), and ones dedicated to monitoring
grid or cluster structures [8-11] (usually having monitoring
logic distributed), but regardless of the kind of monitoring system,
monitoring aims to give administrators of monitored systems
a clear indication of what is wrong. The next step is to
solve the problem (to repair the system), so integrating monitoring
and repair aspects seems natural.
However, repairs are usually more complicated than monitoring,
as they often involve manual and time-consuming interventions
of administrators, but observations made by the
author of this article show that, in many cases, even they can
be automated and, moreover, integrated with the monitoring
task. Their automation is a complex problem, which is still the
area of active research. The already proposed solutions are
usually too trivial to handle complex repairs in the real world
situations. Others have vulnerabilities, excluding their industrial
application. Some solutions use the concept of timeouts
or retrying failed actions finite number of times, hoping the
problem will not reoccur, or the concept of event handlers
[4-6], being simple executions of remote commands [7], telling
the system which program to execute on undesired monitoring
results. Some solutions address only automation of administrative
tasks [12,13] and do not integrate with monitoring.
Other attempts focus on describing the architecture the system
should have, to facilitate automatic repair [14-16]. Also efforts
were made to integrate the Nagios Monitoring System
[4-6] with the CFengine system (in particular situation, regarding
network problems [17]), and some works show the directions,
monitoring and healing (repairing) can go [18].
Goal and context
This article focuses mainly on the Repair Management System
(RMS), that is one of the parts of the developed Repair
Management Framework, aming at automating the process
of repairing IT systems. The RMF consists also of the Repair
Management Model (RMM) and the repair library. Both of
them were formally and precisely specified, using the Z notation
[19-21] and are described in [22]. The RMM introduces
two mathematical models (model of monitoring and model of
repair processes), general enough to cover the existing problems
and solutions, while RMS, with its complex architecture,
uses those concepts as fundamentals, to incorporate and exploit
existing monitoring solutions into triggering and conducting
repairs automatically. The repair library introduces the
abstraction layer (in a form of API = Application Programmers
Interface), to allow for easy constructing of the repair algorithms,
taking advantage of the programming language, they
are embedded in, and of set of predefined routines (procedures
and function), hiding away from programmers many
unimportant details, regarding monitoring and repair of those
particular problems they solve. All parts of the RMF have been
already instantiated and are under tests in the Lufthansa Systems
Poland Company.
Definition of the solved problem
The problem addressed in this article may be briefly defined
as follows:
• IT company continuously supervises work of many objects
of various kinds,
54 ELEKTRONIKA 11/2009