# Presentation: 659936

## An Architecture and Protocols for Grid Performance Monitoring

- Dan Gunter
- DIDC Group
- Distributed Systems Division
- National Energy Research and Supercomputing Center
- Lawrence Berkeley National Laboratory
- Berkeley, CA, USA

## Outline

**Introduction**
**Requirements of Grid performance monitoring**
**Grid Monitoring Architecture (GMA)**
**GMA work so far**
**Future directions **
**Conclusion**
**References**

- 22 March 2001

## Introduction to the “Grid”

**Direction of metacomputing is connected groups of computing resources that can work together as a single “Grid” for large (e.g.: particle physics, climate simulation) applications**
**Global Grid Forum is defining standards for interoperability**
**GGF Performance Working Group is defining standards for collection and dissemination of Grid performance monitoring information**

- 22 March 2001

## What is Grid Performance Monitoring?

**Implies that a resource or process exists that can be measured over time**
**Performance monitoring is the collection of measurements of that resource or process, and the dissemination of that information to other parties**
**“****Grid performance monitoring” simply means that the resource or process is part of a Grid**

- 22 March 2001

## Requirements for Grid Performance Monitoring

**Scalable: no central bottlenecks in either control of monitoring or sending/receipt of monitoring data**
**Efficient: ability to handle many high-volume streams of information**
**Flexible: can work with broad variety of types of existing monitoring tools**

- 22 March 2001

## Grid Monitoring Architecture

- 22 March 2001

## GMA Producer-Consumer Protocol (1)

**Publish/Subscribe model**
**Consumer can subscribe to Producer to receive a stream of events**
**Producer can subscribe to Consumer to push a stream of events**
**Either side can unsubscribe**
**Query model**
**Consumer can get a single event**

- 22 March 2001

## GMA Producer-Consumer Protocol (2)

**Example of Consumer subscribing to latency information between two hosts.**

- 22 March 2001

## Simple XML Producer-Consumer Protocol (1)

**Developed to test producer-consumer protocol ideas**
**Emphasis on ease of debugging, clarity for explanation**
**In the next two slides, sample messages are shown for a consumer subscribing for a *****ping***** event (from host *****foo *****to host *****bar) *****-- steps 3. and 4. on the diagram in the previous slide.**

- 22 March 2001

## C: <SubscribeRequest requestID=‘10’>
<SubscriptionID> 100 </SubscriptionID>
<PingParameters>
	<Period> 15 </Period>
	<SourceHost> foo </SourceHost>
	<TargetHost> bar </TargetHost>
</PingParameters>
</SubscribeRequest>
P: <SubscribeReply requestID=‘10’>
	<SubscriptionID> 6001 </SubscriptionID>
	<Return>Success</Return>
</SubscribeReply>

**<SubscriptionID> 100 </SubscriptionID>**
**<PingParameters>**
**	****<Period> 15 </Period>**
**	****<SourceHost> foo </SourceHost>**
**	****<TargetHost> bar </TargetHost>**
**</PingParameters>**
**</SubscribeRequest>**
**P:**** <SubscribeReply requestID=‘10’>**
**	****<SubscriptionID> 6001 </SubscriptionID>**
**	****<Return>Success</Return>**
**</SubscribeReply>**

- -- continued --

- Simple XML Producer-Consumer Protocol (2)

- 22 March 2001

## P: <Event subscriptionID=‘100’>
<PingEvent>
	<SourceHost> foo </SourceHost>
	<TargetHost> bar </TargetHost>
	<TimeStamp> 2001-03-22T11:00:00.143 </TimeStamp>
	<RoundTripTime> 87.5 </RoundTripTime>
</PingEvent>
</Event>
P: ... more <Event> messages ...
C: <UnsubscribeRequest requestID=‘11’>
<SubscriptionID> 6001 </SubscriptionID>
</UnsubscribeRequest>
P: <UnsubscribeReply requestID=‘11’>
<Return>Success</Return>
</UnsubscribeReply>

**<PingEvent>**
**	****<SourceHost> foo </SourceHost>**
**	****<TargetHost> bar </TargetHost>**
**	****<TimeStamp> 2001-03-22T11:00:00.143 </TimeStamp>**
**	****<RoundTripTime> 87.5 </RoundTripTime>**
**</PingEvent>**
**</Event>**
**P:**** ... more <Event> messages ...**
**C:**** <UnsubscribeRequest requestID=‘11’>**
**<SubscriptionID> 6001 </SubscriptionID>**
**</UnsubscribeRequest>**
**P:**** <UnsubscribeReply requestID=‘11’>**
**<Return>Success</Return>**
**</UnsubscribeReply>**

- -- Fin --

- Simple XML Producer-Consumer Protocol (3)

- 22 March 2001

## GMA Work So Far

**GGF White Paper**
**GGF “Simple Case Study” document**
**Simple XML Producer-Consumer protocol**
**Subscribe, Unsubscribe, Query, two event types (ping, cpu load).**
**Interoperable C++, Java implementations**

- 22 March 2001

## Future Directions

**Actuators**
**Archives**
**Producer/consumer pipes**
**Third-party event transfers**
**XML protocols: XML-RPC, BEEP, SOAP**
**Data models**

- 22 March 2001

## Actuators (1)

**“****Subscribe” can be used as an **_**implicit**_** command to start a certain type of monitoring, but **_**explicit**_** control may be needed**

- 22 March 2001

## Actuators (2)

**Could be modeled as a separate set of producer “control” functions, i.e. a control interface (and associated protocol)**
**The actuator is then just a consumer that can speak this control protocol**

- producer

- event delivery
- interface

- event control
- interface

- consumer

**events**

- start, stop, etc. monitoring

- subscribe, query, etc.

- 22 March 2001

## Archives

**An archive could act as both a producer and a consumer**
**The back end could be anything from a relational database to a flat file**

- 22 March 2001

## Producer/Consumer Pipes

**Statistical summaries of the data from one or more producers will be a commonly needed function**
**This can be implemented by a “pipe” that receives events from more than one producer**

- 22 March 2001

## “Third-Party” Event Delivery (1)

**It will be useful to deliver events to a given URL instead of to the subscribing host.**
**For example, when a consumer wants to send events to an archive**
**Very infrequent events could perform a connect/disconnect for each event to avoid overhead of mostly idle connection-per-consumer.**
**This also applies to non-third-party event delivery, of course**

- 22 March 2001

## “Third-Party” Event Delivery (2)

**Very infrequent events**
**A new connection is made for each delivered event**

- 22 March 2001

## “Third-Party” Event Delivery (3)

**Relatively frequent events**
**The producer subscribes and unsubscribes to the third-party consumer**

- 22 March 2001

## XML Protocols (1)

**Current prototype is handcrafted XML messages over TCP. **
**Several alternatives exist, including:**
_**XML-RPC**_**: API for XML call-response over HTTP. Mature implementations.**
_**SOAP**_**: API for XML messaging (including call-response) over arbitrary transport, although in practice only HTTP. Immature implementations. (W3C)**
_**BEEP**_**: Protocol “middleware”; not XML-specific. Immature implementations. (IETF)**

- 22 March 2001

## XML Protocols (2)

**These alternatives suggest a variety of conflicting approaches, including:**
**Use XML (XML-RPC or SOAP) for all control messages, set up separate data channel for XML or binary event data.**
**Use XML (SOAP) for XML control and data, then a separate handcrafted binary control/data protocol.**
**Use XML/binary messages over BEEP.**
**Which is best? Implementation experience is needed to decide.**

- 22 March 2001

## Data Models

**Early on, Event data model was attempted but discussions went in circles**
**For XML prototype, only name=value pairs were used:**
**<name> value </name>**
**XML can easily be extended, but a binary event format needs to make this decision early**
**Arguments for changing the data model need to be considered**

- 22 March 2001

## Data models: Time series

**De facto “*****event*****” data model is just name=value pairs**
**This makes it hard to efficiently represent time series because “meta” data is not separated from data that changes for each time **
**NWS folks (M. Swany, R. Wolski) providing input on what’s needed **

- 22 March 2001

## Data Models: Relational?

**Is the current event model too simple to be truly useful?**
**Steve Fisher and others argue that relational data model should be used instead**
**Does this answer the **_**[requirements](slide5.xml)**__**?**_
**This is still an open issue**

- 22 March 2001

## Conclusion

**GMA seems like a good start**
**Many areas still under discussion and definition**
**Implementations needed to clarify actual tradeoffs**
**Testbeds and applications needed to really evaluate scalability, efficiency, flexibility of underlying models**

- 22 March 2001

## References

**Global Grid Forum**
**http://www.gridforum.org**
**BEEP (Blocks Extensible Exchange Protocol)**
**http://bxxp.org**
**XML-RPC**
**http://www.xmlrpc.com**
**http://www.pythonware.com/products/xmlrpc (Python implemenation)**
**SOAP (Simple Object Access Protocol)**
**http://www.develop.com/soap**
**http://www.soapware.org**

- 22 March 2001