Wide-Area Service Composition: Performance, Availability and Scalability Bhaskaran Raman SAHARA, EECS, U.C.Berkeley Presentation at Ericsson, Jan 2002

Service Composition: Motivation Provider Q Texttospeech Provider R Cellular Phone repository Provider A Video-on-demand server Provider B Thin Client Provider A Provider B Replicated instances Transcoder Service-Level Path Other examples: ICEBERG, IETF OPES’00

In this work: Goals Performance: Choice of Service Instances Availability: Detecting and Handling Failures Scalability: Internet-scale operation

In this work: Assumptions and Non- goals Operational model: –Service providers deploy different services at various network locations –Next generation portals compose services –Code is NOT mobile (mutually untrusting service providers) We do not address service interface issue Assume that service instances have no persistent state –Not very restrictive [OPES’00]

Solution: Requirements Performance information collection Failure detection/liveness tracking Service location Global information is required –Hop-by-hop approach will not work Active monitoring Service 1 Alternate service 1 Service 2 Hop-by-hop approach

Challenges Scalability and Global information –Information about all service instances, and network paths in-between should be known Quick failure detection and recovery –Internet dynamics  intermittent congestion System evaluation –Simulation? –Real implementation?

Architecture Internet Service cluster: compute cluster capable of running services Peering: exchange perf. info. Destination Source Composed services Hardware platform Peering relations, Overlay network Service clusters Logical platform Application plane Overlay can grow slowly Amortization of overhead Hierarchical monitoring

Software Architecture Finding Overlay Entry/ExitLocation of Service Replicas Service-Level Path Creation, Maintenance, Recovery Link-State Propagation At-least -once UDP Perf. Meas. Liveness Detection Peer-Peer Layer Link-State Layer Service-Composition Layer Functionalities at the Cluster-Manager

Evaluation: Emulation Testbed Idea: Use real implementation, emulate the wide-area network behavior (NistNET) Opportunity: Millennium cluster App Lib Node 1 Node 2 Node 3 Node 4 Rule for 1  2 Rule for 1  3 Rule for 3  4 Rule for 4  3 Emulator

Evaluation: Recovery of Application Session Text-to-Audio application Two possible places of failure Setup: –20-node overlay network –No service instance replicas –Deterministic failure for 10sec during session Metric: gap between arrival of successive audio packets at the client Texttospeech Desktop Text Source Leg-2 Leg-1

Recovery of Application Session: CDF of gaps>100ms Recovery time: 822 ms Recovery time: 2963 ms = Detection: 1800 ms + Alternate path setup: 1163 ms Recovery time: 10,000 ms

Evaluation: Scaling Scaling bottleneck: –Simultaneous recovery of all client sessions on a failed overlay link Parameter: load on failed link = #paths to be recovered Metric: Time to recovery

Average Time-to-Recovery Total of 5000 paths in 20- node overlay network Two services in each path Two replicas per service Each data-point is a separate run Controlled link-failure

Evaluation: Scaling At a “load” of 695 paths on the failed edge –Average path recovery time: 575 ms –All paths recover within 1.5 sec Back calculation to determine the number of simultaneous clients a cluster manager can support –350 –Okay for heavy-weight services (text-to-speech)

Summary Service Composition: flexible service creation We address performance, availability, scalability Results so far: –Good recovery time for real-time applications: O(3 sec) –Good scalability: minimal additional provisioning for cluster managers Ongoing work: –Overlay topology issues: how many nodes –Stability issues –Trade-offs in recovery mechanisms Feedback, Questions? Presentation made using VMWare

References [OPES’00] A. Beck and et.al., “Example Services for Network Edge Proxies”, Internet Draft, draft-beck-opes-esfnep-01.txt, Nov 2000