ओपनस्टैक MySQL + rabbitMQ सेवाओं के लिए अबाधित (HA)

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

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

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

कैसे OpenStack मैसेजिंग और डेटाबेस काम करते हैं

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

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

- उपयोगकर्ताओं द्वारा दर्ज किए गए डेटा की जांच करता है: (उदाहरण के लिए, सत्यापित करता है कि अनुरोधित वीएम छवि, विविधता, नेटवर्क मौजूद है)। यदि वे परिभाषित नहीं हैं, तो यह डिफ़ॉल्ट मान प्राप्त करने की कोशिश करता है (उदाहरण के लिए, विविधता, डिफ़ॉल्ट नेटवर्क)।
- उपयोगकर्ता प्रतिबंधों के अनुपालन के लिए अनुरोध की जाँच करता है।
- उसके बाद, ऊपर वर्णित चेक ने सकारात्मक परिणाम दिए, डेटाबेस में उदाहरण के बारे में एक रिकॉर्ड बनाता है (create_db_entry_for_new_instance फ़ंक्शन)।
- फ़ंक्शन _schedule_run_instance को कॉल करता है, जो उपयोगकर्ता अनुरोध को AMQP प्रोटोकॉल का उपयोग करते हुए संदेश कतार के माध्यम से नोवा-शेड्यूलर घटक को पास करता है। अनुरोध निकाय में उदाहरण पैरामीटर हैं:

request_spec = {
'छवि': jsonutils.to_primitive (छवि),
'inst_properties': base_options,
'inst_type': inst_type,
'num_instances': num_instances,
'block_device_mapping': block_device_mapping,
'सुरक्षा_ग्रुप': सुरक्षा_ग्रुप,
}

_Schedule_run_instance फ़ंक्शन शेड्यूलर_rpcapi.run_instance फ़ंक्शन कॉल के साथ AMQP संदेश भेजकर पूरा होता है।

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

मेजबान फ़िल्टर ubuntu (pid = 15493) से पास_फिल्टर / स्टॉप/stack/nova/nova/scheduler/host_manager.py:163
फ़िल्टर्ड [होस्ट 'ubuntu': free_ram_mb: 1501 free_disk_mb: 5120] से (pid = 15493) _schedule /opt/stack/nova/nova/scheduler-filter_scheduler.py:199

वह सबसे कम लागत के साथ नोड का चयन करता है, वजन फ़ंक्शन का उपयोग करता है (केवल एक नोड है, इसलिए इस मामले में वजन ऑपरेशन कुछ भी नहीं बदलता है):

भारित भारोत्तोलक मेजबान: ubuntu from (pid = 15493) _schedule /opt /stack/nova/nova/scheduler/filter_scheduler.py:209

कम्प्यूटेशनल नोड जिस पर चलाने के लिए आवश्यक है के बाद उदाहरण निर्धारित किया जाता है, शेड्यूलर ने cast_to_compute_host फ़ंक्शन को कॉल किया, जो:

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

जवाब में, चयनित नोड पर नोवा-कंप्यूट सेवा _run_instance विधि को कॉल करती है, जो डेटाबेस से आवृत्ति पैरामीटर प्राप्त करती है (UUID पर स्थानांतरित किया गया था) के आधार पर और उपयुक्त मापदंडों के साथ आवृत्ति शुरू करता है। उदाहरण के सेटअप के दौरान, nova-compute नेटवर्क इंटरेक्शन को कॉन्फ़िगर करने के लिए nov-network सेवा के साथ AMQP प्रोटोकॉल के माध्यम से संचार भी करता है (जिसमें IP पता असाइन करना और DHCP सर्वर को कॉन्फ़िगर करना भी शामिल है)। निर्माण प्रक्रिया के विभिन्न चरणों में वर्चुअल मशीन की स्थिति _ डेटाबेस में _instance_update फ़ंक्शन का उपयोग करके दर्ज की जाती है।

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

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

डेटाबेस के लिए हा समाधान

आप डेटा के बैकअप और प्रतिकृति के द्वारा डेटाबेस क्रैश को रोक सकते हैं। MySQL के मामले में, MySQL क्लस्टर (MySQL क्लस्टरिंग के लिए "आधिकारिक" सेट), MMM (कई मुख्य प्रतिकृतियों के साथ एक प्रतिकृति प्रबंधन उपकरण) और Percona के साथ XtraDB सहित विस्तृत विवरण के साथ कई समाधान हैं।

MySQL क्लस्टर

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

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

XtraDB क्लस्टर

यह उद्योग द्वारा मान्यता प्राप्त पेरकोना से एक समाधान है। XtraDB क्लस्टर में नोड्स का एक सेट होता है, जिनमें से प्रत्येक में प्रतिकृति का समर्थन करने के लिए ऐड-ऑन के सेट के साथ Percona XtraDB का एक उदाहरण चलता है। ऐड-ऑन में InnoDB भंडारण इंजन के साथ डेटा का आदान-प्रदान करने के लिए प्रक्रियाओं का एक सेट होता है और इसे WSREP विनिर्देश के अनुपालन वाले निचले स्तर पर प्रतिकृति प्रणाली बनाने की अनुमति देता है।



Percona से ऐड-ऑन के साथ एक mysqld संस्करण प्रत्येक क्लस्टर नोड पर चल रहा है। उनमें से प्रत्येक में डेटा की पूरी प्रति भी शामिल है। प्रत्येक नोड संचालन को पढ़ने और लिखने की अनुमति देता है। MySQL क्लस्टर की तरह, XtraDB क्लस्टर की यहाँ कुछ सीमाएँ हैं ।

MMM

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

- "रिकॉर्डिंग": ग्राहक इस आईपी पते से कनेक्ट करके डेटाबेस में लिख सकता है (पूरे क्लस्टर में केवल एक रिकॉर्डिंग नोड हो सकता है)।

- "पढ़ना": ग्राहक इस आईपी पते से जुड़कर डेटाबेस में पढ़ सकता है (रीडिंग को स्केल करने के लिए कई रीडिंग नोड हो सकते हैं)।

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



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

संदेश कतार के लिए सेवा (एचए) की निरंतरता

उनके स्वभाव से, RabbitMQ डेटा बहुत बार बदलता है। चूंकि संदेश भेजने के लिए गति और डेटा की मात्रा महत्वपूर्ण है, सभी संदेश रैम में संग्रहीत किए जाते हैं, जब तक कि आपने कतारों को "स्थिर" के रूप में परिभाषित नहीं किया है - इस मामले में, RabbitMQ डिस्क पर संदेश लिखता है। यह सुविधा OpenStack द्वारा समर्थित है nova.conf में rabbit_durable_queues = True पैरामीटर का उपयोग करके। हालाँकि संदेश डिस्क पर लिखे जाते हैं और इस प्रकार गायब नहीं होंगे यदि RabbitMQ सर्वर क्रैश या रिबूट होता है, यह निर्बाध संचालन सुनिश्चित करने के लिए एक वास्तविक समाधान नहीं है, जैसे:

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

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

पेसमेकर पर आधारित एक समाधान भी है, लेकिन यह ऊपर वर्णित एक की तुलना में अप्रचलित माना जाता है।

यह ध्यान दिया जाना चाहिए कि ऊपर वर्णित क्लस्टरिंग मोड में से कोई भी सीधे ओपनस्टैक में समर्थित नहीं है; फिर भी, मिरांटिस के पास इस क्षेत्र में काफी अनुभव है (नीचे इस पर अधिक)।

मिरांटिस में तैनाती का अनुभव

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



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

MMM के शीर्ष पर Haproxy दोनों IP पतों के बीच लोड संतुलन को पढ़कर बेहतर प्रदर्शन प्रदान करता है। बेशक, अधिक मापनीयता के लिए, आप पढ़ने के लिए अतिरिक्त आईपी पते के साथ कई अधीनस्थ नोड जोड़ सकते हैं। जबकि HAproxy यातायात को अच्छी तरह से वितरित करता है, यह स्वयं द्वारा निर्बाध संचालन सुनिश्चित नहीं करता है, इसलिए एक और HAproxy इंस्टेंस बनाया जाता है और पेसमेकर में दोनों उदाहरणों के लिए एक संसाधन बनाया जाता है। इसलिए, यदि HAproxy proxies में से एक विफल रहता है, तो पेसमेकर IP पते को निष्क्रिय "रिकॉर्डिंग सर्वर" से दूसरे में स्थानांतरित करता है।

चूंकि हमारे पास केवल एक "रिकॉर्डिंग" आईपी पता है, इसलिए हमें लोड को वितरित करने और अनुरोधों को सीधे लिखने की आवश्यकता नहीं है।

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

RabbitMQ HA और OpenStack की तुलना में, Mirantis ने कतार मिररिंग के लिए समर्थन के साथ नोवा के लिए एक ऐड-ऑन का प्रस्ताव दिया है। उपयोगकर्ता के दृष्टिकोण से, ऐड-ऑन nova.conf में दो नए विकल्प जोड़ता है:

-Brbit_ha_queues = ट्रू मिररिंग सक्षम करने के लिए सही / गलत -।
-rabbit_hosts = ["rabbit_host1", "rabbit_host2"] - ताकि उपयोगकर्ता RabbitMQ HA नोड्स की संकुल जोड़ी को परिभाषित कर सकें।

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

अतिरिक्त जानकारी

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

http://wiki.openstack.org/HAforNovaDB/: ओपनस्टैक डीबी के लिए निरंतरता
http://wiki.openstack.org/RabbitmqHA: निर्बाध कतार प्रणाली
http://www.hastexo.com/blogs/florian/2012/03/21/high-avolution-openstack: ओपनस्टैक में निरंतरता के विभिन्न पहलुओं पर लेख
http://docs.openstack.org/developer/nova/devref/rpc.html: ओपनस्टैक मैसेज कैसे काम करता है
http://www.laurentluce.com/posts/openstack-nova-internals-of-instance-launching/: एक उदाहरण शुरू करते समय चरणों के अनुक्रम का एक दिलचस्प विवरण
https://lists.launchpad.net/openstack/pdfGiNwMEtUBJ.pdf: नोवा में निरंतरता पर प्रस्तुति
http://openlife.cc/blogs/2011/may/different-ways-doing-ha-mysql/: शीर्षक सब कुछ समझाता है
http://www.linuxjournal.com/article/10718: MySQL प्रतिकृति लेख
http://www.mysqlperformanceblog.com/2010/10/20/mysql-limitation-part-1-single-threaded-replication/: प्रतिकृति प्रदर्शन समस्याओं के बारे में
https://github.com/jayjanssen/Percona-Pacemaker-Resource-Agents/blob/master/doc/PRM-setup-guide.rst: MySQL प्रतिकृति लेख: पर्कॉन प्रतिकृति प्रबंधक लेख
http://www.rabbitmq.com/clustering.html: RabbitMQ क्लस्टरिंग
http://www.rabbitmq.com/ha.html: RabbitMQ अनुरोधों को प्रतिबिंबित किया

मूल लेख अंग्रेजी में