ทำความเข้าใจกับความซับซ้อนของความพร้อมใช้งานสูงสำหรับแอปพลิเคชันที่สำคัญต่อธุรกิจ

ทำความเข้าใจกับความซับซ้อนของความพร้อมใช้งานสูงสำหรับแอปพลิเคชันที่สำคัญต่อธุรกิจ

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

ความพร้อมใช้งานสูงคืออะไร?

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

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

ไอดีซีโมเดล

ข้อตกลงระดับบริการ (SLA) สำหรับความพร้อมใช้งานสูงช่วยให้แน่ใจว่าองค์ประกอบหลักของโครงสร้างพื้นฐานด้านไอทีนั้นใช้งานได้และพร้อมใช้งานในช่วงเวลาทำการ IDC ได้สร้างแบบจำลอง SLA สำหรับความพร้อมใช้งานสูงที่กำหนดห้าระดับด้วยข้อกำหนดด้านเวลาทำงานต่อไปนี้: • AL4 (ความพร้อมใช้งานอย่างต่อเนื่อง—ความทนทานต่อความผิดพลาดของระบบ): ไม่มีการหยุดชะงักของผู้ใช้และเวลาหยุดทำงานทั้งที่วางแผนไว้และไม่ได้วางแผนรวมสูงสุดไม่เกิน 5 นาที 15 วินาทีต่อปี (ความพร้อมใช้งาน 99.999% หรือ "ห้า-เก้า")
• AL3 (ความพร้อมใช้งานสูง—การทำคลัสเตอร์แบบดั้งเดิม): การหยุดชะงักของผู้ใช้น้อยที่สุดและเวลาหยุดทำงานทั้งที่วางแผนไว้และไม่ได้วางแผนรวมสูงสุดไม่เกิน 52 นาที 35 วินาทีต่อปี (ความพร้อมใช้งาน 99.99% หรือ "สี่-เก้า")
• AL2 (การกู้คืน—การจำลองข้อมูลและการสำรองข้อมูล): การขัดจังหวะของผู้ใช้บางรายและเวลาหยุดทำงานทั้งที่วางแผนไว้และไม่ได้วางแผนรวมสูงสุดไม่เกิน 8 ชั่วโมง 45 นาที และ 56 วินาทีต่อปี (ความพร้อมใช้งาน 99.9% หรือ "สามเก้า")
• AL1 (ความน่าเชื่อถือ—ส่วนประกอบที่ถอดเปลี่ยนได้อย่างรวดเร็ว): การหยุดให้บริการทั้งหมดและเวลาหยุดทำงานทั้งที่วางแผนไว้และไม่ได้วางแผนรวม 87 ชั่วโมง 39 นาที 29 วินาทีต่อปี (ความพร้อมใช้งาน 99% หรือ “ทู-ไนน์”)
• AL0 (เซิร์ฟเวอร์ที่ไม่มีการป้องกัน): หยุดให้บริการทั้งหมด และไม่มีการกำหนด SLA สถานะการออนไลน์

ความต้องการความพร้อมใช้งานสูงของคุณขึ้นอยู่กับความสำคัญของระบบโดยรวม แอปพลิเคชัน และปัจจัยอื่นๆ อีกมากมาย ได้แก่: • แอปพลิเคชันมีความสำคัญต่อธุรกิจเพียงใด • ลูกค้าสังเกตเห็นผลกระทบหรือไม่ • แอปพลิเคชันทำงานบ่อยเพียงใด • ผู้ใช้จำนวนเท่าใดที่ได้รับผลกระทบจากการหยุดทำงาน • ฐานข้อมูลหรือแอปพลิเคชันต้องล้มเหลวอย่างรวดเร็วเพียงใดไปยังระบบสำรองเพื่อหลีกเลี่ยงการหยุดชะงัก • ปริมาณข้อมูล การสูญเสียเป็นสิ่งที่ยอมรับได้ โดยทั่วไปความพร้อมใช้งาน Five Nines จะถูกสงวนไว้สำหรับแอปพลิเคชันที่ต้องการการดำเนินการแบบ "Stateful" อย่างต่อเนื่อง สำหรับแอปพลิเคชันที่สำคัญทางธุรกิจ ความพร้อมใช้งานสี่ในเก้าเป็นมาตรฐาน ระบบและแอปพลิเคชันที่ไม่สำคัญ คุณอาจต้องการความพร้อมใช้งานเพียงสองในเก้าเท่านั้น เมื่อพิจารณาเวลาหยุดทำงานที่ยอมรับได้ สิ่งสำคัญคือต้องพิจารณา: • เวลาหยุดทำงานที่ไม่ได้วางแผนไว้ (นั่นคือความล้มเหลวของฮาร์ดแวร์หรือซอฟต์แวร์) • เวลาหยุดทำงานตามแผนสำหรับการบำรุงรักษาฮาร์ดแวร์และซอฟต์แวร์ตามปกติ • เวลาทำงานในระดับแอปพลิเคชันและฐานข้อมูล โซลูชันความพร้อมใช้งานสูงต่างๆ สามารถช่วยให้ธุรกิจบรรลุวัตถุประสงค์ SLA ได้ สำหรับระบบ ฐานข้อมูล และแอปพลิเคชันต่างๆ แม้ว่าความพร้อมใช้งานอย่างต่อเนื่อง (AL4) อาจดูเหมือนเป็นเป้าหมายที่เหมาะสมที่สุดสำหรับการปรับใช้ที่สำคัญต่อธุรกิจ สิ่งสำคัญคือต้องหาสมดุลที่เหมาะสมระหว่างต้นทุนและความพร้อมใช้งาน ความพร้อมใช้งานอย่างต่อเนื่องอาจส่งผลเสียต่อเวลาหยุดทำงานที่จำเป็นสำหรับการบำรุงรักษาตามแผน เนื่องจากโดยทั่วไประบบจะต้องออฟไลน์เมื่อมีการใช้การอัปเดตแอปพลิเคชันหรือระบบปฏิบัติการ เมื่อเทียบกับความพร้อมใช้งานสูง ซึ่งโดยทั่วไปจะอนุญาตให้มีการอัปเดตแบบต่อเนื่อง

เมตริกความพร้อมใช้งานสูง: RTO กับ RPO

นอกจากเวลาทำงานและความพร้อมใช้งานแล้ว Recovery Time Objectives (RTO) และ Recovery Point Objectives (RPO) ยังเป็นเมตริกที่สำคัญที่ใช้ในการประเมินความพร้อมใช้งานสูง (เช่นเดียวกับการกู้คืนความเสียหาย) ในระบบ ฐานข้อมูล หรือแอปพลิเคชัน

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

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

การทำคลัสเตอร์แบบดั้งเดิม

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

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

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

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

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

หลักการออกแบบ

คลัสเตอร์ High Availability ที่ล้ำหน้าที่สุดมีหลักการออกแบบดังต่อไปนี้: • พวกเขาล้มเหลวโดยอัตโนมัติและรวดเร็วไปยังระบบที่ซ้ำซ้อนเมื่อส่วนประกอบที่ใช้งานล้มเหลว • พวกเขารักษาแนวทางปฏิบัติที่ดีที่สุดเฉพาะแอปพลิเคชันในระหว่างและหลังความล้มเหลว • พวกเขาให้ความสามารถในการสลับและสลับกลับด้วยตนเองเพื่อให้การทดสอบมีประสิทธิภาพและการบำรุงรักษาแบบ "ต่อเนื่อง" โดยน้อยที่สุด ดาวน์ไทม์ที่วางแผนไว้ • สามารถตรวจจับความล้มเหลวโดยอัตโนมัติในเครือข่าย ที่เก็บข้อมูล OS ฮาร์ดแวร์ หรือแอปพลิเคชัน • ป้องกันข้อมูลสูญหายในกรณีที่ระบบล้มเหลว • ล้มเหลวในโหนดที่แยกจากกันทางภูมิศาสตร์สำหรับการกู้คืนความเสียหาย

การทำคลัสเตอร์ความพร้อมใช้งานสูง

มีโซลูชันซอฟต์แวร์การทำคลัสเตอร์ที่หลากหลายสำหรับ Windows, Linux ดิสทริบิวชัน และไฮเปอร์ไวเซอร์ต่างๆ (โซลูชันเครื่องเสมือน) กลุ่มหนึ่งรองรับระบบปฏิบัติการเดียวเท่านั้น เช่นต่อไปนี้: • Windows Server Failover Clustering (WSFC): ให้ความพร้อมใช้งานสูงและการกู้คืนความเสียหายสำหรับแอปพลิเคชันที่โฮสต์ เช่น Microsoft SQL Server และ Microsoft Exchange • SUSE Linux Enterprise High Availability Extension (HAE): รองรับการทำคลัสเตอร์ของเซิร์ฟเวอร์ Linux จริงและเสมือนด้วยการทำคลัสเตอร์ที่ขับเคลื่อนด้วยนโยบายและการจำลองข้อมูลอย่างต่อเนื่อง • เครื่องกระตุ้นหัวใจแบบหมวกสีแดง (เครื่องกระตุ้นหัวใจ): สร้างคลัสเตอร์ไซต์เดียวเพื่อประสิทธิภาพ ความพร้อมใช้งานสูง โหลดบาลานซ์ และความสามารถในการปรับขนาด ไม่มีโซลูชันใดที่แสดงรายการในที่นี้ที่สามารถปกป้อง SAP ที่ทำงานบนระบบปฏิบัติการ Oracle Linux เป็นต้น ดังนั้น แต่ละโซลูชันจะจำกัดความยืดหยุ่นและตัวเลือกการปรับใช้ของคุณ ก้าวหน้ายิ่งขึ้น โซลูชันความพร้อมใช้งานสูง เช่น SIOS Protection Suite สำหรับ Linux มอบการป้องกันที่รับรู้แอปพลิเคชันใน Linux ดิสทริบิวชันหลักๆ รวมถึง Oracle Linux, Red Hat และ SUSE

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

ตัวอย่างของแอปพลิเคชัน ฐานข้อมูล และระบบ ERP ที่มีความสำคัญต่อธุรกิจโดยทั่วไปได้รับการปกป้องด้วยการทำคลัสเตอร์เมื่อเกิดข้อผิดพลาด ได้แก่ SAP S/4HANA, SQL Server และแอปพลิเคชันและฐานข้อมูลอื่นๆ

SAP S/4HANA ผู้จำหน่าย Linux หลายรายเสนอส่วนขยายความพร้อมใช้งานสูงแบบโอเพ่นซอร์สสำหรับ SAP ในการสมัครสมาชิก “Enterprise for SAP” สภาพแวดล้อม SAP S/4HANA ประกอบด้วยบริการหลายอย่าง เช่น ABAP SAP Central Service (ASCS), Evaluated Receipt Settlement (ERS) และส่วนประกอบ SAP อื่นๆ ที่จำเป็นต้องได้รับการบำรุงรักษาในตำแหน่งที่ถูกต้องและเริ่มต้นตามลำดับที่ถูกต้อง ในผลิตภัณฑ์การทำคลัสเตอร์แบบโอเพ่นซอร์ส เช่น SUSE HAE และ Red Hat Pacemaker การกำหนดค่าและจัดการคลัสเตอร์ด้วยตนเองในสภาพแวดล้อมที่ซับซ้อนเหล่านี้อาจใช้เวลานานและมีแนวโน้มที่จะเกิดข้อผิดพลาดจากมนุษย์ ซึ่งจะเพิ่มความเสี่ยงต่อการหยุดทำงานอย่างรุนแรงและข้อมูลสูญหาย

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

SAP ยังมี HANA System Replication ซึ่งเป็นคุณสมบัติที่มาพร้อมกับซอฟต์แวร์ HANA มีการซิงโครไนซ์อย่างต่อเนื่องของฐานข้อมูล SAP HANA กับตำแหน่งรองในศูนย์ข้อมูลเดียวกัน ที่ไซต์ระยะไกล หรือในระบบคลาวด์ ข้อมูลจะถูกจำลองไปยังไซต์รองและโหลดไว้ล่วงหน้าในหน่วยความจำ เมื่อเกิดความล้มเหลว ไซต์รองจะเข้าแทนที่โดยไม่ต้องรีสตาร์ทฐานข้อมูล ซึ่งช่วยลด RTO อย่างไรก็ตาม การย้อนกลับไปยังโหนดหลักจะต้องถูกเรียกใช้ด้วยตนเอง HSR จำเป็นต้องจับคู่กับซอฟต์แวร์การทำคลัสเตอร์ที่รู้จักแอปพลิเคชัน เช่น SIOS Protection Suite ที่สามารถตรวจจับความล้มเหลวและจัดการความล้มเหลวได้หากจำเป็น

เซิร์ฟเวอร์ SQL

บริษัทหลายแห่งใช้ SQL Server เป็นฐานข้อมูลส่วนหลังสำหรับแอปพลิเคชันหลักที่สนับสนุนฟังก์ชันทางธุรกิจที่สำคัญ Microsoft WSFC มักใช้เพื่อสนับสนุน Always On Availability Groups (AG) และ SQL Server Failover Cluster Instances (FCI) สำหรับแอปพลิเคชัน SQL Server

อย่างไรก็ตาม WSFC ที่มี AG ต้องการสิทธิ์ใช้งาน SQL Server Enterprise Edition ที่มีค่าใช้จ่ายสูง นอกจากนี้ ด้วย FCI อินสแตนซ์ทั้งหมดจะล้มเหลวผ่านไปยังโหนดสแตนด์บาย ด้วย AG เฉพาะฐานข้อมูลในกลุ่มเท่านั้นที่ได้รับการป้องกัน
โดยใช้ SIOS Data Keeper ด้วย WSFC ช่วยให้คุณสามารถให้การป้องกันความพร้อมใช้งานขั้นสูงขั้นสูงสำหรับ SQL Server โดยใช้สิทธิ์การใช้งาน Standard Edition ที่คุ้มค่า

แอปพลิเคชั่นและฐานข้อมูลอื่น ๆ

ซอฟต์แวร์ SIOS สามารถใช้เพื่อป้องกันแอปพลิเคชันที่สำคัญทางธุรกิจ ฐานข้อมูล และ ERP ที่หลากหลาย รวมถึง Oracle, MaxDB, MySQL, PostgreSQL และ DB2 ซอฟต์แวร์ SIOS เปิดใช้งานการทำคลัสเตอร์และการกู้คืนระบบ

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

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

Epicure ปกป้อง SQL Server ที่สำคัญทางธุรกิจด้วยซอฟต์แวร์ Amazon EC2 และ SIOS SANLess Clustering

Epicure ปกป้อง SQL Server ที่สำคัญทางธุรกิจด้วยซอฟต์แวร์ Amazon EC2 และ SIOS SANLess Clustering

ซอฟต์แวร์การทำคลัสเตอร์ SIOS DataKeeper ช่วยให้ Gulliver International สามารถย้ายระบบไอทีภายในไปยัง Amazon Web Services ได้อย่างปลอดภัย

ซอฟต์แวร์การทำคลัสเตอร์ SIOS DataKeeper ช่วยให้ Gulliver International สามารถย้ายระบบไอทีภายในไปยัง Amazon Web Services ได้อย่างปลอดภัย

การสร้างคลัสเตอร์เซิร์ฟเวอร์ HA Oracle Database ใน AWS

การสร้างคลัสเตอร์เซิร์ฟเวอร์ HA Oracle Database ใน AWS

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

ฉันจะจัดโครงสร้างชุดบล็อกที่เน้นการตั้งค่าสภาพแวดล้อม HA สำหรับการพัฒนา Proof of Concepts โดยใช้ โซลูชั่น SIOS HA เช่น DataKeeper, LifeKeeper และ SIOS Protection Suite หากคุณมีความต้องการเร่งด่วนที่เรายังไม่ได้กล่าวถึง โปรดแจ้งให้เราทราบ แล้วเราจะย้ายการกำหนดค่าของคุณขึ้นไปใน Backlog

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

ฐานข้อมูล AWS HA Oracle SIOS Protection Suite สำหรับ Linux

1. เปิดใช้ Oracle 2 อินสแตนซ์บน Linux
2. ทำให้ Xwindows ทำงาน
3. เชื่อมต่อกับอินสแตนซ์และติดตั้งดิสก์เพิ่มเติม
4. ติดตั้งชุด AWS cli
5. กำหนดค่าความปลอดภัย/การเข้าถึง
6. สร้างรายการเส้นทางสำหรับ IP เสมือน
7. ปิดใช้งานการตรวจสอบต้นทาง/ปลายทางสำหรับ ENI
8. แก้ไข /etc/hosts
9. กำหนดค่า Listener ด้วยชื่อโฮสต์ VIP
10. ปิดใช้งาน SELinux
11. ติดตั้ง SIOS Protection Suite สำหรับ Linux
12. เริ่ม LifeKeeper
13. เชื่อมต่อกับเซิร์ฟเวอร์ที่สอง
14. สร้างเส้นทางการสื่อสาร
15. สร้างทรัพยากร DataKeeper
16. สร้างลำดับชั้นด้วยทรัพยากร Virtual IP
17. สร้างทรัพยากรผู้ฟังของ Oracle
18. สร้างลำดับชั้นด้วย Oracle Database
19. สร้างลำดับชั้นด้วย EC2
20. เปลี่ยนพฤติกรรมการปิดเครื่อง
21. ทดสอบความล้มเหลว

1. เปิดใช้ Oracle 2 อินสแตนซ์บน Linux

ในบล็อกแรกนี้ เราจะตั้งค่าสภาพแวดล้อม HA ใน AWS สำหรับ Oracle Cluster โดยใช้ SIOS LifeKeeper สำหรับ Linuxซึ่งหมายถึงการนำข้อกำหนดเบื้องต้นทั้งหมดออกไปให้พ้นทาง ฉันจะใช้ aws-marketplace/Oracle Database 19.8.0 Enterprise Edition บน Oracle Linux 8 AMIการเปลี่ยนแปลงเหล่านี้บ่อยครั้งและอาจเป็นเรื่องยากที่จะค้นหาสิ่งที่ถูกต้องซึ่งตรงกับความต้องการของคุณAMI นี้เป็นความพยายามครั้งที่ 3 ของฉันเพราะการติดตั้งอะไรก็ตาม โดยเฉพาะอย่างยิ่งบางอย่างเช่น Oracle ในระบบคลาวด์นั้นทำได้ยากมาก เนื่องจากปัญหาเกี่ยวกับพื้นที่เก็บข้อมูล การออกใบอนุญาต การลงทะเบียน และความปลอดภัยAMI นี้ใช้งานได้จริงเพราะติดตั้ง Oracle บนอิมเมจแล้วตรวจสอบว่าเวอร์ชันของระบบปฏิบัติการและเวอร์ชัน Oracle DB ได้รับการสนับสนุนโดย SIOSที่สามารถตรวจสอบได้ ที่นี่ .

ตัวอย่างของฉันมี:

21. VPC เดียว
22. ภาคเดียว
23. Availability Zone ที่แตกต่างกันสำหรับแต่ละเซิร์ฟเวอร์
24. ไดรฟ์เพิ่มเติมสำหรับการจัดเก็บฐานข้อมูล
25. 2 อินเทอร์เฟซเครือข่ายสำหรับแต่ละอินสแตนซ์ในเครือข่ายย่อยต่างๆ
26. สร้างที่อยู่ IP แบบยืดหยุ่น 2 รายการและแนบหนึ่งรายการกับแต่ละเซิร์ฟเวอร์

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

เชื่อมต่อกับอินสแตนซ์และติดตั้งดิสก์เพิ่มเติม ฉันใช้ Putty และ Xming เพื่อเชื่อมต่อกับอินสแตนซ์ของฉันหากใช้ Xming อย่าลืมเรียกใช้ Xlaunch ก่อนที่จะพยายามเชื่อมต่อ

หลังจากเปิดตัวอินสแตนซ์ คุณจะต้องแบ่งพาร์ติชันดิสก์ใหม่ง่ายที่สุดที่จะหาได้จาก[ ls /dev/disk/by-path ] :

ตอนนี้คุณต้องแบ่งพาร์ติชันดิสก์ด้วย fdisk :

จากนั้นสร้างระบบไฟล์ในพาร์ติชันใหม่ด้วย mkfs.xfs :

ตอนนี้เราจะเมานต์ระบบไฟล์ด้วย ภูเขา :

ในที่สุดเราจะเพิ่มรายการเพื่อเมานต์ดิสก์โดยอัตโนมัติใน fstab:

โปรดทราบว่าคุณไม่จำเป็นต้องเรียกใช้การติดตั้งสำหรับ OracleAMI ได้ดำเนินการดังกล่าวและสร้างฐานข้อมูลให้กับคุณฉันลบฐานข้อมูลที่กำหนดค่าไว้ล่วงหน้าด้วย AMI นี้ และสร้างฐานข้อมูลใหม่บนดิสก์ /data โดยใช้ DBCAฉันเริ่มต้นฐานข้อมูลและสร้างสคีมาและเพิ่มข้อมูลโดยใช้ SQLPLUSทั้งหมดนี้ต้องการให้ Xwindows ทำงาน

2. ทำให้ Xwindows ทำงาน

Xdisplay โดยใช้ Putty สามารถตั้งค่าได้โดยใช้ Xming สำหรับ Windowsติดตั้ง Xming ก่อนจากนั้นตรวจสอบให้แน่ใจว่าคุณเปิดใช้งานการส่งต่อ X11 ป้อน localhost:0.0 ในตำแหน่ง x display และพาธและ xming.exe executable ในไฟล์ x Authority สำหรับการแสดงผลในเครื่อง:

ที่ดูแลด้าน Windows แต่คุณยังต้องแก้ไขด้าน Linuxก่อนอื่นให้แก้ไข /etc/ssh/sshd_config และยกเลิกการแสดงความคิดเห็น “X11Forwarding yes”การค้นหาและเพิ่มคีย์ที่ถูกต้องใน Xauthority เป็นเรื่องถัดไปคุณอาจต้องเริ่มเซสชันใหม่หากคุณเปลี่ยนผู้ใช้แล้วหลังจากเข้าสู่ระบบในฐานะผู้ใช้ ec2 รายการ xauth ซึ่งจะให้คีย์ hex ที่คุณต้องเพิ่มในไฟล์ Xauthority ของคุณเปลี่ยนเป็นผู้ใช้ oracle: ซู – ออราเคิลจากนั้นเรียกใช้ xauth เพิ่ม $DISPLAY <hexkey คัดลอกมาจากรายการ xauth>ซึ่งเก็บข้อมูลไว้ในไฟล์ /home/oracle/.Xauthorityทางออก กลับไปที่ผู้ใช้ ec2

3. เชื่อมต่อกับอินสแตนซ์และติดตั้งดิสก์เพิ่มเติม

ฉันใช้ Putty และ Xming เพื่อเชื่อมต่อกับอินสแตนซ์ของฉันหากใช้ Xming อย่าลืมเรียกใช้ Xlaunch ก่อนที่จะพยายามเชื่อมต่อ

หลังจากเปิดตัวอินสแตนซ์ คุณจะต้องแบ่งพาร์ติชันดิสก์ใหม่ง่ายที่สุดที่จะหาได้จาก[ ls /dev/disk/by-path ] :

ตอนนี้คุณต้องแบ่งพาร์ติชันดิสก์ด้วย fdisk :

ต่อไปเราจะสร้างระบบไฟล์ในพาร์ติชันใหม่ด้วย mkfs.xfs :

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

สร้างจุดเมานต์ด้วย mkdir /u01 และเมานต์โวลุ่มด้วยเมานต์ย้ายไฟล์ไปยังดิสก์ใหม่ด้วย mv /oracle /u01 การดำเนินการนี้จะใช้เวลาสักครู่เนื่องจากมีข้อมูลประมาณ 11GB

ในที่สุดเราจะเพิ่มรายการเพื่อเมานต์ดิสก์โดยอัตโนมัติใน fstab:

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

4. ติดตั้งชุด AWS cli

เราต้องการชุด awscli ดังนั้นในขณะที่เรารูทดาวน์โหลดไฟล์ด้วย ขด “https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip” -o “awscliv2.zip”

แตกไฟล์ด้วย เปิดเครื่องรูด awscliv2.zip

ติดตั้งแอพพลิเคชั่นด้วย sudo ./aws/install

ตั้งค่าคีย์การเข้าถึงใน AWS ถัดไปโดยคลิกที่บัญชีของคุณที่ด้านบนขวาของคอนโซล จากนั้นเลือก ข้อมูลรับรองความปลอดภัย

คลิกที่สร้างคีย์การเข้าถึง:

จากนั้นคลิกที่ดาวน์โหลดไฟล์ .csv:

ถ่ายโอนไฟล์นี้ไปยังเซิร์ฟเวอร์ของคุณและกำหนดค่า AWS โดยใช้ ID คีย์และคีย์การเข้าถึงจากไฟล์ csv ของคุณด้วย aws กำหนดค่า สั่งการ:

ทดสอบว่ามันใช้งานได้กับสิ่งต่อไปนี้: aws –no-paginate –no-cli-pager ec2 อธิบายอินสแตนซ์

5. กำหนดค่าความปลอดภัย/การเข้าถึง

อันดับแรก ฉันเพิ่มผู้ใช้ Oracle ในกลุ่มรูทและวงล้อโดยให้สิทธิ์หลอก ( Usermod -aG ล้อ oracle) .สิ่งนี้จะทำให้ชีวิตง่ายขึ้นโดยทำให้บัญชี Oracle เป็นบัญชี lkadminฉันดาวน์โหลด sps.img และไฟล์ลิขสิทธิ์ลงบนเซิร์ฟเวอร์ทั้งสองเครื่อง

ก่อนติดตั้งซอฟต์แวร์ มีขั้นตอนที่จำเป็นเพิ่มเติมอีกสองสามขั้นตอนที่ต้องทำขั้นแรกให้กำหนดค่ากลุ่มความปลอดภัยสำหรับเซิร์ฟเวอร์เพื่อให้สามารถสื่อสารได้โดยเปิดพอร์ต TCP 5900-59010 เปิดพอร์ต TCP 81 และ 82 ด้วย ตรวจสอบให้แน่ใจว่าพอร์ตเปิดอยู่สำหรับ Virtual IP

6. สร้างรายการเส้นทางสำหรับ IP เสมือน

ตารางเส้นทางจะต้องได้รับการอัพเดตเพื่อให้ Virtual IP ของคลัสเตอร์ทำงานได้ในการกำหนดค่าคลัสเตอร์หลายเครือข่ายย่อยนี้ Virtual IP จำเป็นต้องอยู่นอกช่วงของ CIDR ที่จัดสรรให้กับ VPC ของคุณกำหนดเส้นทางใหม่ที่จะส่งทราฟฟิกไปยัง Virtual IP ของคลัสเตอร์ (172.30.0.101) ไปยังโหนดคลัสเตอร์หลัก (Oracle1) จากแดชบอร์ด VPC เลือกตารางเส้นทาง คลิกแก้ไขเพิ่มเส้นทางสำหรับ “172.30.0.101/32” โดยมีปลายทางของ Elastic Network Interface (ENI) หลักบนเซิร์ฟเวอร์หลัก:

7. ปิดใช้งานการตรวจสอบต้นทาง/ปลายทางสำหรับ ENI's

ภายใต้ Network Interfaces ให้เลือกทีละอินเทอร์เฟซ จากนั้นภายใต้ Actions ให้เลือก change source/dest

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

ยกเลิกการเลือก เปิดใช้งาน กล่อง:

ทำซ้ำสำหรับอินเทอร์เฟซทั้งหมด

8. แก้ไข /etc/hosts

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

9. กำหนดค่า Listener ด้วยชื่อโฮสต์ VIP

แก้ไขหรือสร้างไฟล์ $ORACLE_HOME/network/admin/listener.ora เพื่อชี้ไปที่ oracle-vip:

10. ปิดใช้งาน SELinux

แก้ไขไฟล์ /etc/sysconfig/selinux และตั้งค่า “SELINUX=disabled”

รีบูทเซิร์ฟเวอร์หาก ณ จุดนี้เซิร์ฟเวอร์ไม่สำรองข้อมูล เป็นไปได้ว่าคุณปล่อยการตั้งค่า SELINUX ไว้ที่อนุญาตและตั้งค่า SELINUXTYPE เป็นปิดใช้งาน ซึ่งจะทำให้อินสแตนซ์หยุดทำงานเพียงยกเลิกการเชื่อมโยงไดรฟ์ข้อมูลใน AWS จากอินสแตนซ์ของคุณแล้วติดตั้งด้วย เมานต์ -o rw, nouuid {อุปกรณ์} {เมานต์ไดเร็กทอรี} คำสั่งไปยังอินสแตนซ์การทำงานใหม่หรือที่มีอยู่แก้ไขไฟล์ /{mount directory]/etc/sysconfig/selinux และแก้ไขข้อผิดพลาดบันทึกไฟล์ ยกเลิกการต่อเชื่อมและยกเลิกการเชื่อมโยงไดรฟ์ข้อมูลกับอินสแตนซ์นี้ และแนบกลับเข้าไปใหม่กับอินสแตนซ์เก่า

11. ติดตั้ง SIOS Protection Suite สำหรับ Linux

ต่อไป ในฐานะรูท ฉันได้ติดตั้งชุดป้องกัน SIOS โดยการเมานต์ไฟล์อิมเมจด้วย เมานต์ /home/ec2-user/sps.img /mnt/ -t iso9660 -o วนซ้ำ . เรียกใช้การตั้งค่าด้วย /mnt/ตั้งค่า :

ภายใต้ LifeKeeper Authentication ฉันเลื่อนลงไปที่กลุ่ม lkadmin กด Enter และเพิ่ม oracle ลงในกลุ่ม 'lkadmin':

เลือกตกลงแล้วแท็บเสร็จสิ้นและกด Enterเลื่อนถัดไปเพื่อติดตั้งไฟล์รหัสใบอนุญาตและกด Enter:

จากที่นี่ พิมพ์ตำแหน่งและชื่อไฟล์ใบอนุญาตของคุณ:

ต่อไป ฉันเลือก Recovery Kit Selection Menu และกด Enter:

ที่นี่ฉันเลือกเครือข่าย:

กดปุ่มสเปซบาร์เพื่อเลือก LifeKeeper Recovery Kit สำหรับ EC2 แท็บเสร็จสิ้นแล้วกด Enterต่อไป ฉันเลือกเมนูฐานข้อมูล เลื่อนลงและกดสเปซบาร์บน LifeKeeper Oracle RDBMS Recovery Kit:

แท็บเสร็จสิ้นหรือกด D แล้วเลื่อนลงไปที่ Storage แล้วกด Enterต่อไปฉันกดสเปซบาร์แล้วเลือก DataKeeper สำหรับ Linux:

แท็บเสร็จสิ้นแล้วกด Enter หรือกด d เพื่อสำรองข้อมูลไปที่ Recovery Kit Selection จากนั้นกดแท็บเสร็จสิ้นหรือกด D เพื่อถอยออกจากเมนูการกำหนดค่าหลัก:

ตรวจสอบให้แน่ใจว่าได้เลือก LifeKeeper Startup After Install แล้วเลือกแท็บสุดท้ายเสร็จหรือกด d แล้วเราจะได้หน้าจอยืนยันการติดตั้ง:

ที่นี่กด Enter หรือ y และการติดตั้งจะเริ่มขึ้น

12. เริ่ม LifeKeeper

เริ่มต้น LifeKeeper GUI ด้วย /opt/LifeKeeper/bin/lkGUIapp หากล้มเหลว อาจเป็นเพราะคุณไม่มีหมายเลขวิเศษสำหรับบัญชีที่คุณลงชื่อเข้าใช้ไฟล์ .Xauthorityฉันเข้าสู่ระบบด้วย oracle แล้วทำ sudo -i เพื่อไปที่รูทดังนั้นหาก gui ของฉันไม่โหลด ฉันจะคัดลอกไฟล์ /home/oracle/.Xauthority ไปที่ /root :

ที่นี่ฉันเข้าสู่ระบบในฐานะ oracle:

13. เชื่อมต่อกับเซิร์ฟเวอร์ที่สอง

จากนั้นคลิกที่ปุ่มเชื่อมต่อคลัสเตอร์

เข้าสู่ระบบด้วย oracle:

14. สร้างเส้นทางการสื่อสาร

คลิกที่ปุ่มสร้างเส้นทางการสื่อสาร :

หากเกิดข้อผิดพลาด ตรวจสอบให้แน่ใจว่าไฟร์วอลล์และ iptables ถูกปิดใช้งานตีต่อไป:

ตีต่อไป:

เลือกที่อยู่ IP แรกของคุณแล้วกดถัดไป:

เลือก IP ระยะไกล:

ตีต่อไป:

กดสร้าง:

ตีต่อไป:

ตีเสร็จแล้ว: ต่อไปเราต้องสร้างเส้นทางการสื่อสารที่สองโดยทำซ้ำขั้นตอนที่ 14 กับที่อยู่สำรอง

เมื่อสร้างเส้นทางทั้งสองสำเร็จแล้ว เซิร์ฟเวอร์ควรเป็นสีเขียว

15. สร้างทรัพยากร DataKeeper

คลิกที่ปุ่มสร้างลำดับชั้นของทรัพยากร:

เลือกการจำลองข้อมูลและกดถัดไป:

กดปุ่มถัดไป (Intelligent หมายความว่าหลังจากเกิดข้อผิดพลาด คุณต้องดำเนินการย้อนกลับด้วยตนเอง):

ตีต่อไป:

เลือกเซิร์ฟเวอร์หลักของคุณและกดถัดไป:

เลือกจำลองระบบไฟล์ที่มีอยู่แล้วกดถัดไป:

เลือกจุดเชื่อมต่อที่มีอยู่แล้วกดถัดไป:

สร้าง การจำลองข้อมูล แท็กทรัพยากร และกดถัดไป:

เลือกแท็กทรัพยากรระบบไฟล์และกดถัดไป:[1]

เพื่อประสิทธิภาพสูงสุด ควรวางไฟล์บิตแมปไว้บนวอลุ่มชั่วคราว เพื่อวัตถุประสงค์ในการทดสอบ สามารถวางบิตแมปบนดิสก์ OS ดังที่แสดงไว้ด้านบน เลือกตำแหน่งไฟล์บิตแมปและกดถัดไป:

เลือกไม่สำหรับ เปิดใช้งานการจำลองแบบอะซิงโครนัส และกดถัดไป:

เลือกเซิร์ฟเวอร์เป้าหมายและกดถัดไป:

เลือกประเภท Switchback และกดถัดไป:

เลือกลำดับความสำคัญของเทมเพลตแล้วกดถัดไป:

เลือก Target Priority แล้วกดถัดไป:

ตีต่อไป:

เลือก Target Disk แล้วกด Next:

ตีต่อไป:

ตีต่อไป:

เลือกปลายทางเครือข่ายที่คุณต้องการใช้สำหรับการจำลองแบบและกดถัดไป:

เลือกจุดเมานต์แล้วกดถัดไป:

เลือกแท็กทรัพยากรและกดถัดไป:

ตีเสร็จ:

ตีเสร็จ:

หากคุณคลิกที่ /u01 คุณจะเห็นปริมาณการซิงค์:

16. สร้างลำดับชั้นด้วยทรัพยากร Virtual IP

คลิกที่ปุ่มสร้างทรัพยากร:

เลือก IP และกดถัดไป:

เลือกประเภท Switchback และกดถัดไป:

เลือกเซิร์ฟเวอร์หลักและกดถัดไป:

ป้อนที่อยู่ IP เสมือนจากขั้นตอนที่ 6 และกดถัดไป:

ป้อน subnet mask สำหรับ VIP แล้วกด Next:

ป้อนอินเทอร์เฟซเครือข่ายและกดถัดไป

ป้อนแท็กทรัพยากรและกดถัดไป:

หลังจากสร้างสำเร็จให้กดต่อไป:

เลือกเซิร์ฟเวอร์เป้าหมายและกดถัดไป:

เลือกประเภทการสลับกลับและกดถัดไป:

เลือกลำดับความสำคัญและกดถัดไป:

เลือกลำดับความสำคัญและกดถัดไป:

เมื่อเสร็จสิ้นให้กดต่อไป:

ตีต่อไป:

เลือกเน็ตมาสก์ที่เหมาะสมแล้วกดถัดไป:

เลือกอินเทอร์เฟซและกดถัดไป:

เลือกแท็กทรัพยากรและขยายการกด:

ตีเสร็จเมื่อสำเร็จ:

กดเสร็จสิ้นหลังจากการตรวจสอบ

17. สร้างทรัพยากร Oracle Listener

ตรวจสอบให้แน่ใจว่าฐานข้อมูลและผู้ฟังกำลังทำงานก่อนที่จะพยายามกำหนดค่าทรัพยากรเหล่านี้ใน LifeKeeperคลิกที่ปุ่มสร้างทรัพยากร:

เลือก Oracle Database Listener แล้วกดถัดไป:

เลือกเซิร์ฟเวอร์หลักและกดถัดไป:

ป้อนเส้นทางไฟล์การกำหนดค่า Listener และชื่อไฟล์ แล้วกดถัดไป:

ตีต่อไป:

ป้อนเส้นทางสำหรับ Listener Executables และกดถัดไป:

เลือกระดับการป้องกันและกดถัดไป:

เลือกระดับการกู้คืนและกดถัดไป:

เลือกที่อยู่ IP ที่เชื่อมโยงกับ Listener หากจำเป็น และกดถัดไป:

ป้อนชื่อแท็กผู้ฟังและกดสร้าง:

ตีต่อไป:

กดยอมรับค่าเริ่มต้นเพื่อสร้างทรัพยากรบนเซิร์ฟเวอร์ที่สองของคุณ:

คลิกที่เสร็จสิ้น:

คลิกที่เสร็จสิ้นและขยาย LSNR และ /u01:

18. สร้างลำดับชั้นด้วยฐานข้อมูล Oracle

คลิกที่ปุ่มสร้างลำดับชั้นของทรัพยากร :

เลือก Oracle Database แล้วกด Next:

เลือกประเภท Switchback และกดถัดไป:

เลือกเซิร์ฟเวอร์และกดถัดไป:

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

ป้อนชื่อผู้ใช้ sysdba และกดถัดไป:

ป้อนรหัสผ่านสำหรับบัญชีและกดถัดไป:

เลือก Oracle Listener และกดถัดไป:

กดสร้าง:

เมื่อสร้างสำเร็จให้เลือก ถัดไป:

เลือกยอมรับค่าเริ่มต้น:

เลือกเสร็จสิ้น:

ตีเสร็จ: ขยายต้นไม้เพื่อดูทรัพยากรทั้งหมด:

19. สร้างลำดับชั้นด้วย EC2

คลิกที่ปุ่มสร้างลำดับชั้นของทรัพยากร :

เลือก Amazon EC2 แล้วกด Next>

เลือกอัจฉริยะแล้วกดถัดไป>

เลือกเซิร์ฟเวอร์หลักของคุณและกด Next>

เลือกประเภททรัพยากร EC2 (เราใช้คลัสเตอร์แบ็กเอนด์สำหรับตัวอย่างนี้) แล้วกด Next>

เลือกทรัพยากร IP และเลือก ถัดไป>

เลือกชื่อแท็กทรัพยากร EC2 แล้วกดสร้าง

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

เมื่อการตรวจสอบเสร็จสิ้นให้กดยอมรับค่าเริ่มต้นอีกครั้ง:

ตี เสร็จสิ้น และหลังจากการยืนยันกด เสร็จสิ้น:

การกำหนดค่าเสร็จสมบูรณ์ตอนนี้เราสามารถทดสอบการเฟลโอเวอร์ได้แล้ว

20. เปลี่ยนพฤติกรรมการปิดเครื่อง

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

คลิกขวาที่เซิร์ฟเวอร์หลักของคุณและเลือกคุณสมบัติ:

ภายใต้แท็บทั่วไปให้เปลี่ยนกลยุทธ์การปิดเครื่องเป็นสลับทรัพยากรแล้วกดใช้:

จากนั้นเลือกเซิร์ฟเวอร์รองจากเซิร์ฟเวอร์แบบเลื่อนลงและตรวจสอบการเปลี่ยนแปลงการตั้งค่า: กดตกลง:

21. ทดสอบความล้มเหลว

ฉันกำลังเรียกใช้ lkGUIapp จากเซิร์ฟเวอร์รองหากคุณอยู่บนเซิร์ฟเวอร์หลัก ให้ออกจาก LifeKeeper GUI และเรียกใช้จากเซิร์ฟเวอร์รอง

ขยายลำดับชั้นทรัพยากรทั้งหมดและเปิดเซสชัน SSH ไปยังเซิร์ฟเวอร์หลักของคุณ

ฉันยังใช้ ping -i 5 กับ oracle-vip:

ปิดเซิร์ฟเวอร์หลัก:

คุณสามารถเห็นในกรณีของฉัน IP หยุดตอบสนองเป็นเวลา < 25 วินาทีฉันพลาด 4 ปิง 20-23 ในช่วงเวลา 5 วินาทีตอนนี้ทุกอย่างใช้งานได้บนเซิร์ฟเวอร์สำรองเนื่องจากหลักของเรายังคงไม่ทำงาน เราจึงได้รับคำเตือนเกี่ยวกับลำดับชั้น

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

คลิกขวาที่ปุ่มสแตนด์บายสำหรับ cdb1 แล้วเลือก In Service…

คลิกในบริการ

กด เสร็จสิ้น

จะใช้เวลาสองสามนาทีในการซิงค์ดิสก์อีกครั้ง แต่ในที่สุดก็จะซิงค์

หลังจากกู้คืนทุกอย่างแล้ว ขณะนี้เรามีฐานข้อมูล HA Oracle ใน AWS ที่พร้อมสำหรับการพัฒนา

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

ผู้ผลิตเครื่องดื่มชั้นนำปกป้อง SAP ERP ที่สำคัญใน AWS EC2 Cloud

ผู้ผลิตเครื่องดื่มชั้นนำปกป้อง SAP ERP ที่สำคัญใน AWS EC2 Cloud