कॉन्सुल का उपयोग स्केल स्टेटफुल सर्विसेज के लिए

22 सितंबर को, हमने अत्यधिक भारित सिस्टम के डेवलपर्स के लिए अपना पहला गैर-मानक मिटैप आयोजित किया। यह बहुत अच्छा था, रिपोर्टों पर बहुत सारी सकारात्मक प्रतिक्रिया और इसलिए न केवल उन्हें अपलोड करने का फैसला किया, बल्कि हैबर के लिए डिक्रिप्ट भी किया। आज हम BIT.GAMES से इवान बुब्नोव, DevOps द्वारा एक भाषण प्रकाशित करते हैं। उन्होंने राज्य सेवाओं के तेजी से विकास और विफलता की संभावना के लिए पहले से ही काम कर रहे उच्च-लोड परियोजना में कौंसल खोज सेवा के कार्यान्वयन के बारे में बात की। और बैकएंड अनुप्रयोगों और नुकसान के लिए एक लचीला नाम स्थान के आयोजन के बारे में भी। अब इवान के लिए एक शब्द।


मैं BIT.GAMES स्टूडियो में प्रोडक्शन इन्फ्रास्ट्रक्चर का संचालन करता हूं और हमारी परियोजना "गिल्ड ऑफ हीरोज" में हैशिकॉर्प से कंसूल के कार्यान्वयन की कहानी बताता हूं - मोबाइल उपकरणों के लिए अतुल्यकालिक पीपीवी के साथ फंतासी आरपीजी। Google Play, App Store, Samsung, Amazon पर उपलब्ध है। DAU लगभग 100,000, ऑनलाइन 10 से 13 हजार तक। हम गेम को यूनिटी में बनाते हैं, इसलिए हम क्लाइंट को C # में लिखते हैं और गेम लॉजिक के लिए अपनी BHL स्क्रिप्टिंग भाषा का उपयोग करते हैं। हम गोलंग में सर्वर भाग लिखते हैं (इसे PHP से स्विच किया जाता है)। अगला हमारे प्रोजेक्ट की योजनाबद्ध वास्तुकला है।


वास्तव में, बहुत अधिक सेवाएं हैं, गेम लॉजिक की मूल बातें हैं।

तो हमारे पास क्या है। स्टेटलेस सेवाओं में, ये हैं:

• nginx, जिसे हम फ्रंटेंड और लोड बैलेंसर के रूप में उपयोग करते हैं और वजन गुणांक द्वारा हमारे बैकेंड को क्लाइंट वितरित करते हैं;
• नामांकित - गो से बैकएंड, संकलित अनुप्रयोग। यह हमारी वास्तुकला की केंद्रीय धुरी है, वे काम के शेर का प्रदर्शन करते हैं और अन्य सभी बैकेंड सेवाओं के साथ संवाद करते हैं।

स्टेटफुल सेवाओं में से, हमारे पास मुख्य हैं:

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

डिजाइन प्रक्रिया के दौरान, हम (बाकी सभी की तरह) को उम्मीद थी कि यह परियोजना सफल होगी और एक तेज तंत्र के लिए प्रदान की जाएगी। इसमें दो MAINDB डेटाबेस इकाइयाँ और स्वयं शार्द शामिल हैं।



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

लेकिन जब हमने डिजाइन किया था, तो हम एक बड़ी परियोजना नहीं थे, इसलिए हमने केवल आम तौर पर शार्प शार्क बनाने का फैसला किया। वे सभी एक ही भौतिक सर्वर पर स्थित थे और सबसे अधिक संभावना डेटाबेस में एक ही सर्वर के विभाजन की थी।

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

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



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

कंसूल इस सब के प्रबंधन के लिए शानदार वेब UI और REST API भी प्रदान करता है।

उच्च उपलब्धता के लिए, हमने ऑटो-फ़ेलओवर के लिए दो उपयोगिताओं को चुना:

• MySQL के लिए MHA
• Redis-प्रहरी

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

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

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



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

इसके अलावा, डेटा सेंटर एक स्थिर संरचना नहीं है जिसे आप से भर गए हैं और यह इरादा के अनुसार काम करता है। लेकिन हम, दुर्भाग्य से (या सौभाग्य से), इसके बारे में बाद में ही पता चला, लेकिन अब हम प्रेरित थे और आत्मविश्वास से भरे हुए थे कि हम उत्पादन पर सब कुछ लागू करेंगे।



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

इसलिए, हमने अपनी स्क्रिप्ट बाइंडिंग के बारे में सोचा और इस प्रश्न को स्थगित कर दिया। हमने लगातार कार्रवाई करने और कंसुल के कार्यान्वयन के साथ शुरुआत करने का फैसला किया।



कौंसल एक विकेन्द्रीकृत, वितरित क्लस्टर है जो गपशप प्रोटोकॉल और रेज़मै सर्वसम्मति एल्गोरिथ्म के आधार पर संचालित होता है।

हमारे पास पांच सर्वरों का एक स्वतंत्र समतुल्य है (विभाजित मस्तिष्क की स्थिति से बचने के लिए पांच)। प्रत्येक नोड के लिए, हम कॉन्सुल एजेंट को एजेंट मोड में छोड़ते हैं और सभी हेल्थचेक को स्पिल करते हैं (यानी ऐसा नहीं था कि हम किसी विशिष्ट सर्वर पर एक हेल्थचेक और अन्य को विशिष्ट सर्वर पर अपलोड करें)। Healthcheck इसलिए लिखे गए थे कि वे केवल वहीं पास करें जहाँ कोई सेवा हो।

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

सब कुछ पहली बार शुरू हुआ, हमारी खुशी कोई सीमा नहीं थी। लेकिन यह आनन्दित करने के लिए बहुत जल्दी था, क्योंकि एक घंटे के भीतर हमने देखा कि सभी नोड्स पर जहां हमारे बैकेंड स्थित हैं, लोड औसत संकेतक 0.7 से बढ़कर 1.0 हो गया, जो कि एक वसा संकेतक है।



मैं सर्वर पर चढ़ गया यह देखने के लिए कि क्या हो रहा है और यह स्पष्ट हो गया कि सीपीयू कॉन्सुल खा रहा था। यहां हमने इसका पता लगाना शुरू कर दिया, स्ट्रेस (यूनिक्स सिस्टम के लिए एक उपयोगिता जो आपको ट्रैक को चलाने की अनुमति देता है जो कि प्रक्रिया चल रही है) के साथ शंटिंग करना शुरू कर दिया, इस नोड पर क्या चल रहा है, यह समझने के लिए Dnsmasq आँकड़ों को डंप करना, और यह पता चला कि हम एक बहुत महत्वपूर्ण बिंदु चूक गए। एकीकरण की योजना बनाते हुए, हम DNS रिकॉर्ड्स की कैशिंग से चूक गए और यह पता चला कि हमारे बैकेंड ने अपने प्रत्येक मूवमेंट के लिए Dnsmasq को खींच लिया है, और इसके बदले में कौंसल की ओर रुख किया और इसके परिणामस्वरूप प्रति सेकंड 940 DNS प्रश्नों का सामना करना पड़ा।

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

फिर हमने कस्टम होस्ट्स-फ़ाइल का उपयोग करते हुए एक मुश्किल तरीके से बाहर निकलने का फैसला किया।



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

हमने क्या किया, फिर से स्क्रिप्ट को Ansible में तैयार किया, इसे उत्पादन पर अपलोड किया और यह कुछ इस तरह दिखने लगा:



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

अब सब कुछ ऐसा लगने लगा जैसे हमने योजना बनाई है - हमारे उत्पादन के लिए बिल्कुल पारदर्शी, व्यावहारिक रूप से बिना संसाधनों के उपभोग के।

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



सुबह लॉग से निपटते हुए, मैंने देखा कि सभी त्रुटियां एक ही प्रकार के अज्ञात होस्ट की थीं। यह स्पष्ट नहीं था कि Dnsmasq एक फ़ाइल से एक या दूसरी सेवा का उपयोग क्यों नहीं कर सकता है - ऐसा लग रहा था कि यह बिल्कुल भी मौजूद नहीं था। यह समझने की कोशिश करने के लिए कि क्या चल रहा था, मैंने फ़ाइल को फिर से जेनरेट करने के लिए एक कस्टम मीट्रिक जोड़ा - अब मुझे ठीक उसी समय का पता था जब यह पुनर्जीवित होगा। इसके अलावा, कॉन्सल टेम्पलेट में एक उत्कृष्ट बैकअप विकल्प है, अर्थात। आप पुनर्जीवित फ़ाइल की पिछली स्थिति देख सकते हैं।

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



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

हमने इस बारे में सोचना शुरू किया कि क्या करना है और क्या समय-सीमा पैरामीटर को कौंसल में मोड़ दिया जाता है, जिसके बाद नोड कितना गिरता है, इसकी पहचान की जाती है। हम काफी छोटे संकेतक के साथ इस समस्या को हल करने में कामयाब रहे, नोड्स का गिरना बंद हो गया, लेकिन इससे हेल्थचेक में मदद नहीं मिली।

हमने हेल्थचेक के लिए अलग-अलग मापदंडों को चुनने के बारे में सोचना शुरू किया, किसी तरह समझने की कोशिश की कि यह कब और कैसे होता है। लेकिन इस तथ्य के कारण कि सब कुछ छिटपुट और अप्रत्याशित रूप से हुआ, हम ऐसा करने में सक्षम नहीं थे।

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

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



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

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

So. हमें आखिरकार वही मिला जो हम चाहते थे और हमारी बैकेंड के लिए एक गतिशील नाम स्थान का आयोजन किया। आगे हम उच्च उपलब्धता सुनिश्चित करने की दिशा में आगे बढ़े।



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

इसलिए, हम एक सरल (या जटिल) रास्ते पर चले गए: हमने ड्यूटी पर प्रशासक के विवेक पर विफलता को छोड़ने का फैसला किया, लेकिन उसे एक और अतिरिक्त उपकरण दिया। हमने मास्टर मोड के साथ मास्टर दास प्रतिकृति पढ़ें केवल मोड में प्रतिस्थापित किया है। यह विफलता की प्रक्रिया में सिरदर्द की एक बड़ी मात्रा को हटा देता है - जब आपको एक विज़ार्ड मिलता है, तो आपको केवल वेब UI या एपीआई में एक कमांड का उपयोग करके k / v-स्टोरेज में मूल्य को बदलना होगा और इससे पहले, केवल मोड पढ़ें बैकअप मास्टर।

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


कंसूल वेब इंटरफेस

दाईं ओर k / v- स्टोरेज है और हमारी सेवाएं दिखाई देती हैं, जिसका उपयोग हम gamed में करते हैं; मान नोड का नाम है।

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



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



इसलिए हमने शार्ट्स को तोड़ दिया। 40 , backend' ( , — ).



failover', — 20 40 . .

— , , - , .

-, , , , - , , , .

- , , ; — , , , .

k/v — ?

K/v- Consul- - , http- RESTful API Web UI.

, - , , .

, Redis?

, - .

-, backend. -, backend', — . यानी , MAINDB , . . - , .

- , inmemory key-value -.

?

MySQL — Percona server.

? Maria, MHA for MySQL, Galera.

Galera. - « » Galera , . , .

, — , , - , , , .

Pixonic DevGAMM Talks

• CICD: ( , Pixonic);
• - Quake Champions ( , backend- Saber Interactive);
• - - Tacticool ( , Lead Software Engineer PanzerDog);
• ECS, C# Job System SRP ( , Field Engineer Unity);
• KISS ( , Lead Game Programmer 1C Game Studios);
• ( , Deputy Technical Officer Pixonic).
• Cucumber : BDD- ( , Technical Product Manager ALICE Platform).