ตามที่เราได้พูดคุยกันใน ความพร้อมใช้งานสูง สภาพแวดล้อมคลัสเตอร์ มีโหนดที่ใช้งานอยู่หนึ่งโหนดและโหนดสแตนด์บายอย่างน้อยหนึ่งโหนดที่จะเข้ารับบริการเมื่อโหนดที่ใช้งานอยู่ล้มเหลวหรือหยุดตอบสนอง

ฟังดูเหมือนเป็นข้อสันนิษฐานที่สมเหตุสมผลจนกว่าจะพิจารณาชั้นเครือข่ายระหว่างโหนด จะเกิดอะไรขึ้นหากเส้นทางเครือข่ายระหว่างโหนดหยุดทำงาน

ขณะนี้โหนดทั้งสองไม่สามารถสื่อสารกับโหนดอื่นได้ และในสถานการณ์นี้ เซิร์ฟเวอร์สำรองอาจเลื่อนระดับตัวเองให้เป็นเซิร์ฟเวอร์ที่ใช้งานอยู่บนพื้นฐานที่เชื่อว่าโหนดที่ใช้งานอยู่ล้มเหลว ส่งผลให้ทั้งสองโหนดกลายเป็น 'ใช้งาน' เนื่องจากแต่ละโหนดจะเห็นว่าโหนดอื่นตาย ด้วยเหตุนี้ ความสมบูรณ์ของข้อมูลและความสอดคล้องกันจึงถูกบุกรุก เนื่องจากข้อมูลบนโหนดทั้งสองจะมีการเปลี่ยนแปลง นี้เรียกว่า “แยกสมอง” .

เพื่อหลีกเลี่ยงสถานการณ์สมองแตก ควรติดตั้งโหนด Quorum (เรียกอีกอย่างว่า 'พยาน') ภายในคลัสเตอร์ การเพิ่มโหนดควอรัม (ไปยังคลัสเตอร์ที่ประกอบด้วยโหนดจำนวนคู่) จะสร้างโหนดจำนวนคี่ (3, 5, 7 ฯลฯ ) โดยโหนดลงคะแนนเพื่อตัดสินใจว่าควรทำหน้าที่เป็นโหนดที่ใช้งานอยู่ภายในคลัสเตอร์

ในตัวอย่างด้านล่าง ชั้นวางเซิร์ฟเวอร์ที่มีโหนด B หายไป LAN การเชื่อมต่อ ในสถานการณ์สมมตินี้ โดยการเพิ่มโหนดที่ 3 เข้ากับสภาพแวดล้อมคลัสเตอร์ ระบบยังสามารถระบุได้ว่าโหนดใดควรเป็นโหนดที่ทำงานอยู่

ฟังก์ชัน Quorum/Witness รวมอยู่ใน SIOS ชุดป้องกัน เมื่อทำการติดตั้ง Quorum / Witness จะถูกเลือกบนโหนดทั้งหมด (ไม่ใช่เฉพาะโหนดควอรัม) และกำหนดเส้นทางการสื่อสารระหว่างโหนดทั้งหมด (รวมถึงโหนดควอรัมด้วย)

โหนดควอรัมไม่ได้โฮสต์บริการใดๆ ที่ใช้งานอยู่ บทบาทเดียวของมันคือการมีส่วนร่วมในการสื่อสารโหนดเพื่อตรวจสอบว่ามีการใช้งานใดอยู่และเพื่อให้ 'การลงคะแนนแบบผูกขาด' ในกรณีที่การสื่อสารหยุดชะงัก

SIOS ยังรองรับ IO การฟันดาบและการจัดเก็บ เป็นอุปกรณ์ควอรัม และในการตั้งค่าคอนฟิกเหล่านี้ โหนดควอรัมเพิ่มเติมไม่จำเป็น

ตามที่กล่าวไว้ก่อนหน้านี้ เมื่อ a คลัสเตอร์ความพร้อมใช้งานสูง ได้รับการกำหนดค่าแล้ว สองโหนดขึ้นไปทำงานพร้อมกันและผู้ใช้เชื่อมต่อกับ โหนด "ใช้งานอยู่" . เมื่อเกิดปัญหากับโหนดที่ใช้งานอยู่ จะเกิดสภาวะ "เฟลโอเวอร์" และโหนด "สแตนด์บาย" จะกลายเป็นโหนด "แอ็คทีฟ" ใหม่ เมื่อเกิดข้อผิดพลาดขึ้น จะต้องมีกลไกที่ยอมให้ไคลเอ็นต์ตรวจหาเงื่อนไขเฟลโอเวอร์และเชื่อมต่อใหม่ หรือโอนเซสชันไคลเอ็นต์ที่ใช้งานอยู่ของผู้ใช้ไปยังโหนดที่ใช้งานอยู่ได้อย่างราบรื่น

ที่อยู่ IP เสมือน

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

ตัวอย่างเช่น สมมติว่ามีสองโหนดคือ A และ B โดยมีที่อยู่ IP ของ 10.20.1.10 และ 10.20.2.10 . ในตัวอย่างนี้ เราจะกำหนดที่อยู่ IP เสมือนเป็น 10.20.0.10 ซึ่งควรพิจารณาให้กำหนดให้กับโหนดที่ใช้งานอยู่ในปัจจุบัน

ซึ่งคล้ายกับการกำหนดที่อยู่ IP ที่สองให้กับการ์ดอินเทอร์เฟซเครือข่ายหนึ่งใบบนโหนดเดียว ถ้าคำสั่ง ip a ถูกป้อนบนโหนดที่ใช้งานอยู่ ที่อยู่ IP ทั้งสองจะปรากฏขึ้น (ดังในบรรทัดที่ 10 และ 12 ในตัวอย่าง Linux นี้):

ดิ ARP มาตรการ

เมื่อไคลเอนต์พยายามค้นหาเซิร์ฟเวอร์โดยใช้ที่อยู่ IP ไคลเอนต์มักจะใช้ ARP (Address Resolution Protocol) เพื่อค้นหา MAC (Media Access Control) ที่อยู่ของเครื่องเป้าหมาย

เมื่อไคลเอนต์กระจายข้อความเพื่อค้นหาที่อยู่ IP เป้าหมาย โหนดที่ทำงานอยู่จะตอบกลับด้วย MAC ที่อยู่และลูกค้าแก้ไขคำขอและเชื่อมต่อกับมัน

ARP ทางเลือกอื่นสำหรับสภาพแวดล้อมคลาวด์

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

• AWS สถานการณ์ตารางเส้นทาง

• AWS สถานการณ์ IP แบบยืดหยุ่น

• AWS เส้นทาง 53 สถานการณ์

• สถานการณ์จำลองโหลดบาลานซ์ภายในของ Azure

• สถานการณ์จำลองการโหลดบาลานซ์ภายในของ Google Cloud