architecture for internet is

7/29/2019 architecture for internet is

1/17

A Management Architecture for Internet Information Services

F. Stamatelopoulos, B. Maglaris

Jimma university

Jimma Institute of

Technology

Depar tment of

Elec tr ica l and

Computer Engineer ingCommunicat ion

Stream

T e c h n i c a l R e p o r t W r i t i n g

A s s i g n m e n t o n R e s e a r c h

F o r m a t

Group members

N a m e I D

1. S h a m b e l A d m a s u 0 0 7 0 8 / 0 2

2. N a o d M u l u 0 0 6 4 0 / 0 2

3. S o l o m o n G u t a 0 0 7 3 5 / 0 2

4. T e m e s g e n S e n a y 0 0 7 7 8 / 0 2

5. T a l e i f M a h a d i 0 0 7 6 5 / 0 2

6. M u s t e f a A b d u r h m e n . . 0 0 6 3 4 / 0 2

7. R e m e d a n M o h a m m e d 0 0 / 0 2

8. M u l u k e n E s h e t u 0 0 6 3 0 / 0 2

2 | P a g e


2/17

table of Contents

1 . A c k no w l e d ge m e nt . . 4

2. A b s t r a c t 5

3. I n t r o d u c t i o n 6

4. M e t h o d o f s t u d y 7

4 . 1 . A d a pt i ve m e th o d ol o g y

4 . 2 . U se r r e qu i r e me n ts

4 . 3 . U s e r i n te r f ac e r eq u i r e me n t

4 . 4 . M a na g e me n t f u n c t i o n r e q ui r e me n t ( Q o S

P a r a m e t e r )

4 . 5 . A r c hi t ec t u ra l r e qu i r em en t s

5. T h e p r o p o s e d m a n a g e m e n t f r a m e

w o r k 1 1

5 . 1 . A r c hi t ec t u ra l o v er v i ew

5 . 2 . D a ta a n d f u n c t io n a l i t y d i s t r i bu t i on

5 . 3 . I n te r ac t i on m o de l

6. C o n c l u s i o n . 1 5

7. R e c o m m e n d a t i o n . . 1 5

8. R e f e r e n c e 1 6

1 . A c kn o w le d g em en t

3 | P a g e


3/17

W e w o u l d l i k e t o t h a n k J i m m a U n i v e r s i t y a n d t h e

d e p a r t m e n t o f E l e c t r i c a l a n d C o m p u t e r E n g i n e e r i n g f o r

g i v i n g s u p p o r t f o r t h e c o m p l e t i o n o f o u r R e s e a r c h b y

p r o v i d i n g m a t e r i a l s u p p o r t .

A n d o u r h e a r t - f u l l g r a t i t u d e a l s o g o e s t o o u r T e c h n i c a l

R e p o r t W r i t i n g i n s t r u c t o r D e r j e f o r g i v i n g u s a g u i d e l i n e sa n d m o t i v a t i o n a l s u p p o r t s .

2 . AbstractWe present a hierarchical management scheme for Internet

4 | P a g e


4/17

Information Services. The proposed architecture is based on the

SNMP management protocol and achieves scalability through the

use of multiple levels of manager components and the introduction

of a uniform interaction interface between all components

(manager-to-agent, manager-to-manager). The hierarchy consists ofat least three layers: the agent, the domain manager/ remote

monitoring agent (DM/RMA) and the management station (MS). At

the lowest layer SNMP agents are installed on the systems hosting

Information Services entities (http, ftp, wais, gopher servers and

their dependent applications). The agent is responsible for

monitoring and gathering first-hand management information, being

as light-weighted as possible by performing minimal calculation. The

DM/RMA is a dual role module that acts as a manager monitoring a

group of IS systems by polling the associated agents,

implementing alarm procedures, producing higher level management

information and calculating QoS parameters & indicators within

the scope of its managed domain. Domains are defined by

geographical, economical, organizational or other criteria and may

include not only agents but also other DM/RMA modules, thus

expanding the hierarchy layers beyond three. The DM/RMA is

viewed as an agent from the MS perspective; the MS polls

multiple DM/ RMAs through SNMP (ismMIB) and handles the

asynchronous notifications generated by them, providing a top-level

filtering mechanism that produces a set of higher level QoS

metrics targeted to both the IS manager and the IS end-user. Multiple

MS components may be responsible for different functional orgeographical areas. Two Management Information Base (MIB)

modules are maintained for structuring the management information

collected & stored and defining the interaction semantics between

components.

3. INTRODUCTION

During the last five years we have witnessed an explosive growth of the Internetand an increasing interest in the usage of TCP/IP-based information protocols. The

5 | P a g e


5/17

term Internet Information Services has grown to be an every-day term referring

mainly to the WWW information system but also covering other Internet servers

based on FTP, Gopher, WAIS, etc. This global web of information serves

millions of users daily through wide area international network paths. The

level of QoS (Quality of Service) delivered to the Information Service (IS)end-user is affected by multiple factors; network health

1, serversystem load

(processor, operating system, etc.) and IS entity utilization are the dominant factor

categories.

The failure or degradation of service quality is usually perceived by the end-user

before the cause or even the symptoms of the failure is identified by the IS

manager. As IS systems become more complex in architecture and content, the

need for a coherent management tool increases. The requirement of QoS monitoring

can only be met efficiently by an integrated, system-wide management framework.

Such a framework will make possible the early diagnosis of faults or the lack

of performance, allow for improved planning and assist security and maintenance

by monitoring the service QoS and gathering resource usage and access statistics.

In this paper, we present a distributed management architecture that relies on a

hierarchy ofmultiple manager modules that use the SNMP protocol [ 4] for

polling and exchanging management information. Specialized MIB modules define

the managed objects that the agents maintain as well as the interaction semantics

for agent-to-manager and manager-to- manager communication. The manager

components use these MIB objects to implement a set of QoS parameters

(calculated in one level, or in co-operation - vertically in the hierarchy)

offered to both the IS manager (in full detail) and the IS end-user.

4. METHODOLOG Y- REQUIREMENTS

A. AdoptedMethodology

6 | P a g e


6/17

In order to identify the management requirements and design the framework we

adopted the following methodology:

(a) We attempted to recognize the user (both IS manager and end-user)

requirements that the management framework should aim to satisfy. Contrary

to the conventional management application scope, the aim of our effort wasto address the IS manager needs and at the same time provide some output

for the IS end-user as well.

(b) Through the analysis of the information engines and their architecture,

and after reviewing similar efforts at the MIB level, we defined a set of

management functions and QoS parameters that should be accessible by the

IS manager and end-user.

(c) Given the functionality and the desired output of the management

framework we defined the appropriate management architecture and specified

the MIB modules that model the monitored data and interaction semantics.

B. UserRequirements

An on-line WWW survey[ 7] performed within DESIRE provided the

following key conclusions:

Most IS managers do not currently use any monitoring tools for performance,

fault, security and accounting but they feel they need an integrated monitoring

and remote configuration tool would be valuable. The IS managers view

monitoring and remote configuration as more important functionality than

accounting.

The few IS developers that participated in the survey agreed thatintegrated management applications will ease the detection of IS system

problems.

The IS end-users expressed the wish to have access to performance statistics

andbe notified of causes for service failures.

C. User Interface Requirements

Visualizing the management information, QoS metrics and the output of

management functions in general in an ergonomically way, is of great importance

to the efficiency ofany management application and solutions have been given and

applied in most commercial products. An additional requirement in our proposedframework arises from the fact that the management system produces output not

only for the IS manager, but also for the non- specialized IS end-user. This makes

the usage of straightforward and simple visualizing techniques more significant

and introduces the requirement of supporting user interfaces over a wide area

scale2

and enhances the decision for a distributed/ co-operative management

scheme. Supporting an HTTP interface, at least for the end-user, provides

attractive solution.

D. Management Functional Requirements - QoSParametersThe main management functional areas are monitoring and remote

7 | P a g e


7/17

configuration. Monitoring is focused on configuration, performance, faulty

conditions, security and access statistics, while remote configuration functions

provide the means for recovering from an error or preventing the fault or the

degradation ofperformance.

The management functions are responsiblefor:

(a) Providing an up-to-date view of the information system

architecture and configuration (components that make up a system and

the relationship between them) and support the ability to identify changes

or even automatically discover configuration.

(b) Monitor system and information server performance and utilization,

including system resource utilization, service throughput & delays, error

rates, system and service availability, service utilization, accessibility

between the components of an IS system and others. The maintenance of

historical performance data is important and essential for planningprocedures (IS manager) and for providing before-hand estimations of

performance (IS end-user). This is the most sensitive functional area from

which the majority of end-user oriented QoS metrics are derived.

(c) Monitoring and analysis of errors and faulty conditions. Errors

could be categorized according to temporal parameters, service types

or client domains aiming to identify error patterns or just sources and

causes.

(d) Monitoring of server security mechanisms and access

control.

(e) Gathering published information access statistics, e.g. most accessed

documents, top domains and clients. The analysis of such historical data can

reveal useraccesspatterns that can be used for improving the QoS offered.

(f) Check published information consistency and structure.

(g) Remote configuration of the server parameters, including run-time, access

control and limitationparameters.

(h) Change the IS entity running status, in order to recover from a crash or to

changing the server configuration (a standalone UNIX server performs

more efficiently than a intend-started server in certain access patterns

and vice-versa).

QoS metrics, on the other hand, tend to be more compact (less detail and more

condensed information) and they are suited for presentation in a visualized waythrough graphical interfaces (bars, gauges, diagrams, etc.).

8 | P a g e


8/17

QoS metrics and indicators approach QoS management from three different

Given these functional areas, we derived a set of QoS metrics and indicators

These are high-level parameters that attempt to model the QoS offered by different

points ofview targeted to the IS end-users, the IS managers or both. QoS indicators

are more detailed parameters that are mostly targeted for use by the IS manager,while the QoS metrics are abstract and more IS-end-user oriented. QoS indicators

tend to be larger in size (usually taking the form of tables), more detailed and have

a more localized nature.

viewpoint angles: the network, the system and the application (IS entity), covering

all three layers ofan IS system. Network parameters provide an estimation of

network status & health, including historical data. System parameters provide

system health information that affect the IS entity performance & reliability,

while the application level parameters (that outnumber by far the other two)

provide metrics and indicators on the health, security, access, configuration,

current status, resource utilization, etc. on the IS entity and dependentcomponents.

9 | P a g e


9/17

101

E. ArchitecturalRequirements

In addition, the following performance, efficiency and organizational

requirements were identified during the analysis of IS systems:

Minimize WAN traffic generated by management

components. Minimize overall management system

response.

Provide views of the managed systems, services and applications in multiple

levels of abstraction.

Provide up-to-date and correct management information at any level of the

hierarchy. Support distribution of management responsibilities in a wide area

scale (pan-EuropeanorGlobal).

The above requirements, together with the distributed nature of Internet

information systems and the volume of monitored parameters lead us to

adopting a distributed, hierarchical approach for the proposed management

framework. This is in accordance to other research results [ 10,12,13,15] in

network and systems management: the complexity and scaling up of modern

computer and communication systems drives towards distributed management

architectures where the concept of the mid-level manager [ 2] and delegated

functionality[ 5] provides the solution to scaleability, extensibility, management

traffic and data handlingproblems.


10/17

11

5.THE PROPOSED MANAGEMEN TFRAMEWORK

A. Architecture Overview

The overall architecture is organized in at least three levels of hierarchy, that

may be generalized and expanded horizontally (add more three-level hierarchies)or vertically (add more levels of hierarchy). The generic architecture exhibits a

mesh (or tree) topology with three core component types:

At the leaf level (level 1, lowest in the hierarchy) the Agent is responsible for

collecting first-hand, low level information from the managed information

entity. This is the traditional, lightweight agent as introduced by the IETF

management framework and the SNMP protocol. Lightweight refers to system

resources usage, not the number ofsupported objects and MIB objects, i.e. the

agent is a process that operates with limited system resources without

significantly affecting the performance of the managed entity. Since the

proposed agent must be integrated into the IS server and the hosting systemmay have already another SNMP agent (maintaining other MIB modules), the

master/ sub-agent architecture is the most suitable solution for the

implementation.

TheDomain Manager / Remote Monitoring Agent (DM/RMA) operates at

level 2 and is responsible for a specific domain of Agents, acting as a

delegate of higher level manager modules. The DM/RMA provides a

first level of calculation and implementation of direct QoS parameters that

exhibit a local nature. It also gathers and stores locally statistics and recent

historical data, that will eventually migrate upwards in the hierarchy. A user-

interface (console based and/or WWW-based) may or may notbe supported bythe DM/RMA. If no interface exists, then the human operator cannot request

directly information and the manager acts solely as a local delegate of higher

level managercomponents.

The Management System (MS) operates at the top level (level 3 in the simple

case, orhigher) and it is nearer to the traditional management system, supporting

the full set ofconventional management functions (monitoring, history, alarms,

topology, remote configuration, etc.) including a graphical user-interface (GUI).

In addition to the conventional UI (e.g. X-Windows based) the MS supports

a WWW-interface to a secured sub-set of its functions that implement the

end-user oriented QoS metrics. Development effort can be reduced by relyingentirely on a WWW-based interface for

both the IS manager and the IS end-user (with different functionality and access

levels).


11/17

12

MS

DM/RMA

Agent

Managed

domain

More levels of DM/ RMAs may be inserted between the MS and level 1, thus

expanding the hierarchy vertically and generalising the concept of the domain

(include other DM/RMA in a domain). Further, multiple MSs may be introduced

at the top level (horizontal expansion of the model) for satisfying redundancy

requirements or for separating functionality at the top level, e.g. an MS is

responsible for planning and global access statistical analysis,

another is responsible for fault handling and trouble ticket generation, etc.

Figure 2presents an example.Vertical

expansionHorizontal

expansion

MS

DM/

RMA MS

DM/

RMADM/

RMA

DM/

RMA

Agents


12/17

13

B. Data and Functionality Distribution

QoS parameters (metrics and indicators) are implemented vertically

throughout the hierarchy of management components in a co-operative way and

they are offered through a WWW-based interface to the human operator or

end-user mostly by the MS oralternatively by a local DM/RMA. Most QoS

indicators are implemented at the DM/RMA,

while most QoS metrics are calculated at the MS or through a co-operation of the

MS and a group of DM/ RMAs. Historical data and statistics that have

significant storage requirements are eventually stored at the MS; they are storeddirectly to the MS ortemporarily stored at the local DM/RMA and later migrate

to the MS.

As a rule the DM/RMA stores domain-local and recent historical data, performs

a first level of processing preparing the MIB data for higher level modules.

Processing and storage requirements are limited compared to the MS and

simple storage management systems suffice for its implementation. The MS on

the other hand, operates on a more abstract and global viewpoint, gathers a large

amount of processed and historical data from multiple DM/ RMAs, performs meta-

processing and provides the main delivery channel of the final product (QoS

metrics and indicators) to the IS manager and end-user. The MS storagerequirements are much higher than the DM/RMA and more powerful storage and

retrieval management systems should be used to support it. Finally, at the lowest

level, the agent process remains lightweight imposing minimal local storage and

processing overhead on the managed system host. Processing & storage

requirements grow upwards in the hierarchy, while the local nature of manage

data decrease.

C. Interaction Model

All interaction between the components of the proposed architecture is performedthrough the SNMP management protocol. The choice of SNMP mandates the use

and installation of Management Information Bases (MIBs) on every component

that interacts with entities at higherlevels.

At level 1, the SNMP agents maintain the Information Service Node MIB (

isnMIB). The manager components access the isnMIB to retrieve low level

management and implement their functions based on these MIB objects. The

DM/RMA components maintain the Information Service Manager MIB (

ismMIB). The ismMIB provides an SNMP interface to the functions that the

DM/RMA implements and supports the interaction with the MS components or

other higher level DMR/MAs.


13/17

14

Management System

tunneled SNMPfor WAN communication

IS MANAGER

MIBDM / RMA

SNMP forLANtunneled SNMP forWAN

IS NODE

MIBAgent

IS Entity / Dependent

Applications

Both MIB modules ( isnMIB and ismMIB) are SNMP MIBs based on the

SNMPv2 SMI as defined in [3]. The isnMIB object definition procedure was guided by

analysis of the userrequirements & IS engines and the study of similar MIB definition

efforts. In fact, there is a significant number of MIB constructs with a direct or indirect

orientation towards the management of information services that are have been

produced by other research efforts or they are being developed within IETF groups

(like the CEO Project MIBs, the XXX

MIB, the University of Lisbon WWW MIB, SysAppl MIB, the Host Resources

MIB, the FTP MIB, etc. [ 1,6,7,8,9,11]). All this effort was taken into account in

order to avoid duplication of effort, try to remain within the IETF philosophy and

manage to identify already commonly accepted objects and constructs. In the isnMIB

we have tried include most of the common objects, refer to already established

MIB modules instead ofduplicating objects and groups and aimed to produce objects

that will cover all information services (at least http, ftp, gopher and wais) through

common and protocol independent objects.

Access and information retrieval from the isnMIB is exclusively based on

polling, since it will be performed by the local DM/RMA. In the ismMIB, however, we

have included the ability to defined alarm and monitoring procedures that

generate asynchronous notifications in order to minimise polling. The DM/RMA is

similar to what we havepresented in [ 13] and part of the ismMIB is a sub-set of the

Manager MIB alsopresented in that paper. The main features is the event mechanism

that allows the custom handling ofalarms and monitoring procedures: the higher

level manager may define through the ismMIB alarms and monitors for specific

isnMIB objects, by defining thresholds, timeperiods for sampling and reporting, a

monitoring function and the corresponding event that will handle the activated alarm or

the reporting monitor object. A fired event may be configured to generate an SNMP

acknowledged notification, add a log entry in a special ismMIB table, or both. Inaddition, to this mechanism, the ismMIB maintains summary and lookup

information for its managed domain.


14/17

15

6. CONCLUSION S

We presented an proposed architecture for managing Internet Information

Services based on the SNMP protocol, multiple manager components (including

dual-role managers) and two MIB modules. Our manager diverts from the

conventional, commercial norm not only due to the use of SNMP for manager-

to-manager interaction, but also for the fact that

output is provided to the end-user of the managed service in addition to the

administrator/manager. These managers are organized in hierarchical

structures and provide a WWW interface, turning this network of managersinto a management web plane operating in parallel to the managed

information providingplane.

7. Recommendations

Apart from implementing prototypes and experimenting with visualization of the

produced QoS metrics and indicators, future work will include work on

supporting end-user feedback: the user should be able not only to browsethrough the QoS metrics and estimates, but also participate into the

management process by reporting errors, preferences, acceptable QoS

thresholds, etc. Finally, prototype implementations will allow us to test and fine-

tune the distribution of functionality and data between the different

hierarchical levels.


15/17

8. REFERENCES

[1] Carillo J.A., Madeira E.R.M., A Scheme for FTP Management,

INET94 /JENC5, 1994.

[2] Case J., Levi B., SNMP mid-level-manager MIB and SNMP script

language, Internet Drafts, 1993.

[3] Case J., McCloghrie K., Rose M., Waldbusser S., "Structure of

Management Information for Version 2 of the Simple Network

Management Protocol (SNMPv2)", SNMP Research, Cisco

Systems, Dover Beach Consulting, International Network

Services,RFC1902, January 1996.

[4] Case J., McCloghrie K., Rose M., Waldbusser S., "Protocol Operations for

Version

2 of the Simple Network Management Protocol (SNMPv2)", SNMP

Research, Cisco Systems, Dover Beach Consulting, International NetworkServices, RFC

1905, January

1996.

[5] Goldszimdt G., Yemini Y., Distributed Management by Delegation,

15th

International Conference on Distributed Computing System,

Jsune 1995.

[6] H. Hazewinkel, E. van Hengstum, A. Pras, Definitions of Managed

Objects for

HTTP, draft-hazewinkel-httpmib-00.txt, April1996.


Objects foran

Information Retrieval Service, draft-hazewinkel-rsmib-00.txt, April

1996.


Objects foran

Information Store, draft-hazewinkel-ismib-00.txt, April

1996.

[9] S. Kille, N. Freed, Network Services Monitoring MIB, RFC1565, January

1994. [10] Konopka R., Trommer M., A Multilayer-Architecture for

SNMP-Based,

Distributed and Hierarchical Management of Local Area Networks,

4thInternational Conference on Computer Communications and

Networks, ICCCN95, 1995.


16/17

[11] C. Picoto, P. Veiga, Management of a WWW Server using SNMP,

JENC6.

[12] Siegl M.R., Trausmuth G., Hierarchical Network Management, In Proc.

JENC6,

1995.

[13] Stamatelopoulos F., Chiotis T., Maglaris B., A Scaleable, Platform-

Based Architecture for Multiple Domain Network Management, IEEE

InternationalConference on Communications 9,5June 1995.

[14] Stamatelopoulos F., Chiotis T., Karounos T., Grammatikou M.,

Stathis C., Maglaris B., Meneses R., Hazewinkel H., Requirements

Survey for Quality ofService in Distributed Information Systems, DESIRE

RE 1004 Project Deliverable D7.1[ http://www.surfnet.nl/surfnet/projects/desire/deliver/WP7/D7-1.html] ,

December1996.

[15] Waldbusser S.L., The Trend Towards Hierarchical Network Management,

The Simple Times, The Bi-Monthly Newsletter of SNMP Technology,

Comment, and Events, Volume 2, Number 6, November/December 1993.
http://www.surfnet.nl/surfnet/projects/desire/deliver/WP7/D7-1.htmlhttp://www.surfnet.nl/surfnet/projects/desire/deliver/WP7/D7-1.html


17/17

architecture for internet is

Documents