190 likes | 386 Views
Grid Builder Status. Rui Wang July 16, 2007. Grid Builder. The Grid Builder uses a management console to deploy grids dynamically and remotely The user UI monitors the status of all accessible resources
E N D
Grid Builder Status Rui Wang July 16, 2007
Grid Builder • The Grid Builder uses a management console to deploy grids dynamically and remotely • The user UI monitors the status of all accessible resources • After receives the command from the user, each managed node starts building the required grids/services • Meta data is saved in a so-called Registry, from which the console can retrieve information like: • Host IP Address • Status • UUID • Service Adapter Type • SA manager Type • Operating System, etc
Improvements based on feedbacks • More types of useful metadata are added • The user UI console can refresh the status information automatically • A monitoring thread is added to the service adapter • the user UI can show the output from the remote resource at real time • A prototype resource matching algorithm • E.g., based on OS type • A dialog for user to choose a grid to deploy
Status • A stable version of the grid builder tool is developed and serves as a benchmark for future development • QuakeSim2 portals are installed on Ball’s cluster • Installation manual and demo instructions are created
Future Work • More grid applications for testing purpose • Sensor grids • Collaboration grids (Impromptu) • DoD grids • Metadata repository to replace the current registry • Daemon for maintaining and updating deployed grids automatically • Grid profiles to facilitate feature matching
Deploy, Discover and Manage Sensors in the Grid Builder Rui Wang July 24, 2007
Sensor Grids • To develop a flexible computing environment for coupling real-time data sources to High Performance Geographic Information Systems (GIS) applications • Real Time Data (RTD) server • GPS device and a server • GML encoding for describing the data • Integrate NaradaBrokering to provide real-time access to streaming data
Sensor Discovery Approaches • Top-down • User pre-defined • Bottom-up • Follows the WS Dynamic Discovery specification • Multicast group to discover existing sensor services
Sensor Discovery Process • Initially a sensor sends a multicast Hello when it joins a network • The client (the Grid Builder herein) multicasts a Probe to discover existing sensors • A sensor may receive a multicast Probe and send a unicast Probe Match (PM) if it matches that Probe • The same manner for a Resolve • When a sensor dies or leaves a network, it sends a multicast Bye
Specifications • The probe and reply messages are formatted according to WS_Discovery protocol and enveloped in SOAP • Protocol assignments: • Discovery_Port: port 3702 • IPv4 multicast address: 239.255.255.250 • IPv6 multicast address: FF02::C (link-local scope)
Resource Manager Side Service Side Make Sensors Manageable cgl.hpsearch.core.services.manager.ResourceManager cgl.hpsearch.wsmgmt.WSManProcessor Manager Service Adapter cgl.hpsearch.sensor.SensorManager cgl.hpsearch.sensor.SensorServiceAdapter cgl.hpsearch.wsmgmt.WSManClient Sensor to Manage cgl.hpsearch.sensor.SensorClientAdapter
Sensors in Grid Builder • Deploy a new sensor • Discover existing sensors over the network • Provide up-to-date information on detected sensors • Manipulate managed sensors: • Add/remove sensors • Assign sensors
RTD Server • Currently the sensor grid takes archived data from a specific repository • We developed a filter service to obtain the real time data from a GPS device (I-blue) • NMEA format • Example: $<CR><LF>MRK,0<CR><LF>ZDA,123336.8069,17,06,2001,13.0<CR><LF>GLL,2924.11158,N,1211.07392,W, 75.97,M<CR><LF>VTG,218.7,T,2.38,H,0.18,V<CR><LF>SGD,-1.0,G,-1.0,M<CR><LF>SYS,3T,9<CR><LF>ZEV,0.28745E-006<CR><LF> • A host running the filter service, which could be a laptop, PDA or Tablet, can work as the RTD server
Additional Slides • HSD demo? • Group/Sharedlets?