Bitrix24 आर्किटेक्चर - इनसाइड व्यू

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

इस सेवा का पहला प्रोटोटाइप पिछले साल फरवरी में लॉन्च किया गया था। एक सर्वर पर, स्केलिंग के लिए कोई विशेष सुविधाओं के बिना, डेटा सेंटर स्तर पर बैकअप के बिना ... :) केवल एक अवधारणा।

इस प्रकाशन के साथ हम पदों की एक श्रृंखला खोलेंगे जिसमें हम आपको बताना चाहेंगे कि विकास के वर्ष के दौरान क्या किया गया था, परियोजना की अंतिम वास्तुकला क्या थी; हम प्रति दिन परियोजना के वास्तविक "24" घंटे सुनिश्चित करने के लिए क्या करते हैं; 1C-बिट्रिक्स विकास मंच में क्या परिवर्तन किए जाने थे; अमेज़न बादल सुविधाएँ और अधिक।

हम वास्तव में चाहते हैं कि हमारा अनुभव उन सभी डेवलपर्स के लिए उपयोगी हो जो अभी लॉन्च करने की योजना बना रहे हैं या पहले से ही बड़ी वेब परियोजनाओं और सेवाओं का संचालन और समर्थन कर रहे हैं।

* * *

तो, पहली पोस्ट समग्र रूप से परियोजना की वास्तुकला के बारे में है। चलो चलते हैं!

खुद Bitrix24 विचार विकसित करने की प्रक्रिया में , हमने अपने लिए कई व्यावसायिक कार्य तैयार किए:

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

इन व्यावसायिक आवश्यकताओं ने अंततः काम के दो बड़े "मोर्चों" का गठन किया: एक स्केलेबल फॉल्ट-टॉलरेंट (थोड़ा आगे "क्लाउड") विकास मंच का निर्माण और परियोजना बुनियादी ढांचे के लिए एक तकनीकी मंच का विकल्प।

1C- बिट्रिक्स डेवलपमेंट प्लेटफॉर्म

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

1C-बिट्रिक्स प्लेटफॉर्म के विकास में एक बड़ा कदम था, पिछले वसंत में संस्करण 10.0 में वेब क्लस्टर मॉड्यूल का उदय।

हमने उनके बारे में हैबे पर विस्तार से लिखा है। मुख्य विशेषताओं को संक्षेप में दोहराएं:

• ऊर्ध्वाधर शार्किंग (MySQL सर्वर को अलग करने के लिए अलग-अलग मॉड्यूल का स्थानांतरण)
• मंच कोर स्तर पर सर्वर के बीच MySQL प्रतिकृति और लोड संतुलन
• वितरित डेटा कैश (मेमेकैक्ड)
• वेब सर्वर (डेटाबेस में सत्रों को संग्रहीत करने) के बीच सत्र निरंतरता
• वेब सर्वर क्लस्टरिंग

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



लेकिन आदर्श अभी भी दूर था, "अड़चनें" थीं:

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

2011 के पतन में जारी "1C-बिट्रिक्स" प्लेटफॉर्म संस्करण 11.0 में, हमने इन समस्याओं को भी हल किया। क्लाउड फ़ाइल भंडारण के लिए समर्थन ने स्थिर सामग्री के सिंक्रनाइज़ेशन की समस्या को हल किया, और MySQL में मास्टर-मास्टर प्रतिकृति के समर्थन के कार्यान्वयन ने भौगोलिक रूप से वितरित वेब क्लस्टर बनाने के लिए संभव बना दिया।

और हम दूसरे बड़े काम के करीब आ गए ...

इन्फ्रास्ट्रक्चर तैनाती मंच

सच कहूं तो चुनाव बहुत मुश्किल नहीं था। :)

"क्लाउड" या "क्लाउड" नहीं - ऐसा सवाल भी खड़ा नहीं हुआ था। :)

स्वयं या पट्टे पर उपकरण को परियोजना की शुरुआत में बुनियादी ढांचे में काफी गंभीर निवेश की आवश्यकता होती है। भौतिक हार्डवेयर स्केल करना कठिन (लंबा और महंगा) है। प्रशासन (विशेषकर विभिन्न डीसी में) असुविधाजनक है।

इसलिए - "बादल"!

कौन सा? हमने Amazon AWS को चुना।

हमारी सभी साइटें काफी समय से अमेज़न में काम कर रही हैं। हम इस तथ्य को पसंद करते हैं कि कई तैयार सेवाएं हैं जो आप अपनी बाइक का आविष्कार करने के बजाय बस अपनी परियोजना में ले सकते हैं और उपयोग कर सकते हैं: एस 3 क्लाउड स्टोरेज, इलास्टिक लोड बैलेंसिंग , क्लाउडवेच , ऑटोस्केलिंग और बहुत कुछ।

बहुत ही सरल रूप में, Bitrix24 की पूरी वास्तुकला कुछ इस तरह दिखती है:



वेब - ऑटो स्केल

एप्लिकेशन (वेब) हमारे साथ लंबवत (सर्वर क्षमता में वृद्धि) नहीं करता है, लेकिन क्षैतिज रूप से (नई मशीनें जोड़ रहा है)।

ऐसा करने के लिए, हम इलास्टिक लोड बैलेंसिंग + क्लाउडवॉच + ऑटो स्केलिंग के एक गुच्छा का उपयोग करते हैं। सभी क्लाइंट अनुरोध (HTTP और HTTPS) एक या एक से अधिक Amazon Balancers (ELBs) को भेजे जाते हैं। हम CloudWatch के माध्यम से लोड में वृद्धि और कमी की निगरानी करते हैं। दो दिलचस्प मैट्रिक्स हैं - ईसी 2 नोड्स की स्थिति (% सीपीयू यूटिलाइजेशन) और बैलेंसर (विलंबता समय - सेकंड में)।

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

अब, अंत में, नई मशीनें स्वचालित रूप से शुरू हो जाएंगी यदि औसत सीपीयू उपयोग (अमेज़ॅन शब्दों में) 60% से अधिक हो जाता है, और स्वचालित रूप से बंद हो जाता है और अगर औसत लोड 30% से कम है तो डिकमीशन।

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



सेवा उपयोगकर्ताओं की स्थिर सामग्री

उपरोक्त योजना में, वेब नोड अनिवार्य रूप से "उपभोग्य वस्तुएं" बन जाते हैं। वे किसी भी समय और किसी भी समय बुझाने के लिए शुरू कर सकते हैं। और इसका मतलब यह है कि उन पर कोई उपयोगकर्ता सामग्री नहीं होनी चाहिए।

यही कारण है कि Bitrix24 में प्रत्येक नए पोर्टल को बनाते समय, अमेज़ॅन के लिए S3 में डेटा संग्रहीत करने के लिए एक व्यक्तिगत खाता बनाया जाता है। इस प्रकार, प्रत्येक पोर्टल का डेटा एक दूसरे से पूरी तरह से अलग है।

वहीं, S3 स्टोरेज अपने आप में बहुत विश्वसनीय है। अमेज़ॅन स्वयं अपने डिवाइस का विस्तार से वर्णन करता है (और, सिद्धांत रूप में, उन्हें विश्वास नहीं करने का कोई कारण नहीं है)।

S3 में डेटा को कई बिंदुओं पर दोहराया जाता है। एक ही समय में - भौगोलिक रूप से वितरित बिंदुओं (विभिन्न डेटा केंद्र) के लिए।

भंडारण उपकरणों में से प्रत्येक की निगरानी की जाती है और जल्दी से एक या किसी अन्य खराबी की स्थिति में प्रतिस्थापित किया जाता है।

जब आप रिपॉजिटरी में नई फाइलें अपलोड करते हैं, तो आपको एक सफल अपलोड के बारे में केवल तभी प्रतिक्रिया मिलेगी, जब फाइल कई अलग-अलग बिंदुओं पर पूरी तरह से बच जाए।

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

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

दो डेटा केंद्र और मास्टर-मास्टर प्रतिकृति

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

थोड़ा और विस्तार - यह सब कैसे काम करता है।

प्रत्येक डीसी में आधार दूसरे डीसी में दास के सापेक्ष मास्टर होता है और उसी समय दास मास्टर के सापेक्ष होता है।

इस तंत्र को लागू करने के लिए MySQL में महत्वपूर्ण सेटिंग्स auto_increment_increment और हैं
auto_increment_offset । वे रिकॉर्ड्स के दोहराव से बचने के लिए, स्वत: -आबंध - फ़ील्ड के लिए ऑफ़सेट मान सेट करते हैं। मोटे तौर पर, एक मास्टर में - केवल आईडी भी, दूसरे में - केवल विषम वाले।

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

विभिन्न डेटा केंद्रों में डेटाबेस समकालिक होते हैं, लेकिन एक-दूसरे से स्वतंत्र होते हैं: डेटा केंद्रों के बीच कनेक्टिविटी का नुकसान घंटों हो सकता है, पुनर्प्राप्ति के बाद डेटा सिंक्रनाइज़ किया जाता है।

विश्वसनीयता, विश्वसनीयता, विश्वसनीयता

Bitrix24 में सबसे महत्वपूर्ण प्राथमिकताओं में से एक है सेवा की निरंतर उपलब्धता और इसका दोष सहिष्णुता।

सरल सेवा योजना याद है? परिणामस्वरूप (वैसे भी सरलीकृत, लेकिन फिर भी :) यह कुछ इस तरह दिखता है:



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

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

यदि डेटा केंद्र पूरी तरह से विफल हो जाता है, या, उदाहरण के लिए, आधार पर विफलता होती है, तो सभी ट्रैफ़िक स्वचालित रूप से एक कार्यशील डेटा केंद्र पर स्विच हो जाते हैं।

यदि यह मशीनों पर एक बढ़े हुए लोड का कारण बनता है, तो CloudWatch बढ़े हुए CPU उपयोग को निर्धारित करता है और AutoScaling के नियमों के अनुसार एक डेटा केंद्र में आवश्यक मशीनों की संख्या को जोड़ता है।

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

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

* * *

मैंने इस पहली पोस्ट को "आसान", मनोरम बनाने की कोशिश की। :) अगर मैंने वह सब कुछ रखा है जो मैं एक पाठ में साझा करना चाहता हूं और एक बार में हमारे सभी अनुभव के बारे में बताया है, तो मुझे बहुत सारे पत्र मिले होंगे। :)

विषयगत पदों की एक श्रृंखला बनाना मेरे लिए अधिक तर्कसंगत लगता है। जिन विषयों की हम पहले से तैयारी कर रहे हैं:

• अमेज़ॅन की बारीकियाँ: गैर-स्पष्ट सीमाएं, बैनरों के विभिन्न मोड, एएमआई छवियों के साथ काम करना
• वेब नोड विनिर्देशन: सॉफ्टवेयर अपडेट तंत्र, अपाचे / गैर अपाचे, सुरक्षा और उपयोगकर्ता अलगाव
• MySQL: क्यों Percona, मास्टर-मास्टर की विशेषताएं, डेटा की एक बड़ी मात्रा की प्रतिकृति, क्वेरी कैश की बारीकियों, तेज
• डेटा बैकअप और सबसे महत्वपूर्ण बात - उनकी वसूली
• हजारों वस्तुओं की निगरानी, ​​अलर्ट के साथ खुद को स्पैम करने के लिए कैसे नहीं, हम सूचनाओं की प्रतिक्रिया को स्वचालित करते हैं

आपके लिए सबसे दिलचस्प क्या है? आप अनायास मतदान कर सकते हैं और टिप्पणियों में सीधे निशान लगा सकते हैं। :)

और निश्चित रूप से - खुद Bitrix24 की कोशिश करो! पहला टैरिफ फ्री है। यदि इसकी सीमा या कार्यक्षमता पर्याप्त नहीं है - तो उच्च टैरिफ पर स्विच करना संभव होगा। :)

कनेक्ट - और खुशी के साथ काम!