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

User Interface (1)

User Interface (2)

User Interface (3)

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

Major Sensor Grid Components

Sensor Discovery Approaches

• Top-down– User pre-defined

• Bottom-up– Follows the WS Dynamic Discovery

specification– Multicast group to discover existing sensor

services

Message Exchanging between Sensor Adapter and Client

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)

Make Sensors Manageable

• Resource Manager Side

• Service Side

Ser

vice

Ada

pter

cgl.hpsearch.wsmgmt.WSManProcessor

cgl.hpsearch.sensor.SensorServiceAdapter

Sensor to Manage

Man

ager

cgl.hpsearch.core.services.manager.ResourceManager

cgl.hpsearch.sensor.SensorManager

cgl.hpsearch.wsmgmt.WSManClient

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?