🕺🏽 👩🏿‍💼 🤲🏾 "किसी भी कीमत पर जीवित रहें" मोड में खरगोश (खरगोश का बच्चा) का ऑपरेशन 🙃 🐤 🤚🏼

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

टेलिकॉम की वास्तविकताओं में परिवहन का कार्य क्या है?

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

दूरसंचार में परिवहन की विशेषताएं: बड़े, कोई गलत नहीं, अतुल्यकालिक परिवहन के माध्यम से प्रेषित विविध डेटा की बड़ी धारा।

कुछ सबसिस्टम संदेश प्रवाह की भारीता के कारण अलग-अलग क्लस्टर पर रहते हैं - क्लस्टर पर बस कोई संसाधन नहीं बचे हैं, उदाहरण के लिए, 5-6 हजार संदेशों / सेकंड के संदेश प्रवाह के साथ, स्थानांतरित किए गए डेटा की मात्रा 170-190 मेगाबाइट्स / सेकंड तक पहुंच सकती है। इस तरह के लोड प्रोफाइल के साथ, इस क्लस्टर पर किसी और को भी उतारने की कोशिश से दुःखद परिणाम सामने आएंगे: चूँकि सभी डेटा को एक ही समय में संसाधित करने के लिए पर्याप्त संसाधन नहीं हैं, खरगोश आने वाले कनेक्शनों को प्रवाह में लाना शुरू कर देगा - एक साधारण प्रकाशन प्रक्रिया शुरू हो जाएगी, जिसमें सभी सबसिस्टम और सिस्टम के लिए सभी परिणाम होंगे। पूरे।

परिवहन के लिए बुनियादी आवश्यकताएं:

वाहनों की पहुंच 99.99% होनी चाहिए। व्यवहार में, यह 24/7 परिचालन आवश्यकता और किसी भी आपातकालीन स्थितियों में स्वचालित रूप से प्रतिक्रिया करने की क्षमता में तब्दील हो जाता है।
डेटा सुरक्षा: परिवहन पर खोए हुए संदेशों का% 0 तक होना चाहिए।

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

सबस्क्राइबर के कार्यों के कारण होने वाली घटनाओं के अलावा, सबसिस्टम का आदान-प्रदान करने वाले सेवा संदेश परिवहन के माध्यम से जाते हैं। इस प्रकार, कई हजार विभिन्न संदेश मार्ग प्राप्त होते हैं, कुछ प्रतिच्छेद, कुछ अलगाव में मौजूद होते हैं। यह परिवहन मानचित्र के अनुमानित पैमाने को समझने के लिए विभिन्न कंट्रोल्स पर मार्गों में शामिल कतारों की संख्या को नाम देने के लिए पर्याप्त है: केंद्रीय सर्किट 600, 200, 260, 15 पर ... और दूरस्थ सर्किट 80-100 पर ...

परिवहन की ऐसी भागीदारी के साथ, सभी परिवहन नोड्स की 100% पहुंच की आवश्यकताएं अब अत्यधिक नहीं लगती हैं। हम इन आवश्यकताओं के कार्यान्वयन के लिए आगे बढ़ रहे हैं।

हम कार्यों को कैसे हल करते हैं

RabbitMQ के अलावा, हाप्रोक्सी का उपयोग लोड को संतुलित करने और आपात स्थितियों के लिए एक स्वचालित प्रतिक्रिया प्रदान करने के लिए किया जाता है।

हार्डवेयर और सॉफ्टवेयर वातावरण के बारे में कुछ शब्द जिसमें हमारे खरगोश मौजूद हैं:

सभी खरगोश सर्वर वर्चुअल हैं, जिनमें 8-12 सीपीयू, 16 जीबी मेम, 200 जीबी एचडीडी के पैरामीटर हैं। जैसा कि अनुभव से पता चला है, यहां तक कि 90 कोर के साथ खौफनाक गैर-आभासी सर्वर का उपयोग और रैम का एक गुच्छा काफी उच्च लागत पर एक छोटे से प्रदर्शन को बढ़ावा देता है। प्रयुक्त संस्करण: २.६.६ (व्यवहार में - ३.६ का सबसे स्थिर) १ 3.6.३ के प्रस्फुटन के साथ, २०.१ के एरांग के साथ ३.६.६
हाप्रोक्सी के लिए, आवश्यकताएँ बहुत कम हैं: 2 सीपीयू, 4 जीबी मेम, हैप्रोक्सी संस्करण 1.8 स्थिर है। सभी हैप्रोक्सी सर्वर पर संसाधनों का भार 15% सीपीयू / मेम से अधिक नहीं है।
संपूर्ण चिड़ियाघर देश भर में 7 साइटों पर 14 डेटा केंद्रों में स्थित है, जो एकल नेटवर्क में एकजुट हैं। प्रत्येक डेटा सेंटर में तीन नोड और एक हब का एक क्लस्टर होता है।
रिमोट सर्किट के लिए, 2 डेटा सेंटर का उपयोग किया जाता है, प्रत्येक केंद्रीय सर्किट के लिए - 4।
सेंट्रल सर्किट्स एक-दूसरे के साथ-साथ रिमोट सर्किट्स के साथ बातचीत करते हैं; बदले में, रिमोट सर्किट केवल सेंट्रल सर्किट्स के साथ काम करते हैं; उनका एक-दूसरे के साथ सीधा संवाद नहीं होता है।
एक ही सर्किट के भीतर अंतराल और समूहों के विन्यास पूरी तरह से समान हैं। प्रत्येक सर्किट के लिए प्रवेश बिंदु कई ए-डीएनएस रिकॉर्ड के लिए एक उपनाम है। इस प्रकार, ऐसा होने से रोकने के लिए, प्रत्येक सर्किट में कम से कम एक एचपी और कम से कम क्लस्टर्स (क्लस्टर में कम से कम एक नोड) उपलब्ध होगा। चूंकि एक ही समय में दो डेटा केंद्रों में 6 सर्वरों की विफलता का मामला बेहद असंभावित है, इसलिए स्वीकार्यता को 100% के करीब माना जाता है।

यह सब इस तरह से कल्पना (और कार्यान्वित) करता है:

अब कुछ विन्यास।

हाप्रोसी विन्यास

फ्रंटेंड सेंटर-rmq_5672
	बाँध	*: 5672
	मोड	टीसीपी
	maxconn	10000
	टाइमआउट क्लाइंट	3 ज
	विकल्प	tcpka
	विकल्प	tcplog
	default_backend	केंद्र-rmq_5672
फ्रंटएंड सेंटर-rmq_5672_lvl_1
	बाँध	लोकलहोस्ट: 56721
	मोड	टीसीपी
	maxconn	10000
	टाइमआउट क्लाइंट	3 ज
	विकल्प	tcpka
	विकल्प	tcplog
	default_backend	केंद्र-rmq_5672_lvl_1
बैकएंड सेंटर- rmq_5672
	संतुलन	leastconn
	मोड	टीसीपी
	fullconn	10000
	मध्यांतर	सर्वर 3 ह
	सर्वर	srv-rmq01 10/10/10/106767 चेक 5s वृद्धि 2 गिरावट 3 पर चिह्नित-अप शटडाउन-बैकअप सत्र
	सर्वर	srv-rmq03 10/10/10/2011 11672 चेक 5s वृद्धि 2 गिरावट 3 पर चिह्नित-अप शटडाउन-बैकअप सत्र
	सर्वर	srv-rmq05 10/10/10/126767 चेक 5s वृद्धि 2 गिरावट 3 पर चिह्नित-अप शटडाउन-बैकअप सत्र
	सर्वर	लोकलहोस्ट 127.0.0.1 ∗ 6721 चेक इंटर 5 एस 2 फॉल 3 बैकअप ऑन-मार्क-डाउन शटडाउन-सेशन
backend Center-rmq_5672_lvl_1
	संतुलन	leastconn
	मोड	टीसीपी
	fullconn	10000
	मध्यांतर	सर्वर 3 ह
	सर्वर	srv-rmq02 10/10/10/136767 चेक 5s वृद्धि 2 गिरावट 3 पर चिह्नित बंद-बैकअप-सत्र
	सर्वर	srv-rmq04 10/10/10/14/1067 चेक 5s वृद्धि 2 गिरावट 3 पर चिह्नित-अप शटडाउन-बैकअप सत्र
	सर्वर	srv-rmq06 10.10.10.5:0767 चेक 5s वृद्धि 2 गिरावट 3 पर चिह्नित-अप शटडाउन-बैकअप सत्र

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

उपरोक्त उदाहरण दूरस्थ लूप के संतुलन का वर्णन करता है - जो दो डेटा केंद्रों के भीतर संचालित होता है: srv-rmq सर्वर {01,03,05} - डेटा सेंटर नंबर 1 में रहते हैं, srv-rmq {02,04,050} - डेटा सेंटर नंबर 2 में। इस प्रकार, चार-कोडा समाधान को लागू करने के लिए, हमें केवल दो स्थानीय मोर्चों और संबंधित रबी सर्वरों के दो बैकेंड अनुभागों को जोड़ना होगा।

इस कॉन्फ़िगरेशन के साथ बैलेंसर का व्यवहार निम्नानुसार है: जबकि कम से कम एक मुख्य सर्वर जीवित है, हम इसका उपयोग करते हैं। यदि मुख्य सर्वर अनुपलब्ध हैं, तो हम एक रिज़र्व के साथ काम करते हैं। यदि कम से कम एक प्राथमिक सर्वर उपलब्ध हो जाता है, तो बैकअप सर्वर के सभी कनेक्शन काट दिए जाते हैं और, जब कनेक्शन बहाल हो जाता है, तो वे पहले से ही प्राथमिक क्लस्टर पर आते हैं।

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

इसलिए, हमने एक क्लस्टर की एक मनमानी संख्या को लोड संतुलन प्रदान किया है और स्वचालित रूप से उनके बीच स्विच करते हैं, यह सीधे खरगोशों पर जाने का समय है।

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

पूर्व शर्त के अनुसार, निम्नलिखित जो सबसिस्टम की ओर से सबसे स्थिर संचालन और प्राप्त संदेशों को बचाने के लिए आवश्यकता की पूर्ति सुनिश्चित करेगा:

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

अब सीधे खरगोशों पर सेटिंग्स:

स्थानीय होस्ट के पास वेब इंटरफ़ेस तक पहुंच नहीं है
वेब तक पहुंच LDAP के माध्यम से आयोजित की जाती है - हम AD के साथ एकीकृत करते हैं और लॉगिंग प्राप्त करते हैं कि कौन और कहां वेबकैम पर गया। कॉन्फ़िगरेशन स्तर पर, हम AD खातों के अधिकारों को प्रतिबंधित करते हैं, न केवल हमें एक निश्चित समूह में होने की आवश्यकता होती है, बल्कि हम केवल "" "" अधिकार देते हैं। निगरानी समूह पर्याप्त से अधिक हैं। और हम AD में किसी अन्य समूह पर व्यवस्थापक अधिकार लटकाते हैं, इस प्रकार परिवहन पर प्रभाव का चक्र बहुत सीमित है।
प्रशासन और ट्रैकिंग की सुविधा के लिए:
सभी VHOST पर, हम तुरंत सभी कतारों (पैटर्न: *) के लिए आवेदन के साथ स्तर 0 की नीति को लटका देते हैं:।
- हा-मोड: सभी - सभी डेटा को क्लस्टर के सभी नोड्स पर संग्रहीत करते हैं, संदेशों की प्रसंस्करण गति कम हो जाती है, लेकिन उनकी सुरक्षा और उपलब्धता सुनिश्चित की जाती है।
- हा-सिंक-मोड: स्वचालित - क्रॉलर को क्लस्टर के सभी नोड्स पर डेटा को स्वचालित रूप से सिंक्रनाइज़ करने का निर्देश देता है: डेटा की सुरक्षा और उपलब्धता भी बढ़ जाती है।
- कतार-मोड: आलसी - शायद सबसे उपयोगी विकल्पों में से एक है जो संस्करण 3.6 के बाद से खरगोशों में दिखाई दिया है - एचडीडी पर संदेशों की तत्काल रिकॉर्डिंग। यह विकल्प नाटकीय रूप से रैम की खपत को कम करता है और नोड्स या क्लस्टर के पूरे गिरने के दौरान डेटा की सुरक्षा को बढ़ाता है।
कॉन्फ़िगरेशन फ़ाइल में सेटिंग्स ( rabbitmq-main / conf / rabbitmq.config ):
- धारा खरगोश : {vm_memory_high_watermark_paging_ratio, 0.5} - संदेशों को डिस्क पर डाउनलोड करने के लिए सीमा 50%। आलसी चालू होने पर, यह एक पॉलिसी बनाते समय बीमा के रूप में अधिक कार्य करता है, उदाहरण के लिए, स्तर 1, जिसमें हम आलसी को शामिल करना भूल जाते हैं।
- {vm_memory_high_watermark, 0.95} - हम खरगोश को कुल रैम के 95% तक सीमित करते हैं, चूंकि केवल खरगोश सर्वरों पर रहता है, इसलिए अधिक कठोर प्रतिबंधों को लागू करने का कोई मतलब नहीं है। 5% "व्यापक इशारा" तो यह हो - ओएस, निगरानी और अन्य उपयोगी छोटी चीजों को छोड़ दें। चूंकि यह मान ऊपरी सीमा है, इसलिए सभी के लिए पर्याप्त है।
- {cla_partition_handling, pause_minority} - नेटवर्क विभाजन होने पर क्लस्टर के व्यवहार का वर्णन करता है, तीन या अधिक नोड क्लस्टर के लिए इस ध्वज की सिफारिश की जाती है - यह क्लस्टर को स्वयं पुनर्प्राप्त करने की अनुमति देता है।
- {disk_free_limit, "500MB"} - सब कुछ सरल है, जब 500 MB मुक्त डिस्क स्थान है - संदेश प्रकाशन बंद हो जाएगा, केवल घटाव उपलब्ध होगा।
- {schem_backends, [rabbit_auth_backend_internal, rabbit_auth_backend_ldap]} - खरगोशों के लिए प्राधिकरण आदेश: सबसे पहले, स्थानीय डेटाबेस में एक अल्ट्रासाउंड की उपस्थिति की जाँच की जाती है, और यदि नहीं, तो LDAP सर्वर पर जाएं।
- धारा rabbitmq_auth_backend_ldap - AD के साथ सहभागिता का कॉन्फ़िगरेशन: {सर्वर, ["srv_dc1", "srv_dc2"]} - डोमेन नियंत्रकों की एक सूची, जिस पर प्रमाणीकरण होगा।
- वे मानदंड जो उपयोगकर्ता को सीधे AD, LDAP पोर्ट इत्यादि में वर्णित करते हैं और विशुद्ध रूप से व्यक्तिगत होते हैं और प्रलेखन में विस्तार से वर्णित हैं।
- हमारे लिए सबसे महत्वपूर्ण बात प्रशासन और खरगोशों के वेब इंटरफेस तक पहुंच के अधिकारों और प्रतिबंधों का विवरण है: tag_queries:
  [{व्यवस्थापक, {in_group, "cn = rabbitmq-admins, ou = GRP, ou = GRP_MAIN, dc = My_domain, dc = ru"}},
  {निगरानी,
  {in_group, "cn = rabbitmq-web, ou = GRP, ou = GRP_MAIN, dc = My_domain, dc = ru"}
  }] - यह डिज़ाइन rabbitmq-web ग्रुप के लिए rabbitmq-admins group और निगरानी अधिकार (एक्सेस देखने के लिए न्यूनतम पर्याप्त) के सभी उपयोगकर्ताओं के लिए प्रशासनिक विशेषाधिकार प्रदान करता है।
- resource_access_query :
  {के लिए,
  [{अनुमति, कॉन्फ़िगर करें, {in_group, "cn = rabbitmq-admins, ou = GRP, ou = GRP_MAIN, dc = My_domain, dc = ru"}}
  {अनुमति, लिखें, {in_group, "cn = rabbitmq-admins, ou = GRP, ou = GRP_MAIN, dc = My_domain, dc = ru"}},
  {अनुमति, पढ़ें, {निरंतर, सत्य}}
  ]
  } - हम केवल व्यवस्थापकों के समूह को कॉन्फ़िगर करने और लिखने का अधिकार प्रदान करते हैं, बाकी सभी जो सफलतापूर्वक लॉग इन करते हैं, अधिकार केवल पढ़ने के लिए हैं - यह वेब इंटरफ़ेस के माध्यम से संदेश पढ़ सकते हैं।

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

ऐसे कई बिंदु हैं जिन पर विचार किया जाना चाहिए जब इस तरह के अत्यधिक लोड किए गए सिस्टम का संचालन किया जाता है:

राजनेताओं द्वारा कतारों को बनाते समय फांसी के मापदंडों के बजाए, सभी अतिरिक्त गुणों (टीटीएल, एक्सपायर, अधिकतम लंबाई, आदि) को व्यवस्थित करना बेहतर होता है। यह एक लचीली अनुकूलन योग्य संरचना को बदल देता है जिसे वास्तविकताओं को बदलने के लिए मक्खी पर अनुकूलित किया जा सकता है।
टीटीएल का उपयोग करना। सीपीयू पर लोड जितना अधिक होगा, उतनी लंबी कतार होगी। "छत के माध्यम से तोड़ने" को रोकने के लिए कतार की लंबाई को अधिकतम लंबाई के साथ-साथ सीमित करना बेहतर है।
खरगोश के अलावा, कई उपयोगिता एप्लिकेशन सर्वर पर कताई कर रहे हैं, जो अजीब तरह से पर्याप्त हैं, इसके लिए सीपीयू संसाधनों की भी आवश्यकता होती है। एक चमकदार खरगोश, डिफ़ॉल्ट रूप से, सभी उपलब्ध गुठली लेता है ... एक अप्रिय स्थिति हो सकती है: संसाधनों के लिए एक संघर्ष, जो आसानी से खरगोश पर ब्रेक लगा सकता है। ऐसी स्थिति की घटना से बचने के लिए, उदाहरण के लिए, निम्नानुसार: एर्गैंग के लॉन्च के मापदंडों को बदलें - उपयोग किए गए कोर की संख्या पर एक अनिवार्य सीमा का परिचय दें। हम इसे इस प्रकार करते हैं: फ़ाइल rabbitmq-env ढूंढें , SERVER_ERL_ARGS = पैरामीटर देखें और उसमें + sct L0-Xc0-X + SY: Y जोड़ें। जहाँ X, कोर -1 की संख्या है (गिनती 0 से शुरू होती है), Y - कोर की संख्या -1 (1 से गिनती)। + sct L0-Xc0-X - कर्नेल के लिए बाइंडिंग को बदल देता है, + SY: Y - एर्गैंग द्वारा लॉन्च किए गए शेड्यूलर्स की संख्या में परिवर्तन करता है। तो 8 कोर की एक प्रणाली के लिए, अतिरिक्त पैरामीटर फॉर्म लेंगे: + sct L0-6c0-6 + S 7: 7। इस तरह, हम खरगोश को केवल 7 कोर देते हैं और उम्मीद करते हैं कि ओएस अन्य प्रक्रियाओं को लॉन्च करके, बेहतर तरीके से कार्य करेगा और उन्हें एक अनलोड किए गए कर्नेल पर लटका देगा।

परिणामस्वरूप चिड़ियाघर के संचालन की बारीकियां

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

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

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

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

और अब यह एक अस्पष्ट संकेत है - बैकअप क्लस्टर पर स्विच करें। स्विचिंग एक झोंपड़ी प्रदान करेगा, आपको बस मुख्य क्लस्टर पर खरगोशों को रोकने की जरूरत है - कई मिनट की बात। नतीजतन, हम परिवहन की कार्य क्षमता की बहाली प्राप्त करते हैं और सुरक्षित रूप से दुर्घटना और इसके उन्मूलन के विश्लेषण के लिए आगे बढ़ सकते हैं।

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

हम इसे कुछ चरणों में करते हैं:

विफल क्लस्टर के सभी नोड्स को रोकें - hap बैकअप क्लस्टर में लोड को स्विच करेगा
RABBITMQ_NODE_PORT=5673 rabbitmq-env – , Web - 15672.
.

. , , – msg_store_persistent , msg_store_transient , queues ( 3.6) msg_stores ( 3.7).

, .

( ): , .

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

लिपियों में cpio और रास्तों के साथ शर्मिंदगी के परिणामस्वरूप, हमें एक बिल्ड विकल्प मिला: दो खरगोश-बेस फ़ोल्डर (मूल असेंबली में - मानेसिया फ़ोल्डर) और रब्बिमक-मुख्य - यहां मैंने खरगोश के सभी आवश्यक स्क्रिप्ट रखे और खुद को मिटा दिया।

Rabbimq-main / bin में - खरगोश और एरांग स्क्रिप्ट के लिए सहानुभूति और एक खरगोश ट्रैकिंग स्क्रिप्ट (नीचे विवरण)।

Rabbimq-main / init.d में - rabbitmq-server स्क्रिप्ट जिसके माध्यम से लॉग शुरू / बंद / घूमता है; वास्तव में, खरगोश ही; in lib64 - erlang (केवल स्ट्रिप-डाउन का उपयोग करके, खरगोश के लिए, erlang का संस्करण)।

जब नए संस्करण जारी किए जाते हैं तो परिणामी असेंबली को अपडेट करना बेहद आसान है - नए संस्करणों से रबीमैक-मेन / लिब और रब्बिमक-मेन / लिब64 की सामग्री जोड़ें और बिन में सिम्लिंक्स को बदलें। यदि अद्यतन नियंत्रण स्क्रिप्ट को भी प्रभावित करता है - तो बस उनमें हमारे लिए पथ बदलें।

इस दृष्टिकोण का एक महत्वपूर्ण लाभ संस्करणों की पूर्ण निरंतरता है - सभी पथ, स्क्रिप्ट, नियंत्रण आदेश अपरिवर्तित रहते हैं, जो आपको प्रत्येक संस्करण के लिए डोपिंग के बिना किसी भी स्व-लिखित उपयोगिता स्क्रिप्ट का उपयोग करने की अनुमति देता है।

, , — ( ). 99% , kill , .

3.6 3.7 .

3.6

#!/usr/bin/python import subprocess import os import datetime import zipfile def LastRow(fileName,MAX_ROW=200): with open(fileName,'rb') as f: f.seek(-min(os.path.getsize(fileName),MAX_ROW),2) return (f.read().splitlines())[-1] if os.path.isfile('/data/logs/rabbitmq/startup_log'): if b'FAILED' in LastRow('/data/logs/rabbitmq/startup_log'): proc = subprocess.Popen("ps x|grep rabbitmq-server|grep -v 'grep'", shell=True, stdout=subprocess.PIPE) out = proc.stdout.readlines() if str(out) == '[]': cur_dt=datetime.datetime.now() try: os.stat('/data/logs/rabbitmq/after_crush') except: os.mkdir('/data/logs/rabbitmq/after_crush') z=zipfile.ZipFile('/data/logs/rabbitmq/after_crush/repair_log'+'-'+str(cur_dt.day).zfill(2)+str(cur_dt.month).zfill(2)+str(cur_dt.year)+'_'+str(cur_dt.hour).zfill(2)+'-'+str(cur_dt.minute).zfill(2)+'-'+str(cur_dt.second).zfill(2)+'.zip','a') z.write('/data/logs/rabbitmq/startup_err','startup_err') proc = subprocess.Popen("~/rabbitmq-main/init.d/rabbitmq-server start", shell=True, stdout=subprocess.PIPE) out = proc.stdout.readlines() z.writestr('res_restart.log',str(out)) z.close() my_file = open("/data/logs/rabbitmq/run.time", "a") my_file.write(str(cur_dt)+"\n") my_file.close()

3.7 के लिए, केवल दो पंक्तियों को बदल दिया जाता है

 if (os.path.isfile('/data/logs/rabbitmq/startup_log')) and (os.path.isfile('/data/logs/rabbitmq/startup_err')): if ((b' OK ' in LastRow('/data/logs/rabbitmq/startup_log')) or (b'FAILED' in LastRow('/data/logs/rabbitmq/startup_log'))) and not (b'Gracefully halting Erlang VM' in LastRow('/data/logs/rabbitmq/startup_err')):

हम एक क्रैस्टैब खाता सेट करते हैं जिसके तहत खरगोश इस स्क्रिप्ट को निष्पादित करते हुए (डिफ़ॉल्ट रूप से खरगोश का काम करेगा) (स्क्रिप्ट नाम: check_and_run) हर मिनट (पहले, हम खाते को सिलेब का उपयोग करने का अधिकार देने के लिए कहते हैं, लेकिन अगर हमारे पास जड़ अधिकार हैं, तो हम इसे स्वयं करते हैं):
* / 1 * * * * ~ / rabbitmq-main / bin / check_and_run

आश्वस्त खरगोश का उपयोग करने का दूसरा बिंदु लॉग का रोटेशन है।

चूँकि हम लोगो सिस्टम से बंधे नहीं हैं, इसलिए हम डेवलपर द्वारा प्रदान की गई कार्यक्षमता का उपयोग करते हैं: init.d से खरगोशबिट-सर्वर स्क्रिप्ट (संस्करण 3.6 के लिए)
रोटेट_लॉग्स_ब्रबिटम () में छोटे बदलाव करके
जोड़ना:

  find ${RABBITMQ_LOG_BASE}/http_api/*.log.* -maxdepth 0 -type f ! -name "*.gz" | xargs -i gzip --force {} find ${RABBITMQ_LOG_BASE}/*.log.*.back -maxdepth 0 -type f | xargs -i gzip {} find ${RABBITMQ_LOG_BASE}/*.gz -type f -mtime +30 -delete find ${RABBITMQ_LOG_BASE}/http_api/*.gz -type f -mtime +30 -delete

खरगोश-सर्वर-स्क्रिप्ट को कुंजी घुमाए-लॉग के साथ चलाने का परिणाम: लॉग को gzip द्वारा संपीड़ित किया जाता है, और केवल पिछले 30 दिनों के लिए संग्रहीत किया जाता है। http_api - वह मार्ग जहां खरगोश लॉग्स को डालता है http - कॉन्फ़िगरेशन फ़ाइल में कॉन्फ़िगर किया गया: {rabbitmq_management, [{दरों_मोड, विस्तृत}, {http_log_dir, path_to_logs / http_api "}]}

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

नए संस्करणों के 3.7 के रिलीज के साथ, init.d में rabbimq-server स्क्रिप्ट की पूरी अस्वीकृति थी। ऑपरेशन की सुविधा के लिए (खरगोश के संस्करण की परवाह किए बिना नियंत्रण आदेशों की एकरूपता) और संस्करणों के बीच एक चिकनी संक्रमण, पुन: प्राप्त खरगोश में हम इस स्क्रिप्ट का उपयोग करना जारी रखते हैं। सच्चाई फिर से है: हम रोटेट_लॉग्स_बर्बिटम () को थोड़ा बदल देंगे , क्योंकि रोटेशन के बाद नामकरण लॉग के लिए तंत्र 3.7 में बदल गया है:

  mv ${RABBITMQ_LOG_BASE}/$NODENAME.log.0 ${RABBITMQ_LOG_BASE}/$NODENAME.log.$(date +%Y%m%d-%H%M%S).back mv ${RABBITMQ_LOG_BASE}/$(echo $NODENAME)_upgrade.log.0 ${RABBITMQ_LOG_BASE}/$(echo $NODENAME)_upgrade.log.$(date +%Y%m%d-%H%M%S).back find ${RABBITMQ_LOG_BASE}/http_api/*.log.* -maxdepth 0 -type f ! -name "*.gz" | xargs -i gzip --force {} find ${RABBITMQ_LOG_BASE}/*.log.* -maxdepth 0 -type f ! -name "*.gz" | xargs -i gzip --force {} find ${RABBITMQ_LOG_BASE}/*.gz -type f -mtime +30 -delete find ${RABBITMQ_LOG_BASE}/http_api/*.gz -type f -mtime +30 -delete

अब यह केवल कॉंट्रैब पर लॉग रोटेशन के लिए कार्य को जोड़ने के लिए रहता है - उदाहरण के लिए, 23-00 पर हर दिन:
00 23 * * * ~ / rabbitmq-main / init.d / rabbitmq-server रोटेट-लॉग

आइए उन कार्यों पर चलते हैं जिन्हें "खरगोश फार्म" के संचालन के ढांचे में हल करने की आवश्यकता है:

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

हमारे चिड़ियाघर के संचालन और आवाज वाले कार्यों के समाधान के द्वारा आपूर्ति की गई नियमित खरगोशबीम_मनरेशन प्लग-इन के माध्यम से संभव है, लेकिन बेहद असुविधाजनक है, यही वजह है कि खरगोशों की पूरी विविधता को नियंत्रित करने के लिए एक शेल विकसित और कार्यान्वित किया गया था।

"किसी भी कीमत पर जीवित रहें" मोड में खरगोश (खरगोश का बच्चा) का ऑपरेशन

टेलिकॉम की वास्तविकताओं में परिवहन का कार्य क्या है?

हम कार्यों को कैसे हल करते हैं

अब सीधे खरगोशों पर सेटिंग्स:

परिणामस्वरूप चिड़ियाघर के संचालन की बारीकियां

More articles: