Figure shows a small scenario with two domains
(L and R).
One hosts a web server WS and a database server DB providing
content for the web pages. The other contains the Domain Name
System DNS responsible to resolve the name of both web- and
database server. Thus, WS is said to
depend on DNS. Further, there are two users who typically
access information on the web server via web clients. They depend
on WS and--if they want to type normal URLs instead of IP
addresses--also on DNS.
The figure also depicts the mentioned dependencies between its major objects. For simplicity, it neglects all dependencies to the communication infrastructure and further sub-services. One can see that although several objects of the example depend on DNS, none of their existing implementations explicitly tells to do so and cannot be queried by management applications for this fact.
As there is no support to obtain information about dependencies
by nowadays management tools, conventional approaches
generally struggle with evaluation problems, e.g., of configuration
files (for an overview see section ).
The problem becomes worse if, e.g., the format of those files changes
with software updates etc.
In heterogeneous environments such modeling systems typically must
further be restricted to a very limited set of resource types
or vendors. The major alternative to dependency detection at runtime
would be an a priori description of the environment with its components
and dependencies, similar to what is achieved in software
engineering by the help of Architecture Description Languages
(ADL) and Module Interconnection Languages (MIL), respectively.
However, so far similar dependency
description languages have not been commonly agreed on in the
IT-network and service provisioning world.
As a consequence, dependency models are not generally used in
today's management world--although their benefits are commonly
known (section explains existing applications).
This fact leads to a lack of overview for the IT-administrators and
prevents the use of powerful management tools like event
correlators that are based on dependency models [#!gopa2000!#].
More applications are described in section
together with an overview of existing types of dependency
models.
Typical enterprise scenarios will of course be much larger than the example above. In such cases it would be hard to keep the overview even with the help of dependency models. To reduce the number of elements, respectively to restrict the model to currently interesting parts, the concept of domains is used to provide a basic means of structuring models. This allows to provide an overview on higher, e.g., business process oriented levels, and enhances visualization and understandability for the IT-managers working with them--without abandoning details on lower levels needed for proper fault diagnosis. Graphical user interfaces of management tools will typically be capable of folding and unfolding domains to navigate into sub-models, thus handling scalability of their visualization. However, this concept also needs support from the underlying modeling architecture.
To overcome the two main problems of automated modeling--the
lack of direct dependency information as well as the scalability
issues--this paper presents a new approach to gain management relevant
dependency information. Unlike conventional approaches it is designed to obtain useful
results independent of the heterogeneity of the managed environment.
It is based on two key parts. The first (covered by section
) are the underlying concepts of
dependency determination that are carried out with the help of
neural networks. However, this paper does not aim at
details about artificial intelligence like, e.g., the training
methods of our neural networks, but concentrates on modeling and
realization aspects relevant for IT-management. Thus, the second part (section
) deals with
questions of installation efforts and scalability to seamlessly
integrate the modeling into real IT-environments.
Section introduces the most important types
of models and shows their existing applications. This is followed
by an overview of the state of the art of approaches to
model creation in section
. They are analysed
by the help of a generic modeling process which also
leads to a complete set of requirements.
Our solution to meet those requirements is presented in section
.
Section
draws the conclusions of the paper.