Clusterbased Scalable Network Services

1
Cluster-based Scalable Network Services

• Fox et al.
• 16th SOSP (1997)

2
General Comments

• Really an experiential or reporting paper
• Recall the context 1997
• Dialup broadband
• Internet boom
• Dell
• Reverse-architecture from HotBot

3
COW preferable to Big Iron?

• Scalability
• Grain size of network apps more appropriate to
  COW - Remember the problem domain!
  
• Replace capacity planning with reactionary
  incremental scaling
  
• Availability
• Single HW failure not fatal
• Cost effectiveness
• Commodity building blocks make expansion
  easy/efficient
  

4
Challenges for COW

• Administration
• Frequently biggest headache, but they dont
  really address it
  
• Matching SW scaling to HW scaling
• HW unit of scaling is a PC component-ize SW to
  match
  
• Partial failures?
• Shared state?

5
ACID semantics

• ACID database model
• Atomicity all or nothing
• Consistency only valid data written to
  database, only consistent database states
  allowed
  
• Isolation (serialization) simultaneous
  transactions dont affect one another
  
• Durability no transaction is ever lost -
  database is always consistent
  
• Preferable for services to be unavailable rather
  than to perform inconsistently
  
• Claim ACID is overkill for network applications

6
BASE semantics

• Basically available, soft state, eventual
  consistency
  
• Service is always available although data may be
  inexact
  
• Regenerate instead of store data
• Focus on performance approximate/quick data vs.
  exact/slow
  
• Trades consistency for simplicity of
  implementation
  
• They target applications that deal with BASE
  data
  

7
Scalable Network Services
Graphical Monitor
WAN

Manager
System Area Network
User Profile DB


Worker API
8
SNS layering

• 3 layers
• SNS implementation
• TACC Transformation, aggregation, caching,
  customization
  
• Service-specific (user interface, device-specific
  presentation)

9
SNS Layer

• Scalability through replication
• Workload (grain size) makes this approach
  feasible
  
• Component-based code, simple workers
• Resource needs scale linearly with load
• Centralized load balancing w/overload pool
• Fault-tolerance via process peers
• Stub code simplifies workers

10
TACC programming model

• Transformation changing data content
  (filtering, encryption, compression)
  
• Aggregation collecting/collating data
• Customization user preferences (again, recall
  the context)
  
• Caching storing data cheaper than moving it
• Claims
• Many interesting services can be implemented
  entirely at TACC layer
  
• Of those, few will need SNS-level mods

11
TranSend

• Web distillation proxy deployed at Berkeley
• HTTP front ends
• Workers are distillers (JPEG filters)
• Exploits user preferences and cached data

12
Load balancing in TranSend

• All components subscribe to manager via IP
  multicast beacon
  
• Manager matches requests with available/appropriat
  e workers
  
• Worker stubs report load information to manager
• Manager computes new load-balances, beacons them
  to manager stubs at front-ends
  
• Mgr. stubs cache load info in case manager dies

13
Fault-tolerance in TranSend

• All components register with manager
• Manager detects broken connections, uses
  timeouts
  
• All soft state is beaconed
• All processes have peers which restart them if
  necessary (in manager stub code)

14
Workers in TranSend

• Two groups of worker processes
• Cache workers process requests from an object
  cache
  
• Distillers perform scaling and filtering on JPEG
  images, add user-specified markup

15
Exploiting BASE

• Cached (stale) data avoids communications with a
  dead source
  
• Soft state can be regenerated, therefore no need
  for transactional commit
  
• Approximate answers (no distillation or cached
  data) can be used when system is heavily loaded
  or workers unavailable
  
• Approximate/quick vs. exact/slow

16
Experimentation

• 20-million-request HTTP trace used
• Size distribution of image requests drives 1KB
  distillation cutoff
  
• Characterized request capacity per worker
• Worker performance scales roughly linearly with
  input size
  
• Load balancing
• Need to balance H (load avg at which new worker
  is spawned) and D (new worker uptake interval)
  
• Soft state was originally too soft

17
Scalability

• Start with minimal system
• Increase load until some component saturates
• Add resources
• Lather, rinse, repeat
• Results
• System grown nearly linear
• Scaling limited by incoming bandwidth, not SAN
• As SAN saturates, multicast (unreliable) traffic
  is dropped and load balancing scheme fails

18
Take-home ideas

• A good example of growing a framework from an
  existing implementation (HotBot)
  
• Hitting the sweet spot SW component size, HW
  scalability increment, work request size all
  match
  
• Providing useful services where BASE model holds
• Detailed characterization of system behavior
• Always helps to have a real workload trace