परिचय

कुछ समय पहले मुझे फेलओवर क्लस्टर विकसित करने का काम दिया गया था पोस्टग्रेएसक्यूएल, एक शहर के भीतर ऑप्टिकल फाइबर से जुड़े कई डेटा केंद्रों में काम कर रहा है, और एक डेटा सेंटर की विफलता (उदाहरण के लिए, ब्लैकआउट) को झेलने में सक्षम है। सॉफ़्टवेयर के रूप में जो दोष सहनशीलता के लिए ज़िम्मेदार है, मैंने इसे चुना लीडरक्योंकि फेलओवर क्लस्टर बनाने के लिए यह RedHat का आधिकारिक समाधान है। यह अच्छा है क्योंकि RedHat इसके लिए समर्थन प्रदान करता है, और क्योंकि यह समाधान सार्वभौमिक (मॉड्यूलर) है। इसकी मदद से, न केवल PostgreSQL, बल्कि अन्य सेवाओं की भी दोष सहनशीलता सुनिश्चित करना संभव होगा, या तो मानक मॉड्यूल का उपयोग करके या उन्हें विशिष्ट आवश्यकताओं के लिए बनाकर।

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

अब प्रबंधन ने अनुमति दे दी है एमआईटी लाइसेंस के तहत ओपन सोर्स समुदाय के लिए प्रोजेक्ट खोलें. README का जल्द ही अंग्रेजी में अनुवाद किया जाएगा (क्योंकि यह उम्मीद है कि मुख्य उपभोक्ता पेसमेकर और PostgreSQL डेवलपर्स होंगे), और मैंने इस लेख के रूप में README के ​​पुराने रूसी संस्करण (आंशिक रूप से) को प्रस्तुत करने का निर्णय लिया है।

वर्चुअल मशीनों पर क्लस्टर तैनात किए जाते हैं VirtualBox. कुल 12 वर्चुअल मशीनें (कुल 36GiB) तैनात की जाएंगी, जो 4 दोष-सहिष्णु क्लस्टर (विभिन्न विकल्प) बनाती हैं। पहले दो क्लस्टर में दो PostgreSQL सर्वर होते हैं, जो विभिन्न डेटा केंद्रों में स्थित होते हैं, और एक सामान्य सर्वर होता है गवाह c कोरम उपकरण (तीसरे डेटा सेंटर में एक सस्ती वर्चुअल मशीन पर होस्ट किया गया), जो अनिश्चितता का समाधान करता है 50% / 50%, किसी एक पार्टी को अपना वोट देना। तीन डेटा केंद्रों में तीसरा क्लस्टर: एक मास्टर, दो दास, नहीं कोरम उपकरण. चौथे क्लस्टर में चार PostgreSQL सर्वर होते हैं, प्रति डेटा सेंटर दो: एक मास्टर, बाकी प्रतिकृतियां, और इसका उपयोग भी करता है गवाह c कोरम उपकरण. चौथा दो सर्वर या एक डेटा सेंटर की विफलता का सामना कर सकता है। यदि आवश्यक हो तो इस समाधान को बड़ी संख्या में प्रतिकृतियों तक बढ़ाया जा सकता है।

सटीक समय सेवा एनटीपीडी दोष सहनशीलता के लिए भी पुन: कॉन्फ़िगर किया गया है, लेकिन यह विधि का ही उपयोग करता है ntpd (अनाथ मोड). साझा सर्वर गवाह एक केंद्रीय एनटीपी सर्वर के रूप में कार्य करता है, जो अपना समय सभी समूहों में वितरित करता है, जिससे सभी सर्वर एक दूसरे के साथ सिंक्रनाइज़ होते हैं। अगर गवाह विफल हो जाता है या अलग हो जाता है, तो क्लस्टर सर्वरों में से एक (क्लस्टर के भीतर) अपना समय वितरित करना शुरू कर देगा। सहायक कैशिंग HTTP प्रॉक्सी तक भी बढ़ा दिया गया है गवाह, इसकी मदद से अन्य वर्चुअल मशीनों को यम रिपॉजिटरी तक पहुंच प्राप्त होती है। वास्तव में, सटीक समय और प्रॉक्सी जैसी सेवाओं को संभवतः समर्पित सर्वर पर होस्ट किया जाएगा, लेकिन बूथ में उन्हें होस्ट किया जाता है गवाह केवल वर्चुअल मशीनों और स्थान की संख्या बचाने के लिए।

संस्करणों

वि0. वर्चुअलबॉक्स 7 पर CentOS 11 और PostgreSQL 6.1 के साथ काम करता है।

क्लस्टर संरचना

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

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

यदि नोड्स की संख्या सम है (दो डेटा केंद्रों में एक क्लस्टर), तो तथाकथित अनिश्चितता उत्पन्न हो सकती है 50% / 50% (समान) जब नेटवर्क अलगाव क्लस्टर को बिल्कुल आधे में विभाजित करता है। इसलिए, सम संख्या में नोड्स के लिए, हम जोड़ते हैं कोरम उपकरण एक बिना मांग वाला डेमॉन है जिसे तीसरे डेटा सेंटर में सबसे सस्ती वर्चुअल मशीन पर लॉन्च किया जा सकता है। वह किसी एक खंड (जिसे वह देखता है) को अपना वोट देता है, और इस तरह 50%/50% अनिश्चितता का समाधान करता है। मैंने उस सर्वर का नाम दिया है जिस पर कोरम डिवाइस लॉन्च किया जाएगा गवाह (रेपएमजीआर से शब्दावली, मुझे यह पसंद आई)।

संसाधनों को एक स्थान से दूसरे स्थान पर ले जाया जा सकता है, उदाहरण के लिए, दोषपूर्ण सर्वर से अच्छे सर्वर पर, या सिस्टम प्रशासक के आदेश पर। ताकि ग्राहकों को पता चले कि उन्हें जिन संसाधनों की आवश्यकता है वे कहां स्थित हैं (कहां कनेक्ट करें?), फ्लोटिंग आईपी (फ्लोट आईपी). ये आईपी हैं जिन्हें पेसमेकर नोड्स के चारों ओर घुमा सकता है (सबकुछ एक फ्लैट नेटवर्क पर है)। उनमें से प्रत्येक एक संसाधन (सेवा) का प्रतीक है और वहां स्थित होगा जहां आपको इस सेवा (हमारे मामले में, एक डेटाबेस) तक पहुंच प्राप्त करने के लिए कनेक्ट करने की आवश्यकता है।

Tuchanka1 (संघनन के साथ सर्किट)

संरचना

विचार यह था कि हमारे पास कम लोड वाले कई छोटे डेटाबेस हैं, जिनके लिए केवल पढ़ने के लेनदेन के लिए हॉट स्टैंडबाय मोड में एक समर्पित स्लेव सर्वर को बनाए रखना लाभहीन है (संसाधनों की इतनी बर्बादी की कोई आवश्यकता नहीं है)।

प्रत्येक डेटा सेंटर में एक सर्वर होता है। प्रत्येक सर्वर में दो PostgreSQL उदाहरण होते हैं (PostgreSQL शब्दावली में उन्हें क्लस्टर कहा जाता है, लेकिन भ्रम से बचने के लिए मैं उन्हें उदाहरण कहूंगा (अन्य डेटाबेस के साथ सादृश्य द्वारा), और मैं केवल पेसमेकर क्लस्टर क्लस्टर कहूंगा)। एक उदाहरण मास्टर मोड में काम करता है, और केवल यह सेवाएं प्रदान करता है (केवल फ्लोट आईपी ही इसकी ओर ले जाता है)। दूसरा उदाहरण दूसरे डेटा सेंटर के लिए गुलाम के रूप में काम करता है, और केवल तभी सेवाएं प्रदान करेगा जब उसका मास्टर विफल हो जाए। चूंकि अधिकांश समय दो में से केवल एक उदाहरण (मास्टर) सेवाएं प्रदान करेगा (अनुरोध निष्पादित करेगा), सभी सर्वर संसाधनों को मास्टर के लिए अनुकूलित किया गया है (मेमोरी साझा_बफ़र्स कैश आदि के लिए आवंटित की गई है), लेकिन ताकि दूसरा उदाहरण डेटा केंद्रों में से किसी एक की विफलता के मामले में भी पर्याप्त संसाधन हैं (यद्यपि फ़ाइल सिस्टम कैश के माध्यम से उप-इष्टतम संचालन के लिए)। क्लस्टर के सामान्य संचालन के दौरान स्लेव सेवाएं प्रदान नहीं करता है (केवल पढ़ने के लिए अनुरोध नहीं करता है), ताकि एक ही मशीन पर मास्टर के साथ संसाधनों के लिए कोई युद्ध न हो।

दो नोड्स के मामले में, दोष सहिष्णुता केवल अतुल्यकालिक प्रतिकृति के साथ संभव है, क्योंकि तुल्यकालिक प्रतिकृति के साथ, दास की विफलता के कारण मास्टर रुक जाएगा।

गवाही न देना

गवाही देने में विफलता (कोरम उपकरण) मैं केवल Tuchanka1 क्लस्टर के लिए विचार करूंगा, अन्य सभी के साथ भी यही कहानी होगी। यदि गवाह विफल हो जाता है, तो क्लस्टर संरचना में कुछ भी नहीं बदलेगा, सब कुछ उसी तरह काम करता रहेगा जैसे उसने किया था। लेकिन कोरम 2 में से 3 हो जाएगा, और इसलिए बाद की कोई भी विफलता क्लस्टर के लिए घातक होगी। इसे अभी भी तत्काल ठीक करना होगा.

Tuchanka1 इनकार

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

Tuchanka2 (शास्त्रीय)

संरचना

दो नोड्स की क्लासिक योजना। एक पर मालिक काम करता है, दूसरे पर गुलाम। दोनों अनुरोध निष्पादित कर सकते हैं (दास केवल पढ़ने के लिए है), इसलिए दोनों को फ्लोट आईपी द्वारा इंगित किया जाता है: krogan2 मास्टर है, krogan2s1 दास है। स्वामी और दास दोनों में दोष सहनशीलता होगी।

दो नोड्स के मामले में, दोष सहिष्णुता केवल अतुल्यकालिक प्रतिकृति के साथ संभव है, क्योंकि तुल्यकालिक प्रतिकृति के साथ, दास की विफलता के कारण मास्टर रुक जाएगा।

Tuchanka2 इनकार

यदि कोई डेटा सेंटर विफल हो जाता है गवाह दूसरे के लिए वोट करें. एकमात्र कार्यशील डेटा सेंटर पर, मास्टर को उठाया जाएगा, और दोनों फ्लोट आईपी इसे इंगित करेंगे: मास्टर और स्लेव। बेशक, इंस्टेंस को इस तरह से कॉन्फ़िगर किया जाना चाहिए कि इसमें मास्टर और स्लेव फ्लोट आईपी से सभी कनेक्शन और अनुरोधों को एक साथ स्वीकार करने के लिए पर्याप्त संसाधन (कनेक्शन सीमा आदि) हों। यानी सामान्य ऑपरेशन के दौरान इसकी सीमा की पर्याप्त आपूर्ति होनी चाहिए।

Tuchanka4 (कई गुलाम)

संरचना

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

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

Tuchanka4 इनकार

यदि एक डेटा सेंटर (यानी, दो सर्वर) विफल हो जाता है, तो गवाह दूसरे के लिए वोट करता है। परिणामस्वरूप, दूसरे डेटा सेंटर में दो सर्वर चल रहे हैं: एक मास्टर चला रहा है, और मास्टर फ्लोट आईपी इसे इंगित करता है (पढ़ने-लिखने के अनुरोध प्राप्त करने के लिए); और दूसरे सर्वर पर सिंक्रोनस प्रतिकृति के साथ एक स्लेव चल रहा है, और स्लेव फ्लोट आईपी में से एक इसे इंगित करता है (केवल पढ़ने के अनुरोधों के लिए)।

ध्यान देने वाली पहली बात यह है कि सभी स्लेव फ्लोट आईपी श्रमिक नहीं होंगे, बल्कि केवल एक ही होंगे। और इसके साथ सही ढंग से काम करने के लिए यह आवश्यक होगा एसक्यूएल प्रॉक्सी सभी अनुरोधों को एकमात्र शेष फ्लोट आईपी पर पुनर्निर्देशित किया गया; और अगर एसक्यूएल प्रॉक्सी नहीं, तो आप कनेक्शन यूआरएल में अल्पविराम से अलग किए गए सभी फ्लोट आईपी स्लेव को सूचीबद्ध कर सकते हैं। इस मामले में, साथ libpq कनेक्शन पहले कार्यशील आईपी से होगा, यह स्वचालित परीक्षण प्रणाली में किया जाता है। शायद अन्य पुस्तकालयों में, उदाहरण के लिए, जेडीबीसी, यह काम नहीं करेगा और आवश्यक है एसक्यूएल प्रॉक्सी. ऐसा इसलिए किया जाता है क्योंकि दासों के लिए फ्लोट आईपी को एक सर्वर पर एक साथ उठाए जाने से प्रतिबंधित किया जाता है, ताकि यदि उनमें से कई चल रहे हों तो उन्हें दास सर्वरों के बीच समान रूप से वितरित किया जा सके।

दूसरा: डेटा सेंटर की विफलता की स्थिति में भी, समकालिक प्रतिकृति बनाए रखी जाएगी। और यदि कोई द्वितीयक विफलता होती है, यानी, शेष डेटा सेंटर में दो सर्वरों में से एक विफल हो जाता है, तो क्लस्टर, हालांकि यह सेवाएं प्रदान करना बंद कर देगा, फिर भी सभी प्रतिबद्ध लेनदेन के बारे में जानकारी बनाए रखेगा जिसके लिए उसने प्रतिबद्धता की पुष्टि दी है (द्वितीयक विफलता के मामले में कोई हानि की जानकारी नहीं होगी)।

Tuchanka3 (3 डेटा सेंटर)

संरचना

यह ऐसी स्थिति के लिए एक क्लस्टर है जहां तीन पूरी तरह से काम करने वाले डेटा सेंटर हैं, जिनमें से प्रत्येक में एक पूरी तरह से काम करने वाला डेटाबेस सर्वर है। इस मामले में कोरम उपकरण जरूरत नहीं। एक डेटा सेंटर में एक मास्टर का स्टाफ होता है, अन्य दो में गुलामों का स्टाफ होता है। प्रतिकृति तुल्यकालिक है, कोई भी टाइप करें (स्लेव1, स्लेव2), यानी, क्लाइंट को एक कमिट पुष्टिकरण प्राप्त होगा जब कोई भी स्लेव सबसे पहले जवाब देगा कि उसने कमिट स्वीकार कर लिया है। संसाधनों को मास्टर के लिए एक फ्लोट आईपी और दासों के लिए दो द्वारा दर्शाया जाता है। Tuchanka4 के विपरीत, सभी तीन फ्लोट आईपी दोष-सहिष्णु हैं। केवल पढ़ने योग्य SQL क्वेरीज़ को संतुलित करने के लिए आप इसका उपयोग कर सकते हैं एसक्यूएल प्रॉक्सी (अलग दोष सहनशीलता के साथ), या एक स्लेव फ्लोट आईपी को आधे ग्राहकों को और दूसरे आधे को दूसरे को असाइन करें।

Tuchanka3 इनकार

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

मैंने फ़ाइल संरचना और परिनियोजन का विस्तृत विवरण शामिल नहीं करने का निर्णय लिया। जो कोई भी खेलना चाहता है वह README में यह सब पढ़ सकता है। मैं केवल स्वचालित परीक्षण का विवरण प्रदान कर रहा हूं।

स्वचालित परीक्षण प्रणाली

विभिन्न दोषों का अनुकरण करके समूहों की दोष सहनशीलता का परीक्षण करने के लिए, एक स्वचालित परीक्षण प्रणाली बनाई गई है। स्क्रिप्ट द्वारा लॉन्च किया गया test/failure. स्क्रिप्ट उन क्लस्टरों की संख्या को पैरामीटर के रूप में ले सकती है जिनका आप परीक्षण करना चाहते हैं। उदाहरण के लिए यह आदेश:

test/failure 2 3

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

टर्मिनल को परीक्षण किए जा रहे क्लस्टरों की संख्या के अनुसार कॉलम में विभाजित किया गया है; डिफ़ॉल्ट रूप से (स्क्रीनशॉट में) चार हैं। मैं Tuchanka2 के उदाहरण का उपयोग करके कॉलम की सामग्री का वर्णन करूंगा। स्क्रीनशॉट में पैनल क्रमांकित हैं:

1. परीक्षण आँकड़े यहाँ प्रदर्शित किए गए हैं। कॉलम:
   • विफलता - परीक्षण का नाम (स्क्रिप्ट में फ़ंक्शन) जो गलती का अनुकरण करता है।
   • प्रतिक्रिया - सेकंड में अंकगणितीय औसत समय जिसके दौरान क्लस्टर ने अपनी कार्यक्षमता को पुनः प्राप्त किया। इसे किसी गलती का अनुकरण करने वाली स्क्रिप्ट की शुरुआत से उस क्षण तक मापा जाता है जब क्लस्टर अपनी कार्यक्षमता को पुनर्स्थापित करता है और सेवाएं प्रदान करना जारी रखने में सक्षम होता है। यदि समय बहुत कम है, उदाहरण के लिए, छह सेकंड (यह कई दासों (Tuchanka3 और Tuchanka4) वाले समूहों में होता है), इसका मतलब है कि गलती अतुल्यकालिक दास पर थी और किसी भी तरह से प्रदर्शन को प्रभावित नहीं किया; वहाँ कोई नहीं था क्लस्टर स्थिति स्विच।
   • विचलन - मूल्य का प्रसार (सटीकता) दर्शाता है प्रतिक्रिया मानक विचलन विधि का उपयोग करना।
   • गणना - यह परीक्षण कितनी बार किया गया।
2. एक संक्षिप्त लॉग आपको यह मूल्यांकन करने की अनुमति देता है कि क्लस्टर वर्तमान में क्या कर रहा है। पुनरावृत्ति (परीक्षण) संख्या, टाइमस्टैम्प और ऑपरेशन का नाम प्रदर्शित किया जाता है। बहुत देर तक दौड़ना (> 5 मिनट) किसी समस्या का संकेत देता है।
3. दिल (हृदय)-वर्तमान समय। प्रदर्शन के दृश्य मूल्यांकन के लिए परास्नातक फ्लोट आईपी मास्टर का उपयोग करके वर्तमान समय को लगातार इसकी तालिका में लिखा जाता है। सफल होने पर, परिणाम इस पैनल में प्रदर्शित होता है।
4. हरा (पल्स) - "वर्तमान समय", जो पहले स्क्रिप्ट द्वारा दर्ज किया गया था दिल मास्टर करने के लिए, अब से पढ़ें दास इसके फ्लोट आईपी के माध्यम से। आपको दास और प्रतिकृति के प्रदर्शन का दृश्य मूल्यांकन करने की अनुमति देता है। Tuchanka1 में फ्लोट आईपी के साथ कोई गुलाम नहीं है (सेवाएं प्रदान करने वाला कोई गुलाम नहीं है), लेकिन दो उदाहरण (डीबी) हैं, इसलिए इसे यहां नहीं दिखाया जाएगा हराऔर दिल दूसरा उदाहरण.
5. उपयोगिता का उपयोग करके क्लस्टर स्वास्थ्य की निगरानी करना pcs mon. संरचना, नोड्स में संसाधनों का वितरण और अन्य उपयोगी जानकारी दिखाता है।
6. क्लस्टर में प्रत्येक वर्चुअल मशीन से सिस्टम मॉनिटरिंग यहां प्रदर्शित की गई है। क्लस्टर में कितनी वर्चुअल मशीनें हैं, इसके आधार पर ऐसे और भी पैनल हो सकते हैं। दो ग्राफ़ सीपीयू लोड (वर्चुअल मशीनों में दो प्रोसेसर होते हैं), वर्चुअल मशीन का नाम, सिस्टम लोड (इसे लोड औसत नाम दिया गया है क्योंकि इसका औसत 5, 10 और 15 मिनट में होता है), प्रक्रिया डेटा और मेमोरी आवंटन।
7. परीक्षण कर रही स्क्रिप्ट का ट्रेस। खराबी की स्थिति में - संचालन में अचानक रुकावट या अंतहीन प्रतीक्षा चक्र - यहां आप इस व्यवहार का कारण देख सकते हैं।

परीक्षण दो चरणों में किया जाता है। सबसे पहले, स्क्रिप्ट सभी प्रकार के परीक्षणों से गुजरती है, बेतरतीब ढंग से एक वर्चुअल मशीन का चयन करती है जिस पर यह परीक्षण लागू किया जाए। फिर परीक्षण का एक अंतहीन चक्र चलाया जाता है, हर बार आभासी मशीनों और दोषों को यादृच्छिक रूप से चुना जाता है। परीक्षण स्क्रिप्ट (निचला पैनल) की अचानक समाप्ति या किसी चीज़ के लिए प्रतीक्षा करने का अंतहीन चक्र (> एक ऑपरेशन के लिए 5 मिनट का निष्पादन समय, इसे ट्रेस में देखा जा सकता है) इंगित करता है कि इस क्लस्टर पर कुछ परीक्षण विफल हो गए हैं।

प्रत्येक परीक्षण में निम्नलिखित ऑपरेशन शामिल हैं:

1. एक फ़ंक्शन लॉन्च करें जो किसी गलती का अनुकरण करता है।
2. तैयार? - क्लस्टर के बहाल होने की प्रतीक्षा की जा रही है (जब सभी सेवाएँ प्रदान की जाती हैं)।
3. क्लस्टर पुनर्प्राप्ति समयबाह्य दिखाता है (प्रतिक्रिया).
4. फिक्स - क्लस्टर की "मरम्मत" की जा रही है। जिसके बाद इसे पूरी तरह से चालू स्थिति में लौट आना चाहिए और अगली खराबी के लिए तैयार रहना चाहिए।

यहां परीक्षणों की एक सूची दी गई है जिसमें बताया गया है कि वे क्या करते हैं:

• को forkbomb: फोर्क बम का उपयोग करके "स्मृति से बाहर" बनाता है।
• अंतरिक्ष से बाहर: हार्ड ड्राइव भर गई है. लेकिन परीक्षण प्रतीकात्मक है; परीक्षण के दौरान उत्पन्न होने वाले महत्वहीन लोड के साथ, हार्ड ड्राइव भर जाने पर PostgreSQL आमतौर पर विफल नहीं होता है।
• पोस्टग्रेस-किल: कमांड से PostgreSQL को मारता है killall -KILL postgres.
• पोस्टग्रेस-स्टॉप: PostgreSQL कमांड हैंग हो जाता है killall -STOP postgres.
• poweroff: कमांड के साथ वर्चुअल मशीन को "डी-एनर्जेट" करता है VBoxManage controlvm "виртуалка" poweroff.
• रीसेट: कमांड के साथ वर्चुअल मशीन को ओवरलोड करता है VBoxManage controlvm "виртуалка" reset.
• एसबीडी-स्टॉप: कमांड के साथ एसबीडी दानव को निलंबित करता है killall -STOP sbd.
• बंद: SSH के माध्यम से वर्चुअल मशीन को एक कमांड भेजता है systemctl poweroff, सिस्टम शालीनता से बंद हो जाता है।
• उतारना: नेटवर्क अलगाव, आदेश VBoxManage controlvm "виртуалка" setlinkstate1 off.

मानक tmux कमांड "किल-विंडो" का उपयोग करके परीक्षण पूरा करना Ctrl-बी &, या "डिटैच-क्लाइंट" कमांड Ctrl-बी डी: इस बिंदु पर परीक्षण समाप्त हो जाता है, tmux बंद हो जाता है, वर्चुअल मशीनें बंद हो जाती हैं।

परीक्षण के दौरान समस्याओं की पहचान की गई

• फिलहाल, प्रहरी दानव एसबीडी प्रेक्षित डेमॉन को रोकने पर काम करता है, लेकिन उन्हें फ़्रीज़ करने पर नहीं। और, परिणामस्वरूप, दोष जो केवल ठंड की ओर ले जाते हैं कोरोसिंक и लीडर, लेकिन लटका नहीं एसबीडी. जांच के लिए कोरोसिंक पहले से ही है पीआर#83 (GitHub पर एसबीडी), सूत्र को स्वीकार किया गया मास्टर. उन्होंने वादा किया था (पीआर#83 में) कि पेसमेकर के लिए भी कुछ ऐसा ही होगा, मुझे उम्मीद है कि ऐसा होगा RedHat 8 करूंगा। लेकिन ऐसी "ख़राबियाँ" काल्पनिक हैं और उदाहरण के लिए, कृत्रिम रूप से इनका आसानी से अनुकरण किया जा सकता है। killall -STOP corosync, लेकिन असल जिंदगी में कभी नहीं मिलते।

• У लीडर के लिए संस्करण में 7 CentOS ग़लत ढंग से सेट किया गया सिंक_टाइमआउट у कोरम उपकरण, नतीजतन यदि एक नोड विफल हो जाता है, तो कुछ संभावना के साथ दूसरा नोड भी रीबूट हो जाता है, जिस ओर स्वामी को जाना था। विस्तार से ठीक हो गया सिंक_टाइमआउट у कोरम उपकरण तैनाती के दौरान (स्क्रिप्ट में) setup/setup1). यह संशोधन डेवलपर्स द्वारा स्वीकार नहीं किया गया लीडर, इसके बजाय उन्होंने बुनियादी ढांचे को इस तरह से (कुछ अनिर्दिष्ट भविष्य में) फिर से डिजाइन करने का वादा किया कि इस टाइमआउट की गणना स्वचालित रूप से की जाएगी।

• यदि डेटाबेस कॉन्फ़िगरेशन उसे निर्दिष्ट करता है LC_MESSAGES (पाठ संदेश) यूनिकोड का उपयोग किया जा सकता है, उदा. ru_RU.UTF-8, फिर स्टार्टअप पर postgres ऐसे वातावरण में जहां लोकेल यूटीएफ-8 नहीं है, खाली वातावरण में कहें (यहां)। पेसमेकर+pgsqlms(पीएएफ) चलता है postgres), फिर लॉग में UTF-8 अक्षरों के स्थान पर प्रश्न चिह्न होंगे. PostgreSQL डेवलपर्स इस बात पर सहमत नहीं हैं कि इस मामले में क्या करना है। इसकी लागत है, आपको स्थापित करने की आवश्यकता है LC_MESSAGES=en_US.UTF-8 डेटाबेस इंस्टेंस को कॉन्फ़िगर (बनाते) करते समय।

• यदि wal_receiver_timeout सेट है (डिफ़ॉल्ट रूप से यह 60s है), तो Tuchanka3 और Tuchanka4 क्लस्टर में मास्टर पर PostgreSQL-STOP परीक्षण के दौरान प्रतिकृति नए मास्टर से पुनः कनेक्ट नहीं होती है. वहां प्रतिकृति समकालिक है, इसलिए न केवल दास रुकता है, बल्कि नया स्वामी भी रुकता है। PostgreSQL को कॉन्फ़िगर करते समय wal_receiver_timeout=0 सेट करके काम करता है।

• कभी-कभी मैंने फोर्कबॉम्ब परीक्षण (मेमोरी ओवरफ़्लो) में PostgreSQL में प्रतिकृति फ़्रीज़ देखी। फोर्कबॉम्ब के बाद, कभी-कभी दास नए मास्टर से दोबारा नहीं जुड़ पाते हैं. मैंने इसका सामना केवल Tuchanka3 और Tuchanka4 क्लस्टर में किया है, जहां सिंक्रोनस प्रतिकृति के कारण मास्टर फ़्रीज़ हो गया था। काफी देर (करीब दो घंटे) के बाद समस्या अपने आप दूर हो गई। इसे ठीक करने के लिए और अधिक शोध की आवश्यकता है। लक्षण पिछले बग के समान हैं, जो एक अलग कारण से होता है, लेकिन समान परिणाम के साथ।

क्रोगन चित्र से लिया गया Deviant कला लेखक की अनुमति से:

स्रोत: www.habr.com