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

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

ความท้าทายทั่วไปในการเพิ่มประสิทธิภาพระบบไอทีเพื่อความพร้อมใช้งานสูง

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

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

สุดท้ายนี้ หลักการของการควบคุมการเข้าถึงจะซับซ้อนขึ้นเล็กน้อยเมื่อกำหนดค่าระบบที่มีความพร้อมใช้งานสูง ในขณะที่แต่ละทีม (IE, ทีม DB, ทีม SAP, ทีมคลาวด์ – ไม่ว่าจะมีการกระจายสิ่งต่าง ๆ ก็ตาม) แต่ละทีมต้องการสิทธิ์ผ่านโดเมนของตน ผู้ดูแลระบบที่จัดการโซลูชัน HA อาจเห็นว่าพวกเขามีสิทธิ์เพิ่มเติมที่สามารถเข้าถึงได้ผ่านโซลูชัน HA (IE , การเริ่มต้นเฟลโอเวอร์ของแอปพลิเคชัน, การสร้างการสื่อสารระหว่างโหนด, การล็อค/ปลดล็อคที่เก็บข้อมูล ฯลฯ) ด้วยเหตุนี้ จึงเป็นสิ่งสำคัญที่จะต้องพิจารณาการดำเนินการที่มีอยู่ผ่านโซลูชัน HA เมื่อมอบหมายสิทธิ์การเข้าถึง อาจเป็นเรื่องที่เกี่ยวข้องที่จะอนุญาตให้มีการควบคุม HA สำหรับผู้ใช้ระดับรูทเท่านั้น หรือคุณอาจกำหนดขั้นตอนสำหรับการดำเนินการผ่านโซลูชัน HA เพื่อให้ทีมได้รับการแจ้งเตือนและการดำเนินการอาจถูกติดตาม ไม่ว่าในมุมมองของหลักการของสิทธิ์ขั้นต่ำ โซลูชัน HA นำเสนอความซับซ้อนที่ควรพิจารณาเพื่อให้แน่ใจว่าแอปพลิเคชันและระบบจะสามารถเข้าถึงได้และไม่แน่นอนโดยฝ่ายที่ได้รับมอบหมายเท่านั้น

บทบาทของกลยุทธ์การเฟลโอเวอร์และการกู้คืนความเสียหายในการประกันเวลาทำงานของระบบ

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

การสร้างสมดุลระหว่างความคุ้มค่าและความพร้อมใช้งานสูง: กลยุทธ์สำหรับองค์กร

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

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

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

การใช้ความพร้อมใช้งานสูง: แนวทางปฏิบัติที่ดีที่สุด

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

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

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

เทคโนโลยี 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