Internet & Web Application

สรุป Paper “A Survey of Fault-Tolerance and Fault-Recovery Techniques in Parallel Systems”

Abstract: ในระบบ Supercomputing System สร้างด้วย Computing Cluster มีลักษณะของ Distributed System ซึ่งประกอบไปด้วย Hardware ที่พึ่งพากัน และอาจจะนำไปสู่ความผิดพลาดในการประมวลผลได้ ดังนั้นเพื่อที่จะเพิ่มความทนทาน “Robustness” มี Techniques มากมายดังจะนำเสนอต่อไปนี้

1.Introduction

.. ความสำคัญของการแก้ปัญหา Failure ในระบบ HPC, Cluster System … Bra Bra Bra …

สิ่งที่ Paper นี้ Focus => Cluster System และ Software ในระบบดังกล่าว .. ผลกระทบที่จะเกิดขึ้นจากปัญหา Failure ดังกล่าวนั้นจะส่งผลคือ .. Bra Bra Bra …

สามารถแบ่ง Fault ที่เกิดใน Parallel System ออกเป็น 2 แบบ

แบบแรก เกิด Failure ที่ Centralize Component เช่น … Bra Bra .. แก้โดยสร้าง Redundancy, เพิ่มอุปกรณ์ที่ Replicate, ให้ทำงานแทนเมื่ออุปกรณ์หลัก Fail

แบบสอง เกิด Failure ที่ Node ใดใดโดยรอบ ทำให้ผลการทำงานบางประการผิดพลาด (แต่ระบบยังทำงานอยู่ได้) … แก้โดยทำ Restore, Checkpoint & Roll Back

2.Fault Model

Parallel System จะมีอาการอย่างไรเมื่อประสบกับ Fault ประเภทต่างๆ .. รูปแบบ, อาการ, ของ Fault ที่เกิดขึ้น

Byzantine Faults

Model นี้ Assume ว่า Failed Nodes สามารถติดต่อกับระบบที่เหลืออยู่ได้

Node ที่ยังทำงานได้ดีอยู่ จะไม่สามารถทราบว่ามี Node มีปัญหาหรือไม่, หรืออาจทราบได้ ถ้าสามารถระบุ Output ที่คาดว่าจะได้ตรงตามที่คาดหรือไม่, จาก Paper [21] ยืนยันว่า จะไม่สามารถ Guarantee ได้ว่าระบบที่มี Nodes จำนวน 3m+1 ทำงานได้ถูกต้อง หาก Nodes จำนวน m เกิด Byzantine Faults

ยกตัวอย่างสาเหตุความผิดพลาดใน Node ของ Model นี้ เป็นแบบ Random และมีผลเนื่องมาจาก Hacker .. เป็นลักษณะ Fail ที่แยกไม่ออกว่าทำงานได้อยู่หรือเปล่าจริงๆ

จาก Paper [21] ยกตัวอย่างงานวิจัย, ที่มาของชื่อ ‘Byzantine’ ว่าได้รับอิทธิพลจากกองทหารของอนาจักร ในช่วงประวัติศาสตร์ยุคช่วง 600-1400 A.C. ที่ตั้งค่ายรอบกองกำลังข้าศึก โดยแต่ละค่ายจะทำการสื่อสารกันด้วย ‘พลนำสาร’ ระหว่างผู้บัญชาการแต่ละนาย

การจะบุกข้าศึก จะทำการพร้อมกัน โดยอาศัยความเห็นร่วม .. จึงเป็นที่มาของปัญหาว่า หากมีผู้ทรยศ ส่งสารผิด หลอกลวง จะทราบได้หรือไม่ว่าเกิดความผิดพลาดขึ้นมาแล้ว .. ในกรณีนี้เขาให้ยึดว่า ความเห็นร่วมที่ตรงกัน 2 ใน 3 จะถือว่าเชื่อถือได้

จากภาพแสดงตัวอย่าง หากมีผู้ทรยศไม่เกิน 1 ใน 3 จะพอที่จะทราบได้ว่าเกิดความผิดปรกติขึ้น

Fail-stop Faults

เรียบง่ายกว่า Byzantine .. ทุก Nodes สามารถ Fail ได้ตลอดเวลา และจะสิ้นสุดการทำงาน ไม่มี Output, ไม่ติดต่อกับระบบที่เหลืออยู่, โดยที่ระบบที่เหลืออยู่ก็จะทราบว่า Node ใด Fail ด้วย

ลักษณะ Fail ของ Model นี้เกิดจาก System Node Hang – Crash .. แต่ไม่ใช่เกิดจาก RAM มีบางส่วน Fail .. ???? !!!! ???? ดูใน [32]

ใน Paper [32] อธิบายว่า Fail-stop Processor จะทำการหยุดทำงานเองทันที เมื่อตัวเอง Fail .. ไม่ต้องรอให้ระบบมาตรวจสอบ ไม่ยอมให้ระบบได้รับผลจากการทำงานของตน ไม่ยอมให้ความผิดพลาดนั้นแสดงออกมา

Fail-stutter Faults

Model แรกยากเกินไป สำหรับการนำไปประยุกต์ ส่วน Model ที่สองก็ง่ายจนในไปใช้จริงได้ลำบาก ดังนั้น Assumption ของ Model นี้ อยู่กลางๆระหว่างสอง Model ข้างต้น .. Extension ของ Fail-stop Model .. Fail-stutter Model ช่วยเรื่อง Manageability, Reliability, Plug-n-Play, Avialability

Fail-stutter ต่างจาก Fail-stop คือ

  1. แยก Performance Fault ออกจาก Correctness Fault
  2. การที่เกิด Performance Failure ในอุปกรณ์ในระบบ ไม่จำเป็นต้องรายงานให้อุปกรณ์ตัวอื่นทราบ
  3. ต้องกำหนด Performance Specification เพื่อสามารถตรวจสอบได้ว่า ณ ขณะนี้ เกิด Performance Fault ขึ้นในระบบหรือไม่

ยกตัวอย่างกรณีเกิด Failure ขึ้นกับสายสัญญาณของเครือข่าย ทำให้รับส่งข้อมูลได้ช้าลง แต่อาจจะพอทำงานได้อยู่ จะเห็นว่าไม่สามารถ Map เข้ากับ Fail-stop Fault Model ได้ .. จำเป็นต้องเป็น Fail-stutter Model แทน

3.Fault-Tolerance of Centralized Components

Cluster System ประกอบไปด้วย Compunents จำนวนมาก เชื่อมต่อเพื่อทำหน้าที่ตามที่ได้มุ่งหมาย เช่น Management Nodes: จัดการ จัดสรรค์ Job ที่ได้รับมอบให้ Node ส่วนประมวลผล, Storage Nodes: รองรับการจัดเก็บข้อมูลความจุสูง, หรือ Head Nodes: ที่หมายรวมถึง Nodes ที่ตอบสนอง ตอบโต้คำสั่งกับผู้ใช้ เป็นต้น

Components ในระบบดังที่ได้ยกตัวอย่างมีจำนวนน้อย แต่อาจเกิดความเสียหายอย่างมีนัยสำคัญ จึงอาจจะทำการ ‘เพิ่ม’ กระบวนการเพื่อรายงานสภาพผิดปรกติ เตรียม Components สำรองพร้อมเข้าทำงานแทน ส่วน Function ที่สูญเสียไป

Replication

สร้างตัวสำรองทำซ้ำ Function ที่ต้องการให้ทนทานต่อ Fault แบ่งออกได้สองรูปแบบ (สังเกตุตามพฤติกรรมของ Replicas)

  • Active Replication

ทำการสร้างตัวสำรอง (ทาง H/W) ที่รับ Input ทั้งหมดเหมือนของตัวจริง และทำงานด้วย Functionเดียวกัน โดยที่ในสภาวะปรกติ จะตรวจสอบดูว่า Component ตัวจริงทำงานได้ถูกต้องดีอยู่หรือไม่ หากเกิดเหตุการณ์ที่แสดงว่าเกิดข้อผิดพลาดในตัวจริง, Component สำรองจำแต่งตั้งตัวเองขึ้นเป็น Component หลัก เข้ารับผิดชอบ Function การทำงานทั้งหมด (หรือบางส่วนเฉพาะที่สำคัญ)

การที่มี Active Component เสียหายก็จะหยุดทำงานไป สามารถเปรียบได้กับ Fail-stop: Fault Model

วิธีการดังกล่าว อาจไม่เกิดขึ้นใน Component ที่เป็น Computer Node เพราะต้นทุนค่าใช้จ่ายจะสูง แต่อย่างไรก็ดีบางครั้ง ถ้าจำเป็น อาจเป็นได้ว่าทำการ Replicate สร้างตัวสำรอง (Backup) มากกว่าหนึ่ง, ทุกตัวมี Input เหมือนกัน, ซึ่งผล Output ที่ได้จากทุกตัว จะเข้าสู่วงจรของการ Vote เพื่อตัดสินว่า Output ควรเชื่อว่าจะเป็นเท่าใด ดังนั้นจึงเปรียบวิธีการหลาย Replicas นี้ได้ว่าเป็น Bazantine: Fault Model

  • Passive Replication

“Cold Spare” หรือเครื่องที่จะเข้าทำงานแทน เครื่องหลัก อยู่ใน Mode Idel หรือ Power Off, จะเข้าทำหน้าที่แทนได้ก็ต่อเมื่อเกิดปัญหาขึ้นกับเครื่องจริง ซึ่งด้วยเหตุนี้ อาจส่งผลให้เกิดสภาวะการทำงานของระบบ หยุดชงัก ระหว่างการสลับเข้ารับตำแหน่ง, ยกเว้นเสียแต่ว่า จะมีการ Implement Checkpoint & Roll Back เพื่อเข้าทำงานแทนกัน .. แต่ก็ไม่เหมาะกับเครื่องที่มีความซับซ้อนของ State ภายใน .. มักเหมาะกับเครื่องที่มี State ไม่มาก (ตื่นเร็ว นอนเร็ว) เช่น เครื่องที่ทำงาน Monitoring ระบบอย่างเดียว

ในบางกรณีสามารถเลือกให้ Redundant ได้เฉพาะบาง Hardware ของเครื่อง ทำการเปลี่ยนเมื่อเกิดเสีย (ทั้งโดยปิดก่อน หรือ Hot-swap) เช่น RAMs, SCSI HDDs, CPUs, etc.

Reliable Communication

สำหรับ Active Replication ในระบบที่ Components เชื่อมโยงด้วยระบบเครือข่าย ต้องการ Protocol พิเศษเพื่อ Multicast สถานะของ Component ใดใดให้กับ Centralized Nodes ทราบ โดยจะขอยกตัวอย่างดังนี้

  • แบบแรก: Multicast Protocol ที่เป็นแบบ Token-Based, อาศัยการส่งต่อ “Virtual Token” กันเป็นทอด จาก Node หนึ่งสู่ Node หนึ่งไล่กันไป, ซึ่งแต่ละครั้งของการส่ง Token จะมีการปรับเลขลำดับระบุใน Token, ดังนั้นหากมีการสูญหายของ Token จะทำให้ Node ที่ได้รับข้อมูลที่ผิดลำดับร้องขอ Token Sequence ที่หายไป
    วิธีนี้สามารถนำไปประยุกต์ใช้กับ Multiple Ring ได้ กล่าวคือหากจำเป็นต้องมีการผ่าน Token จาก Ring หนึ่งสู่อีก Ring หนึ่ง จะให้มี “Gate Keeper Node” ทำการสลับ Seq NO ใหม่, ด้วยการอาศัย Time Stamp ในแต่ละ Token เองเป็นตัวเปรียบเทียบว่า หาก Token จาก Ring A ไปสู่ Ring B ต้องเปลี่ยน Seq NO ใหม่เป็นเลขอะไร
  • แบบที่สอง: วิธีนี้ที่แยก “Multicast Atomicity” จาก “Multicast Reliability”, โดยอาศัย “Sequencer Node” สามารถทำได้หนึ่งในสองวิธี กล่าวคือ วิธีแรกจะให้ทุก Message ส่งตรงไปยัง Seq Node ทั้งหมด จากนั้นหากมี Nodes ใดบ้างที่ควรได้รับ Message, Seq Node จะทำการส่ง Message นั้นไปยังผู้ที่ต้องได้รับทั้งหมด, ในกรณีนี้ Seq Node เป็นผู้กำหนด Seq No ของ Message เพื่อให้ทุก Node ที่ได้รับ Message สามารถตรวจสอบความถูกต้องได้
    วิธีที่สองจะให้ผู้ที่ต้องการส่ง Multicast [Message แรก] ไปยังทุก Nodes ที่ต้องได้รับ รวมถึงส่งไปยัง Sequencer Node ด้วย, จากนั้น Seq Node จะทำการ Multicast [Message ที่สอง] ไปยัง Nodes ที่ Message แรกส่งไป (ข้อมูลซ้ำเดิมแต่เปลี่ยน Seq No), ทำให้ Nodes ทุก Node ที่ได้รับ Message สามารถตรวจสอบความถูกต้องของ Link ได้ โดยดูจากลำดับที่ถูกต้องของ Message .. กรรมวิธีนี้ใช้ Byzantine Agreement Protocol เพื่อยืนยันว่าผู้รับทุกคนจะได้รับ Message เดียวกัน

Monitoring

สำหรับระบบที่มีการปลุกให้ Replica ขึ้นมาทำงานแทนอัตโนมัตเมื่อ Component หยุดทำงานจำเป็นต้องมีการ Monitor การทำงานของ Component หลักอยู่เสมอ ซึ่งมีวิธีการดังต่อไปนี้

  • Heartbeat System: โดย Component จะส่ง Message ไปบอก Monitoring Node เป็นระยะ หากเมื่อครบกำหนดเวลาแล้วไม่ได้รับ Message แสดงว่า Component นั้น Fail .. เห็นได้ว่าเป็นเหมาะกับ Component ที่ทำงานแบบ Fail-stop Model .. ยิ่งกว่านี้สามารถ Implove ให้การทำ Heartbeat ส่งแบบ Broadcast ทั้งระบบ (หากมี Monitor หลายตัว หรือเพื่อกำจัด Single-point of Failure ที่ Monitoring Node) หรือส่งตรงไปยัง Root ของ Hierarchy (เพื่อควบคุม Congestion) ได้อีกด้วย
  • Byzantine Consensus: คือการที่ต้อง Monitor ทั้งหมดของ Replicas Component ที่มี Input เดียวกัน จากนั้นก็ตรวจสอบผล ซึ่งก็คือผล Vote แสดงถึงการทำงานได้ถูกต้องหรือไม่ของ Component .. วิธีการนี้จะดี เมื่อต้องใช้ตรวจสอบ Byzantine Fault แต่มีค่าใช้จ่ายในการสื่อสารสูงกว่า Heartbeat แน่นอน
  • Self-consistency Check: Node จะทำงานเป็นคาบเพื่อตรวจสอบว่า Component ภายใน Node นั้น ทำงานถูกต้องหรือไม่ และสามารถให้ Nodes อื่นๆในระบบ ร่วมรับรู้รายงานการตรวจสอบนั้นได้ด้วย .. และกลับกัน หาก Node อื่น (เช่น Central Server) สงสัยลักษณะการทำงานที่ผิดปรกติใน Node ใด ก็สามารถสั่งให้ Node ดังกล่าวตรวจสอบอุปกรณ์ภายในตนเองได้อีกด้วย

Software Engineering

การออกแบบ Management Software เพื่อใช้ในระบบ Parallel System สามารถคำนึงถึง Fault ที่จะเกิดขึ้น ทนทานต่อ Fault และทำให้ช่วงที่ต้องหยุดทำงาน (Down Time) สั้นที่สุด โดยไม่กระทบต่อการทำงานของระบบโดยรวม

การสั่ง Restart ระบบเป็นวิธีการที่ง่ายที่สุดที่จะจัดการแก้ไขปัญหา แต่ส่งผลกระทบมากมาย วิธีหนึ่งที่ทำได้คือ การแบ่ง Software ในระบบออกเป็นส่วนเล็ก ย่อยๆ เพื่อให้ส่วนอื่นที่ยังทำงานต่อไปได้ไม่จำเป็นต้อง Restart เช่น การแบ่งแยก Web Server ออกจาก Database Server จะทำให้เมื่อต้อง Restart Web Server ก็ไม่ต้องทำกับ Database Server ทำให้ลด Down Time ลงไปได้

4.Fault-Tolerance of Parallel Applications

คุณค่าของ Parallel System ไม่อาจอยู่ที่ Management Software + Centralized Components .. แต่อยู่ที่งานที่ระบบทำ คืออยู่ที่ Parallel Application ทั้งหลาย ดังนั้นหาก Nodes โดยรอบไม่สามารถทำงานต่อไปได้ ระบบที่เหลือก็ไม่มีความหมาย

Checkpointing and Rollback Recovery

Parallel Applications จำนวนคงที่ อาศัยกระบวนการ Message-passing เพื่อ Record ข้อมูล State ของ Application เป็นช่วง ไปยังสื่อบันทึกข้อมูลที่มีเสถียรภาพภายในระบบ และเมื่อมีปัญหาขึ้น Parallel Application ก็จะขอข้อมูลดังกล่าว กลับมาทำ Rollback Recovery, Technique นี้ Assume ว่าเป็น Model แบบ Fail-stop Fault

ประเด็นเรื่อง Stable Storage ก็เป็นปัญหา เช่นว่า ควรเป็น Disk หรือ Volatile Storage, หาก Node ที่เป็น Storage ในระบบ Fail จะโอนไปยัง Node อื่นให้ทำหน้าที่แทน แล้ว Parallel Application จะทราบได้อย่างไรว่า ควร Redirection ไปยัง Node ใหม่ได้ด้วยวิธีใด

สามารถแบ่งได้เป็น 2 Categories: Checkpoint-based, Log-based

The Domino Effect

ภายหลังจากทำการ Rollback แล้ว Process ผู้รับจะได้รับ Message ที่ยังไม่ได้ส่งตาม State ของผู้ส่ง กรณีนี้ State ของผู้รับต้อง Rollback กลับไปตาม Message ที่ได้ส่งมา ผลก็คือ Application ที่เชื่อมต่อกันจะ Rollback ต่อกันแบบ Cascade อย่างไม่สามารถคาดเดาได้ => Domino Effect [30]

ทำไมเฉพาะกับ Process 3 จึงส่งผลกระทบให้ทั้งสาม ต้อง Rollback กลับไปยังจุดเริ่มต้น ?

Checkpoint-based Rollback Recovery

  • Uncoordinated (หรือ Asynchronous) แต่ละ Process จะตัดสินใจเลือก Checkpoint ของตน ด้วยตัวเอง ทำให้ลดความซับซ้อนเรื่องที่ต้องทำ Synchronization ออกไป แต่ก็ทำให้ได้รับผลร้ายเช่น ประการแรก Process จะต้องเพิ่ม Checkpoint ที่คำนึงถึงผลรวมในการทำงานเมื่อต้อง Intercommunication กับ Process อื่น ส่งผลให้เกิด Overhead ขึ้น, ประการต่อมา การใช้ Checkpoint จะส่งผลในแง่ Domino Effect และเป็นการยากจะหาจุด Recovery .. ดังนั้นงานวิจัยที่เกี่ยวข้องกับหัวข้อนี้คือ จะต้องเพิ่ม Checkpoint ที่ใดบ้าง
  • Coordinated (หรือ Synchronous) จำเป็นต้องมี Checkpoint Process เพื่อทำการเตือน Processes อื่นที่เหลือ ให้ทำการ Checkpoint พร้อมกันทันที ทำให้หลุดพ้นจากปัญหา Domino Effect และง่ายต่อการ Recovery .. แต่ก็มีความซับซ้อนเพิ่มขึ้นมาที่ Process ที่ทำหน้าที่ Synchronous ตัดสินใจทำ Global Checkpoint
  • Communication-induced (หรือ Quasi-asynchronous) แต่ละ Process จะสนใจทำ Checkpoint เมื่อคำนึงถึงผลกระทบต่อ Node เฉพาะตนเท่านั้น เหมือนกับ Uncoordinated, แต่ก็ประกอบไปด้วยกระบวนการ Message Passing ข้อมูลระหว่าง Processes ด้วยกัน ทำให้แต่ละ Process สามารถตัดสินใจได้ว่า ควรทำ Global Checkpoint ร่วมกันหรือไม่ (การตัดสินใจแบบองค์รวม) .. ดูเพิ่มเติม [14]

Log-based Rollback Recovery

“Log-based Rollback Recovery Protocol” เป็นส่วนเสริมให้กับ Checkpoint ปรกติ ด้วยการบันทึก Messages ที่มีการรับส่งโดย Processes ในระบบ, เมื่อใด Process ทำงาน Fail จะนำ Log ที่บันทึกมาใช้เพื่อระบุถึง Checkpoint ล่าสุดที่ Process ทำงาน

ข้อดีคือ สามารถเก็บ Log ได้บ่อยครั้งกว่า Checkpoint ทั่วไป และด้วยความที่เป็น Global .. ทุก Process ต่างก็ปล่อย Message ออกมา ซึ่งน่าจะมาไล่ลำดับเพื่อ Rollback ได้ที่ Node เก็บ Log .. ทำให้ไม่เกิด Domino Effect (Why ??)

Log-based เป็นระบบแบบ “Piecewise Deterministic Assumption (PWD)” คือสามารถระบุเห็นการณ์ที่ถือว่าเป็น Fail ได้ระหว่าง State .. หรือจาก Log ต้องสามารถนำกลับมาสร้าง State ใหม่ได้อีกครั้ง

  • Pessimistic Logging Techniques (Synchronous Logging) มีการเก็บ Log ลง Storage ก่อนที่จะอนุญาตให้ใช้คำนวณ ?? .. สามารถนำมาใช้ Recovery ได้ตลอดเวลา เพราะจะไม่มี Process ใดได้ผลกระทบหาก Log ยังไม่ได้บันทึก ????? .. ประโยชน์ที่ได้รับมี 2 อย่างคือ ประการแรก เมื่อเกิดการ Fail, Process ที่เหลืออยู่ จะไม่กลายเป็น “กำพร้า” และไม่ต้องทำอะไรเป็นพิเศษ ส่งผลให้ง่ายต่อ Recovery Algorithm ?? .. ประการที่สอง ระบบ Gabage Collection ของ Msg-Log และ Checkpoint นั้นเรียบง่าย โดยมีแค่เพียง Checkpoint เดียวเท่านั้นที่ต้องคงไว้สำหรับแต่ละ Process และ Log ที่เก่ากว่า Checkpoint ดังกล่าว ก็จะไม่มีการเก็บไว้อีกต่อไป
  • Optimistic Logging Techniques (Asynchronous Logging) ทำการบันทึก Log บน Volatile Storage ส่งผลให้เกิดการลดลงของ Overhead การทำงานของ Application ที่ไม่ต้องรอการเขียนข้อมูล .. แต่สิ่งที่ตามมาก็คือ ความซับซ้อนในการ Recover System เนื่องจาก Volatile Storage อาจไม่สามารถเก็บ Message ระบุสถานะได้ สูญหายทั้งหมด ทำให้ Application จำเป็นต้องสามารถ Rollback กลับมายังจุดที่ไม่จำเป็นต้องอาศัย Message ดังกล่าวได้ ????
  • Causal Logging Protocol นำเอาประโยชน์ของทั้ง Pessimistic และ Optimistic หลอมรวมเข้าด้วยกัน โดยการที่ลด Overhead ของ Optimistic โดยการ Save Log บน Volatile Storage .. แต่สิ่งที่ต้องเสียคือ จำเป็นต้องมี Recovery Techniques ที่ซับซ้อนยิ่งขึ้น

*** Volatile Storage = สื่อบันทึกที่การอ่านและเขียนเป็นแบบ Atomic .. สื่อที่ไม่มีไฟฟ้า ข้อมูลจะหาย .. หมายถึง Non-blocking ?

Virtual Processor

ทำให้ Parallel Application สามารถแบ่งส่วนออก เข้าทำงานได้ใน Virtual Processor ซึ่งสามารถกำหนดให้มีจำนวนมากกว่า Physical Process มาก แต่สิ่งที่สูญเสียไปคือ ประสิทธิภาพที่ต้องเสียกับ Overhead ในการจำลอง Processor

สามารถใช้ร่วมกับ Checkpoint & Recovery Technique ได้ดี

ตัวอย่าง Software Virtual Machine อย่างเช่น VM Ware, Virtual PC, Xen, …

5.Implementation/Packaging

.. API ที่ใช้เพื่อช่วยสร้าง Fault-Tolerant Parallel System ? .. ช่วยในแง่ Synchronization (ระหว่าง Nodes) .. ??

.. อาศัยการติดตั้ง System Middleware Infrastructure of System ????

.. อาศัยการสอดแทรก Preprocessor ใน Source Code ซึ่งส่งผลให้ Compiler แทรกคำสั่งเพื่อทำการ Checkpoint เข้าไป โดยสามารถทำได้ทั้งแบบ Manual (Programer เป็นผู้ตัดสินใจ) หรือทั้งแบบ Automatic (Compiler จัดการให้เอง)

6.Conclusions (อ่านหัวข้อนี้ก่อน Clear สุด)

เป็น Paper ที่ Overview การทำ Fault-Tolerance Techniques ใน Large Scale Cluster Computing System จัดกลุ่มได้เป็น

  • Protection สำหรับ Cluster Management Hardware และ Software Infrastructure
  • Protection สำหรับ Computation Nodes และ Long-running Applications ที่ Excute บน Nodes นั้นๆ

Cluster Management Hardware และ Software Fault-Tolerance โดยปรกติจะใช้วิธีการ Redundancy ด้วนเนื่องจาก จำนวนของ Components ที่จำเป็นต้องทำซ้ำ ไม่มากมายอะไร จึงให้ส่วน Redundancy รับผิดชอบงานแทน หากเกิดความผิดปรกติขึ้น .. ยิ่งกว่านั้น ยังสามารถทำกระบวนการ Fault-Detection โดยเปรียบเทียบ Output ในแต่ละ Replicas เพื่อหาข้อขัดแย้งอีกด้วย

Cluster Application ถูกป้องกันได้ด้วยวิธี Checkpointing and Rollback Recovery Techniques โดยแต่ละ Process จะทำการบันทึก Checkpoint ของตนเองตามคาบเวลาที่กำหนด ลงในสื่อเก็บข้อมูลที่เชื่อถือได้ ซึ่งเมื่อเกิดปัญหากับ Process ก็จะสามารถนำกลับ Checkpoint ที่ได้ทำการบันทึกล่าสุดนั้น มาทำงานต่อไปได้ .. ส่งที่น่าสนใจคือ ข้อกำหนดเรื่องเวลา ว่าเมื่อใดควรทำการเก็บ Checkpoint และเมื่อใดควรทำการ Rollback กลับมาใช้

Fault-Tolerance Solutions สามารถนำมา Implement ให้เกิดผลในทางปฏิบัติจริงได้ ในหลากหลายรูปแบบ ทั้งการมี Software Libraries ให้เรียกใช้งาน, การสร้าง Programming Language พิเศษ, การแก้ไข Compiler – เพิ่มเติม Preprocessor, เพิ่มส่วนขยายความสามารถให้กับ Operating System, และท้ายที่สุดรวมถึงการติดตั้งระบบ Middleware .. ทั้งหมดที่กล่าวมานี้มีข้อดีและข้อเสีย ที่ต้อง Tradeoff – ต้องคำนึงถึงทั้งในแง่พลังงาน, Portability, และอื่นๆ

7.Reference

asdf

Advertisements
มาตรฐาน

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s