परिचय

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

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

अहिले व्यवस्थापनले अनुमति दिएको छ MIT लाइसेन्स अन्तर्गत खुला स्रोत समुदायमा परियोजना खोल्नुहोस्। README चाँडै अङ्ग्रेजीमा अनुवाद गरिनेछ (किनभने यो अपेक्षा गरिएको छ कि मुख्य उपभोक्ताहरू Pacemaker र PostgreSQL विकासकर्ताहरू हुनेछन्), र मैले README को पुरानो रूसी संस्करण (आंशिक रूपमा) यस लेखको रूपमा प्रस्तुत गर्ने निर्णय गरें।

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

सही समय सेवा एनटीपीडी गल्ती सहिष्णुताको लागि पनि पुन: कन्फिगर गरिएको छ, तर यो विधि आफै प्रयोग गर्दछ ntpd (अनाथ मोड)। साझा सर्भर साक्षी केन्द्रीय NTP सर्भरको रूपमा कार्य गर्दछ, यसको समय सबै क्लस्टरहरूमा वितरण गर्दछ, यसैले सबै सर्भरहरू एकअर्कासँग सिंक्रोनाइज गर्दछ। यदि साक्षी असफल हुन्छ वा अलग हुन्छ, त्यसपछि क्लस्टर सर्भरहरू मध्ये एक (क्लस्टर भित्र) आफ्नो समय वितरण गर्न सुरु हुनेछ। सहायक क्यासिङ HTTP प्रोक्सी मा पनि उठाइयो साक्षी, यसको मद्दतले, अन्य भर्चुअल मेसिनहरूले Yum भण्डारहरूमा पहुँच गर्न सक्छन्। वास्तवमा, सेवाहरू जस्तै सही समय र प्रोक्सीहरू प्राय: समर्पित सर्भरहरूमा होस्ट गरिनेछ, तर बुथमा तिनीहरू होस्ट गरिएका छन्। साक्षी भर्चुअल मेसिन र ठाउँको संख्या बचत गर्न मात्र।

संस्करणहरु

v0। VirtualBox 7 मा CentOS 11 र PostgreSQL 6.1 सँग काम गर्दछ।

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

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

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

यदि नोडहरूको संख्या बराबर छ (दुई डाटा केन्द्रहरूमा एक क्लस्टर), तब तथाकथित अनिश्चितता उत्पन्न हुन सक्छ। 50% / 50% (आधा आधा) जब नेटवर्क अलगावले क्लस्टरलाई ठ्याक्कै आधामा विभाजित गर्दछ। त्यसकारण, नोडहरूको समान संख्याको लागि, हामी थप्छौं कोरम यन्त्र तेस्रो डाटा सेन्टरमा सस्तो भर्चुअल मेसिनमा सुरु गर्न सकिने एक अनावश्यक डेमन हो। उसले आफ्नो भोट कुनै एउटा खण्डमा दिन्छ (जुन उसले देख्छ), र यसरी ५०%/५०% अनिश्चितता समाधान गर्छ। मैले सर्भरको नाम दिएँ जसमा कोरम उपकरण सुरु हुनेछ साक्षी (repmgr बाट शब्दावली, मलाई यो मनपर्यो)।

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

Tuchanka1 (कम्प्याक्शन सहितको सर्किट)

संरचना

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

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

दुई नोडहरूको मामलामा, गल्ती सहिष्णुता एसिन्क्रोनस प्रतिकृतिको साथ मात्र सम्भव छ, किनकि सिंक्रोनस प्रतिकृतिको साथ, दासको विफलताले मालिकको रोकिनेछ।

साक्षी दिन असफल

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

Tuchanka1 अस्वीकार

Tuchanka1 को लागि डाटा केन्द्रहरु मध्ये एक को विफलता। यस मामला मा साक्षी दोस्रो डाटा सेन्टरमा दोस्रो नोडमा मतदान गर्छ। त्यहाँ, पहिलेको दास मास्टरमा परिणत हुन्छ, नतिजाको रूपमा, दुबै मालिकहरू एउटै सर्भरमा काम गर्छन् र तिनीहरूको फ्लोट आईपीहरूले तिनीहरूलाई संकेत गर्दछ।

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

संरचना

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

दुई नोडहरूको मामलामा, गल्ती सहिष्णुता एसिन्क्रोनस प्रतिकृतिको साथ मात्र सम्भव छ, किनभने सिंक्रोनस प्रतिकृतिको साथ, दासको विफलताले मालिकको रोकिनेछ।

Tuchanka2 अस्वीकार

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

Tuchanka4 (धेरै दासहरू)

संरचना

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

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

Tuchanka4 अस्वीकार

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

ध्यान दिनुपर्ने पहिलो कुरा यो हो कि सबै दास फ्लोट आईपीहरू कामदारहरू हुनेछैनन्, तर एक मात्र। र यसलाई सही रूपमा काम गर्न यो आवश्यक हुनेछ sql प्रोक्सी सबै अनुरोधहरू मात्र बाँकी फ्लोट आईपीमा पुन: निर्देशित गरियो; र यदि sql प्रोक्सी होइन, त्यसोभए तपाईंले जडान URL मा अल्पविरामद्वारा छुट्याइएको सबै फ्लोट IP दासहरूलाई सूचीबद्ध गर्न सक्नुहुन्छ। यस अवस्थामा, संग libpq जडान पहिलो काम गर्ने IP मा हुनेछ, यो स्वचालित परीक्षण प्रणाली मा गरिन्छ। सायद अन्य पुस्तकालयहरूमा, उदाहरणका लागि, JDBC, यसले काम गर्दैन र आवश्यक छ sql प्रोक्सी। यो गरिएको हो किनभने दासहरूका लागि फ्लोट आईपीहरू एकै सर्भरमा एकै साथ उठाउन निषेध गरिएको छ, ताकि तिनीहरूमध्ये धेरै चलिरहेको खण्डमा दास सर्भरहरू बीच समान रूपमा वितरण गरिन्छ।

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

Tuchanka3 (3 डाटा केन्द्रहरू)

संरचना

यो स्थितिको लागि क्लस्टर हो जहाँ तीनवटा पूर्ण रूपमा कार्य गर्ने डाटा केन्द्रहरू छन्, जसमध्ये प्रत्येकमा पूर्ण रूपमा कार्य गर्ने डाटाबेस सर्भर छ। यस मामला मा कोरम यन्त्र चाहिदैन। एउटा डाटा सेन्टरमा मालिकद्वारा कर्मचारीहरू छन्, अन्य दुईमा दासहरू छन्। प्रतिकृति सिंक्रोनस हो, कुनै पनि टाइप गर्नुहोस् (स्लेभ१, दास २), अर्थात्, कुनै पनि दासले प्रतिबद्धता स्वीकार गरेको प्रतिक्रिया दिने पहिलो व्यक्ति हुँदा ग्राहकले प्रतिबद्धता पुष्टि गर्नेछ। स्रोतहरू मालिकको लागि एक फ्लोट आईपी र दासहरूको लागि दुई द्वारा संकेत गरिएको छ। Tuchanka1 को विपरीत, सबै तीन फ्लोट आईपीहरू दोष-सहिष्णु छन्। तपाईले प्रयोग गर्न सक्नुहुने पढ्ने मात्र SQL क्वेरीहरू सन्तुलनमा राख्न sql प्रोक्सी (अलग गल्ती सहिष्णुता संग), वा एक दास फ्लोट आईपी ग्राहकहरु को आधा, र दोस्रो को लागी अर्को आधा प्रदान गर्नुहोस्।

Tuchanka3 अस्वीकार

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

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

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

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

test/failure 2 3

दोस्रो र तेस्रो क्लस्टर मात्र परीक्षण गर्नेछ। यदि प्यारामिटरहरू निर्दिष्ट गरिएको छैन भने, त्यसपछि सबै क्लस्टरहरूको परीक्षण गरिनेछ। सबै क्लस्टरहरू समानान्तरमा परीक्षण गरिन्छ, र परिणाम tmux प्यानलमा प्रदर्शित हुन्छ। Tmux ले समर्पित tmux सर्भर प्रयोग गर्दछ, त्यसैले स्क्रिप्टलाई पूर्वनिर्धारित tmux बाट चलाउन सकिन्छ, परिणामस्वरूप एउटा नेस्टेड tmux हुन्छ। म एउटा ठूलो विन्डोमा र सानो फन्टको साथ टर्मिनल प्रयोग गर्न सिफारिस गर्दछु। परीक्षण सुरु हुनु अघि, स्क्रिप्ट पूरा हुँदा सबै भर्चुअल मेसिनहरू स्न्यापसटमा फिर्ता हुन्छन्। setup.

टर्मिनललाई परीक्षण गरिँदै आएको क्लस्टरहरूको संख्या अनुसार स्तम्भहरूमा विभाजन गरिएको छ; पूर्वनिर्धारित रूपमा (स्क्रिनसटमा) त्यहाँ चार छन्। म Tuchanka2 को उदाहरण प्रयोग गरेर स्तम्भहरूको सामग्री वर्णन गर्नेछु। स्क्रिनसटमा प्यानलहरू नम्बर गरिएका छन्:

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

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

प्रत्येक परीक्षणमा निम्न कार्यहरू हुन्छन्:

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

यहाँ तिनीहरूले के गर्छन् भन्ने विवरणको साथ परीक्षणहरूको सूची छ:

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

मानक tmux आदेश "kill-window" प्रयोग गरेर परीक्षण पूरा गर्दै Ctrl-b र, वा "detach-client" आदेश Ctrl-b d: यस बिन्दुमा परीक्षण समाप्त हुन्छ, tmux बन्द हुन्छ, भर्चुअल मेसिनहरू बन्द हुन्छन्।

परीक्षणको क्रममा पहिचान गरिएका समस्याहरू

• यो क्षण मा वाचडग राक्षस sbd अवलोकन गरिएका डेमनहरूलाई रोक्न काम गर्दछ, तर तिनीहरूलाई फ्रिज गर्दैन। र, नतिजाको रूपमा, गल्तीहरू जसले फ्रिजिङ मात्र निम्त्याउँछ Corosync и pacemaker, तर झुण्डिएको छैन sbd... जाँच को लागी Corosync पहिले नै छ PR#१७०३६३ (GitHub मा मा sbd), थ्रेडमा स्वीकार गरियो मास्टर। तिनीहरूले वाचा गरे (PR # 83 मा) कि त्यहाँ Pacemaker को लागी केहि समान हुनेछ, मलाई आशा छ कि रेडह्याट ७ काम चल्छ। तर त्यस्ता "गल्तीहरू" सट्टा हो र सजिलै संग कृत्रिम रूपमा प्रयोग गर्न सकिन्छ, उदाहरणका लागि, killall -STOP corosyncतर वास्तविक जीवनमा कहिल्यै भेटिएन।

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

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

• यदि wal_receiver_timeout सेट गरिएको छ (पूर्वनिर्धारित रूपमा यो 60s हो), त्यसपछि tuchanka3 र tuchanka4 क्लस्टरहरूमा मास्टरमा PostgreSQL-STOP परीक्षणको क्रममा प्रतिकृति नयाँ मास्टरमा पुन: जडान हुँदैन। त्यहाँ प्रतिकृति सिंक्रोनस छ, त्यसैले दास मात्र रोक्दैन, तर नयाँ मालिक पनि। PostgreSQL कन्फिगर गर्दा wal_receiver_timeout=0 सेट गरेर काम गर्दछ।

• कहिले काँही मैले फोर्कबम परीक्षण (मेमोरी ओभरफ्लो) मा PostgreSQL मा प्रतिकृति फ्रिज देखेको छु। ForkBomb पछि, कहिलेकाहीँ दासहरू नयाँ मालिकसँग पुन: जडान नहुन सक्छन्। मैले यो tuchanka3 र tuchanka4 क्लस्टरहरूमा मात्र भेटेको छु, जहाँ सिंक्रोनस प्रतिकृतिको कारण मास्टर फ्रिज भयो। लामो समय (लगभग दुई घण्टा) पछि समस्या आफैं हट्यो। यसलाई सच्याउन थप अनुसन्धान आवश्यक छ। लक्षणहरू अघिल्लो बगसँग मिल्दोजुल्दो छन्, जुन फरक कारणले गर्दा हुन्छ, तर परिणामहरू उस्तै हुन्छन्।

क्रोगनबाट लिइएको तस्बिर विकृत कला लेखक को अनुमति संग:

स्रोत: www.habr.com