Bitrix24: "छिटो उठेको कुरालाई पतन भएको मानिने छैन"

आज, Bitrix24 सेवासँग सयौं गिगाबिट ट्राफिक छैन, न त यसमा सर्भरहरूको ठूलो फ्लीट छ (यद्यपि, अवश्य पनि, त्यहाँ धेरै अवस्थित छन्)। तर धेरै ग्राहकहरु को लागी यो कम्पनी मा काम को लागी मुख्य उपकरण हो; यो एक वास्तविक व्यापार-महत्वपूर्ण अनुप्रयोग हो। त्यसैले ढल्ने बाटो छैन । के यदि दुर्घटना भयो भने, तर सेवा यति चाँडै "पुन: प्राप्त भयो" कि कसैले केहि पनि याद गरेन? र कसरी कामको गुणस्तर र ग्राहकहरूको संख्या नगुमाई असफलता कार्यान्वयन गर्न सम्भव छ? Bitrix24 मा क्लाउड सेवाका निर्देशक अलेक्जेन्डर डेमिडोभले हाम्रो ब्लगको लागि रिजर्भेसन प्रणाली कसरी उत्पादनको अस्तित्वको 7 वर्षमा विकसित भएको छ भन्ने बारे कुरा गर्नुभयो।

"हामीले 24 वर्ष पहिले SaaS को रूपमा Bitrix7 सुरु गर्यौं। मुख्य कठिनाई सायद निम्न थियो: यो SaaS को रूपमा सार्वजनिक रूपमा सुरू गर्नु अघि, यो उत्पादन केवल बाकस समाधानको ढाँचामा अवस्थित थियो। ग्राहकहरूले यसलाई हामीबाट किनेका छन्, यसलाई तिनीहरूको सर्भरमा होस्ट गरेका छन्, कर्पोरेट पोर्टल सेटअप गरेका छन् - कर्मचारी सञ्चार, फाइल भण्डारण, कार्य व्यवस्थापन, CRM, यो सबैको लागि सामान्य समाधान। र 2012 सम्म, हामीले निर्णय गर्यौं कि हामी यसलाई SaaS को रूपमा सुरू गर्न चाहन्छौं, यसलाई आफैं व्यवस्थापन गर्दै, त्रुटि सहिष्णुता र विश्वसनीयता सुनिश्चित गर्दै। हामीले बाटोमा अनुभव प्राप्त गर्यौं, किनकि त्यतिन्जेल हामीसँग यो थिएन - हामी केवल सफ्टवेयर निर्माताहरू थियौं, सेवा प्रदायकहरू होइनौं।

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

Bitrix.24 SaaS को रूपमा

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

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

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

हामीले विभिन्न क्लाउड वस्तु भण्डारणहरूको लागि उत्पादन स्तरमा समर्थन गरेका छौं: google भण्डारण, amazon s3, साथै खुला स्ट्याक स्विफ्टको लागि समर्थन। तसर्थ, यो हाम्रो लागि सेवाको रूपमा र प्याकेज गरिएको समाधानको साथ काम गर्ने विकासकर्ताहरूको लागि दुवै सुविधाजनक थियो: यदि तिनीहरूले कामको लागि मात्र हाम्रो API प्रयोग गर्छन् भने, तिनीहरूले फाईल अन्ततः कहाँ बचत हुनेछ भन्ने बारे सोच्दैनन्, स्थानीय रूपमा फाइल प्रणालीमा वा। वस्तु फाइल भण्डारणमा।

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

जे चाहन्थे, त्यही पाए...

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

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

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

यो सबै कसरी काम गर्छ? — हामी ट्राफिकलाई काम गर्ने डाटा सेन्टरमा स्विच गर्छौं - यदि डाटा सेन्टरमा दुर्घटना भएको छ भने, पूर्ण रूपमा, यदि यो एउटा डाटाबेसको साथ हाम्रो योजनाबद्ध काम हो भने, हामी यी ग्राहकहरूलाई सेवा दिने ट्राफिकको अंशलाई दोस्रो डाटा केन्द्रमा स्विच गर्छौं, निलम्बन गर्दै। यसको प्रतिकृति। यदि वेब अनुप्रयोगहरूको लागि नयाँ मेसिनहरू आवश्यक छ किनभने दोस्रो डाटा केन्द्रमा लोड बढेको छ, तिनीहरू स्वचालित रूपमा सुरु हुनेछन्। हामी काम समाप्त गर्छौं, प्रतिकृति पुनर्स्थापित हुन्छ, र हामी सम्पूर्ण लोड फिर्ता गर्छौं। यदि हामीले दोस्रो DC मा केही काम मिरर गर्न आवश्यक छ भने, उदाहरणका लागि, प्रणाली अद्यावधिकहरू स्थापना गर्नुहोस् वा दोस्रो डाटाबेसमा सेटिङहरू परिवर्तन गर्नुहोस्, त्यसपछि, सामान्यतया, हामी उही कुरा दोहोर्याउँछौं, अर्को दिशामा। र यदि यो दुर्घटना हो भने, हामी सबै कुरा तुच्छ रूपमा गर्छौं: हामी अनुगमन प्रणालीमा घटना-ह्यान्डलर संयन्त्र प्रयोग गर्छौं। यदि धेरै जाँचहरू ट्रिगर हुन्छन् र स्थिति महत्वपूर्णमा जान्छ भने, हामी यो ह्यान्डलर चलाउँछौं, एक ह्यान्डलर जसले यो वा त्यो तर्क कार्यान्वयन गर्न सक्छ। प्रत्येक डाटाबेसको लागि, हामी कुन सर्भर यसको लागि फेलओभर हो निर्दिष्ट गर्छौं, र यदि यो अनुपलब्ध छ भने ट्राफिक कहाँ स्विच गर्न आवश्यक छ। ऐतिहासिक रूपमा, हामी नागियोस वा यसको केही काँटाहरू एक वा अर्को रूपमा प्रयोग गर्दछौं। सैद्धान्तिक रूपमा, लगभग कुनै पनि अनुगमन प्रणालीमा समान संयन्त्रहरू अवस्थित छन्; हामी अझै जटिल केहि प्रयोग गर्दैनौं, तर सायद कुनै दिन हामी गर्नेछौं। अब अनुगमन अनुपलब्धता द्वारा ट्रिगर गरिएको छ र केहि स्विच गर्ने क्षमता छ।

के हामीले सबै कुरा आरक्षित गरेका छौं?

हामीसँग संयुक्त राज्य अमेरिकाबाट धेरै ग्राहकहरू छन्, युरोपका धेरै ग्राहकहरू, धेरै ग्राहकहरू जुन पूर्व - जापान, सिंगापुर र यस्तै अन्य नजिक छन्। निस्सन्देह, ग्राहकहरु को एक ठूलो हिस्सा रूस मा छन्। अर्थात् काम एउटै क्षेत्रमा हुँदैन । प्रयोगकर्ताहरू द्रुत प्रतिक्रिया चाहन्छन्, त्यहाँ विभिन्न स्थानीय कानूनहरूको पालना गर्न आवश्यकताहरू छन्, र प्रत्येक क्षेत्रमा हामीले दुईवटा डेटा केन्द्रहरू आरक्षित गर्छौं, साथै त्यहाँ केही अतिरिक्त सेवाहरू छन्, जुन फेरि, एक क्षेत्र भित्र राख्नको लागि सुविधाजनक छन् - ग्राहकहरूका लागि। यो क्षेत्र काम गरिरहेको छ। REST ह्यान्डलरहरू, प्राधिकरण सर्भरहरू, तिनीहरू समग्र रूपमा क्लाइन्टको सञ्चालनको लागि कम महत्वपूर्ण छन्, तपाइँ तिनीहरूलाई सानो स्वीकार्य ढिलाइको साथ स्विच गर्न सक्नुहुन्छ, तर तपाइँ तिनीहरूलाई कसरी निगरानी गर्ने र के गर्ने भन्ने बारे चक्र पुन: आविष्कार गर्न चाहनुहुन्न। तिनीहरुसँग। तसर्थ, हामी थप उत्पादनहरूमा केही प्रकारको क्षमता विकास गर्नुको सट्टा अधिकतममा अवस्थित समाधानहरू प्रयोग गर्ने प्रयास गरिरहेका छौं। र कतै हामी DNS लेभलमा स्विचिङलाई तुच्छ रूपमा प्रयोग गर्छौं, र हामी त्यही DNS द्वारा सेवाको जीवन्तता निर्धारण गर्छौं। Amazon सँग रुट 53 सेवा छ, तर यो केवल DNS मात्र होइन जसमा तपाइँ प्रविष्टिहरू गर्न सक्नुहुन्छ र यो हो - यो धेरै लचिलो र सुविधाजनक छ। यसको माध्यमबाट तपाईले जियोलोकेशनका साथ जियो-वितरित सेवाहरू निर्माण गर्न सक्नुहुन्छ, जब तपाइँ यसलाई ग्राहक कहाँबाट आयो भनेर निर्धारण गर्न र उसलाई निश्चित रेकर्डहरू दिन प्रयोग गर्नुहुन्छ - यसको मद्दतले तपाइँ फेलओभर आर्किटेक्चरहरू निर्माण गर्न सक्नुहुन्छ। उही स्वास्थ्य-जाँचहरू रुट 53 मा कन्फिगर गरिएको छ, तपाईंले अनुगमन गरिएका अन्तिम बिन्दुहरू सेट गर्नुहोस्, मेट्रिकहरू सेट गर्नुहोस्, सेवाको "जीवितता" निर्धारण गर्न कुन प्रोटोकलहरू सेट गर्नुहोस् - tcp, http, https; सेवा जीवित छ वा छैन भनेर निर्धारण गर्ने जाँचहरूको आवृत्ति सेट गर्नुहोस्। र DNS मा नै तपाइँले निर्दिष्ट गर्नुहुन्छ के प्राथमिक हुनेछ, के माध्यमिक हुनेछ, यदि स्वास्थ्य-जाँच रुट 53 भित्र ट्रिगर भयो भने कहाँ स्विच गर्ने। यो सबै केहि अन्य उपकरणहरूसँग गर्न सकिन्छ, तर किन यो सुविधाजनक छ - हामीले यसलाई सेट गर्छौं। एक पटक माथि र त्यसपछि हामी कसरी जाँच गर्छौं, हामी कसरी स्विच गर्छौं भन्ने बारे सोच्नुहोस्: सबै कुरा आफ्नै काम गर्दछ।

पहिलो "तर": रुट ५३ आफैं कसरी र केसँग रिजर्भ गर्ने ? कसलाई थाहा छ, यदि उसलाई केहि भयो भने? सौभाग्यवश, हामीले यो रेकमा कहिल्यै कदम चालेनौं, तर फेरि, मसँग एउटा कथा हुनेछ किन हामीले सोच्यौं कि हामीले अझै पनि आरक्षण गर्न आवश्यक छ। यहाँ हामीले पहिले नै आफ्नो लागि स्ट्राहरू राख्यौं। दिनमा धेरै पटक हामी 53 मार्गमा भएका सबै क्षेत्रहरूको पूर्ण अनलोड गर्छौं। Amazon को API ले तपाईंलाई JSON मा सजिलै पठाउन अनुमति दिन्छ, र हामीसँग धेरै ब्याकअप सर्भरहरू छन् जहाँ हामी यसलाई रूपान्तरण गर्छौं, यसलाई कन्फिगरेसनको रूपमा अपलोड गर्छौं र लगभग बोल्ने, ब्याकअप कन्फिगरेसन छ। यदि केहि भयो भने, हामी DNS सेटिङ डेटा नगुमाइकन यसलाई म्यानुअल रूपमा प्रयोग गर्न सक्छौं।

दोस्रो "तर": यो तस्विरमा के अझै आरक्षित गरिएको छैन? ब्यालेन्सर आफैं! क्षेत्र अनुसार हाम्रो ग्राहकहरु को वितरण धेरै सरल बनाइएको छ। हामीसँग bitrix24.ru, bitrix24.com, .de डोमेनहरू छन् - अब त्यहाँ 13 फरक छन्, जुन विभिन्न क्षेत्रहरूमा काम गर्दछ। हामी निम्नमा आएका छौं: प्रत्येक क्षेत्रको आफ्नै ब्यालेन्सरहरू छन्। यसले नेटवर्कमा पीक लोड कहाँ छ भन्ने आधारमा क्षेत्रहरूमा वितरण गर्न अझ सुविधाजनक बनाउँछ। यदि यो एकल ब्यालेन्सरको स्तरमा विफलता हो भने, त्यसपछि यो केवल सेवाबाट हटाइन्छ र dns बाट हटाइन्छ। यदि ब्यालेन्सरहरूको समूहमा केही समस्या छ भने, तिनीहरू अन्य साइटहरूमा ब्याकअप हुन्छन्, र तिनीहरू बीचको स्विच एउटै मार्ग प्रयोग गरी गरिन्छ53, किनभने छोटो TTL को कारणले, स्विचिङ अधिकतम 2, 3, 5 मिनेट भित्र हुन्छ। ।

तेस्रो "तर": के अझै आरक्षित छैन? S3, सही। जब हामीले s3 मा प्रयोगकर्ताहरूका लागि भण्डारण गर्ने फाइलहरू राख्यौं, हामीले ईमानदारीपूर्वक विश्वास गर्यौं कि यो आर्मर-छेड्ने थियो र त्यहाँ केहि पनि रिजर्भ गर्न आवश्यक छैन। तर इतिहासले देखाउँछ कि चीजहरू फरक रूपमा हुन्छन्। सामान्यतया, Amazon ले S3 लाई आधारभूत सेवाको रूपमा वर्णन गर्दछ, किनभने Amazon आफैंले S3 को मेशिन छविहरू, कन्फिगहरू, AMI छविहरू, स्न्यापसटहरू भण्डारण गर्न प्रयोग गर्दछ ... र यदि s3 क्र्यास भयो भने, यी 7 वर्षहरूमा एक पटक भयो, जबसम्म हामीले प्रयोग गर्दै आएका छौं। bitrix24, यसले फ्यानले जस्तै यसलाई पछ्याउँछ त्यहाँ धेरै चीजहरू छन् जुन आउँछ - भर्चुअल मेसिनहरू सुरू गर्न असक्षमता, एपीआई विफलता, र यस्तै।

र S3 खस्न सक्छ - यो एक पटक भयो। तसर्थ, हामी निम्न योजनामा ​​आएका थियौं: केही वर्ष पहिले रूसमा कुनै गम्भीर सार्वजनिक वस्तु भण्डारण सुविधाहरू थिएनन्, र हामीले आफ्नै केही गर्ने विकल्पलाई विचार गर्यौं... सौभाग्यवश, हामीले यो गर्न थालेनौं, किनभने हामी हामीसँग नभएको विशेषज्ञतामा खन्यौं, र सम्भवतः गडबड हुनेछ। अब Mail.ru सँग s3-कम्प्याटिबल भण्डारण छ, Yandex सँग छ, र धेरै अन्य प्रदायकहरूसँग यो छ। हामी अन्ततः यो विचारमा आएका थियौं कि हामी चाहन्छौं, पहिलो, ब्याकअप, र दोस्रो, स्थानीय प्रतिलिपिहरूसँग काम गर्ने क्षमता। विशेष गरी रूसी क्षेत्रका लागि, हामी Mail.ru Hotbox सेवा प्रयोग गर्छौं, जुन API s3 सँग मिल्दो छ। हामीलाई एप्लिकेसन भित्रको कोडमा कुनै ठूलो परिमार्जनको आवश्यकता पर्दैन, र हामीले निम्न संयन्त्र बनायौं: s3 मा ट्रिगरहरू छन् जसले वस्तुहरूको सिर्जना/मेटाउने ट्रिगर गर्दछ, Amazon सँग Lambda नामक सेवा छ - यो कोडको सर्भरलेस लन्च हो। जुन निश्चित ट्रिगरहरू ट्रिगर हुँदा मात्र कार्यान्वयन हुनेछ।

हामीले यो धेरै सरल रूपमा गर्यौं: यदि हाम्रो ट्रिगर फायर भयो भने, हामी कोड कार्यान्वयन गर्छौं जसले वस्तुलाई Mail.ru भण्डारणमा प्रतिलिपि गर्नेछ। डेटाको स्थानीय प्रतिलिपिहरूसँग पूर्ण रूपमा काम सुरु गर्न, हामीलाई रिभर्स सिङ्क्रोनाइजेसन पनि चाहिन्छ ताकि रूसी खण्डमा रहेका ग्राहकहरूले उनीहरूको नजिकको भण्डारणमा काम गर्न सकून्। मेलले यसको भण्डारणमा ट्रिगरहरू पूरा गर्न लागेको छ - पूर्वाधार स्तरमा रिभर्स सिङ्क्रोनाइजेसन गर्न सम्भव हुनेछ, तर अहिलेको लागि हामी यो हाम्रो आफ्नै कोडको स्तरमा गर्दैछौं। यदि हामीले देख्यौं कि क्लाइन्टले फाइल पोस्ट गरेको छ, त्यसपछि कोड स्तरमा हामी घटनालाई लाममा राख्छौं, यसलाई प्रशोधन गर्छौं र उल्टो प्रतिकृति गर्छौं। यो किन नराम्रो छ: यदि हामीले हाम्रो उत्पादन भन्दा बाहिरका वस्तुहरूसँग कुनै प्रकारको काम गर्छौं, त्यो हो, केही बाह्य माध्यमबाट, हामी यसलाई ध्यानमा राख्दैनौं। तसर्थ, हामी अन्त सम्म पर्खन्छौं, जब ट्रिगरहरू भण्डारण स्तरमा देखा पर्दछ, ताकि हामी जहाँबाट कोड कार्यान्वयन गर्छौं, हामीलाई आएको वस्तु अर्को दिशामा प्रतिलिपि गरिन्छ।

कोड स्तरमा, हामी प्रत्येक ग्राहकको लागि दुबै भण्डारणहरू दर्ता गर्छौं: एउटालाई मुख्य मानिन्छ, अर्कोलाई ब्याकअप मानिन्छ। यदि सबै कुरा ठीक छ भने, हामी हाम्रो नजिकको भण्डारणसँग काम गर्छौं: त्यो हो, हाम्रा ग्राहकहरू जो Amazon मा छन्, तिनीहरू S3 सँग काम गर्छन्, र रूसमा काम गर्नेहरूले Hotbox सँग काम गर्छन्। यदि फ्ल्याग ट्रिगर भयो भने, फेलओभर जडान हुनुपर्छ, र हामी ग्राहकहरूलाई अर्को भण्डारणमा स्विच गर्छौं। हामी क्षेत्र अनुसार यो बाकस स्वतन्त्र रूपमा जाँच गर्न सक्छौं र तिनीहरूलाई अगाडि र पछाडि स्विच गर्न सक्छौं। हामीले यसलाई व्यवहारमा प्रयोग गरेका छैनौं, तर हामीले यो मेकानिजम प्रदान गरेका छौं र हामीलाई लाग्छ कि कुनै दिन हामीलाई यो धेरै स्विच चाहिन्छ र काममा आउनेछ। यो पहिले पनि एक पटक भएको छ।

ओह, र Amazon भाग्यो ...

यो अप्रिल रूसमा टेलिग्राम ब्लकिङको सुरुवातको वार्षिकोत्सव हो। यस अन्तर्गत परेको सबैभन्दा प्रभावित प्रदायक अमेजन हो। र, दुर्भाग्यवश, सारा संसारको लागि काम गर्ने रूसी कम्पनीहरूले बढी पीडा भोगे।

यदि कम्पनी विश्वव्यापी छ र रूस यसको लागि धेरै सानो खण्ड हो, 3-5% - राम्रो, एक तरिका वा अर्को, तपाइँ तिनीहरूलाई बलिदान गर्न सक्नुहुन्छ।

यदि यो एक विशुद्ध रूसी कम्पनी हो भने - म निश्चित छु कि यो स्थानीय रूपमा अवस्थित हुन आवश्यक छ - ठीक छ, यो केवल प्रयोगकर्ताहरूको लागि सुविधाजनक हुनेछ, सहज हुनेछ, र त्यहाँ कम जोखिमहरू हुनेछन्।

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

मार्च 2018 को अन्त्यमा, Roskomnadzor ले ठूला अपरेटरहरूलाई एउटा पत्र पठायो कि उनीहरूले जेलो मेसेन्जरलाई ब्लक गर्न धेरै मिलियन अमेजन आईपीहरू ब्लक गर्ने योजना बनाएका थिए। यी उही प्रदायकहरूलाई धन्यवाद - तिनीहरूले सफलतापूर्वक सबैलाई पत्र लीक गरे, र त्यहाँ एक समझ थियो कि Amazon सँग जडान हुन सक्छ। यो शुक्रबार थियो, हामी सर्वर.ru बाट हाम्रा सहकर्मीहरूलाई आतंकित भएर दौडियौं, यसो भन्दै: "साथीहरू, हामीलाई धेरै सर्भरहरू चाहिन्छ जुन रूसमा, अमेजनमा होइन, तर उदाहरणका लागि, एम्स्टर्डममा कतै अवस्थित हुनेछन्," क्रममा। कम्तिमा कुनै न कुनै रूपमा हाम्रो आफ्नै VPN र प्रोक्सी स्थापना गर्न सक्षम हुनको लागि त्यहाँ केही अन्तिम बिन्दुहरूको लागि जुन हामीले कुनै पनि हिसाबले प्रभाव पार्न सक्दैनौं, उदाहरणका लागि समान s3 को endponts - हामी नयाँ सेवा उठाउने र फरक ip प्राप्त गर्ने प्रयास गर्न सक्दैनौं, हामी तपाईं अझै त्यहाँ पुग्न आवश्यक छ। केही दिनमा, हामीले यी सर्भरहरू सेट अप गर्यौं, तिनीहरूलाई चलाउन थाल्यौं, र सामान्यतया, ब्लकिङ सुरु भएको क्षणको लागि तयार छौं। यो उत्सुक छ कि RKN, गडबड र आतंक हेर्दै भन्यो: "होइन, हामी अब केहि रोक्दैनौं।" (तर यो ठ्याक्कै टेलिग्राम अवरुद्ध हुन थालेको क्षण सम्म हो।) बाइपास क्षमताहरू सेट अप गरिसकेपछि र ब्लकिङ पेश गरिएको थिएन भनेर महसुस गरेपछि, हामीले सम्पूर्ण मामिलालाई हल गर्न थालेका छैनौं। हो, केवल मामला मा।

र 2019 मा, हामी अझै पनि अवरुद्ध अवस्थामा बाँचिरहेका छौं। मैले हिजो राती हेरे: लगभग एक मिलियन आईपीहरू अवरुद्ध हुन जारी छ। साँचो, Amazon लगभग पूर्ण रूपमा अनब्लक गरिएको थियो, यसको चरम सीमामा यो 20 मिलियन ठेगानाहरूमा पुग्यो... सामान्यतया, वास्तविकता यो हो कि त्यहाँ समन्वय, राम्रो समन्वय नहुन सक्छ। अचानक। यो प्राविधिक कारणहरूको लागि अवस्थित नहुन सक्छ - आगो, उत्खनन, ती सबै। वा, हामीले देख्यौं, पूर्ण रूपमा प्राविधिक छैन। त्यसकारण, कोही ठूला र ठूला, तिनीहरूको आफ्नै AS को साथ, सम्भवतः यसलाई अन्य तरिकामा व्यवस्थापन गर्न सक्छ - प्रत्यक्ष जडान र अन्य चीजहरू पहिले नै l2 स्तरमा छन्। तर एउटा साधारण संस्करणमा, हाम्रो जस्तै वा त्योभन्दा पनि सानो, तपाईले, केवल यदि, कतै उठाइएको सर्भरको स्तरमा अनावश्यकता छ, अग्रिम vpn, प्रोक्सीमा कन्फिगर गरिएको छ, ती खण्डहरूमा कन्फिगरेसनलाई द्रुत रूपमा स्विच गर्ने क्षमताको साथ। जुन तपाईंको जडानको लागि महत्वपूर्ण छ। यो हाम्रो लागि एक पटक भन्दा बढी काममा आयो, जब Amazon को अवरुद्ध सुरु भयो; सबैभन्दा खराब अवस्थामा, हामीले तिनीहरू मार्फत S3 ट्राफिक मात्र अनुमति दियौं, तर बिस्तारै यो सबै समाधान भयो।

कसरी रिजर्भ गर्ने... सम्पूर्ण प्रदायक?

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

काल्पनिक रूपमा, अमेजनको लागि हामी अर्को प्रदायकको स्तरमा आरक्षणको सम्भावनालाई विचार गर्दैछौं; हुनसक्छ गुगल, हुनसक्छ अरू कोही... तर अहिलेसम्म हामीले व्यवहारमा अवलोकन गरेका छौं कि अमेजनमा एक उपलब्धता क्षेत्रको स्तरमा दुर्घटनाहरू भए पनि सम्पूर्ण क्षेत्रको स्तरमा दुर्घटनाहरू एकदमै दुर्लभ छन्। त्यसकारण, हामीसँग सैद्धान्तिक रूपमा विचार छ कि हामीले "Amazon is not Amazon" आरक्षण बनाउन सक्छौं, तर व्यवहारमा यो अहिलेसम्म भएको छैन।

स्वचालन बारे केही शब्दहरू

के स्वचालन सधैं आवश्यक छ? यहाँ यो Dunning-Kruger प्रभाव सम्झना उपयुक्त छ। "x" अक्षमा हाम्रो ज्ञान र अनुभव हो जुन हामीले प्राप्त गर्छौं, र "y" अक्षमा हाम्रो कार्यहरूमा विश्वास छ। सुरुमा हामीलाई केहि थाहा छैन र निश्चित छैन। त्यसोभए हामी थोरै थाहा पाउँछौं र मेगा-आत्मविश्वास बनाउँछौं - यो तथाकथित "मूर्खताको शिखर" हो, चित्र "डिमेन्सिया र साहस" द्वारा राम्रोसँग चित्रण गरिएको छ। त्यसपछि हामीले थोरै सिकेका छौं र युद्धमा जान तयार छौं। त्यसपछि हामी केही महा-गम्भीर गल्तीहरूमा कदम चाल्छौं र आफूलाई निराशाको उपत्यकामा फेला पार्छौं, जब हामीलाई केहि थाहा छ जस्तो लाग्छ, तर वास्तवमा हामी धेरै जान्दैनौं। त्यसपछि, जब हामीले अनुभव प्राप्त गर्छौं, हामी थप विश्वस्त हुन्छौं।

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

निष्कर्षमा

७ वर्षको दौडान, हामी यो तथ्यबाट गयौं कि जब केहि खस्यो, त्यहाँ आतंक-आतंक थियो, समस्याहरू अवस्थित छैनन्, त्यहाँ केवल कार्यहरू छन्, तिनीहरू समाधान गर्नुपर्दछ - र गर्न सकिन्छ। जब तपाइँ सेवा निर्माण गर्दै हुनुहुन्छ, यसलाई माथिबाट हेर्नुहोस्, हुन सक्ने सबै जोखिमहरू मूल्याङ्कन गर्नुहोस्। यदि तपाईंले तिनीहरूलाई तुरुन्तै देख्नुभयो भने, त्यसपछि रिडन्डन्सीको लागि अग्रिम प्रदान गर्नुहोस् र गल्ती-सहिष्णु पूर्वाधार निर्माण गर्ने सम्भावना, किनकि कुनै पनि बिन्दु जसले असफल हुन सक्छ र सेवाको असक्षमता निम्त्याउँछ निश्चित रूपमा त्यसो गर्नेछ। र यदि यो तपाईंलाई लाग्दछ कि पूर्वाधारका केही तत्वहरू निश्चित रूपमा असफल हुनेछैनन् - समान s7 जस्तै, अझै पनि तिनीहरूले गर्न सक्छन् भनेर ध्यान राख्नुहोस्। र कम्तिमा सिद्धान्तमा, यदि केहि भयो भने तपाईले उनीहरूसँग के गर्नुहुन्छ भन्ने एक विचार राख्नुहोस्। जोखिम व्यवस्थापन योजना बनाउनुहोस्। जब तपाईं स्वचालित रूपमा वा म्यानुअल रूपमा सबै कुरा गर्ने बारे सोच्दै हुनुहुन्छ, जोखिमहरू मूल्याङ्कन गर्नुहोस्: के हुन्छ यदि स्वचालनले सबै चीजहरू स्विच गर्न थाल्छ भने - के यसले दुर्घटनाको तुलनामा अझ खराब अवस्थाको नेतृत्व गर्दैन? सायद कतै स्वचालनको प्रयोग र ड्यूटीमा इन्जिनियरको प्रतिक्रियाको बीचमा उचित सम्झौता प्रयोग गर्न आवश्यक छ, जसले वास्तविक चित्रको मूल्याङ्कन गर्नेछ र बुझ्नेछ कि केहि स्थानमा स्विच गर्न आवश्यक छ वा "हो, तर अहिले होइन।"

पूर्णतावाद र वास्तविक प्रयास, समय, पैसा बीचको उचित सम्झौता जुन तपाईंले योजनामा ​​खर्च गर्न सक्नुहुन्छ जुन तपाईंसँग अन्ततः हुनेछ।

यो पाठ सम्मेलनमा अलेक्जेन्डर डेमिडोभको रिपोर्टको अद्यावधिक र विस्तारित संस्करण हो अपटाइम दिन 4.

स्रोत: www.habr.com