1 / 28

Dependability QoS

Anh Nguyen. Dependability QoS. Outline. The emergence of continuous consistency model (CCM) Conit-based CCM What is it? Policies Examples Discussion Break… The composability of consistency conditions Discussion Summary. My presentation is successful if you ….

drema
Download Presentation

Dependability QoS

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. Anh Nguyen DependabilityQoS

  2. Outline • The emergenceofcontinuousconsistencymodel (CCM) • Conit-based CCM • What is it? • Policies • Examples • Discussion Break… • The composabilityofconsistencyconditions • Discussion • Summary

  3. My presentation is successfulifyou … • Understand theideasof CCM, and Conit-based CCM • Examples • Identifyconits, parameters • Understand the general meaningoftheframeworkofthecomposabilityofconsistencyconditions • What is it? • What is it for? • Basic consistencyconditions

  4. The emergence of CCM • The availability of services • The exponential increase in access to Web services • Network failures • 0.1% improvement in availability ≈ 8 hours of additional uptime/year ≈ $1 million in additional revenue • Replication is a key approach

  5. The emergence of CCM • Despite being a really promising solution to improve the availabality of services, it also brings about many new issues • Inconsistency among replicas • Ex: distributed database

  6. The emergence of CCM Well-known tradeoffs between consistency and availability

  7. The emergenceof CCM • Designers have beenforced to choose from eitherconsistencyguarantees (strictconsistencymodels) or none at all (optimisticconsistencymodels) • Differentapplications have differentrequirementsaboutconsistency (thelevelofconsistency) • BulletinboardvsAirlinereservation system • An applicationmayneeddifferentlevelsofconsistency during itsruntime or under certaincircumstances • A dynamic web pagetrackingthe score of a football game → Continuousconsistencymodels: enable services to describe and to specifydifferentlevelsofconsistency in betweentraditionalstrong and optimisticconsistency

  8. Conit-based CCM • HaifengYu and Amin Vahdatintroducedtheconceptof a conit (consistencyunit) • The conit-based CCM • allows a broad range ofreplicated services to conveniently and quantitativelyexpresstheirconsistencyrequirements • applicable to a wide range ofapplications (generality) • able to efficientlyenforce target consistencylevels (practicality)

  9. Conit-based CCM • A conit is a logicalconsistencyunit • The spaceofconsistency is parameterized by thefollowingmetrics • Numerialerror: the total weightofwriteson a conit not seen by a replica • Order error: thenumberofwritesthat have not establishedtheircommit order at anyonereplica • Staleness: a real-timeboundonthedelayofwritepropagationamongreplicas

  10. Conit-based CCM • An example: a replicatedbulletinboard service whereusersmaypost/retrievenewsmessages to/from anyreplica • Conit: numberof all newsmessages • Numerialerror: the total numberofmessagespostedsystem-widebut not seenlocally • Order error: thenumberofoutof order messageson a given replica (messagesseenlocallybut not committed) • Staleness: thedelayofmessages

  11. Conit-based CCM • An exercise • Airline Reservation System • A replicated e-commerce service that accepts inquiries and purchase orders on a catalog • Each server maintains a full replica of the flight information database and accepts user reservatinos and inquiries about seat availability • Conit • represents for the number of available seats • At a state of the system • Committed value of the number of available seats: 300 • At a replica: • the number of available seats is 350 • The number of seats currently booked by users (not committed yet): 100 • Numerial error: • Order error: • Staleness 50 100

  12. Conit-based CCM

  13. Conit-based CCM • The continuityofconit-based CCM • (numericalerror, order error, staleness) • Strictconsistencymodels: (0,0,0) • Optimisticconsistencymodels: (∞, ∞, ∞) • Real values for the parameters achievethecontinuity • The levelof service consistency is adjustedflexibly by changing (numericalerror, order error, staleness) • Eachreplicacan have itsown independent consistencylevel for a conit. This allowsthe system to routeclientrequests to replicaswithappropriateconsistencyboundson a per-request basis • In theairlinereservation system, requests from ”preferred” clientsmay be directed to a replicathatmaintainshigherconsistencylevels (reducingtheprobabilityof an inconsistentaccess)

  14. Conit-based CCM • AffectConit(): how each write affects the return value of a conit F. The system • can then infer the return value of F by summing all accumulated numerical weights • DependonConit(): declare the required consistency level on each access

  15. Conit-based CCM • Continuousconsistencyprogramming • Crystallisehigh-levelapplicationconsistencysemantics. ”whatdoes 90% consistencymean?” • Conit, numericalerror, order error, staleness • AffectConit() • DependonConit() • TACT: A middlewarelayer

  16. Discussion • Canconit-based CCM modeltheconsistencyof all (most) services? • Difficulties • The numberofconitschangesrapidly? • Adaptability • HaifengYu, Amin Vahdat, ”The Costs and Limits ofAvailability for Replicated Services”, ACM Trans. Comput. Syst. 24(1): 70-113 (2006)

  17. Break…

  18. The composabilityofconsistencyconditions • DependonConit(): declaretherequiredconsistencyleveloneachaccess • Anotherapproach to expressdifferentlevelsofconsistency • Definesbasicconsistencyconditions • A formal frameworkthatenablescomposing a collectionofconsistencyconditionsinto a more restrictiveone • Provesthat a given implementationof a highlevelcondition is correct • Can be used to devise flexible, composableimplementationofconsistencyconditions

  19. The composabilityofconsistencyconditions • Definitions and conventions • Clientprocesses: p1, p2, …, pn • An operation: op (read, write) • An invocationevent: inv(op) • A correspondingresponseevent: resp(op) • A history (H): a sequenceofinvocation and responseevents • A sequentialhistory: eachinvocationevent is immediatelyfollowed by the matching responseevent • A serialization (S) of a history H: a sequentialhistorycontaining all theoperationsof H • A sequentialhistory H to be legalifthevaluereturned by eachreadoperation r in H is the same as thevaluewritten by the last writeoperationthataccessesthe same objectbefore r in H

  20. The composabilityofconsistencyconditions • Composabilityframework • Consistencycondition (consistency): a setofrestrictionsonallowed histories (levelofconsistency) • Eventual Propagation: everywriteoperation by anyprocess must be seen by all otherprocesses • Strongconsistencyconditions • requiretheexistenceofsomespecial legal serializationofthehistory • All processesviewtheoperations in the same logical order • Weakerconditions • onlyrequiretheexistenceofonespecialserialization for eachprocess • Eachprocessviewstheoperations in a differentlogical order • A history preserves a consistencycondition by requiringtheexistenceof a serializationsetthatobeyscertainorderingrestrictions

  21. The composabilityofconsistencyconditions • Basic consistencyconditions • ReadYourWrites(for a localhistory) • for everytwooperationswrite and read in thelocalhistory • Ifwriteprecedesread, thereturnvalueofread is thevalueupdated by write • FIFO ofReads(for a localhistory) • for everytwooperationread1 and read2 in thelocalhistory • Ifread1precedesread2, thereturnvalueofread2 is ”newer” or equal to thereturnvalueread1

  22. The composabilityofconsistencyconditions • Basic consistencyconditions • FIFO ofWrites(for a localhistory) • For everytwooperationswrite1 and write2 in thelocalhistory • Ifwrite1precedeswrite2, theobject is updated by write1 and thenwrite2 • ReadsBeforeWrites(for a localhistory) • For everytwooperationsread and write in thelocalhistory • Ifreadprecedeswrite, thereturnvalueofread is thevalue not updated by write

  23. The composabilityofconsistencyconditions • Basic consistency conditions • Local Causality (for a local history) • For every three operations write1, read, and write2 in which read and write2 are in the local history (write1 is not) • If the return value of read is a result written by write1 and read precedes write2, the object is updated by write1 and then write2 • Total order

  24. The composabilityofconsistencyconditions • An exampleofusefulcompositions • Anyhistorythat is consistentwithrespect to Total Order and ReadsBeforeWritesis alsoconsistentwithrespect to LocalCausality • An application • Thereareseveral simple clients and a few supervisor clients. Each simple clientreads and writes to differentobjectsthantheother simple clients. Supervisors canread all objects • Simple clients: FIFO ofWritesand ReadYourWrites • Supervisors: FIFO ofReads

  25. The composabilityofconsistencyconditions • In an deal system • Each basic condition will be implemented as a layer of code • When a given application needs a specific high-level consistency condition, it could simply pick the layers that implement the collection of basic conditions from which the high-level condition is composed of

  26. Discussion • Difficulties? • Implementation compositions of conditions • In compile time? • On-the-fly? • Does a complete set of basic consistency conditions to generate any consistency condition exist?

  27. Summary • Conit-based CCM • The composability of consistency conditions • Adaptability and Dependability

  28. References • Section 7.5.1 in TvS • "Design and Evaluation of a Conit-based Continuous Consistency Model for Replicated Services." ACM Transactions on Computer Systems, by Yu and Vahdat • "On the composability of consistency conditions“ InformationProcessing Letters by Friedman, vitenberg, and Chockler • ”The Costs and Limits ofAvailability for Replicated Services”, ACM Trans. Comput. Syst. 24(1): 70-113 (2006), by HaifengYu, Amin Vahdat

More Related