Uma.Tech ने पायाभूत सुविधा कशा विकसित केल्या

आम्ही नवीन सेवा सुरू केल्या, रहदारी वाढली, सर्व्हर बदलले, नवीन साइट कनेक्ट केल्या आणि डेटा सेंटर पुन्हा तयार केले - आणि आता आम्ही ही कथा सांगू, ज्याची सुरुवात आम्ही तुम्हाला पाच वर्षांपूर्वी केली होती.

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

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

आम्ही आमच्या पायाभूत सुविधांचे हार्डवेअर कसे विकसित केले याबद्दल आम्ही बोललो ("रुट्यूब 2009-2015: आमच्या हार्डवेअरचा इतिहास") आणि व्हिडिओ अपलोड करण्यासाठी जबाबदार प्रणाली विकसित केली ("शून्य ते 700 गीगाबिट प्रति सेकंद - रशियामधील सर्वात मोठ्या व्हिडिओ होस्टिंग साइट्सपैकी एक व्हिडिओ कसा अपलोड करते"), परंतु हे मजकूर लिहिल्यापासून बराच वेळ निघून गेला आहे, इतर अनेक उपाय तयार केले गेले आहेत आणि अंमलात आणले गेले आहेत, ज्याचे परिणाम आम्हाला आधुनिक आवश्यकता पूर्ण करण्यास आणि नवीन कार्यांशी जुळवून घेण्यास पुरेसे लवचिक बनविण्यास अनुमती देतात.

नेटवर्क कोर आपण सतत विकास करत आहोत. आम्ही 2015 मध्ये सिस्को उपकरणांवर स्विच केले, ज्याचा आम्ही मागील लेखात उल्लेख केला आहे. तेव्हा ते अजूनही 10/40G समान होते, परंतु स्पष्ट कारणांमुळे, काही वर्षांनी त्यांनी विद्यमान चेसिस अपग्रेड केले आणि आता आम्ही सक्रियपणे 25/100G वापरतो.

100G लिंक्स फार पूर्वीपासून लक्झरी नाहीत (त्याऐवजी, आमच्या विभागातील ही काळाची तातडीची गरज आहे), किंवा दुर्मिळता (अधिकाधिक ऑपरेटर अशा वेगाने कनेक्शन प्रदान करतात). तथापि, 10/40G संबंधित राहते: या लिंक्सद्वारे आम्ही ऑपरेटरना थोड्या प्रमाणात रहदारीसह कनेक्ट करणे सुरू ठेवतो, ज्यासाठी सध्या अधिक क्षमतेचे पोर्ट वापरणे अयोग्य आहे.

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

व्हिडिओ आउटपुट सर्व्हर त्वरीत विकसित होते, ज्यासाठी आम्ही खूप प्रयत्न करतो. जर पूर्वी आम्ही प्रत्येकी दोन 2G पोर्टसह 4-5 नेटवर्क कार्डांसह मुख्यतः 10U सर्व्हर वापरत असू, तर आता बहुतेक रहदारी 1U सर्व्हरवरून पाठविली जाते, ज्यात प्रत्येकी दोन 2G पोर्टसह 3-25 कार्डे आहेत. 10G आणि 25G कार्ड्सची किंमत जवळजवळ समान आहे आणि वेगवान उपाय तुम्हाला 10G आणि 25G दोन्हीवर प्रसारित करण्याची परवानगी देतात. परिणाम स्पष्ट बचत होते: कनेक्शनसाठी कमी सर्व्हर घटक आणि केबल्स - कमी किंमत (आणि उच्च विश्वासार्हता), घटक रॅकमध्ये कमी जागा घेतात - प्रति युनिट क्षेत्रामध्ये अधिक सर्व्हर ठेवणे शक्य झाले आणि त्यामुळे, भाड्याचा खर्च कमी झाला.

पण त्याहूनही महत्त्वाचं म्हणजे वेग वाढणं! आता आम्ही 1U सह 100G पेक्षा जास्त पाठवू शकतो! आणि हे अशा परिस्थितीच्या पार्श्‍वभूमीवर आहे जिथे काही मोठे रशियन प्रकल्प 40U मधील 2G आउटपुटला "उपलब्ध" म्हणतात. आम्हाला त्यांच्या समस्या आवडतील!

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

स्टोरेज सिस्टम देखील वाढत आहेत. गेल्या पाच वर्षांत, ते बारा-डिस्क (12x HDD 2U) वरून छत्तीस-डिस्क (36x HDD 4U) मध्ये बदलले आहेत. काहींना अशी क्षमता असलेले "मृतदेह" वापरण्याची भीती वाटते, कारण अशी एक चेसिस अयशस्वी झाल्यास, उत्पादनक्षमतेला - किंवा अगदी कार्यक्षमतेला धोका असू शकतो! - संपूर्ण प्रणालीसाठी. परंतु हे आमच्यासोबत होणार नाही: आम्ही डेटाच्या भौगोलिक-वितरित प्रतींच्या स्तरावर बॅकअप प्रदान केला आहे. आम्ही वेगवेगळ्या डेटा सेंटर्सवर चेसिस वितरीत केले आहे - आम्ही एकूण तीन वापरतो - आणि यामुळे चेसिसमध्ये बिघाड झाल्यास आणि साइट पडल्यावर समस्या उद्भवू शकतात.

अर्थात, या दृष्टिकोनाने हार्डवेअर RAID रिडंडंट केले, जे आम्ही सोडून दिले. रिडंडंसी दूर करून, आम्ही एकाच वेळी सोल्यूशन सुलभ करून आणि अपयशाच्या संभाव्य बिंदूंपैकी एक काढून सिस्टम विश्वसनीयता वाढवली. आम्‍ही तुम्‍हाला आठवण करून देतो की आमच्‍या स्टोरेज सिस्‍टम "होममेड" आहेत. आम्ही हे जाणूनबुजून केले आणि आम्ही निकालावर पूर्णपणे समाधानी होतो.

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

दोन वर्षांपूर्वी, आम्ही MMTS-9 मध्ये स्थलांतरित झालो, उच्च-गुणवत्तेची दुरुस्ती, चांगली कूलिंग सिस्टम, स्थिर वीज पुरवठा आणि धूळ नसलेल्या साइटवर गेलो, जे पूर्वी सर्व पृष्ठभागांवर जाड थरांमध्ये होते आणि आमच्या उपकरणांच्या आतील बाजू देखील अडकल्या होत्या. . दर्जेदार सेवा निवडा - आणि धूळ नाही! - आमच्या हालचालीचे कारण बनले.

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

दुसरे स्थलांतर एका वर्षापूर्वी झाले; 2019 मध्ये, आम्ही खूप चांगल्या डेटा सेंटरमधून O2xygen वर गेलो. हलविण्याची कारणे वर चर्चा केलेल्यांसारखीच होती, परंतु ते दूरसंचार ऑपरेटर्ससाठी मूळ डेटा सेंटरच्या अनाकर्षकतेच्या समस्येमुळे पूरक होते - अनेक प्रदात्याना स्वतःहून या बिंदूपर्यंत "पकडणे" होते.

MMTS-13 मधील उच्च-गुणवत्तेच्या साइटवर 9 रॅकच्या स्थलांतरामुळे हे स्थान केवळ ऑपरेटरचे स्थान (दोन रॅक आणि ऑपरेटरचे “फॉरवर्ड”) म्हणून विकसित करणे शक्य झाले नाही तर ते एक म्हणून वापरणे देखील शक्य झाले. मुख्य. यामुळे फारसे चांगले नसलेल्या डेटा सेंटरमधून स्थलांतर काहीसे सोपे झाले - आम्ही बहुतेक उपकरणे तेथून दुसर्‍या साइटवर नेली आणि O2xygen ला विकसनशील एकाची भूमिका सोपवण्यात आली, तेथे उपकरणांसह 5 रॅक पाठवले.

आज O2xygen आधीच एक पूर्ण प्लॅटफॉर्म आहे, जिथे आम्हाला आवश्यक असलेले ऑपरेटर "आले आहेत" आणि नवीन कनेक्ट होत आहेत. ऑपरेटरसाठी, O2xygen देखील धोरणात्मक विकासाच्या दृष्टिकोनातून आकर्षक असल्याचे दिसून आले.

आम्ही नेहमी एका रात्रीत हालचालीचा मुख्य टप्पा पार पाडतो, आणि MMTS-9 आणि O2xygen मध्ये स्थलांतर करताना, आम्ही या नियमाचे पालन केले. रॅकची संख्या कितीही असली तरी आम्ही "मूव्ह ओव्हरनाईट" नियमाचे काटेकोरपणे पालन करतो यावर आम्ही जोर देतो! आम्ही 20 रॅक हलवले आणि ते एका रात्रीत पूर्ण केल्याचीही एक उदाहरणे होती. स्थलांतर ही एक अगदी सोपी प्रक्रिया आहे ज्यासाठी अचूकता आणि सातत्य आवश्यक आहे, परंतु तयारी प्रक्रियेत आणि हलताना आणि नवीन ठिकाणी तैनात करताना येथे काही युक्त्या आहेत. तुम्हाला स्वारस्य असल्यास आम्ही स्थलांतराबद्दल तपशीलवार बोलण्यास तयार आहोत.

निकाल आम्हाला पंचवार्षिक विकास योजना आवडतात. आम्ही तीन डेटा केंद्रांमध्ये वितरीत केलेल्या नवीन दोष-सहिष्णु पायाभूत सुविधांचे बांधकाम पूर्ण केले आहे. आम्ही रहदारीची घनता झपाट्याने वाढवली आहे - जर अलीकडे आम्ही 40U सह 80-2G सह आनंदी होतो, तर आता आमच्यासाठी 100U सह 1G आहे. आता एक टेराबिट ट्रॅफिक देखील आम्हाला सामान्य समजले जाते. आम्ही आमची पायाभूत सुविधा आणखी विकसित करण्यास तयार आहोत, जी लवचिक आणि स्केलेबल झाली आहे.

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

लेखक: Petr Vinogradov - Uma.Tech चे तांत्रिक संचालक हॅम्स्टर

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