DataGrid I NFORMATION AND M ONITORING: C URRENT T ECHNOLOGY C URRENT T ECHNOLOGY R EVIEW AND E VALUATION. WP3: Information and Monitoring

Transcription

1 DataGrid I NFORMATION AND M ONITORING: C URRENT T ECHNOLOGY C URRENT T ECHNOLOGY R EVIEW AND E VALUATION WP3: Information and Monitoring Document identifier: Date: 31/01/2002 Work package: Partner(s): Lead Partner: Document status: WP3: Information and Monitoring IBM, PPARC, SZTAKI PPARC APPROVED Deliverable identifier: D3.1 Abstract: An overview and evaluation of the current technologies with respect to information and monitoring in a distributed computing environment. IST PUBLIC 1 / 31

2 Delivery Slip Name Partner Date Signature From S. M. Fisher PPARC 31/01/2002 Verified by Stefano Beco DATAMAT 1/02/2002 Approved by PTB 4/02/2002 Document Log Issue Date Comment Author /12/2001 Submitted to Reviewers WP /01/2002 Submitted to PTB WP /01/2002 Small correction requested by PTB WP /01/2002 Final version WP3 Document Change Record Issue Item Reason for Change Files MS Word Software Products User files IST PUBLIC 2 / 31

3 CONTENT 1. INTRODUCTION OBJECTIVES OF THIS DOCUMENT APPLICATION AREA APPLICABLE DOCUMENTS AND REFERENCE DOCUMENTS DOCUMENT EVOLUTION PROCEDURE TERMINOLOGY EXECUTIVE SUMMARY EVALUATION CRITERIA INTRODUCTION EVALUATION CRITERIA TOOLS AUTOPILOT & VIRTUE GRM & PROVE IBM WEB SERVICES JINI JXTA LDAP BASED INFORMATION SERVICES Globus MDS Ftree MULTI ROUTER TRAFFIC GRAPHER (MRTG) NETLOGGER NETWORK WEATHER SERVICE ON-LINE MONITORING INTERFACE SPECIFICATION (OMIS) R-GMA SCOUT SITEASSURE VA CLUSTER MANAGEMENT (VACM) EVALUATIONS CONCLUSION ACKNOWLEDGEMENTS...31 IST PUBLIC 3 / 31

4 1. INTRODUCTION 1.1. OBJECTIVES OF THIS DOCUMENT This document is the D3.1 deliverable specified in the technical annexe of the EU DataGrid. The task which results in this deliverable is described in the technical annexe as: Evaluation of existing distributed computing monitoring technologies to understand potential uses and limitations. Tests will be made in the first demonstration environments of the project to gain experience with tools currently available. Issues studied will include functionality, scalability, robustness and resource usage As the work of WP3 covers both information and monitoring, a range of systems has been evaluated; some are primarily monitoring systems, some are information systems and some exhibit characteristics of both. The evaluation has covered products from industry and some which are open source. It was also decided to include components which have been developed by WP3 members, both before the project, and during the first year of the project. These products, where our bias may be visible, are identified APPLICATION AREA This report of current technology is being used by WP3 as a basis for determining appropriate technology for implementation of the DataGrid Information and Monitoring system APPLICABLE DOCUMENTS AND REFERENCE DOCUMENTS Reference documents [1] Web Services architecture overview, [2] Jini Architectural Overview, [3] Jxta Technology Overview, [4] B. Tierney et al., The NetLogger Methodology for High Performance Distributed Systems Performance Analysis, Proc. of the IEEE HPDC-7 (July 28-31, 1998, Chicago, IL) LBNL [5] D. Gunter et al., NetLogger: A Toolkit for Distributed System Performance Analysis Proc. of the IEEE Mascots 2000 Conference (Aug. 2000) LBNL [6] Netlogger Home Page, [7] OMIS Version 2.0 Home Page, [8] N. Podhorszki, P. Kacsuk: Design and Implementation of a Distributed Monitor for Semi-on-line Monitoring of VisualMP Applications, Proceedings DAPSYS'2000 Distributed and Parallel Systems, From Instruction Parallelism to Cluster Computing, Balatonfüred, Hungary, pp , [9] P. Kacsuk: Performance Visualization in the P-GRADE Parallel Programming Environment, HPCN Asia, Beijing, China, [10] GRM & Prove Home Page, [11] R. Wolski et al.: The Network Weather Service: A Distributed Resource Performance Forecasting Service for Metacomputing, Journal of Future Generation Systems, [12] The Network Weather Service: IST PUBLIC 4 / 31

5 [13] Network Weather Service Home Page: [14] J.S. Vetter and D.A. Reed: Real-time Monitoring Adaptive Control and Interactive Steering of Computational Grids, The International Journal of High Performance Computing Applications (2000) [15] Scalable Performance Tools (Pablo Toolkit) [16] E. Shaffer et al.: Virtue: Immersive Performance Visualisation of Parallel and Distributed Applications, IEEE Computer, December 1999, pp [17] Autopilot Home Page: [18] MRTG Home Page: [19] RRDtool Home Page: [20] Open LDAP Home Page, [21] MDS Home Page, [22] VACM Home Page, [23] VACM Overview, [24] Information and Monitoring (WP3) Architecture Report, [25] WP7, Grid Network Monitoring, Document accompanying D DOCUMENT EVOLUTION PROCEDURE This document will not evolve once it has been completed TERMINOLOGY Acronyms API ASCII ATM BMC CORBA CPU DIT EMP GGF GIIS GMA GRIS GRM Application Programming Interface American Standard Code for Information Interchange Asynchronous Transfer Mode Baseboard Management Controller Common Object Request Broker Architecture Central Processing Unit Directory Information Tree Emergency Management Port Global Grid Forum Grid Information Index Server Grid Monitoring Architecture Grid Resource Information Server GRade Monitor IST PUBLIC 5 / 31

6 GSI Grid Security Infrastructure HTML Hyper Text Mark-up Language HTTP Hyper Text Transfer Protocol IBM International Business Machines IETF Internet Engineering Task Force IPC Inter Process Communication IPMI Intelligent Platform Management Interface JXTA Juxtapose LAN Local Area Network LDAP Lightweight Directory Access Protocol MDS Metacomputing Directory Services MRTG Multi Router Traffic Grapher NASSL Network-Accessible Service Specification Language NWS Network Weather Service OCM OMIS Compliant Monitoring OMIS On-line Monitoring and Interface Specification P-GRADE Professional GRAphical parallel program Development Environment PNG Portable Network Graphics PVM Parallel Virtual Machine RC4 Ron's Code 4 R-GMA Relational Grid Monitoring Architecture RMI Remote Method Invocation RRDtool Round Robin Database tool RSA Rivest, Shamir, & Adleman RSH Remote Shell SASL Simple Authentication and Security Layer SDDF Self-Defining Data Format SHA-1 Secure Hash Algorithm SNMP Simple Network Management Protocol SOAP Simple Object Access Protocol SQL Structured Query Language SSL Secure Sockets Layer TCP/IP Transmission Control Protocol/Internet Protocol TLS Transport Layer Security ttl Time to live UDDI Universal Description, Discovery and Integration UDDI4J Universal Description, Discovery and Integration for JAVA ULM Universal Logger Message VACM VA Cluster Management IST PUBLIC 6 / 31

7 VO WAN WDS WSDL WSDL4J WSTK XML XSLT Virtual Organisation Wide Area Network Well-Defined Service Web Services Description Language Web Services Description Language for Java Web Services Tool Kit Extensible Markup Language Extensible Stylesheet Language Transformations IST PUBLIC 7 / 31

8 2. EXECUTIVE SUMMARY The goal of the Information and Monitoring work package (WP3) is to deliver a flexible infrastructure that provides information on the EU DataGrid itself and upon grid applications. Resources will advertise their status and available features, and applications will publish any information they choose, though this is primarily for performance tuning. This report starts by listing a set of evaluation criteria. A major consideration for the system is that it can cope with nodes in a distributed environment. Dynamic addition and deletion of nodes and network failures should not affect the system as a whole, and it must have a security system able to address the access to information at quite a fine level of granularity, i.e. control over security is at the level of small units of information. In addition to being able to work well on an unreliable Wide Area Network (WAN), the system must allow new data types to be defined and should support both push and pull models. The product should be available and be being developed under an open source model. Members of WP3 tried some of the products, but for others this report relies upon technical documents describing the product. The products range from rather inflexible monitoring systems with a fixed set of sensors working in a Local Area Network (LAN) to very general solutions such as the IBM Web Services. Jini and JXTA are both rather general systems from Sun. Jini technology is tied to the Java platform and does not extend to the WAN but JXTA does not have these limitations. Globus MDS (Metacomputing Directory Services) is distributed as part of the Globus tool kit and as such should be applicable to grid environments. However, MDS is based on LDAP (Lightweight Directory Access Protocol), which was designed for address books which are rather static not for Grid environments. The query language only supports very simple queries. A WP3 development, Ftree, implements a draft LDAP streaming protocol. The only product that has been specifically designed from the beginning as a Grid Monitoring and Information system is R-GMA (Relational Grid Monitoring Architecture). This is being developed by WP3 as a relational implementation of the Global Grid Forum s (GGF) Grid Monitoring Architecture (GMA). R-GMA on its own is not enough however. A mechanism of non-intrusive sensors is required along with powerful visualisation tools. In both cases the tools must be able to accept user defined data types. Possible tools offering both the sensors and the visualisation facilities are Autopilot/Virtue, Grade Monitor (GRM) /PROVE and Scout. GRM/PROVE are components originally developed before the DataGrid project by members of WP3, but which have been adapted so that they can be used in the DataGrid environment. It is also interesting to be able to support NetLogger, for which there is also a lot of instrumented code in existence already. NetLogger is in principle intrusive, but unless it is collecting a huge amount of information this is not a problem in practice. It has been concluded that the development of the GGF s GMA in the form of R-GMA is the best route to follow to obtain the desired functionality for the DataGrid. The future plans of WP3 include the incorporation of GRM/PROVE into R-GMA to enable the delivery of an integrated information and monitoring system. IST PUBLIC 8 / 31

9 3. EVALUATION CRITERIA 3.1. INTRODUCTION The technologies reviewed are either information systems, monitoring systems or systems that exhibit characteristics of both. The criteria have been phrased in such a way that simple Yes or No answers can be given. There has not been sufficient time to try out all the tools and technologies, so there is a lot of reliance upon the information provided by the suppliers. Those products that someone in WP3 has first hand knowledge of are marked as such in the evaluation tables. In some cases it is not clear from the documentation if some feature has been implemented or not, in this case the box is marked to indicate Not Tested. The following criteria appear to be relevant to grid information and monitoring systems CRITERIA a) Tested Has WP3 first hand, working knowledge of the product? b) Open Source Does the product have an open source licence? c) WAN Is the product suitable for WAN d) Data Types Will it support new data types? e) Push Does it support the push communication model? f) Pull Does it support the pull communication model? g) Availability Is the product currently available and supported? h) No Failure Does not have a single point of failure? i) Multiple Users Is the product scalable to multiple users? j) Info Providers Will it extend for new information providers? k) Security Does the product have authentication and authorisation features? l) Control Does the product have a fine granularity of control of authorisation? m) Publish/Subscribe IST PUBLIC 9 / 31

10 Does it use the Publish/Subscribe communication model? n) Portable Is the data format that it uses portable between different machine architectures? o) Non-intrusive A monitoring system is considered to be intrusive when it significantly perturbs the quantities it is measuring. To avoid this some products use shared memory buffers to collect data, switch off monitoring, and then transfer the buffered data. Of course even this can be intrusive in the sense that it impacts other users. p) Sensor Control Can the sensors control their intrusiveness? This is only relevant for sensors which push information. q) Visualisation Does the product have a visualisation tool? r) Archive Does the product have archive handling? IST PUBLIC 10 / 31

11 4. TOOLS Some of these tools are also addressed in deliverable D7.2 [25] 4.1. AUTOPILOT & VIRTUE Autopilot [14] is a distributed performance measurement and resource control system that is designed to allow applications and runtime libraries to change their behaviour and optimise their performance in response to real-time data on software dynamics and performance. Autopilot is based on the Pablo performance toolkit [15]. It is complemented by Virtue [16], which is an environment that accepts real-time data from Autopilot for visualisation and allows users to change the software behaviour and resource policies. The Autopilot infrastructure, Figure 1 and 2, consists of the following components: Distributed sensors and actuators that may be embedded in an application, The resource policy that is influenced by the sensors and actuators, Behavioural classification tools, Decision procedures based on fuzzy logic, Autopilot manager. Application Sensors Actuators Resource policy Assertion & classification Decision procedures Figure 1. Adaptive Infrastructure of Autopilot IST PUBLIC 11 / 31

12 Instrumented Tasks Sensor/actuator controls Sensor data Remote Client Task(s) Sensor/actuator registration Request Sensor/actuator pointer Sensor/Actuator Manager Figure 2. Autopilot Manager Infrastructure Sensors can capture quantitative application and system performance data and compute performance metrics. Software actuators enable and configure resource management policies. Sensors and actuators are placed into the source code (to provide access to program variables and control points). They can work in either procedural or threaded mode. In procedural mode they are invoked by the program and have no influence until invoked. In threaded mode they run in a separate thread, have access to program variables and can influence the running program asynchronously. The Autopilot Manager maintains information about all currently available sensors and actuators, and their associated properties. A sensor client or actuator client specifies the sensor(s) or actuators(s) that it is interested in monitoring or controlling through its own property list that is used to select from all of the available sensors and actuators. The client's property list is communicated to the Autopilot Manager where it is compared to the property lists of registered sensors and actuators. A sensor or actuator whose property list contains all of the properties desired by the client is a match for the client request. There may be multiple matches to a single client request. Decision procedures can select resource management policies and enable actuators based on observed application resource requests and the system responses captured by performance sensors. Resource policy selection and configuration are isolated within re-targetable decision procedures. This infrastructure design increases software portability by allowing application and runtime libraries to adapt to disparate hardware and software with minimal change. Decision procedures are based on fuzzy logic to provide robust control. The Performance Monitor Component of Autopilot consists of two kinds of processes. Collectors, which run on the machines to be monitored and retrieve statistics (such as processor, memory, disk and network utilisation); and recorders, which take the data and process, record or output it. There are two recorders; one simply prints an abbreviated form of each record as it receives it (used mostly for debugging) and another one, which writes records to a Self-Defining Data Format (SDDF) output file. The Pablo SDDF is a performance data description language that specifies both data record structures and data record instances. Because the format can describe general data records, as opposed to a predefined set of records, it can be viewed as a data meta-format. The SDDF data meta-format is used by most software developed by the Pablo group including Autopilot and Virtue. Virtue is an immersive virtual environment to manipulate the abstract world of software in the same way as a physical environment. The Virtue toolkit includes the following components: IST PUBLIC 12 / 31

13 Hierarchical groups for software structure, Software component control, Manipulation tools to interact with the virtual environment, Multimedia annotation tools, Standard interfaces. Virtue and Autopilot work together to allow users to monitor and steer distributed computations in real-time. Using data from Autopilot, Virtue defines a visualisation hierarchy for managing performance details. The Virtue 3D display allows a variety of statistics to be mapped to different graphs defined in different levels of the system hierarchy (from distributed sites in the grid to single tasks). Virtue's most powerful tool is a generalised magnifying glass, called a magic lens, which allows users to interactively focus on a portion of the visualisation. A set of actualisation interfaces allows users to directly manipulate visualisation and to change software behaviour via Autopilot actuators GRM & PROVE GRM is a semi-on-line monitor [8] that collects information about an application running in a distributed heterogeneous system and delivers the collected information to the PROVE visualisation tool [9]. The information can be either event trace data or statistical information of the application behaviour. Semi-on-line monitoring means that any time during execution, the user can require all available trace data and the monitor is able to gather them in a reasonable amount of time. GRM consists of three main components as shown in Figure 3: y Local Host Main Monitor MM Site 1 Host 1 Host 2 Host 1 Local Monitor LM Local Monitor LM Local Monitor LM Site 2 Client Library Application Process Client Library Application Process Client Library Application Process Figure 3. Structure of GRM Client library The application is instrumented with the functions of the client library (currently available in the C language). Event formats should be defined first and then event records can be generated by a simple IST PUBLIC 13 / 31

14 function call giving data as function parameters. Both trace events and statistics can be generated by the same instrumentation. An application process places trace event records into a shared memory buffer provided by the local monitor and does not need to communicate outside of the host. Local monitor process A local monitor is running on each host and is responsible for the handling of trace data from processes on the same host. It creates a shared memory buffer and event records are directly placed into this buffer by the processes. Thus, if a process fails, all trace events are available for the user to the point of the failure. In statistics collection mode, the shared memory buffer is used to store the counters and the local monitor is responsible for generating the final statistics data. Main monitor process A main monitor process co-ordinates the work of the local monitor processes. It collects trace data from them when the user asks or a trace buffer on a local host becomes full. Trace is written into a text file in Tape/PVM (Parallel Virtual Machine) format, which is a record based format for trace events in ASCII (American Standard Code for Information Interchange) representation. Also, it performs clock synchronisation among the hosts. GRM is designed for application performance monitoring and it can handle high volumes of data. Host and network monitoring sensors can be easily connected to GRM using its client library that enables sensors to define new type of events. Sensors can put their events into the shared memory buffer themselves (using the client library). However, sensors should be set up and stopped manually. There is no support for sensor management in GRM. Using host and network sensors, application performance can be examined in the context of the execution environment. PROVE has been developed for performance visualisation of Tape/PVM trace files. It supports the presentation of detailed event traces as well as statistical information of applications. It can work both off-line and semi-on-line and it can be used for observation of long-running distributed applications. Users can watch the progress of their application and observe performance problems with in it. PROVE communicates with the main monitor of GRM and periodically asks for trace collection. It can work remotely from the main monitor process. With the ability to read new volumes of data and remove any portion of data from memory, PROVE can observe an application for a long period. GRM and PROVE have been developed as part of the P-GRADE [10] professional graphical parallel program development environment by members of WP3 before the Data Grid project. This year GRM and Prove have been separated off for use on the DataGrid and are now considered part of the the current WP3 technology IBM WEB SERVICES The IBM Web Services Tool Kit (WSTK) collects a number of technologies, under different licensing terms to demonstrate the use of these technologies. The WSTK is not a product and is not intended to be a product on its own. It is a preview technology package of emerging technologies. The core technologies like SOAP, UDDI, WSDL, XML are all open standards and the WSTK ships with open source implementations for those standards. Other parts are licensed under the IBM Public License and some components are IBM proprietary. The following bullet points were taken from reference [1]: Web Services are self-contained, modular applications that can be described, published, located, and invoked over a network, generally the World Wide Web. IST PUBLIC 14 / 31

15 The Web Services architecture describes three roles: service provider, service requester and service broker; and three basic operations: publish, find and bind. A network component can play any or all of these roles. Two separate documents describe Web Services: A Well-Defined Service (WDS) document describes non operational service information, such as service category, service description, and expiry date, as well as business information about the service provider, such as company name, address, and contact information. A Network-Accessible Service Specification Language (NASSL) document describes operational information about the service, such as service interface, implementation details, access protocol, and contact endpoints. Service provider Publish Bind Service broker Find Service requester Figure 4. Basic Webservices architecture A Web Services architecture implementation should allow for incremental security and quality of service models facilitated by configuring a set of environmental prerequisites (for example, authentication mechanism, billing, and so on) to control and manage the interactions. Web Services can be dynamically composed into applications stemming from capabilities-based look-up at runtime, instead of the traditional static binding. The dynamic nature of the collaborations allows the implementations to be platform- and programming language-neutral, and communications mechanism-independent. The roles of the WDS and NASSL documents are provided by the Web Services Description Language (WSDL), which is used to describe what a service offers, how to invoke it, and how to bind to it. The Service Broker for every published service holds a pointer to the WSDL document. The Service Broker can be implemented as a Universal Description, Discovery and Integration (UDDI) registry, but this is not essential. The Simple Object Access Protocol (SOAP) can be used to communicate between the different components, but other bindings (e.g. HTTP (Hyper Text Transfer Protocol)) can be defined as well in WSDL. Web services provide a very general means to locate and use Services over the network designed to overcome the limitations of earlier solutions (Common Object Request Broker Architecture (CORBA), Java Remote Method Invocation (RMI)). An Information and Monitoring System could be implemented using the Web services approach, because of the similarity to the Grid Monitoring Architecture. However the intention of Web services is to provide a framework by which well known services can be invoked dynamically to build business applications that are less brittle than the tightly coupled monolithic systems of the past. This does not take the transient nature that a Grid Information and Monitoring System will have to deal with into account. Such a system has to be a low overhead, efficient solution to be widely applicable. In this respect Web services are too general. The technologies underlying Web services (UDDI, SOAP, IST PUBLIC 15 / 31

16 WSDL) are all open source and in the process of being standardised, which provides for interoperability and vendor independence. Microsoft s implementation of Web services is part of their.net framework. The IBM WSTK contains a Client Runtime environment for client application access: The UDDI Java API (Application Programming Interface) (UDDI4J) which allows applications to perform the Save, Delete, Find and Get operations against a UDDI registry (a Private UDDI or a Public UDDI registry that resides on the Internet), The Service Registry API allows applications to perform the Publish, Unpublish and Find operations against a UDDI registry, A Service Proxy API allows applications to access Web services via the SOAP protocol, The WSDL Java API (WSDL4J) provides an object model for WSDL documents. Design-time Web services Tools: A WSDL Generator Tool for assisting in encapsulating legacy code as Web services, A Web services Toolkit Configuration Tool to facilitate set-up and customisation of the Web services Toolkit, A Service Proxy Generator Tool which creates a Java client-side interface to connect to a Web service, A Service Implementation Template Generator Tool creates a Java Server-side interface template so that client programs can access the Web service. A Web services runtime environment that includes: The SOAP infrastructure using Apache SOAP V2.2 and the Apache Axis code. (Apache Axis is the follow-on project to the Apache SOAP project - also known as SOAP 3.0), Xerces (Java Extensible Mark-up Language (XML) Parser), Xalan (Extensible Stylesheet Language Transformations (XSLT) stylesheet processor) JINI Jini technology enables access to services over any network, regardless of platform, operating system, network protocols or distance. It provides a mechanism for connecting distributed services by locating them on a network and finding the methods that the service requires. When a service has been located, the methods and attributes for that service can be downloaded in the form of a Java object. The Java byte codes for the service can be run on any system that is Java enabled. The result is a system that is protocol independent but is tied to the Java platform. To enable Java objects to be passed around the network, Jini makes use of the Java RMI [2]. Jini allows the dynamic addition of new resources and can also handle dynamic data and data structures. It comes with a security manager and allows for the implementation of other security managers. The core of a Jini system contains three protocols called discovery, join, and lookup. Discovery occurs when a service is looking for a lookup service with which to register. Join occurs when a service has located a lookup service and wishes to join it. Lookup occurs when a client or user needs to locate and invoke a service described by its interface. JINI is neither an information nor a monitoring system, however the mechanisms of discovery, join and lookup could be useful when implementing either kind of system. IST PUBLIC 16 / 31

17 Discovery/Join is the process of adding a service to a Jini system. First, the service provider locates a lookup service by multicasting a request on the local network for any lookup services to identify themselves (Figure 5). Service provider seeks a lookup service Lookup Service Client Service Provider Service Object Service Attributes Figure 5. Jini discovery process Then a Java object for the service is loaded into the lookup service (Figure 6). This object contains the Java programming language interface for the service including the methods that users and applications will invoke to execute the service, along with any other descriptive attributes. A service provider registers a service object and its service attributes with the lookup service Lookup Service Service Object Service Attributes Client Service Provider Service Object Service Attributes Figure 6. Jini join process The service is now ready to be looked up and used, as shown in Figure 7. A client requests a service by Java type and, perhaps, other service attributes. A copy of the service object is moved to the client and used by the client to talk to the service Lookup Service Service Object Service Attributes Client Service Object Service Provider Figure 7. Jini lookup process A client locates an appropriate service by its interface written in the Java programming language, along with descriptive attributes that are used in the lookup service. The Java object is loaded into the client. The final stage is to invoke the service, as shown in the following diagram (Figure 8). IST PUBLIC 17 / 31

18 The client interacts directly with the service provider via the service object Lookup Service Service Object Service Attributes Client Service Object Service Provider Figure 8. Jini service invocation process 4.5. JXTA JXTA is short for Juxtapose, (to place side by side). JXTA started as a research project at Sun Microsystems and is now open-source. JXTA technology is a set of six protocols that enable Peer-to- Peer network computing without the need of a centralised management infrastructure. It is independent of platform, programming language and networking (such as TCP/IP (Transmission Control Protocol/Internet Protocol) or Bluetooth). To underpin this set of protocols, JXTA technology defines a number of concepts [3]. Peers A peer is any entity that can use the protocols. Peer Groups A peer group is a collection of co-operating peers providing a common set of services. Identifiers Identifiers are 128-bit data that refer to an entity. They become significant only after they are securely bound to other information such as a name and network address. Pipes Pipes are communication channels for sending and receiving messages, and are asynchronous. They are also uni-directional, so there are input pipes and output pipes. A pipe can be viewed as an abstract, named message queue that supports a number of abstract operations such as create, open, close, delete, send, and receive. Advertisements Advertisements are XML structured documents that name, describe, and publish the existence of a resource, such as a peer, a peer group, a pipe, or a service. JXTA technology defines a basic set of advertisements. More advertisement subtypes can be formed from these basic types using XML schemas. IST PUBLIC 18 / 31

19 JXTA Community Applications JXTA Community Services Peer Groups Peer Monitoring Security Peer Pipes Any peer Figure 9. The structure of JXTA The six JXTA protocols [3] Peer Discovery Protocol Enables a peer to advertise its resources and to discover resources from other peers or peer groups. Every peer resource is described and published using an advertisement. Peer Revolver Protocol This protocol enables a peer to send and receive generic queries to find or search for peers, peer groups, pipes, and other information. Peer Information Protocol This protocol allows a peer to learn about other peers' capabilities and status. The Peer Membership Protocol A peer wanting to join or leave an existing peer group uses this protocol. A single peer can belong to multiple peer groups. Peer Membership Protocol Authenticators and security credentials are used to provide the desired level of protection. Pipe Binding Protocol Allows a peer to bind a pipe advertisement to a pipe endpoint, thus indicating where messages actually go over the pipe. Bind occurs during the open operation, whereas unbind occurs during the close operation. Peer Endpoint Protocol This protocol allows a peer to ask a peer router for available routes for sending a message to a destination peer. Any peer can decide to become a peer router by implementing the Peer Endpoint Protocol. JXTA supports a number of mechanisms for peer discovery. However, it does not mandate exactly how discovery is done. It can be centralised or decentralised. JXTA does not mandate how messages are propagated, therefore, it does not restrict the message to a LAN. Project JXTA will initially implement security classes for the RSA public key exchange, the RC4 byte stream cipher, and the Secure Hash Algorithm (SHA-1) [3]. It also provides a framework where different security solutions can be plugged in. IST PUBLIC 19 / 31

20 4.6. LDAP BASED INFORMATION SERVICES LDAP accesses hierarchically structured information. Its main use has been for address books and other similar systems where the information it contains is static. Obviously for use as an information service within a grid environment the limitation of only being able to handle static data is unacceptable. Therefore two solutions for handling dynamic data within LDAP have been developed: these are Globus s MDS and Ftree. Both systems have overcome the problem by having entries in the DIT (Directory Information Tree) that runs scripts that populate the underlying levels of the DIT. The actual implementation of this differs within both systems Globus MDS Within the Globus configuration active entries can be specified. The active entry runs a script on demand. When a search is undertaken on a section of the DIT under the active entry, a script is run to generate entries in the underlying section of the DIT. The entries created by the script have a time stamp and a ttl (time to live) associated with them and will be cached. Subsequent inquiries will then check the timestamp and ttl of the cached information to see if the information is still valid, if it is then the cached information will be returned otherwise the script will be rerun to refresh the cache. This can result in slow response times. Globus MDS uses GRIS s (Grid Resource Information Server) and GIIS s (Grid Information Index Server). These are specific instances of LDAP servers each of which uses a different customised LDAP backend. A GRIS sits on a resource and publishes information about that resource. A GIIS is an index of GRIS s and provides a means of grouping resources. A GIIS may also contain indexes of other GIIS s thus enabling the creation of hierarchical data structures. For example a site would have a site GIIS in which all of the site resources where registered. This would then form a single point of contact for any queries about the resources at that site. Previous versions of MDS have used file based caching whereas MDS 2.1 uses memory based caching. There is a registration protocol between GRIS s and GIIS s. When a GRIS is started it will register with one or more GIIS s depending upon how it was configured. A GIIS is configured to allow registration from hosts with known credentials. Site GIIS s could then register with a higher level GIIS, i.e. a country or virtual organisation GIIS. Globus s MDS supports GSI (Grid Security Infrastructure) authentication and access control. Client and server can mutually authenticate using public key technology. Access can be restricted to trees of data or categories of information such as object classes and attribute types. A particular name or everything below it can be accessed to return information on a set of results. Authorisation can be static, "self," or dynamic. Static authorisation is based on class, attribute, or object name rules. "Self" authorisation is based on a semi-dynamic rule, and requires an "owner" attribute on objects. Authorisation is also possible for a group, based on LDAP distinguished names. Dynamic authorisation is based on per-object access rule attributes. That is, the object contains the access rule within itself. Dynamic authorisation uses directory-based group lists. LDAP dynamic authorisation is being worked on in the LDAP community Ftree As with Globus s MDS, Ftree uses the concept of active entries to provide dynamic information. However unlike Globus MDS these active entries are true object classes within the DIT and as such can be read and written using standard LDAP client commands. As well as providing the cache searches data model employed by Globus Ftree also has the cache periodically and cache from stream data models all of which use memory based caching. The cache periodically option runs a script at a pre-determined interval that should be shorter than the ttl of the information it provides. Hence when IST PUBLIC 20 / 31

21 searching the DIT current information will already be cached in memory and there will be no need to run a script in response to the query, this results in fast response times. The cache from stream data model is very useful when setting up hierarchical structures, in particular when setting up the equivalent of a Globus GIIS. For example, a number of information servers each supplying information about a resource, may be configured to run on a number of machines around a site. All the information can then be cached in the site cache; the connection is initiated from the site cache. This is the reverse to Globus s MDS where the registration is made from the GRIS to the GIIS. Using the cache from stream model, once the connection is made the resource servers will push updates of information to the site cache. The site cache is not restricted to being just a cache for other servers, it to can also be a direct provider of information. This is because the functionality is controlled by the object classes rather than having to use different backends as in the case of Globus s MDS. An LDAP server can also be set up as a country/virtual organisation cache to which updates of information are streamed from the sites below it. This then enables complex multi-site queries to be resolved directly by the country/virtual organisation server without having to specifically refer to individual sites, resulting in fast response times. Caching at every level of the organisation will not scale. When it is no longer feasible to cache all of the information, referrals to lower level caches may be used. Ftree can use any of the security features supplied by openldap. These include strong authentication services through the use of SASL (simple authentication and security layer) and privacy and integrity protections through the use of TLS (Transport Layer Security) (or SSL (Secure Sockets Layer)). The TLS implementation utilises OpenSSL software. Access can be controlled using entries based on LDAP authorisation information, IP address, domain name and other criteria. OpenLDAP supports both static and dynamic access control information. Ftree was developed within WP3 before MDS 2.1 was available MULTI ROUTER TRAFFIC GRAPHER (MRTG) The Multi Router Traffic Grapher (MRTG [18]) is a tool to monitor the traffic load on network-links. MRTG generates HTML (Hyper Text Mark-up Language) pages containing PNG (Portable Network Graphics) images, which provide a visual representation of traffic. MRTG consists of a Perl script which uses SNMP (Simple Network Management Protocol) to read the traffic counters of routers and a C program which logs the traffic data and creates graphs representing the traffic on the monitored network connection. These graphs are embedded into webpages which can be viewed from a Webbrowser. The basic graph MRTG generates shows the traffic seen in the last 24 hours. In addition to the detailed daily view, MRTG also creates visual representations of the traffic seen during the last seven days, the last four weeks and the last twelve months. MRTG is not limited to monitoring traffic; it is possible to monitor any SNMP variable. An external program can also be used to gather the data which should be monitored via MRTG. It also allows the accumulation of two or more data sources into a single graph. MRTG is however limited to only monitor changes of values in time. This is because of the way it keeps a log of the relevant data needed to generate the graphs. This log is automatically consolidated, so that it can be small and does not grow over time. This is achieved by taking measurements at regular time intervals, calculating differences of consecutive measurements and storing only changes averaged during time intervals (and the maximum value) instead of the measurements themselves. Measurements from different sources are resampled to the standard time slot of five minutes. MRTG does not keep all of its history in five-minute intervals however. Older data is stored in thirty-minute intervals, two-hour intervals and one-day intervals. The rationale behind is that if the image created IST PUBLIC 21 / 31

22 by MRTG is 400 pixels wide and the amount of time displayed is 400 days, there is no point in keeping five-minute averages, because the image cannot show this resolution. There are four images in a standard MRTG install. All four images display 400 intervals by default. The sizes of the intervals are: daily: with five-minute intervals, for a total of 400 * 5 minutes or 1.3 days, weekly: with thirty-minute intervals, for a total of 400 * 30 minutes or 8.3 days, monthly: with two-hour intervals, for a total of 400 * 2 hours or 33.3 days, yearly: with one-day intervals, for a total of 400 days or 1.1 year. This is reflected in the log file but with different amounts. For the daily, weekly and monthly part there are about 600 lines with average values on corresponding intervals. The yearly part of the log file is about 732 lines with averages on one day intervals. This way wider images can also be generated that can display more data. The visualisation and data handling part of MRTG is also available separately as Round Robin Database tool (RRDtool) [19] NETLOGGER The NetLogger system enables real time diagnosis of performance problems in complex distributed systems. The system combines network, host and application level monitoring to provide a complete view of the entire system [4], [5], [6]. Main suggested application areas are: performance and bottleneck analysis, selecting hardware components to upgrade (to alleviate bottlenecks), real-time and post-mortem analysis of application, correlating application performance with system information. netlogd trace file sensor instrumented application process sensor Figure 10. Structure of NetLogger IST PUBLIC 22 / 31

23 Components: Message format: IETF (Internet Engineering Task Force) ULM (Universal Logger Message) format. Used for logging and exchange message. API: It links the application with the NetLogger library (currently available in the following languages: Java, C, C++, Perl, Python, Fortran and Tcl). It uses simple calls that given a timestamp, builds NetLogger a message and sends it to its destination. Client library: Using the library one can send log messages to a local file, a remote host or local memory. It also includes wrappers for several systems monitoring utilities. Host and network tools: Typical network tool examples are host monitoring, router monitoring and ATM (Asynchronous Transfer Mode) switch monitoring. Monitoring tools that can be used wrapped with programs include netstat (used e.g. TCP retransmission), vmstat (used e.g. system load), iostat (used e.g. disk activity) and ping. Visualisation tool: It is used for interactive graphical representation of system-level and applicationlevel events. The visualisation tool can display several types of events at once. It is user configurable and can play, pause, rewind, provide slow motion, zoom, etc. It can run post-mortem or in real-time. It uses three types of primitives: 1. Lifeline represents the life of an object (datum or computation) as it travels through a distributed system. The slope of the lifeline gives a clear visual indication of latencies. Each object has a unique identifier. 2. Loadline connects a series of scaled values into a continuous segmented curve. Most often it is used for representing changes in system resources (e.g. CPU (Central Processing Unit) load or free memory). 3. Point is used to graph single occurrences of events (e.g. error or warning conditions). It can be scaled to a value producing in a scatterplot. A more detailed structure of NetLogger is shown in Figure 10, where netlogd is a data-logging daemon that writes trace data into the trace file. Sensors and instrumented application processes can generate events in ULM formats using the client library of NetLogger and send them to the netlogd daemon. Sensors can run remotely from netlogd and send data through the network NETWORK WEATHER SERVICE The Network Weather Service [11], [12] and [13](NWS) is a distributed system that periodically monitors and dynamically forecasts the performance that various networks and computational resources can deliver over a given time interval. It operates a distributed set of performance sensors (CPU monitors, network monitors, etc.) from which it gathers readings of instantaneous conditions and then uses numerical models (mean-based, median based and autoregressive methods) to generate forecasts of what the conditions will be for a given time frame. NWS tracks the accuracy (using prediction error as an accuracy measure) of all predictors, and uses the one exhibiting the lowest cumulative error measure at any given moment. In this way, it automatically identifies the best forecasting technique for any given resource. NWS currently measures end-to-end network performance (latency and bandwidth), available CPU percentage and available memory. A sensor interface is in development that will allow new internal sensors to be configured into the system. Time series of any numerically representable metrics can be inserted into the system and the forecasting module can be used to make predictions based on this data. IST PUBLIC 23 / 31

24 The NWS provides four components that can be connected to build a monitoring environment (see Figure 11): Name server process It implements a directory capability used to bind process and data names with low-level contact information (TCP/IP address and port number). Active processes must register their bindings periodically. NWS registrations follow the LDAP model. The address of the NWS Name Server Process is the only well-known address used by the system allowing both data and services to be distributed. Sensor process It gathers time stamped performance measurements from a specified resource. Each sensor process may measure several different performance characteristics, known as skills. The currently supported skills are: cpumonitor: This skill monitors the fraction of CPU available to both newly-started and existing processes at different nice levels. diskmonitor: This skill monitors the amount of space available on a disk holding the directories or files of specified paths. memorymonitor: This skill monitors the amount of free memory available on the machine (only available on Linux). tcpconnectmonitor: This skill monitors the time required to establish a TCP connection between each pair of a set of machines. tcpmessagemonitor: This skill monitors the TCP bandwidth and latency between each pair of a set of machines. It can measure small-message round-trip time and large-message throughput. Forecaster Memory file Memory file file file Name Server Sensor Sensor Sensor Figure 11. Structure of NWS Persistent state process (Memory) It stores and retrieves measurements from persistent storage. Sensor processes can store measurements in Persistent State processes. A persistent state must be able to survive the failure of a IST PUBLIC 24 / 31