1

Bringing the Grid Home

Chris Sosa, Andrew GrimshawUniversity of VirginiaOctober 1, 2008

2

Introduction

c Grid

Explosion of Information

SystemsCyclone of Integration

3

The Big Problem

Grid has little uptake

Hard to Use

Inflexible Security

Doesn’t play well with others

4

Solution Criteria

Simple and

Familiar

Flexible Security

Standards-Based

Not Slow

5

Bring in G-ICING

Users and applications are familiar with the filesystem

Grid-backend will appear as a network drive to users

6

Talking to a Grid-Backend Resource Naming Service (RNS)

Basic directory services Entries may be added, deleted and listed

ByteIO Provides POSIX-like interface to resources Resources can be anything (database, a file, a host)

Who else uses it? ByteIO interoperability fiesta – UVa, Fujitsu, EPCC,

UNICORE CERN has a working RNS with LFC and is working on a

ByteIO implementation

7

User to Kernel CommunicationDESIGN ALTERNATIVES

Local Procedure Calls Deprecated by MS Calls are synchronous

Inverted Call Model Takes advantage of the I/O mechanisms in WinNT User level program makes special I/O Request:

“Hello, I’m waiting for an operation” and Kernel mode stores it

Kernel forwards actual I/O requests, to the user mode by responding to the above I/O with the forwarded I/O call

8

IFS Development in Windows

RDBSSI/O Sub SystemI/O RequestProgram

or OSI/O Request

IFSDriver

9

G-ICING Design

UFSKMS Inverted Calls

Grid-backend

J ava VM

GIS

RN

S /

Byt

eIO

I/O Request JNI

10

Kernel Management Service (KMS)

Installable File System Driver Network Redirector Kernel driver that interacts with other

Kernel components Communicates to User-mode UFS

with Inverted Call Model

11

User Forwarding Service (UFS) Uses JNI to

communicate and forwards requests to GIS

Prompts user for credentials and obtains a delegated credential for use Flexible Security

through Delegation

12

Grid Interface Service (GIS) Converts FS

requests into ByteIO/RNS calls

Caches meta-information from ByteIO/RNS

Only interface to Grid-backend

Meta-data Caching

13

Prototype in Action

14

Prototype in Action (Continued)

15

Evaluation Usability (compared to the alternatives)

Shell Extension (not app transparent) Posix-like libraries (neither user or app

transparent) Special libraries – application transparent only if

recompiled (can't with COTS or Legacy) Security

Depends on the Grid-backend but prototype is compatible with a flexible delegation model

Standards – RNS, ByteIO Performance – Coming up …

16

Performance Evaluation Setup Client

Single-core 2.34 GHz desktop machine with 1GB memory running WinXP

100 Mbps connection Grid-Backend

Genesis II running on seven 8-core Xeon processors running at 2.33 GHz with 16 GB memory

1 Gbps connection

17

Performance Evaluation

G-ICING R/W with Varying Record Size

1

10

100

1000

10000

100000

4 8 16 32 64 128 256

Record Size in KB

KB

/S

CIFS Write CIFS Read IFS Write IFS Read

18

Future Work

1. Improve performance On-disk caching of data of both ByteIO and RNS data Research in location-aware caching

2. Implementation and Comparison to different FS mechanisms in other OSs

3. Stretching RNS / ByteIO interfaces to perform more Grid services

19

Conclusions

Grids are still too difficult to use for both users and applications

Can extend the filesystem paradigm in Windows to bring the Grid to users

20

Related Work LUFS and FUSE are filesystem in user-space

technologies for UNIX / Mac Lack support for Windows Tied to UNIX security semantics

Open AFS creates a modified Samba server but stuck to Samba/CIFS security model

Gfarm uses FUSE + syscall hook library Same problems with just FUSE Overly complex for Windows, requires set up of a

separate Linux box to forward messages through Glite provides POSIX-like interface that is neither user

or application transparent

21

Questions

?