Red Hat ลดค่าใช้จ่ายฮาร์ดแวร์ Edge ด้วยโครงสร้างสองเซิร์ฟเวอร์ ไม่ต้องใช้มินี‑PC

Red Hat ได้ประกาศแนวทางใหม่เพื่อลดจำนวนเซิร์ฟเวอร์ที่ต้องใช้ในโครงสร้างแบบ high‑availability edge ของแพลตฟอร์ม OpenShift เนื่องจากต้นทุนฮาร์ดแวร์ที่เพิ่มสูงขึ้นอย่างต่อเนื่อง การปรับโทโพโลยีเป็นสองเครื่องจึงกลายเป็นตัวเลือกสำคัญสำหรับองค์กรที่ต้องการความเสถียรโดยไม่ต้องลงทุนในอุปกรณ์ mini‑PC เพิ่มเติม

Overview

Red Hat แสดงความกังวลเกี่ยวกับค่าใช้จ่ายของฮาร์ดแวร์ในการเปิดใช้งาน OpenShift ที่ตำแหน่งขอบเครือข่าย (edge) โดยเฉพาะเมื่อผู้ใช้งานต้องการระบบที่พร้อมทำงานตลอดเวลา ทีมจาก IBM Business Unit ของ Red Hat ได้แก่ Daniel Froehlich และ Paul Lancaster ได้อธิบายว่าการเพิ่มโหนดที่สามในหลายพันหรือหลายหมื่นไซต์ทำให้ค่าใช้จ่ายในการจัดหาไฟฟ้า, การบำรุงรักษาและการติดตั้งสูงเกินกว่าจะรับได้ นอกจากนี้ราคาฮาร์ดแวร์ที่พุ่งขึ้นอย่างรวดเร็วในช่วงไม่กี่เดือนที่ผ่านมา ทำให้ความต้องการโซลูชันแบบสองโหนดเพิ่มมากขึ้นเป็นอย่างชัดเจน

Technical Approach

Red Hat มีวิธีใช้ arbiter เป็นอุปกรณ์เสริมเพื่อรักษา quorum ระหว่างสองโหนดหลักของ OpenShift ก่อนหน้านี้ arbiter ต้องมีสเปคพื้นฐานดังต่อไปนี้:

• อย่างน้อย 2 virtual CPUs
• 8 GB RAM
• พื้นที่จัดเก็บแบบ SSD ขนาด 50 GB

arbiter ทำหน้าที่ป้องกันสถานการณ์ split‑brain ซึ่งเกิดเมื่อโหนดสองเครื่องสูญเสียการเชื่อมต่อและแต่ละเครื่องพยายามทำหน้าที่เป็นหัวข้อหลักพร้อมเขียนข้อมูลซ้ำกัน การใช้ arbiter จึงช่วยกำหนดว่าโหนดใดจะเป็น “cluster boss” อย่างชัดเจน

อย่างไรก็ตาม Red Hat พบว่าค่าใช้จ่ายและความซับซ้อนของการจัดหาอุปกรณ์ arbiter เองก็เริ่มกลายเป็นอุปสรรคต่อการนำไปใช้งานที่ขนาดเล็ก ดังนั้นทีมพัฒนาจึงปรับเทคนิคจาก Red Hat Enterprise Linux High Availability Add‑On โดยใช้ส่วนประกอบหลักคือ Corosync และ Pacemaker เพื่อทำระบบ fencing แทนการพึ่งพา arbiter

Fencing Mechanism

ฟังก์ชัน fencing ทำงานโดยบังคับให้โหนดที่เหลืออยู่ “ปิดเครื่อง” หรือ “รีบูต” โหนดที่ล้มเหลวหรือขาดการเชื่อมต่ออย่างแข็งขัน ผ่านคำสั่งจาก Pacemaker หากโหนดหนึ่งสูญเสียการเชื่อมต่อ Corosync จะประกาศสถานะเป็นความล้มเหลวโดยอัตโนมัติ แม้ว่าโหนดนั้นอาจยังทำงานได้อยู่ แต่ Pacemaker จะพิจารณาโหนดดังกล่าวว่า “ตายอย่างถาวร” และรับหน้าที่ทั้งหมดของคลัสเตอร์ การดำเนินการเช่นนี้ช่วยขจัดความเสี่ยงของ split‑brain อย่างมีประสิทธิภาพ

เพื่อให้ฟังก์ชัน fencing ทำงานได้ จำเป็นต้องมี Baseboard Management Controller (BMC) ที่รองรับ Redfish API** ซึ่งทำหน้าที่ส่งคำสั่งควบคุมพลังงานจากระยะไกล หากไม่มี BMC ที่สนับสนุน Redfish การจัดการแบบอัตโนมัติจะไม่สามารถใช้งานได้และต้องอาศัยขั้นตอนมือมนุษย์เพิ่มขึ้น

Limitations & Challenges

แม้ระบบสองโหนดจะลดจำนวนฮาร์ดแวร์ลงอย่างมาก แต่ Red Hat ยังคงระบุข้อจำกัดหลายประการ โหนดหนึ่งที่ฟื้นตัวหลังจากไฟฟ้ากลับมาทำงานอาจทำให้คลัสเตอร์สูญเสียความสอดคล้อง (consistency) เนื่องจาก Pacemaker ไม่สามารถรับประกันได้ว่าข้อมูลจะถูกซิงโครไนซ์อย่างสมบูรณ์ในกรณีดังกล่าว นอกจากนี้ หากทั้งสองโหนดล้มเหลวพร้อมกันและมีเพียงหนึ่งโหนดที่รีสตาร์ท ระบบอาจต้องการการแทรกแซงจากผู้ดูแลเพื่อทำการตรวจสอบและคืนค่าการทำงานให้กลับมาปกติ

ข้อจำกัดนี้เป็นประเด็นสำคัญสำหรับการใช้งานในสภาพแวดล้อม edge ที่มักมีพลังไฟฟ้าไม่เสถียรหรืออาจเกิดเหตุการณ์ดับไฟหลายครั้งต่อวัน การต้องพึ่งพา BMC ที่รองรับ Redfish ยังเพิ่มความซับซ้อนในการเลือกฮาร์ดแวร์ให้เหมาะสมกับแต่ละสถานที่

Market Implications

ผู้เชี่ยวชาญด้าน edge computing คาดว่าการใช้งาน hardware inferencing เช่น ระบบวิเคราะห์วิดีโอแบบเรียลไทม์ในร้านค้าปลีกหรือศูนย์กระจายสินค้าจะยังคงต้องการฮาร์ดแวร์ที่มีประสิทธิภาพสูง แม้ว่าตลาดอุปกรณ์จะเผชิญกับราคาที่เพิ่มขึ้น การปรับโครงสร้างให้ใช้สองเครื่องแทนสามเครื่องช่วยลดค่า CAPEX (capital expenditure) อย่างมีนัยสำคัญ

ยิ่งไปกว่านั้น OpenShift ที่รองรับ OpenShift Virtualization ทำให้ผู้ประกอบการสามารถรันเวอร์ช่วลได้นบนโหนดเดียวกันได้ ส่งผลให้แพลตฟอร์มของ Red Hat กลายเป็นคู่แข่งที่มีศักยภาพต่อ VMware ในตลาด edge ที่ต้องการความคล่องตัวและการจัดการทรัพยากรแบบรวมศูนย์

Summary

Red Hat เสนอแนวทางสอง‑node สำหรับ OpenShift ที่ลดความจำเป็นของอุปกรณ์ arbiter และใช้เทคนิค fencing ผ่าน Corosync/Pacemaker เพื่อลดต้นทุนฮาร์ดแวร์ใน edge deployments แม้จะยังมีข้อจำกัดเรื่องการฟื้นตัวและความต้องการ BMC รองรับ Redfish แต่แนวทางนี้เปิดโอกาสให้ผู้ใช้งานปรับสเกลระบบได้อย่างคุ้มค่าและเพิ่มการแข่งขันต่อผู้ให้บริการคลาวด์เดิม.