परिचय

काही काळापूर्वी मला एक फेलओव्हर क्लस्टर विकसित करण्याचे काम देण्यात आले होते पोस्टग्रे एसक्यूएल, एका शहरामध्ये ऑप्टिकल फायबरने जोडलेल्या अनेक डेटा सेंटर्समध्ये कार्यरत आणि एका डेटा सेंटरचे अपयश (उदाहरणार्थ, ब्लॅकआउट) सहन करण्यास सक्षम. दोष सहिष्णुतेसाठी जबाबदार असलेले सॉफ्टवेअर म्हणून, मी निवडले पेसमेकरकारण हे फेलओव्हर क्लस्टर्स तयार करण्यासाठी RedHat कडून अधिकृत उपाय आहे. हे चांगले आहे कारण RedHat यासाठी समर्थन पुरवते आणि कारण हे समाधान सार्वत्रिक (मॉड्युलर) आहे. त्याच्या मदतीने, केवळ PostgreSQL चीच नाही तर इतर सेवांमध्येही दोष सहिष्णुता सुनिश्चित करणे शक्य होईल, एकतर मानक मॉड्यूल वापरून किंवा विशिष्ट गरजांसाठी तयार करा.

या निर्णयाने वाजवी प्रश्न उपस्थित केला: फेलओव्हर क्लस्टर किती दोष-सहिष्णु असेल? याची तपासणी करण्यासाठी, मी एक चाचणी खंडपीठ विकसित केले जे क्लस्टर नोड्सवरील विविध अपयशांचे अनुकरण करते, सेवा पुनर्संचयित होण्याची प्रतीक्षा करते, अयशस्वी नोड पुनर्प्राप्त करते आणि लूपमध्ये चाचणी सुरू ठेवते. या प्रकल्पाला सुरुवातीला hapgsql असे म्हटले जात होते, परंतु कालांतराने मला या नावाचा कंटाळा आला, ज्यामध्ये फक्त एक स्वर होता. म्हणून, मी दोष-सहिष्णु डेटाबेसेस कॉल करण्यास सुरुवात केली (आणि फ्लोट आयपी त्यांच्याकडे निर्देशित करते) क्रोगन (संगणक गेममधील एक वर्ण ज्यामध्ये सर्व महत्वाचे अवयव डुप्लिकेट केले जातात), आणि नोड्स, क्लस्टर्स आणि प्रकल्प स्वतःच tuchanka (ज्या ग्रहात क्रोगन्स राहतात).

आता व्यवस्थापनाने परवानगी दिली आहे एमआयटी परवान्याअंतर्गत ओपन सोर्स समुदायासाठी प्रकल्प उघडा. README लवकरच इंग्रजीमध्ये अनुवादित केले जाईल (कारण हे अपेक्षित आहे की मुख्य ग्राहक पेसमेकर आणि PostgreSQL विकासक असतील), आणि मी या लेखाच्या रूपात README ची जुनी रशियन आवृत्ती (अंशत:) सादर करण्याचे ठरवले आहे.

व्हर्च्युअल मशीनवर क्लस्टर्स तैनात केले आहेत वर्च्युअलबॉक्स. एकूण 12 व्हर्च्युअल मशीन (एकूण 36GiB) तैनात केल्या जातील, जे 4 दोष-सहिष्णु क्लस्टर (वेगवेगळे पर्याय) बनवतात. पहिल्या दोन क्लस्टरमध्ये दोन PostgreSQL सर्व्हर असतात, जे वेगवेगळ्या डेटा सेंटरमध्ये असतात आणि एक सामान्य सर्व्हर साक्षीदार c कोरम डिव्हाइस (तिसऱ्या डेटा सेंटरमध्ये स्वस्त व्हर्च्युअल मशीनवर होस्ट केलेले), जे अनिश्चिततेचे निराकरण करते 50% / 50%, पक्षांपैकी एकाला तुमचे मत देणे. तीन डेटा सेंटरमध्ये तिसरा क्लस्टर: एक मास्टर, दोन गुलाम, क्र कोरम डिव्हाइस. चौथ्या क्लस्टरमध्ये चार PostgreSQL सर्व्हर असतात, दोन प्रति डेटा सेंटर: एक मास्टर, बाकीच्या प्रतिकृती आणि वापरतात साक्षीदार c कोरम डिव्हाइस. चौथा दोन सर्व्हर किंवा एका डेटा सेंटरच्या अपयशाचा सामना करू शकतो. हे समाधान आवश्यक असल्यास मोठ्या संख्येने प्रतिकृतींमध्ये मोजले जाऊ शकते.

अचूक वेळेची सेवा एनटीपीडी दोष सहिष्णुतेसाठी देखील पुन्हा कॉन्फिगर केले आहे, परंतु ते स्वतःच पद्धत वापरते ntpd (अनाथ मोड). शेअर केलेला सर्व्हर साक्षीदार मध्यवर्ती NTP सर्व्हर म्हणून कार्य करते, त्याचा वेळ सर्व क्लस्टर्समध्ये वितरीत करते, त्याद्वारे सर्व सर्व्हर एकमेकांशी समक्रमित होते. तर साक्षीदार अयशस्वी होते किंवा वेगळे होते, नंतर क्लस्टर सर्व्हरपैकी एक (क्लस्टरमध्ये) त्याचा वेळ वितरित करण्यास सुरवात करेल. सहायक कॅशिंग HTTP प्रॉक्सी पर्यंत देखील वाढविले साक्षीदार, त्याच्या मदतीने, इतर व्हर्च्युअल मशीन्सना यम रेपॉजिटरीजमध्ये प्रवेश आहे. प्रत्यक्षात, अचूक वेळ आणि प्रॉक्सी यासारख्या सेवा बहुधा समर्पित सर्व्हरवर होस्ट केल्या जातील, परंतु बूथमध्ये त्या होस्ट केल्या जातात साक्षीदार केवळ आभासी मशीनची संख्या आणि जागा वाचवण्यासाठी.

आवृत्त्या

v0. VirtualBox 7 वर CentOS 11 आणि PostgreSQL 6.1 सह कार्य करते.

क्लस्टर रचना

सर्व क्लस्टर्स एका सपाट नेटवर्कमध्ये एकत्रित केलेल्या एकाधिक डेटा सेंटरमध्ये स्थित आहेत आणि एका डेटा सेंटरच्या अपयश किंवा नेटवर्क अलगावचा सामना करणे आवश्यक आहे. म्हणून अशक्य आहे विरुद्ध संरक्षणासाठी वापरा विभाजित मेंदू मानक पेसमेकर तंत्रज्ञान म्हणतात स्टोनिथ (इतर नोड इन द हेड शूट करा) किंवा कुंपण. त्याचे सार: जर क्लस्टरमधील नोड्सला शंका येऊ लागली की काही नोडमध्ये काहीतरी चुकीचे आहे, ते प्रतिसाद देत नाही किंवा चुकीचे वागत आहे, तर ते "बाह्य" डिव्हाइसेसद्वारे जबरदस्तीने ते बंद करतात, उदाहरणार्थ, आयपीएमआय किंवा यूपीएस कंट्रोल कार्ड . परंतु हे केवळ अशा प्रकरणांमध्ये कार्य करेल जेथे, एकल अपयशी झाल्यास, IPMI किंवा UPS सर्व्हर कार्य करणे सुरू ठेवते. येथे आम्ही संपूर्ण डेटा सेंटर अयशस्वी झाल्यास (उदाहरणार्थ, शक्ती गमावल्यास) अधिक आपत्तीजनक अपयशापासून संरक्षण करण्याची योजना आखतो. आणि अशा नकाराने, सर्वकाही स्टोनिथ-डिव्हाइस (IPMI, UPS, इ.) देखील कार्य करणार नाहीत.

त्याऐवजी, प्रणाली कोरमच्या कल्पनेवर आधारित आहे. सर्व नोड्सचा आवाज असतो आणि केवळ तेच काम करू शकतात जे सर्व नोड्सपैकी अर्ध्याहून अधिक पाहू शकतात. "अर्धा + 1" या परिमाणाला म्हणतात कोरम. जर कोरम पूर्ण झाला नाही, तर नोड ठरवतो की तो नेटवर्क अलगावमध्ये आहे आणि त्याची संसाधने बंद करणे आवश्यक आहे, उदा. हे असे आहे स्प्लिट-ब्रेन संरक्षण. या वर्तनासाठी जबाबदार असलेले सॉफ्टवेअर कार्य करत नसल्यास, वॉचडॉग, उदाहरणार्थ, IPMI वर आधारित, कार्य करावे लागेल.

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

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

तुचांका 1 (कॉम्पॅक्शनसह सर्किट)

रचना

कल्पना अशी होती की आमच्याकडे कमी भार असलेले अनेक छोटे डेटाबेस आहेत, ज्यासाठी केवळ वाचनीय व्यवहारांसाठी हॉट स्टँडबाय मोडमध्ये समर्पित स्लेव्ह सर्व्हर राखणे फायदेशीर नाही (संसाधनांचा असा अपव्यय करण्याची आवश्यकता नाही).

प्रत्येक डेटा सेंटरमध्ये एक सर्व्हर असतो. प्रत्येक सर्व्हरमध्ये दोन PostgreSQL उदाहरणे असतात (PostgreSQL शब्दावलीत त्यांना क्लस्टर म्हणतात, परंतु गोंधळ टाळण्यासाठी मी त्यांना उदाहरणे म्हणेन (इतर डेटाबेसशी साधर्म्य करून) आणि मी फक्त Pacemaker क्लस्टर क्लस्टर्स म्हणेन). एक उदाहरण मास्टर मोडमध्ये कार्य करते आणि केवळ ते सेवा प्रदान करते (फक्त फ्लोट आयपी त्याकडे नेतो). दुसरा प्रसंग दुसऱ्या डेटा सेंटरसाठी गुलाम म्हणून काम करतो आणि त्याचा मालक अयशस्वी झाल्यासच सेवा प्रदान करेल. बर्‍याच वेळा दोनपैकी फक्त एकच प्रसंग (मास्टर) सेवा प्रदान करेल (विनंत्या पूर्ण करा), सर्व सर्व्हर संसाधने मास्टरसाठी ऑप्टिमाइझ केली जातात (मेमरी सामायिक_बफर्स ​​कॅशे इ. साठी वाटप केली जाते), परंतु त्यामुळे दुसरी घटना डेटा सेंटरपैकी एक अयशस्वी झाल्यास पुरेशी संसाधने देखील आहेत (जरी फाइल सिस्टम कॅशेद्वारे सबऑप्टिमल ऑपरेशनसाठी). क्लस्टरच्या सामान्य ऑपरेशन दरम्यान स्लेव्ह सेवा प्रदान करत नाही (केवळ वाचन विनंत्या करत नाही), जेणेकरून त्याच मशीनवर मास्टरसह संसाधनांसाठी कोणतेही युद्ध होणार नाही.

दोन नोड्सच्या बाबतीत, दोष सहिष्णुता केवळ असिंक्रोनस प्रतिकृतीसह शक्य आहे, कारण समकालिक प्रतिकृतीसह, गुलाम अपयशी झाल्यामुळे मास्टर थांबेल.

साक्ष देण्यात अयशस्वी

साक्ष देण्यात अयशस्वी (कोरम डिव्हाइस) मी फक्त Tuchanka1 क्लस्टरसाठी विचार करेन, इतर सर्वांसह ती समान कथा असेल. साक्षीदार अयशस्वी झाल्यास, क्लस्टरच्या संरचनेत काहीही बदलणार नाही, सर्व काही त्याच प्रकारे कार्य करत राहील. परंतु कोरम 2 पैकी 3 होईल, आणि म्हणून त्यानंतरचे कोणतेही अपयश क्लस्टरसाठी घातक ठरेल. तरीही ते तातडीने दुरुस्त करावे लागेल.

तुचांका1 नकार

Tuchanka1 साठी डेटा केंद्रांपैकी एक अयशस्वी. या प्रकरणात साक्षीदार दुसऱ्या डेटा सेंटरमध्ये दुसऱ्या नोडला आपले मत देते. तेथे, माजी गुलाम मास्टरमध्ये बदलतो, परिणामी, दोन्ही मास्टर्स एकाच सर्व्हरवर काम करतात आणि त्यांचे दोन्ही फ्लोट आयपी त्यांच्याकडे निर्देश करतात.

तुचांका2 (शास्त्रीय)

रचना

दोन नोड्सची क्लासिक योजना. मालक एकावर काम करतो, गुलाम दुसऱ्यावर. दोघेही विनंत्या अंमलात आणू शकतात (स्लेव्ह फक्त वाचला जातो), त्यामुळे दोन्ही फ्लोट IP द्वारे निर्देशित केले जातात: krogan2 हा मास्टर आहे, krogan2s1 हा गुलाम आहे. मालक आणि गुलाम दोघांनाही दोष सहिष्णुता असेल.

दोन नोड्सच्या बाबतीत, दोष सहिष्णुता केवळ असिंक्रोनस प्रतिकृतीसह शक्य आहे, कारण समकालिक प्रतिकृतीसह, स्लेव्हच्या अपयशामुळे मास्टरचा थांबा होईल.

तुचांका2 नकार

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

तुचांका 4 (अनेक गुलाम)

रचना

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

या योजनेचे आणखी एक वैशिष्ट्य म्हणजे एक समकालिक प्रतिकृती आयोजित करणे आधीच शक्य आहे. मास्टर सारख्या डेटा सेंटरमधील प्रतिकृती बनवण्याऐवजी, शक्य असल्यास, दुसर्‍या डेटा सेंटरमध्ये प्रतिकृती तयार करण्यासाठी हे कॉन्फिगर केले आहे. मास्टर आणि प्रत्येक गुलाम फ्लोट आयपीद्वारे निर्देशित केले जातात. सुदैवाने, गुलामांच्या दरम्यान विनंत्या कसा तरी संतुलित करणे आवश्यक असेल sql प्रॉक्सी, उदाहरणार्थ, क्लायंटच्या बाजूने. वेगवेगळ्या प्रकारच्या क्लायंटला वेगवेगळ्या प्रकारची आवश्यकता असू शकते sql प्रॉक्सी, आणि फक्त क्लायंट डेव्हलपरना माहित आहे की कोणाची गरज आहे. ही कार्यक्षमता बाह्य डिमनद्वारे किंवा क्लायंट लायब्ररी (कनेक्शन पूल) इत्यादीद्वारे लागू केली जाऊ शकते. हे सर्व फेलओव्हर डेटाबेस क्लस्टरच्या विषयाच्या पलीकडे जाते (फेलओव्हर SQL प्रॉक्सी क्लायंटच्या दोष सहिष्णुतेसह स्वतंत्रपणे लागू केले जाऊ शकते).

तुचांका4 नकार

एक डेटा सेंटर (म्हणजे दोन सर्व्हर) अयशस्वी झाल्यास, दुसऱ्यासाठी साक्षीदार मते. परिणामी, दुसऱ्या डेटा सेंटरमध्ये दोन सर्व्हर चालू आहेत: एक मास्टर चालवत आहे, आणि मास्टर फ्लोट आयपी त्याच्याकडे निर्देश करतो (वाचन-लेखन विनंत्या प्राप्त करण्यासाठी); आणि दुस-या सर्व्हरवर समकालिक प्रतिकृतीसह एक स्लेव्ह चालू आहे आणि स्लेव्ह फ्लोट आयपींपैकी एक त्यास सूचित करतो (केवळ-वाचनीय विनंतीसाठी).

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

दुसरा: डेटा सेंटर अयशस्वी झाल्यास, सिंक्रोनस प्रतिकृती राखली जाईल. आणि जरी दुय्यम बिघाड झाला, म्हणजे, उर्वरित डेटा सेंटरमधील दोन सर्व्हरपैकी एक अयशस्वी झाला, तरीही क्लस्टर, जरी ते सेवा प्रदान करणे थांबवेल, तरीही सर्व वचनबद्ध व्यवहारांची माहिती ठेवेल ज्यासाठी त्याने वचनबद्धतेची पुष्टी केली आहे. (दुय्यम अयशस्वी झाल्यास नुकसानीची कोणतीही माहिती नसेल).

Tuchanka3 (3 डेटा केंद्रे)

रचना

हे अशा परिस्थितीसाठी क्लस्टर आहे जेथे तीन पूर्णतः कार्यरत डेटा केंद्रे आहेत, ज्यापैकी प्रत्येकामध्ये पूर्णपणे कार्यरत डेटाबेस सर्व्हर आहे. या प्रकरणात कोरम डिव्हाइस गरज नाही. एका डेटा सेंटरमध्ये मास्टरचे कर्मचारी आहेत, तर इतर दोन गुलामांद्वारे कर्मचारी आहेत. प्रतिकृती सिंक्रोनस आहे, ANY टाइप करा (slave1, slave2), म्हणजेच, जेव्हा कोणत्याही गुलामाने वचन स्वीकारले आहे असा प्रतिसाद देणारा पहिला असेल तेव्हा क्लायंटला कमिट कन्फर्मेशन मिळेल. संसाधने मास्टरसाठी एक फ्लोट आयपी आणि गुलामांसाठी दोन द्वारे दर्शविली जातात. Tuchanka4 च्या विपरीत, तिन्ही फ्लोट IP दोष-सहिष्णु आहेत. फक्त-वाचनीय SQL क्वेरी संतुलित करण्यासाठी तुम्ही वापरू शकता sql प्रॉक्सी (स्वतंत्र दोष सहिष्णुतेसह), किंवा अर्ध्या क्लायंटला एक स्लेव्ह फ्लोट IP द्या आणि दुसरा अर्धा दुसऱ्याला द्या.

तुचांका3 नकार

डेटा सेंटरपैकी एक अयशस्वी झाल्यास, दोन शिल्लक राहतात. एकामध्ये, मास्टरकडून मास्टर आणि फ्लोट आयपी वाढवले ​​जातात, दुसऱ्यामध्ये - स्लेव्ह आणि दोन्ही स्लेव्ह फ्लोट आयपी (दोन्ही स्लेव्ह फ्लोट आयपी मधील सर्व कनेक्शन स्वीकारण्यासाठी उदाहरणामध्ये दुप्पट संसाधने असणे आवश्यक आहे). स्वामी आणि गुलाम यांच्यातील समकालिक प्रतिकृती. तसेच, क्लस्टर दोन डेटा सेंटर्स नष्ट झाल्यास (जर ते एकाच वेळी नष्ट न झाल्यास) वचनबद्ध आणि पुष्टी केलेल्या व्यवहारांबद्दलची माहिती जतन करेल (माहितीची कोणतीही हानी होणार नाही).

मी फाइल संरचना आणि उपयोजनाचे तपशीलवार वर्णन समाविष्ट न करण्याचा निर्णय घेतला. ज्याला आजूबाजूला खेळायचे आहे ते सर्व README मध्ये वाचू शकतात. मी फक्त स्वयंचलित चाचणीचे वर्णन देत आहे.

स्वयंचलित चाचणी प्रणाली

विविध दोषांचे अनुकरण करून क्लस्टर्सच्या दोष सहिष्णुतेची चाचणी घेण्यासाठी, एक स्वयंचलित चाचणी प्रणाली तयार केली गेली आहे. स्क्रिप्टद्वारे लाँच केले test/failure. स्क्रिप्ट आपण चाचणी करू इच्छित असलेल्या क्लस्टर्सची संख्या पॅरामीटर्स म्हणून घेऊ शकते. उदाहरणार्थ ही आज्ञा:

test/failure 2 3

फक्त दुसऱ्या आणि तिसऱ्या क्लस्टरची चाचणी करेल. पॅरामीटर्स निर्दिष्ट न केल्यास, सर्व क्लस्टर्सची चाचणी केली जाईल. सर्व क्लस्टर्सची समांतर चाचणी केली जाते आणि परिणाम tmux पॅनेलमध्ये प्रदर्शित केला जातो. Tmux एक समर्पित tmux सर्व्हर वापरते, त्यामुळे स्क्रिप्ट डीफॉल्ट tmux अंतर्गत चालविली जाऊ शकते, परिणामी tmux नेस्टेड होते. मी मोठ्या विंडोमध्ये आणि लहान फॉन्टसह टर्मिनल वापरण्याची शिफारस करतो. चाचणी सुरू होण्यापूर्वी, स्क्रिप्ट पूर्ण झाल्यावर सर्व व्हर्च्युअल मशीन स्नॅपशॉटवर परत आणल्या जातात setup.

चाचणी केलेल्या क्लस्टरच्या संख्येनुसार टर्मिनल स्तंभांमध्ये विभागले गेले आहे; डीफॉल्टनुसार (स्क्रीनशॉटमध्ये) चार आहेत. मी Tuchanka2 चे उदाहरण वापरून स्तंभांच्या सामग्रीचे वर्णन करेन. स्क्रीनशॉटमधील पॅनेल क्रमांकित आहेत:

1. चाचणी आकडेवारी येथे प्रदर्शित केली आहे. स्तंभ:
   • अपयश — चाचणीचे नाव (स्क्रिप्टमधील कार्य) जे दोषाचे अनुकरण करते.
   • प्रतिक्रिया — सेकंदांमध्ये अंकगणित सरासरी वेळ ज्या दरम्यान क्लस्टरने त्याची कार्यक्षमता पुनर्प्राप्त केली. स्क्रिप्टच्या सुरुवातीपासून ते क्लस्टर त्याची कार्यक्षमता पुनर्संचयित करेपर्यंत आणि सेवा प्रदान करणे सुरू ठेवण्यास सक्षम होईपर्यंत फॉल्टचे अनुकरण करत मोजले जाते. जर वेळ फारच कमी असेल, उदाहरणार्थ, सहा सेकंद (हे अनेक गुलामांसह क्लस्टर्समध्ये घडते (तुचांका 3 आणि तुचांका 4)), याचा अर्थ असा की दोष असिंक्रोनस स्लेव्हवर होता आणि त्याचा कोणत्याही प्रकारे कामगिरीवर परिणाम झाला नाही; क्लस्टर स्टेट स्विचेस.
   • विचलन — मूल्याचा प्रसार (अचूकता) दाखवते प्रतिक्रिया मानक विचलन पद्धत वापरणे.
   • गणना - ही चाचणी किती वेळा केली गेली.
2. एक लहान लॉग तुम्हाला क्लस्टर सध्या काय करत आहे याचे मूल्यांकन करण्याची परवानगी देतो. पुनरावृत्ती (चाचणी) क्रमांक, टाइमस्टॅम्प आणि ऑपरेशनचे नाव प्रदर्शित केले जाते. खूप लांब धावणे (> 5 मिनिटे) समस्या दर्शवते.
3. हृदय (हृदय) - वर्तमान वेळ. कामगिरीच्या व्हिज्युअल मूल्यांकनासाठी मास्टर्स फ्लोट आयपी मास्टर वापरून वर्तमान वेळ त्याच्या टेबलवर सतत लिहिली जाते. यशस्वी झाल्यास, निकाल या पॅनेलमध्ये प्रदर्शित केला जाईल.
4. विजय (नाडी) - "वर्तमान वेळ", जी पूर्वी स्क्रिप्टद्वारे रेकॉर्ड केली गेली होती हृदय मास्टर करण्यासाठी, आता पासून वाचा गुलाम त्याच्या फ्लोट आयपी द्वारे. आपल्याला स्लेव्ह आणि प्रतिकृतीच्या कार्यप्रदर्शनाचे दृश्यमानपणे मूल्यांकन करण्यास अनुमती देते. तुचांका1 मध्ये फ्लोट आयपी असलेले कोणतेही गुलाम नाहीत (सेवा देणारे गुलाम नाहीत), परंतु दोन उदाहरणे (डीबी) आहेत, म्हणून ती येथे दर्शविली जाणार नाहीत. विजयआणि हृदय दुसरा प्रसंग.
5. युटिलिटी वापरून क्लस्टर आरोग्याचे निरीक्षण करणे pcs mon. रचना, नोड्समध्ये संसाधनांचे वितरण आणि इतर उपयुक्त माहिती दाखवते.
6. क्लस्टरमधील प्रत्येक व्हर्च्युअल मशीनवरील सिस्टम मॉनिटरिंग येथे प्रदर्शित केले आहे. क्लस्टरमध्ये किती व्हर्च्युअल मशीन आहेत यावर अवलंबून असे आणखी पॅनेल असू शकतात. दोन आलेख CPU लोड (व्हर्च्युअल मशीनमध्ये दोन प्रोसेसर असतात), आभासी मशीनचे नाव, सिस्टम लोड (लोड सरासरी नाव दिले कारण ते सरासरी 5, 10 आणि 15 मिनिटांपेक्षा जास्त आहे), प्रक्रिया डेटा आणि मेमरी वाटप.
7. चाचणी करत असलेल्या स्क्रिप्टचा ट्रेस. खराबी झाल्यास - ऑपरेशनमध्ये अचानक व्यत्यय किंवा अंतहीन प्रतीक्षा चक्र - येथे आपण या वर्तनाचे कारण पाहू शकता.

चाचणी दोन टप्प्यात केली जाते. प्रथम, स्क्रिप्ट सर्व प्रकारच्या चाचण्यांमधून जाते, यादृच्छिकपणे एक आभासी मशीन निवडते ज्यावर ही चाचणी लागू करावी. नंतर चाचणीचे अंतहीन चक्र केले जाते, आभासी मशीन आणि दोष प्रत्येक वेळी यादृच्छिकपणे निवडले जातात. चाचणी स्क्रिप्ट अचानक संपुष्टात येणे (तळाशी पॅनेल) किंवा एखाद्या गोष्टीची प्रतीक्षा करण्याचा अंतहीन लूप (> एका ऑपरेशनसाठी 5 मिनिटे अंमलबजावणीची वेळ, हे ट्रेसमध्ये पाहिले जाऊ शकते) सूचित करते की या क्लस्टरवरील काही चाचण्या अयशस्वी झाल्या आहेत.

प्रत्येक चाचणीमध्ये खालील ऑपरेशन्स असतात:

1. फॉल्टचे अनुकरण करणारे फंक्शन लाँच करा.
2. तयार? — क्लस्टर पुनर्संचयित होण्याची प्रतीक्षा करत आहे (जेव्हा सर्व सेवा प्रदान केल्या जातात).
3. क्लस्टर रिकव्हरी टाइमआउट दाखवते (प्रतिक्रिया).
4. निराकरण - क्लस्टरची "दुरुस्ती" केली जात आहे. त्यानंतर ते पूर्णपणे कार्यरत स्थितीत परत यावे आणि पुढील खराबीसाठी तयार असावे.

ते काय करतात याचे वर्णन असलेल्या चाचण्यांची यादी येथे आहे:

• फोर्कबॉम्ब: फोर्क बॉम्ब वापरून "आऊट ऑफ मेमरी" तयार करते.
• आउटऑफस्पेस: हार्ड ड्राइव्ह भरली आहे. परंतु चाचणी त्याऐवजी प्रतिकात्मक आहे; चाचणी दरम्यान तयार केलेल्या क्षुल्लक लोडसह, हार्ड ड्राइव्ह पूर्ण भरल्यावर पोस्टग्रेएसक्यूएल सहसा अयशस्वी होत नाही.
• पोस्टग्रेस-किल: कमांडसह 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... चेकसाठी कोरोसिंक यापूर्वीच PR#१६९८४१ (गीटहब वर येथे sbd), धाग्यावर स्वीकारले मास्टर. त्यांनी वचन दिले (PR#83 मध्ये) पेसमेकरसाठी असेच काहीतरी असेल, मला आशा आहे की रेडहॅट 8 करेल. परंतु अशा "दोष" सट्टा आहेत आणि कृत्रिमरित्या वापरून सहजपणे अनुकरण केले जाऊ शकतात, उदाहरणार्थ, killall -STOP corosyncपण प्रत्यक्ष आयुष्यात कधीच भेटत नाही.

• У पेसमेकर साठी आवृत्तीमध्ये CentOS 7 चुकीचे सेट केले आहे sync_timeout у कोरम डिव्हाइस, एक परिणाम म्हणून एक नोड अयशस्वी झाल्यास, काही संभाव्यतेसह दुसरा नोड देखील रीबूट होईल, ज्याकडे मास्टरला जायचे होते. विस्ताराने बरा होतो sync_timeout у कोरम डिव्हाइस तैनाती दरम्यान (स्क्रिप्टमध्ये setup/setup1). ही दुरुस्ती विकासकांनी स्वीकारली नाही पेसमेकर, त्याऐवजी त्यांनी पायाभूत सुविधांची अशा प्रकारे पुनर्रचना करण्याचे वचन दिले (काही अनिर्दिष्ट भविष्यात) की ही कालबाह्यता स्वयंचलितपणे मोजली जाईल.

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

• जर wal_receiver_timeout सेट केले असेल (डीफॉल्टनुसार ते 60 चे आहे), तर tuchanka3 आणि tuchanka4 क्लस्टरमधील मास्टरवर PostgreSQL-STOP चाचणी दरम्यान प्रतिकृती नवीन मास्टरशी पुन्हा कनेक्ट होत नाही. तेथे प्रतिकृती सिंक्रोनस आहे, म्हणून केवळ गुलामच थांबत नाही तर नवीन मास्टर देखील. PostgreSQL कॉन्फिगर करताना wal_receiver_timeout=0 सेट करून कार्य करते.

• अधूनमधून मी फोर्कबॉम्ब चाचणी (मेमरी ओव्हरफ्लो) मध्ये PostgreSQL मध्ये प्रतिकृती फ्रीझ झाल्याचे निरीक्षण केले. ForkBomb नंतर, काहीवेळा गुलाम नवीन मास्टरशी पुन्हा कनेक्ट होऊ शकत नाहीत. मला हे फक्त tuchanka3 आणि tuchanka4 क्लस्टरमध्ये आढळले आहे, जेथे सिंक्रोनस प्रतिकृतीमुळे मास्टर गोठला आहे. बर्याच काळानंतर (सुमारे दोन तास) समस्या स्वतःच निघून गेली. हे दुरुस्त करण्यासाठी अधिक संशोधन आवश्यक आहे. लक्षणे मागील बग सारखीच आहेत, जी वेगळ्या कारणामुळे झाली आहे, परंतु त्याच परिणामांसह.

क्रोगन चित्र काढले Deviant कला लेखकाच्या परवानगीने:

स्त्रोत: www.habr.com