A Scalable Virtual Registry Service for j GMA

A Scalable Virtual Registry Service for j. GMA Matthew Grove DSG Seminar 3 rd May 2005

Outline • Introduction, • Changes made to the j. GMA design from last time (November 2004), • The architecture of the Virtual Registry (VR), • An implementation of the VR using IRC, • Benchmarking j. GMA, • Summary. 1

Introduction • j. GMA is a pure Java reference implementation of the GGF's Grid Monitoring Architecture, • The j. GMA design philosophy is to reuse existing implementations rather than reinvent them, • To complete the implementation j. GMA requires a registry component which must: – Be scalable, – Store sufficient information to be GMA compliant, – Be secure, and prevent unauthorised access to the data, – Need minimal configuration, – Ideally have no single point of failure, – Be robust and tolerant of network failure, – Efficient query routing between VRs. 2

Old j. GMA Architecture 3

Architecture Changes • We combined the old Registry and PC Servlets into one service called the Mediator, • The Mediator provides hooks for a distributed Virtual Registry, • The client-side architecture has remained untouched. 4

New j. GMA Architecture 5

Implementation Changes • Moved from Tomcat[4|5] to Jetty, • Changed the internal API to cleanly encapsulate external communications code, • Rewrote all code to make better use of features of Java 1. 5 including the new concurrency package. 6

The Mediator replaces the PC Servlet and the Registry Servlet. 7

The j. GMA Library and API A choice of two local registries have been implemented: Simple (volatile) and My. SQL. The Mediator did not require changes to the client code. 8

Virtual Registry Services • Bootstrapping: Joining the j. GMA network with minimal hardwiring, • Communications: Efficient routing of queries between VR peers, • Caching: Keeping a temporary local copy of some information to reduce the amount of communications between peers. The API is designed to allow different implementations of these core services to be mixed and matched. 9

IRC VR Service • It is an attempt at meeting the criteria of the j. GMA VR by building a service which uses the Internet Relay Chat protocol. • IRC networks have servers connected via a graph topology, some networks manage thousands of users. Simultaneous connections yesterday on some major networks: –Efnet – 89, 817 –Under. Net - 75, 191 –Freenode – 21, 953 10

IRC VR Service Continued Each Mediator has an “IRC Bot” which connects to a chosen IRC network (the IRC networks maintain a DNS pool providing fault tolerant bootstrapping). – – The Bot joins a channel and announces itself to other Bots, The Bot publishes search queries to the IRC channel, Other Bots receive the queries and pass them onto the Registry backend, The Bots reply to the queries via a private message over IRC. All messages are routed by the IRC network. 11

IRC VR Walk-Through 12

IRC VR Strengths • Established distributed network (IRC was ‘born’ in 1988 and the RFC was published in 1993), • Efficient / scalable routing of messages, • Establishing client liveliness is handled by the IRC protocol, • Fault tolerant bootstrapping via DNS, • Various degrees of security can be provided by combinations of: – Leveraging functionality built into the IRC protocol (locking the channel, private messages), – Using features of the IRC daemons such as encrypted routing for IRC messages, – Running your own IRC daemons rather than using a public network. 13

IRC VR Implementation • Done: –Bots join the IRC network, –Bots can post and read j. GMA queries to channels, –Bots can receive query responses via IRC private messages. • TODO: –The IRC Bots do not interact with the Mediator yet, –Bots need to be able to join a locked channel, –There is no caching (this is a generic VR service, not just for the IRC VR). 14

IRC VR Issues / Questions • What are the limits on individual channels, is there a need to have multiple channels and route messages between them? • Using IRC requires an extra port be accessible to the mediator (out going port 6667). 15

Future Work • Short term: –Complete the IRC VR, –Implement a generic caching service for the VR, –Write a simple P 2 P VR which can be used in place of the IRC VR. –Benchmark j. GMA against Naradabroker. • Longer term: –Do another binary release of j. GMA, –Develop an application or library on top of j. GMA. 16

Summary • Current work is focusing on the implementation of IRC VR, • The design of the j. GMA architecture is hopefully complete. 17

Links • Project Web page: – http: //dsg. port. ac. uk/projects/j. GMA/ • The DSG Web page: – http: //dsg. port. ac. uk/ 18