Badoo ने प्रति सेकंद 200k फोटो रेंडर करण्याची क्षमता कशी मिळवली

मीडिया सामग्रीशिवाय आधुनिक वेब जवळजवळ अकल्पनीय आहे: जवळजवळ प्रत्येक आजीकडे स्मार्टफोन आहे, प्रत्येकजण सोशल नेटवर्क्सवर आहे आणि देखभाल डाउनटाइम कंपन्यांसाठी महाग आहे. कंपनीच्या कथेचा उतारा येथे आहे Badoo हार्डवेअर सोल्यूशनचा वापर करून तिने फोटोंची डिलिव्हरी कशी आयोजित केली, प्रक्रियेत तिला कोणत्या कार्यप्रदर्शन समस्या आल्या, त्या कशामुळे झाल्या आणि सर्व स्तरांवर दोष सहिष्णुता सुनिश्चित करताना Nginx वर आधारित सॉफ्टवेअर सोल्यूशन वापरून या समस्या कशा सोडवल्या गेल्या याबद्दल (видео). आम्ही ओलेगच्या कथेच्या लेखकांचे आभार मानतो सन्नीस एफिमोवा आणि अलेक्झांड्रा डायमोवा, ज्यांनी परिषदेत त्यांचे अनुभव सामायिक केले अपटाइम दिवस 4.

— आपण फोटो कसे संग्रहित आणि कॅशे करतो याबद्दल थोड्या परिचयाने सुरुवात करूया. आमच्याकडे एक स्तर आहे जिथे आम्ही ते संग्रहित करतो आणि एक स्तर आहे जिथे आम्ही फोटो कॅशे करतो. त्याच वेळी, जर आम्हाला उच्च युक्ती दर मिळवायचा असेल आणि स्टोरेजवरील भार कमी करायचा असेल, तर आमच्यासाठी हे महत्वाचे आहे की प्रत्येक वापरकर्त्याचा फोटो एका कॅशिंग सर्व्हरवर आहे. अन्यथा, आमच्याकडे जितक्या जास्त सर्व्हर आहेत तितक्या पटीने जास्त डिस्क स्थापित कराव्या लागतील. आमचा ट्रिक रेट सुमारे 99% आहे, म्हणजेच आम्ही आमच्या स्टोरेजवरील भार 100 पट कमी करत आहोत आणि हे करण्यासाठी, 10 वर्षांपूर्वी, जेव्हा हे सर्व तयार केले जात होते, तेव्हा आमच्याकडे 50 सर्व्हर होते. त्यानुसार, हे फोटो देण्यासाठी, आम्हाला हे सर्व्हर सर्व्ह करत असलेल्या 50 बाह्य डोमेनची आवश्यकता आहे.

स्वाभाविकच, प्रश्न लगेच उद्भवला: जर आमचा सर्व्हर डाउन झाला आणि अनुपलब्ध झाला, तर आम्ही रहदारीचा कोणता भाग गमावू? आम्ही बाजारात काय आहे ते पाहिले आणि हार्डवेअरचा तुकडा खरेदी करण्याचा निर्णय घेतला जेणेकरून आमच्या सर्व समस्यांचे निराकरण होईल. निवड F5-नेटवर्क कंपनीच्या सोल्यूशनवर पडली (ज्याने अलीकडेच NGINX, Inc विकत घेतले): BIG-IP लोकल ट्रॅफिक मॅनेजर.

हा हार्डवेअरचा तुकडा (LTM) काय करतो: हा एक लोखंडी राउटर आहे जो त्याच्या बाह्य पोर्ट्सची लोखंडी रिडंडंसी बनवतो आणि तुम्हाला नेटवर्क टोपोलॉजीच्या आधारे, काही सेटिंग्जवर रहदारी रूट करण्याची परवानगी देतो आणि आरोग्य तपासणी करतो. हार्डवेअरचा हा भाग प्रोग्राम केला जाऊ शकतो हे आमच्यासाठी महत्त्वाचे होते. त्यानुसार, विशिष्ट कॅशेमधून विशिष्ट वापरकर्त्याची छायाचित्रे कशी दिली गेली याचे तर्क आम्ही वर्णन करू शकतो. ते कशासारखे दिसते? हार्डवेअरचा एक भाग आहे जो एका डोमेनवर, एका IP वर इंटरनेट पाहतो, ssl ऑफलोड करतो, HTTP विनंत्या पार्स करतो, IRule वरून कॅशे नंबर निवडतो, कुठे जायचे आहे आणि रहदारीला तिथे जाऊ देतो. त्याच वेळी, ते आरोग्य तपासणी करते, आणि काही मशीन अनुपलब्ध झाल्यास, त्या वेळी आम्ही ते केले जेणेकरून वाहतूक एका बॅकअप सर्व्हरवर जाईल. कॉन्फिगरेशनच्या दृष्टिकोनातून, अर्थातच काही बारकावे आहेत, परंतु सर्वसाधारणपणे सर्व काही अगदी सोपे आहे: आम्ही एक कार्ड नोंदणी करतो, नेटवर्कवर आमच्या आयपीला विशिष्ट क्रमांकाचा पत्रव्यवहार करतो, आम्ही म्हणतो की आम्ही पोर्ट 80 वर ऐकू. आणि 443, आम्ही म्हणतो की सर्व्हर अनुपलब्ध असल्यास, तुम्हाला ट्रॅफिक बॅकअपवर पाठवणे आवश्यक आहे, या प्रकरणात 35 व्या, आणि आम्ही हे आर्किटेक्चर कसे वेगळे केले जावे यावरील तर्कांचे एक समूह वर्णन करतो. एकच अडचण अशी होती की हार्डवेअर ज्या भाषेत प्रोग्राम केले गेले होते ती Tcl होती. जर कोणाला हे अजिबात आठवत असेल तर... ही भाषा प्रोग्रामिंगसाठी सोयीस्कर भाषेपेक्षा फक्त लिहिण्यायोग्य आहे:

आम्हाला काय मिळाले? आम्हाला हार्डवेअरचा एक तुकडा मिळाला आहे जो आमच्या पायाभूत सुविधांची उच्च उपलब्धता सुनिश्चित करतो, आमची सर्व रहदारी मार्गी लावतो, आरोग्य फायदे प्रदान करतो आणि योग्य कार्य करतो. शिवाय, हे बर्‍याच काळासाठी कार्य करते: गेल्या 10 वर्षांत याबद्दल कोणतीही तक्रार नाही. 2018 च्या सुरूवातीस, आम्ही आधीच प्रति सेकंद सुमारे 80k फोटो पाठवत होतो. आमच्या दोन्ही डेटा सेंटरमधून जवळपास 80 गिगाबिट रहदारी आहे.

मात्र…

2018 च्या सुरुवातीला, आम्ही चार्टवर एक कुरूप चित्र पाहिले: फोटो पाठवण्यास लागणारा वेळ स्पष्टपणे वाढला होता. आणि ते आम्हाला अनुकूल करणे थांबवले. समस्या अशी आहे की हे वर्तन केवळ रहदारीच्या शिखरावरच दृश्यमान होते - आमच्या कंपनीसाठी ही रविवार ते सोमवारची रात्र आहे. परंतु उर्वरित वेळेत यंत्रणा नेहमीप्रमाणे वागली, बिघाड होण्याची चिन्हे नाहीत.

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

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

म्हणजेच, आम्ही समस्येचा स्रोत ओळखला आहे, अडथळे ओळखले आहेत. आपण काय करायचे ते ठरवायचे आहे.

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

कार्य "शक्य तितक्या लवकर आणि आमच्याकडे असलेले हार्डवेअर वापरून काहीतरी करा" असे वाटत असल्याने, आम्हाला वाटले की काही फार शक्तिशाली नसलेल्या मशीन्स समोरून काढून टाकणे, तेथे Nginx ठेवणे, ज्यासह आम्हाला कसे करायचे ते आम्हाला माहित आहे. कार्य करा आणि हार्डवेअर करत असलेले सर्व तर्क लागू करण्याचा प्रयत्न करा. म्हणजे, खरं तर, आम्ही आमचे हार्डवेअर सोडले, आणखी 4 सर्व्हर स्थापित केले जे आम्हाला कॉन्फिगर करायचे होते, त्यांच्यासाठी बाह्य डोमेन तयार केले, जसे की 10 वर्षांपूर्वी होते... जर ही मशीन पडली तर आम्ही उपलब्धता कमी केली, परंतु तरीही कमी, त्यांनी आमच्या वापरकर्त्यांची समस्या स्थानिक पातळीवर सोडवली.

त्यानुसार, लॉजिक सारखेच राहते: आम्ही Nginx स्थापित करतो, ते SSL-ऑफलोड करू शकते, आम्ही कसे तरी राउटिंग लॉजिक प्रोग्राम करू शकतो, कॉन्फिगमध्ये आरोग्य-तपासणी करू शकतो आणि आमच्याकडे आधी असलेल्या लॉजिकची डुप्लिकेट करू शकतो.

चला configs लिहायला बसू. सुरुवातीला असे वाटले की सर्वकाही अगदी सोपे आहे, परंतु, दुर्दैवाने, प्रत्येक कार्यासाठी मॅन्युअल शोधणे खूप कठीण आहे. म्हणून, आम्ही फक्त "फोटोसाठी Nginx कसे कॉन्फिगर करावे" Google Google करण्याची शिफारस करत नाही: अधिकृत दस्तऐवजांचा संदर्भ घेणे चांगले आहे, जे दर्शवेल की कोणत्या सेटिंग्जला स्पर्श केला पाहिजे. परंतु विशिष्ट पॅरामीटर स्वतः निवडणे चांगले. बरं, मग सर्वकाही सोपे आहे: आम्ही आमच्याकडे असलेल्या सर्व्हरचे वर्णन करतो, आम्ही प्रमाणपत्रांचे वर्णन करतो... परंतु सर्वात मनोरंजक गोष्ट म्हणजे, राउटिंग लॉजिक स्वतःच.

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

परंतु, कदाचित, जर सर्व काही इतके सोपे असते, तर आम्ही फक्त घरी जाऊ आणि काहीही बोलणार नाही. दुर्दैवाने, डीफॉल्ट Nginx सेटिंग्जसह, जे, सर्वसाधारणपणे, अनेक वर्षांच्या विकासासाठी तयार केले गेले होते आणि या केससाठी पूर्णपणे योग्य नाहीत... कॉन्फिगरेशन असे दिसते: काही अपस्ट्रीम सर्व्हरमध्ये विनंती त्रुटी किंवा कालबाह्य असल्यास, Nginx नेहमी पुढील एकावर रहदारी स्विच करते. शिवाय, पहिल्या अपयशानंतर, 10 सेकंदात सर्व्हर देखील बंद होईल, चुकून आणि कालबाह्य - हे कोणत्याही प्रकारे कॉन्फिगर केले जाऊ शकत नाही. म्हणजेच, जर आम्ही अपस्ट्रीम निर्देशामध्ये कालबाह्य पर्याय काढला किंवा रीसेट केला, तर, जरी Nginx या विनंतीवर प्रक्रिया करणार नाही आणि काही फार चांगल्या त्रुटींसह प्रतिसाद देईल, सर्व्हर बंद होईल.

हे टाळण्यासाठी, आम्ही दोन गोष्टी केल्या:

अ) त्यांनी Nginx ला हे व्यक्तिचलितपणे करण्यास मनाई केली - आणि दुर्दैवाने, हे करण्याचा एकमेव मार्ग म्हणजे फक्त कमाल अपयशी सेटिंग्ज सेट करणे.

b) आम्हाला आठवले की इतर प्रकल्पांमध्ये आम्ही एक मॉड्यूल वापरतो जे आम्हाला पार्श्वभूमी आरोग्य तपासणी करण्यास अनुमती देते - त्यानुसार, आम्ही वारंवार आरोग्य तपासणी केली जेणेकरून अपघात झाल्यास डाउनटाइम कमी होईल.

दुर्दैवाने, हे सर्व काही नाही, कारण अक्षरशः या योजनेच्या ऑपरेशनच्या पहिल्या दोन आठवड्यांनी हे दर्शविले आहे की TCP आरोग्य-तपासणी देखील एक अविश्वसनीय गोष्ट आहे: अपस्ट्रीम सर्व्हरवर ते Nginx किंवा D-स्टेटमध्ये Nginx असू शकत नाही आणि या प्रकरणात कर्नल कनेक्शन स्वीकारेल, आरोग्य-तपासणी पास होईल, परंतु कार्य करणार नाही. म्हणून, आम्ही ताबडतोब हेल्थ-चेक HTTP ने बदलले, एक विशिष्ट बनवले, जे 200 परत केल्यास, सर्वकाही या स्क्रिप्टमध्ये कार्य करते. आपण अतिरिक्त तर्क करू शकता - उदाहरणार्थ, कॅशिंग सर्व्हरच्या बाबतीत, फाइल सिस्टम योग्यरित्या आरोहित आहे हे तपासा:

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

एका अपस्ट्रीममध्ये दुसर्‍या अपस्ट्रीमवर जाणे अशक्य असल्याने, मुख्य अपस्ट्रीम, ज्यामध्ये आम्ही फक्त अचूक, आवश्यक फोटो कॅशे रेकॉर्ड केला आहे, अनुपलब्ध असल्यास, आम्ही फॉलबॅक करण्यासाठी फक्त error_page वरून गेलो, याची खात्री करणे आवश्यक होते. जेथे आम्ही बॅकअप अपस्ट्रीमवर गेलो होतो:

आणि अक्षरशः चार सर्व्हर जोडून, ​​आम्हाला हे मिळाले: आम्ही लोडचा काही भाग बदलला - आम्ही ते LTM वरून या सर्व्हरवर काढले, तेथे समान तर्कशास्त्र लागू केले, मानक हार्डवेअर आणि सॉफ्टवेअर वापरून, आणि या सर्व्हरला लगेच बोनस मिळाला. मोजले जाऊ शकते, कारण ते फक्त आवश्यक तेवढे पुरवले जाऊ शकतात. बरं, फक्त नकारात्मक म्हणजे आम्ही बाह्य वापरकर्त्यांसाठी उच्च उपलब्धता गमावली आहे. परंतु त्या क्षणी आम्हाला हे बलिदान द्यावे लागले, कारण त्वरित समस्या सोडवणे आवश्यक होते. म्हणून, आम्ही लोडचा काही भाग काढून टाकला, त्या वेळी ते सुमारे 40% होते, LTM चांगले वाटले, आणि समस्या सुरू झाल्यानंतर अक्षरशः दोन आठवड्यांनंतर, आम्ही प्रति सेकंद 45k विनंत्या पाठविण्यास सुरुवात केली नाही, परंतु 55k. खरं तर, आम्ही 20% वाढलो - हे स्पष्टपणे ट्रॅफिक आहे जे आम्ही वापरकर्त्याला दिले नाही. आणि त्यानंतर त्यांनी उर्वरित समस्येचे निराकरण कसे करावे याबद्दल विचार करण्यास सुरुवात केली - उच्च बाह्य प्रवेशयोग्यता सुनिश्चित करण्यासाठी.

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

सुरुवातीला, Keepalived मध्ये काय समाविष्ट आहे? पहिला व्हीआरआरपी प्रोटोकॉल आहे, जो नेटवर्कर्सना व्यापकपणे ओळखला जातो, जो नेटवर्क उपकरणांवर स्थित आहे जो क्लायंट कनेक्ट केलेल्या बाह्य IP पत्त्यावर दोष सहनशीलता प्रदान करतो. दुसरा भाग म्हणजे आयपीव्हीएस, आयपी व्हर्च्युअल सर्व्हर, फोटो राउटरमधील संतुलन आणि या स्तरावर दोष सहिष्णुता सुनिश्चित करण्यासाठी. आणि तिसरे - आरोग्य तपासणी.

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

सराव मध्ये हे कसे दिसते? सर्व्हरपैकी एक अयशस्वी झाल्यास काय होईल? मास्टर गायब होताच, आमच्या बॅकअपला जाहिराती मिळणे थांबते आणि आपोआप मास्टर बनते. काही काळानंतर, आम्ही मास्टर दुरुस्त केला, रीबूट केले, Keepalived वाढवले ​​- जाहिराती बॅकअपपेक्षा जास्त प्राधान्याने येतात आणि बॅकअप आपोआप मागे वळतो, IP पत्ते काढून टाकतो, कोणतीही मॅन्युअल क्रिया करण्याची आवश्यकता नाही.

अशा प्रकारे, आम्ही बाह्य IP पत्त्याची दोष सहिष्णुता सुनिश्चित केली आहे. पुढील भाग म्हणजे बाह्य IP पत्त्यापासून ते आधीच संपुष्टात आलेल्या फोटो राउटरपर्यंतच्या रहदारीचे संतुलन साधणे. बॅलेंसिंग प्रोटोकॉलसह सर्व काही अगदी स्पष्ट आहे. हे एकतर एक साधे राउंड-रॉबिन आहे, किंवा किंचित अधिक क्लिष्ट गोष्टी, wrr, सूची कनेक्शन आणि असेच. हे मुळात दस्तऐवजीकरणात वर्णन केले आहे, यात विशेष काही नाही. पण वितरण पद्धत... आम्ही त्यापैकी एक का निवडला यावर आम्ही जवळून नजर टाकू. हे NAT, डायरेक्ट राउटिंग आणि TUN आहेत. वस्तुस्थिती अशी आहे की आम्ही ताबडतोब साइट्सवरून 100 गिगाबिट रहदारी वितरीत करण्याची योजना आखली आहे. तुमचा अंदाज असल्यास, तुम्हाला 10 गिगाबिट कार्डांची गरज आहे, बरोबर? एका सर्व्हरमध्ये 10 गिगाबिट कार्डे आधीपासूनच आमच्या "मानक उपकरणे" च्या संकल्पनेच्या पलीकडे आहेत. आणि मग आम्हाला आठवलं की आम्ही फक्त काही ट्रॅफिक देत नाही तर फोटो देतो.

काय विशेष आहे? - इनकमिंग आणि आउटगोइंग ट्रॅफिकमध्ये प्रचंड फरक. येणारी रहदारी खूप लहान आहे, जाणारी रहदारी खूप मोठी आहे:

जर तुम्ही या आलेखांवर नजर टाकली तर तुम्ही पाहू शकता की या क्षणी दिग्दर्शकाला सुमारे 200 MB प्रति सेकंद मिळत आहे, हा एक अतिशय सामान्य दिवस आहे. आम्ही प्रति सेकंद 4,500 MB परत देतो, आमचे प्रमाण अंदाजे 1/22 आहे. हे आधीच स्पष्ट झाले आहे की 22 वर्कर सर्व्हरला आउटगोइंग ट्रॅफिक पूर्णपणे प्रदान करण्यासाठी, आम्हाला फक्त हे कनेक्शन स्वीकारणारा एक हवा आहे. येथे थेट राउटिंग अल्गोरिदम आमच्या मदतीला येतो.

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

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

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

हे, पुन्हा, सराव मध्ये कसे दिसते? चला देखभालीसाठी सर्व्हर बंद करू - उदाहरणार्थ, BIOS फ्लॅश करणे. लॉगमध्ये, आमच्याकडे त्वरित कालबाह्य होते, आम्हाला पहिली ओळ दिसते, त्यानंतर तीन प्रयत्नांनंतर ती "अयशस्वी" म्हणून चिन्हांकित केली जाते आणि ती फक्त सूचीमधून काढून टाकली जाते.

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

तर, अगदी सोप्या पद्धतीने, थोड्या संख्येने सर्व्हरच्या मदतीने, आम्ही बाह्य दोष सहिष्णुतेची समस्या सोडवली.

एवढेच सांगायचे आहे की या सर्व गोष्टींवर अर्थातच लक्ष ठेवण्याची गरज आहे. स्वतंत्रपणे, हे लक्षात घ्यावे की Keepalivede, जसे की सॉफ्टवेअर खूप पूर्वी लिहिलेले आहे, DBus, SMTP, SNMP आणि मानक Zabbix द्वारे चेक वापरून त्याचे निरीक्षण करण्याचे अनेक मार्ग आहेत. शिवाय, त्याला स्वतःला जवळजवळ प्रत्येक शिंकासाठी अक्षरे कशी लिहायची हे माहित आहे आणि खरे सांगायचे तर, कधीतरी आम्ही ते बंद करण्याचा विचार देखील केला, कारण तो कोणत्याही ट्रॅफिक स्विचिंगसाठी, स्विचिंगसाठी, प्रत्येक आयपी कनेक्शनसाठी खूप अक्षरे लिहितो, . नक्कीच, जर तेथे बरेच सर्व्हर असतील तर आपण या अक्षरांनी स्वत: ला भारावून टाकू शकता. आम्ही मानक पद्धती वापरून फोटो राउटरवर nginx चे निरीक्षण करतो आणि हार्डवेअर मॉनिटरिंग दूर झालेले नाही. आम्ही अर्थातच, आणखी दोन गोष्टींचा सल्ला देऊ: प्रथम, बाह्य आरोग्य-तपासणी आणि उपलब्धता, कारण सर्वकाही कार्य करत असले तरी, प्रत्यक्षात, कदाचित वापरकर्त्यांना बाह्य प्रदात्यांसह किंवा काहीतरी अधिक गुंतागुंतीच्या समस्यांमुळे फोटो प्राप्त होत नाहीत. दुसर्‍या नेटवर्कवर, Amazon वर किंवा इतरत्र कुठेतरी ठेवणे नेहमीच फायदेशीर आहे, एक वेगळे मशीन जे तुमच्या सर्व्हरला बाहेरून पिंग करू शकते, आणि ज्यांना अवघड मशीन लर्निंग किंवा साधे निरीक्षण कसे करावे हे माहित आहे त्यांच्यासाठी विसंगती शोधणे वापरणे देखील फायदेशीर आहे. , किमान विनंत्या झपाट्याने कमी झाल्या आहेत किंवा त्याउलट, वाढल्या आहेत याचा मागोवा घेण्यासाठी. त्याचा उपयोगही होऊ शकतो.

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

आम्ही काय संपले? 2018 च्या जानेवारीच्या सुट्ट्यांमध्ये आम्हाला समस्या आली. पहिल्या सहा महिन्यांत आम्ही ही योजना कार्यान्वित करत असताना, LTM वरून सर्व ट्रॅफिक काढून टाकण्यासाठी आम्ही तिचा सर्व ट्रॅफिकमध्ये विस्तार केला, आम्ही फक्त एका डेटा सेंटरमधील रहदारी 40 गिगाबिट्सवरून 60 गिगाबिट्सपर्यंत वाढवली आणि त्याच वेळी संपूर्ण 2018 वर्ष प्रति सेकंद जवळजवळ तीनपट अधिक फोटो पाठविण्यात सक्षम होते.

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