RRC: Responsive Replicated Containers

on YouTube ↗22m

" summary

RRC implements hybrid checkpoint+replay replication at the container level and adds a new kernel primitive, container fork, that clones a container so checkpointing runs on a shadow while the primary continues, cutting pause times by an order of magnitude. It records nondeterministic sync outcomes (not every memory access) and syscall return timing to mitigate rare data races. Evaluation shows <400μs average response delay, <1s recovery, average pause <3.3ms, under 48% throughput overhead on eight benchmarks, and >99% recovery with real-world races.

AI-written summary · about

" chapters (19)

1. 0:00Intro
2. 0:42Server Applications Need Responsive Fault Tolerance
3. 2:09What is Missing in Existing Replication Schemes?
4. 3:22Passive Backup: Checkpointing-Based Mechanisms
5. 4:16Checkpointing-Based Mechanisms → High latency Overhead
6. 5:05Active Backup: Mechanisms based on Active Replication
7. 5:38Disadvantages of Active Backup Mechanisms
8. 7:18Passive Backup as the Starting Point
9. 7:40Using hybrid replication
10. 8:30Choice of Granularity of Replication
11. 10:20Handling Primary Failure
12. 10:56RRC: Backup Failure
13. 11:37Key Design and Implementation Challenge
14. 14:48Data Race Considerations
15. 15:36The Potential Impact of Data Races Replay Run
16. 17:23Evaluation Setup
17. 18:28Throughput Overhead: RRC vs. NiLiCon
18. 19:28Recovery Success Rate
19. 20:02Key goals: Application-transparent fault tolerance for server applications