Random Notes
  • Introduction
  • Reading list
  • Theory
    • Index
      • Impossibility of Distributed Consensus with One Faulty Process
      • Time, Clocks, and the Ordering of Events in a Distributed System
      • Using Reasoning About Knowledge to analyze Distributed Systems
      • CAP Twelve Years Later: How the “Rules” Have Changed
      • A Note on Distributed Computing
  • Operating System
    • Index
  • Storage
    • Index
      • Tachyon: Reliable, Memory Speed Storage for Cluster Computing Frameworks
      • Exploiting Commutativity For Practical Fast Replication
      • Don’t Settle for Eventual: Scalable Causal Consistency for Wide-Area Storage with COPS
      • Building Consistent Transactions with Inconsistent Replication
      • Managing Update Conflicts in Bayou, a Weakly Connected Replicated Storage System
      • Spanner: Google's Globally-Distributed Database
      • Bigtable: A Distributed Storage System for Structured Data
      • The Google File System
      • Dynamo: Amazon’s Highly Available Key-value Store
      • Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications
      • Replicated Data Consistency Explained Through Baseball
      • Session Guarantees for Weakly Consistent Replicated Data
      • Flat Datacenter Storage
      • Small Cache, Big Effect: Provable Load Balancing forRandomly Partitioned Cluster Services
      • DistCache: provable load balancing for large-scale storage systems with distributed caching
      • Short Summaries
  • Coordination
    • Index
      • Logical Physical Clocks and Consistent Snapshots in Globally Distributed Databases
      • Paxos made simple
      • ZooKeeper: Wait-free coordination for Internet-scale systems
      • Just Say NO to Paxos Overhead: Replacing Consensus with Network Ordering
      • Keeping CALM: When Distributed Consistency is Easy
      • In Search of an Understandable Consensus Algorithm
      • A comprehensive study of Convergent and Commutative Replicated Data Types
  • Fault Tolerance
    • Index
      • The Mystery Machine: End-to-end Performance Analysis of Large-scale Internet Services
      • Gray Failure: The Achilles’ Heel of Cloud-Scale Systems
      • Capturing and Enhancing In Situ System Observability for Failure Detection
      • Check before You Change: Preventing Correlated Failures in Service Updates
      • Efficient Scalable Thread-Safety-Violation Detection
      • REPT: Reverse Debugging of Failures in Deployed Software
      • Redundancy Does Not Imply Fault Tolerance
      • Fixed It For You:Protocol Repair Using Lineage Graphs
      • The Good, the Bad, and the Differences: Better Network Diagnostics with Differential Provenance
      • Lineage-driven Fault Injection
      • Short Summaries
  • Cloud Computing
    • Index
      • Improving MapReduce Performance in Heterogeneous Environments
      • CLARINET: WAN-Aware Optimization for Analytics Queries
      • MapReduce: Simplified Data Processing on Large Clusters
      • Dryad: Distributed Data-Parallel Programs from Sequential Building Blocks
      • Resource Management
      • Apache Hadoop YARN: Yet Another Resource Negotiator
      • Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center
      • Dominant Resource Fairness: Fair Allocation of Multiple Resource Types
      • Large-scale cluster management at Google with Borg
      • MapReduce Online
      • Delay Scheduling: A Simple Technique for Achieving Locality and Fairness in Cluster Scheduling
      • Reining in the Outliers in Map-Reduce Clusters using Mantri
      • Effective Straggler Mitigation: Attack of the Clones
      • Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing
      • Discretized Streams: Fault-Tolerant Streaming Computation at Scale
      • Sparrow: Distributed, Low Latency Scheduling
      • Making Sense of Performance in Data Analytics Framework
      • Monotasks: Architecting for Performance Clarity in Data Analytics Frameworks
      • Drizzle: Fast and Adaptable Stream Processing at Scale
      • Naiad: A Timely Dataflow System
      • The Dataflow Model:A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale
      • Interruptible Tasks:Treating Memory Pressure AsInterrupts for Highly Scalable Data-Parallel Program
      • PACMan: Coordinated Memory Caching for Parallel Jobs
      • Multi-Resource Packing for Cluster Schedulers
      • Other interesting papers
  • Systems for ML
    • Index
      • A Berkeley View of Systems Challenges for AI
      • Tiresias: A GPU Cluster Managerfor Distributed Deep Learning
      • Gandiva: Introspective Cluster Scheduling for Deep Learning
      • Workshop papers
      • Hidden Technical Debt in Machine Learning Systems
      • Inference Systems
      • Parameter Servers and AllReduce
      • Federated Learning at Scale - Part I
      • Federated Learning at Scale - Part II
      • Learning From Non-IID data
      • Ray: A Distributed Framework for Emerging AI Applications
      • PipeDream: Generalized Pipeline Parallelism for DNN Training
      • DeepXplore: Automated Whitebox Testingof Deep Learning Systems
      • Distributed Machine Learning Misc.
  • ML for Systems
    • Index
      • Short Summaries
  • Machine Learning
    • Index
      • Deep Learning with Differential Privacy
      • Accelerating Deep Learning via Importance Sampling
      • A Few Useful Things to Know About Machine Learning
  • Video Analytics
    • Index
      • Scaling Video Analytics on Constrained Edge Nodes
      • Focus: Querying Large Video Datasets with Low Latency and Low Cost
      • NoScope: Optimizing Neural Network Queriesover Video at Scale
      • Live Video Analytics at Scale with Approximation and Delay-Tolerance
      • Chameleon: Scalable Adaptation of Video Analytics
      • End-to-end Learning of Action Detection from Frame Glimpses in Videos
      • Short Summaries
  • Networking
    • Index
      • Salsify: Low-Latency Network Video through Tighter Integration between a Video Codec and a Transport
      • Learning in situ: a randomized experiment in video streaming
      • Short Summaries
  • Serverless
    • Index
      • Serverless Computing: One Step Forward, Two Steps Back
      • Encoding, Fast and Slow: Low-Latency Video Processing Using Thousands of Tiny Threads
      • SAND: Towards High-Performance Serverless Computing
      • Pocket: Elastic Ephemeral Storage for Serverless Analytics
      • Fault-tolerant and Transactional Stateful Serverless Workflows
  • Resource Disaggregation
    • Index
  • Edge Computing
    • Index
  • Security/Privacy
    • Index
      • Differential Privacy
      • Honeycrisp: Large-Scale Differentially Private Aggregation Without a Trusted Core
      • Short Summaries
  • Misc.
    • Index
      • Rate Limiting
      • Load Balancing
      • Consistency Models in Distributed System
      • Managing Complexity
      • System Design
      • Deep Dive into the Spark Scheduler
      • The Actor Model
      • Python Global Interpreter Lock
      • About Research and PhD
Powered by GitBook
On this page
  • TL;DR
  • Background and Motivation
  • CloudCanary
  • Related Reading:

Was this helpful?

  1. Fault Tolerance
  2. Index

Check before You Change: Preventing Correlated Failures in Service Updates

https://ennanzhai.github.io/pub/nsdi20-cloudcanary.pdf

PreviousCapturing and Enhancing In Situ System Observability for Failure DetectionNextEfficient Scalable Thread-Safety-Violation Detection

Last updated 5 years ago

Was this helpful?

TL;DR

This paper presents CloudCanary, a system that can perform real-time audits on service updates to identify the root cause of correlated failure risks, and generate improvement plans with increase reliability. This is a follow-up work of their paper in OSDI' 14.

Background and Motivation

To enhance reliability, cloud providers typically replicate states and functionality across multiple servers. However, the complex. multilayered nature of network/software stacks may conceal underlying interdependencies between seemingly independent components. Failures of these common service dependencies can lead to correlated failures despite replication, causing system downtime. For example, a faulty top-of-rack switch would affect all replicas in the same rack.

Risk Group

In redundant systems, a risk group or RG is a set of components whose simultaneous failures could cause a service outage. To prevent correlated failures, the operator needs a tool to check for risk groups in a service deployment and generate improvement plans. For example, if a risk group only contains one element, e.g., a shared switch, it may potentially become a SPOF. In this case, the operator may want to improve the deployment so that even the smallest risk group contains more than one element.

As most services experience frequent updates in their lifetime, checking for risk groups and generating improvement plans need to be performed continuously in real time.

A fault graph is a layered DAG representing the logical relationships between component faults within a given system. The fault graph has two types of nodes: fault events and logic gates. The leaf nodes in a fault graph are basic faults, which are the smallest units of failures under consideration, e.g., the failure of a switch or software library. The root node in a fault graph represents a target service fault, which indicates the failure of the entire service.

Limitation of existing solutions

Prior to CloudCanary, the state-of-the-art auditing systems either performs an exhaustive search(e.g., INDaas), which is fine for one-shot service audits but infeasible for frequent updates, or use heuristics, which sacrifices accuracy. Moreover, they do not provide any improvement plans and rely on manual effort to meet the reliability requirements.

CloudCanary

CloudCanary consist of two primitives: SnapAudit, which is responsible for extracting risk groups, and DepBooster, which generates improvement plans.

SnapAudit

SnapAudit uses an incremental auditing algorithm that identifies differential fault graphs capturing the delta between the before and after state of the service following an update. At service initialization, SnapAudit not only audits the overall fault graph, but also every subgraph and store in a key-value cache. To speed up analysis, SnapAudit then turns a differential fault graph into a boolean formula and uses a a high performance MinCostSAT solver.

The goal of the analysis is to extract top-k minimal risk groups. A risk group is minimal if the removal of any of its constituent elements makes it no longer a risk group. The top-k risk groups of a given fault graph are ranked by size or by failure probability.

DepBooster

DepBooster offers the operator an interface to specify "reliability goals", and assesses if the current deployment meets the goals. If not, DepBooster generates improvement plans with increased reliability.

In particular, it allows the operator to specified the requirements(e.g., the size of the smallest RG or the minimum failure probability), the actions(e.g., add, link and remove), and the constraints.

I enjoyed reading the paper overall and I think it is much more solid than their previous system INDaaS. Fault graphs and risk groups are important and powerful tools in our resilience engineering toolbox.

Related Reading:

Fault Graphs
http://psteitz.blogspot.com/2011/10/correlated-failure-in-distributed.html
https://storage.googleapis.com/pub-tools-public-publication-data/pdf/36737.pdf
INDaaS
An example of service update
Fault Graph of Figure 1