Date: พฤษภาคม 11, 2024
อะไรทำให้เกิดความล้มเหลวเกิดขึ้น?
การทำงานด้านการสนับสนุน หนึ่งในคำถามที่พบบ่อยที่สุดที่เราได้รับจากลูกค้าคือ “สิ่งที่กระตุ้นให้เกิดเฟลโอเวอร์จากโหนดหลักของฉันไปยังโหนดรอง?”
มีสาเหตุหลายประการที่อาจเกิดขึ้น… และเราจะพยายามอธิบายสาเหตุที่พบบ่อยที่สุด และวิธีที่คุณสามารถระบุสาเหตุเหล่านี้ได้
ก่อนที่เราจะเริ่มต้นกันก่อนแยกความแตกต่างระหว่าง ‘เฟลโอเวอร์’ และ ‘สวิตช์โอเวอร์’เนื่องจากลูกค้าจำนวนมากใช้คำเหล่านี้สลับกัน
‘การสลับ’ คือการย้ายลำดับชั้นของคุณจากโหนดหลักไปยังโหนดรองด้วยตนเอง ซึ่งสามารถทำได้ผ่าน GUI โดยดำเนินการ ‘อยู่ในบริการ’ บนโหนดรองหรือผ่านบรรทัดคำสั่ง:
Perform_action -a Restore -t $LKTag (นำลำดับชั้นมาสู่การบริการ)
ในทางกลับกัน ‘เฟลโอเวอร์’ จะดำเนินการโดยไม่มีการโต้ตอบด้วยตนเองใดๆ… และถูกกำหนดให้เป็นการสลับไปยังเซิร์ฟเวอร์สำรองโดยอัตโนมัติเมื่อเซิร์ฟเวอร์ แอปพลิเคชัน หรือฮาร์ดแวร์/เครือข่ายที่ใช้งานก่อนหน้านี้ล้มเหลว
เฟลโอเวอร์และสวิตช์โอเวอร์โดยพื้นฐานแล้วเป็นการดำเนินการเดียวกัน ยกเว้นว่าเฟลโอเวอร์นั้นเป็นไปโดยอัตโนมัติและมักจะทำงานโดยไม่มีการเตือนล่วงหน้าในขณะที่การเปลี่ยนผ่านเกิดขึ้นโดยเจตนาและต้องมีการแทรกแซงจากมนุษย์
ต่อไปนี้คือ ‘ความล้มเหลว’ ที่พบบ่อยที่สุดที่ทำให้เกิด ‘ความล้มเหลว’:
-
สาเหตุระดับเซิร์ฟเวอร์
เซิร์ฟเวอร์ล้มเหลว
- เซิร์ฟเวอร์หลักสูญเสียพลังงานหรือปิดอยู่
- การใช้งาน CPU ที่เกิดจากการโหลดมากเกินไป — ภายใต้การโหลด I/O ที่หนักมาก ความล่าช้าและสภาวะหน่วยความจำเหลือน้อยอาจทำให้ระบบไม่ตอบสนองได้ไลฟ์คีปเปอร์อาจตรวจพบว่าเซิร์ฟเวอร์ล่มและเริ่มการเฟลโอเวอร์
- องค์ประชุม/พยาน – ในฐานะส่วนหนึ่งของกลไกการฟันดาบ I/O ขององค์ประชุม/พยาน เมื่อเซิร์ฟเวอร์หลักสูญเสียองค์ประชุม “บูตเร็ว–ฟาสต์คิล” หรือ “โอสุ” จะถูกดำเนินการ (ขึ้นอยู่กับการตั้งค่า) และการเริ่มต้นระบบเฟลโอเวอร์ เมื่อพิจารณาว่าเมื่อใดที่จะเกิดข้อผิดพลาด เซิร์ฟเวอร์พยานจะอนุญาตให้นำทรัพยากรมาให้บริการบนเซิร์ฟเวอร์สำรองเฉพาะในกรณีที่ตรวจสอบว่าเซิร์ฟเวอร์หลักล้มเหลวและไม่ได้เป็นส่วนหนึ่งของคลัสเตอร์อีกต่อไป วิธีนี้จะป้องกันไม่ให้เกิดข้อผิดพลาดเนื่องจากความล้มเหลวในการสื่อสารทั่วไประหว่างโหนด เมื่อความล้มเหลวเหล่านั้นไม่ส่งผลกระทบต่อการเข้าถึงโดยรวมและประสิทธิภาพของโหนดในบริการ
การสื่อสาร (การเต้นของหัวใจ) ล้มเหลว
LifeKeeper มีสัญญาณ “ฮาร์ทบีท” ในตัวที่จะแจ้งเตือนแต่ละเซิร์ฟเวอร์เป็นระยะในการกำหนดค่าว่าเซิร์ฟเวอร์ที่จับคู่ทำงานอยู่ ตามค่าเริ่มต้น LifeKeeper จะส่งฮาร์ทบีทระหว่างเซิร์ฟเวอร์ทุกๆ ห้าวินาที (ซึ่งสามารถปรับได้สำหรับคลัสเตอร์ที่ไม่ว่าง) หากปัญหาในการสื่อสารทำให้การเต้นของหัวใจข้ามสองจังหวะแต่กลับมาทำงานต่อในการเต้นของหัวใจครั้งที่สาม LifeKeeper จะไม่ดำเนินการใดๆ อย่างไรก็ตาม หากเส้นทางการสื่อสารยังคงไม่ทำงานเป็นเวลาสามจังหวะ LifeKeeper จะติดป้ายเส้นทางการสื่อสารนั้นว่าไม่ทำงาน มันจะเริ่มต้นการเฟลโอเวอร์หากเส้นทางการสื่อสารที่ซ้ำซ้อนนั้นใช้งานไม่ได้เช่นกัน (เราขอแนะนำสองเส้นทาง)
สิ่งต่อไปนี้อาจส่งผลให้หัวใจเต้นผิดจังหวะ:
- การเชื่อมต่อเครือข่ายไปยังเซิร์ฟเวอร์หลักขาดหายไป
- เวลาแฝงของเครือข่าย
- การรับส่งข้อมูลเครือข่ายจำนวนมากบนเส้นทางการสื่อสาร TCP อาจส่งผลให้เกิดพฤติกรรมที่ไม่คาดคิด รวมถึงการเฟลโอเวอร์ที่ผิดพลาดและปัญหาการเริ่มต้น LifeKeeper
- NIC ล้มเหลว
- สวิตช์เครือข่ายล้มเหลว
- การดึง/ถอดการเชื่อมต่อเครือข่ายด้วยตนเอง
- เซิร์ฟเวอร์หลักสูญเสียพลังงานหรือปิดอยู่
- การใช้งาน CPU ที่เกิดจากการโหลดมากเกินไป — ภายใต้การโหลด I/O ที่หนักมาก ความล่าช้าและสภาวะหน่วยความจำเหลือน้อยอาจทำให้ระบบไม่ตอบสนองจน LifeKeeper อาจตรวจพบว่าเซิร์ฟเวอร์ล่มและเริ่มการทำงานล้มเหลว
การปรับพารามิเตอร์การเต้นของหัวใจ:
LCMNUMHBEATS=Y (โดยที่ Y คือจำนวนฮาร์ทบีทก่อนที่จะบันทึกข้อผิดพลาดพาธการสื่อสารล้มเหลวในบันทึก) ค่าเริ่มต้นคือ 3 และสามารถเปลี่ยนแปลงได้หากระบบของคุณไม่ว่างหรือข้าม WAN เพื่อหลีกเลี่ยงความล้มเหลวของเส้นทางการสื่อสารที่ผิดพลาด
LCMHBEATTIME=5 (นี่คือช่วงเวลาเป็นวินาทีและเป็นค่าเริ่มต้นและไม่ควรเปลี่ยนแปลง)
การปรับแต่งเหล่านี้ไม่อยู่ในไฟล์ /etc/default/LifeKeeper ตามค่าเริ่มต้น คุณจะต้องเพิ่มค่าเหล่านี้เพื่อเปลี่ยนค่าฮาร์ทบีท
หลังจากเพิ่มการปรับแต่งและค่าเหล่านี้ใน /etc/default/LifeKeeper แล้ว คุณต้องหยุด LifeKeeper และรีสตาร์ท คุณสามารถใช้คำสั่ง lkstop -f ซึ่งจะหยุด LifeKeeper แต่จะไม่ทำให้แอปพลิเคชันที่ได้รับการป้องกันเสียหาย
และคุณต้องทำสิ่งนี้กับทั้งสองระบบ
ซึ่งจะใช้เวลา 5 ครั้ง Y วินาทีก่อนที่ LifeKeeper จะทำเครื่องหมายเส้นทางการสื่อสารว่าล้มเหลว
Split-Brain คืออะไร และเกิดจากอะไร
หากใช้เส้นทางการสื่อสารเดียวและเส้นทางการสื่อสารล้มเหลว ลำดับชั้นของ LifeKeeper อาจพยายามให้บริการบนหลายระบบพร้อมกัน สิ่งนี้เรียกว่าการเฟลโอเวอร์ที่ผิดพลาดหรือสถานการณ์ “สมองแตก” ในสถานการณ์ “สมองแตก”แต่ละเซิร์ฟเวอร์เชื่อว่าอยู่ในการควบคุมแอปพลิเคชัน และอาจพยายามเข้าถึงและเขียนข้อมูลไปยังอุปกรณ์จัดเก็บข้อมูลที่ใช้ร่วมกัน เพื่อแก้ไขสถานการณ์ที่สมองแตกแยก LifeKeeper อาจทำให้เซิร์ฟเวอร์ปิดหรือรีบูต หรือปล่อยให้ลำดับชั้นไม่อยู่ในบริการ เพื่อรับประกันความสมบูรณ์ของข้อมูลในข้อมูลที่แชร์ทั้งหมด นอกจากนี้ การรับส่งข้อมูลเครือข่ายจำนวนมากบนเส้นทางการสื่อสาร TCP อาจส่งผลให้เกิดพฤติกรรมที่ไม่คาดคิด รวมถึงการเฟลโอเวอร์ที่ผิดพลาดและความล้มเหลวของ LifeKeeper ในการเริ่มต้นอย่างถูกต้อง
ต่อไปนี้เป็นสถานการณ์ที่อาจทำให้สมองแตกได้:
- ความล้มเหลวในการสื่อสารใดๆ ที่ระบุไว้ข้างต้น
- การปิดเครื่อง LifeKeeper ไม่ถูกต้อง
- ความอดอยากทรัพยากรเซิร์ฟเวอร์
- สูญเสียเส้นทางเครือข่ายทั้งหมด
- DNS หรือความผิดพลาดของเครือข่ายอื่น ๆ
- การล็อคระบบ
การใช้องค์ประชุม/พยานเพื่อป้องกันสมองแตกแยก
- แพ็คเกจสนับสนุนเซิร์ฟเวอร์ Quorum/Witness สำหรับ LifeKeeper (steeleye-lkQWK ซึ่งต่อไปนี้จะเรียกว่า “แพ็คเกจ Quorum/Witness”) รวมกับกระบวนการเฟลโอเวอร์ที่มีอยู่ของแกนหลักของ LifeKeeper ช่วยให้การเฟลโอเวอร์ของระบบเกิดขึ้นด้วยระดับความมั่นใจที่มากขึ้นในสถานการณ์ที่ความล้มเหลวของเครือข่ายทั้งหมดอาจเกิดขึ้นได้ เป็นเรื่องธรรมดา ซึ่งหมายความว่าการเฟลโอเวอร์ไซต์ท้องถิ่นและการเฟลโอเวอร์ไปยังโหนดข้าม WAN สามารถทำได้พร้อมทั้งลดความเสี่ยงของแบ่งสมองสถานการณ์
- ในระบบแบบกระจายที่คำนึงถึงการแบ่งพาร์ติชันเครือข่าย มีแนวคิดที่เรียกว่าองค์ประชุมเพื่อรับความเห็นร่วมกันทั่วทั้งคลัสเตอร์ โหนดที่มีองค์ประชุมคือโหนดที่สามารถรับความเห็นพ้องต้องกันของคลัสเตอร์ทั้งหมด และได้รับอนุญาตให้นำทรัพยากรมาให้บริการ ในทางกลับกัน โหนดที่ไม่มีองค์ประชุมคือโหนดที่ไม่สามารถได้รับความเห็นพ้องต้องกันจากคลัสเตอร์ทั้งหมด และไม่ได้รับอนุญาตให้นำทรัพยากรมาให้บริการ วิธีนี้จะป้องกันไม่ให้เกิดภาวะสมองแตก หากต้องการตรวจสอบว่าโหนดมีองค์ประชุมหรือไม่เรียกว่าการตรวจสอบองค์ประชุม จะแสดงเป็น “การตรวจสอบองค์ประชุมสำเร็จ” หากมีองค์ประชุม และ “การตรวจสอบองค์ประชุมล้มเหลว” หากไม่มีองค์ประชุม
- ในกรณีที่การสื่อสารล้มเหลว การใช้โหนดหนึ่งที่เกิดความล้มเหลวและอีกโหนดหนึ่ง (หรืออุปกรณ์อื่นๆ) จะทำให้โหนดได้รับ “ความเห็นที่สอง” เกี่ยวกับสถานะของโหนดที่ล้มเหลว โหนดที่จะได้รับ “ความเห็นที่สอง” เรียกว่าโหนดพยาน (หรืออุปกรณ์พยาน) และการรับ “ความเห็นที่สอง” เรียกว่าการตรวจสอบพยาน เมื่อพิจารณาว่าจะเฟลโอเวอร์เมื่อใด โหนดพยาน (อุปกรณ์พยาน) จะอนุญาตให้นำทรัพยากรมาให้บริการบนเซิร์ฟเวอร์สำรองเฉพาะในกรณีที่ตรวจสอบว่าเซิร์ฟเวอร์หลักล้มเหลวและไม่ได้เป็นส่วนหนึ่งของคลัสเตอร์อีกต่อไป วิธีนี้จะป้องกันไม่ให้เกิดข้อผิดพลาดเนื่องจากความล้มเหลวในการสื่อสารทั่วไประหว่างโหนด เมื่อความล้มเหลวเหล่านั้นไม่ส่งผลกระทบต่อการเข้าถึงโดยรวมและประสิทธิภาพของโหนดในบริการ ในระหว่างการทำงานจริง โหนดพยาน (อุปกรณ์พยาน) จะถูกปรึกษาเมื่อ LifeKeeper เริ่มทำงานหรือเส้นทางการสื่อสารที่ล้มเหลวได้รับการกู้คืน การตรวจสอบพยานสามารถทำได้เฉพาะกับโหนดที่มีองค์ประชุมเท่านั้น
-
สาเหตุความล้มเหลวของทรัพยากร
LifeKeeper ได้รับการออกแบบมาเพื่อตรวจสอบแต่ละแอปพลิเคชันและกลุ่มของแอปพลิเคชันที่เกี่ยวข้อง ทำการกู้คืนหรือการแจ้งเตือนในเครื่องเป็นระยะ ๆ เมื่อแอปพลิเคชันที่ได้รับการป้องกันล้มเหลว ตัวอย่างแอปพลิเคชันที่เกี่ยวข้องคือลำดับชั้นที่แอปพลิเคชันหลักขึ้นอยู่กับที่เก็บข้อมูลระดับล่างหรือทรัพยากรเครือข่าย LifeKeeper ติดตามสถานะและสุขภาพของทรัพยากรที่ได้รับการคุ้มครองเหล่านี้ หากทรัพยากรถูกกำหนดให้อยู่ในสถานะล้มเหลว จะพยายามกู้คืนทรัพยากรหรือแอปพลิเคชันบนระบบปัจจุบัน (โหนดในบริการ) โดยไม่มีการแทรกแซงจากภายนอก หากการกู้คืนในเครื่องนี้ล้มเหลว ทรัพยากรจะเริ่มต้นขึ้นเมื่อเกิดข้อผิดพลาด
ความล้มเหลวของแอปพลิเคชัน
- ตรวจพบความล้มเหลวของแอปพลิเคชัน แต่กระบวนการกู้คืนในเครื่องล้มเหลว
- ลบความล้มเหลว – ในระหว่างกระบวนการเฟลโอเวอร์ทรัพยากร ทรัพยากรบางอย่างจำเป็นต้องถูกลบออกจากบริการบนเซิร์ฟเวอร์หลัก จากนั้นจึงนำมาให้บริการบนเซิร์ฟเวอร์สำรองที่เลือก เพื่อให้ฟังก์ชันการทำงานเต็มรูปแบบของแอปพลิเคชันที่สำคัญ หากกระบวนการลบนี้ล้มเหลว การรีบูตเซิร์ฟเวอร์หลักจะดำเนินการส่งผลให้เซิร์ฟเวอร์เกิดข้อผิดพลาดโดยสมบูรณ์
ตัวอย่างของความล้มเหลวในการลบ:
- ไม่สามารถถอนติดตั้งระบบไฟล์ได้
- ไม่สามารถปิดแอปพลิเคชันที่ได้รับการป้องกัน (oracle, mysql, postgres ฯลฯ )
ปัญหาระบบไฟล์
- ดิสก์เต็ม — การตรวจสอบสภาพระบบไฟล์ของ LifeKeeper สามารถตรวจจับสภาวะระบบไฟล์เต็มของดิสก์ ซึ่งอาจส่งผลให้เกิดความล้มเหลวของทรัพยากรระบบไฟล์
- ยกเลิกการเมานท์หรือเมานต์ระบบไฟล์ไม่ถูกต้อง — ผู้ใช้ถอนเมานท์ด้วยตนเองหรือเปลี่ยนตัวเลือกบนระบบไฟล์ที่ได้รับการป้องกันและ LK
- การเมานต์ใหม่ล้มเหลว — ต่อไปนี้คือรายการสาเหตุทั่วไปสำหรับความล้มเหลวในการเมานต์ใหม่ซึ่งจะนำไปสู่การเฟลโอเวอร์:
- ระบบไฟล์เสียหาย (fsck ล้มเหลว)
- ความล้มเหลวในการสร้างไดเร็กทอรีจุดเมานท์
- จุดเมานต์ไม่ว่าง
- ความล้มเหลวในการติดตั้ง
- ข้อผิดพลาดภายใน LifeKeeper
ที่อยู่ IP ล้มเหลว
เมื่อชุดการกู้คืน IP ตรวจพบความล้มเหลวของที่อยู่ IP ความล้มเหลวที่เกิดขึ้นจะทริกเกอร์การดำเนินการของสคริปต์การกู้คืนภายใน IP LifeKeeper พยายามนำที่อยู่ IP กลับมาให้บริการบนอินเทอร์เฟซเครือข่ายปัจจุบันเป็นครั้งแรก หากความพยายามในการกู้คืนในเครื่องล้มเหลว LifeKeeper จะดำเนินการย้ายที่อยู่ IP และทรัพยากรที่ต้องพึ่งพาทั้งหมดไปยังเซิร์ฟเวอร์สำรอง ในระหว่างการเฟลโอเวอร์ กระบวนการลบจะยกเลิกการกำหนดค่าที่อยู่ IP บนเซิร์ฟเวอร์ปัจจุบัน เพื่อให้สามารถกำหนดค่าบนเซิร์ฟเวอร์สำรองได้ ความล้มเหลวของกระบวนการลบนี้จะทำให้ระบบรีบูต
- ข้อขัดแย้งด้าน IP
- การชนกันของไอพี
- การแก้ปัญหา DNS ล้มเหลว
- NIC หรือสวิตช์ล้มเหลว
ข้อขัดแย้งในการจอง
- การจองอุปกรณ์ที่ได้รับการป้องกันสูญหายหรือถูกขโมย
- ไม่สามารถจองหรือควบคุมอุปกรณ์ทรัพยากรที่ได้รับการป้องกันได้ (เกิดจากการที่ผู้ใช้ดำเนินการด้วยตนเอง HBA หรือสวิตช์ล้มเหลว)
อุปกรณ์ SCSI
- ไม่สามารถเปิดอุปกรณ์ SCSI ที่มีการป้องกันได้ อุปกรณ์อาจทำงานล้มเหลวหรืออาจถูกลบออกจากระบบ
แหล่งข้อมูลสำหรับการระบุสาเหตุของการเฟลโอเวอร์
/var/log/lifekeeper.log
ไฟล์บันทึกนี้เขียนโดย LifeKeeper ควรเป็นที่แรกที่คุณจะพิจารณาถึงสิ่งที่อาจทำให้เกิดความล้มเหลว
ตัวอย่างเช่น สาเหตุที่พบบ่อยที่สุดประการหนึ่งคือเส้นทางการสื่อสารล้มเหลว ด้านล่างนี้เป็นตัวอย่างของรายการที่คุณจะพบใน lifekeeper.log เมื่อเกิดเหตุการณ์เช่นนี้:
21 กันยายน 11:06:57 es1ecc08tev lcm[46893]: INFO:lcm.tli_hand:::005257:missed heartbeat 1 จาก 48 ใน dev 10.236.17.226/10.238.17.226 (หมายเลขไดรเวอร์ lcm = 129)
21 กันยายน 11:06:57 es1ecc08tev lcm[46893]: INFO:lcm.tli_hand:::005257:missed heartbeat 1 จาก 48 ใน dev 10.236.17.226/10.237.17.226 (หมายเลขไดรเวอร์ lcm = 1360929)
21 กันยายน 11:07:02 es1ecc08tev lcm[46893]: INFO:lcm.tli_hand:::005257:missed heartbeat 2 จาก 48 ใน dev 10.236.17.226/10.238.17.226 (หมายเลขไดรเวอร์ lcm = 129)
หลังจากที่ฮาร์ทบีทถึงจำนวนสูงสุดแล้ว การเฟลโอเวอร์จะเริ่มต้นขึ้น:
21 กันยายน 11:10:49 น. es6ecc08tev lcm[9416]: INFO:lcm.tli_hand:::005257:missed heartbeat 47 จาก 48 ใน dev 10.237.17.226/10.236.17.226 (หมายเลขไดรเวอร์ lcm = 71)
21 กันยายน 11:10:49 น. es6ecc08tev eventslcm [47082]: WARN:lcd.net:::004258: การสื่อสารไปยัง es1ecc08tev โดย 10.237.17.226/10.236.17.226 ล้มเหลว
21 ก.ย. 11:10:49 น. es6ecc08tev eventslcm[47082]: WARN:lcd.net:::004261:COMMUNICATIONS เฟลโอเวอร์จากระบบ “es1ecc08tev” จะเริ่มทำงาน
21 กันยายน 11:10:49 น. es6ecc08tev lifekeeper [47121]: แจ้งเตือน:event.comm_down:::010466:COMMUNICATIONS es1ecc08tev FAILED
/var/log/messages
โดยทั่วไปไฟล์ที่สร้างโดย Linux จะมีข้อความระบบที่สร้างโดยกระบวนการและบริการต่างๆ ที่ทำงานบนระบบ ข้อความเหล่านี้อาจรวมถึง:
ข้อความการบูตระบบ: ข้อมูลเกี่ยวกับกระบวนการบูตระบบ รวมถึงข้อความเคอร์เนลและข้อความจาก systemd หรือระบบ init อื่นๆ
ข้อความเริ่มต้นและปิดบริการ: ข้อความที่ระบุว่าบริการเริ่มต้นหรือหยุดเมื่อใด รวมถึงข้อผิดพลาดหรือคำเตือนใด ๆ ที่พบในระหว่างกระบวนการ
ข้อความเคอร์เนล: ข้อมูลเกี่ยวกับการทำงานของเคอร์เนล Linux รวมถึงการตรวจหาฮาร์ดแวร์ การเริ่มต้นอุปกรณ์ และข้อผิดพลาดหรือคำเตือนเคอร์เนล
ข้อความที่เกี่ยวข้องกับเครือข่าย: ข้อมูลเกี่ยวกับการเชื่อมต่อเครือข่าย กิจกรรมไฟร์วอลล์ และการเปลี่ยนแปลงการกำหนดค่าเครือข่าย
ข้อมูลประสิทธิภาพระบบ: ข้อความที่เกี่ยวข้องกับการตรวจสอบประสิทธิภาพระบบ เช่น การใช้งาน CPU, การใช้หน่วยความจำ และสถิติดิสก์ I/O
SIOS ความพร้อมใช้งานสูงและการกู้คืนความเสียหาย
SIOS เทคโนโลยี คอร์ปอเรชั่น จัดให้ความพร้อมใช้งานสูงและการกู้คืนระบบผลิตภัณฑ์ที่ปกป้องและเพิ่มประสิทธิภาพโครงสร้างพื้นฐานด้านไอทีด้วยการจัดการคลัสเตอร์สำหรับแอปพลิเคชันที่สำคัญที่สุดของคุณติดต่อเราวันนี้สำหรับข้อมูลเพิ่มเติม.
ทำซ้ำโดยได้รับอนุญาตจากSIOS