250 likes | 430 Views
MSc Project. Grid Services Monitor Long Term Monitoring of Grid Services Using Peer-to-Peer Techniques. Yin Chen Supervised by Dr Stuart Anderson 2003. Content. ● Requirements ● Architecture ● Design & Implementation ● Implementation Outcome. Grid Services Monitor. Requirements ….
E N D
MSc Project Grid Services Monitor Long Term Monitoring of Grid Services Using Peer-to-Peer Techniques Yin Chen Supervised by Dr Stuart Anderson 2003
Content ●Requirements ● Architecture ●Design & Implementation ● Implementation Outcome
Grid Services Monitor Requirements …
Requirements ● Monitoring grid services behaviours ● Providinglong-term historicalinformation ●Reporting to an end-user or a prediction model ● Helping make prediction of services behaviours
Requirements ●The system must be fault tolerant ●Should allow nodes to join and leave dynamically ●Must be able to scale with the grid ●Monitoring data must be distributed
GridServicesMonitor Architecture …
Architecture ●Peer-to-Peer architecture ●Why P2P ? -Decentralized fashion - Much scalability - Better fault tolerance ● Traditional P2P system designed for file sharing and storing ● This project focuses on decentralized data querying and retrieval
System Architecture Monitor Sensor Monitor Sensor Data Store Data Store Local Collector Local Collector Listener A Listener B Collector Data Store Requester
Peer Group C Peer Group A Peer Group B Topology
Pull Model ●Data delivered by Pull ● Pushmodel: the listener sends out notifications to other peers ● Advantages : - Less network traffic: data deliver only when necessary -Has NO time synchronisation problem: collect data from resources at the same time -The requester determines query conditions, data type etc., making data operation easier
Requester Merge Query Union Receive … Receive Send Send Local Query Local Query Listener A Listener N Query Planning
Grid Services Monitor Design & Implementation …
Design & Implementation ●Monitor Sensor ●P2P Transport Mechanism ●Decentralized Data Storage and Querying
Monitor Sensor ● Implement GT3ServiceLifecycleMonitor Create – when an instance of service is going to be created Destroy – when the instance is going to be destroyed PreCall – the service is going to be invoked PostCall – service invocation has finished PreSerializationCall – input parameters are going to be desterilized PostSerializationCall – input parameters have been desterilized ● Problem: can NOT report failure of the service instance ● Solution: use timeout
P2P Transport Mechanism ●Based on JXTA platform ● Queries are scoped to one peer group ● A requester multicasts a request message, all listeners response by sending back requested data ● Controlling the messages not to flood the network - Data delivered by Pull - Reduce the size of messages: Local collector precooked data - Reduce the volume of messages ●Timeout: to finish a data collection process
P2P Transport Mechanism ListenerB Monitor Sensor Output Pipe Data Store Input Pipe ListenerC Local Collector Peer Group Input Pipe Output Pipe ListenerA Output Pipe Input Pipe Collector Data Store Requester
Data Storage & Querying ● Using XML file : light weight and platform independence ●Decentralized manner: Insert handled by Monitor Sensor of each Listener Retrieve by Local Collector of each Listener Datajoin by Collector of Requester ● Data operations: Insert : inserts a ChildNode at the root of log file Query : XPath Join : adds PeerID as a part of primary key to avoid primary key replication problems
Grid Services Monitor Implementation Outcome …
Generating Monitoring Data Gt3 Server keeps tracing and monitoring <?xml version="1.0" encoding="ISO-8859-1" ?> -<log> <servicename="Weather Service" date="Aug 14, 2003" start="9:55:43 AM BST" end="9:55:59 AM BST" succeed="true" /> <servicename="Weather Service" date="Aug 14, 2003" start="9:55:43 AM BST" end="9:56:00 AM BST" succeed="true" /> </log> A Grid Service having a monitor sensor on it Sample of log record
Collecting Monitoring Data • ListenerA • RequesterA> request • Finish calculating data • RequesterB> request • Finish calculating data • ListenerB • RequesterA> request • Finish calculating data • RequesterB> request • Finish calculating data • ListenerC • RequesterA> request • Finish calculating data • RequesterB> request • Finish calculating data • RequesterB • ListenerB>I got it • ListenerC>I got it • Finish collecting data • Data collected from 2 peers • RequesterA • ListenerA>I got it • ListenerC>I got it • ListenerB>I got it • Finish collecting data • Data collected from 3 peers
Displaying Data In Graphical Layout Number of responding peers Service name Key Line of total running times Y Axis indicates successful or total running times Marks on the line indicate the values X Axis indicates the duration of the data Line of successful running times
Displaying Data In Table Layout Service name Number of responding peers The date of period Success time Total running time
Grid Services Monitor Thanks !