slide1 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Topics PowerPoint Presentation
Download Presentation
Topics

Loading in 2 Seconds...

play fullscreen
1 / 47

Topics - PowerPoint PPT Presentation


  • 134 Views
  • Uploaded on

Topics. ACID vs BASE. Starfish Availability. TACC Model. Transend Measurements. SNS Architecture. Extensible Cluster Based Network Services. Armando Fox Steven Gribble Yatin Chawathe Eric Brewer Paul Gauthier. University of California Berkeley. Inktomi Corporation.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Topics


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

Topics

ACID vs BASE

Starfish Availability

TACC Model

Transend Measurements

SNS Architecture

slide2

Extensible Cluster Based Network Services

Armando Fox

Steven Gribble

Yatin Chawathe

Eric Brewer

Paul Gauthier

University of CaliforniaBerkeley

Inktomi Corporation

Presenter: Ashish Gupta

Advanced Operating Systems

slide3

Motivation

  • Proliferation of network-based services
  • Two critical issues must be addressed by Internet services:
    • System scalability
      • Incremental and linear scalability
    • Availability and fault tolerance
      • 24x7 operation

Clusters of workstations meet these requirements

slide4

Commodity PCs as unit of scaling

Good Cost/performance

Incremental Scalability

“Embarrassingly parallel” workloads

Map well onto workstations

Redundancy of clusters

Masks transient failures

contribution of this work
Contribution of this work

Isolate common requirements of cluster-based Internet apps into a reusable substrate

the Scalable Network Services (SNS) framework

Goal: complete separation of *ility concerns from application logic

  • Legacy code encapsulation
  • Insulate programmers from nasty engineering
contribution of this work6
Contribution of this work
  • Architecture for SNS, exploiting the strength of cluster computing
  • Separation of content of network services from implementation
    • Encapsulation of low level functions in a lower layer
    • Example of a new service
  • A Programming Model to go with the architecture
the sns architecture

W

W

W

A

Interconnect

W

W

W

T

The SNS architecture

Workers and Front-ends

All control decisions for satisfying user requests localized in the front-ends:

Which Servers to invoke, access profile database, notify the end-user etc.

Workers simple and stateless

  • Behaviour of service defined entirely at the front-end
  • Analogy of processes in a Unix pipeline: ls –l | grep .pl | wc

User ProfileDatabase

Caches

Front Ends

C

FE

$

$

$

FE

Workers

FE

GUI

LB/FT

Manager:

Load Balancing & Fault Tolerance

AdministrationInterface

the sns architecture8

W

W

W

A

Interconnect

W

W

W

T

The SNS architecture

Front-ends

User Interface to SNS

Queue requests for service

Can Maintain State for many simultaneous outstanding requests

User ProfileDatabase

Caches

Front Ends

C

FE

$

$

$

FE

Workers

FE

GUI

LB/FT

Manager:

Load Balancing & Fault Tolerance

AdministrationInterface

the sns architecture9

W

W

W

A

Interconnect

W

W

W

T

The SNS architecture

User Profile

Allows Mass customization of request processing

User ProfileDatabase

Caches

Front Ends

C

FE

$

$

$

FE

Workers

FE

GUI

LB/FT

Manager:

Load Balancing & Fault Tolerance

AdministrationInterface

the sns architecture10

W

W

W

A

Interconnect

W

W

W

T

The SNS architecture

Workers

Caches, Service specific Modules

Multiple Instantiation possible

Themselves just perform a specific task, not responsible for load balancing, fault tolerance

User ProfileDatabase

Caches

Front Ends

C

FE

$

$

$

FE

Workers

FE

GUI

LB/FT

Manager:

Load Balancing & Fault Tolerance

AdministrationInterface

the sns architecture11

W

W

W

A

Interconnect

W

W

W

T

The SNS architecture

Administrative Interface

Tracking and Visualization of system’s behaviour

Administrative actions

User ProfileDatabase

Caches

Front Ends

C

FE

$

$

$

FE

Workers

FE

GUI

LB/FT

Manager:

Load Balancing & Fault Tolerance

AdministrationInterface

the sns architecture12

W

W

W

A

Interconnect

W

W

W

T

The SNS architecture

Manager

Collects load information from the workers

Balances load across workers

Spawn additional workers on increased load, faults

User ProfileDatabase

Caches

Front Ends

C

FE

$

$

$

FE

Workers

FE

GUI

LB/FT

Manager:

Load Balancing & Fault Tolerance

AdministrationInterface

the sns architecture13

W

W

W

A

Interconnect

W

W

W

T

The SNS architecture

Workers and Front-ends

All control decisions for satisfying user requests localized in the front-ends:

Which Servers to invoke, access profile database, notify the end-user etc.

Workers simple and stateless

  • Behaviour of service defined entirely at the front-end
  • Analogy of processes in a Unix pipeline: ls –l | grep .pl | wc

User ProfileDatabase

Caches

Front Ends

C

FE

$

$

$

FE

Workers

FE

GUI

LB/FT

Manager:

Load Balancing & Fault Tolerance

AdministrationInterface

separating the content from implementation

Service

Service Specific Code

TACC

Transformation, Aggregation, Caching, Customization

SNS

Scalable Network Service Support

Separating the content from implementation

Layered Software model

Previous Components

SNS

Provides Scalability

Load Balancing

Fault tolerance

High Availability

the sns layer
The SNS Layer
  • Scalability
    • Replicate well-encapsulated components
    • Prolonged Bursts: Notion of Overflow Pool
  • Load Balancing
    • Centralized: Simple to implement and predicable
the sns layer16
The SNS Layer
  • Soft State for fault-tolerance and availability
    • Process peers watch each other
    • Because of no hard state, “recovery” == “restart”
  • Load balancing, hot updates, migration are “easy”
    • Shoot down a worker, and it will recover
    • Upgrade == install new software, shoot down old
    • Mostly graceful degradation
starfish availability lb death

W

W

W

A

Interconnect

W

W

W

T

“Starfish” Availability: LB Death

FE detects via broken pipe/timeout, restarts LB

C

FE

$

$

$

FE

FE

LB/FT

starfish availability lb death18

W

W

W

A

Interconnect

W

W

W

T

LB/FT

“Starfish” Availability: LB Death

New LB announces itself (multicast), contacted by workers, gradually rebuilds load tables

FE detects via broken pipe/timeout, restarts LB

If partition heals, extra LB’s commit suicide

FE’s operate using cached LB info during failure

C

FE

$

$

$

FE

FE

LB/FT

slide20

The TACC Model

a model for structuring services

Transformation

Aggregation

Caching

Customization

Operation on a single data object that changes its content

Collecting data from several sources and collating it

Storing/re-computing easier than moving across internet

Can also store post-transformation (or post-aggregation) content

Per user: for content generation

Per device: data delivery, content “packaging”

C

T

Question: How do we build the services in the higher layers?

slide21

The TACC Model

a model for structuring services

Programming model based on composable building blocks

Many existing services fit well within the TACC model

a meta search engine in tacc
A Meta-Search Engine In TACC
  • Uses existing services to create a new service
  • 2.5 hours to write using TACC franework

Internet

Metasearch

Web UI

datatype specific distillation
Datatype-Specific Distillation
  • Lossy compression that preserves semantic content
  • Tailor content for each client
  • Reduce end-to-end latency when link is slow
  • Meaningful presentation for range of clients

6.8x

65x

1.2 The Remote Queue Model

We introduce Remote Queues (RQ), ….

transend sns components
TranSend SNS Components
  • Workers = Distillers here
  • Simple restart mechanism for fault-tolerance
  • Each distiller took 5-6 hrs to write
  • SNS Fault tolerance removes worries about occasional bugs/crashes
measurements
Measurements
  • Request Generation:
    • High performance HTTP request playback engine
  • Burstiness
    • Handled by the overflow pool
slide27

Load Balancing

Metric: Queue Length at distillers

Load reaches threshold:

Manager spawns a new distiller

slide28

Scalability

Strategy:

Begin with minimal instance

Increase offered load until saturation

Add more resources to eliminate saturation

Observations:

Nearly perfect linear growth

1 Distiller ~ 23 requests/sec

Front end ~ 70 requests/sec

Ultimate bottleneck:

Shared components of the system (Manager and the SAN)

SAN could be bottleneck for communication-intensive workloads (Example of 10Mb/s eth)

Topic for future research

conclusion
Conclusion
  • A layered architecture for cluster-based scalable network services
  • Authors shielded from software complexity of automatic scaling, high availability, and failure management
  • New services as composition of stateless workers

A useful paradigm for deploying new Internet services

slide30

ACID vs BASE semantics

An approximate answer delivered quickly is more useful than the exact answer slowly

slide31

ACID vs BASE semantics

An approximate answer delivered quickly is more useful than the exact answer slowly

Search Engine as a database

  • 1 Big table
    • Unknown but large growth
    • Must be truly highly available
slide32

A DBMS would be too slow

Choose availability over consistency

Graceful degradation: OK to temporarily lose small random subsets of data due to faults

Atomicity

BASE

Basically Available

Soft-State

Eventual Consistency

Replace with

Availablity

Graceful degradation

Performance

Consistency

Isolation

Durability

Database research is about ACID

why base
Why BASE ?

Idea: focus on looser semantics rather than ACID semantics

  • ACID => data unavailable rather than available but inconsistent
  • BASE => data available, but could be stale, inconsistent or approximate
  • Real systems use BOTH semantics
  • Claim: BASE can lead to simpler systems and better performance
    • Performance: caching and avoidance of communication and some locks (e.g. ACID requires strict locking and communication with replicas for every write and any reads without locks)
    • Simpler: soft-state leads to easy recovery and interchangable components
  • BASE fits clusters well due to partial failure
more base
More BASE…
  • Reduces complexity of service implementation , consistency for simplicity
    • Fault Tolerance
    • Availability
  • Opportunities for better performance optimizations in the SNS framework
    • ACID : durable and consistent state across partial failures
      • This Is relaxed in the BASE model
  • Example of HotBot
question
Question
  • Why are the cluster-based network service well suited to internet service
answer
answer
  • The requirements are highly parallel( many indepent simultaneous users)
  • The grain size typically corresponds to at most a few CPU seconds on a commodity PC
question 2
Question 2
  • Why does the cluster-base network service use BASE semantics?
answer40
Answer:
  • BASE semantics allow us to handle partial failure in clusters with less complexity and cost.
question 3
Question 3
  • When the overflow machines are being recruited unusually often, what should be done at this time?
answer42
Answer:
  • It is time to add new machines.
question 4
Question 4
  • Does the Front-end crash not lost any information? If does, what kind information will be lost?
answer44
Answer:
  • User requests will be lost and user need to handle timeout and resend request.
clustering and internet workloads
Clustering and Internet Workloads
  • Internet vs. “traditional” workloads
    • e.g. Database workloads (TPC benchmarks)
    • e.g. traditional scientific codes (matrix multiply, simulated annealing and related simulations, etc.)
  • Some characteristic differences
    • Read mostly
    • Quality of service (best-effort vs. guarantees)
    • Task granularity
  • “Embarrasingly parallel”…why?
    • HTTP is stateless with short-lived requests
    • Web’s architecture has already forced app designers to work around this! (not obvious in 1990)
meeting the cluster challenges
Meeting the Cluster Challenges
  • Software & programming models
  • Partial failure and application semantics
  • System administration
  • Two case studies to contrast programming models
    • GLUnix goal: support “all” traditional Unix apps, providing a single system image
    • SNS/TACC goal: simple programming model for Internet services (caching, transformation, etc.), with good robustness and easy administration