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 ¡
• n ¡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 ¡

• 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 ¡
• f ¡fault ¡
• This ¡paper ¡focus ¡on ¡processor ¡fault ¡

Compare ¡With ¡Chain ¡ReplicaGon ¡

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 ¡

• 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) ¡

Compare ¡With ¡Chain ¡ReplicaGon ¡

• 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 ¡

Performance ¡

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? ¡

¡