home

หน้าแรก
 Computer >> คอมพิวเตอร์ >  >> การเขียนโปรแกรม >> ฐานข้อมูล

ข้อมูลเบื้องต้นเกี่ยวกับการถ่วงน้ำหนักโหนด Oracle RAC

ในสภาพแวดล้อม Oracle Real Application Clusters (RAC) อินสแตนซ์หรือเซิร์ฟเวอร์ทั้งหมดสื่อสารกันโดยใช้การเชื่อมต่อระหว่างกันความเร็วสูงบนเครือข่ายส่วนตัว หากสมาชิกของอินสแตนซ์ใน RAC ไม่สามารถ ping หรือไม่สามารถเชื่อมต่อกันได้ผ่านการเชื่อมต่อส่วนตัวนี้ เซิร์ฟเวอร์ทั้งหมดที่กำลังทำงานอยู่ (และอินสแตนซ์ฐานข้อมูลบนเซิร์ฟเวอร์เหล่านั้น) อาจอยู่ในสภาวะที่เรียกว่า split-brain .

ในคลัสเตอร์ Oracle (ก่อนเวอร์ชัน Oracle RAC 12c รีลีส 2) เมื่อปัญหา asplit-brain เกิดขึ้นเนื่องจากปัญหาเครือข่ายหรือดิสก์ โหนดที่มีหมายเลขโหนดต่ำสุดจะรอดชีวิตในคลัสเตอร์ อย่างไรก็ตาม ด้วย Oracle RAC 12cRelease 2 ล่าสุด มีการเปลี่ยนแปลงในอัลกอริธึมโดยที่ระบบเลือก Candidatenodes ที่จะถูกขับออกสำหรับกรณีเฉพาะที่ split-brain ส่งผลให้เกิดการสร้างโหนดในจำนวนที่เท่ากันใน sub-cluster .

บล็อกโพสต์นี้ครอบคลุมการเปลี่ยนแปลงของอัลกอริธึมการขับโหนดใน OracleRAC 12c รีลีส 2 โดยอิงตามฟีเจอร์การถ่วงน้ำหนักโหนดใหม่

ข้อมูลเบื้องต้นเกี่ยวกับอัลกอริทึมการถ่วงน้ำหนักโหนด

รูปภาพต่อไปนี้แสดงอัลกอริทึมการถ่วงน้ำหนักโหนด

ข้อมูลเบื้องต้นเกี่ยวกับการถ่วงน้ำหนักโหนด Oracle RAC การถ่วงน้ำหนักโหนดใน Oracle

ที่มา:https://goo.gl/images/qarxrq

Node Weighting เป็นคุณลักษณะใหม่ที่นำมาใช้กับ Oracle RAC 12c Release 2 ซึ่งพิจารณาปริมาณงานที่โฮสต์ในคลัสเตอร์ระหว่างการฟันดาบ เมื่อเกิดการแยกสมองออกจากกัน Oracle Clusterware จะใช้กฎเกณฑ์บางอย่างเพื่อเลือกกลุ่มผู้รอดชีวิต และระบบอาจขับไล่โหนดที่ทำงานด้วยทรัพยากรที่สำคัญ เมื่อใช้คุณสมบัติใหม่นี้ เราสามารถกำหนดน้ำหนักให้กับโหนดบางโหนดและบันทึกโหนดไม่ให้ถูกยุติจากคลัสเตอร์

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

งานอัลกอริทึมการถ่วงน้ำหนักโหนด

อัลกอริทึมการถ่วงน้ำหนักโหนดทำงานดังต่อไปนี้:

  • กำหนดน้ำหนักให้กับอินสแตนซ์ฐานข้อมูลหรือบริการ เราสามารถตั้งค่า -css_critical ถึง yes ด้วย srvctl เพิ่มฐานข้อมูล หรือ srvctl เพิ่มบริการ คำสั่งเมื่อเราเพิ่มอินสแตนซ์ฐานข้อมูลหรือบริการ นอกจากนี้เรายังสามารถตั้งค่าหรือเปลี่ยนพารามิเตอร์ด้วย srvctl แก้ไขฐานข้อมูล และ srvctl แก้ไขบริการ คำสั่ง
  • กำหนดน้ำหนักให้กับทรัพยากรที่ไม่ใช่ ora.* เราใช้ -attr CSS_CRITICAL=yes พารามิเตอร์ด้วยคำสั่ง *crsctl add resource* และ *crsctl modified resource* เมื่อเราเพิ่มหรือแก้ไขทรัพยากร
  • กำหนดน้ำหนักให้กับเซิร์ฟเวอร์ เราตั้งค่า -css_critical พารามิเตอร์เป็น yes ด้วย เซิร์ฟเวอร์ชุด crsctl คำสั่ง

ต่อไปนี้คือตัวอย่างการกำหนดน้ำหนักให้กับอินสแตนซ์ฐานข้อมูลหรือบริการ:

$srvctl modify database –d <dbname> css\_critical yes
$srvctl modify service  –db  <dbname> -service <service_name> css_critical yes

หากไม่ได้กำหนดน้ำหนักให้กับทรัพยากร อัลกอริทึมจะตรวจสอบข้อควรพิจารณาต่อไปนี้:

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

กรณีทดสอบ

คำแนะนำโค้ดต่อไปนี้จะตรวจสอบกรณีที่ bond2 ถูกใช้เป็นการเชื่อมต่อระหว่างกันแบบส่วนตัวสำหรับคลัสเตอร์แบบสองโหนด

$oifcfg getif
bond0  147.167.80.0  global  public
bond2  10.168.33.32  global  cluster\_interconnect
$olsnodes -s -n
node1   1       Active
node2   2       Active
$
$crsctl set server css\_critical yes
$crsctl get server css\_critical
CRS-5092: Current value of the server attribute CSS_CRITICAL is yes.
$

มาหยุด bond2 เพื่อจำลองความล้มเหลวในการสื่อสารระหว่าง node1 และ node2:

#ifdown bond2

$olsnodes -s -n
node1   1       Active
node2   2       Inactive

เอาต์พุตจาก OCSSD.trc

2018-01-09 11:01:21.220 :    CSSD:1825834752: clssnmrCheckNodeWeight: node(1) has weight stamp(393228187) pebbles (0) goldstars (0) flags (3) SpoolVersion (0)
2018-01-09 11:01:21.220 :    CSSD:1825834752: clssnmrCheckNodeWeight: node(2) has weight stamp(0) pebbles (0) goldstars (0) flags (0) SpoolVersion (0)
2018-01-09 11:01:21.727 :    CSSD:1825834752: clssnmrCheckNodeWeight: node(1) has weight stamp(393228187) pebbles (0) goldstars (0) flags (3) SpoolVersion (0)
2018-01-09 11:01:21.727 :    CSSD:1825834752: clssnmrCheckNodeWeight: node(2) has weight stamp(0) pebbles (0) goldstars (0) flags (0) SpoolVersion (0)
2018-01-09 11:01:21.727 :    CSSD:1825834752: clssnmrCheckNodeWeight: Server pool version not consistent
2018-01-09 11:01:21.727 :    CSSD:1825834752: clssnmrCheckNodeWeight: stamp(393228187), completed(1/2)

บทสรุป

เริ่มตั้งแต่ RAC 12c รีลีส 2 อัลกอริธึมใหม่จะตัดสินใจว่าโหนดจะถูกขับออกหรือถูกรักษาไว้ (ระหว่างสถานการณ์สมมติสมองแตก) ดังนี้:

  • หากคลัสเตอร์ย่อยมีขนาดต่างกัน ฟังก์ชันการทำงานจะเหมือนกับในรุ่นก่อนหน้า

  • หากคลัสเตอร์ย่อยทั้งหมดมีขนาดเท่ากัน ฟังก์ชันการทำงานได้รับการแก้ไขดังนี้:

    • หากคลัสเตอร์ย่อยมีน้ำหนักโหนดเท่ากัน คลัสเตอร์ย่อยที่มีหมายเลขโหนดต่ำสุดจะอยู่รอดเพื่อให้แน่ใจว่าในคลัสเตอร์แบบสองโหนด โหนดที่มีหมายเลขโหนดต่ำสุดจะยังคงอยู่
    • หากคลัสเตอร์ย่อยมีน้ำหนักโหนดไม่เท่ากัน คลัสเตอร์ย่อยที่มีน้ำหนักสูงกว่าจะอยู่รอดเพื่อให้แน่ใจว่าในคลัสเตอร์แบบสองโหนด โหนดที่มีหมายเลขโหนดต่ำสุดจะถูกขับออกเนื่องจากน้ำหนักที่ต่ำกว่า

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