कसरी Uma.Tech ले पूर्वाधार विकास गर्यो

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

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

हामी PREMIER र Match TV लगायत विश्वसनीयता र लोडका लागि सबैभन्दा कडा आवश्यकताहरूको साथ सबैभन्दा जटिल परियोजनाहरूको सञ्चालन सुनिश्चित गर्छौं। खेलकुद प्रसारणहरू र लोकप्रिय टिभि शृङ्खलाहरूको प्रिमियरलाई टेराबिट/सेकेन्डमा ट्राफिक चाहिन्छ, हामी यसलाई सजिलै कार्यान्वयन गर्छौं, र प्रायः यस्तो गतिमा काम गर्ने हाम्रो लागि लामो समयदेखि सामान्य भएको छ। र पाँच वर्ष पहिले, हाम्रो प्रणालीहरूमा चलिरहेको सबैभन्दा ठूलो परियोजना रुट्युब थियो, जुन पछि विकसित भएको छ, भोल्युम र ट्राफिक बढेको छ, जसलाई लोड योजना बनाउँदा ध्यानमा राख्नु पर्ने थियो।

हामीले हाम्रो पूर्वाधारको हार्डवेयर कसरी विकास गर्यौं भन्ने बारेमा कुरा गर्यौं ("Rutube 2009-2015: हाम्रो हार्डवेयर को इतिहास") र भिडियोहरू अपलोड गर्नका लागि जिम्मेवार प्रणाली विकास गरियो ("शून्य देखि 700 गीगाबिट प्रति सेकेन्ड सम्म - कसरी रूस मा सबै भन्दा ठूलो भिडियो होस्टिंग साइटहरु मध्ये एक भिडियो अपलोड गर्दछ"), तर यी पाठहरू लेखिएको धेरै समय बितिसकेको छ, धेरै अन्य समाधानहरू सिर्जना र कार्यान्वयन गरिएको छ, जसको परिणामहरूले हामीलाई आधुनिक आवश्यकताहरू पूरा गर्न र नयाँ कार्यहरूमा अनुकूलन गर्न पर्याप्त लचिलो हुन अनुमति दिन्छ।

नेटवर्क कोर हामी निरन्तर विकास गरिरहेका छौं। हामीले 2015 मा सिस्को उपकरणमा स्विच गर्यौं, जुन हामीले अघिल्लो लेखमा उल्लेख गरेका छौं। पछि यो अझै पनि 10/40G थियो, तर स्पष्ट कारणहरूको लागि, केही वर्ष पछि तिनीहरूले अवस्थित चेसिस अपग्रेड गरे, र अब हामी सक्रिय रूपमा 25/100G प्रयोग गर्दछौं।

100G लिङ्कहरू लामो समयदेखि न विलासिता भएका छन् (बरु, यो हाम्रो खण्डमा समयको तत्काल आवश्यकता हो), न त दुर्लभता (अधिक र अधिक अपरेटरहरूले यस्तो गतिमा जडानहरू प्रदान गर्दछ)। जे होस्, 10/40G सान्दर्भिक रहन्छ: यी लिङ्कहरू मार्फत हामी अपरेटरहरूलाई सानो मात्रामा ट्राफिकसँग जडान गर्न जारी राख्छौं, जसको लागि यो हाल अधिक क्षमतायुक्त पोर्ट प्रयोग गर्न अनुपयुक्त छ।

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

भिडियो आउटपुट सर्भरहरू चाँडै विकसित, जसको लागि हामी धेरै प्रयास प्रस्ताव गर्दछौं। यदि पहिले हामीले मुख्यतया 2U सर्भरहरू 4-5 नेटवर्क कार्डहरू प्रत्येक दुई 10G पोर्टहरू सहित प्रयोग गर्यौं भने, अब धेरै जसो ट्राफिकहरू 1U सर्भरहरूबाट पठाइन्छ, जसमा प्रत्येक दुई 2G पोर्टहरू सहित 3-25 कार्डहरू छन्। 10G र 25G भएका कार्डहरू लागतमा लगभग बराबर छन्, र छिटो समाधानहरूले तपाईंलाई 10G र 25G दुवैमा प्रसारण गर्न अनुमति दिन्छ। नतिजा स्पष्ट बचत थियो: कम सर्भर कम्पोनेन्टहरू र जडानका लागि केबलहरू - कम लागत (र उच्च विश्वसनीयता), कम्पोनेन्टहरूले र्याकमा कम ठाउँ लिन्छन् - यो प्रति एकाइ क्षेत्र बढी सर्भरहरू राख्न सम्भव भयो र त्यसैले, कम भाडा लागत।

तर अधिक महत्त्वपूर्ण गति मा लाभ छ! अब हामी 1U मार्फत 100G भन्दा बढी पठाउन सक्छौं! र यो अवस्थाको पृष्ठभूमिमा हो जहाँ केही ठूला रूसी परियोजनाहरूले 40U बाट 2G आउटपुटलाई "उपलब्धि" भनिन्छ। हामी उनीहरूको समस्या चाहन्छौं!

ध्यान दिनुहोस् कि हामी अझै पनि 10G मा मात्र सञ्चालन गर्न सक्ने नेटवर्क कार्डहरूको उत्पादन प्रयोग गर्छौं। यो उपकरण स्थिर रूपमा काम गर्दछ र हामीलाई धेरै परिचित छ, त्यसैले हामीले यसलाई फ्याँक्यौं, तर यसको लागि नयाँ प्रयोग फेला पार्यो। हामीले भिडियो भण्डारण सर्भरहरूमा यी कम्पोनेन्टहरू स्थापना गर्यौं, जसको लागि एक वा दुई 1G इन्टरफेसहरू प्रभावकारी रूपमा सञ्चालन गर्न पर्याप्त छैनन्; यहाँ 10G कार्डहरू सान्दर्भिक भए।

भण्डारण प्रणालीहरू पनि बढिरहेका छन् । विगत पाँच वर्षहरूमा, तिनीहरू बाह्र-डिस्क (12x HDD 2U) बाट छत्तीस-डिस्क (36x HDD 4U) मा परिवर्तन भएका छन्। कसै-कसैलाई यस्तो क्षमता भएको "शव" प्रयोग गर्न डर लाग्छ, किनकि यदि यस्तो चेसिस असफल भयो भने, त्यहाँ उत्पादकता - वा सञ्चालन क्षमतामा खतरा हुन सक्छ! - सम्पूर्ण प्रणालीको लागि। तर यो हामीसँग हुने छैन: हामीले डेटाको भू-वितरित प्रतिलिपिहरूको स्तरमा ब्याकअप प्रदान गरेका छौं। हामीले चेसिसलाई विभिन्न डाटा सेन्टरहरूमा वितरण गरेका छौं - हामी जम्मा तीनवटा प्रयोग गर्छौं - र यसले चेसिसमा विफलता र साइट खस्दा दुवै समस्याहरूको घटनालाई हटाउँछ।

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

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

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

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

दोस्रो माइग्रेसन एक वर्ष अघि भएको थियो; २०१९ मा, हामी धेरै राम्रो नभएको डाटा सेन्टरबाट O2019xygen मा सारियो। यस कदमको कारणहरू माथि छलफल गरिएकाहरूसँग मिल्दोजुल्दो थिए, तर तिनीहरू टेलिकम अपरेटरहरूको लागि मूल डाटा सेन्टरको अनाकर्षकताको समस्याले पूरै थिए - धेरै प्रदायकहरूले यस बिन्दुमा आफैं "सम्झना" गर्नुपर्‍यो।

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

आज O2xygen पहिले नै एक पूर्ण प्लेटफर्म हो, जहाँ हामीलाई चाहिने अपरेटरहरू "आइपुगे" र नयाँहरू जडान हुन जारी राख्छन्। अपरेटरहरूका लागि, O2xygen रणनीतिक विकासको दृष्टिकोणबाट पनि आकर्षक देखियो।

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

Результаты हामीलाई पञ्चवर्षीय विकास योजना मनपर्छ। हामीले तीनवटा डाटा सेन्टरहरूमा वितरित नयाँ त्रुटि-सहिष्णु पूर्वाधारको निर्माण पूरा गरेका छौं। हामीले ट्राफिक घनत्व तीव्र रूपमा बढाएका छौं - यदि हालै हामी 40U सँग 80-2G सँग खुसी थियौं भने, अब हाम्रो लागि 100U सँग 1G हो। अब एक टेराबिट ट्राफिक पनि हामी द्वारा सामान्य रूपमा बुझिन्छ। हामी हाम्रो पूर्वाधारको थप विकास गर्न तयार छौं, जुन लचिलो र स्केलेबल भएको छ।

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

लेखक: Petr Vinogradov - Uma.Tech को प्राविधिक निर्देशक Hamsters

स्रोत: www.habr.com