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

यह लेख ~~प्रोडक्शन ड्रामा~~ की एक श्रृंखला के बारे में है जिसमें हमने आउटसोर्सिंग के साथ अपनी सेवा को बेहतर बनाया है। हम वास्तविक समस्याओं और निष्कर्षों को साझा करते हैं।

बादल, धुंधले बालों वाले घोड़े ...

^{(इंटरनेट पर कहीं से, मैंने पहली बार इसे यहां देखा था।)}

हमारे सिस्टम पर लोड बहुत असमान है: सबसे पहले, दिन के दौरान लोड 5 बार बदलता है। दूसरे, एक स्पष्ट मौसम है। ग्रीष्मकालीन सत्र की समाप्ति के बाद दैनिक अधिकतम चेक 10 गुना कम हो जाता है! शीतकालीन सत्र इतना उज्ज्वल नहीं है, लेकिन यह भी एक उपहार नहीं है। साथ ही, प्रत्येक बाद के ग्रीष्मकालीन सत्र भारी (चेक की संख्या के संदर्भ में) और पिछले एक के कठिन (नई खोज प्रौद्योगिकियां और कार्यक्षमता) हैं। इसलिए, एक तरफ, मैं संसाधनों की अच्छी आपूर्ति करना चाहता हूं, दूसरी तरफ, गतिविधि में गिरावट के दौरान बहुत अधिक भुगतान न करें। आप एक सत्र में अधिक सर्वरों को तैनात कर सकते हैं, और गर्मियों में खपत संसाधनों की मात्रा को कम कर सकते हैं। जाहिर है, यह केवल क्लाउड प्रदाताओं के मामले में है। इस लेख में, मैं कई क्लाउड प्रदाताओं (AWS, IT Grad, MCS, YC) के साथ बातचीत के विभिन्न पहलुओं के बारे में बात करूँगा। अगर यह किसी को लगता है कि यह आत्मा का रोना है, तो वह बहुत गलत नहीं होगा। तो चलिए!

एडब्ल्यूएस

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

सच है, अमेज़ॅन के साथ संबंधों में मरहम में एक मक्खी भी थी। निम्नलिखित विशेषताएं या असुविधाएँ हैं जो हमारे पास अमेज़ॅन के साथ हैं:

आप किसी ब्राउज़र के माध्यम से वर्चुअल मशीन के कंसोल तक नहीं पहुँच सकते। और कभी-कभी यह सही है कि वास्तव में यहाँ आवश्यक है! एक बार जब हमने गलती से नेटवर्क इंटरफेस को डिलीट कर दिया, और मशीनों में से एक पर एक्सेस खो गया। यह भाग्यशाली था कि किसी को पहले से ही इस तरह की समस्या का सामना करना पड़ा, आधे घंटे में हमने समाधान ढूंढ लिया और सफलतापूर्वक लागू किया। कंसोल के माध्यम से, इस तरह के ऑपरेशन को एक मिनट में किया जा सकता है।
लागत डॉलर में हैं, और हम रूबल में कमाते हैं। तदनुसार, लाभप्रदता डॉलर पर निर्भर करती है।
रूस में कोई डेटा सेंटर नहीं है, जब हमने शुरू किया था तो वह सबसे नज़दीकी आयरलैंड में था। इसका मतलब है एक बड़ा पिंग और डेटा भंडारण पर कुछ प्रतिबंध जो रूसी कानून की आवश्यकताओं के कारण उत्पन्न होते हैं।
Roskomnadzor नियमित रूप से AWS पतों को ब्लॉक करता है। वर्तमान में, विभिन्न साइटों से AWS में अलग-अलग सर्वर की उपलब्धता है। अज्ञात कारणों से, मशीन से कनेक्शन गिर सकता है। आमतौर पर, आईपी एड्रेस, वीपीएन और प्रॉक्सी को बदलने में मदद मिलती है।
अमेज़ॅन रूसी बादलों की तुलना में काफी अधिक महंगा है। सच है, आप एक लचीले बैकअप प्रोग्राम और स्पॉट इंस्टेंस के उपयोग के माध्यम से लागत को कम कर सकते हैं। और हम सक्रिय रूप से दोनों का उपयोग कर रहे हैं। काश, हमने अभी तक घरेलू बादलों में इस तरह की कार्यक्षमता नहीं देखी है (18 फरवरी न्यूजलेटर पर वाईसी ने "बाधित वीएम" की घोषणा की, हम विवरण की प्रतीक्षा कर रहे हैं)।
अपर्याप्त सूचनात्मक संदेशों के साथ समस्या। मशीनों के तीसरी पीढ़ी से 4 वें या 5 वें स्थान पर संक्रमण के दौरान, आभासी हार्डवेयर को गंभीरता से बदल दिया गया, विशेष रूप से, ड्राइव को जोड़ने का तरीका, और मशीन बस प्रकार के परिवर्तन के बाद शुरू नहीं हुई। उदाहरण प्रबंधन इंटरफ़ेस ने एक संक्षिप्त संदेश लौटाया: अपर्याप्त क्षमता। मार्जिन के साथ आवश्यक प्रकार की मशीनें बनाने के लिए पर्याप्त सीमाएं थीं, और लगभग छह महीने तक हमने सीमाओं को बदलने की कीमत पर मुफ्त तकनीकी सहायता को असफल रूप से प्रताड़ित किया। इसने मदद नहीं की नतीजतन, उन्होंने स्वयं समाधान को गुगला दिया - मशीनों का एक मनोरंजक मनोरंजन मदद करता है।
कई बार हमने SSD को छेद करने के लिए मिटा दिया: डिस्क सभी डेटा के साथ सिस्टम से गायब हो गया। यह देखते हुए कि ये पंचांग डिस्क थे, अर्थात जब मशीन बंद हो जाती है तो डेटा खो जाता है, हमने उन पर कुछ अपूरणीय नहीं जमा किया।

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

आईटी ग्रैड 2016

2015 में, हमने फैसला किया कि हमारे लिए अपना लोहा पूरी तरह से त्यागने का समय आ गया है। मैं विशेष रूप से दूसरों पर उपकरणों की विश्वसनीयता पर समस्याओं को रखना चाहता था और अपने स्वयं के विकास की प्रक्रियाओं को बेहतर बनाने पर अधिक ध्यान केंद्रित करना चाहता था। हमारे पूर्वानुमानों के अनुसार, 2016 में हमारे पास अभी हमारे पास पर्याप्त उपकरण थे, और हम इस आग की घटना के लिए एक रिजर्व रखना चाहेंगे। हमने प्रदाता की पसंद को अच्छी तरह से जाना: हमने एक लोड परीक्षण और हमारे लिए महत्वपूर्ण प्रश्नों के साथ एक प्रश्नावली तैयार की और सावधानीपूर्वक पांच प्रदाताओं से चुना: ActiveCloud, Cloud4Y, CloudOne, IT Grad, Softline।

नतीजतन, हमने आईटी ग्रैड क्लाउड का विकल्प चुना। उनके फायदे:

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

2016 में, हम आईटी ग्रैड में चले गए। यहाँ हमारे जीवन के अपूर्ण तीन वर्षों में एक साथ क्या हुआ है:

एक बार हमें समस्या हुई। वास्तव में 21:00 पर प्रदर्शन में एक अजीब गिरावट शुरू हुई। सिस्टम द्वारा किए जाने वाले चेक की संख्या 150 से 20-30 प्रति मिनट तक गिर सकती है, जबकि कुछ घंटों के बाद सब कुछ बहाल हो गया और 600 चेक प्रति मिनट की गति से हल किया गया। हमने घर पर एक सप्ताह तक खोजा, उपयोगकर्ताओं की जाँच की, बॉट और डीडीओ को पकड़ा, लेकिन कुछ भी नहीं मिला। हमने आईटी-ग्रैड के समर्थन की ओर रुख किया, पता चला कि "ओह, और हम यहां बैकअप कर रहे हैं।" नतीजतन, उन्होंने हमें अलग-अलग डिस्क सिस्टम में समस्याओं का एक स्रोत दिया और काम सेट किया।
आमतौर पर (उत्पाद का उपयोग करने की विशेषताएं), एक सत्र के दौरान, हमारा ट्रैफ़िक प्रति सेकंड 100 मेगाबिट से अधिक होता है। यह मूल्य, वैसे, अक्सर कई क्लाउड प्रदाताओं में गैर-आरक्षित चैनल के लिए डिफ़ॉल्ट रूप से सेट किया जाता है। जब हमने पहली बार इस सीमा को पार किया था, तो कई समस्याएं पैदा हुईं: अंतर्निहित एज हमारे उपकरणों पर स्थित प्रवेश बिंदु और क्लाउड में स्थित वेब सर्वर की वर्चुअल मशीन के बीच वीपीएन का सामना नहीं कर सका। जैसी कि उम्मीद थी, वे समर्थन के लिए मुड़ गए, जहां हमें एज पर संसाधन बढ़ाने की पेशकश की गई थी। ठीक है, कोई सवाल नहीं है, हमने उनके कॉन्फ़िगरेशन को छोटे से बड़े में बदल दिया, और चैनल को एक मार्जिन के साथ हमारे चरम यातायात के आकार तक विस्तारित किया। इसने मदद नहीं की सामान्य तौर पर, हम इष्टतम समाधान नहीं ढूंढ सकते थे, मुझे उत्पादन का हिस्सा अन्य साइटों पर ले जाकर यातायात की मात्रा को कम करना था।
IT ग्रैड साइट पर वीपीएन कनेक्शन कभी-कभी 1-2 मिनट के लिए टूट जाता है। ऐसा क्यों होता है के सवाल पर, न तो हम और न ही तकनीकी समर्थन इसका जवाब पा सकते हैं। अभी तक मुझे इस समस्या के साथ रहना है।
संसाधनों को आकार देने का तंत्र खराब काम करता है, दोनों मक्खी और बंद राज्य में। हालाँकि, यह मुझे लगता है कि यह प्लेटफ़ॉर्म वेंडर (VMware) के साथ एक समस्या है। फिर भी, हम पहले से ही इस तथ्य का सामना कर चुके हैं कि सभी एक्सटेंशनों को मज़बूती से लागू करने के लिए, अतिथि मशीन (विंडोज सर्वर 2012 R2) को पुनरारंभ करना आवश्यक था। आकार बदलने के बाद, मशीन ने कई बार बूट नहीं किया। समर्थन एक बार सत्र के दौरान सुबह 2 से 4 बजे तक इस समस्या को ठीक किया - हमारे बहुत ही मौसम। रात में भी गर्म थी!
2016 में, हमारे पास एवरेस्ट जैसा एक विशाल मोनोलिथ था, जिसके लिए बहुत सारे संसाधनों की आवश्यकता थी। इतने सारे कि कभी-कभी हमें दिए गए मेजबान के लिए अनुशंसित अतिथि मशीनों के अधिकतम आकार को पार करने की आवश्यकता होती है। समर्थन ने हमें लगातार वर्चुअल मशीनों के आकार को कम से कम आधे मेजबान के आकार को कम करने के लिए कहा। हमें आईटी ग्रेड के लिए श्रद्धांजलि अर्पित करनी चाहिए - हमें पूरी तरह से इसका उपयोग करने की क्षमता के साथ एक अलग हार्डवेयर पर जाने की पेशकश की गई थी, हालांकि, कुछ अन्य बड़े पैसे के लिए, और क्लाउड का लचीलापन खो गया था।
खपत किए गए संसाधनों की मात्रा को मापने के लिए महीने में एक बार बिलिंग करना हमारे लिए दो बार एक चाल है। शुरुआत में, हमने सीधे तौर पर कम भुगतान करने के लिए एक महीने के 14-15 वें दिन संसाधनों को कम करने के अवसर के बारे में पूछा। हमें सीधे जवाब दिया गया कि यह कैसे काम करता है। पहली बार यह हमारे क्लाउड पर बिक्री के एक हिस्से के हस्तांतरण के दौरान हमें दर्दनाक रूप से मारा। मानव कारक ने काम किया - उन्होंने 14 वीं तक सब कुछ जल्दी से खत्म करने की कोशिश की, फिर उन्होंने इसे उल्लेखनीय रूप से रेक किया। दूसरी बार हमने लगभग 3 वर्षों के सहयोग के बाद यह अवसर लिया, जिसके बाद हमें 5 वें, 15 वें, 20 वें दिन औसतन बिल भेजा गया। फिर मानव कारक ने उनके लिए काम किया - कॉल के बाद यह पता चला कि उन्होंने अपने पक्ष में गलती की है (पुनर्गणना मैन्युअल रूप से की गई थी), माफी मांगी, छूट दी।
एक पूरे के रूप में डिस्क और मशीनों के प्रदर्शन ने घोषित विशेषताओं को पूरा किया। फिर भी, कई बार हम समझ नहीं पाए कि सब कुछ इतनी धीमी गति से क्यों काम कर रहा था, यहां तक कि इंटरफ़ेस भी निर्दयता से धीमा हो गया। समर्थन ने आश्वासन दिया कि सब कुछ क्रम में था और उन्हें उपकरणों के साथ कोई समस्या नहीं थी। वहाँ क्या हुआ - उस समय हमारा सर्वर पड़ोसी होस्ट में चला गया या किसी ने डिस्क सबसिस्टम का बैकअप लिया - यह हमारे लिए एक रहस्य बना हुआ है।
समर्थन के माध्यम से केवल स्वतंत्र रूप से मशीनों के बीच डिस्क को स्विच किया जा सकता है। उपयोग की शुरुआत में, मशीन में विभिन्न प्रकार के डिस्क होना असंभव था, आपको बाहर निकलना था (iSCSI, सांबा और एनएफएस)। कुछ समय बाद, एक मशीन में विभिन्न प्रकार के डिस्क का उपयोग समर्थन के माध्यम से पहले संभव हो गया, और फिर अपने दम पर (जाहिरा तौर पर vCloudDirector में किया गया)। वैसे, वर्चुअलाइजेशन प्रबंधन प्रणाली को अपडेट करना नियमित रूप से होता है। हमें महीने में 1-2 बार एक पत्र प्राप्त होता है जिसमें कहा जाता है कि एक या दो घंटे के लिए वर्चुअल मशीन नियंत्रण प्रणाली तकनीकी कार्य करती है और कुछ समय के लिए अनुपलब्ध रहेगी, मशीनें स्वयं इस समय काम करना जारी रखती हैं।
16 फरवरी, 2018 को, आईटी ग्राउंड में स्थित हमारी बिक्री का एक हिस्सा डेटा सेंटर की बिजली आपूर्ति की समस्याओं के कारण पड़ा था जिसमें उपकरण स्थित था। हमें घटना के बारे में पता चला, हम तकनीकी सहायता से संपर्क नहीं कर सके। मुझे हमारे खाता प्रबंधक को फोन करना था, उन्होंने तुरंत एक मिनट में कहा कि क्या और कैसे, और डिस्कनेक्ट किया गया, जाहिरा तौर पर बाकी को बता रहा था। सुखद से - हम VKontakte के बगल में झूठ बोल रहे थे।

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

मेल क्लाउड समाधान

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

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

उस समय तक, हमारे पास पहले से ही IaC हिस्सा था जो टैरफॉर्म के माध्यम से सभी मशीनों को तैनात करने के लिए तैयार था। MCS ओपनस्टैक था और इसे अच्छी तरह से समर्थन किया गया था! वैसे, तकनीकी समर्थन एक टेलीग्राम चैनल के माध्यम से किया जाता है - "लाइव" संचार और यह स्पष्ट है कि वे मदद करना चाहते हैं। टिकट प्रणाली है, लेकिन हमने अभी तक इसका उपयोग नहीं किया है। तकनीकी सहायता एसएलए टिकट प्रणाली में बनाए गए अनुरोधों को संदर्भित करता है।

दिसंबर 2018 तक, हमने टेराफॉर्म के माध्यम से इन्फ्रास्ट्रक्चर तैनाती स्क्रिप्ट लिखी थी। यह स्थानांतरित करने का समय है। शुरू करने के लिए, हमने निजी ग्राहकों के साथ सिस्टम को स्थानांतरित करने का फैसला किया, जो इस समय आईटी ग्रैड में उपकरणों पर रहते थे। फिर सब कुछ एक फिल्म की तरह है:

7 (), 18:00 . , . 10 (), 10:00 – . 12 () – . 10:00 terraform. , , . 12:00 ansible'. . ! 15:30 . 30 , 16:30. 15:45 . . 15:55 . : , . 16:20 , . , . , - . 17:30 , , . 18:00 . 1,5 .

एक नए प्रयास के साथ अलग-अलग प्रारूपों के साथ पहचानी गई समस्या सामने नहीं आनी चाहिए थी, लेकिन हमने इसे पाया और सिर्फ मामले में इसे ठीक किया।

17 (), . 15:30 . , . 16:00 . . 16:30 , 100%. -? ! 17:00 , , , , iotop, top, ProcessExplorer, PerformanceMonitor. . 21:45 , , , 2000 . 22:00 , .

आईटी ग्रैड पर पुराने ठेस आसानी से उपयोगकर्ता की जाँच के लिए स्थगित मांग को संतुष्ट करते हैं, कोई समस्या नहीं।

अगले दिन (18 दिसंबर), हमें निम्नलिखित का एहसास हुआ:

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

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

एमसीएस के साथ काम करने के दौरान हमने क्या किया:

यहां तक कि चयन के चरण में, हमें डिस्क द्वारा वर्चुअल हार्डवेयर और एसएलए की विशेषताओं के साथ एक टेबल भेजा गया था। प्लसस में से एक यह था कि उन्होंने SSD के लिए 50 IOPS / GB (IT Grad: 30 IOPS / GB) का वादा किया था। अनुबंध अलग हो गया: "पढ़ना: 5000 आईओपीएस, लेखन: 2000 आईओपीएस", और हम इससे चूक गए, हमें इसकी उम्मीद नहीं थी। तालिकाओं समान हैं, अंतर केवल एक ही स्थान पर है! वैसे, हमने डिस्क आकार पर प्रदर्शन निर्भरता नहीं देखी। जब हमने परीक्षण किया, तो यह भी पता चला कि एक बड़ी ड्राइव के साथ, गति कम हो जाती है। ऐसे छोटे संकेतकों का रहस्य यह है कि MCS में जियो-वितरित ceph है, जिसका अर्थ है कि जब तक दूरस्थ नोड का कहना है कि डेटा लिखा गया है, क्लाइंट को यह नहीं बताया जाएगा कि रिकॉर्डिंग पूरी हो गई है। वैसे, किसी को भी ऐसी "बॉक्स से बाहर" विश्वसनीयता नहीं मिलती है, जिसके साथ हमने बात की थी। लेकिन हमारे लिए इस तरह की विश्वसनीयता केवल पहियों में चिपक जाती है! यदि कुछ होता है, तो समस्याएँ उत्पन्न होने पर हमें जल्दी से दूसरे डीसी में जाने की आवश्यकता होती है, और इसलिए हमारी अपनी एसिंक्रोनस प्रतिकृति होती है। हमारे पास डीआरपी है , और हम एक दुर्घटना की स्थिति में डेटा की एक छोटी राशि के नुकसान के लिए तैयार हैं। हमें एमसीएस के लिए श्रद्धांजलि अर्पित करनी चाहिए, उन्होंने स्थानीय एसएसडी सरणी के कमीशन को तेज किया, जिसका प्रदर्शन बहुत अधिक था।
मशीनों के मापदंडों के रूप में, वे मनमाना नहीं हैं। CPU-RAM का एक निश्चित सेट है- {SSD / HDD} (लगभग AWS की तरह), और अन्य प्रकार की मशीनें केवल समर्थन के माध्यम से बनाई जा सकती हैं। पूरी प्रक्रिया में लगभग 2 घंटे लगते हैं, प्रकारों की संख्या की कोई सीमा नहीं है, मुख्य बात यह है कि कोर की संख्या हाइपोवेइज़र ~ 40-48 प्रोसेसर के आधे से अधिक नहीं होनी चाहिए। मशीन निर्माण के दौरान, आप स्वयं डिस्क जोड़ सकते हैं और उन्हें मशीनों के बीच स्विच कर सकते हैं।
स्थानीय एसएसडी को चालू करने के बाद, मशीन के मापदंडों को बदलने से इसे शुरू करना असंभव हो गया। उन्हें केवल समर्थन के माध्यम से लॉन्च किया जा सकता था। एक महीने में कहीं न कहीं उन्होंने समस्या हल कर दी।
पहली बार टेलीग्राम द्वारा तकनीकी सहायता का सामना किया। सामान्य तौर पर, यह सुविधाजनक है, खासकर शुरुआत में, जब बहुत सारे सवाल होते हैं और सेवा में पीसना होता है। लेकिन जितनी दूर, सवाल उतने ही कठिन होते गए और प्रतिक्रिया और सूचना सामग्री की गति धीरे-धीरे कम होती गई। वर्ष के अंत तक, जब, निश्चित रूप से, सभी की समय सीमा समाप्त हो गई थी, प्रतिक्रियाओं की कम गति ने मुझे बहुत प्रभावित किया। कुछ बिंदु पर, उन्होंने SLAs के बारे में भी पूछा। यहीं से समझ में आया कि एसएलए टिकट प्रणाली में है, न कि टेलीग्राम में! 19 फरवरी के समय, इस चैनल में 24 दिसंबर को पूछे गए हमारे कई अनुत्तरित प्रश्न ...
टिकट प्रणाली के माध्यम से तकनीकी सहायता यह ध्यान में नहीं रखती है कि हम लॉग इन हैं, और अनुबंध संख्या की एक अतिरिक्त अधिसूचना की आवश्यकता है। जवाब में, वह एक पत्र "हम आपसे संपर्क करेंगे" भेजता है, लेकिन टिकट संख्या या स्थिति का संकेत नहीं देता है।

एमसीएस के साथ काम करते समय, एक और बादल समानांतर में दिखना शुरू हुआ।

फिर भी एक और बादल (Yandex Cloud)

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

आईटी ग्रेज 2019

सामान्य तौर पर, हम पहले से ही 22 दिसंबर को आगे बढ़ने के लिए एक समय सीमा निर्धारित करते हैं, ताकि एक नए निवास की छिपी समस्याओं को पहचानने और हल करने के लिए एक और सप्ताह हो। MCS और YC के व्यक्ति में नई जानकारी की प्रचुरता से समय सीमा समाप्त होने और थोड़ी थकने की उम्मीद खोने के बाद, हमने फैसला किया कि आईटी ग्रैड उनकी पृष्ठभूमि के खिलाफ इतना बुरा नहीं है। हमने भी थोड़ा उदासीन महसूस किया और सोचा कि नया सब कुछ अच्छी तरह से स्थापित है। पहले से ही आईटी ग्रैड में हम निश्चित रूप से ठीक काम करेंगे - एक मिसाल है। प्लस आईटी ग्रैड ने पंप किया: एक मॉस्को डेटा सेंटर था, टीयर III, इस समय अपटाइम में अभी भी 100% है (कभी भी विफल नहीं हुआ), और अंदर का उपकरण 4-सॉकेट इंटेल एक्सॉन स्केलेबल (42 कोर x 3 तक) है GHz Xeon Gold 6154)। क्या मजाक नहीं है, हम एक दूसरा मौका देंगे!

28 (), 18:10 - vDC , , . 29 ( ), 17:04 , . .iso , . , . , . , . 30 (), 22:00 , .iso, . , - . 31 (), 3:15 Edge vDC vDC. , . . , . 2 (), 15:30 . 2 (), 21:50 , Guest OS Customization . 3 (), 18:05 !

अब, लेख की तैयारी में, उन्होंने पाया कि अनुरोधों और उत्तरों का सही समय टिकट प्रणाली में परिलक्षित नहीं होता है। इसके बजाय, यह कहता है "लगभग 2 महीने पहले," सटीक समय केवल टूलटिप में दिखाया गया है। मेल के द्वारा, घटनाओं के अनुक्रम को पुनर्स्थापित करना भी कठिन है। मेल के संदेश गैर-स्पष्ट तर्क में आते हैं और इसमें कार्रवाई का विवरण नहीं होता है। आईटी ग्रैड तकनीकी सहायता कर्मचारी की ओर से कुछ समय बाद सिस्टम में टिकट बनाए जाते हैं।
छुट्टियों के बाद उपकरण को करीब से देखने के बाद, हमने वहां Xeon v2 देखा। यह वह नहीं है जिस पर हम सहमत थे। ठीक है, हमने यह सवाल खाता प्रबंधक के साथ तय किया। इस तथ्य के कारण कुछ कठिनाइयां थीं कि नए 2019 वर्ष में आईटी ग्रेड को एमटीएस में शामिल किया गया था, और छुट्टियों के ठीक बाद थोड़ा गड़बड़ हो गया था। मास्को डीसी में नए उपकरणों पर नए साल से पहले बनाए गए वीडीसी दिखाई नहीं दे रहे थे। केवल खुले इंटरनेट के माध्यम से, तकनीकी सहायता हमें "प्रसन्न" करती है कि गति की गति 1 टीबी / दिन से अधिक नहीं है। और हमने पहले ही 7TB डेटा अपलोड कर दिया है! नतीजतन, उन्होंने गुरुवार शाम को स्थानांतरित करने के लिए एक आवेदन बनाया। एक दिन बाद, शुक्रवार शाम को, मैंने पूछा कि आप कैसे हैं और वे कब शुरू करने की योजना बना रहे हैं (लगभग एक सप्ताह प्रतीक्षा करें!)। एक दिन बाद, शनिवार की शाम को, हमें बताया गया कि सभी कार चले गए थे। मुझे ऐसा नहीं लगा कि 2.5 दिनों में काम की प्रगति के बारे में कोई जानकारी नहीं थी और इस कदम पर अनुमान बहुत निराशावादी थे।
सितंबर 2018 में, जब हमने IaC को लागू करना शुरू किया, तो हमने महसूस किया कि टेराफॉर्म vCloudDirector के साथ बहुत खराब तरीके से काम करता है (अपडेट: लेखन के समय, हमने सीखा कि VMware vCloud डायरेक्टर प्रोवाइडर 2.0 दिखाई दिया , लेकिन अभी तक ऐसा नहीं किया है)। सबसे पहले, हम इस तथ्य के कारण मशीन भी नहीं बना सके कि vCloud ने हमें "कुछ गलत हो गया है, की भावना में त्रुटि की सूचना दी, आपके पास 512 वर्णों की एक त्रुटि है 136 लाइनें (लाइन छोटी थी!) मशीन के कॉन्फ़िगरेशन की Xml"। हमने समर्थन मांगा। इस सवाल को इंजीनियरों के पास भेज दिया गया, अंत में हमें बताया गया कि टेराफॉर्म का समर्थन नहीं किया गया है - इसे खुद ही सुलझा लें। वैसे भी, हमें पता चला कि पैकर को दोष देना था, जिसके साथ हमने मशीन की छवि एकत्र की, वह मालिकाना वीएमवेयर कॉन्फ़िगरेशन प्रारूप का सामना नहीं कर सका। TerClform vCloudDirector के साथ बहुत खराब है, सब कुछ धीरे-धीरे थ्रेडेड है, और कनेक्टर को लंबे समय तक छोड़ दिया गया है और विकसित नहीं होता है। कोई भी हमें vSphere तक पहुंच नहीं देता। यदि आप VMware पर रहते हैं, तो आपको अपने स्वचालन को उनके एपीआई के माध्यम से देखने की आवश्यकता है।

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

हमने MCS (2 GHz, Xeon v4) और IT Grad (3 GHz, Xeon v2) पर समानांतर में डेवलपर्स द्वारा अनुशंसित सेटिंग्स के साथ एक लोड परीक्षण चलाया - कोर और मेमोरी की संख्या समान है। एमसीएस पर, परीक्षण तेजी से (एक चौथाई से) और चिकनी हो गया (आईटी ग्रैड पर, परीक्षण झटकेदार चला गया, फिर तेजी से, फिर धीमा)।

डिस्क प्रदर्शन तुलना

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

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

हमने SSD डिस्क पर पोस्टग्रेज डेटाबेस के लिए HDD और SSD डिस्क के साथ-साथ tps (लेनदेन प्रति सेकंड) के लिए iops की गिनती की। एमसीएस में दो प्रकार के डिस्क होते हैं: नियमित भू-वितरित सीफ एसएसडी और एचडीडी और स्थानीय (केवल एक डीसी में) एसएसडी (उनका प्रदर्शन कोष्ठक में दिखाया गया है)। जनवरी 2019 में, MCS से मेलिंग में, हमने पढ़ा कि उन्होंने डिस्क प्रदर्शन 20% बढ़ा दिया है, परीक्षण का परिणाम तालिका (MCS 2019) में भी है। फरवरी में, एक और त्वरण की सूचना मिली थी, लेकिन हमने यहां परीक्षण नहीं किया था।

परिणाम:

	HDD, iops		SSD, iops		SSD, tps
	पढ़ना	लिखने	पढ़ना	लिखने	पढ़ो लिखो
मार्स	1336	445	17,196	5729	2000
आईटी ग्रैड	4544	1515	13231	4407	3063
एमसीएस	1185	395	8931 (22857)	2980 (7637)	497 (1,402)
MCS 2019	3229	1080	9334 (22270)	3113 (7418)	463 (1342)
वाईसी	2202	735	5522	1843	1824

परीक्षण पद्धति

iops की गणना 4 fio रन के औसत के रूप में की गई:
/root/fio-2.0.9/fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75

tps, 3 pgbench के औसत के रूप में चलता है:
pgbench -c 10 -j 2 -t 10000 example

स्टैंड का विवरण

मार्स

Xeon v4, 2 GHz ; HDD: ceph, 9x 2Tb ST2000NX0253 के 3 नोड, प्रतिकृति 2; SSD: ceph, 2Tb NVMe Intel DC P4600 पर 3 नोड्स, प्रतिकृति 2

सीपीयू : 4, रैम : 8 जीबी, एचडीडी : 32 जीबी, एसएसडी : 150 जीबी; समानांतर उत्पादन कताई है।

आईटी ग्रैड

Xeon v4 / v2, 2 GHz ; HDD : 0.1 IOPS / GB ; SSD: 30 IOPS / GB

CPU : 4, RAM : 4GB, HDD : 250GB, SSD : 200GB

एमसीएस

Xeon v4; HDD: r / w: 1500/1000 IOPS; SSD: r / w: 5000/2000 IOPS

HDD: CPU : 2, RAM : 4GB, HDD : 50GB

SSD, TPS : CPU : 8, RAM : 16GB, SSD : 600GB

वाईसी

Xeon v4, 2GHz

CPU : 8, RAM : 8GB, HDD : 20GB, SSD : 50GB

वर्ष के लिए TCO अनुमानों की तुलना

हमने TCO को चार विकल्पों में गिना। सापेक्ष मूल्य नीचे दी गई तालिका में दिखाए गए हैं। मुझे कहना होगा कि यह हमारे विशिष्ट मामले के लिए एक गणना है और सब कुछ आपके लिए अलग हो सकता है।

एमसीएस	वाईसी	आईटी ग्रैड	एडब्ल्यूएस
1	1.23	1.37	2.28

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

AWS के साथ मूल्यांकन करने में थोड़ी कठिनाई हुई, जैसे स्मृति के कर्नेल और गीगाबाइट के लिए कोई प्रत्यक्ष लागत नहीं है। हमने 3 न्यूनतम मशीनें c5.large, r5.large और m5.large लीं और एमसीएस की कीमतों पर उनकी लागत की गणना की (आनुपातिक रूप से सीपीयू कोर की लागत बदल रही है, क्योंकि एमसीएस की आवृत्ति 2 गीगाहर्ट्ज़ है)। यह इस तरह से निकला: औसतन, सामान्य एडब्ल्यूएस उदाहरणों की लागत एमसीएस की लागत से 2.5-2.8 गुना अधिक है। AWS वैट के बिना मूल्य प्रकाशित करता है। इसलिए, एडब्ल्यूएस की लागत के लिए हम 20% जोड़ते हैं, औसत वार्षिक डॉलर की दर 70 रूबल है। ईबीएस की कीमतों पर डिस्क को काफी सरल माना जाता है (हम विभिन्न प्रकार के gp2, sc1, st1 का उपयोग करते हैं)। कुछ स्थानों पर हमें i3 परिवार के उदाहरणों से NVMe ड्राइव की आवश्यकता होती है। प्रति गीगाबाइट उनकी कीमत बहुत सरलता से गणना की जाती है: आई 3 और एन 4 एम की राशि से विभाजित आर 4 परिवार के एक अनुरूप प्रोसेसर और मेमोरी उदाहरण के बीच लागत में अंतर। यह 30 दिनों में प्रति गीगाबाइट में 3.1 रूबल निकलता है।

बजट के बारे में बातचीत में भी, मैं सभी क्लाउड प्रदाताओं के लिए प्रति माह एक कोर के लिए विंडोज लाइसेंस की लागत में अंतर को नोट करना चाहूंगा। AWS पर, कोर की संख्या से विभाजित लिनक्स OnDemand और Windows OnDemand इंस्टेंस की लागत के बीच का अंतर लगभग 2,800 रूबल प्रति माह है। वाईसी में, कर्नेल के लिए विंडोज लाइसेंस 3 गुना सस्ता है, एक महीने में लगभग 900 रूबल, और एमसीएस में, लगभग 9 (!) टाइम्स सस्ता है, एक महीने में लगभग 300 रूबल। हम अभी भी विंडोज पर बहुत निर्भर हैं: अब, .net कोर के लिए धन्यवाद, हम रखरखाव की लागत को कम करने के लिए एंटी-प्लाजियरिज़्म क्रॉस-प्लेटफ़ॉर्म बनाना शुरू कर रहे हैं।

वाईसी की कुल लागत में यातायात की लागत भी शामिल है।

निष्कर्ष

बादलों के माध्यम से

एडब्ल्यूएस। वे कहते हैं कि रूस में 4 अच्छे क्लाउड प्रदाता हैं: AWS, GCP, Azure और DO, और ये सभी रूस में नहीं हैं।
पेशेवरों: महान सेवा, उच्च गुणवत्ता वाले आधुनिक उपकरण, EC2 में अच्छी कॉन्फ़िगरेशन, सेवाओं की एक बड़ी संख्या।
विपक्ष: महंगा (प्लस विनिमय दर जोखिम) और रूस में नहीं (ILV, क्षितिज पर महान रूसी फ़ायरवॉल)। मैं वास्तव में चाहता हूं कि हमारे बादल इस उदाहरण का अनुसरण करें।
विशेषताएं: नि : शुल्क तकनीकी सहायता न्यूनतम मुद्दों को हल कर सकती है, लेकिन, ईमानदार होने के लिए, हमने इसे केवल उपयोग सीमाओं का विस्तार करने के लिए संपर्क किया। भुगतान किया, वैसे, खाते के लगभग 10% की लागत।

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

MCS । EC2 सेवाओं के एनालॉग हैं (वहाँ GPU हैं), S3, ECS, RDS, EMR, उनकी अपनी सेवाएं: मशीन लर्निंग, क्लाउड डिजास्टर रिकवरी, क्लाउड बैकअप
पेशेवरों: सस्ती, सक्रिय रूप से विकसित, जीपीयू (टेस्ला वी 100 और ग्रिड के 2) हैं।
विपक्ष: मूल कंपनी से धीमी गति से ड्राइव, नम, बुरे कर्म।
विशेषताएं: शुरुआत में तकनीकी सहायता उपयोगी होती है, बड़ी संख्या में कर्मचारी चालू होते हैं, मदद महसूस की जाती है, लेकिन तब गतिविधि में ध्यान देने योग्य गिरावट होती है (वे 24 दिसंबर से कुछ भी जवाब नहीं देते हैं, मैं लोगों के बारे में भी चिंतित नहीं हूं)।

वाई सी । हमारे पास इस प्रदाता के साथ काम करने का बहुत कम अनुभव है, कुछ भी विशिष्ट कहना मुश्किल है। EC2, S3, RDS, DS, SQS (अल्फा), ELB (अल्फा), उनकी अनूठी सेवाएं: SpeechKit, Translate के एनालॉग हैं।
पेशेवरों: एमसीएस की तुलना में ड्राइव तेज हैं।
विपक्ष: टेराफॉर्म के लिए प्रदाता नम है; ओपन एपी के साथ वर्चुअलाइजेशन शेल का सॉफ्टवेयर समुदाय के लिए बहुत बड़ा नहीं है, जिसका अर्थ है कि अब तक आप केवल टेराफॉर्म के लिए प्रदाता के विकास में वाईसी टीम की ताकत पर भरोसा कर सकते हैं।
विशेषताएं: यातायात के लिए भुगतान करते हैं।

सबक सीखा

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

हम बादलों से क्या चाहते हैं

तकनीकी सहायता से शीघ्र उत्तर। दुर्भाग्य से, हम इसे AWS के रूप में उपयोग नहीं कर सकते, अब तक - बहुत कम जानकारी उपलब्ध है।
मुक्त धन (टेराफॉर्म) के माध्यम से बुनियादी ढांचे की तैनाती के स्वचालन के लिए समर्थन।
प्रदर्शन में भविष्यवाणी। यह बिलिंग, सीपीयू प्रदर्शन, रैम, डिस्क पर लागू होता है।
कार्यात्मक एनालॉग EC2, S3, RDS की उपस्थिति अब। निकट भविष्य में, हमें k8s और GPU गणनाओं के लिए समर्थन की आवश्यकता है (हम पहले से ही AWS पर इसका उपयोग करते हैं)।

बादलों के लिए आगे बढ़ने के अलावा, पिछले कुछ महीनों में हम अन्य क्षेत्रों में रेक को छूने में कामयाब रहे हैं। यह कैसा था - हम थोड़ा बाद में बताएंगे।

इस तरह के दर्द, इस तरह के दर्द, सेवा 1: 0 के रूप में बुनियादी ढाँचा