A Management Architecture for Internet Information Services

F. Stamatelopoulos, B. Maglaris

Jimma university Jimma Institute of Technology

D e p a r t me n t o f Electrical and Computer Engineering
Communication Stream

Technical Report Writing Assignment on Research Format

Group members
Name
1. 2. 3. 4. 5. 6. 7.

ID

Shambel Admasu 00708/02 Naod Mulu 00640/02 Solomon Guta 00735/02 Temesgen Senay 00778/02 Taleif Mahadi 00765/02 Mustefa Abdurhmen..00634/02 Remedan Mohammed00 /02 8. Muluken Eshetu 00630/02
2|Page

table of Contents
1.
2.

Acknowledgement..4 Abstract 5

3. 4.

Introduction6 Method of study7

4.1. Adaptive methodology 4.2. User requirements 4.3. User interface requirement 4.4. Management function requirement (QoS Parameter) 4.5. Architectural requirements The proposed management frame work 11 5.1. Architectural overview 5.2. Data and functionality distribution 5.3. Interaction model
5. 6. 7. 8.

Conclusion.15 Recommendation..15 Reference16

1. Acknowledgement
3|Page

We would like to thank Jimma University and the department of Electrical and Computer Engineering for giving support for the completion of our Research by providing material support. And our heart-full gratitude also goes to our Technical Report Writing instructor Derje for giving us a guidelines and motivational supports.

2 . Abstract
We present a hierarchical management scheme for Internet
4|Page

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 of at 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 or geographical 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 Internet and an increasing interest in the usage of TCP/IP-based information protocols. The
5|Page

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, server system 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 of multiple 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. Adopted Methodology 6|Page

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 was to 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. User Requirements

An on-line WWW survey[ 7] performed following key conclusions:

within DESIRE provided the

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 that integrated management applications will ease the detection of IS system problems. The IS end-users expressed the wish to have access to performance statistics and be 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 of any management application and solutions have been given and applied in most commercial products. An additional requirement in our proposed framework 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 scale 2 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 - QoS Parameters

The

main

management

functional

areas

are

monitoring

and

remote
7|Page

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 of performance. The management functions are responsible for: (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 planning procedures (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 user access patterns 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 limitation parameters. (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 way through graphical interfaces (bars, gauges, diagrams, etc.).
8|Page

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 of view 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 of an 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 dependent components.

9|Page

E. Architectural Requirements

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-European or Global). 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 handling problems.

1 10

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 of supported 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 system may have already another SNMP agent (maintaining other MIB modules), the master/ sub-agent architecture is the most suitable solution for the implementation. The Domain 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 userinterface (console based and/or WWW-based) may or may not be supported by the 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 manager components. The Management System (MS) operates at the top level (level 3 in the simple case, or higher) and it is nearer to the traditional management system, supporting the full set of conventional 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 relying entirely on a WWW-based interface for both the IS manager and the IS end-user (with different functionality and access levels).

11

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 2 presents an example.
Vertical expansion Horizontal expansion

MS

DM/ RMA

MS

DM/ RMA

DM/ RMA

DM/ RMA

Agents

12

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 or alternatively 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 stored directly to the MS or temporarily 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 metaprocessing and provides the main delivery channel of the final product (QoS metrics and indicators) to the IS manager and end-user. The MS storage requirements 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 performed through 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 higher levels. 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

Management System
tunneled SNMP for WAN communication

IS MANAGER MIB

DM / RMA

SNMP for LAN tunneled SNMP for WAN IS NODE MIB

Agent

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 user requirements & 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 of duplicating 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 have presented in [ 13] and part of the ismMIB is a sub-set of the Manager MIB also presented in that paper. The main features is the event mechanism that allows the custom handling of alarms and monitoring procedures: the higher level manager may define through the ismMIB alarms and monitors for specific isnMIB objects, by defining thresholds, time periods 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. In addition, to this mechanism, the ismMIB maintains summary and lookup information for its managed domain.
14

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 managerto-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 managers into a management web plane operating in parallel to the managed information providing plane.

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 browse through 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 finetune the distribution of functionality and data between the different hierarchical levels.

15

8. REFERENCES

[1] [2] [3]

Carillo J.A., Madeira E.R.M., A Scheme for FTP Management, INET94 / JENC5, 1994. Case J., Levi B., SNMP mid-level-manager MIB and SNMP script language, Internet Drafts, 1993. 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,RFC 1902, 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 Network Services, 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, April 1996. [7] H. Hazewinkel, E. van Hengstum, A. Pras, Definitions of Managed Objects for an Information Retrieval Service, draft-hazewinkel-rsmib-00.txt, April 1996. [8] H. Hazewinkel, E. van Hengstum, A. Pras, Definitions of Managed Objects for an Information Store, draft-hazewinkel-ismib-00.txt, April 1996. [9] S. Kille, N. Freed, Network Services Monitoring MIB, RFC1565, January Multilayer-Architecture for 1994. [10] Konopka R., Trommer M., A

SNMP-Based, Distributed and Hierarchical Management of Local Area Networks, 4th International Conference on Computer Communications and Networks, ICCCN95, 1995.

[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, PlatformBased Architecture for Multiple Domain Network Management, IEEE International Conference 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 of Service in Distributed Information Systems, DESIRE RE 1004 Project Deliverable D7.1 [http://www.surfnet.nl/surfnet/projects/desire/deliver/WP7/D7-1.html] , December 1996. [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.