# Presentation: 205154

## “Warehouse” Monitoring Software Infrastructure

- Craig Steffen, NCSA
- SSS Meeting       June 5,6 2003
- Argonne, Illinois

## The Task

- Create a replacement for the System Monitor Component
- Current design not scalable
- Ugly code, not easy to maintain

## The Challenges

- Make it scalable
- flexible
- easy to maintain
- turns lead into gold

## The Old Way:

- collector

- Periodic updates

- node monitor

- node monitor

- node monitor

## The New Way:

- Periodic updates

## Also The New Way:

- Periodic updates

## All Nodes Are The Same

- Each blue box on the tree has the same role.  It obtains information, stores it, and passes it up the tree

- Info store

- Info out

- Info in

## Important Generalization

- In general, each box accepts and stores info about multiple other boxes.
- For efficiency and generalization purposes, each box must categorize its information.

- Info store

- Info out

- Info in

- Info in

## Warehouse Design

- source

- source

- From
- compute1

- From
- compute2

- sink

- To compute
- Info display

- sink

- To work room
- Monitor display

- Multiple sinks

- Multiple sources

## The Notion of a “Node”

- Two numerical lists for comparisons

- Non-typed string list

## Information is Untyped

- Information is designated as integer or float to utilize comparisons
- Otherwise, information is untyped
- Intermediate layers have no need to know what the information means

## Configuration only extends one layer:

- Clus. 1, comp 0f

- Clus. 1, comp 00

- Clus. 2, comp 00

- Clus. 2, comp 0f

- . . .

- . . .

- NCSA cluster 1

- NCSA cluster 2

- NCSA cluster superv.

- Group: compute

- Node: comp00

- . . .

- Node: comp1f

- Teragrid superv.

- Group: NCSA compute

- Node: comp00

- . . .

- Node: comp1f

## Combine NCSA clusters 1 and 2

- Clus. 1, comp 1f

- Clus. 1, comp 00

- . . .

- NCSA cluster 1

- NCSA cluster superv.

- Group: compute

- Node: comp00

- . . .

- Node: comp1f

- Teragrid superv.

- Group: NCSA compute

- Node: comp00

- . . .

- Node: comp1f

- Cluster 1: new IP
- Addresses and such

- This warehouse has
- Its config change

- This warehouse is
- Unaware of any
- change

## Source Configuration

- source

- source

- sink

- What each source knows:
-   who to connect to
-   list of internal group,node and external group,node pairs

## Warehouse as “Node Monitor”

- source

- sink

- “Node Monitor” role is just a source that talks to a local library

- Hardware
- Monitor lib.

- Group “”

- Node “”

## Implementation is modular

- Source and sinks are modular (supplied by external libraries?)
- At first simple, later implementations can be more sophisticated
- Interoperability as long as protocol doesn’t change

## First steps

- Sinks:
- Deliver all info every 5 seconds
- Act as SSS XML client
- Deliver requested info at requested intervals

- Sources:
- Accept info without asking for it
- Request just what’s being asked for from above

## What has been done

- Information storehouse infrastructure (lots of code, thread safe)
- Basic sink (tested via keyboard)
- Basic source (under software test)

## The Grand Design

- Efficient use of bandwidth, only update changed information
- Self tuning update intervals
- Message passing to request information through the tree