1 / 42

Designing an OGSA Service for Replica Location

Designing an OGSA Service for Replica Location. Outline. Options for a Service-Oriented RLS design Overview of Service-Oriented RLS Background Data Services (DAIS) ServiceGroups (OGSI) Representing replicaSets as services Designing replicaSets as ServiceGroups

kenna
Download Presentation

Designing an OGSA Service for Replica Location

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. Designing an OGSA Service for Replica Location

  2. Outline • Options for a Service-Oriented RLS design • Overview of Service-Oriented RLS • Background • Data Services (DAIS) • ServiceGroups (OGSI) • Representing replicaSets as services • Designing replicaSets as ServiceGroups • Optional Indexes for replicaSets • Supporting Policy in replicaSets • Components of replicaSets • Factories, SDEs, Methods

  3. Replica Location Services • Register existence of replicas of data items • Replicas according to some semantic definition of replica, such as byte-to-byte copies, versions, etc. • Logical identifier or equivalence class associates replicated data items • Respond to queries about replicas • Return identifier or locators for individual replicas • May enforce policies about replicas • Authorization, maintaining semantic definitions, etc.

  4. The Existing Replica Location Service Replica Location Indexes RLI RLI LRC LRC LRC LRC LRC Local Replica Catalogs • LRCs contain consistent information about logical-to-physical mappings on a site or storage system • RLIs nodes aggregate information about LRCs

  5. Initial Thoughts on Moving Toward a Service-Oriented RLS • Grid Service Wrappers around existing RLS • LRC Target Names become GSHs • Use of general Grid Service indexing mechanisms • Name Space Management via a Logical Naming Authority • Representing Replica Sets as Services • ReplicaSets and/or Indexes Implemented as ServiceGroups

  6. Option 1: Grid Service Wrappers around existing RLS • Provide Grid service wrappers around existing Local Replica Catalog (LRC) and Replica Location Index (RLI) services • RLS mappings between logical and target names are independent of the GSHs that name dataset services • This option is reflected in the first version of the Local Replica Catalog specification • Advantage: Allows us to use OGSI-compliant mechanisms to access RLS components • Disadvantage: Does not allow us to take advantage of other OGSA machinery • Introspection on dataset service data • Subscription, index mechanisms, serviceGroups, etc.

  7. Treating Datasets as Services • Would apply to files, file systems, databases,… • Global names • Datasets are uniquely and globally names by Grid Service Handles (GSHs) • Standard mechanisms for data access, lifetime management, etc. • All properties of OGSI-compliant services • Implement Grid Service port type • Support introspection on service data elements • OGSI lifetime management

  8. Option 2: LRC Target Names Become GSHs • Store the GSHs of datasets in the target entries of LRC mappings • LRC mappings from logical names to the GSHs that point to replica datasets • Design of the RLI is unchanged • Advantage: Allows us to locate datasets that are represented as Grid services • Disadvantage: Does not allow us to use other OGSA machinery

  9. Option 3: Use of general Grid Service indexing mechanisms • Replace specialized LRC and RLI indexes with general OGSA index mechanisms • E.g., port types and SDEs being developed for use in OGSA information services and elsewhere • Information provider sends info to an index service • A dataset would provide information about itself to an indexing Grid service • Advantages: • Exploit commonalities with other OGSA components • Avoid developing separate index service • Requires acceptable performance from general index services

  10. Concerns Raised About the Original RLS Grid Service Specification • Access control • Insufficient control over who is allowed to create mappings • No validity guarantees for mappings • Namespace management • Uniqueness of names • Support for hierarchical namespaces

  11. Option 4: Name Space Management via a Logical Naming Authority • The logical name associated with a dataset would become a service data element (SDE) of that dataset • A Logical Naming Authority (LNA) would assert validity of mapping from a logical name to dataset • Sign the mapping • Any unsigned mapping is considered invalid • Registration of a new replica mapping requires: • A client requests a signed mapping from a LNA with whom the client has a trust relationship • Signed mapping is associated with dataset as SDE • Signed mapping is registered with an LRC

  12. Option 5: Representing Replica Setsas Services • The logical names registered in RLS catalogs can be thought of as defining equivalence sets of replicas • Can represent not only individual datasets but also sets of replicas as Grid services • Benefit from the OGSI mechanisms (global names, service data, lifetime management) • replicaSet services • The GSH for a replicaSet could then be used as the logical name for the replicated dataset

  13. Option 5 (continued) • Advantage: replicaSet service provides natural point for controlling the registration of new replicas in the equivalence class • Effectively serve as Logical Naming Authorities • Enforce policies for access control • Only allow clients with trust relationship to add new dataset services as members of the equivalence set • Advantage: replicaSet service can also enforce policies for replica coherence

  14. Option 5 (continued) • A client may directly inspect a replicaSet • Must respond to queries about its service data, including information about its members • Replica location functionality • No longer require the LRC and RLI services of the current RLS design from a functionality perspective • Providing such indexes may be useful for performance and reliability reasons • Aggregating information about replicaSet services can provide more efficient discovery of replica datasets

  15. Option 6: ReplicaSets and/or Indexes Implemented as ServiceGroups • Can implement replicaSet as a ServiceGroup • A Grid service that maintains information about a group of other Grid services • ServiceGroup entries consist of a locator and content information describing the member service • Advantage: Make use of ongoing development of Service Group port types • Including add and remove methods of the ServiceGroupRegistration port type • Can also implement LRC/RLI catalogs as ServiceGroups

  16. Overview of Replica Location Service Design • Data items are exposed as Grid services called data services • Data services are uniquely identified by Grid Service Handles (GSHs) • Replicated data services are effectively members of an equivalence class according to some semantic definition of equivalence • A replica set equivalence class should be exposed as a Grid service called a replicaSet service • The replicaSet service design should be based on and extend the OGSI ServiceGroup, which is a collection of Grid services

  17. Overview of Replica Location Service Design (Continued) • The replicaSet service should be have associated policies for authorization and semantics (what constitutes a member of the equivalence class) • The RLS design may include additional indexes for aggregating information about multiple replicaSet ServiceGroups • For availability and performance • These indexes should also be designed as extensions of ServiceGroups

  18. Background: Data Services • The OGSA Data Services Specification is being standardized through the DAIS Working Group • DAIS/OREP session Monday 2-5:30pm, DAIS session Monday 8-9:30pm • A data service is an OGSI Grid service that represents and encapsulates a data virtualization, which is an abstract view of some data • Service data elements (SDEs) describe key parameters of the data virtualization • Support one or more interfaces: • Inspect SDEs • Access the data • Derive new data virtualizations • Manage data virtualizations

  19. Relevant Aspects of Data Services for Replica Location Services OGSI service data elements (SDEs) are used to describe aspects of a data service’s data virtualization as well as metadata OGSI Grid Service Handles are used to globally and uniquely identify data services Data services inherit basic lifetime management capabilities from OGSI Grid Services Data services may be created dynamically using data factories

  20. Relevant Aspects of Data Services (Continued) • Data services implement one or more of the four base data interfaces: DataDescription, DataAccess, DataFactory and DataManagement • We are most concerned with DataDescription • Defines service data describing the data virtualization • Allows clients to inspect this service data • Access these SDEs using: • FindServiceData operations from the Grid service portType • Subscription/notification operations from the Notification portType

  21. Background: ServiceGroups • Defined in Open Grid Services Infrastructure (OGSI) Version 1.0 specification • ServiceGroups are Grid services that maintain information about a group of other Grid services • A ServiceGroup contains entries for member services • Entries are represented as Service Data Elements (SDEs) of the ServiceGroup • Each ServiceGroup entry SDE value is a triple with: • A memberServiceLocator • An optional serviceGroupEntryLocator for a service associated with an entry, used for managing entry • Content

  22. ServiceGroups (Continued) • Used to implement service registries • Also specialized indexes, such as for information services

  23. Outline • Overview of Service-Oriented RLS • Background • Data Services (DAIS) • ServiceGroups (OGSI) • Representing replicaSets as services • Designing replicaSets as ServiceGroups • Optional Indexes for replicaSets • Supporting Policy in replicaSets • Components of replicaSets • Factories, SDEs, Methods

  24. Representing ReplicaSets as Services • Replicated data items are defined by an equivalence class • Expose these equivalence sets as services • Thus define a replicaSet Gridservice as a virtualization of the set of replicas that make up an equivalence class • This equivalence class is globally and uniquely identified by a Grid Service Handle • Effectively, a replicaSet service provides a mapping from the locator (handle) of the equivalence set service to one or more locators for member data services

  25. Representing ReplicaSets as Services (Continued) • Represent information about data services that are members of the replicaSet service as service data elements (SDEs) of the replicaSet service • ReplicaSet service data may also include information about policies that the replicaSet service supports • A client may use standard inspection and subscription/notification methods to inspect a replicaSet service and obtain information about its members and policies

  26. Designing ReplicaSets as ServiceGroups • Maintain information about a group of other Grid services • Each entry in the ServiceGroup is a service data element SDE consisting of three values: • the locator of the serviceGroupEntry service used for management of the entry • the locator of the member data service • content associated with the entry • Extend the ServiceGroupRegistration port type’s add and remove methods

  27. DataServices and ReplicaSet Services • Maps from GSH of ReplicaSet Service to GSHs of member replica DataServices

  28. Optional Indexes for ReplicaSet Services • A client may directly inspect a replicaSet • Must respond to queries about its service data, including information about its members • Do not require separate Replica Location Service index services from a functionality perspective • Indexes may be useful for availability and performance reasons • Aggregate information about data services that make up one or more replicaSet services • Improve availability by answering queries about replicaSet members even if a particular replicaSet service is unavailable due to temporary failure • Improve performance by allowing bulk query operations on indexes

  29. Designing Indexes • These could also be implemented as ServiceGroups • ServiceGroupEntries would include: • locators to member replicaSet services • content fields that include data services in corresponding replicaSet equivalence class

  30. Replica Location Index Service

  31. Scenario for Creating a New Replica and Adding it to a ReplicaSet • Client A invokes data factory port type on an existing data service to create a new derived data service that is a replica of the original • Client A invokes the add operation on the replicaSet • The replicaSet enforces authorization, semantic and other policies • If allowed, the new data service is added to the replicaSet service • The replicaSet service may send information about its membership to one or more aggregating indexes

  32. Outline • Overview of Service-Oriented RLS • Background • Data Services (DAIS) • ServiceGroups (OGSI) • Representing replicaSets as services • Designing replicaSets as ServiceGroups • Optional Indexes for replicaSets • Supporting Policy in replicaSets • Components of replicaSets • Factories, SDEs, Methods

  33. Enforcing Policies in ReplicaSet Services • A replicaSet service may enforce policies about the equivalence set of replicas • Access control policies determine who is allowed to add or remove data services as members • Semantic policies specify the meaning of replication and which data services may be members of a replicaSet • Policies determine what attributes may be associated as service data elements • The extent to which the assertions about replica semantics are verified or enforced depend on the replicaSet service implementation • Policies enforced at time members are added • Policies maintained over time

  34. Possible Standard Semantic Policies for ReplicaSets • Byte-for-byte copy of data items, such as files • Data objects that contain the same information in different formats • Data objects that are equivalent to a specified degree • Data objects that are derived from a common parent • Versions of data objects • Replicas that have been synchronized within a specific time period • Partial replicas of data objects

  35. Specialized ReplicaSet Services • Can implement specialized replicaSet services for implementing higher-level behaviors • E.g., replicaSet services could maintain policy relationships among members of the equivalence class, such as byte-for-byte copies • Use subscription to be notified of any changes in the contents of member data services • Propagate these changes among replicas according to a particular coherency scheme • Alternatively: periodically introspect on the members of the replicaSet to check coherence and remove non-complying members

  36. Basic components of replicaSets • Factories • Service data elements (SDEs) • Methods/Port types

  37. replicaSet Factories • Used to create new equivalence classes for replicas • Extend the ServiceGroupFactory to support policy specification for authorization, replica semantics, etc. • Relates to the Factory port type of OGSI specification • Also to the Agreement Factory being specified through GRAAP Working Group of GGF • Policies may eventually be considered as part of the published agreement terms • SDEs specify assertions that instances created by the factory can support • There may be mechanisms associated with these assertions

  38. replicaSet Factory (continued) • Different factory services may support different assertions, extensions and mechanisms • Examples: • Byte for Byte Copy replicaSetFactory • Versioning replicaSetFactory • A call to a replicaSetFactory service to create a new replicaSet service instance would specify one of the advertised policies of the factory • The newly-created replicaSet service would include SDEs describing the policies that replicaSet supports

  39. replicaSet Service Data Elements • SDEs must describe the policies supported by the service, including authorization, replica semantics or other policies • In addition, the replicaSet contains SDEs that describe its members • optional locator of the ServiceGroupEntry management service • locator of the member service • content associated with the entry • Content in the SDE entries can be added at registration time or pulled later from the underlying data service • Open question: what content needs to be associated with replicaSet entries?

  40. replicaSet SDEs (continued) • Some content will come from the individual data services that are members of the ServiceGroup • These services have service data elements (SDEs) • Could represent complete or partial member data service SDEs • Or may summarize or aggregate data service SDEs in some manner for the replicaSet content field • We would need to provide additional mechanisms to summarize or aggregate SDEs from a member data service • Likely these would be useful for additional services besides ReplicaSets that use ServiceGroups. • We may find it useful to define a schema for the content entry in the replicaSet ServiceGroup.

  41. replicaSet Methods • Inherit from ServiceGroup (service data only), ServiceGroupEntry and ServiceGroupRegistration port types: • Publishes service group entries as service data elements • Add, delete entries • Use the addExtensibility features of the ServiceGroupRegistration add call to define the content to be added to the replicaSet service entry • SDEs of replicaSets can be accessed: • By query oeprations of the GridService port type such as FindServiceDataByName • Using the Notification portType to support subscription and notification

  42. Next Steps • More work on Factories and WS-Agreement • Specifying policies and enforcement guarantees as part of negotiated agreements • Content of replicaSet entries • What content from underlying data services should be stored in the replicaSet • Prototype of replicaSet service • Based on GT3 Index Service

More Related