1 / 9

Performance and Availability Constrained Composition of Services

This paper discusses an architecture for the composition of services across the wide-area internet, considering performance and availability constraints. It explores the challenges of composing services from different providers and proposes a solution using service clusters and a logical overlay network. The architecture allows for the exchange of information regarding service location, performance, and liveness across clusters. Topics such as failure detection, scalability, stability, and overlay network issues are also addressed.

zinaa
Download Presentation

Performance and Availability Constrained Composition of Services

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. Cellular Phone Video-on-demand server Provider A Provider R Text to speech Provider B Transcoder Email repository Thin Client Provider Q An Architecture for Performance and Availability Constrained Composition of Services across the Wide-Area Internet Bhaskaran Raman ICEBERG, EECS, U.C.Berkeley

  2. Video-on-demand server Provider A Provider A Provider B Transcoder Provider B Thin Client Problem Statement • Operational model: • Independent service providers deploy services at different locations on the Internet • Composition across the wide-area and across providers • Composed instances: service-level path • Challenges: • Performance constrained choice of service instances for composition • Wide-area replicas • Maintenance of composed service session • Alternate service-level paths

  3. Related Work • Service composition is complex: • Service discovery, Interface definitions, Semantics of composition • Previous efforts have addressed: • Semantics and interface definitions • COTS (Stanford), Future Computing Environments (G. Tech) • Fault tolerance composition within a single cluster • TACC (Berkeley) • Performance constrained choice of service, but not for composed services • SPAND (Berkeley), Harvest (Colorado), Tapestry/CAN (Berkeley), RON (MIT) • None address wide-area network performance or failure issues for long-lived composed sessions

  4. Source Internet Composed services Destination Application plane Peering: monitoring & cascading Service location Service-level path creation Peering relations, Overlay network Network performance Logical platform Detection Handling failures Service clusters Recovery Hardware platform Service cluster: compute cluster capable of running services Our Architecture

  5. Architecture: Advantages • Service clusters provide compute platform for deploying services • Compute cluster can be provided by third party provider • Logical overlay network provides context for service composition • Exchange information for service location, performance and liveness of wide-area paths • Hierarchical monitoring • Within cluster: for process/machine failures • Across clusters: for network problems • Aggregated monitoring • Monitoring overhead amortized across all compositions between two clusters

  6. Architecture: Issues • Failure detection • Wide-area network path: need to detect that something is wrong • Is this possible, given Internet dynamics and congestion? • Scalability of the overlay network • Information exchange grows as network size grows • Stability of information exchanged • For performance-sensitive choice of service instance • Stability when alternate service instances are chosen during failure • Overlay network issues: • How many nodes? Preliminary studies: 5% enough, could be less. • Where to place the nodes: edge versus core • Who to peer with: minimize sharing of physical paths

  7. UDP-based keep-alive across the wide-area • Graph shows distribution of number of gaps at the receiving end, for a periodic heart-beat • Main result: short outage in the network path often predicts a long outage (knee in the graph) • Can monitor network path; timeout of 1-2sec often useful in predicting long failures • Can take corrective action quickly Failure detection: UDP-based heart-beat study 85 gaps above 900ms False-positive rate: 6/11 5 11 6

  8. Ongoing study • Algorithms for exchange of performance and liveness information • Link state • Scaling and stability issues: study using simulations • Trade-offs in mechanism for failure recovery • Pre-construction vs on-demand patch-up • Service cluster placement and peering issues • Methodologies: • Analytical models for failure • Traces from real measurements • From other independent studies • Collaboration with TUBerlin, UNSW, others. • Emulation/simulation environment on the Millennium cluster • Hundreds of fast, well-connected, cluster machines • Use it to emulate wide-area network conditions

  9. Conclusions and Questions • Service composition gives a lot of flexibility and reuse in building end-to-end services • Performance and availability are important for composed services • Our architecture is based on an overlay of service clusters • Questions: • How complex can service composition be? How many services can be composed meaningfully for a single client session? • Distributed versus Centralized services • Much easier to buy good connectivity than to manage service instances at two different places • How dynamic is the composition? We have assumed relatively static composition: portal provider kind of operational model • What are some killer applications for service composition? • Video-on-demand, Other multimedia applications, Email over phone, Network games

More Related