Oracle RAC नोड वेटिंग को समझना: एक व्यावहारिक गाइड

Oracle रियल एप्लिकेशन क्लस्टर (RAC) वातावरण में, सभी इंस्टेंस या सर्वर निजी नेटवर्क पर हाई-स्पीड इंटरकनेक्ट का उपयोग करके एक दूसरे के साथ संचार करते हैं। यदि RAC में इंस्टेंस सदस्य इस निजी इंटरकनेक्ट के माध्यम से एक दूसरे को पिंग या कनेक्ट करने में विफल रहते हैं, तो भौतिक रूप से चालू और चल रहे सभी सर्वर (और उन सर्वरों पर डेटाबेस इंस्टेंस) स्प्लिट-ब्रेन के रूप में जानी जाने वाली स्थिति में समाप्त हो सकते हैं।

Oracle क्लस्टर में (Oracle RAC 12c रिलीज़ 2 संस्करण से पहले), जब नेटवर्क या डिस्क समस्याओं के कारण स्प्लिट-ब्रेन समस्या होती थी, तो क्लस्टर में सबसे कम नोड-नंबर वाला नोड बच जाता था। हालांकि, नवीनतम Oracle RAC 12c रिलीज़ 2 के साथ, उस विशिष्ट मामले के लिए उम्मीदवार नोड्स को चुने जाने के एल्गोरिदम में बदलाव आया है जहां स्प्लिट-ब्रेन के परिणामस्वरूप उप-क्लस्टर में समान संख्या में नोड्स का निर्माण होता है।

यह ब्लॉग पोस्ट नई नोड-वेटिंग सुविधा के आधार पर Oracle RAC 12c रिलीज़ 2 में नोड निष्कासन एल्गोरिदम में परिवर्तनों को कवर करता है।

नोड-वेटिंग एल्गोरिदम का परिचय

निम्न छवि नोड-वेटिंग एल्गोरिदम को दर्शाती है।

स्रोत: https://goo.gl/images/qarxrq

नोड वेटिंग Oracle RAC 12c रिलीज़ 2 के साथ पेश की गई एक नई सुविधा है जो फ़ेंसिंग के दौरान क्लस्टर में होस्ट किए गए वर्कलोड पर विचार करती है। जब स्प्लिट-ब्रेन स्थिति होती है, तो Oracle Clusterware जीवित रहने वाले समूह का चयन करने के लिए कुछ नियम लागू करता है, और सिस्टम उस नोड को निष्कासित कर सकता है जो महत्वपूर्ण संसाधनों के साथ चल रहा है। इस नई सुविधा का उपयोग करके, हम कुछ नोड्स को वेट असाइन कर सकते हैं और उन्हें क्लस्टर से समाप्त होने से बचा सकते हैं।

एक नया बनाया गया टैग, CSS_CRITICAL, विभिन्न स्तरों या घटकों पर सेट किया जा सकता है ताकि उन्हें "महत्वपूर्ण" के रूप में चिह्नित किया जा सके ताकि विफलता के मामले में क्लस्टर उन्हें संरक्षित करने का प्रयास करे। जब Oracle Clusterware स्प्लिट ब्रेन के मामले में किस नोड को निष्कासित करना है, इस बारे में निर्णय लेता है, तो CSS_CRITICAL टैग का सम्मान किया जाता है जब तक कि कोई अन्य तकनीकी कारण नोड के जीवित रहने को प्रतिबंधित न करे (जहां विफलता के समय नोड में कम से कम एक महत्वपूर्ण घटक हो)। यह अवधारणा अधिकांश काम को अप्रभावित रहने देती है, अगर बाकी सब बराबर है।

नोड-वेटिंग एल्गोरिदम कार्य

नोड-वेटिंग एल्गोरिदम निम्न कार्य करता है:

• डेटाबेस इंस्टेंस या सेवाओं को वेट असाइन करता है। हम srvctl add database या srvctl add service कमांड के साथ डेटाबेस इंस्टेंस या सेवा जोड़ते समय -css_critical को yes पर सेट कर सकते हैं। हम srvctl modify database और srvctl modify service कमांड के साथ पैरामीटर को सेट या बदल भी सकते हैं।
• नॉन ora.* संसाधनों को वेट असाइन करता है। हम संसाधन जोड़ते या संशोधित करते समय *crsctl add resource* और *crsctl modify resource* कमांड के साथ -attr CSS_CRITICAL=yes पैरामीटर का उपयोग करते हैं।
• सर्वर को वेट असाइन करता है। हम crsctl set server कमांड के साथ -css_critical पैरामीटर को yes पर सेट करते हैं।

डेटाबेस इंस्टेंस या सेवाओं को वेट असाइन करने के कुछ उदाहरण निम्नलिखित हैं:

$srvctl modify database –d  css_critical yes
$srvctl modify service –db  -service  css_critical yes

यदि संसाधन को वेट असाइन नहीं किया गया है, तो एल्गोरिदम निम्नलिखित विचारों की जांच करता है:

• किस नोड पर अधिकतम संख्या में सेवाएं बनाई गई हैं?
• क्या इंस्टेंस के लिए सिंगलटन सेवाएं बनाई गई हैं?
• क्या नोड एक कॉन्फ़िगर किया गया फ्लेक्स 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 से शुरू होकर, नया एल्गोरिदम स्प्लिट-ब्रेन परिदृश्य के दौरान निष्कासित या बनाए रखे जाने वाले नोड्स का निर्णय इस प्रकार करता है:

• यदि उप-क्लस्टर अलग-अलग आकार के हैं, तो कार्यक्षमता पिछले रिलीज़ के समान है।

• यदि सभी उप-क्लस्टर समान आकार के हैं, तो कार्यक्षमता को निम्नानुसार संशोधित किया गया है:

  • यदि उप-क्लस्टर के नोड वेट समान हैं, तो सबसे कम नोड नंबर वाला उप-क्लस्टर जीवित रहता है ताकि यह सुनिश्चित हो सके कि दो-नोड क्लस्टर में, सबसे कम नोड नंबर वाला नोड जीवित रहे।
  • यदि उप-क्लस्टर के नोड वेट असमान हैं, तो अधिक वेट वाला उप-क्लस्टर जीवित रहता है ताकि यह सुनिश्चित हो सके कि दो-नोड क्लस्टर में, कम वेट के कारण सबसे कम नोड नंबर वाला नोड निष्कासित हो जाता है।

सर्वर वेट-आधारित नोड निष्कासन का उपयोग करके, हम Oracle Clusterware विफलता पुनर्प्राप्ति तंत्र पर अधिक नियंत्रण प्राप्त करते हैं यह चुनकर कि स्प्लिट ब्रेन की स्थिति में किन क्लस्टर नोड्स को समाप्त या निष्कासित किया जाना चाहिए। यदि इस विषय पर आपके कोई प्रश्न हैं या मार्गदर्शन की आवश्यकता है, तो आप नीचे दिए गए क्षेत्र में टिप्पणी जोड़ सकते हैं।