Bitrix24: "जे पटकन वर येते ते पडलेले मानले जात नाही"

आज, Bitrix24 सेवेमध्ये शेकडो गीगाबिट रहदारी नाही किंवा त्यात सर्व्हरचा मोठा ताफा नाही (जरी, अर्थातच, तेथे बरेच काही अस्तित्वात आहेत). परंतु बर्‍याच क्लायंटसाठी हे कंपनीमध्ये काम करण्याचे मुख्य साधन आहे; हे एक वास्तविक व्यवसाय-गंभीर अनुप्रयोग आहे. त्यामुळे पडायला मार्ग नाही. क्रॅश झाला तर काय, परंतु सेवा इतक्या लवकर "पुनर्प्राप्त" झाली की कोणाच्याही लक्षात आले नाही? आणि कामाची गुणवत्ता आणि ग्राहकांची संख्या न गमावता फेलओव्हरची अंमलबजावणी करणे कसे शक्य आहे? Bitrix24 मधील क्लाउड सेवांचे संचालक, अलेक्झांडर डेमिडोव्ह यांनी आमच्या ब्लॉगसाठी उत्पादनाच्या अस्तित्वाच्या 7 वर्षांमध्ये आरक्षण प्रणाली कशी विकसित झाली आहे याबद्दल सांगितले.

“आम्ही 24 वर्षांपूर्वी SaaS म्हणून Bitrix7 लाँच केले. मुख्य अडचण कदाचित खालील होती: SaaS म्हणून सार्वजनिकपणे लॉन्च करण्यापूर्वी, हे उत्पादन फक्त बॉक्स्ड सोल्यूशनच्या स्वरूपात अस्तित्वात होते. ग्राहकांनी ते आमच्याकडून विकत घेतले, त्यांच्या सर्व्हरवर होस्ट केले, कॉर्पोरेट पोर्टल सेट केले - कर्मचारी संप्रेषण, फाइल स्टोरेज, कार्य व्यवस्थापन, CRM, इतकेच. आणि 2012 पर्यंत, आम्ही ठरवले की आम्हाला ते SaaS म्हणून लाँच करायचे आहे, ते स्वतः प्रशासित करायचे आहे, दोष सहिष्णुता आणि विश्वासार्हता सुनिश्चित करायची आहे. आम्ही वाटेत अनुभव मिळवला, कारण तोपर्यंत आमच्याकडे ते नव्हते - आम्ही फक्त सॉफ्टवेअर उत्पादक होतो, सेवा प्रदाता नाही.

सेवा लाँच करताना, आम्हाला समजले की सर्वात महत्वाची गोष्ट म्हणजे दोष सहिष्णुता, विश्वासार्हता आणि सेवेची सतत उपलब्धता सुनिश्चित करणे, कारण जर तुमच्याकडे साधी सामान्य वेबसाइट असेल, उदाहरणार्थ स्टोअर असेल आणि ती तुमच्यावर पडेल आणि तिथे बसेल. एक तास, फक्त तुम्हाला त्रास होतो, तुम्ही ऑर्डर गमावता, तुम्ही क्लायंट गमावता, परंतु स्वतः तुमच्या क्लायंटसाठी, हे त्याच्यासाठी फारसे गंभीर नाही. तो नक्कीच अस्वस्थ होता, परंतु त्याने जाऊन ते दुसर्या साइटवर विकत घेतले. आणि जर हा असा अनुप्रयोग असेल ज्यावर कंपनीमधील सर्व कार्ये, संप्रेषणे, निर्णय बद्ध आहेत, तर सर्वात महत्वाची गोष्ट म्हणजे वापरकर्त्यांचा विश्वास संपादन करणे, म्हणजे त्यांना निराश न करणे आणि पडणे न देणे. कारण आतून काहीतरी काम न केल्यास सर्व काम थांबू शकते.

Bitrix.24 SaaS म्हणून

आम्ही 2011 मध्ये सार्वजनिक प्रक्षेपणाच्या एक वर्ष आधी पहिला प्रोटोटाइप एकत्र केला. आम्ही ते एका आठवड्यात एकत्र केले, ते पाहिले, ते फिरवले - ते अगदी कार्यरत होते. म्हणजेच, तुम्ही फॉर्ममध्ये जाऊ शकता, तेथे पोर्टलचे नाव प्रविष्ट करा, एक नवीन पोर्टल उघडेल आणि वापरकर्ता आधार तयार होईल. आम्ही ते पाहिले, तत्त्वानुसार उत्पादनाचे मूल्यांकन केले, ते स्क्रॅप केले आणि वर्षभर ते परिष्कृत करणे सुरू ठेवले. कारण आमच्याकडे एक मोठे कार्य होते: आम्हाला दोन भिन्न कोड बेस बनवायचे नव्हते, आम्हाला वेगळ्या पॅकेज केलेले उत्पादन, वेगळ्या क्लाउड सोल्यूशन्सचे समर्थन करायचे नव्हते - आम्हाला हे सर्व एकाच कोडमध्ये करायचे होते.

त्या वेळी एक सामान्य वेब ऍप्लिकेशन एक सर्व्हर होता ज्यावर काही PHP कोड चालतो, एक mysql डेटाबेस, फाइल्स अपलोड केल्या जातात, दस्तऐवज, चित्रे अपलोड फोल्डरमध्ये ठेवली जातात - बरं, हे सर्व कार्य करते. अरेरे, याचा वापर करून गंभीरपणे स्थिर वेब सेवा सुरू करणे अशक्य आहे. तेथे, वितरित कॅशे समर्थित नाही, डेटाबेस प्रतिकृती समर्थित नाही.

आम्‍ही आवश्‍यकता तयार केली आहे: ही विविध ठिकाणी असण्‍याची क्षमता आहे, प्रतिकृतीला समर्थन देण्‍याची आणि आदर्शपणे विविध भौगोलिक दृष्ट्या वितरीत डेटा केंद्रात असण्‍याची क्षमता आहे. उत्पादन तर्कशास्त्र आणि खरं तर, डेटा स्टोरेज वेगळे करा. लोडनुसार डायनॅमिकली स्केल करण्यास सक्षम व्हा आणि स्टॅटिक्स पूर्णपणे सहन करा. या विचारांतून, खरं तर, उत्पादनाच्या आवश्यकता उद्भवल्या, ज्या आम्ही वर्षभरात परिष्कृत केल्या. या वेळी, प्लॅटफॉर्ममध्ये, जे एकत्रित झाले - बॉक्स्ड सोल्यूशन्ससाठी, आमच्या स्वतःच्या सेवेसाठी - आम्हाला आवश्यक असलेल्या गोष्टींसाठी आम्ही समर्थन केले. उत्पादनाच्या स्तरावरच mysql प्रतिकृतीसाठी समर्थन: म्हणजेच, कोड लिहिणारा विकसक त्याच्या विनंत्या कशा वितरित केल्या जातील याचा विचार करत नाही, तो आमचा एपीआय वापरतो आणि मास्टर्स दरम्यान विनंत्या लिहिणे आणि वाचणे योग्यरित्या कसे वितरित करावे हे आम्हाला माहित आहे. आणि गुलाम.

आम्ही विविध क्लाउड ऑब्जेक्ट स्टोरेजसाठी उत्पादन स्तरावर समर्थन केले आहे: google स्टोरेज, amazon s3, तसेच ओपन स्टॅक स्विफ्टसाठी समर्थन. म्हणून, आमच्यासाठी सेवा म्हणून आणि पॅकेज केलेल्या सोल्यूशनसह काम करणार्‍या विकासकांसाठी हे दोन्ही सोयीस्कर होते: जर त्यांनी आमचा एपीआय फक्त कामासाठी वापरला, तर फाईल शेवटी कुठे सेव्ह केली जाईल याचा ते विचार करत नाहीत, स्थानिकरित्या फाइल सिस्टमवर किंवा ऑब्जेक्ट फाइल स्टोरेजमध्ये.

परिणामी, आम्ही ताबडतोब निर्णय घेतला की आम्ही संपूर्ण डेटा सेंटरच्या स्तरावर आरक्षित करू. 2012 मध्ये, आम्ही पूर्णपणे Amazon AWS वर लॉन्च केले कारण आम्हाला या प्लॅटफॉर्मचा अनुभव आधीच होता - आमची स्वतःची वेबसाइट तिथे होस्ट केली गेली होती. प्रत्येक प्रदेशात Amazon कडे अनेक उपलब्धता झोन आहेत या वस्तुस्थितीमुळे आम्ही आकर्षित झालो होतो - खरं तर, (त्यांच्या शब्दावलीत) अनेक डेटा सेंटर्स जे एकमेकांपासून कमी-अधिक प्रमाणात स्वतंत्र आहेत आणि आम्हाला संपूर्ण डेटा सेंटरच्या स्तरावर आरक्षित करण्याची परवानगी देतात: जर ते अचानक अयशस्वी झाले, तर डेटाबेस मास्टर-मास्टरची प्रतिकृती बनवल्या जातात, वेब ऍप्लिकेशन सर्व्हरचा बॅकअप घेतला जातो आणि स्थिर डेटा s3 ऑब्जेक्ट स्टोरेजमध्ये हलविला जातो. लोड संतुलित आहे - त्या वेळी Amazon elb द्वारे, परंतु थोड्या वेळाने आम्ही आमच्या स्वतःच्या लोड बॅलन्सर्सकडे आलो, कारण आम्हाला अधिक जटिल तर्काची आवश्यकता होती.

त्यांना जे हवे होते तेच मिळाले...

सर्व मूलभूत गोष्टी ज्या आम्हाला सुनिश्चित करायच्या होत्या - स्वतः सर्व्हरची दोष सहिष्णुता, वेब अनुप्रयोग, डेटाबेस - सर्वकाही चांगले कार्य केले. सर्वात सोपी परिस्थिती: जर आमच्या वेब ऍप्लिकेशन्सपैकी एक अयशस्वी झाला, तर सर्वकाही सोपे आहे - ते संतुलित करण्यापासून बंद केले आहेत.

बॅलन्सरने (त्यावेळी ते अॅमेझॉनचे एल्ब होते) अस्वास्थ्यकर नसलेल्या मशीनला चिन्हांकित केले आणि त्यांच्यावर लोड वितरण बंद केले. ऍमेझॉन ऑटोस्केलिंगने कार्य केले: जेव्हा भार वाढला, ऑटोस्केलिंग गटामध्ये नवीन मशीन जोडल्या गेल्या, लोड नवीन मशीनवर वितरित केले गेले - सर्व काही ठीक होते. आमच्या बॅलन्सर्ससह, तर्कशास्त्र अंदाजे समान आहे: ऍप्लिकेशन सर्व्हरला काही घडल्यास, आम्ही त्यातून विनंत्या काढून टाकतो, ही मशीन बाहेर टाकतो, नवीन सुरू करतो आणि कार्य करणे सुरू ठेवतो. ही योजना गेल्या काही वर्षांत थोडी बदलली आहे, परंतु ते कार्य करत आहे: हे सोपे, समजण्यासारखे आहे आणि त्यात कोणतीही अडचण नाही.

आम्ही जगभर काम करतो, ग्राहकांच्या भाराची शिखरे पूर्णपणे भिन्न आहेत, आणि, मैत्रीपूर्ण मार्गाने, आम्ही आमच्या सिस्टमच्या कोणत्याही घटकांवर कोणत्याही वेळी विशिष्ट सेवा कार्य करण्यास सक्षम असायला हवे - ग्राहकांचे लक्ष न देता. म्हणून, आमच्याकडे ऑपरेशनमधून डेटाबेस बंद करण्याची संधी आहे, लोडचे दुसऱ्या डेटा सेंटरवर पुनर्वितरण करणे.

हे सर्व कसे कार्य करते? — आम्ही ट्रॅफिकला कार्यरत डेटा सेंटरवर स्विच करतो - जर डेटा सेंटरवर अपघात झाला असेल, तर पूर्णपणे, जर हे आमचे एका डेटाबेससह नियोजित काम असेल, तर आम्ही या क्लायंटना सेवा देणार्‍या रहदारीचा काही भाग निलंबित करून दुसऱ्या डेटा सेंटरवर स्विच करतो. त्याची प्रतिकृती. वेब ऍप्लिकेशन्ससाठी नवीन मशीन्सची आवश्यकता असल्यास, कारण दुसऱ्या डेटा सेंटरवरील लोड वाढला आहे, ते आपोआप सुरू होतील. आम्ही काम पूर्ण करतो, प्रतिकृती पुनर्संचयित केली जाते आणि आम्ही संपूर्ण भार परत करतो. जर आम्हाला दुसऱ्या डीसीमध्ये काही काम मिरर करायचे असेल, उदाहरणार्थ, सिस्टम अपडेट्स स्थापित करा किंवा दुसऱ्या डेटाबेसमध्ये सेटिंग्ज बदला, तर, सर्वसाधारणपणे, आम्ही त्याच गोष्टीची पुनरावृत्ती करतो, फक्त दुसऱ्या दिशेने. आणि जर हा अपघात असेल तर आम्ही सर्वकाही क्षुल्लकपणे करतो: आम्ही मॉनिटरिंग सिस्टममध्ये इव्हेंट-हँडलर्स यंत्रणा वापरतो. जर अनेक तपासण्या ट्रिगर झाल्या आणि स्थिती गंभीर झाली, तर आम्ही हा हँडलर चालवतो, एक हँडलर जो हे किंवा ते तर्क कार्यान्वित करू शकतो. प्रत्येक डेटाबेससाठी, आम्ही निर्दिष्ट करतो की कोणता सर्व्हर त्याच्यासाठी फेलओव्हर आहे आणि ते अनुपलब्ध असल्यास रहदारी कुठे स्विच करणे आवश्यक आहे. ऐतिहासिकदृष्ट्या, आम्ही नागीओस किंवा त्याचे काही काटे एका किंवा दुसर्या स्वरूपात वापरतो. तत्वतः, जवळजवळ कोणत्याही देखरेख प्रणालीमध्ये समान यंत्रणा अस्तित्वात आहे; आम्ही अद्याप काहीही अधिक जटिल वापरत नाही, परंतु कदाचित एखाद्या दिवशी आम्ही करू. आता अनुपलब्धतेमुळे मॉनिटरिंग सुरू झाले आहे आणि काहीतरी स्विच करण्याची क्षमता आहे.

आम्ही सर्व काही राखून ठेवले आहे का?

आमच्याकडे यूएसए मधून बरेच क्लायंट आहेत, युरोपचे बरेच क्लायंट आहेत, बरेच क्लायंट जे पूर्वेला जवळ आहेत - जपान, सिंगापूर वगैरे. अर्थात, ग्राहकांचा मोठा वाटा रशियामध्ये आहे. म्हणजेच काम एका प्रदेशात होत नाही. वापरकर्त्यांना द्रुत प्रतिसाद हवा आहे, विविध स्थानिक कायद्यांचे पालन करण्यासाठी आवश्यकता आहेत आणि प्रत्येक प्रदेशात आम्ही दोन डेटा केंद्रे राखून ठेवतो, तसेच काही अतिरिक्त सेवा आहेत, ज्या पुन्हा एका प्रदेशात ठेवण्यासाठी सोयीस्कर आहेत - जे ग्राहक हा प्रदेश कार्यरत आहे. REST हँडलर्स, ऑथोरायझेशन सर्व्हर, ते संपूर्णपणे क्लायंटच्या ऑपरेशनसाठी कमी गंभीर आहेत, आपण त्यांच्याद्वारे थोड्या स्वीकारार्ह विलंबाने स्विच करू शकता, परंतु आपण त्यांचे निरीक्षण कसे करावे आणि काय करावे याबद्दल चाक पुन्हा शोधू इच्छित नाही. त्यांच्या सोबत. म्हणून, आम्ही अतिरिक्त उत्पादनांमध्ये काही प्रकारची क्षमता विकसित करण्याऐवजी विद्यमान उपाय जास्तीत जास्त वापरण्याचा प्रयत्न करीत आहोत. आणि कुठेतरी आम्ही क्षुल्लकपणे DNS स्तरावर स्विचिंगचा वापर करतो आणि त्याच DNS द्वारे आम्ही सेवेची सजीवता निर्धारित करतो. Amazon कडे रूट 53 सेवा आहे, परंतु ती फक्त DNS नाही ज्यामध्ये तुम्ही एंट्री करू शकता आणि तेच आहे—ती अधिक लवचिक आणि सोयीस्कर आहे. त्याद्वारे तुम्ही भौगोलिक स्थानांसह भौगोलिक-वितरित सेवा तयार करू शकता, जेव्हा तुम्ही क्लायंट कोठून आला हे निर्धारित करण्यासाठी आणि त्याला काही नोंदी देण्यासाठी वापरता - त्याच्या मदतीने तुम्ही फेलओव्हर आर्किटेक्चर तयार करू शकता. तीच आरोग्य-तपासणी मार्ग 53 मध्येच कॉन्फिगर केली आहे, तुम्ही निरीक्षण केले जाणारे एंडपॉइंट सेट करता, मेट्रिक्स सेट करता, सेवेची “लाइव्हनेस” ठरवण्यासाठी कोणते प्रोटोकॉल सेट करता - tcp, http, https; तपासणीची वारंवारता सेट करा जी सेवा जिवंत आहे की नाही हे निर्धारित करते. आणि DNS मध्येच तुम्ही निर्दिष्ट करता की काय प्राथमिक असेल, काय दुय्यम असेल, मार्ग 53 मध्ये आरोग्य-तपासणी सुरू झाल्यास कुठे स्विच करावे. हे सर्व काही इतर साधनांसह केले जाऊ शकते, परंतु ते सोयीचे का आहे - आम्ही ते सेट करतो एकदा उठून मग आपण तपासण्या कशा करतो, कसे स्विच करतो याचा अजिबात विचार करू नका: प्रत्येक गोष्ट स्वतःच कार्य करते.

पहिला "पण": मार्ग 53 कसा आणि कशाने आरक्षित करायचा? कुणास ठाऊक, त्याला काही झालं तर? सुदैवाने, आम्ही या रेकवर कधीही पाऊल टाकले नाही, परंतु आम्हाला अजूनही आरक्षण करण्याची आवश्यकता का आहे असे आम्हाला वाटले याची एक कथा माझ्यापुढे आहे. येथे आम्ही आगाऊ स्वतःसाठी पेंढा घातला. दिवसातून अनेक वेळा आम्ही मार्ग 53 मध्ये असलेल्या सर्व झोनचे संपूर्ण अनलोड करतो. Amazon चे API तुम्हाला ते JSON मध्ये सहजपणे पाठवण्याची परवानगी देते आणि आमच्याकडे अनेक बॅकअप सर्व्हर आहेत जिथे आम्ही ते रूपांतरित करतो, कॉन्फिगच्या स्वरूपात अपलोड करतो आणि साधारणपणे बोलायचे झाल्यास, बॅकअप कॉन्फिगरेशन आहे. काही घडल्यास, आम्ही DNS सेटिंग्ज डेटा न गमावता ते व्यक्तिचलितपणे उपयोजित करू शकतो.

दुसरा "पण": या चित्रात अजून काय राखून ठेवलेले नाही? बॅलन्सर स्वतःच! आमच्या ग्राहकांचे प्रदेशानुसार वितरण अतिशय सोपे केले आहे. आमच्याकडे bitrix24.ru, bitrix24.com, .de ही डोमेन आहेत - आता 13 भिन्न आहेत, जे विविध झोनमध्ये कार्यरत आहेत. आम्ही खालील गोष्टींकडे आलो: प्रत्येक प्रदेशाचे स्वतःचे बॅलन्सर आहेत. नेटवर्कवरील पीक लोड कुठे आहे यावर अवलंबून, हे सर्व प्रदेशांमध्ये वितरित करणे अधिक सोयीस्कर बनवते. जर हे एकाच बॅलन्सरच्या पातळीवर अपयशी ठरले तर ते फक्त सेवेतून काढून टाकले जाते आणि डीएनएसमधून काढले जाते. बॅलन्सर्सच्या गटामध्ये काही समस्या असल्यास, इतर साइट्सवर त्यांचा बॅकअप घेतला जातो, आणि त्यांच्या दरम्यान स्विच करणे समान मार्ग53 वापरून केले जाते, कारण लहान TTL मुळे, स्विचिंग जास्तीत जास्त 2, 3, 5 मिनिटांत होते. .

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

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

आम्ही ते अगदी सोप्या पद्धतीने केले: जर आमचा ट्रिगर फायर झाला, तर आम्ही कोड कार्यान्वित करतो जो ऑब्जेक्टला Mail.ru स्टोरेजमध्ये कॉपी करेल. डेटाच्या स्थानिक प्रतींसह कार्य पूर्णपणे लॉन्च करण्यासाठी, आम्हाला रिव्हर्स सिंक्रोनाइझेशन देखील आवश्यक आहे जेणेकरुन रशियन विभागातील क्लायंट त्यांच्या जवळ असलेल्या स्टोरेजसह कार्य करू शकतील. मेल त्याच्या स्टोरेजमध्ये ट्रिगर पूर्ण करणार आहे - पायाभूत सुविधा स्तरावर रिव्हर्स सिंक्रोनाइझेशन करणे शक्य होईल, परंतु आत्ता आम्ही हे आमच्या स्वतःच्या कोडच्या स्तरावर करत आहोत. जर आपल्याला दिसले की क्लायंटने फाइल पोस्ट केली आहे, तर कोड स्तरावर आम्ही इव्हेंटला रांगेत ठेवतो, त्यावर प्रक्रिया करतो आणि उलट प्रतिकृती करतो. ते वाईट का आहे: जर आम्ही आमच्या उत्पादनाच्या बाहेर आमच्या वस्तूंसह काही प्रकारचे काम केले, म्हणजे, काही बाह्य मार्गांनी, आम्ही ते विचारात घेणार नाही. म्हणून, आम्ही शेवटपर्यंत प्रतीक्षा करतो, जेव्हा स्टोरेज स्तरावर ट्रिगर दिसतात, जेणेकरून आम्ही कोड कोठून कार्यान्वित करतो हे महत्त्वाचे नाही, आमच्याकडे आलेली ऑब्जेक्ट दुसऱ्या दिशेने कॉपी केली जाईल.

कोड स्तरावर, आम्ही प्रत्येक क्लायंटसाठी दोन्ही स्टोरेजची नोंदणी करतो: एक मुख्य मानले जाते, दुसरे बॅकअप मानले जाते. सर्व काही ठीक असल्यास, आम्ही आमच्या जवळ असलेल्या स्टोरेजसह कार्य करतो: म्हणजेच आमचे क्लायंट जे Amazon मध्ये आहेत, ते S3 सह काम करतात आणि जे रशियामध्ये काम करतात ते Hotbox सोबत काम करतात. ध्वज ट्रिगर झाल्यास, फेलओव्हर कनेक्ट केले जावे आणि आम्ही क्लायंटला दुसर्‍या स्टोरेजवर स्विच करू. आम्ही हा बॉक्स स्वतंत्रपणे प्रदेशानुसार तपासू शकतो आणि त्यांना पुढे आणि मागे बदलू शकतो. आम्ही अद्याप हे व्यवहारात वापरलेले नाही, परंतु आम्ही ही यंत्रणा प्रदान केली आहे आणि आम्हाला वाटते की एखाद्या दिवशी आम्हाला हे स्विच आवश्यक असेल आणि ते उपयोगी पडेल. हे यापूर्वीही एकदा घडले आहे.

अरे, आणि Amazon पळून गेला...

या एप्रिलमध्ये रशियामध्ये टेलिग्राम ब्लॉकिंग सुरू झाल्याची वर्धापन दिन आहे. या अंतर्गत सर्वात प्रभावित प्रदाता अॅमेझॉन आहे. आणि, दुर्दैवाने, संपूर्ण जगासाठी काम करणाऱ्या रशियन कंपन्यांना अधिक त्रास सहन करावा लागला.

जर कंपनी जागतिक आहे आणि रशिया त्याच्यासाठी खूप लहान विभाग आहे, 3-5% - ठीक आहे, एक मार्ग किंवा दुसरा, आपण त्यांचा त्याग करू शकता.

जर ही पूर्णपणे रशियन कंपनी असेल - मला खात्री आहे की ती स्थानिक पातळीवर स्थित असणे आवश्यक आहे - बरं, ते वापरकर्त्यांसाठी सोयीस्कर असेल, आरामदायक असेल आणि कमी जोखीम असतील.

जर ही कंपनी जागतिक स्तरावर कार्यरत असेल आणि रशिया आणि जगभरातील जवळपास समान संख्येने ग्राहक असतील तर? सेगमेंट्सची कनेक्टिव्हिटी महत्त्वाची आहे, आणि त्यांनी एकमेकांशी एक किंवा दुसर्या मार्गाने कार्य केले पाहिजे.

मार्च 2018 च्या शेवटी, Roskomnadzor ने सर्वात मोठ्या ऑपरेटरना एक पत्र पाठवले की त्यांनी Zello मेसेंजर ब्लॉक करण्यासाठी अनेक दशलक्ष Amazon IPs ब्लॉक करण्याची योजना आखली आहे. या समान प्रदात्यांचे आभार - त्यांनी यशस्वीरित्या प्रत्येकाला पत्र लीक केले आणि अॅमेझॉनशी संबंध तुटू शकतो अशी समज होती. शुक्रवार होता, आम्ही घाबरून आमच्या सहकार्‍यांकडे सर्व्हर.रू वरून धावत गेलो, ते म्हणाले: “मित्रांनो, आम्हाला असे अनेक सर्व्हर हवे आहेत जे रशियामध्ये नसतील, ऍमेझॉनमध्ये नसतील, परंतु, उदाहरणार्थ, अॅमस्टरडॅममध्ये कुठेतरी असतील,” क्रमाने. आम्ही कोणत्याही प्रकारे प्रभावित करू शकत नाही अशा काही एंडपॉइंट्ससाठी आमचे स्वतःचे व्हीपीएन आणि प्रॉक्सी स्थापित करण्यास सक्षम होण्यासाठी, उदाहरणार्थ समान s3 चे एंडपॉन्ट्स - आम्ही नवीन सेवा वाढवण्याचा प्रयत्न करू शकत नाही आणि वेगळा ip मिळवू शकत नाही, आम्हाला तुम्हाला अजून तिथे पोहोचायचे आहे. फक्त काही दिवसात, आम्ही हे सर्व्हर सेट केले, ते सुरू केले आणि चालू केले आणि सर्वसाधारणपणे, ब्लॉकिंग सुरू झाल्याच्या क्षणासाठी तयार झालो. हे उत्सुक आहे की RKN, गडबड आणि घाबरून बघत म्हणाला: "नाही, आम्ही आता काहीही ब्लॉक करणार नाही." (परंतु टेलीग्राम ब्लॉक होण्याच्या क्षणापर्यंत हेच आहे.) बायपास क्षमता स्थापित केल्यावर आणि ब्लॉकिंग सुरू केले गेले नाही हे लक्षात आल्यावर, आम्ही संपूर्ण प्रकरण सोडवण्यास सुरुवात केली नाही. होय, फक्त बाबतीत.

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

कसे आरक्षित करावे... संपूर्ण प्रदाता?

संपूर्ण Amazon खाली गेल्यास सध्या आमच्याकडे परिस्थिती नाही. आपल्याकडे रशियाबाबतही अशीच परिस्थिती आहे. रशियामध्ये, आम्ही एका प्रदात्याद्वारे होस्ट केले होते, ज्यांच्याकडून आम्ही अनेक साइट्स निवडल्या आहेत. आणि एक वर्षापूर्वी आम्हाला एका समस्येचा सामना करावा लागला: जरी ही दोन डेटा केंद्रे असली तरीही, प्रदात्याच्या नेटवर्क कॉन्फिगरेशनच्या पातळीवर आधीच समस्या असू शकतात ज्यामुळे दोन्ही डेटा केंद्रांवर परिणाम होईल. आणि आम्ही दोन्ही साइटवर अनुपलब्ध असू शकतो. अर्थात तेच झाले. आम्ही आतल्या वास्तुकलेचा पुनर्विचार करून संपवला. हे फारसे बदललेले नाही, परंतु रशियासाठी आमच्याकडे आता दोन साइट्स आहेत, ज्या एकाच प्रदात्याच्या नसून दोन भिन्न साइट्सच्या आहेत. एक अयशस्वी झाल्यास, आम्ही दुसऱ्यावर स्विच करू शकतो.

काल्पनिकदृष्ट्या, ऍमेझॉनसाठी आम्ही दुसर्या प्रदात्याच्या स्तरावर आरक्षणाची शक्यता विचारात घेत आहोत; कदाचित Google, कदाचित कोणीतरी... परंतु आतापर्यंत आम्ही सरावाने पाहिले आहे की अॅमेझॉनला एका उपलब्धतेच्या क्षेत्राच्या पातळीवर अपघात होत असताना, संपूर्ण प्रदेशाच्या पातळीवर अपघात फारच दुर्मिळ आहेत. म्हणून, आमची सैद्धांतिकदृष्ट्या अशी कल्पना आहे की आम्ही "Amazon is not Amazon" आरक्षण करू शकतो, परंतु प्रत्यक्षात तसे झालेले नाही.

ऑटोमेशन बद्दल काही शब्द

ऑटोमेशन नेहमी आवश्यक आहे का? येथे डनिंग-क्रुगर प्रभाव आठवणे योग्य आहे. “x” अक्षावर आपण मिळवलेले ज्ञान आणि अनुभव आहे आणि “y” अक्षावर आपल्या कृतींवरील आत्मविश्वास आहे. सुरुवातीला आपल्याला काहीच कळत नाही आणि खात्रीही नसते. मग आपल्याला थोडेसे कळते आणि आत्मविश्वास वाढतो - हे तथाकथित “मूर्खपणाचे शिखर” आहे, जे “स्मृतीभ्रंश आणि धैर्य” या चित्राद्वारे स्पष्ट केले आहे. मग आपण थोडे शिकलो आहोत आणि युद्धात उतरायला तयार आहोत. मग आपण काही मोठ्या-गंभीर चुकांवर पाऊल टाकतो आणि निराशेच्या दरीत स्वतःला सापडतो, जेव्हा आपल्याला काहीतरी माहित आहे असे दिसते, परंतु प्रत्यक्षात आपल्याला फारसे माहित नसते. मग जसजसा अनुभव मिळतो तसतसा आपला आत्मविश्वास वाढतो.

विशिष्ट अपघातांवरील विविध स्वयंचलित स्विचेसबद्दलचे आमचे तर्क या आलेखाद्वारे अतिशय चांगले वर्णन केले आहे. आम्ही सुरुवात केली - आम्हाला काहीही कसे करावे हे माहित नव्हते, जवळजवळ सर्व काम हाताने केले गेले. मग आम्हाला समजले की आम्ही प्रत्येक गोष्टीला ऑटोमेशन जोडू शकतो आणि शांतपणे झोपू शकतो. आणि अचानक आपण मेगा-रेकवर पाऊल ठेवतो: चुकीचे सकारात्मक ट्रिगर केले जाते आणि आपण ट्रॅफिक पुढे-मागे बदलतो जेव्हा, चांगल्या मार्गाने, आपल्याला हे करायला नको होते. परिणामी, प्रतिकृती तुटते किंवा आणखी काही - ही निराशेची दरी आहे. आणि मग आपण समजून घेतो की आपण प्रत्येक गोष्टीकडे शहाणपणाने संपर्क साधला पाहिजे. म्हणजेच, खोट्या अलार्मची शक्यता प्रदान करून ऑटोमेशनवर अवलंबून राहणे अर्थपूर्ण आहे. परंतु! जर परिणाम विनाशकारी असू शकतात, तर ते ड्युटी शिफ्टवर, ड्युटीवर असलेल्या अभियंत्यांवर सोडणे चांगले आहे, जे खरोखरच अपघात झाला आहे की नाही याची खात्री करतील आणि निरीक्षण करतील आणि आवश्यक कृती मॅन्युअली पार पाडतील...

निष्कर्ष

7 वर्षांच्या कालावधीत, आम्ही या वस्तुस्थितीपासून पुढे गेलो की जेव्हा एखादी गोष्ट पडते तेव्हा घाबरणे-घाबरणे होते, समस्या अस्तित्त्वात नसतात, फक्त कार्ये असतात, त्या सोडवल्या पाहिजेत - आणि होऊ शकतात. जेव्हा तुम्ही सेवा तयार करत असाल, तेव्हा ती वरून पहा, घडणाऱ्या सर्व जोखमींचे मूल्यांकन करा. जर तुम्हाला ते लगेच दिसले, तर अगोदरच रिडंडंसी आणि दोष-सहिष्णु पायाभूत सुविधा तयार करण्याची शक्यता प्रदान करा, कारण कोणताही मुद्दा जो अयशस्वी होऊ शकतो आणि सेवेच्या अकार्यक्षमतेस कारणीभूत ठरू शकतो ते निश्चितपणे असे करेल. आणि जरी तुम्हाला असे वाटत असेल की पायाभूत सुविधांचे काही घटक निश्चितपणे अयशस्वी होणार नाहीत - समान s3 प्रमाणे, तरीही ते करू शकतात हे लक्षात ठेवा. आणि किमान सिद्धांतानुसार, जर काही घडले तर आपण त्यांच्याशी काय कराल याची कल्पना करा. जोखीम व्यवस्थापन योजना तयार करा. जेव्हा तुम्ही सर्व काही आपोआप किंवा मॅन्युअली करण्याचा विचार करत असाल, तेव्हा जोखमींचे मूल्यांकन करा: ऑटोमेशनने सर्वकाही बदलण्यास सुरुवात केल्यास काय होईल - यामुळे अपघाताच्या तुलनेत आणखी वाईट परिस्थिती निर्माण होणार नाही का? कदाचित कुठेतरी ऑटोमेशनचा वापर आणि कर्तव्यावर असलेल्या अभियंत्याची प्रतिक्रिया यांच्यात वाजवी तडजोड करणे आवश्यक आहे, जे वास्तविक चित्राचे मूल्यांकन करेल आणि जागेवर काहीतरी स्विच करणे आवश्यक आहे की नाही हे समजेल किंवा "होय, परंतु आता नाही."

परफेक्शनिझम आणि वास्तविक प्रयत्न, वेळ, पैसा यामधील वाजवी तडजोड जे तुम्ही शेवटी तुमच्याकडे असलेल्या योजनेवर खर्च करू शकता.

हा मजकूर कॉन्फरन्समधील अलेक्झांडर डेमिडोव्हच्या अहवालाची अद्ययावत आणि विस्तारित आवृत्ती आहे अपटाइम दिवस 4.

स्त्रोत: www.habr.com