Transcript S-DAD: Site Dynamic Announcement & Discovery

DADS: Dynamic Announcement
& Discovery on a Site
Abdeslem DJAOUI
Group meeting
Monday 12 Dec 2005
What is it?
• Using techniques such as IP multicasting
– Spontaneous discovery of services as they come and go
• Services send an announcement to a multicast group when they
are started and when they are stopped
• Client listen to the multicast group and discover services as
they come and go
– Client can probe for listening services based on name,
type …
• Multicasting relies on existence of IP network
only
– No need to know an information service endpoint
before discovering services of interest
– Services that wish to be discovered dynamically Must
implement some DADS functionality
Is it needed?
• Existing EGEE user requirements on bootstrapping
– #100537: There must be a simple deterministic procedure to find the entry points to the
information system (bootstrapping problem).
– #100538: It must be possible to obtain information about all grid services the user is
authorized to use (in particular, VOs, RBs, CEs, SEs...) through a well known and unique
procedure. The information system bootstrapping issue (see requirement #100537) should be
solved for this. For the sake of simplicity, their must be a well known and accessible entry
point to the information system.
• But current SD is just an abstracted API on top of
existing Info systems
– Abstraction is not bootstrapping!
• SD as it is, can help bootstrapping (with caching)
• Bootstrapping should
– Minimize expected client knowledge
– Always work (no reliance of client holding volatile data)
Is it high or low priority?
• Priority was low while still struggling with basic
service functionality/reliability problems
• But is increasing as more users move to EGEE.
Right time to start work for it to be ready on time
• Extremely important for users
– connect to a site and be assured they can find where the
UI or RGMA servers are?
– Discovery on Site always available even
• when network link to outside broken
• When Grid Information system breaks down or not known
– Can be used to ease recovery from faults
Optional components of DADS
Architecture version 0.0
• Local relay Proxy
– Many sites have more than one subnet
– Local relay proxy, relays probes to other subnets
– Caches and updates information about services on its
sub-net
– Responds to relayed queries
• Using cached information
• Or may be asked to submit a probe for the most up to date
information
How does it fit in the current
gLite architecture?
• A complement to R-GMA and SD
• SD COULD be augmented with DADS
functionality so it can really be used for
bootstrapping
• Dynamic discovery useful in other instances
– UI can keep the list of its services up to date dynamically
(automated way) – for example R-GMA server endpoints.
– An R-GMA site publisher may wish to use DADS to publish its
existence dynamically (one site publisher per site).
Summary
• DADS is concerned with addressing user
requirements on BOOTSTRAPPING and dynamic
announcement and discovery of services
• Other uses
– Provide alternative discovery for sites when GRID info system
unavailable or link to outside broken
– Fits nicely as an addition to existing SD for bootstrapping
– Presents benefits for other services that are critical for user
interaction with the Grid, such UI.
• Complexity cost
– Relies on multicast techniques (UDP packets)