A Recovery-Friendly, Self-Managing Session State Store.ppt

A Recovery-Friendly, Self-Managing Session State Store Benjamin Ling and Armando Fox{bling,fox}@ Outline Motivation: What is Session State? Existing solutions SSM: Architecture and Algorithm SSM: Recovery-friendly SSM: Self-Managing Related and Future Work Conclusion Example of Session State Session State and Existing Solutions We focus on a subcategory of session state Single-user, serial access, semi-persistent data Examples: Temporary application data, application workflow Example of usage (e.g. J2EE): Existing solutions : File System and Databases Poor failure behavior Lose data (FS) Slow recovery (Both) Difficult to administer (DB) Difficult to tune (both) In-memory replication using primary/secondary: Performance coupling Poor failover (uneven load balancing) Goal Build a session state store that is: Failure-friendly Does not lose data on crash Degrades gracefully Recovery-friendly Recovers fast Self-Managing High performance Avoids performance coupling Session State Manager (SSM) Write example: “Write to Many, Wait for Few” Write example: “Write to Many, Wait for Few” Write example: “Write to Many, Wait for Few” Write example: “Write to Many, Wait for Few” Algorithm Properties Client remembers metadata Fate sharing Stubs are stateless Negative feedback loop SSM: Recovery-Friendly Failure No data is lost, WQ-1 copies of the data remain State is available for R/W during failure Recovery Start a new brick – don’t need to recover anything No special case recovery code (restart=recovery) State is available for R/W during brick restart Repair phase does not reduce throughput/performance Session state is self-recovering User’s access pattern will cause data to be rewritten SSM: Self-Managing Adaptive: Stub maintains count of maximum allowable in-flight requests to each brick Additive increase on successful request Multiplicative decrease on timeout Stubs discover load capacity of each brick ? Self-Tuning Admission control Stubs say “no” if insufficien