สี่กลยุทธ์การหลีกเลี่ยงเพื่อปรับปรุงความยืดหยุ่น ประสิทธิภาพ และผลลัพธ์ของคลัสเตอร์

สี่เหตุผลในการใช้กลยุทธ์การหลีกเลี่ยงในความพร้อมใช้งานสูง

1. ประสิทธิภาพที่ดีขึ้น (ลดการโอเวอร์โหลดของเซิร์ฟเวอร์)

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

2. การเพิ่มประสิทธิภาพการทำงาน

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

3. การเพิ่มประสิทธิภาพความพร้อมใช้งานสูง

HA Optimization เป็นอีกสถานการณ์หนึ่งสำหรับการปรับใช้กลยุทธ์การหลีกเลี่ยง เช่นเดียวกับกลยุทธ์การเพิ่มประสิทธิภาพการทำงาน การเพิ่มประสิทธิภาพ HA ถูกใช้เพื่อให้แน่ใจว่าสภาพแวดล้อมของคุณสามารถอยู่รอดได้ในสถานการณ์ความล้มเหลวส่วนใหญ่ และแอปพลิเคชันของคุณได้รับการปรับให้เหมาะสมเพื่อให้ระดับความพร้อมใช้งานสูงสุด ณ เวลาใดเวลาหนึ่งการเพิ่มประสิทธิภาพ HA เป็นสิ่งสำคัญสำหรับแอปพลิเคชัน เช่น SAP ที่มีกระบวนการเข้าคิวที่จำลองแบบในสภาพแวดล้อม SAP ใดๆ คุณไม่ต้องการให้อินสแตนซ์ ASCS (ABAP SAP Central Service) และ ERS (enqueue replication services) อยู่บนเซิร์ฟเวอร์เดียวกันเป็นเวลานานเนื่องจากความเสี่ยงของการล็อกที่สูญหายและงานที่ถูกยกเลิก เพื่อป้องกันไม่ให้สิ่งนี้เกิดขึ้น คุณสามารถใช้กลยุทธ์การหลีกเลี่ยงที่ทำให้อินสแตนซ์ ERS และ ASCS ทำงานบนโหนดคลัสเตอร์ตรงข้ามเสมอพิจารณากรณีของเซิร์ฟเวอร์สามเครื่องที่ใช้ปริมาณงานจริง เรียกว่าเซิร์ฟเวอร์อัลฟ่า เบต้า แกมมาเซิร์ฟเวอร์อัลฟ่ากำลังเรียกใช้อินสแตนซ์ ASCS ในขณะที่เซิร์ฟเวอร์เบต้ากำลังเรียกใช้อินสแตนซ์ ERSServer Gamma ทำหน้าที่เป็นโหนดที่สามสำหรับการเฟลโอเวอร์ของทั้ง Server Beta (ERS) และ Server Alpha (ASCS)หากเบต้าขัดข้อง คุณจะไม่ต้องการให้ทรัพยากร ERS ทำงานบนโหนดเดียวกันกับอินสแตนซ์ ASCSเพื่อให้แน่ใจว่าการดำเนินการนี้ คุณสามารถปรับใช้กลยุทธ์การหลีกเลี่ยงที่จะตรวจสอบโดยอัตโนมัติก่อน และทำให้แน่ใจว่าทั้งสองแอปพลิเคชันอยู่บนเซิร์ฟเวอร์ที่แยกจากกัน และคงไว้ซึ่งแนวทางปฏิบัติที่ดีที่สุดของ SAP ASCS/ERS สำหรับการล็อกเมื่อเกิดข้อผิดพลาด

4. การหลีกเลี่ยง DR

สมมติว่าคุณมีศูนย์ข้อมูลสองแห่ง: City Alpha และ City Beta ซึ่งอยู่ห่างกันประมาณ 70 ไมล์ โดยที่ลูกค้าส่วนใหญ่ของคุณตั้งอยู่ตรงกลางระหว่างพวกเขา อย่างไรก็ตาม เนื่องจากการเปลี่ยนแปลงล่าสุดในองค์กรภายใน การควบรวม/ปิดและการเข้าซื้อกิจการ และข้อกำหนดด้านการกำกับดูแล ทีมไอทีของคุณจะต้องเพิ่มศูนย์ข้อมูลแห่งที่สามที่ตั้งอยู่ใน City Gamma ซึ่งอยู่ห่างจาก Alpha และ Beta ประมาณ 350 ไมล์ตอนนี้ทรัพยากรที่ได้รับการคุ้มครองในอัลฟ่าและเบต้าเป็นหลักก็ขยายไปยังตำแหน่งแกมมาด้วยเนื่องจากผู้ใช้และทีมส่วนใหญ่อยู่ใกล้ตำแหน่งอัลฟ่าและเบต้า และแม้แต่ผู้ใช้ที่รุนแรงที่สุดก็ตั้งอยู่ในเมืองใกล้เคียง ทีมของคุณต้องหลีกเลี่ยงการเฟลโอเวอร์ไปยังตำแหน่งแกมมา เช่นเดียวกับกลยุทธ์อื่นๆ การหลีกเลี่ยง DR พยายามเพิ่มประสิทธิภาพการทำงาน ต้นทุนข้อมูลขาเข้า/ออกในภูมิภาค เวลาแฝง และการเข้าถึงไคลเอ็นต์โดยการหลีกเลี่ยงโหนด DR หากมีเพียงหนึ่งโหนดภายในภูมิภาคใดภูมิภาคหนึ่งที่ล้มเหลวนอกจากนี้ยังช่วยให้แน่ใจว่าแม้ว่าโหนดทั้งสองจะล้มเหลวหลังจากเวลาต่างกัน แต่การเฟลโอเวอร์จะเกิดขึ้นกับโหนดอื่นในคลัสเตอร์หรือศูนย์ข้อมูลเสมอก่อนที่จะย้ายไปยัง DR คุณจะปรับใช้กลยุทธ์การหลีกเลี่ยงอย่างไรผู้ให้บริการหลายรายมีกฎความสัมพันธ์ที่สามารถกำหนดค่าได้ ในขณะที่ผู้ให้บริการรายอื่นๆ ใช้ลำดับความสำคัญของเซิร์ฟเวอร์ร่วมกันหรือขั้นตอนที่ต้องทำด้วยตัวเองในกรณีของ SIOS Protection Suite สำหรับ Linux คุณสามารถใช้วิธีการในตัวได้หลายวิธี ได้แก่:

1. การจัดลำดับความสำคัญของทรัพยากร

ในกรณีที่เกิดความล้มเหลว ทรัพยากรจะล้มเหลวไปยังเซิร์ฟเวอร์ที่มีลำดับความสำคัญที่เหลืออยู่ต่ำสุดและต่อไปยังเซิร์ฟเวอร์เพิ่มเติม (อัลฟ่า เบต้า และแกมมา)Server Alpha เป็นเซิร์ฟเวอร์หลักสำหรับ Resource.HR, Server Beta เป็นเซิร์ฟเวอร์หลักสำหรับ Resource.MFG และ Server Gamma เป็นเซิร์ฟเวอร์สำรองสำหรับทรัพยากร/เซิร์ฟเวอร์ทั้งหมดการใช้การจัดลำดับความสำคัญของทรัพยากร Resource.HR จะมีลำดับความสำคัญหนึ่ง (1) ใน Server Alpha และลำดับความสำคัญสอง (2) บน Server Gammaในขณะที่ Resource.MFG สามารถมีลำดับความสำคัญหนึ่ง (1) บนเซิร์ฟเวอร์เบต้าและลำดับความสำคัญสอง (2) บนเซิร์ฟเวอร์ Gammaหากลูกค้าต้องการปรับการใช้สภาพแวดล้อมให้เหมาะสม Resource.HR สามารถมีลำดับความสำคัญสาม (3) บนเซิร์ฟเวอร์เบต้าและทรัพยากร MFG สามารถมีลำดับความสำคัญสาม (3) บนเซิร์ฟเวอร์อัลฟ่าในกรณีที่เซิร์ฟเวอร์อัลฟ่าล้มเหลว ทรัพยากร Resource.HR จะล้มเหลวในเซิร์ฟเวอร์แกมมาก่อนที่จะพยายามเข้ามาใช้บริการ (ถูกกู้คืน) บนเซิร์ฟเวอร์อัลฟ่า

SIOS Protection Suite สำหรับ Linux (UI และ CLI) อนุญาตให้ผู้ใช้ระบุลำดับความสำคัญสำหรับแต่ละเซิร์ฟเวอร์และการรวมทรัพยากร

2. นโยบายหรือกฎความสัมพันธ์

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

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

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

• แหล่งข้อมูลการหลีกเลี่ยงเฉพาะ

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

สำหรับตัวอย่างเพิ่มเติมของกลยุทธ์การหลีกเลี่ยงและทรัพยากร ให้พิจารณา SIOS Protection Suite สำหรับ Linux เอกสาร .หากลูกค้ามีสองแอปพลิเคชัน ได้แก่ app1 และ app2 ซึ่งพวกเขาต้องการให้ทำงานบนโหนดต่างๆ ทุกครั้งที่ทำได้ ลูกค้าสามารถสร้างทรัพยากรโหนดปลายสุดของเทอร์มินัลการหลีกเลี่ยงได้ 2 รายการโดยใช้ SIOS Protection Suite สำหรับทรัพยากร Linux gen/app และ '/opt/LifeKeeper /lkadm/bin/avoid_restore' สคริปต์

– Cassius Rhue รองประธานฝ่ายประสบการณ์ลูกค้า