เทคโนโลยี SIOS ช่วยสร้างสมดุลระหว่างความพร้อมใช้งานสูงและต้นทุนระบบคลาวด์

 

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

ปัจจัยสำคัญที่มีอิทธิพลต่อต้นทุนในสภาพแวดล้อมคลาวด์

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

ค้นหาความสมดุลระหว่างความพร้อมใช้งานสูงและการเพิ่มประสิทธิภาพต้นทุนในระบบคลาวด์

• Bermingham อธิบายว่าแม้ว่าความพร้อมใช้งานสูงจะมีค่าใช้จ่ายบางส่วน แต่ก็ช่วยลดต้นทุนที่เกี่ยวข้องกับการหยุดทำงานซึ่งอาจมีนัยสำคัญ
• สิ่งสำคัญคือต้องสร้างสมดุลระหว่างความพร้อมใช้งานสูงและการลดต้นทุนระบบคลาวด์โดยการสร้างระบบที่เป็นโมดูลาร์และปรับขนาดได้ พร้อมด้วยกลยุทธ์การปฏิบัติงานที่รวบรวมวัฒนธรรม DevOps และใช้แนวปฏิบัติ CI/CD

การเพิ่มประสิทธิภาพต้นทุนบนคลาวด์และความท้าทายด้านความพร้อมใช้งานสูง

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

โซลูชันความพร้อมใช้งานสูงของ SIOS Technology ช่วยได้อย่างไร

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

ทำซ้ำโดยได้รับอนุญาตจากSIOS

SIOS LifeKeeper สำหรับ Linux v 9.8.1 ปรับปรุงวิธีที่บริษัทต่างๆ จัดการ HA/DR

ในสภาพแวดล้อมที่ขับเคลื่อนด้วยเทคโนโลยีในปัจจุบัน บริษัทต่างๆ กำลังมองหาโซลูชันที่เป็นนวัตกรรมเพื่อรักษาสภาพแวดล้อมการใช้งานที่ซับซ้อนได้อย่างมีประสิทธิภาพ ในวิดีโอนี้ท็อดด์ โดแอนวิศวกรฝ่ายขายที่ SIOS Technology อธิบายวิธีการใช้เวอร์ชันล่าสุดSIOS LifeKeeper สำหรับ Linuxช่วยบริษัทต่างๆ ในการปกป้องระบบองค์กรที่สำคัญจากการหยุดทำงานและภัยพิบัติ “การเปิดตัวมีคุณสมบัติกคอนโซลการจัดการเว็บใหม่– มันมีอยู่ในตัวเองและไม่จำเป็นต้องมีการติดตั้งเพิ่มเติมหรือส่วนเสริมของบุคคลที่สาม” Doane กล่าว

ทำซ้ำโดยได้รับอนุญาตจากSIOS

การเลือกระหว่าง GenApp และ QSP: การปรับแต่งความพร้อมใช้งานสูงสำหรับแอปพลิเคชันที่สำคัญของคุณ

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

เจนแอพ,ย่อมาจาก Generic Application เป็นประเภททรัพยากรที่ช่วยให้คุณจัดการแอปพลิเคชันที่กำหนดเองภายใน LifeKeeper ด้วยเฟรมเวิร์กที่ยืดหยุ่น คุณสามารถใช้สคริปต์ของคุณเองเพื่อทำงานต่างๆ ที่แอปพลิเคชันของคุณอาจต้องการเพื่อทำให้กระบวนการเฟลโอเวอร์และการกู้คืนเป็นแบบอัตโนมัติ ความยืดหยุ่นนี้ช่วยให้สามารถควบคุมวิธีที่ LifeKeeper จัดการกับการเริ่มต้น การปิดระบบ การตรวจสอบ การดำเนินการบันทึก และอื่นๆ อย่างละเอียด เพื่อให้มั่นใจว่าแอปพลิเคชันของคุณมีความพร้อมใช้งานสูง

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

ฉันจะเลือกโซลูชันที่เหมาะสมได้อย่างไร

สิ่งแรกที่คุณต้องพิจารณาคือว่าแอปพลิเคชันของคุณสามารถกู้คืนได้โดยการหยุดและรีสตาร์ทบริการหรือ daemon หากเป็นเช่นนั้น QSP น่าจะเป็นทางออกที่ดีที่สุดและเร็วที่สุดในการทำให้แอปพลิเคชันของคุณทำงานต่อไปได้ เนื่องจากไม่จำเป็นต้องเขียนโค้ด และภายในไม่กี่นาทีคุณสามารถเพิ่มแอปพลิเคชันเป็นทรัพยากร QSP ภายใน LifeKeeper GUI ได้ นอกจากนี้ยังเป็นส่วนหนึ่งของผลิตภัณฑ์หลักและการอัพเดตโค้ดใดๆ จะรวมอยู่ในการเปิดตัวผลิตภัณฑ์ใหม่ อย่างไรก็ตาม หากแอปพลิเคชันของคุณต้องการสิ่งอื่นใดนอกเหนือจากการตรวจสุขภาพแบบธรรมดาและรีสตาร์ทความสามารถที่ระดับบริการ OS เพื่อกู้คืนอย่างเหมาะสม คุณจะต้องสำรวจ GenApps การสร้างสคริปต์แบบกำหนดเองสำหรับประเภททรัพยากร GenApp จะต้องอาศัยทักษะด้านเทคนิคเชิงลึกมากขึ้นและการบำรุงรักษาในระยะยาว อย่างไรก็ตาม ความยืดหยุ่นในการทำงานทุกอย่างที่จำเป็นเพื่อให้แอปพลิเคชันของคุณทำงานได้อย่างราบรื่นถือเป็นสิ่งสำคัญ โดยเฉพาะอย่างยิ่งสำหรับแอปพลิเคชันเฉพาะกลุ่ม งานเหล่านี้อาจเป็นอะไรก็ได้ตั้งแต่การตรวจสอบ การบันทึก งานล้างข้อมูล หรือการเปลี่ยนแปลงการกำหนดค่า

ต้องการรายละเอียดทางเทคนิคเพิ่มเติมหรือไม่?

GenApps และ QSP ได้รับการสนับสนุนบนทั้ง LifeKeeper สำหรับ Linux และ Windows รายละเอียดทางเทคนิคเพิ่มเติมสามารถดูได้จากลิงก์ด้านล่าง

• GenApp สำหรับ LifeKeeper สำหรับ Linux
• GenApp สำหรับ LifeKeeper สำหรับ Windows
• QSP สำหรับ LifeKeeper สำหรับ Linux
• QSP สำหรับ LifeKeeper สำหรับ Windows

ทำซ้ำโดยได้รับอนุญาตจากSIOS

https://www.sios-apac.com/th/2024/05/16346/

อะไรทำให้เกิดความล้มเหลวเกิดขึ้น?

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

มีสาเหตุหลายประการที่อาจเกิดขึ้น… และเราจะพยายามอธิบายสาเหตุที่พบบ่อยที่สุด และวิธีที่คุณสามารถระบุสาเหตุเหล่านี้ได้

ก่อนที่เราจะเริ่มต้นกันก่อนแยกความแตกต่างระหว่าง ‘เฟลโอเวอร์’ และ ‘สวิตช์โอเวอร์’เนื่องจากลูกค้าจำนวนมากใช้คำเหล่านี้สลับกัน

‘การสลับ’ คือการย้ายลำดับชั้นของคุณจากโหนดหลักไปยังโหนดรองด้วยตนเอง ซึ่งสามารถทำได้ผ่าน GUI โดยดำเนินการ ‘อยู่ในบริการ’ บนโหนดรองหรือผ่านบรรทัดคำสั่ง:

Perform_action -a Restore -t $LKTag (นำลำดับชั้นมาสู่การบริการ)

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

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

ต่อไปนี้คือ ‘ความล้มเหลว’ ที่พบบ่อยที่สุดที่ทำให้เกิด ‘ความล้มเหลว’:

1. สาเหตุระดับเซิร์ฟเวอร์

เซิร์ฟเวอร์ล้มเหลว

• เซิร์ฟเวอร์หลักสูญเสียพลังงานหรือปิดอยู่
• การใช้งาน 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 เริ่มทำงานหรือเส้นทางการสื่อสารที่ล้มเหลวได้รับการกู้คืน การตรวจสอบพยานสามารถทำได้เฉพาะกับโหนดที่มีองค์ประชุมเท่านั้น

2. สาเหตุความล้มเหลวของทรัพยากร

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

เคล็ดลับสามประการเพื่อการสนับสนุนที่ดียิ่งขึ้น

เบ็ตซี่คือรถ Amazon Green Ford F-150 ปี 1999 ซึ่งเป็นรถคันแรกที่ฉันเคยซื้อ ฉันไม่แน่ใจว่ารถบรรทุกของฉันชื่อเบ็ตซี่มาได้อย่างไร หรือทำไมมันถึงติดอยู่ แต่มันก็เป็นเช่นนั้น เป็นเวลากว่า 17 ปีที่ Betsy ทำทุกอย่างตั้งแต่ล่องเรือไปตามชายหาดไปจนถึงแข่งบนสนามแข่ง ลากอุปกรณ์จัดสวนจำนวนมาก และพาครอบครัวที่กำลังเติบโตของฉันข้ามตะวันออกเฉียงใต้ หลังจากเรียนรู้การดูแลรถบรรทุกมาหลายปี เธอก็เริ่มแสดงการสึกหรอ ในการขับรถช่วงบ่ายวันหนึ่ง ฉันสังเกตเห็นมาตรวัดอุณหภูมิคืบคลานไปถึง H (สูง) หลังจากพูดคุยกันไม่กี่ครั้ง ฉันก็พา Betsy ไปที่แผนกบริการของตัวแทนจำหน่ายในพื้นที่เพื่อเริ่มต้นการทดสอบด้วยการทำร้ายตัวเองเป็นเวลาหนึ่งสัปดาห์

ในการเยี่ยมชมครั้งแรก ฉันรีบให้รายละเอียดระดับสูงอย่างรวดเร็ว “หลังจากนั้นไม่กี่นาที รถบรรทุกก็ร้อนจัด” ฉันพูด หกชั่วโมงกับเงิน $100 ต่อมา ฉันก็เอารถบรรทุกของฉันกลับมา ช่างเทคนิคไม่สามารถทำให้เกิดปัญหาซ้ำได้ ดังนั้นฉันจึงถูกส่งกลับบ้านพร้อมค่าธรรมเนียมการวินิจฉัย และขอให้กลับมาอีกครั้งหากเกิดขึ้นอีก ในการเยี่ยมครั้งที่สอง ฉันรีบเสริมว่าปัญหาเกิดขึ้นหลังจากขับรถไป 18 นาทีหรือ 14 ไมล์นานกว่า 45 นาทีในการเดินทาง หกชั่วโมงและประมาณ 375 ดอลลาร์ต่อมา ฉันเอารถบรรทุกของฉันกลับมา ช่างเทคนิคสามารถสร้างปัญหาขึ้นมาใหม่ได้ด้วยรายละเอียดใหม่ และพวกเขาก็เปลี่ยนเทอร์โมสตัทและสายยางใหม่ ในการเยี่ยมครั้งที่สาม ช่างเทคนิคโทรมาแต่เช้าว่า “คุณ… Rhue คุณจะต้องมีหม้อน้ำใหม่”

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

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

ขั้นแรกรับและให้รายละเอียดทั้งหมด

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

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

ประการที่สอง อธิบายสิ่งที่คุณทำ (ดีหรือไม่ดี)

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

สุดท้าย ดำเนินการตามคำแนะนำก่อนหน้านี้

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

สองวันหลังจากการเยี่ยมเยียนครั้งที่สาม หม้อน้ำตัวใหม่ได้รับสินค้าที่ถูกจองแล้ว และฉันก็เปลี่ยนหม้อน้ำใหม่ ฉันขับรถเบ็ตซี่ต่อไปอีกหลายปีก่อนที่จะเปลี่ยนเป็นรถเอสยูวีสำหรับครอบครัวในที่สุด

ทำซ้ำโดยได้รับอนุญาตจากSIOS