กลุ่มของสองโหนด - ปีศาจอยู่ในรายละเอียด

เฮ้ ฮับ! ฉันขอเสนอการแปลบทความให้คุณทราบ "สองโหนด - ปีศาจอยู่ในรายละเอียด" โดย แอนดรูว์ บีคฮอฟ

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

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

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

เมื่อพิจารณาถึงข้อดีข้อเสียแล้ว เราไม่เพียงแต่มองหา SPoF เท่านั้น แต่ยังต้องสร้างสมดุลระหว่างความเสี่ยงและผลที่ตามมาด้วย ซึ่งผลลัพธ์ที่ได้คือข้อสรุปว่าสิ่งใดสำคัญและสิ่งใดไม่สำคัญอาจแตกต่างกันในแต่ละการใช้งาน

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

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

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

ดังนั้น เพื่อป้องกันข้อมูลเสียหายอันเป็นผลมาจากความล้มเหลวของโหนดเดียว เราจึงต้องอาศัยสิ่งที่เรียกว่า "ความแตกแยก" (ฟันดาบ).

หลักการของการแยกตัวออกจากกัน

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

วิธีการแยกตัวออกจากกันมีสองประเภท ซึ่งผมจะเรียกว่า โดยตรง и ทางอ้อมแต่ก็เรียกได้เหมือนกัน คล่องแคล่ว и เฉยๆ. วิธีการโดยตรงรวมถึงการดำเนินการในส่วนของเพียร์ที่ยังมีชีวิตอยู่ เช่น การโต้ตอบกับอุปกรณ์ IPMI (Intelligent Platform Management Interface) หรือ iLO (กลไกสำหรับการจัดการเซิร์ฟเวอร์ในกรณีที่ไม่มีการเข้าถึงทางกายภาพ) ในขณะที่วิธีการทางอ้อมจะขึ้นอยู่กับความล้มเหลว โหนดเพื่อรับรู้ว่ามันอยู่ในสภาพที่ไม่แข็งแรง (หรืออย่างน้อยก็ป้องกันไม่ให้สมาชิกคนอื่นฟื้นตัว) และส่งสัญญาณ สุนัขเฝ้าบ้านฮาร์ดแวร์ เกี่ยวกับความจำเป็นในการยกเลิกการเชื่อมต่อโหนดที่ล้มเหลว

Quorum ช่วยในการใช้วิธีการทั้งทางตรงและทางอ้อม

การแยกตัวโดยตรง

ในกรณีของการแยกตัวโดยตรง เราสามารถใช้องค์ประชุมเพื่อป้องกันการแยกตัวออกจากกันในกรณีที่เครือข่ายล้มเหลว

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

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

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

น่าเสียดายที่คุณสมบัติการทำงานของอุปกรณ์ IPMI และ iLo นั้นไม่ค่อยได้รับการพิจารณาในขณะที่ซื้ออุปกรณ์

การแยกตัวทางอ้อม

องค์ประชุมยังมีความสำคัญสำหรับการจัดการการแยกส่วนทางอ้อม หากทำอย่างถูกต้อง องค์ประชุมสามารถอนุญาตให้ผู้รอดชีวิตสันนิษฐานว่าโหนดที่สูญหายจะเปลี่ยนไปสู่สถานะที่ปลอดภัยหลังจากช่วงระยะเวลาหนึ่ง

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

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

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

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

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

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

องค์ประชุม

Quorum ฟังดูดีมากใช่ไหม?

ข้อเสียเพียงอย่างเดียวคือเพื่อที่จะให้มีคลัสเตอร์ที่มีสมาชิก N คุณจะต้องมีการเชื่อมต่อระหว่าง N/2+1 ของโหนดของคุณที่เหลืออยู่ ซึ่งเป็นไปไม่ได้ในสองโหนดคลัสเตอร์หลังจากหนึ่งโหนดล้มเหลว

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

การทำงานของคลัสเตอร์แบบสองโหนด

บางครั้งลูกค้าไม่สามารถหรือไม่ต้องการซื้อโหนดที่สาม และเราถูกบังคับให้มองหาทางเลือกอื่น

ตัวเลือก 1 - วิธีการแยกตัวซ้ำกัน

อุปกรณ์ iLO หรือ IPMI ของโหนดแสดงถึงจุดที่เกิดความล้มเหลว เนื่องจากหากล้มเหลว ผู้รอดชีวิตจะไม่สามารถใช้อุปกรณ์ดังกล่าวเพื่อนำโหนดไปสู่สถานะที่ปลอดภัยได้ ในคลัสเตอร์ที่มีตั้งแต่ 3 โหนดขึ้นไป เราสามารถลดปัญหานี้ได้โดยการคำนวณองค์ประชุมและใช้ฮาร์ดแวร์เฝ้าระวัง (กลไกการแยกการเชื่อมโยงทางอ้อม ตามที่กล่าวไว้ก่อนหน้านี้) ในกรณีที่มีสองโหนด เราต้องใช้ Network Power Distribution Unit (PDU) แทน

หลังจากความล้มเหลว ผู้รอดชีวิตจะพยายามติดต่อกับอุปกรณ์แยกการเชื่อมโยงหลัก (iLO หรือ IPMI แบบฝัง) หากสำเร็จ การฟื้นตัวจะดำเนินต่อไปตามปกติ เฉพาะในกรณีที่อุปกรณ์ iLO/IPMI ล้มเหลวเท่านั้นที่จะสามารถเข้าถึง PDU ได้ หากการเข้าถึงสำเร็จ การกู้คืนก็สามารถดำเนินต่อไปได้

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

ที่นี่คุณอาจถาม - PDU เป็นจุดเดียวของความล้มเหลวหรือไม่? ซึ่งคำตอบก็คือแน่นอนว่าเป็นเช่นนั้น

หากความเสี่ยงนี้สำคัญสำหรับคุณ คุณไม่ได้อยู่คนเดียว: ​​เชื่อมต่อทั้งสองโหนดเข้ากับ PDU สองตัวและบอกให้ซอฟต์แวร์การทำคลัสเตอร์ใช้ทั้งสองอย่างเมื่อเปิดและปิดโหนด ขณะนี้คลัสเตอร์ยังคงทำงานอยู่หาก PDU ตัวหนึ่งเสีย และความล้มเหลวครั้งที่สองของ PDU อื่นหรืออุปกรณ์ IPMI จะต้องบล็อกการกู้คืน

ตัวเลือกที่ 2 - การเพิ่มอนุญาโตตุลาการ

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

ในกรณีนี้ ทางเลือกที่แนะนำคือการสร้างบุคคลที่สามที่เป็นกลางซึ่งสามารถเสริมการคำนวณองค์ประชุมได้

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

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

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

ตัวเลือก 3 - ปัจจัยมนุษย์

แนวทางสุดท้ายคือให้ผู้รอดชีวิตสามารถใช้บริการใดก็ตามที่ตนใช้งานอยู่ต่อไปได้ แต่อย่าเริ่มบริการใหม่จนกว่าปัญหาจะได้รับการแก้ไขเอง (การคืนค่าเครือข่าย การรีบูตโหนด) หรือบุคคลจะรับผิดชอบในการยืนยันด้วยตนเองว่าอีกฝ่ายเสียชีวิตแล้ว

ตัวเลือกโบนัส

ฉันพูดถึงคุณสามารถเพิ่มโหนดที่สามได้หรือไม่?

สองชั้นวาง

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

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

คำตอบสั้นๆ ก็คือ มันเป็นไปไม่ได้ และอีกครั้งที่เรากำลังจัดการกับปัญหาทั้งหมดในกรณีแบบสองโหนด หรือผู้รอดชีวิต:

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

ไม่ว่าในกรณีใด แร็คสองแร็คก็ไม่ได้ดีไปกว่าแร็คเดียว และโหนดจะต้องได้รับแหล่งจ่ายไฟแยกจากกัน หรือกระจายไปยังแร็คสามแร็ค (หรือมากกว่านั้น ขึ้นอยู่กับจำนวนโหนดที่คุณมี)

ศูนย์ข้อมูลสองแห่ง

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

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

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

ที่มา: will.com