Optimal checkpointing periods with fail-stop and silent errors

Similar documents
Fault-Tolerant Techniques for HPC

Resilient and energy-aware algorithms

Checkpoint Scheduling

On scheduling the checkpoints of exascale applications

Efficient checkpoint/verification patterns

Efficient checkpoint/verification patterns for silent error detection

Coping with silent and fail-stop errors at scale by combining replication and checkpointing

Energy-aware checkpointing of divisible tasks with soft or hard deadlines

Checkpointing strategies for parallel jobs

Energy-efficient scheduling

How to deal with uncertainties and dynamicity?

Analysis of the Tradeoffs between Energy and Run Time for Multilevel Checkpointing

Fault Tolerate Linear Algebra: Survive Fail-Stop Failures without Checkpointing

Checkpointing strategies with prediction windows

Impact of fault prediction on checkpointing strategies

Knowledge Discovery and Data Mining 1 (VO) ( )

Scheduling algorithms for heterogeneous and failure-prone platforms

Coping with silent and fail-stop errors at scale by combining replication and checkpointing

Modeling Resubmission in Unreliable Grids: the Bottom-Up Approach

Coordination. Failures and Consensus. Consensus. Consensus. Overview. Properties for Correct Consensus. Variant I: Consensus (C) P 1. v 1.

A Flexible Checkpoint/Restart Model in Distributed Systems

Fault Tolerance. Dealing with Faults

Adaptive and Power-Aware Resilience for Extreme-scale Computing

The exponential distribution and the Poisson process

Fault-Tolerant Computing

Checkpointing strategies with prediction windows

Identifying the right replication level to detect and correct silent errors at scale

Coping with Recall and Precision of Soft Error Detectors

2DI90 Probability & Statistics. 2DI90 Chapter 4 of MR

Tradeoff between Reliability and Power Management

Reliable Computing I

Reading: Karlin and Taylor Ch. 5 Resnick Ch. 3. A renewal process is a generalization of the Poisson point process.

Reliability of Technical Systems

Divisible Load Scheduling

1 st Semester 2007/2008

A Backward/Forward Recovery Approach for the Preconditioned Conjugate Gradient Method

Time. Lakshmi Ganesh. (slides borrowed from Maya Haridasan, Michael George)

Scalable, Robust, Fault-Tolerant Parallel QR Factorization. Camille Coti

Causal Consistency for Geo-Replicated Cloud Storage under Partial Replication

Fault Tolerant Computation of Hyperbolic Partial Differential Equations with the Sparse Grid Combination Technique

Network Algorithms and Complexity (NTUA-MPLA) Reliable Broadcast. Aris Pagourtzis, Giorgos Panagiotakos, Dimitris Sakavalas

Rollback-Recovery. Uncoordinated Checkpointing. p!! Easy to understand No synchronization overhead. Flexible. To recover from a crash:

2.6 Complexity Theory for Map-Reduce. Star Joins 2.6. COMPLEXITY THEORY FOR MAP-REDUCE 51

Do we have a quorum?

Toward an Optimal Online Checkpoint Solution under a Two-Level HPC Checkpoint Model

CHAPTER 10 RELIABILITY

Exercises Stochastic Performance Modelling. Hamilton Institute, Summer 2010

On the Complexity of Mapping Pipelined Filtering Services on Heterogeneous Platforms

Chapter 2. Planning Criteria. Turaj Amraee. Fall 2012 K.N.Toosi University of Technology

DS-GA 1002 Lecture notes 2 Fall Random variables

9. Reliability theory

416 Distributed Systems

f X (x) = λe λx, , x 0, k 0, λ > 0 Γ (k) f X (u)f X (z u)du

C 1. Recap: Finger Table. CSE 486/586 Distributed Systems Consensus. One Reason: Impossibility of Consensus. Let s Consider This

Scalability of Partial Differential Equations Preconditioner Resilient to Soft and Hard Faults

Dependable Systems. ! Dependability Attributes. Dr. Peter Tröger. Sources:

Random variables. DS GA 1002 Probability and Statistics for Data Science.

Scheduling Parallel Iterative Applications on Volatile Resources

Review: From problem to parallel algorithm

Engineering Risk Benefit Analysis

Part I Stochastic variables and Markov chains

md5bloom: Forensic Filesystem Hashing Revisited

FACTORS AFFECTING CONCURRENT TRUNCATE

Identifying the right replication level to detect and correct silent errors at scale

Che-Wei Chang Department of Computer Science and Information Engineering, Chang Gung University

Robust Network Codes for Unicast Connections: A Case Study

CS425: Algorithms for Web Scale Data

Optimal Checkpoint Placement on Real-Time Tasks with Harmonic Periods

Agreement Protocols. CS60002: Distributed Systems. Pallab Dasgupta Dept. of Computer Sc. & Engg., Indian Institute of Technology Kharagpur

Embedded Systems Design: Optimization Challenges. Paul Pop Embedded Systems Lab (ESLAB) Linköping University, Sweden

Cactus Tools for Petascale Computing

Process Scheduling for RTS. RTS Scheduling Approach. Cyclic Executive Approach

10 Introduction to Reliability

Analytical Modeling of Parallel Programs (Chapter 5) Alexandre David

Multi-State Availability Modeling in Practice

Scheduling divisible loads with return messages on heterogeneous master-worker platforms

Optimizing Fault Tolerance for Real-Time Systems

PROBABILITY DISTRIBUTIONS

PoissonprocessandderivationofBellmanequations

Reliability of Technical Systems

Scalable Techniques for Fault Tolerant High Performance Computing

Time-varying failure rate for system reliability analysis in large-scale railway risk assessment simulation

Exponential Distribution and Poisson Process

A Pseudo-Random Encryption Mode

The virtue of dependent failures in multi-site systems

Availability. M(t) = 1 - e -mt

Chapter Learning Objectives. Probability Distributions and Probability Density Functions. Continuous Random Variables

IEOR 6711, HMWK 5, Professor Sigman

14 Random Variables and Simulation

Energy-aware checkpointing of divisible tasks with soft or hard deadlines

STAT509: Continuous Random Variable

STAT2201. Analysis of Engineering & Scientific Data. Unit 3

Survival Distributions, Hazard Functions, Cumulative Hazards

Stat 512 Homework key 2

NICTA Short Course. Network Analysis. Vijay Sivaraman. Day 1 Queueing Systems and Markov Chains. Network Analysis, 2008s2 1-1

Introduction to Reliability Theory (part 2)

Statistical Reliability Modeling of Field Failures Works!

Northwestern University Department of Electrical Engineering and Computer Science

Coding for loss tolerant systems

Die Fallstricke der Verfügbarkeit (Trapped with availability) Hendrik Schäbe

Transcription:

Optimal checkpointing periods with fail-stop and silent errors Anne Benoit ENS Lyon Anne.Benoit@ens-lyon.fr http://graal.ens-lyon.fr/~abenoit 3rd JLESC Summer School June 30, 2016 Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 1/ 57

Exascale platforms Hierarchical 10 5 or 10 6 nodes Each node equipped with 10 4 or 10 3 cores Failure-prone MTBF one node 1 year 10 years 120 years MTBF platform 30sec 5mn 1h of 10 6 nodes More nodes Shorter MTBF (Mean Time Between Failures) Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 2/ 57

Exascale platforms Hierarchical 10 5 or 10 6 nodes Each node equipped with 10 4 or 10 3 cores Failure-prone MTBF one node 1 year 10 years 120 years MTBF platform 30sec 5mn 1h of 10 6 nodes Exascale Petascale 1000 More nodes Shorter MTBF (Mean Time Between Failures) Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 2/ 57

Even for today s platforms (courtesy F. Cappello) Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 3/ 57

Even for today s platforms (courtesy F. Cappello) Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 4/ 57

A few definitions Many types of faults: software error, hardware malfunction, memory corruption Many possible behaviors: silent, transient, unrecoverable Restrict to faults that lead to application failures This includes all hardware faults, and some software ones Will use terms fault and failure interchangeably Silent errors (SDC) will be addressed later in the course First question: quantify the rate or frequency at which these faults strike! Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 5/ 57

A few definitions Many types of faults: software error, hardware malfunction, memory corruption Many possible behaviors: silent, transient, unrecoverable Restrict to faults that lead to application failures This includes all hardware faults, and some software ones Will use terms fault and failure interchangeably Silent errors (SDC) will be addressed later in the course First question: quantify the rate or frequency at which these faults strike! Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 5/ 57

Exponential failure distributions Failure Probability Sequential Machine 1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 Exp(1/100) 0 0 200 400 600 800 1000 Time (years) Exp(λ): Exponential distribution law of parameter λ: Probability density function (pdf): f (t) = λe λt dt for t 0 Cumulative distribution function (cdf): F (t) = 1 e λt Mean: µ = 1 λ Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 6/ 57

Exponential failure distributions Failure Probability Sequential Machine 1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 Exp(1/100) 0 0 200 400 600 800 1000 Time (years) X random variable for Exp(λ) failure inter-arrival times: P (X t) = 1 e λt dt (by definition) Memoryless property: P (X t + s X s ) = P (X t) (for all t, s 0): at any instant, time to next failure does not depend on time elapsed since last failure Mean Time Between Failures (MTBF) µ = E (X ) = 1 λ Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 6/ 57

With several processors Rebooting only faulty processor Platform failure distribution superposition of p IID processor distributions IID only for Exponential Define µ p by n(f ) lim = 1 F + F µ p n(f ) = number of platform failures until time F is exceeded Theorem: µ p = µ p for arbitrary distributions Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 7/ 57

Summary for the road MTBF key parameter and µ p = µ p Exponential distribution OK for most purposes Assume failure independence while not (completely) true Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 8/ 57

General purpose approach Periodic checkpointing, rollback and recovery Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 9/ 57

Outline 1 Probabilistic models Young/Daly s approximation Assessing protocols at scale 2 In-memory checkpointing 3 Dealing with silent errors 4 Conclusion Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 10/ 57

Outline 1 Probabilistic models Young/Daly s approximation Assessing protocols at scale 2 In-memory checkpointing 3 Dealing with silent errors 4 Conclusion Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 11/ 57

Checkpointing cost Time spent working Time spent checkpointing Time Computing the first chunk Checkpointing the first chunk Processing the first chunk Processing the second chunk Blocking model: while a checkpoint is taken, no computation can be performed Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 12/ 57

Framework Periodic checkpointing policy of period T Independent and identically distributed (IID) failures Applies to a single processor with MTBF µ = µ ind Applies to a platform with p processors with MTBF µ = µ ind p coordinated checkpointing tightly-coupled application progress all processors available platform = single (powerful, unreliable) processor Waste: fraction of time not spent for useful computations Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 13/ 57

Waste in fault-free execution Time spent working Time spent checkpointing Computing the first chunk Checkpointing the first chunk Processing the first chunk Processing the second chunk Time Time base : application base time Time FF : with periodic checkpoints but failure-free Time FF = Time base + #checkpoints C Timebase #checkpoints = Time base (valid for large jobs) T C T C Waste[FF ] = Time FF Time base Time FF = C T Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 14/ 57

Waste due to failures Time base : application base time Time FF : with periodic checkpoints but failure-free Time final : expectation of time with failures Time final = Time FF + N faults T lost N faults : number of failures during execution T lost : average time lost per failure N faults = Time final µ T lost? Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 15/ 57

Waste due to failures Time base : application base time Time FF : with periodic checkpoints but failure-free Time final : expectation of time with failures Time final = Time FF + N faults T lost N faults : number of failures during execution T lost : average time lost per failure N faults = Time final µ T lost? Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 15/ 57

Computing T lost Time spent working Downtime Time spent checkpointing Recovery time Time P0 P1 P2 P3 T /2 D R T C C T T lost = D + R + T 2 Rationale Instants when periods begin and failures strike are independent Approximation used for all distribution laws Exact for Exponential and uniform distributions Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 16/ 57

Waste due to failures Time final = Time FF + N faults T lost Waste[fail] = Time final Time FF = 1 ( D + R + T ) Time final µ 2 Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 17/ 57

Total waste T -C C T -C C T -C C T -C C T -C C Time FF =Time final (1-Waste[fail]) Time final Waste[fail] Time final Waste = Time final Time base Time final 1 Waste = (1 Waste[FF ])(1 Waste[fail]) Waste = C ( T + 1 C ) ( 1 D + R + T ) T µ 2 Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 18/ 57

Waste minimization Waste = C ( T + 1 C ) ( 1 D + R + T ) T µ 2 u = C ( 1 D + R ) µ Waste = u T + v + wt v = D + R C/2 µ w = 1 2µ Waste minimized for T = u w T = 2(µ (D + R))C Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 19/ 57

Validity of the approach (1/3) Technicalities E (N faults ) = Time final µ and E (T lost ) = D + R + T 2 but expectation of product is not product of expectations (not independent RVs here) Enforce C T to get Waste[FF ] 1 Enforce D + R µ and bound T to get Waste[fail] 1 but µ = µ ind p too small for large p, regardless of µ ind Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 20/ 57

Validity of the approach (2/3) Several failures within same period? Waste[fail] accurate only when two or more faults do not take place within same period Cap period: T γµ, where γ is some tuning parameter Poisson process of parameter θ = T µ Probability of having k 0 failures: P(X = k) = θk k! e θ Probability of having two or more failures: π = P(X 2) = 1 (P(X = 0) + P(X = 1)) = 1 (1 + θ)e θ γ = 0.27 π 0.03 overlapping faults for only 3% of checkpointing segments Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 21/ 57

Validity of the approach (3/3) Enforce T γµ, C γµ, and D + R γµ Optimal period 2(µ (D + R))C may not belong to admissible interval [C, γµ] Waste is then minimized for one of the bounds of this admissible interval (by convexity) Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 22/ 57

Wrap up Capping periods, and enforcing a lower bound on MTBF mandatory for mathematical rigor Not needed for practical purposes actual job execution uses optimal value account for multiple faults by re-executing work until success Approach surprisingly robust Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 23/ 57

Lesson learnt for fail-stop failures (Not so) Secret data Tsubame 2: 962 failures during last 18 months so µ = 13 hrs Blue Waters: 2-3 node failures per day Titan: a few failures per day Tianhe 2: wouldn t say T opt = 2µC Waste[opt] 2C µ Petascale: C = 20 min µ = 24 hrs Waste[opt] = 17% Scale by 10: C = 20 min µ = 2.4 hrs Waste[opt] = 53% Scale by 100: C = 20 min µ = 0.24 hrs Waste[opt] = 100% Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 24/ 57

Lesson learnt for fail-stop failures (Not so) Secret data Tsubame 2: 962 failures during last 18 months so µ = 13 hrs Blue Waters: 2-3 node failures per day Titan: a few failures per day Tianhe 2: wouldn t say Exascale Petascale 1000 Need more reliable components T opt = Need to2µc checkpoint Waste[opt] faster 2C µ Petascale: C = 20 min µ = 24 hrs Waste[opt] = 17% Scale by 10: C = 20 min µ = 2.4 hrs Waste[opt] = 53% Scale by 100: C = 20 min µ = 0.24 hrs Waste[opt] = 100% Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 24/ 57

Lesson learnt for fail-stop failures (Not so) Secret data Tsubame 2: 962 failures during last 18 months so µ = 13 hrs Blue Waters: 2-3 node failures per day Titan: a few failures per day Tianhe 2: wouldn t say Silent errors: detection latency additional problems T opt = 2C 2µC Waste[opt] µ Petascale: C = 20 min µ = 24 hrs Waste[opt] = 17% Scale by 10: C = 20 min µ = 2.4 hrs Waste[opt] = 53% Scale by 100: C = 20 min µ = 0.24 hrs Waste[opt] = 100% Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 24/ 57

Exponential failure distribution How to compute the expected time E(T (W, C, D, R, λ)) to execute a work of duration W followed by a checkpoint of duration C? How to extend this result for sequential and parallel jobs? Attend the hands-on session at 14.45: Mathematical exercises on Daly and extensions! Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 25/ 57

Outline 1 Probabilistic models Young/Daly s approximation Assessing protocols at scale 2 In-memory checkpointing 3 Dealing with silent errors 4 Conclusion Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 26/ 57

Which checkpointing protocol to use? Coordinated checkpointing No risk of cascading rollbacks No need to log messages All processors need to roll back Rumor: May not scale to very large platforms Hierarchical checkpointing Need to log inter-group messages Slowdowns failure-free execution Increases checkpoint size/time Only processors from failed group need to roll back Faster re-execution with logged messages Rumor: Should scale to very large platforms Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 27/ 57

Blocking vs. non-blocking Time spent working Time spent checkpointing Time Computing the first chunk Checkpointing the first chunk Processing the first chunk Processing the second chunk Blocking model: checkpointing blocks all computations Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 28/ 57

Blocking vs. non-blocking Time spent working Time spent checkpointing Time Computing the first chunk Checkpointing the first chunk Processing the first chunk Processing the second chunk Non-blocking model: checkpointing has no impact on computations (e.g., first copy state to RAM, then copy RAM to disk) Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 28/ 57

Blocking vs. non-blocking Time spent working Time spent checkpointing Time spent working with slowdown Time Computing the first chunk Checkpointing the first chunk Processing the first chunk General model: checkpointing slows computations down: during a checkpoint of duration C, the same amount of computation is done as during a time αc without checkpointing (0 α 1) Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 28/ 57

Waste in fault-free execution Time spent working Time spent checkpointing Time spent working with slowdown Time P0 P1 P2 P3 T C T C Time elapsed since last checkpoint: T Amount of computations executed: Work = (T C) + αc Waste[FF ] = T Work T Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 29/ 57

Waste due to failures Time spent working Time spent checkpointing Time spent working with slowdown Time P0 P1 P2 P3 Failure can happen 1 During computation phase 2 During checkpointing phase Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 29/ 57

Waste due to failures Time spent working Time spent checkpointing Time spent working with slowdown Time P0 P1 P2 P3 Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 29/ 57

Waste due to failures Time spent working Time spent checkpointing Time spent working with slowdown Time P0 P1 P2 P3 Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 29/ 57

Waste due to failures Time spent working Time spent checkpointing Time spent working with slowdown Time P0 P1 P2 P3 Tlost Coordinated checkpointing protocol: when one processor is victim of a failure, all processors lose their work and must roll back to last checkpoint Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 29/ 57

Waste due to failures in computation phase Time spent working Time spent checkpointing Time spent working with slowdown Downtime Time P0 P1 P2 P3 D Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 29/ 57

Waste due to failures in computation phase Time spent working Downtime Time spent checkpointing Recovery time Time spent working with slowdown Time P0 P1 P2 P3 R Coordinated checkpointing protocol: all processors must recover from last checkpoint Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 29/ 57

Waste due to failures in computation phase Time spent working Time spent checkpointing Time spent working with slowdown Downtime Recovery time Re-executing slowed-down work Time P0 P1 P2 P3 C αc Redo the work destroyed by the failure, that was done in the checkpointing phase before the computation phase But no checkpoint is taken in parallel, hence this re-execution is faster than the original computation Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 29/ 57

Waste due to failures in computation phase Time spent working Time spent checkpointing Time spent working with slowdown Downtime Recovery time Re-executing slowed-down work Time P0 P1 P2 P3 T C Re-execute the computation phase Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 29/ 57

Waste due to failures in computation phase Time spent working Downtime Time spent checkpointing Recovery time Time spent working with slowdown Re-executing slowed-down work Time P0 P1 P2 P3 C Finally, the checkpointing phase is executed Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 29/ 57

Total waste Time spent working Time spent checkpointing Time spent working with slowdown Downtime Recovery time Re-executing slowed-down work Time P0 P1 P2 P3 Tlost D R αc T C C T Waste[fail] = 1 µ ( D + R + αc + T ) 2 Optimal period T opt = 2(1 α)(µ (D + R + αc))c Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 29/ 57

Hierarchical checkpointing Time spent working Downtime Time spent checkpointing Recovery time Time spent working with slowdown Re-executing slowed-down work Time G 1 G 2 G g G 4 G 5 T lost D R T lost G.C α(g g+1)c T G.C T lost T Processors partitioned into G groups Each group includes q processors Inside each group: coordinated checkpointing in time C(q) Inter-group messages are logged Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 30/ 57

Total waste Waste[FF ] = T Work with Work = T (1 α)gc(q) T Waste[fail] = 1 ( ) D(q) + R(q) + Re-Exec with µ Re-Exec = T GC(q) Re-Exec comp + GC(q) T T Re-Exec ckpt Waste = Waste[FF ] + Waste[fail] Waste[FF ]Waste[fail] Minimize Waste subject to: GC(q) T (by construction) Gets complicated! Use computer algebra software Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 31/ 57

Conclusion Hierarchical protocols better for small MTBFs: more suitable for failure-prone platforms Struggle when communication intensity increases, but limited waste in all other cases The faster the checkpointing time, the smaller the waste Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 32/ 57

Outline 1 Probabilistic models 2 In-memory checkpointing 3 Dealing with silent errors 4 Conclusion Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 33/ 57

Motivation Checkpoint transfer and storage critical issues of rollback/recovery protocols Stable storage: high cost Distributed in-memory storage: Store checkpoints in local memory no centralized storage Much better scalability Replicate checkpoints application survives single failure Still, risk of fatal failure in some (unlikely) scenarios Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 34/ 57

Double checkpointing algorithm Platform nodes partitioned into pairs Each node in a pair exchanges its checkpoint with its buddy Each node saves two checkpoints: - one locally: storing its own data - one remotely: receiving and storing its buddy s data Two algorithms blocking version by Zheng, Shi and Kalé non-blocking version by Ni, Meneses and Kalé Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 35/ 57

Non-blocking checkpoint algorithm Local checkpoint done Remote checkpoint done Period done Node p f 1 Node p' f 1 d q s P Checkpoints taken periodically, with period P = δ + θ + σ Phase 1, length δ: local checkpoint, blocking mode. No work Phase 2, length θ: remote checkpoint. Overhead φ Phase 3, length σ: application at full speed 1 Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 36/ 57

Non-blocking checkpoint algorithm Local checkpoint done Remote checkpoint done Period done Node p f 1 Node p' f 1 d q s P Work in failure-free period: W = (θ φ) + σ = P δ φ Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 36/ 57

Cost of overlap Local checkpoint done Remote checkpoint done Period done Node p f 1 Node p' f 1 d q s P Overlap computations and checkpoint file exchanges Large θ more flexibility to hide cost of file exchange smaller overhead φ Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 37/ 57

Cost of overlap Local checkpoint done Remote checkpoint done Period done Node p f 1 Node p' f 1 d q s P θ = θ min : fastest communication, fully blocking φ = θ min θ = θ max : full overlap with computation φ = 0 Linear interpolation θ(φ) = θ min + α(θ min φ) φ = 0 for θ = θ max = (1 + α)θ min α: rate of overhead decrease w.r.t. communication length Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 38/ 57

Assessing the risk Node p f 1 f 1 Risk Period Node p' f 1 f 1 d q s P d q t lost Checkpoint of p Checkpoint of p' Node to replace p f 1 D R q t lost After failure: downtime D and recovery from buddy node Two checkpoint files lost, must be re-sent to faulty processor 1 Checkpoint of faulty node, needed for recovery sent as fast as possible, in time R = θ min 2 Checkpoint of buddy node, needed in case buddy fails later on?? Application at risk until complete reception of both messages Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 39/ 57

Checkpoint of buddy node Scenario DoubleNBL File sent at same speed as in regular mode, in time θ(φ) Overhead φ Favors performance, at the price of higher risk Scenario DoubleBoF File sent as fast as possible, in time θ min = R Overhead R Favors risk reduction, at the price of higher overhead Computing the waste? Hands-on session at 14:45! Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 40/ 57

Conclusion Double checkpointing DoubleBoF reduces risk duration, at the cost of increasing failure overhead Parameter α for transfer cost overlap Unified model for performance/risk bi-criteria assessment Triple checkpointing Save checkpoint on two remote processes instead of one, without much more memory or storage requirements Excellent success probability, almost no failure-free overhead Assessment of performance and risk factors using unified mode Realistic scenarios conclude to superiority of Triple Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 41/ 57

Outline 1 Probabilistic models 2 In-memory checkpointing 3 Dealing with silent errors Revisiting Young/Daly (base pattern) Pattern with several verifications 4 Conclusion Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 42/ 57

General-purpose approach Periodic checkpointing, rollback and recovery: Error C C C Time Works fine for fail-stop errors Detection latency in silent errors risk of saving corrupted checkpoint(s) Maintaining multiple checkpoints (Lu, Zheng and Chien, 2013) Requires more stable storage Which checkpoint to roll back to? Critical failure when all live checkpoints are invalid Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 43/ 57

General-purpose approach Periodic checkpointing, rollback and recovery: Error Corrupt Detect C C C Time Works fine for fail-stop errors Detection latency in silent errors risk of saving corrupted checkpoint(s) Maintaining multiple checkpoints (Lu, Zheng and Chien, 2013) Requires more stable storage Which checkpoint to roll back to? Critical failure when all live checkpoints are invalid Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 43/ 57

General-purpose approach Periodic checkpointing, rollback and recovery: Error Corrupt Detect C C C Time Works fine for fail-stop errors Detection latency in silent errors risk of saving corrupted checkpoint(s) Maintaining multiple checkpoints (Lu, Zheng and Chien, 2013) Requires more stable storage Which checkpoint to roll back to? Critical failure when all live checkpoints are invalid Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 43/ 57

General-purpose approach Periodic checkpointing, rollback and recovery: Corrupt Corrupt Detect C C C Time Works fine for fail-stop errors Detection latency in silent errors risk of saving corrupted checkpoint(s) Maintaining multiple checkpoints (Lu, Zheng and Chien, 2013) Requires more stable storage Which checkpoint to roll back to? Critical failure when all live checkpoints are invalid Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 43/ 57

General-purpose approach Periodic checkpointing, rollback and recovery: Corrupt Corrupt Detect C C C Time Works fine for fail-stop errors Detection latency in silent errors risk of saving corrupted checkpoint(s) Maintaining multiple checkpoints (Lu, Zheng and Chien, 2013) Requires more stable storage Which checkpoint to roll back to? Critical failure when all live checkpoints are invalid Need to know when silent error occurred Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 43/ 57

Coping with silent errors Couple checkpointing with verification: Error Detect V C V C V C Time Before each checkpoint, run some verification mechanism or error detection test Silent error, if any, is detected by verification need to maintain only one checkpoint, which is always valid Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 44/ 57

Models and objective Resilience parameters Objective C: Cost of checkpointing R: Cost of recovery V : Cost of verification Design a periodic computing pattern that minimizes the expected execution time (makespan) of the application V C V C V C Pattern Time Last verification of a pattern is always perfect to avoid saving corrupted checkpoints Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 45/ 57

Outline 1 Probabilistic models 2 In-memory checkpointing 3 Dealing with silent errors Revisiting Young/Daly (base pattern) Pattern with several verifications 4 Conclusion Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 46/ 57

Revisiting Young/Daly (Base Pattern P c ) V C V C W Time Proposition The expected time to execute a base pattern P c of work length W is E(W ) = W + V + C + λw (W + V + R) + O(λ 2 W 3 ) Proof. First, express the expected execution time recursively: E(W ) = W + V + (1 e λw )(R + E(W )) + e λw C Then, solve the recursion and take first-order approximation Approximation is accurate if platform MTBF is large in front of the resilience parameters Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 47/ 57

Revisiting Young/Daly (Base Pattern P c ) Proposition The optimal work length W of the base pattern P c is V + C W = λ and the optimal expected overhead is Overhead = 2 λ(v + C) + O(λ) Proof. Derive the overhead from the expected execution time: Overhead = E(W ) W 1 Balance W to minimize Overhead = V + C W + λw + λ(v + R) + O(λ2 W 2 ) Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 48/ 57

Revisiting Young/Daly (Base Pattern P c ) Recall from the waste analysis: Fail-stop errors Silent errors Pattern T = W + C T = W + V + C Waste ff C T V +C T Waste fail λ(d + R + W 2 ) λ(r + W + V ) Optimal period Waste[opt] 2C λ V +C λ 2λC 2 λ(v + C) Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 49/ 57

Outline 1 Probabilistic models 2 In-memory checkpointing 3 Dealing with silent errors Revisiting Young/Daly (base pattern) Pattern with several verifications 4 Conclusion Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 50/ 57

Pattern with several verifications Perform several verifications before each checkpoint: Error Detect V C V V V C V V V C Time silent error is detected earlier in the pattern additional overhead in fault-free executions What is the optimal checkpointing period? How many verifications to use? Where are their positions? Hands-on session at 14:45! Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 51/ 57

Pattern with several verifications Perform several verifications before each checkpoint: Error Detect V C V V V C V V V C Time silent error is detected earlier in the pattern additional overhead in fault-free executions What is the optimal checkpointing period? How many verifications to use? Where are their positions? Hands-on session at 14:45! Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 51/ 57

Pattern with several verifications Perform several verifications before each checkpoint: Error Detect V C V V V C V V V C Time silent error is detected earlier in the pattern additional overhead in fault-free executions What is the optimal checkpointing period? How many verifications to use? Where are their positions? Hands-on session at 14:45! Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 51/ 57

Outline 1 Probabilistic models 2 In-memory checkpointing 3 Dealing with silent errors 4 Conclusion Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 52/ 57

Leitmotiv Resilient research on resilience Models needed to assess techniques at scale without bias Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 53/ 57

Conclusion Multiple approaches to Fault Tolerance Application-Specific Fault Tolerance will always provide more benefits: Checkpoint size reduction (when needed) Portability (can run on different hardware, different deployment, etc..) Diversity of use (can be used to restart the execution and change parameters in the middle) More about this tomorrow at 10:00: ABFT techniques (Frederic Vivien) Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 54/ 57

Conclusion Multiple approaches to Fault Tolerance Application-Specific Fault Tolerance will always provide more benefits: Checkpoint size reduction (when needed) Portability (can run on different hardware, different deployment, etc..) Diversity of use (can be used to restart the execution and change parameters in the middle) More about this tomorrow at 10:00: ABFT techniques (Frederic Vivien) Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 54/ 57

Conclusion Multiple approaches to Fault Tolerance General Purpose Fault Tolerance is a required feature of the platforms Not every computer scientist needs to learn how to write fault-tolerant applications Not all parallel applications can be ported to a fault-tolerant version Faults are a feature of the platform. Why should it be the role of the programmers to handle them? Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 54/ 57

Conclusion General Purpose Fault Tolerance Software/hardware techniques to reduce checkpoint, recovery, migration times and to improve failure prediction Need to deal with silent errors and design/use verification mechanisms General problem: multi-criteria scheduling problem execution time/energy/reliability Add replication Consider best resource usage (performance trade-offs) Need combine all these approaches and find optimal checkpointing periods! Several challenging algorithmic/scheduling problems Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 55/ 57

Bibliography Exascale Toward Exascale Resilience, Cappello F. et al., IJHPCA 23, 4 (2009) The International Exascale Software Roadmap, Dongarra, J., Beckman, P. et al., IJHPCA 25, 1 (2011) Models Checkpointing strategies for parallel jobs, Bougeret M. et al., SC 2011 Unified model for assessing checkpointing protocols at extreme-scale, Bosilca G. et al., INRIA RR-7950, 2012 Buddy Revisiting the double checkpointing algorithm, Dongarra J., Hérault T., Robert Y., INRIA RR-8196, 2012 Silent errors Assessing general-purpose algorithms to cope with fail-stop and silent errors, Benoit A., Cavelan A., Robert Y., Sun H., INRIA RR-8599, 2014 Optimal resilience patterns to cope with fail-stop and silent errors, Benoit A., Cavelan A., Robert Y., Sun H., INRIA RR-8786, 2015 Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 56/ 57

Bibliography New Monograph, Springer Verlag 2015 Thanks to Yves Robert, Thomas Hérault, George Bosilca, Aurélien Bouteiller and Hongyang Sun, from whom I borrowed some slides Anne.Benoit@ens-lyon.fr 3rd JLESC Summer School Optimal checkpointing periods 57/ 57