Hypervisor-Based Fault-Tolerance Thomas C. Bressoud, Isis - PowerPoint PPT Presentation

Hypervisor-­‑Based ¡Fault-­‑Tolerance ¡ Thomas ¡C. ¡Bressoud, ¡Isis ¡Distributed ¡Systems ¡ Fred ¡B. ¡Schneider, ¡Cornell ¡University ¡ ¡ SOSP, ¡1995 ¡

Problem ¡ • Fault ¡tolerance ¡is ¡subtle ¡and ¡oEen ¡hard ¡to ¡implement ¡ on ¡exisGng ¡layers ¡ • Hardware ¡Level ¡ImplementaGon ¡ – Design ¡cost, ¡design ¡oEen ¡lag ¡behind ¡ • OperaGng ¡System ¡Level ¡ImplementaGon ¡ – Difficult ¡to ¡idenGfy ¡state ¡transiGons ¡ – So ¡many ¡OSes ¡compare ¡to ¡the ¡number ¡of ¡arch ¡ • ApplicaGon ¡Level ¡ImplementaGon ¡ – Do ¡similar ¡coordinaGon ¡for ¡all ¡program ¡ – High ¡demanding ¡

Compare ¡With ¡Chain ¡ReplicaGon ¡ • Similarity: ¡ – Explored ¡trade-­‑off ¡space ¡with ¡a ¡new ¡design ¡ – Based ¡on ¡ failstop ¡model ¡ • Difference: ¡ – Overall, ¡the ¡goal ¡of ¡two ¡paper ¡are ¡quite ¡different ¡ • Chain ¡replicaGon ¡focus ¡on ¡maintaining ¡system ¡performance ¡while ¡ providing ¡strong ¡consistency ¡ • This ¡paper ¡concerns ¡more ¡about ¡engineering ¡costs ¡versus ¡Gme-­‑to-­‑ market ¡costs ¡ – Another ¡one ¡is ¡what ¡kind ¡of ¡fault ¡to ¡tolerate ¡ • Chain ¡ReplicaGon ¡is ¡not ¡parGcularly ¡interested ¡in ¡any ¡certain ¡type ¡ of ¡fault ¡ • This ¡paper ¡focus ¡on ¡processor ¡fault ¡

SoluGon ¡ • Hypervisor ¡between ¡hardware ¡& ¡OS ¡ – One ¡per ¡instrucGon-­‑set ¡architecture ¡ – Can ¡support ¡all ¡OSes ¡run ¡on ¡that ¡architecture ¡ – Frees ¡applicaGon ¡developer ¡ • Idea ¡ – Sequence ¡of ¡instrucGons ¡executed ¡by ¡two ¡virtual ¡machines ¡ running ¡on ¡different ¡physical ¡processors ¡are ¡idenGcal ¡ • Primary ¡and ¡Backup ¡based ¡on ¡state ¡machine ¡approach ¡ – Primary ¡makes ¡decision, ¡backup ¡takeover ¡if ¡primary ¡fail ¡ – State: ¡virtual ¡processor ¡state ¡ – Commands: ¡instrucGon ¡to ¡run ¡and ¡also ¡interrupt ¡(with ¡ data) ¡at ¡primary ¡to ¡deliver ¡

Technical ¡Detail ¡ • I/O ¡Accessibility ¡AssumpGon: ¡ • I/O ¡devices ¡are ¡shared ¡ • IdenGcal ¡Command ¡Stream ¡ ¡ – Ordinary ¡InstrucGon ¡& ¡Environment ¡InstrucGon ¡ • Eliminate ¡non-­‑determinisGc ¡by ¡communicate ¡when ¡ execuGng ¡environment ¡instrucGon ¡ – Epochs ¡( ¡checkpoint ¡) ¡ • Use ¡register ¡count ¡to ¡periodically ¡invoke ¡hypervisor ¡ • Synchronize ¡VMs ¡by ¡sending ¡interrupts ¡received ¡by ¡ primary ¡replica ¡

Compare ¡With ¡Chain ¡ReplicaGon ¡ • Similar ¡idea ¡ – Both ¡paper ¡use ¡the ¡method ¡of ¡primary ¡and ¡backup ¡ • DifferenGate ¡cost ¡and ¡effect ¡of ¡operaGons ¡ – CommunicaGon ¡is ¡necessary ¡to ¡deal ¡non-­‑determinism ¡ – For ¡Chan ¡ReplicaGon, ¡it ¡is ¡the ¡update ¡request ¡ ¡ – In ¡this ¡paper, ¡it ¡is ¡the ¡environment ¡instrucGon ¡ • Different ¡layer ¡and ¡mindset ¡ – Chain ¡ReplicaGon ¡works ¡on ¡applicaGon ¡layer ¡(top ¡down) ¡ – This ¡paper ¡implement ¡on ¡hypervisor ¡layer ¡which ¡mask ¡the ¡ hardware ¡failure ¡(bo\om ¡up) ¡

Performance ¡ • Increase ¡epoch ¡length ¡improves ¡performance ¡ – With ¡a ¡limit ¡of ¡385,000 ¡ • Epoch ¡length ¡has ¡less ¡effect ¡on ¡I/O ¡intensive ¡ workloads ¡ • Run ¡programs ¡about ¡a ¡factor ¡of ¡2 ¡slower ¡than ¡ a ¡bare ¡machine ¡would ¡ • Have ¡to ¡deal ¡with ¡virtual ¡memory ¡

Take ¡away ¡ • The ¡key ¡issue ¡of ¡replicated ¡state ¡machine ¡ – EliminaGng ¡non-­‑determinism ¡ • The ¡costs ¡of ¡fault ¡tolerant ¡are ¡different ¡between ¡ ImplementaGon ¡layers ¡ – Hypervisor ¡level ¡implementaGon ¡ ¡ • Cost ¡of ¡performance ¡and ¡fault ¡coverage ¡ • Provides ¡transparent ¡fault ¡tolerance ¡and ¡OS ¡coverage ¡ – ApplicaGon ¡level ¡implementaGon ¡ ¡ • Requires ¡higher ¡level ¡idea ¡of ¡enGre ¡system ¡and ¡its ¡requirement ¡ • PotenGally ¡be\er ¡scalability ¡and ¡task ¡specific ¡opGmizaGon ¡ – How ¡do ¡we ¡choose? ¡ ¡