Oracle रियल एप्लिकेशन क्लस्टर्स (RAC) वातावरण में, सभी उदाहरण या सर्वर निजी नेटवर्क पर हाई-स्पीड इंटरकनेक्ट का उपयोग करके एक दूसरे के साथ संचार करते हैं। यदि आरएसी में इंस्टेंस सदस्य इस निजी इंटरकनेक्ट के माध्यम से एक-दूसरे को पिंग करने या कनेक्ट करने में विफल रहते हैं, तो सभी सर्वर जो भौतिक रूप से ऊपर और चल रहे हैं (और उन सर्वरों पर डेटाबेस इंस्टेंस) स्प्लिट-ब्रेन के रूप में जानी जाने वाली स्थिति में हो सकते हैं। ।
Oracle क्लस्टर में (Oracle RAC 12c रिलीज़ 2 संस्करण से पहले), जब नेटवर्क या डिस्क समस्याओं के कारण asplit-brain समस्या उत्पन्न हुई, तो निम्नतम नोड-संख्या वाला नोड क्लस्टर में बच गया। हालांकि, नवीनतम Oracle RAC 12cRelease 2 के साथ, एल्गोरिथम में एक बदलाव किया गया है जिसके द्वारा बेदखल किए जाने वाले उम्मीदवार नोड्स को विशिष्ट मामले के लिए चुना जाता है जहां उप-क्लस्टर में समान संख्या में नोड्स के निर्माण में विभाजित-मस्तिष्क का परिणाम होता है ।
इस ब्लॉग पोस्ट में नई नोड-वेटिंग सुविधा के आधार पर OracleRAC 12c रिलीज़ 2 में नोड निष्कासन एल्गोरिथम में परिवर्तन शामिल हैं।
नोड-वेटिंग एल्गोरिथम का परिचय
निम्न छवि नोड-भारित अलोरिथम को दर्शाती है।
Oracle में नोड वेटिंगस्रोत:https://goo.gl/images/qarxrq
नोड वेटिंग ओरेकल आरएसी 12सी रिलीज 2 के साथ पेश की गई एक नई सुविधा है जो बाड़ लगाने के दौरान क्लस्टर में होस्ट किए गए कार्यभार पर विचार करती है। जब एक स्प्लिट-ब्रेनसिचुएशन होता है, तो Oracle क्लस्टरवेयर बचे हुए कोहोर्ट का चयन करने के लिए कुछ नियम लागू करता है, और सिस्टम एक नोड को बेदखल कर सकता है जो महत्वपूर्ण संसाधनों के साथ चल रहा है। इस नई सुविधा का उपयोग करके, हम कुछ नोड्स को भार प्रदान कर सकते हैं और नोड को क्लस्टर से समाप्त होने से बचा सकते हैं।
एक नया बनाया गया टैग, CSS\_CRITICAL
, विभिन्न स्तरों या घटकों पर उन्हें "महत्वपूर्ण" के रूप में चिह्नित करने के लिए सेट किया जा सकता है ताकि क्लस्टर विफलता के मामले में उन्हें संरक्षित करने का प्रयास करे। जब Oracle क्लस्टरवेयर यह निर्णय लेता है कि विभाजित मस्तिष्क के मामले में किस नोड को हटाना है, तो CSS_CRITICAL
टैग को तब तक सम्मानित किया जाता है जब तक कि कोई अन्य तकनीकी कारण नोड के अस्तित्व को प्रतिबंधित नहीं करता है (जहां विफलता के समय नोड में कम से कम एक महत्वपूर्ण घटक होता है)। अवधारणा अधिकांश काम को अप्रभावित रहने देती है, अगर बाकी सब समान है।
नोड-वेटिंग एल्गोरिथम कार्य
नोड-वेटिंग एल्गोरिथम निम्नलिखित कार्य करता है:
- डेटाबेस इंस्टेंस या सेवाओं को महत्व देता है। हम
-css_critical
सेट कर सकते हैं करने के लिएyes
srvctl डेटाबेस जोड़ें . के साथ या srvctl सेवा जोड़ें कमांड जब हम डेटाबेस इंस्टेंस या सर्विस जोड़ते हैं। हम srvctl संशोधित डेटाबेस के साथ पैरामीटर को सेट या बदल भी सकते हैं और srvctl सेवा संशोधित करें आदेश। - गैर ora.* संसाधनों को महत्व देता है. हम -attr
CSS_CRITICAL=yes
. का उपयोग करते हैं जब हम संसाधनों को जोड़ते या संशोधित करते हैं तो *crsctl add Resource* और *crsctl संशोधित संसाधन* कमांड के साथ पैरामीटर। - सर्वर को भार प्रदान करता है। हमने
-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 इंस्टेंस है?
- क्या कोई सार्वजनिक नेटवर्क विफलता थी?
- नोड किस प्रकार का होता है - हब या लीफ?
टेस्ट केस
निम्नलिखित कोड वॉक-थ्रू एक ऐसे मामले की जांच करता है जहां बॉन्ड2 को दो-नोड क्लस्टर के लिए निजी इंटरकनेक्ट के रूप में उपयोग किया जाता है।
$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.
$
नोड1 और नोड2 के बीच संचार विफलता का अनुकरण करने के लिए बॉन्ड2 को रोकें:
#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 विफलता पुनर्प्राप्ति तंत्र पर अधिक नियंत्रण प्राप्त करते हैं। यदि इस विषय पर आपके कोई प्रश्न हैं या मार्गदर्शन की आवश्यकता है, तो आप नीचे दिए गए क्षेत्र में टिप्पणी जोड़ सकते हैं।