👆🏿 💒 👩🏼‍🤝‍👨🏽 InterSystems डेटाबेस मिररिंग। दर्पण बनाना और परीक्षण करना। भाग २ 💅🏾 🈁 💅🏼

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

ब्रेक्स नियोजित और अनियोजित दोनों हो सकते हैं।
शेड्यूल किए गए हैं जब हमें ऑपरेटिंग सिस्टम, डीबीएमएस संस्करण, एप्लिकेशन सिस्टम संस्करण को अपडेट करने के लिए सर्वर को रोकने की आवश्यकता होती है और हम प्रक्रिया को नियंत्रित करते हैं।

अनुसूचित विराम के उदाहरण:

ओएस को रिबूट करना, उदाहरण के लिए, अपडेट स्थापित करने के लिए;
DBMS रिबूट
हार्डवेयर सर्वर अद्यतन।

अनिर्धारित - जब कुछ ऐसा होता है जो सर्वर की अक्षमता को सूचना प्रणाली के ग्राहकों के साथ काम करने की ओर ले जाता है, और हमारे ज्ञान के बिना। इसका कारण यह हो सकता है:

DBMS ठंड
ओएस फ्रीज
आपातकालीन (रीसेट, पावर ऑफ);
सर्वर हार्डवेयर विफलता;
नेटवर्क उपकरण की विफलता;
~~युद्ध, महामारी, बर्फ का तूफान, बाहरी अंतरिक्ष ब्लैक होल।~~

फ़ेलओवर (विफलता)

कैशे दर्पण के लिए स्वचालित विफलता केवल प्राथमिक सर्वर पर विफलता / रुकावट की स्थिति में होती है, और इस लेख में हम ऐसे मामलों पर विचार करेंगे। बेशक, बैकअप सर्वर पर कोई समस्या होने पर परिदृश्य हो सकते हैं, लेकिन इस मामले में आईपी काम करना जारी रखता है, और जब तक कि व्यवस्थापक मैन्युअल रूप से बैकअप सर्वर को पुनर्स्थापित नहीं करता, तब तक कोई भौतिक दर्पण नहीं है। एक और परिदृश्य संभव है जब दोनों सर्वर तुरंत विफल हो गए - लेकिन इस मामले में, आईपी के संचालन में एक ब्रेक अपरिहार्य है, और इसका निपटान "मैन्युअल रूप से" किया जाता है।

स्वचालित आगामी विफलता का मूल परिदृश्य:

प्राइमरी-सर्वर IS क्लाइंट्स का काम करता है जो मिरर किए गए डेटाबेस में से एक के साथ काम करते हैं और बैकअप-सर्वर "स्टैंड बाय" होता है;
प्राथमिक सर्वर पर विफलता होती है;
बैकअप सर्वर यह सुनिश्चित करता है कि प्राथमिक सर्वर "डाउन" में है, स्वचालित रूप से प्राथमिक सर्वर बन जाता है और सूचना प्रणाली के ग्राहकों की सेवा करना जारी रखता है;
पूर्व प्राथमिक सर्वर को पुनर्स्थापित किया जाता है (उदाहरण के लिए, व्यवस्थापक द्वारा), एक नया बैकअप सर्वर बन जाता है और नए प्राथमिक सर्वर के लिए "स्टैंड बाय" मोड में प्रवेश करता है।

क्या गलत हो सकता है?
ऐसी स्थिति की कल्पना करें जहां नेटवर्क इंटरफ़ेस प्राथमिक सर्वर पर विफल रहता है, लेकिन लंबे समय तक नहीं, हालांकि, यह बैकअप सर्वर के लिए प्राथमिक सर्वर बनने के लिए पहले से ही "निर्णय" करने के लिए पर्याप्त है। परिणाम एक विभाजित मस्तिष्क की स्थिति है।

विभाजित मस्तिष्क

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

AgentContactRequiredForFailover

विफलता / रुकावट के दौरान कैचे दर्पण के व्यवहार के लिए निर्णायक कारक AgentContactRequiredForFailover = हां / कोई पैरामीटर नहीं है।

AgentContactRequiredForFailover = हाँ

AgentContactRequiredForFailover (ACRF) = हां (डिफ़ॉल्ट) के मामले में, विफलता के साथ, दोनों सर्वरों पर ISC एजेंट को ब्रेक के समय संपर्क में होना चाहिए। यह स्थिति कैश की अनिर्धारित विफलता के मामलों के लिए संभव है, कैश के अनुसूचित रिबूट, ओएस के अनुसूचित रिबूट। इसलिए, इस मोड में, अन्य सभी मामलों के लिए, एक स्वचालित विफलता नहीं होगी!

AgentContactRequiredForFailover = नहीं

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

परीक्षण के परिणाम

बेशक, एक असफल समाधान का निर्माण करते समय, हम ज्यादातर स्थितियों के लिए विफलता को स्वचालित रूप से दूर करने की उम्मीद करते हैं, अन्यथा यह सब क्यों। वर्तमान में, कैच मिरर लगभग सभी संभावित परिदृश्यों को स्वचालित रूप से संसाधित करने में सक्षम है।
हमने परीक्षण किया कि दर्पण विभिन्न ACRF मूल्यों के साथ कई विशिष्ट परिदृश्यों के लिए कैसे व्यवहार करता है।
हमने फिलहाल Caché 2012.2 RC के नवीनतम संस्करण का परीक्षण किया। हां - इस परिदृश्य के लिए स्वचालित विफलता का मतलब है।

एन	परिदृश्यों	ACRF = हाँ	ACRF = नहीं
1	योजनाबद्ध या आपातकालीन रिबूट, प्राथमिक पर काचे डीबीएमएस को बंद करना	हां	हां
2	ओएस अनुसूचित रिबूट	हां	हां
3	इमरजेंसी स्टॉप ओएस, रीसेट, पावर ऑफ	नहीं	हां
4	प्राथमिक पर नेटवर्क इंटरफ़ेस को अक्षम करना	नहीं	हां
5	पावर ऑफ एक ही समय में प्राथमिक और बैकअप, और फिर पहले प्राथमिक बूट करें	हां	हां
6	एक ही समय में प्राथमिक और बैकअप पावर बंद, और फिर पहले बैकअप बूट	नहीं	नहीं

परीक्षण के परिणामों के अनुसार, यह पता चला - एक अप्रिय परिदृश्य नेटवर्क इंटरफ़ेस (नंबर 4) को अक्षम करना है। इसलिए, यह अनुशंसा की जाती है कि दर्पण सर्वर के बीच एक अनावश्यक नेटवर्क लिंक स्थापित किया जाए।
उदाहरण सर्वर कॉन्फ़िगरेशन:

दोनों सर्वरों की एक साथ विफलता की स्थिति में - परिदृश्य 5-6 (उदाहरण के लिए, बिजली की आपूर्ति में एक लंबा रुकावट), कमीशन कमीशन का निरीक्षण करना महत्वपूर्ण है - प्राथमिक सर्वर को पहले सक्रिय किया जाना चाहिए। अन्यथा, बैकअप सर्वर प्राथमिक हो जाता है, और पूर्व प्राथमिक सर्वर की शुरुआत के बाद, उनमें से दो हैं - विभाजित मस्तिष्क के परिणामस्वरूप।

जैसा कि तालिका से देखा जा सकता है, ACRF = हाँ (डिफ़ॉल्ट मान) के साथ Caché सिंक्रोनस मिरर केवल उन आपातकालीन स्थितियों को प्रदान करता है जब क्लस्टर सर्वर के बीच नेटवर्क "जीवित" होता है।
अन्य स्थितियों के लिए, ACRF = कोई मोड नहीं है, जहां व्यवस्थापक, अपने जोखिम पर, प्राथमिक सर्वर विफल होने पर निर्धारित करने के लिए उपयोगकर्ता प्रोग्राम ZMIRROR लिखता है।

ZMIRROR

दर्पण की अंतिम स्थापना के लिए इस तरह के हार्डवेयर-सॉफ्टवेयर सिस्टम का निर्माण करना सैद्धांतिक रूप से संभव है, जब किसी भी परिदृश्य के लिए सॉफ्टवेयर राज्य में विशिष्ट रूप से यह निर्धारित करना संभव है कि प्राथमिक सर्वर किस राज्य में है।
यदि आपके सर्वर पर यह स्थिति होती है, तो मोड को ACRF = no पर सेट करना उचित है। तब ब्रेक के मामले में, और जब ISC एजेंट प्राथमिक सर्वर के साथ कोई संचार नहीं होता है, तो सिस्टम $ $ IsOtherNodeDown ^ ZMIRROR () फ़ंक्शन को कॉल करता है। फ़ंक्शन 1 या 0. लौटाता है, यदि कोई फ़ंक्शन नहीं है या फ़ंक्शन 0 देता है, तो स्वचालित विफलता प्रक्रिया समाप्त हो जाती है।
$$ IsOtherNodeDown ^ ZMIRROR () फ़ंक्शन के कस्टम कार्यान्वयन को लिखते समय, प्रोग्रामर का कार्य प्राथमिक रूप से यह सत्यापित करना है कि प्राथमिक सर्वर वास्तव में विफल हो गया है और इस मामले में 1 लौटाता है।

उदाहरण उपयोगकर्ता फ़ंक्शन ZMIRROR

ZMIRROR
; अपने खुद के जोखिम पर उपयोग करें।
क्ष

IsOtherNodeDown () सार्वजनिक
{
d ## वर्ग ( % डिवाइस )। प्रसारण ( "" , "------------> IsOtherNodeDown ()" )

कोशिश करो {
s ip = "192.168.169.186"; एक और विफलता नोड का पता

s PingSuccessful = $ system .INetInfo CheckAddressExist (ip)
d ## वर्ग ( % डिवाइस )। प्रसारण ( "" , "आईपी पता" _ip_ "" _
$ s (पिंगसुफल: "उपलब्ध" , 1: "अनुपलब्ध" ) _ "।" )
यदि 'PingSuccessful s returnValue = 1 q ; कोई पिंग नहीं

s url = " " _ip_ ": 57772 / csp / sys / UtilHome.csp"
s स्टेटमेंट = $ $ गेटस्टैटस (url)
d ## वर्ग ( % डिवाइस )। प्रसारण ( "" , url_ "" _stat_ "है।" )
अगर स्टेट [ "त्रुटि" का रिटर्नवैल्यू = 1 क्यू ;
s रिटर्नवैल्यू = 0

} कैच (ई) {
d ## वर्ग ( % Library.Device )। प्रसारण ( "" , e। DisplayString ()
s रिटर्नवैल्यू = 0
}
d ## वर्ग ( % डिवाइस )। प्रसारण ( "" , "रिटर्निंग" _returnValue_ "..." )
d ## वर्ग ( % डिवाइस )। प्रसारण ( "" , "<------------ IsOtherNodeDown ()" )
q वापसी
}

CheckBecomePrimaryOK () सार्वजनिक
{
d ## वर्ग ( % डिवाइस )। प्रसारण ( "" , "------------> CheckBecomePrimaryOK ()" )
कोशिश करो {
s स्टेटमेंट = $$ मेंबरशिप ()
s रिटर्नवैल्यू = 1
d ## वर्ग ( % डिवाइस )। प्रसारण ( "" , "यह उदाहरण" _stat) है
d ## वर्ग ( % डिवाइस )। प्रसारण ( "" , "रिटर्निंग" _returnValue_ "..." )
} कैच (ई) {
d ## वर्ग ( % Library.Device )। प्रसारण ( "" , e। DisplayString ()
s रिटर्नवैल्यू = 0
}
d ## वर्ग ( % डिवाइस )। प्रसारण ( "" , "<------------ CheckBecomePrimaryOK ()" )
q वापसी
}

NotifyBecomePrimary () सार्वजनिक
{
d ## वर्ग ( % डिवाइस )। प्रसारण ( "" , "------------> NotifyBecomePrimary ()" )
कोशिश करो {
d ## वर्ग ( % डिवाइस )। प्रसारण ( "" , "यह उदाहरण है" _ $$ मेम्बरडस्क्रिप्शन ())
} कैच (ई) {
d ## वर्ग ( % Library.Device )। प्रसारण ( "" , e। DisplayString ()
}
d ## वर्ग ( % डिवाइस )। प्रसारण ( "" , "<------------ NotifyBecomePrimary ()" )
}

NotifyBecomePrimaryFailed () सार्वजनिक
{
d ## वर्ग ( % डिवाइस )। प्रसारण ( "" , "------------> NotifyBecomePrimaryFailed ()" )
कोशिश करो {
d ## वर्ग ( % डिवाइस )। प्रसारण ( "" , "यह उदाहरण है" _ $$ मेम्बरडस्क्रिप्शन ())
} कैच (ई) {
d ## वर्ग ( % Library.Device )। प्रसारण ( "" , e। DisplayString ()
}
d ## वर्ग ( % डिवाइस )। प्रसारण ( "" , "<------------ NotifyBecomePrimaryFailed ()" )
}

सदस्य विवरण () ; दर्पण सदस्य का दर्जा प्राप्त करें
q $ s ( $ सिस्टम । मिरर । Isember (): $ s ( $ सिस्टम । मिरर । इसबैक ) (): "एक बैकअप" ।
$ प्रणाली । IsPrimary (): "एक प्राथमिक" ,
$ प्रणाली । IsAsyncMember (): "a async" ,
1: "अज्ञात" ) _ "का सदस्य" _ $ सिस्टम । मिरर । मिररनेम ()
1: "सदस्य नहीं" )

GetStatus (url)
; url - पता http: // localhost: 57772 / csp / sys / UtilHome.csp
S $ ZT = "HttpError"
N A, स्थिति, इरेटा, कैंपसक्वेस्ट, पोर्ट, कंटेंट,% objlasterror
सेट करें व्याख्याकार = ## वर्ग ( % Net.HttpRequest )। % नया ()
S A = $ P ( $ p (url, ": //" , 2), "/" , 1) I A = "" Q "त्रुटि! URL!"
I A [ ":" S पोर्ट = $ P (A : ":" , 2), A = $ P (A, ":" , 1) सेट करें चित्रण। पोर्ट = पोर्ट
स्पष्ट सेट करें । सर्वर = ए
S A = "/" _ $ P ( $ p (url, ": //" , 2), "/" , 2,991)
स्पष्ट सेट करें । समयबाह्य = ३
चित्रण करें। जाओ (ए)
एस स्थिति = स्पष्ट नहीं। HttpResponse । StatusLine
चित्रण करें। % बंद ()
i स्टेटस = "" , $ g (% objlasterror) '= "" g HttpError
क्ष स्थिति
HttpError I $ ZE [ "<INVALID OREF>" Q "त्रुटि? सर्वर नहीं पहुंच?" _ ZE
do DecomposeStatus ^% apiOBJ (% objlasterror, .err)
Q "त्रुटि" _ $ G (इरेट (इरेट))

अस्वीकरण! किसी भी तरह से इस कोड का उपयोग करना ACRF = No. के लिए आपके उत्पादन कॉन्फ़िगरेशन में एक स्वचालित विफलता की गारंटी देता है। इस मोड के वास्तविक उपयोग के लिए, व्यक्तिगत रूप से प्रत्येक कॉन्फ़िगरेशन के लिए पूरी तरह से विफलता परीक्षण आवश्यक है!

मिरर टिप्स

InterSystems डेटाबेस मिररिंग अनुभव से कुछ सिफारिशें

यदि आप बैकअप सर्वर बंद है, तो आप प्राथमिक सर्वर लॉग को "मैन्युअल रूप से" साफ़ नहीं कर सकते हैं।
वास्तव में, यदि आप ऐसा करते हैं, लेकिन बैकअप सर्वर ने आवश्यक लॉग लेने का प्रबंधन नहीं किया है, तो आप फिर से एक बैकअप सर्वर बना सकते हैं।

"प्राथमिक सर्वर चल रहा है, तो आप बैकअप सर्वर को लंबे समय तक बंद नहीं रख सकते हैं"
इस मामले में, प्राथमिक सर्वर डिस्क स्थान अनइंस्टॉल किए गए लॉग के अतिप्रवाह के कारण बाहर हो सकता है।

"सर्वर पर समय सिंक्रनाइज़ किया जाना चाहिए"
यह एक साधारण स्थिति है, लेकिन इसे पूरा किया जाना चाहिए। अन्यथा, desynchronization के दौरान, उदाहरण के लिए, कई घंटों के लिए, लॉग्स की प्रासंगिकता के साथ बैकअप सर्वर "भ्रमित हो जाता है"। परिणामस्वरूप, हम बैकअप सर्वर को फिर से बनाते हैं।

"सर्वर के बीच नेटवर्क अनलोड होना चाहिए"
नेटवर्क पर, लॉग को लगातार प्राथमिक सर्वर से बैकअप में स्थानांतरित किया जा रहा है। यदि सर्वर के बीच नेटवर्क अभी भी कुछ के साथ व्यस्त है, या चैनल डेटा ट्रांसफर के लिए पर्याप्त नहीं है, तो परिणामस्वरूप प्राथमिक सर्वर "धीमा" होना शुरू हो जाएगा, जिसमें आईएस उपयोगकर्ताओं द्वारा दर्ज किए गए डेटा को स्थानांतरित करने का समय नहीं होगा।

"सिस्टम कॉन्फ़िगरेशन सेटिंग्स, मैपिंग, भूमिका और उपयोगकर्ता सेटिंग्स मैन्युअल रूप से सिंक्रनाइज़ होनी चाहिए"
ग्लोबल्स, कक्षाएं और पैकेज मैप करने के लिए सेटिंग्स, साथ ही प्राथमिक और बैकअप सर्वर के लिए भूमिकाओं, उपयोगकर्ताओं और सिस्टम कॉन्फ़िगरेशन के लिए सभी सेटिंग्स को भी सिंक में रखा जाना चाहिए। मिरर केवल मिररिंग के लिए चयनित डेटाबेस को सिंक्रनाइज़ करता है। इसलिए, दर्पण व्यवस्थापक के पास एक ही कॉन्फ़िगरेशन, मैपिंग और उपयोगकर्ता सुरक्षा नीतियां होनी चाहिए और प्राथमिक और बैकअप सर्वर के लिए इस स्थिति को बनाए रखना चाहिए।

परिचालन संबंधी विशेषताएं

विफलता के लिए एजेंट संपर्क के लिए स्वचालित विफलता के लिए औसत रनटाइम = हां 10-20 सेकंड है। 10-20 सेकंड का ठहराव वह समय है जब एप्लिकेशन नए सर्वर के साथ काम करना जारी रखेगा। इस स्थिति में, कनेक्शन फिर से जुड़ता है (यदि सर्वर से कोई सीधा संबंध था) या बस काम करना जारी रखता है यदि कार्य ईसीपी कनेक्शन के माध्यम से किया गया था।
ACRF = नहीं के मामले में, ठहराव का औसत 35-40 सेकंड है। इस मामले में, ECP क्लाइंट कनेक्शन खो देंगे, क्योंकि ECP = 30 सेकंड के लिए डिफ़ॉल्ट टाइमआउट। ECR का उपयोग करने वाले सिस्टम के लिए और सिस्टम ^% ZSTART में ECP क्लाइंट सर्वरों पर ACRF के साथ एक दर्पण = के लिए, ECP टाइमआउट को बढ़ाने वाला कोड लिखना उचित है:

$ प्रणाली करो ।ECP सेटप्रॉपर्टी ( "ECPRecoveryTimout" , 90)

नीचे की रेखा या "हमें इसकी आवश्यकता है"?

इस प्रश्न का उत्तर देते हुए, मैं कहता हूँ "हाँ।" यहां तक कि अगर आप "आउट ऑफ द बॉक्स" का उपयोग करते हैं - अर्थात्, एसीआरएफ = हां मोड, तो ओएस, कैशे, हार्डवेयर और इतने पर अपडेट करने के लिए निर्धारित कार्य करना संभव है। सूचना प्रणाली का गैर-स्टॉप संचालन, साथ ही कैच डीबीएमएस की विफलताओं का स्वत: काबू शेष परिदृश्यों को पहले से ही ज्ञात साधनों की मदद से कवर किया जा सकता है "दशमलव बिंदु के बाद" नौ की आवश्यक संख्या में हार्डवेयर विफलता क्लस्टर और निर्बाध विद्युत प्रणाली।

InterSystems डेटाबेस मिररिंग। दर्पण बनाना और परीक्षण करना। भाग २