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

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

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

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

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

‘การสลับ’ คือการย้ายลำดับชั้นของคุณจากโหนดหลักไปยังโหนดรองด้วยตนเอง ซึ่งสามารถทำได้ผ่าน 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

SIOS LifeKeeper สำหรับการฝึกอบรมผู้ดูแลระบบ Linux พร้อมใช้งานบน Udemy

SIOS LifeKeeper สำหรับการฝึกอบรมผู้ดูแลระบบ Linux พร้อมใช้งานบน Udemy

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

เทคโนโลยีเอสไอโอเอสได้ประกาศความพร้อมของการฝึกอบรมผู้ดูแลระบบ SIOS LifeKeeper สำหรับ Linuxอูเดมี่ตลาดทักษะออนไลน์และแพลตฟอร์มการเรียนรู้ การพัฒนานี้ตอกย้ำความมุ่งมั่นของ SIOS ในการอำนวยความสะดวกด้านความพร้อมใช้งานของแอปพลิเคชันที่สำคัญโดยจัดเตรียมธุรกิจต่างๆ ทั่วโลกให้มีความพร้อมใช้งานสูงอย่างครอบคลุมและการกู้คืนจากภัยพิบัติ (ฮ่า/ดร) ฝึกอบรมทางเทคนิค.

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

“ความร่วมมือกับ Udemy ครั้งนี้ถือเป็นก้าวสำคัญในภารกิจของเราในการทำให้ทุกคนสามารถเข้าถึงความเชี่ยวชาญของ SIOS HA/DR” Margaret Hoagland รองประธานฝ่ายการขายและการตลาดทั่วโลกของ SIOS Technology Corp. “ด้วยการใช้ประโยชน์จากแพลตฟอร์มของ Udemy เราสามารถเข้าถึงวงกว้างได้ ผู้ชมของผู้เชี่ยวชาญด้านไอที เพิ่มขีดความสามารถให้พวกเขาด้วยความรู้และทักษะที่จำเป็นเพื่อให้แน่ใจว่ามีความพร้อมใช้งานสูงและการกู้คืนความเสียหายในองค์กรของพวกเขา”

ผู้เรียนสามารถเข้าถึงหลักสูตรการฝึกอบรมผู้ดูแลระบบ SIOS LifeKeeper สำหรับ Linux ได้ด้วยการสร้างบัญชีฟรีบน Udemy (www.udemy.com) ก่อน แล้วลงทะเบียนด้วยอีเมลธุรกิจของตน เมื่อลงทะเบียนแล้วให้ส่งแบบฟอร์มที่เว็บไซต์การฝึกอบรม SIOSโดยใช้อีเมลธุรกิจเดียวกันกับที่เคยลงทะเบียนกับ Udemy เพื่อรับคำเชิญเข้าร่วมหลักสูตร

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

เทคโนโลยี SIOS เข้าร่วมโครงการ Nutanix Elevate Partner

เทคโนโลยี SIOS เข้าร่วมโครงการ Nutanix Elevate Partner

SIOS เทคโนโลยีคอร์ปอเรชั่น– ประกาศเป็นสมาชิกในโปรแกรมพันธมิตร Nutanix Elevateซึ่งถือเป็นก้าวสำคัญในการนำเสนอโซลูชันการทำคลัสเตอร์ HA ที่ใช้งานง่ายสำหรับแอปพลิเคชันที่สำคัญภายในสภาพแวดล้อมของ Nutanix AHV

การเสร็จสิ้นการกำหนดการตรวจสอบความถูกต้องของ Nutanix Ready ที่มอบให้กับ SIOS แสดงให้เห็นถึง SIOSไลฟ์คีปเปอร์และDataKeeperความสามารถในการทำงานร่วมกันของ Nutanix กับโครงสร้างพื้นฐานของ Nutanix ส่วนหนึ่งของการตรวจสอบนี้ พันธมิตรทั้ง 2 รายกำลังร่วมมือกันเพื่อช่วยให้ลูกค้าร่วมได้รับประโยชน์จากนวัตกรรมอย่างต่อเนื่อง

ประวัติของ SIOS ประกอบด้วยการใช้งานที่ประสบความสำเร็จสำหรับลูกค้าที่เปิดใช้งาน HA และ DR ด้วยใบอนุญาตมากกว่า 80,000 ใบที่ติดตั้งทั่วโลก ปกป้องแอปพลิเคชันสำหรับบริษัทในอุตสาหกรรมต่างๆ

ผลิตภัณฑ์ LifeKeeper และ DataKeeper ผ่านการทดสอบการตรวจสอบเรียบร้อยแล้ว ซึ่งสามารถช่วยเพิ่มความมั่นใจให้กับลูกค้าเกี่ยวกับความเข้ากันได้ของโซลูชัน LifeKeeper สำหรับ Linux ช่วยให้ Nutanix สามารถนำเสนอ HA ที่เรียบง่ายและเชื่อถือได้แก่ลูกค้าสำหรับแอปพลิเคชันที่สำคัญทางธุรกิจซึ่งได้รับการสนับสนุนโดยความเชี่ยวชาญ HA เชิงลึก ด้วยผลิตภัณฑ์ SIOS ลูกค้าของ Nutanix ที่มีสภาพแวดล้อมที่ซับซ้อน เช่น SAP, HANA, SQL Server และอื่นๆ ที่ทำงานบน SUSE Linux, Red Hat Linux, Oracle Linux, Rocky Linux และ Windows Server สามารถประหยัดเวลาและลดการหยุดทำงานที่มีค่าใช้จ่ายสูงได้ด้วยการติดตั้ง บำรุงรักษา และการจัดการสภาพแวดล้อม HA ที่เสถียรและเชื่อถือได้

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

ผลิตภัณฑ์ SIOS ได้รับรางวัล “Nutanix Ready Validated” ได้แก่:

• LifeKeeper สำหรับ Linux 9.8.0
• LifeKeeper สำหรับ Windows 8.10.0
• DataKeeper สำหรับ Windows 8.10.0

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

ข้อมูลเพิ่มเติมเกี่ยวกับโซลูชัน SIOS-Nutanix

ทีละขั้นตอน – SQL Server 2019 Failover Cluster Instance (FCI) ใน OCI

ละขั้นตอน – SQL Server 2019 Failover Cluster Instance (FCI) ใน OCI

การแนะนำ

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

การปรับใช้ข้ามโดเมนความพร้อมใช้งาน:OCI เสนอ SLA ความพร้อมใช้งาน 99.99% เมื่อคุณปรับใช้เครื่องเสมือน (VM) สองเครื่องขึ้นไปในโดเมนความพร้อมใช้งานที่แตกต่างกันภายในภูมิภาค OCI เดียวกัน

การปรับใช้ข้ามโดเมนข้อบกพร่อง:หากคุณปรับใช้ VM ทั่วทั้ง Fault Domains OCI จะให้ SLA ความพร้อมใช้งาน 99.95% สิ่งสำคัญคือต้องทราบว่าไม่ใช่ทุกภูมิภาคของ OCI ที่มีโดเมนความพร้อมใช้งานหลายโดเมน ดังนั้นในบางภูมิภาค การปรับใช้ข้ามโดเมนข้อบกพร่องจะเป็นทางเลือกเดียวของคุณ

การปรับใช้ VM เดี่ยว:สำหรับการปรับใช้ที่เกี่ยวข้องกับ VM เดียว SLA จะอยู่ที่ 99.9%

เฟรมเวิร์กนี้หมายความว่า OCI รับประกันการเชื่อมต่อภายนอกในระดับหนึ่งโดยขึ้นอยู่กับวิธีที่คุณปรับใช้ VM ของคุณ:

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

เพื่อให้เป็นไปตามเกณฑ์สำหรับ SLA ความพร้อมใช้งาน 99.99% ใน OCI จำเป็นอย่างยิ่งที่จะต้องปรับใช้ VM ของคุณในโดเมนความพร้อมใช้งานหลายแห่ง โพสต์นี้จะแนะนำคุณในการออกแบบโครงสร้างพื้นฐาน OCI ของคุณเพื่ออำนวยความสะดวกให้กับ SQL Server Failover Cluster Instances ที่ครอบคลุมโดเมนความพร้อมใช้งาน เพื่อให้มั่นใจถึงความพร้อมใช้งานและความน่าเชื่อถือสูงสุดสำหรับแอปพลิเคชันทางธุรกิจที่สำคัญของคุณ

สร้าง VCN และซับเน็ต

ในคู่มือนี้ ฉันถือว่าคุณมีความคุ้นเคยกับ Oracle Cloud Infrastructure (OCI) และความเข้าใจพื้นฐานเกี่ยวกับแนวคิดด้านเครือข่าย ฉันจะอธิบายงานการกำหนดค่าทั่วไปพร้อมคำอธิบาย และให้คำแนะนำเพิ่มเติมเมื่อจำเป็นเพื่อจัดการกับความท้าทายทั่วไปที่พบในเครือข่าย OCI

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

แม้ว่าเราจะไม่ครอบคลุมการกำหนดค่าที่ขยาย Fault Domains แทนที่จะเป็น Availability Domains แต่ก็มีผลเช่นเดียวกันกับคลัสเตอร์ที่ขยาย Fault Domains โหนดทั้งหมดต้องอยู่ในเครือข่ายย่อยที่แตกต่างกัน

ในสถานการณ์ของเรา เราจะตั้งค่าเครือข่ายย่อยสามเครือข่ายในโดเมนความพร้อมใช้งานที่แตกต่างกันสามโดเมนภายใน Virtual Cloud Network (VCN) เดียวใน OCI

วีซีเอ็น: 10.0.0.0/16

• AD1: 10.0.0.0/18
• AD2: 10.0.64.0/18
• AD3: 10.0.128.0/18

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

สร้าง VCN

สร้างเครือข่ายย่อยสามเครือข่ายใน VCN

สร้างเกตเวย์อินเทอร์เน็ต

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

แก้ไขรายการความปลอดภัยเริ่มต้น

แก้ไขตารางเส้นทาง

แก้ไขตารางเส้นทางเพื่อให้การรับส่งข้อมูลทั้งหมดที่กำหนดไว้สำหรับภายนอก VCN ถูกกำหนดเส้นทางผ่านอินเทอร์เน็ตเกตเวย์

สร้างกลุ่มความปลอดภัยเครือข่าย

แก้ไขรายการความปลอดภัย

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

แก้ไขตัวเลือก DHCP

เพื่อให้ Active Directory ทำงานได้อย่างถูกต้อง คุณต้องตั้งค่า DC1 เป็นเซิร์ฟเวอร์ DNS หลักในตัวเลือก DHCP ดังที่แสดงด้านล่าง ในกรณีนี้ เราตั้งค่าเป็น 10.0.0.100 ซึ่งเป็น IP แบบคงที่ของตัวควบคุมโดเมนที่เรากำลังกำหนดค่า คุณควรเพิ่มโดเมนของคุณลงในโดเมนการค้นหาที่กำหนดเองด้วย ในกรณีนี้ เราจะใช้โดเมนชื่อ datakeeper.local ซึ่งเราจะสร้างในภายหลังเมื่อเรากำหนดค่าตัวควบคุมโดเมนของเรา

จัดเตรียม VM

เมื่อกำหนดค่า VCN แล้ว ก็ถึงเวลาเริ่มจัดเตรียม VM ในตัวอย่างนี้ เราจะใช้ Windows Server 2022 และ SQL Server 2019 อย่างไรก็ตาม ขั้นตอนที่อธิบายในบทความนี้แทบจะเหมือนกันในทุกเวอร์ชันของ Windows Server และ SQL Server ดังนั้นคุณไม่ควรมีปัญหาใดๆ ไม่ว่าเวอร์ชันของ Windows Server จะเป็นเวอร์ชันใดก็ตาม Windows หรือ SQL Server ที่คุณวางแผนจะใช้

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

ในการกำหนดค่าตัวอย่าง เราจะปรับใช้ Active Directory ในอินสแตนซ์ (DC1) ที่จะทำหน้าที่เป็นพยานในการแชร์ไฟล์ด้วย

AD1 – DC1 (10.0.0.100)

AD2 – SQL1 – (10.0.64.100, 10.0.64.101, 10.0.64.102)

AD3 – SQL2 – (10.0.128.100, 10.0.128.101, 10.0.128.102)

คุณอาจสังเกตเห็นว่าแต่ละโหนดคลัสเตอร์ (SQL1, SQL2) มีที่อยู่ IP สามแห่ง ที่อยู่แรกคือที่อยู่ IP ส่วนตัวของอินสแตนซ์ ที่อยู่ IP อีกสองแห่งจะถูกเพิ่มเป็นที่อยู่รองในแต่ละอินสแตนซ์ ที่อยู่ IP เหล่านี้ใช้สำหรับที่อยู่ IP ของคลัสเตอร์หลักและที่อยู่ IP เสมือนที่เกี่ยวข้องกับทรัพยากรชื่อเครือข่าย SQL Server FCI

เมื่อเราจัดเตรียมโหนดคลัสเตอร์ เราจะใช้อิมเมจ Windows Server 2022 พื้นฐานโดยไม่มีซอฟต์แวร์ SQL Server รวมอยู่ด้วย แต่เราจะดาวน์โหลดสื่อการติดตั้ง SQL Server และใช้สิทธิ์การใช้งาน SQL Server แบบถาวรแทนสิทธิ์การใช้งานแบบ “จ่ายตามการใช้งาน” ที่มีอยู่บน Marketplace

ส่วนต่อไปนี้จะแสดงกระบวนการจัดเตรียม VM ทั้งสามตัวที่ใช้ในตัวอย่างนี้

เตรียมใช้งาน DC1 ใน FD1

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

เมื่อระบุรายละเอียดอินสแตนซ์ ตรวจสอบให้แน่ใจว่าคุณเลือก VCN และซับเน็ตที่เหมาะสมสำหรับตำแหน่งที่เหมาะสม ในหน้าจอแรกนี้ คุณยังระบุ IP แบบคงที่ที่คุณต้องการเชื่อมโยงกับอินสแตนซ์นี้ด้วย

เตรียมใช้งาน SQL1 ใน FD2

ตามที่กล่าวไว้ก่อนหน้านี้ ตัวอย่างนี้ใช้การติดตั้งพื้นฐานของ Windows Server 2022 SQL Server 2019 จะถูกดาวน์โหลดในภายหลังและใช้สำหรับการติดตั้ง SQL Server FCI

เตรียมใช้งาน SQL2 ใน FD3

การเพิ่มเล่มเพิ่มเติม

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

หลายเล่ม

คุณสามารถเพิ่มหลายวอลุ่มเพื่อแยกข้อมูล บันทึก และการสำรองข้อมูลของคุณได้

ประเภทการจัดเก็บ: มีประเภทการจัดเก็บที่หลากหลายเพื่อให้เหมาะกับความต้องการที่แตกต่างกัน

วิธีการแนบ

มีหลายวิธีในการแนบที่เก็บข้อมูลเข้ากับเซิร์ฟเวอร์ของคุณ

ตัวอย่างการกำหนดค่า

ด้านล่างนี้ เราได้รวมภาพหน้าจอที่สาธิตการกำหนดค่าพื้นที่จัดเก็บข้อมูลที่เป็นไปได้จำนวนหนึ่งไว้ด้วย นี่เป็นตัวอย่างเชิงปฏิบัติเพื่อช่วยในการทำความเข้าใจกระบวนการตั้งค่า กระบวนการนี้ควรจะเสร็จสิ้นบน SQL1 และ SQL2

สร้างบล็อควอลลุม

ขั้นแรก สร้างบล็อควอลลุมในโดเมนความพร้อมใช้งานที่เหมาะสมสำหรับ SQL1 และ SQL2

แนบวอลุ่ม

เมื่อสร้างวอลลุมแล้ว คุณต้องแนบไปกับอินสแตนซ์

ประเด็นสำคัญที่ต้องจำ

การตั้งค่ามีความยืดหยุ่น คุณสามารถกำหนดค่าวอลุ่มหนึ่งหรือหลายวอลุ่มได้ตามความต้องการเฉพาะของคุณ

พิจารณาประเภทพื้นที่เก็บข้อมูลและวิธีการแนบที่แตกต่างกันสำหรับการกำหนดค่าของคุณ

เพิ่มที่อยู่ IP รอง

เพื่อให้ Windows Server Failover Clustering ทำงานอย่างถูกต้องใน OCI คุณต้องเพิ่มที่อยู่ IP ของคลัสเตอร์เป็นที่อยู่รองบนอินเทอร์เฟซเครือข่ายเสมือน (VNIC) ที่แนบกับ SQL1 และ SQL1 ดังที่คุณจำได้ เราได้พูดคุยกันโดยใช้ที่อยู่ IP ต่อไปนี้บนแต่ละโหนดคลัสเตอร์ของเรา

	SQL1	SQL2
ที่อยู่หลัก	10.0.64.100	10.0.128.100
คลัสเตอร์ IP 1 (ทรัพยากรคลัสเตอร์หลัก)	10.0.64.101	10.0.128.101
IP คลัสเตอร์ 2(IP คลัสเตอร์เซิร์ฟเวอร์ SQL)	10.0.64.102	10.0.128.102

บนทั้ง SQL1 และ SQL2 ให้แก้ไข VNIC ที่แนบมาเพื่อเพิ่มที่อยู่รอง

สร้างโดเมน

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

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

เปิดใช้งานบริการโดเมน Active Directory

เลื่อนระดับเซิร์ฟเวอร์เป็นตัวควบคุมโดเมน

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

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

ก่อนที่จะเปิดใช้งานบริการโดเมน Active Directory คุณต้องเปิดใช้งานบัญชีผู้ดูแลระบบภายในและเข้าสู่ระบบด้วยบัญชีนั้น

ใช้โปรแกรม RDP ที่คุณชื่นชอบ เชื่อมต่อกับ DC1 โดยใช้ที่อยู่ IP สาธารณะที่เชื่อมโยงกับอินสแตนซ์ เพิ่มบทบาทบริการโดเมน Active Directory

หลังจากการติดตั้งเสร็จสมบูรณ์ ให้เลื่อนระดับเซิร์ฟเวอร์นี้เป็นตัวควบคุมโดเมน

เพื่อจุดประสงค์ของเรา เราจะสร้างโดเมนใหม่

รีบูต DC1 และไปยังส่วนถัดไป

เข้าร่วม SQL1 และ SQL2 กับโดเมน

เตรียมที่จัดเก็บ

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

กำหนดค่าคุณสมบัติการทำคลัสเตอร์ล้มเหลว

เปิดใช้งานคุณลักษณะ Failover Clustering บนทั้ง SQL1 และ SQL2

เรียกใช้คำสั่ง PowerShell นี้บน SQL1 และ SQL2

ติดตั้ง WindowsFeature – ชื่อการทำคลัสเตอร์ล้มเหลว – รวม ManagementTools

ตรวจสอบคลัสเตอร์ของคุณ

เรียกใช้คำสั่ง PowerShell นี้จาก SQL1 หรือ SQL2

คลัสเตอร์ทดสอบ – โหนด sql1, sql2

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

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

สร้างคลัสเตอร์

ต่อไป คุณจะสร้างคลัสเตอร์ ในตัวอย่างด้านล่าง คุณจะสังเกตเห็นว่าฉันใช้ที่อยู่ IP สองแห่งที่เราวางแผนจะใช้ คือ 10.0.64.101 และ 10.0.128.101 คุณสามารถเรียกใช้ Powershell นี้ได้จากโหนดคลัสเตอร์ใดก็ได้

คลัสเตอร์ใหม่ – ชื่อคลัสเตอร์ 1 – โหนด sql1, sql2 – ที่อยู่คงที่ 10.0.64.101, 10.0.128.101

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

เพิ่มพยานการแชร์ไฟล์

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

ในตัวอย่างด้านล่าง พยานการแบ่งปันไฟล์จะถูกสร้างขึ้นบน DC1 ซึ่งอยู่ใน FD1

บน DC1 ให้สร้างการแชร์ไฟล์และกำหนดสิทธิ์การอ่าน-เขียนของวัตถุชื่อคลัสเตอร์ (CNO) ในโฟลเดอร์ เพิ่มสิทธิ์สำหรับ CNO บนแท็บ Share และ Security ของโฟลเดอร์ที่คุณสร้างขึ้น ในตัวอย่างด้านล่าง ฉันได้สร้างโฟลเดอร์ชื่อ “Witness”

เมื่อสร้างโฟลเดอร์และกำหนดสิทธิ์ที่เหมาะสมให้กับ CNO แล้ว ให้รันคำสั่ง PowerShell ต่อไปนี้บน SQL1 หรือ SQL2

ชุด-ClusterQuorum -คลัสเตอร์คลัสเตอร์1 -FileShareWitness \\dc1\Witness

คลัสเตอร์ของคุณควรมีลักษณะดังนี้เมื่อคุณเปิดตัว Failover Cluster Manager บน SQL1 หรือ SQL2

การสร้าง FCI เซิร์ฟเวอร์ SQL

ติดตั้ง DataKeeper Cluster Edition

ก่อนที่คุณจะดำเนินการขั้นตอนต่อไปได้ คุณจะต้องติดตั้ง DataKeeper Cluster Edition บนทั้ง SQL1 และ SQL2 ดาวน์โหลดไฟล์ปฏิบัติการการตั้งค่าและรันการตั้งค่า DataKeeper บนทั้งสองโหนด อ้างถึงเอกสาร SIOSสำหรับคำแนะนำเฉพาะเกี่ยวกับการติดตั้ง

สร้างทรัพยากรโวลุ่ม DataKeeper

เปิดใช้งาน DataKeeper UI บนโหนดคลัสเตอร์ใดโหนดหนึ่งและสร้าง DataKeeper Volume Resource ของคุณดังที่แสดงด้านล่าง

เชื่อมต่อกับเซิร์ฟเวอร์ทั้งสอง อันดับแรกคือ SQL1 และ SQL2

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

คลิกสร้างงานเพื่อเริ่มตัวช่วยสร้างงาน

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

คลิก “ใช่” ที่นี่เพื่อลงทะเบียนทรัพยากร DataKeeper Volume ใน Available Storage

DataKeeper Volume D ปรากฏใน Failover Cluster Manager ในที่เก็บข้อมูลที่มีอยู่

ติดตั้งโหนดแรกของ SQL Server FCI บน SQL1

หลังจากที่สร้างคลัสเตอร์หลักแล้วและทรัพยากรโวลุ่ม DataKeeper อยู่ใน Available Storage ก็ถึงเวลาติดตั้ง SQL Server บนโหนดคลัสเตอร์แรก ตามที่กล่าวไว้ก่อนหน้านี้ ตัวอย่างที่นี่แสดงการกำหนดค่าคลัสเตอร์โดยใช้ SQL 2019 และ Windows 2022 แต่ขั้นตอนทั้งหมดที่อธิบายไว้ในตัวอย่างนี้แทบจะเหมือนกัน ไม่ว่าคุณจะพยายามปรับใช้ Windows Server หรือ SQL Server เวอร์ชันใดก็ตาม

ทำตามตัวอย่างด้านล่างเพื่อติดตั้ง SQL Server บน SQL1

ชื่อที่คุณระบุด้านล่างคือจุดเข้าใช้งานไคลเอ็นต์ นี่คือชื่อที่แอปพลิเคชันเซิร์ฟเวอร์ของคุณจะใช้เมื่อต้องการเชื่อมต่อกับ SQL Server FCI

บนหน้าจอนี้ คุณจะเพิ่มที่อยู่ IP รองของ SQL1 ที่เราระบุไว้ก่อนหน้านี้ในส่วนการวางแผนของส่วนที่ 1ของซีรีย์นี้

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

ติดตั้งโหนดที่สองของ SQL Server FCI บน SQL2

ถึงเวลาติดตั้ง SQL Server บน SQL2 แล้ว

เมื่อคุณติดตั้ง SQL Server บนโหนดคลัสเตอร์ทั้งสองแล้ว Failover Cluster Manager ควรมีลักษณะเช่นนี้

ติดตั้ง Studio จัดการเซิร์ฟเวอร์ SQL

ใน SQL Server เวอร์ชัน 2016 และใหม่กว่า คุณต้องดาวน์โหลดและติดตั้ง SSMS เป็นตัวเลือกแยกต่างหากดังที่แสดงด้านล่าง หมายเหตุ: ใน SQL Server เวอร์ชันก่อนหน้า SQL Server Management Studio (SSMS) เป็นตัวเลือกที่คุณสามารถเลือกติดตั้งระหว่างการติดตั้ง SQL

เมื่อติดตั้ง SSMS แล้ว ให้เชื่อมต่อกับคลัสเตอร์ผ่านจุดเข้าใช้งานไคลเอ็นต์ SQL Server FCI ของคุณควรมีลักษณะเช่นนี้

ข้อควรพิจารณาเกี่ยวกับหลายซับเน็ต

ข้อควรพิจารณาที่ใหญ่ที่สุดประการหนึ่งสำหรับการรัน SQL Server FCI ใน OCI คือข้อเท็จจริงที่ว่าโหนดคลัสเตอร์อยู่ในเครือข่ายย่อยที่แตกต่างกัน Microsoft เริ่มคำนึงถึงข้อเท็จจริงที่ว่าโหนดคลัสเตอร์อาจอยู่ในเครือข่ายย่อยที่แตกต่างกันโดยการเพิ่มฟังก์ชัน “OR” ใน Windows Server 2008 R2 ตามที่อธิบายไว้ใน Microsoftเอกสารประกอบ–

เอามาจากการทำคลัสเตอร์หลายซับเน็ตเซิร์ฟเวอร์ SQL (SQL Server)

สิ่งสำคัญที่อธิบายไว้ในเอกสารประกอบคือแนวคิดของ RegisterAllProvidersIP บนทรัพยากรชื่อเครือข่าย ซึ่งเปิดใช้งานตามค่าเริ่มต้นเมื่อคุณสร้าง SQL Server FCI ตามที่อธิบายไว้ เมื่อเปิดใช้งาน เรคคอร์ด A สองเรคคอร์ดจะถูกลงทะเบียนใน DNS พร้อมด้วยทรัพยากรชื่อเครือข่าย หนึ่งเรคคอร์ดสำหรับแต่ละที่อยู่ IP

การใช้ฟังก์ชัน “OR” เฉพาะที่อยู่ IP ที่เชื่อมโยงกับซับเน็ตที่ใช้งานอยู่เท่านั้นที่จะออนไลน์ และอีกอันหนึ่งจะแสดงเป็นออฟไลน์ หากไคลเอนต์ของคุณรองรับการเพิ่ม multisubnetfailover=true ให้กับสตริงการเชื่อมต่อ ที่อยู่ IP ทั้งสองจะถูกลองใช้พร้อมกัน และไคลเอนต์จะเชื่อมต่อกับโหนดที่ใช้งานอยู่โดยอัตโนมัติ นั่นเป็นวิธีที่ง่ายที่สุดและเป็นวิธีการเริ่มต้นของการเปลี่ยนเส้นทางไคลเอนต์ในคลัสเตอร์หลายซับเน็ต

เอกสารประกอบกล่าวต่อไปว่าหากไคลเอ็นต์ของคุณไม่รองรับฟังก์ชัน multisubnetfailover=true คุณควร “ลองปรับการหมดเวลาการเชื่อมต่อในสตริงการเชื่อมต่อไคลเอ็นต์ภายใน 21 วินาทีสำหรับที่อยู่ IP เพิ่มเติมแต่ละรายการ สิ่งนี้ทำให้แน่ใจได้ว่าความพยายามในการเชื่อมต่อใหม่ของไคลเอ็นต์จะไม่หมดเวลาก่อนที่จะสามารถวนผ่านที่อยู่ IP ทั้งหมดใน FCI แบบหลายซับเน็ตของคุณได้”

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

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

รับ ClusterResource – ชื่อ sqlcluster | ตั้งค่า ClusterParameter – ชื่อ HostRecordTTL – ค่า 300

โปรดทราบว่าอาจต้องใช้เวลาสักระยะก่อนที่การเปลี่ยนแปลงเซิร์ฟเวอร์ DNS ที่รวม AD ของคุณจะเผยแพร่ทั่วทั้งฟอเรสต์ของคุณ

สรุป

คู่มือทางเทคนิคนี้ให้ภาพรวมที่ครอบคลุมของการตั้งค่า SQL Server 2019 Failover Cluster Instance (FCI) ใน Oracle Cloud Infrastructure (OCI) เริ่มต้นด้วยการเน้นถึงความสำคัญของการทำความเข้าใจ SLA ความพร้อมใช้งานของ OCI ที่แตกต่างกันไปตามกลยุทธ์การปรับใช้: 99.99% สำหรับการปรับใช้ข้ามโดเมนความพร้อมใช้งาน, 99.95% สำหรับการปรับใช้ข้ามโดเมนข้อบกพร่อง และ 99.9% สำหรับการปรับใช้ VM เดี่ยว คู่มือนี้เน้นย้ำว่า SLA ครอบคลุมความพร้อมใช้งานของ VM ไม่ใช่แอปพลิเคชันหรือบริการที่ทำงานอยู่บนนั้น จึงจำเป็นต้องมีมาตรการเพิ่มเติมสำหรับความพร้อมใช้งานของแอปพลิเคชัน

คู่มือนี้ให้รายละเอียดเกี่ยวกับขั้นตอนเริ่มต้นของการสร้าง Virtual Cloud Network (VCN) และซับเน็ตใน OCI โดยเน้นถึงความจำเป็นในแผนเครือข่ายที่รองรับโดเมนความพร้อมใช้งานอย่างน้อยสามโดเมนเพื่อจุดประสงค์ในการทำคลัสเตอร์ โดเมนความพร้อมใช้งานแต่ละโดเมนต้องอยู่ในเครือข่ายย่อยที่แตกต่างกัน ซึ่งเป็นข้อกำหนดที่ใช้กับคลัสเตอร์ที่ขยาย Fault Domains เช่นกัน โดยให้การกำหนดค่าเฉพาะสำหรับการตั้งค่าเครือข่ายย่อยสามเครือข่ายในโดเมนความพร้อมใช้งานที่แตกต่างกันภายใน VCN เดียว

นอกจากนี้ คู่มือนี้ยังอธิบายกระบวนการสร้างอินเทอร์เน็ตเกตเวย์และการแก้ไขรายการความปลอดภัยเริ่มต้นและตารางเส้นทางเพื่ออำนวยความสะดวกในการเข้าถึงและการรักษาความปลอดภัยทั่วทั้งโดเมนความพร้อมใช้งาน นอกจากนี้ยังครอบคลุมการกำหนดค่าตัวเลือก DHCP สำหรับความเข้ากันได้ของ Active Directory และสรุปขั้นตอนสำหรับการจัดเตรียม VM ด้วย Windows Server 2022 และ SQL Server 2019 โดยเน้นความสำคัญของชื่อเซิร์ฟเวอร์การวางแผน ที่อยู่ IP และตำแหน่งโซนความพร้อมใช้งาน

จากนั้น คำแนะนำจะเจาะลึกในการเพิ่มวอลลุมเพิ่มเติมสำหรับความต้องการพื้นที่จัดเก็บข้อมูล SQL Server FCI โดยให้รายละเอียดกระบวนการสร้างและการแนบบล็อควอลลุมเข้ากับอินสแตนซ์ นอกจากนี้ยังแนะนำการกำหนดค่าที่อยู่ IP รองสำหรับ Windows Server Failover Clustering ใน OCI

ถัดไป คำแนะนำจะกล่าวถึงการตั้งค่าตัวควบคุมโดเมน รวมถึงการเปิดใช้งานบริการโดเมน Active Directory และการโปรโมตเซิร์ฟเวอร์ไปยังตัวควบคุมโดเมน โดยจะอธิบายขั้นตอนการเตรียมการจัดเก็บข้อมูลและการเปิดใช้งานคุณลักษณะ Failover Clustering บน SQL1 และ SQL2 พร้อมด้วยการตรวจสอบความถูกต้องของคลัสเตอร์และกระบวนการสร้าง

คู่มือนี้จะอธิบายเพิ่มเติมเกี่ยวกับการเพิ่ม File Share Witness เพื่อรักษาองค์ประชุมคลัสเตอร์และการติดตั้ง DataKeeper Cluster Edition สำหรับการจำลองโวลุ่ม โดยให้แนวทางทีละขั้นตอนในการติดตั้ง SQL Server บนโหนดคลัสเตอร์และ SQL Server Management Studio พร้อมด้วยข้อควรพิจารณาสำหรับการปรับใช้หลายซับเน็ต

โดยสรุป คู่มือนี้เสนอพิมพ์เขียวโดยละเอียดสำหรับการปรับใช้และกำหนดค่า SQL Server 2019 FCI ใน OCI ครอบคลุมแง่มุมต่างๆ ตั้งแต่การตั้งค่าเครือข่ายและการจัดเตรียม VM ไปจนถึงการทำคลัสเตอร์ การกำหนดค่าพื้นที่เก็บข้อมูล และการตั้งค่าการควบคุมโดเมน เพื่อให้มั่นใจถึงเวลาทำงานและความน่าเชื่อถือสูงสุดสำหรับแอปพลิเคชันที่สำคัญต่อธุรกิจ .

ดาวน์โหลดคำแนะนำทีละขั้นตอนที่นี่

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