1 / 60

perfSONAR Multi-LS

perfSONAR Multi-LS. Jason Zurawski Martin Swany. Overview. Introduction Functionality Dev Status Future Plans Demo. Introduction. A single LS instance would have problems scaling to the increased volume of global deployment Need multiple LS instances

keren
Download Presentation

perfSONAR Multi-LS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. perfSONARMulti-LS Jason Zurawski Martin Swany

  2. Overview • Introduction • Functionality • Dev Status • Future Plans • Demo

  3. Introduction • A single LS instance would have problems scaling to the increased volume of global deployment • Need multiple LS instances • They need a way to discover one another • The key idea is to relate local LS instances through the exchange of information 'summaries'. • This transformed data is smaller, yet attempts to retain necessary lookup properties.

  4. Introduction • Through federation it is possible to link many LS instances on the inter-domain level, as well as extending this notion between domains through the use of a dedicated representative (leader). • Queries will attempt to be resolved locally first, before either iterating through multiple layers of LS, or simply returning a pointer to the proper location to query.

  5. Introduction • Local LS Schematic

  6. Introduction • Global LS Schematic

  7. Functionality • XSLT Transformation • New XMLDB organization, procedures • Join Algorithm • Token Passing Algorithm • Leader Election / Leader Mirroring • Query Interface • XML Formats

  8. Functionality - XSLT • XSLT is a part of the The Extensible Stylesheet Language Family (XSL) • XSLT is a language for transforming XML documents into other XML documents. • Idea: • Define a set of definitions that match a specific pattern. • Feed source documents that fit this pattern, get back a new document defined by the stylesheet

  9. Functionality - XSLT • Example (initial Document):

  10. Functionality - XSLT • Example (stylesheet):

  11. Functionality - XSLT • Example (final document):

  12. Functionality - XSLT • Use in the LS: • Define 'Local' and 'Global' patterns summarize the contents of 'LSStore'. • Local • Compact both the service definition (MP, MA, etc.), and the actual metadata description (interface, endPoint, etc). • Global • Same idea, but compact multiple services/metadata instances further (reduce domain scope, etc.)

  13. Functionality - XSLT • Use in the LS: • All summarized data is stored in the 'LSCache' file. • Periodic event performs the summarization of LSStore information, stores results in LSCache. • Summaries sent by peer LS instances are stored in LSCache • LSCache is subject to the same cleanup rules as LSStore (should summary life be longer?)

  14. Functionality - XSLT • Open Issues • Format/Style of summaries depends on how much information an LS is willing to share • Formats must be similar (to the same generic pattern of the LSStore) or queries are useless. • If an LS drops out of the ring, how long before it's summary should be removed from other's caches? • Should be a function of the size and speed of the ring.

  15. Functionality - Joining • When a new LS comes online, it will try to join up with other LS instances. • For now depends on list of 'known' LS deployments (don't need to be active, but could be) • List will be updated over time • Once other running LS instances are made aware of a new member, the logical ring can grow.

  16. Functionality - Joining • Joining Example: • LS1 is started, looks through its peer list:

  17. Functionality - Joining • Joining Example: • LS2 Inserts LS1 into it's peer list, and will inform other members (LS3) as well.

  18. Functionality - Joining • Joining Example: • LS1 is added to the ring.

  19. Functionality - Joining • Joining Example: • The Peer List is kept 'updated' by an artificial mechanism meant to measure how well each LS knows each other:

  20. Functionality - Joining • Peer List: • The 'familar' parameter is incremented/decremented (max=3 min=0) to indicate when the last communication between a source and destination LS. • When starting, all values are set to '0'. • Each update from an LS increments the value • If an LS can't contact a particular LS, the value is decremented.

  21. Functionality - Joining • Peer List: • A Peer List with all 0 values means needing to rejoin the ring again. • Any time a single LS reaches 0 they are taken out of the ring.

  22. Functionality – Token Passing • The Join procedure touches on the nature of token passing. • Basic Idea: • Pass around 'your' list of active peers. • Each LS will add 'new' peers to their own list • After waiting some time (token delay) a summary message (from the 'LSCache') will be sent to all active peers. • Token is passed again.

  23. Functionality – Token Passing • LS1 is currently holding the token. It is now time to pass it:

  24. Functionality – Token Passing • Summary information is retrieved from LSCache through an XMLDB query. • A summary Message is created, each Peer gets the message; update the peer list for success/failure • Create a Token Message from the Peer list, pass it to the 'next' LS.

  25. Functionality – Token Passing • Same Idea, new LS:

  26. Functionality – Token Passing • What about new additions to the Ring? • When a new LS joins, only one LS instance in the ring knows at first • When the 'new' LS gets the token for the first time it will send its own summary to the group • New summaries are treated just like a Join.

  27. Functionality – Token Passing • Adding a new member:

  28. Functionality – Token Passing • Adding a new member:

  29. Functionality – Leader Election • Each Local group must be aware of the 'Leader' that communicates to the outside world: • Sends/Receives Group Summaries from related Domains • Acts as a 'non-authoritative' answer to queries that may need to go outside of the domain • How to 'elect' this leader?

  30. Functionality – Leader Election • Election: • Take your hostname as an IP, convert to a 'long' value: • 127.0.0.1 = 127*256^2 + 0*256^2 + 0*256^1 +1*256^0 = 2130706432 • Assign some 'rank' between 0 and 5(?) (this can be used to ensure a certain LS is always the leader) • CAT 1 2130706432 = 12130706432

  31. Functionality – Leader Election • These ID values are used when communicating the summaries and tokens around the ring • The 'smallest' ID is the leader of a group. • The next 1 or 2 smallest entries can be selected to be 'Secondary' and 'Tertiary' LS instances in the logical ring • Are given the Global summaries in case the leader fails.

  32. Functionality – Query Interface • A query, be it from a client or a service, needs to respond in a uniform manner: • Iterative: • A query that results in information being NOT on the inital LS returns only the 'location' (i.e. LS information) of where the true data lives. • Recursive: • A query will iterate through LS instances automatically returning the information, and caching this data as it progresses.

  33. Functionality – Query Interface • Iterative Queries: • Simple Xpath/XQuery statements can be created to search both the LSCache/LSStore and return either the requested data, or the LS that has the requested data. • This requires either expert knowledge of Xpath (a pretty tall assumption) or publishing 'cookbook' queries.

  34. Functionality – Query Interface • Iterative Queries: • declare namespace nmwg="http://ggf.org/ns/nmwg/base/2.0/"; • declare namespace nmwgt="http://ggf.org/ns/nmwg/topology/2.0/"; • for $m in /nmwg:store[@type='LSStore' or @type='LSCache']/nmwg:metadata • for $d in /nmwg:store[@type='LSStore' or @type='LSCache']/nmwg:data • where $m/@id=$d/@metadataIdRef and $d//nmwgt:hostName/text()[fn:matches(.,'.*.abilene.ucaid.edu')] • return $m • This particular query is looking for anything on the Abilene network, it will return either an LS metadata, or the actual MP metadata (if it is local to this LS).

  35. Functionality – Query Interface • Recursive Queries: • May be able to get away with using the same Xpath expression, but requires logic to send the query to the LS in question when we get a Hit. • Logic to Cache results is needed as well. • Do we treat the returned results as 'registration' data, or store it in our LSCache?

  36. Functionality – XML Formats • Introduced a new message: • Token • Created a new function for an old message: • LSRegistration, used for summaries • Created 2 new storage mediums: • Peer List • Cache

  37. Functionality – Token MSG • Type = LSToken • Use Parameters (at the msg level) to indicate if this is a 'Local' or 'Global' token. • Body consists of a peer list.

  38. Functionality – Token MSG • Format:

  39. Functionality – Reg MSG • Type=LSRegisterRequest • Use Parameters (at the msg level) to indicate if this is a 'Local' or 'Global' token, and that it is a summary message. • Body consists of a metadata tag describing the sending LS, and related data that is a summary of that LS's LSStore.

  40. Functionality – Reg MSG • Format:

  41. Functionality – Peers Store • Type=LS(Local|Global)Peers • Same Idea as the LSStore/LSStore-control, meant to house peer entries for each level.

  42. Functionality – Cache Store • Type=LSCache • Same Idea as the LSStore/LSStore-control, meant to house cache information that we created, or others give us.

  43. Dev Status • Completed: • XSLT, XML DB organization, Peer Tracking, Join Alg., Token Passing Alg., Leader Election, Leader Mirroring, eXist changes (xquery+update instead of xupdate, v1.1) • In Progress: • Testing, recursive LS queries, finalize XML formats, experiment on timing and efficiency, code cleanup, error handling • ToDo: • Junit, using jar repository?, merge recent trunk changes into my branch, What becomes of my branch?

  44. Future Plans • Complete testing/experimentation • Start Deployment to various locations • Merge into trunk in preparation for next release

  45. Demo • Demo: • Two installations of MLS, we will be simulating 'local' interaction only • Different data will be registered to each LS, it will be summarized, and exchanged via the token passing protocol • This will be verified by examining the eXist DB contents.

  46. Lookup Service

  47. Lookup Service • Service Discovery • From the client • System component inter-communication • Broad Design Considerations • Use existing tooling as much as possible • Flexible levels of information exchange • Scalability via hierarchical organization • Tolerant of component failures

  48. Service Registration with an LS • Express a perfSONAR service as a Subject • Reuse of existing tools and protocol elements inside the perfSONAR tool namespace • Each service creates a self-identification record consisting of contact point and administrative details • Encode information to be advertised as Data • For an MA, encode Metadata of stored measurements inside Data

  49. LS Registration with other LSes • Create registration infoset that summarizes local registration data • Including other known LS instances • Periodically register self-information and registration infoset with other LS services in the same scope • A service (including an LS) may register in multiple scopes

  50. Multi-LS Simple case in which LS instances register with one another

More Related