Measurement-Based Server Selection within the Application-Layer Anycasting Architecture Mostafa H....

Post on 21-Dec-2015

218 views 1 download

Tags:

Transcript of Measurement-Based Server Selection within the Application-Layer Anycasting Architecture Mostafa H....

Measurement-Based Server Selection within the Application-Layer

Anycasting Architecture

Mostafa H. AmmarCollege of Computing

Georgia Institute of TechnologyAtlanta, GA

ammar@cc.gatech.edu

Contributors

Samrat BhattacharjeeZongming FeiEllen Zegura

Server Replication

Improves service scalability

Server Selection ProblemHow does a client determine which

of the replicated servers to access

Interested in Wide-Area Replication

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)

Other Interesting Work

DSS -- BUSPAND -- BerkeleyMirror Characterization -- CMUIDMaps -- UMich, UCLA et al ...

Anycasting

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

Application-Layer Anycasting

Group of servers identified by Anycast Name

Clients request service from group identified by name

Automatic connection to a “good” server

An Architecture

Resolver

Orange Server Group

Green Server Group

Green Service?

Go to server y

Server y

Resolver

“Close” to clientMaintains

Anycast group membership Selection-enabling information

Client may provide filter that tells resolver how to select

DNS-like hierarchy of resolvers

Web Server Selection

An instantiation of architectureCriterion: 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

Response Time Estimation Alternatives

ProbePushUser-Experience

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 valueOscillation prevention measures

Resolvers Probe for RT and Associated TUFR

Resolver

Orange Server Group

Green Server Group

SF = RT/TUFR

RT &TUFR

Probe for well-known representative “dummy”file maintained by server.

TUFR written in file by server

Servers Push TUFR

Resolver

Orange Server Group

Green Server Group

RT =SF x TUFR

TUFR

Resolver and Server Interaction

Content Server

Push Daemon

Resolver Probe

Anycast Resolver

Server Resolver

PerformanceUpdates

Probes

ServerPushes

ProbeUpdates

Server Push Process

Typical server response cycleassign process to handle queryparse querylocate requested filerepeat until file is written read from file write to network

Measure and smooth time until first read (TUFR)

Push if significant change

Resolver Probe Process

Request dummy file from server

Measure response time

Hybrid Push/Probe Technique

Resolver: request dummy file from serverMeasure response time (RT)Dummy file contains most recent TUFREach probe: compute scaling factor SF = RT/TUFREach Push: estimate response time

RT = SF x TUFR

Evaluation of Hybrid Technique

Resolver: UMD, Server: GT Probe 1/50 accesses, Push max 1/4 sec

Wide-Area Experiments

4

3

5

3

4

51

5

5

3

UCLA

WU

UMD

GT

Servers: UCLA, GTx2, WU,Clients: UMDx4, GTx16,Resolvers: UMD, GT

Anycasting VS Random Selection

Summary of Experiments

50% improvement using nearest serverAnother 50% using AnycastingMore predictable Service

Algorithm Ave. Resp.Time (Sec).

StandardDev. (Sec.)

Random 2.13 6.96Nearest 1.12 2.47Anycasting 0.49 0.69

What if Anycasting is popular?

Avoiding Oscillations

Indicating “best” server when queried can result in oscillations

Use set of equivalent best serversHysteresis to join and leave setChoose randomly among set

Effect of Oscillation Prevention Technique

Server Load

Basic Technique Basic technique withoscillation prevention

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

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