ตามที่กล่าวไว้ก่อนหน้านี้ เมื่อ 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

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

โดยทั่วไป Availability Zone จะคล้ายกับศูนย์ข้อมูล (ตำแหน่งทางกายภาพ) อย่างน้อยหนึ่งแห่งซึ่งตั้งอยู่ในภูมิภาคทางกายภาพเดียวกัน (เช่น ในแคลิฟอร์เนีย) ศูนย์ข้อมูลเหล่านี้อาจตั้งอยู่ในพื้นที่ต่างๆ แต่เชื่อมต่อโดยใช้เครือข่ายความเร็วสูงเพื่อลดเวลาแฝงในการเชื่อมต่อระหว่างกัน (โปรดทราบว่าบริการโฮสติ้งในศูนย์ข้อมูลหลายแห่งภายในขอบเขตความพร้อมใช้งานควรมีความโปร่งใสต่อผู้ใช้)

ตามกฎทั่วไป ยิ่งระยะห่างทางกายภาพระหว่างปริมาณงานมากเท่าใด สภาพแวดล้อมก็จะยิ่งมีความยืดหยุ่นมากขึ้นเท่านั้น เป็นสมมติฐานที่สมเหตุสมผลว่าภัยธรรมชาติ เช่น แผ่นดินไหว จะไม่ส่งผลกระทบต่อภูมิภาคต่างๆ ในเวลาเดียวกัน (เช่น ทั้งชายฝั่งตะวันตกของสหรัฐฯ และชายฝั่งตะวันออกในเวลาเดียวกัน) อย่างไรก็ตาม ยังคงมีโอกาสประสบกับความขัดข้องของบริการในภูมิภาคต่างๆ พร้อมกัน เนื่องจากความล้มเหลวทั่วทั้งระบบ (ผู้ให้บริการคลาวด์บางรายเคยรายงานการหยุดทำงานข้ามภูมิภาคพร้อมกัน เช่น ในสหรัฐอเมริกาและออสเตรเลีย) ควรพิจารณาสร้างแผน DR (การกู้คืนจากภัยพิบัติ) ที่กำหนดไว้สำหรับผู้ให้บริการระบบคลาวด์ต่างๆ

มุมมองที่ควรค่าแก่การพิจารณาอีกประการหนึ่งคือต้นทุนในการปกป้องทรัพยากร โดยทั่วไป ยิ่งระยะห่างระหว่างปริมาณงานสูงขึ้น ค่าใช้จ่ายในการถ่ายโอนข้อมูลก็จะยิ่งมากขึ้น ในหลายกรณี การถ่ายโอนข้อมูลระหว่างโหนดภายในศูนย์ข้อมูลเดียวกัน (Availability Zone) นั้นฟรี ในขณะที่การถ่ายโอนข้อมูลข้าม Availability Zone อาจมีค่าใช้จ่าย $0.01/GB ขึ้นไป ค่าใช้จ่ายเพิ่มเติมนี้อาจเพิ่มขึ้นเป็นสองเท่า (หรือมากกว่า) เมื่อข้อมูลถูกถ่ายโอนข้ามภูมิภาค (เช่น $0.02 / GB) นอกจากนี้ เนื่องจากระยะห่างทางกายภาพที่เพิ่มขึ้นระหว่างปริมาณงาน จึงควรคาดการณ์เวลาแฝงของข้อมูลระหว่างโหนดระหว่างสถานที่มากขึ้น โดยการพิจารณาปัจจัยเหล่านี้ โดยทั่วไปแล้ว ขอแนะนำให้แจกจ่ายปริมาณงานข้าม Availability Zone ภายในภูมิภาคเดียวกัน