A Management Architecture for Internet Information Services

Transcription

1 A Management Architecture for Internet Information Services Abstract F. Stamatelopoulos, B. Maglaris Network Management and Optimal Design (NETMODE) Lab Department of Electrical and Computer Engineering National Technical University of Athens Iroon Politechniou 9, Zographou, Athens, Greece tel.: (+301) fax: (+301) We present a hierarchical management scheme for Internet Information Services. The proposed architecture is based on the SNMP management protocol and achieves scaleability 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, organisational 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. Note: This research was partly funded by the EU R&D Telematics Project DESIRE: RE A prototype with a version of the isnmib and a modified architecture with 2 levels of managers (without the ismmib) will be implemented within DESIRE. Presented at the HP OpenView University Association Workshop, Madrid, April 1997

2 I. 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 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 utilisation 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. Specialised MIB modules define the managed objects that the agents maintain as well as the interaction semantics for agent-to-manager and manager-tomanager 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. II. METHODOLOGY - REQUIREMENTS A. Adopted Methodology In order to identify the management requirements and design the framework we adopted the following methodology: (a) We attempted to recognise 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. 1 for the WAN path from the client site to the server 2

3 B. User Requirements 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 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 Visualising the management information, QoS metrics and the output of management functions in general in an ergonomical 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 nonspecialised IS end-user. This makes the usage of straightforward and simple visualising 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 an attractive solution. D. Management Functional Requirements - QoS Parameters The main management functional areas are monitoring and remote 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 utilisation, including system resource utilisation, service throughput & delays, error rates, system and service availability, service utilisation, 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 categorised 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. 2 the end-user may be accessing from anywhere in the Internet 3

4 (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 inetd-started server in certain access patterns and vice-versa). 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 localised nature. 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 visualised way through graphical interfaces (bars, gauges, diagrams, etc.). QoS metrics and indicators approach QoS management from three different 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 utilisation, etc. on the IS entity and dependent components. E. Architectural Requirements In addition, the following performance, efficiency and organisational requirements were identified during the analysis of IS systems: Minimise WAN traffic generated by management components. Minimise 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. 4

5 III.THE PROPOSED MANAGEMENT FRAMEWORK A. Architecture Overview The overall architecture is organised in at least three levels of hierarchy, that may be generalised 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 user-interface (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). 5

6 MS DM/RMA Managed domain Agent 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 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, 6

7 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 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 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 DM/ RMAs. Note that WAN connectivity may inhibit the use of pure SNMP: if the DM/ RMMA is located in the LAN of the agent then pure SNMP will be used; however, if a WAN path connects the two components then a tunnelled form SNMP 3 should be used since usually WAN routers filter out UDP packets in most ports for performance or security reasons. The same may apply to the DM/RMA - MS interaction Figure ( 3). 3 For example, it has been suggested by researchers that HTTP should be used for tunneling SNMP for WAN usage. 7

8 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. IV. CONCLUSIONS - FUTURE WORK 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 8

9 output is provided to the end-user of the managed service in addition to the administrator/manager. These managers are organised 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. Apart from implementing prototypes and experimenting with visualisation 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 fine-tune the distribution of functionality and data between the different hierarchical levels. V. REFERENCES [1] Carillo J.A., Madeira E.R.M., A Scheme for FTP Management, INET 94 / JENC5, [2] Case J., Levi B., SNMP mid-level-manager MIB and SNMP script language, Internet Drafts, [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, RFC 1902, January [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 [5] Goldszimdt G., Yemini Y., Distributed Management by Delegation, 15th International Conference on Distributed Computing Systems, June [6] H. Hazewinkel, E. van Hengstum, A. Pras, Definitions of Managed Objects for HTTP, draft-hazewinkel-httpmib-00.txt, April [7] H. Hazewinkel, E. van Hengstum, A. Pras, Definitions of Managed Objects for an Information Retrieval Service, draft-hazewinkel-rsmib-00.txt, April [8] H. Hazewinkel, E. van Hengstum, A. Pras, Definitions of Managed Objects for an Information Store, draft-hazewinkel-ismib-00.txt, April [9] S. Kille, N. Freed, Network Services Monitoring MIB, RFC1565, January [10] Konopka R., Trommer M., A Multilayer-Architecture for SNMP-Based, Distributed and Hierarchical Management of Local Area Networks, 4th International Conference on Computer Communications and Networks, ICCCN 95, [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, [13] Stamatelopoulos F., Chiotis T., Maglaris B., A Scaleable, Platform-Based Architecture for Multiple Domain Network Management, IEEE International Conference on Communications 95, June

10 [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 [ December [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