คุณสมบัติความพร้อมใช้งานสูง (HA)

ฟังก์ชันความพร้อมใช้งานสูง (High Availability) เป็นฟังก์ชันที่ “รีสตาร์ท” อัตโนมัติ (เรียกว่า failover) เครื่องเสมือนบนโฮสต์ที่ทำงานปกติอื่นเมื่อโฮสต์ทางกายภาพล้มเหลว ดังนั้น จำเป็นต้องเตรียมการล่วงหน้าภายในระบบปฏิบัติการของเครื่องเสมือนเพื่อให้ระบบสามารถกู้คืนได้โดยอัตโนมัติ

เงื่อนไขในการใช้ HA มีอะไรบ้าง?

เพื่อใช้ HA กับเวอร์ชัน HRPC KVM ต้องมีเงื่อนไขต่อไปนี้:

1. ศูนย์ข้อมูลเสมือนที่ประกอบด้วยโหนดที่มีการกำหนดค่าเหมือนกันสามโหนดหรือมากกว่า
2. ต้องเป็นประเภท HCI หรือประเภท 3-tier เนื่องจากต้องการที่เก็บข้อมูลแบบแชร์ (Ceph, ESF with ES)
3. ต้องมีหน่วยความจำสำรองเพียงพอ (โดยเฉพาะหน่วยความจำ) บนอุปกรณ์ จำเป็นอย่างยิ่งที่หน่วยความจำอย่างน้อยหนึ่งโหนดต้องว่างทั้งหมด
   *ตัวอย่างเช่น ในกรณีของศูนย์ข้อมูลเสมือนที่มีสามโหนด ควรใช้หน่วยความจำของสองโหนดเท่านั้นรวมกัน
4. ตรวจสอบให้แน่ใจว่าได้สำรองข้อมูลของเครื่องเสมือน
   เราขอแนะนำอย่างยิ่งให้คุณทำสัญญากับ Backup Storage หรือบริการที่คล้ายกัน และตั้งค่าการสำรองข้อมูลเครื่องเสมือนเป็นประจำ

วิธีเปิดใช้งานฟังก์ชัน HA?

หากคุณต้องการเปิดใช้งานฟังก์ชัน HA ก่อนอื่นให้เลือก datacenter ในแผงด้านซ้าย เปิด HA ในแผงกลาง และคลิก Group

คลิกปุ่ม Create ในแผงด้านขวา สร้าง ID กลุ่ม HA และตรวจสอบโฮสต์ที่เกี่ยวข้องกับ HA เมื่อสร้างเครื่องเสมือนบนโฮสต์ที่เกี่ยวข้องกับ HA คุณต้องเตรียมหน่วยความจำสำรองอย่างน้อยเท่ากับโฮสต์กายภาพหนึ่งเครื่อง หากคุณเข้าร่วม HA ด้วย HRPC สี่เครื่องที่มีหน่วยความจำ 768GB เครื่องที่เหลือสามเครื่องจะต้องมีหน่วยความจำว่าง 768GB เพื่อให้อุปกรณ์อื่น ๆ สามารถทำงานต่อไปได้แม้ว่า HRPC หนึ่งเครื่องจะเกิดความล้มเหลวทางกายภาพ หากคุณไม่เลือกกลุ่ม HA มันจะถูกละเลยในฐานะเป้าหมาย HA แม้ว่าจะอยู่ในศูนย์ข้อมูลเดียวกัน

หากโฮสต์ถูกถอนออกจากกลุ่ม HA โดยเจตนา และตั้งค่ากลุ่ม HA เป็น “restricted” เครื่องเสมือนที่อยู่ในกลุ่ม HA นั้นจะไม่สามารถเริ่มต้นบนโฮสต์ที่ถูกถอนออกได้

หากเลือก nofailback เมื่อโหนดทางกายภาพที่ล้มเหลวรีบูตและกลับมา เครื่องเสมือนจะไม่ถูกกู้คืน แต่จะยังคงทำงานที่ปลายทางต่อไป หากไม่เลือก nofailback เครื่องเสมือนจะถูกส่งกลับไปยังโหนดดั้งเดิมโดยการย้ายแบบสด (live migration) ซึ่งช่วยให้สามารถจัดการตำแหน่งของโฮสต์โหนดและเครื่องเสมือนได้อย่างเข้มงวด อย่างไรก็ตาม หากโหนดทางกายภาพไม่เสถียรและถูกรีบูตซ้ำ ๆ HA จะถูกเปิดใช้งานอีกครั้งและเครื่องเสมือนจะถูกรีสตาร์ทซ้ำ ๆ ด้วยเหตุนี้ เราขอแนะนำให้เลือก nofailback

นอกจากนี้ แม้ว่าการย้ายแบบสด (live migration) จะเป็นฟีเจอร์ที่ล้มเหลวได้ยาก แต่จะมีการหยุดชะงักภายในชั่วขณะที่อาจก่อให้เกิดปัญหาในซอฟต์แวร์เรียลไทม์

วิธีเปิดใช้งาน HA สำหรับเครื่องเสมือน?

Proxmox HA จะไม่สามารถใช้งานได้เว้นแต่เครื่องเสมือนจะอยู่ภายใต้การจัดการ HA

เพื่อให้เครื่องเสมือนอยู่ภายใต้การจัดการ HA ให้เลือกเครื่องเสมือนและเลือก “Manage HA” จากเมนูแบบดึงลง “More▼” ที่มุมขวาบน เลือก ID ของกลุ่ม HA ที่คุณกำหนดค่าข้างต้นจากกลุ่ม ตั้งค่าสถานะที่ต้องการเป็น started แล้วคลิกปุ่ม Add

เครื่องเสมือนนี้อยู่ภายใต้การควบคุม HA แล้ว

ขอบเขตการทำงานของ HA จะแตกต่างกันไปตาม hypervisor ใน VMware เมื่อเปิดใช้งาน HA ในศูนย์ข้อมูลเสมือน มันจะมีผลต่อเครื่องเสมือนทั้งหมดในศูนย์ข้อมูลเสมือน ในขณะที่ใน XenOrchestra มันจะมีผลเฉพาะกับเครื่องเสมือนในพูลที่เปิดใช้งาน HA และตั้งค่าเป็น “restart”

ความสัมพันธ์ระหว่างการรีสตาร์ทเพื่อบำรุงรักษาของโหนด (โฮสต์) ในกลุ่ม HA และเครื่องเสมือน

เมื่อโหนดที่เป็นส่วนหนึ่งของกลุ่ม HA ถูกรีบูตเพื่อการบำรุงรักษา (ไม่ใช่เนื่องจากความล้มเหลวที่ไม่คาดคิด) พฤติกรรมของเครื่องเสมือนจะแตกต่างกันไปขึ้นอยู่กับว่าเครื่องเสมือนนั้นอยู่ภายใต้การจัดการ HA หรือไม่

เครื่องเสมือนที่อยู่ภายใต้การจัดการ HA	ย้ายแบบสด (Live migration) ไปยังเครื่องอื่น
เครื่องเสมือนที่ไม่ได้อยู่ภายใต้การจัดการ HA	ปิดเครื่องอัตโนมัติและยังคงปิดอยู่หลังจากรีบูต

คอลัมน์

ข้อจำกัดของฟังก์ชัน HA

ฟังก์ชัน HA มีข้อจำกัด และมีปัญหาที่อาจเกิดขึ้นเมื่อใช้ HA

1. การรีสตาร์ทเครื่องเสมือนโดยไม่คาดคิด
2. ข้อมูลเครื่องเสมือนเสียหาย

พูดง่าย ๆ HA คือความสามารถในการเริ่มเครื่องเสมือนจากโหนดอื่นเมื่อโหนดล้มเหลว แต่นี่คือวิธีการทำงานจากมุมมองของผู้ดูแลระบบ และตรรกะของซอฟต์แวร์จริง ๆ จะต้องถูกนำไปใช้ในวิธีที่แตกต่างกันโดยสิ้นเชิง

ประการแรก ไม่สามารถกำหนดได้อย่างเข้มงวดว่า “ความล้มเหลว” ในโหนดใดโหนดหนึ่งจากทั้งสามโหนด (เช่น โหนด A, โหนด B และโหนด C) คืออะไร HA เกิดขึ้นได้โดยการให้แต่ละโหนดทำงานร่วมกัน

เมื่อโหนด A สูญเสียการสื่อสารกับโหนด B ไม่ชัดเจนว่าความล้มเหลวเกิดขึ้นในโหนด B หรือการสื่อสารระหว่างโหนด A และโหนด B สูญเสียไป หากโหนด A สามารถสื่อสารกับโหนด C ได้จากมุมมองของมัน เป็นไปได้ว่าความล้มเหลวอาจเกิดขึ้นในโหนด B

อย่างไรก็ตาม หากข้อมูลของเครื่องเสมือนที่โฮสต์บนโหนด B ถูกอัปเดตอย่างต่อเนื่องบนที่เก็บข้อมูลแบบแชร์ โหนด B อาจถูกแยกออกอย่างสมบูรณ์

ในตัวอย่างข้างต้น หากโหนด A และ C สามารถสื่อสารกันได้ มีความเป็นไปได้สูงว่าโหนด B ล้มเหลว ดังนั้น โหนด A และ C จะพยายามบูตเครื่องเสมือนที่โฮสต์บนโหนด B ด้วยตัวเอง

อย่างไรก็ตาม โหนด B อาจไม่ได้ล้มเหลว แต่อาจถูกแยกออกเท่านั้น หากโหนดตัดสินใจว่าตัวเองถูกแยกออก มันจะปิดเครื่องเสมือนที่โฮสต์ทันทีเพื่อเตรียมพร้อมสำหรับโหนด A และ C ที่อาจเริ่มต้นขึ้น ซึ่งเป็นสาเหตุของการรีบูตที่ไม่คาดคิดที่กล่าวถึงข้างต้น

แล้วจะเกิดอะไรขึ้นหากโหนด B ไม่ปิดเครื่อง?

หากเครื่องเสมือนเดียวกันทำงานในสองที่ คือโหนด B และโหนดอื่น ดิสก์เสมือนของเครื่องเสมือนจะเสียหายในทันที ซึ่งจะนำไปสู่การทำลายข้อมูลของเครื่องเสมือนที่กล่าวถึงข้างต้น

ดังนั้น ทางเลือกของคุณคือรีบูตหรือทำลายข้อมูลของคุณ

HA จำเป็นต้องประสานงานระหว่างแต่ละโหนดเพื่อตัดสินใจว่าโหนดนั้นล้มเหลว สูญเสียการสื่อสาร หรือช้า

หากความล้มเหลวทั้งสองข้างต้นไม่สามารถเกิดขึ้นพร้อมกันได้ สิ่งที่คุณต้องการหลีกเลี่ยงคือข้อมูลเสียหาย ดังนั้นให้ปิดเครื่องทันที

การตัดสินใจนี้เกิดขึ้นเป็นระยะ ๆ และ Proxmox ทำทุก 2 นาที หากไม่มีการตอบสนองเป็นเวลา 2 นาที จะถูกตัดสินว่า “โฮสต์ล้มเหลว” ดังนั้น อย่างน้อยที่สุด ระยะเวลาหยุดทำงานจะเป็น 2 นาที + เวลาที่เครื่องเสมือนใช้ในการบูต (ในความเป็นจริงจะนานกว่านั้น)

อย่างไรก็ตาม หากความเร็วของโหนดช้าลง หน่วยความจำถูกสลับออก การกู้คืนหน่วยความจำโดยไดรเวอร์ ballooning ทำให้เกิดการชะลอตัวชั่วคราว หรือการเขียนที่เก็บข้อมูลช้าลง สองนาทีอาจผ่านไปอย่างรวดเร็วและอาจไม่สามารถปิดเครื่องได้ทันเวลา เนื่องจากสิ่งที่ต้องปกป้องคือข้อมูล ระบบจะใช้ WatchDog Timer หรือสิ่งที่คล้ายกันโดยอัตโนมัติ และคลาวด์ส่วนตัวทำงานบนฮาร์ดแวร์ที่มีอุปกรณ์ที่สามารถรีสตาร์ทเคอร์เนลได้อัตโนมัติแม้ว่าเคอร์เนลของโฮสต์จะหยุดตอบสนอง