1 / 27

Measurement-Based Server Selection within the Application-Layer Anycasting Architecture

Measurement-Based Server Selection within the Application-Layer Anycasting Architecture. Mostafa H. Ammar College of Computing Georgia Institute of Technology Atlanta, GA ammar@cc.gatech.edu. Contributors. Samrat Bhattacharjee Zongming Fei Ellen Zegura. Server Replication.

ziya
Download Presentation

Measurement-Based Server Selection within the Application-Layer Anycasting Architecture

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. Measurement-Based Server Selection within the Application-Layer Anycasting Architecture Mostafa H. Ammar College of Computing Georgia Institute of Technology Atlanta, GA ammar@cc.gatech.edu

  2. Contributors • Samrat Bhattacharjee • Zongming Fei • Ellen Zegura

  3. Server Replication • Improves service scalability • Server Selection Problem How does a client determine which of the replicated servers to access • Interested in Wide-Area Replication

  4. Server Selection Alternatives • Designated Server (e.g., nearest) • Round robin assignment (e.g., DNS rotator) • Explicit list with user selection • Server-cluster techniques (Netdispatcher, Local Director)

  5. Other Interesting Work • DSS -- BU • SPAND -- Berkeley • Mirror Characterization -- CMU • IDMaps -- UMich, UCLA et al ...

  6. Anycasting • Network-Layer Anycasting in RFC 1541 • Anycast IP addresses • Network-layer metrics • Per-packet selection

  7. Application-Layer Anycasting • Group of servers identified by Anycast Name • Clients request service from group identified by name • Automatic connection to a “good” server

  8. Server y Go to server y Green Service? Resolver Orange Server Group Green Server Group An Architecture

  9. Resolver • “Close” to client • Maintains • Anycast group membership • Selection-enabling information • Client may provide filter that tells resolver how to select • DNS-like hierarchy of resolvers

  10. Web Server Selection • An instantiation of architecture • Criterion: Best Response Time • [client request, last byte received] • includes path and server delays • Problem: Maintaining response time estimate for each server in anycast group at resolver

  11. Response Time Estimation Alternatives • Probe • Push • User-Experience

  12. Overview of Approach • Resolver probes for path-dependent response time (RT) • Server measures and pushes path-independent processing time (TUFR) • Lighter-weight push more frequent than heavier-weight probe • Probe result used to calibrate pushed value • Oscillation prevention measures

  13. SF = RT/TUFR RT & TUFR Resolver Probe for well-known representative “dummy” file maintained by server. TUFR written in file by server Orange Server Group Green Server Group Resolvers Probe for RT and Associated TUFR

  14. TUFR RT = SF x TUFR Resolver Orange Server Group Green Server Group Servers Push TUFR

  15. Resolver and Server Interaction Probes Resolver Probe Content Server Probe Updates Performance Updates Server Pushes Anycast Resolver Push Daemon Server Resolver

  16. Server Push Process • Typical server response cycle assign process to handle query parse query locate requested file repeat until file is written read from file write to network • Measure and smooth time until first read (TUFR) • Push if significant change

  17. Resolver Probe Process • Request dummy file from server • Measure response time

  18. Hybrid Push/Probe Technique • Resolver: request dummy file from server • Measure response time (RT) • Dummy file contains most recent TUFR • Each probe: compute scaling factor SF = RT/TUFR • Each Push: estimate response time RT = SF x TUFR

  19. Evaluation of Hybrid Technique Resolver: UMD, Server: GT Probe 1/50 accesses, Push max 1/4 sec

  20. Wide-Area Experiments WU 3 UMD 4 5 1 5 5 5 3 4 3 GT Servers: UCLA, GTx2, WU, Clients: UMDx4, GTx16, Resolvers: UMD, GT UCLA

  21. Anycasting VS Random Selection

  22. Summary of Experiments • 50% improvement using nearest server • Another 50% using Anycasting • More predictable Service

  23. What if Anycasting is popular?

  24. Avoiding Oscillations • Indicating “best” server when queried can result in oscillations • Use set of equivalent best servers • Hysteresis to join and leave set • Choose randomly among set

  25. Effect of Oscillation Prevention Technique Server Load Basic technique with oscillation prevention Basic Technique

  26. Worried about Scalability? • Me Too! • Multicast pushed data • Control frequency of push/probe -- CMU’s results are encouraging • Resolver can track “most promising” servers only • Limit number of Anycast Groups • Users pay premium for service

  27. Concluding Remarks • Appropriate guidance of clients to servers is an important infrastructure function • Client-perceived as well as global performance can be improved with the appropriate selection technology • Emerging services and network environment makes problem more challenging and more important

More Related