Badoo ने प्रति सेकंड 200k फ़ोटो रेंडर करने की क्षमता कैसे हासिल की

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

—आइए हम तस्वीरों को कैसे संग्रहीत और कैश करते हैं, इसके बारे में एक छोटे से परिचय से शुरुआत करें। हमारे पास एक परत है जहां हम उन्हें संग्रहीत करते हैं, और एक परत है जहां हम फ़ोटो को कैश करते हैं। उसी समय, यदि हम उच्च चाल दर प्राप्त करना चाहते हैं और भंडारण पर भार कम करना चाहते हैं, तो हमारे लिए यह महत्वपूर्ण है कि एक व्यक्तिगत उपयोगकर्ता की प्रत्येक तस्वीर एक कैशिंग सर्वर पर हो। अन्यथा, हमारे पास जितने अधिक सर्वर हैं, हमें उतनी ही गुना अधिक डिस्क स्थापित करनी होंगी। हमारी ट्रिक रेट लगभग 99% है, यानी हम अपने स्टोरेज पर लोड को 100 गुना कम कर रहे हैं, और ऐसा करने के लिए, 10 साल पहले, जब यह सब बनाया जा रहा था, हमारे पास 50 सर्वर थे। तदनुसार, इन तस्वीरों को परोसने के लिए, हमें अनिवार्य रूप से 50 बाहरी डोमेन की आवश्यकता थी जो ये सर्वर परोसते हैं।

स्वाभाविक रूप से, यह प्रश्न तुरंत उठा: यदि हमारा कोई सर्वर बंद हो जाता है और अनुपलब्ध हो जाता है, तो हम ट्रैफ़िक का कितना हिस्सा खो देते हैं? हमने देखा कि बाजार में क्या था और हार्डवेयर का एक टुकड़ा खरीदने का फैसला किया ताकि यह हमारी सभी समस्याओं का समाधान कर सके। चुनाव F5-नेटवर्क कंपनी के समाधान पर पड़ा (जिसने, वैसे, हाल ही में NGINX, Inc को खरीदा है): BIG-IP लोकल ट्रैफिक मैनेजर।

हार्डवेयर का यह टुकड़ा (एलटीएम) क्या करता है: यह एक आयरन राउटर है जो अपने बाहरी बंदरगाहों की आयरन रिडंडेंसी बनाता है और आपको कुछ सेटिंग्स पर नेटवर्क टोपोलॉजी के आधार पर ट्रैफिक को रूट करने की अनुमति देता है, और स्वास्थ्य जांच करता है। हमारे लिए यह महत्वपूर्ण था कि हार्डवेयर के इस टुकड़े को प्रोग्राम किया जा सके। तदनुसार, हम इस तर्क का वर्णन कर सकते हैं कि किसी विशिष्ट कैश से किसी विशिष्ट उपयोगकर्ता की तस्वीरें कैसे परोसी गईं। यह किस तरह का दिखता है? हार्डवेयर का एक टुकड़ा है जो एक डोमेन, एक आईपी पर इंटरनेट को देखता है, एसएसएल ऑफलोड करता है, http अनुरोधों को पार्स करता है, आईरूल से एक कैश नंबर चुनता है, कहां जाना है, और ट्रैफिक को वहां जाने देता है। साथ ही, यह स्वास्थ्य जांच करता है, और कुछ मशीन अनुपलब्ध होने की स्थिति में, उस समय हमने इसे बनाया ताकि ट्रैफ़िक एक बैकअप सर्वर पर चला जाए। कॉन्फ़िगरेशन के दृष्टिकोण से, निश्चित रूप से, कुछ बारीकियां हैं, लेकिन सामान्य तौर पर सब कुछ काफी सरल है: हम एक कार्ड पंजीकृत करते हैं, नेटवर्क पर हमारे आईपी के लिए एक निश्चित संख्या का पत्राचार, हम कहते हैं कि हम पोर्ट 80 पर सुनेंगे और 443, हम कहते हैं कि यदि सर्वर अनुपलब्ध है, तो आपको ट्रैफ़िक को बैकअप में भेजने की आवश्यकता है, इस मामले में 35वें, और हम तर्क का एक समूह बताते हैं कि इस आर्किटेक्चर को कैसे अलग किया जाना चाहिए। एकमात्र समस्या यह थी कि जिस भाषा में हार्डवेयर को प्रोग्राम किया गया था वह Tcl थी। यदि किसी को यह बिल्कुल याद है... यह भाषा प्रोग्रामिंग के लिए सुविधाजनक भाषा से अधिक केवल लिखने योग्य भाषा है:

हमें क्या मिला? हमें हार्डवेयर का एक टुकड़ा प्राप्त हुआ जो हमारे बुनियादी ढांचे की उच्च उपलब्धता सुनिश्चित करता है, हमारे सभी ट्रैफ़िक को रूट करता है, स्वास्थ्य लाभ प्रदान करता है और काम करता है। इसके अलावा, यह काफी लंबे समय तक काम करता है: पिछले 10 वर्षों में इसके बारे में कोई शिकायत नहीं आई है। 2018 की शुरुआत तक, हम पहले से ही प्रति सेकंड लगभग 80k फ़ोटो भेज रहे थे। यह हमारे दोनों डेटा केंद्रों से लगभग 80 गीगाबिट ट्रैफ़िक है।

हालांकि ...

2018 की शुरुआत में, हमने चार्ट पर एक बदसूरत तस्वीर देखी: तस्वीरें भेजने में लगने वाला समय स्पष्ट रूप से बढ़ गया था। और इसने हमें सूट करना बंद कर दिया। समस्या यह है कि यह व्यवहार केवल ट्रैफ़िक के चरम के दौरान ही दिखाई देता था - हमारी कंपनी के लिए यह रविवार से सोमवार की रात है। लेकिन बाकी समय सिस्टम हमेशा की तरह व्यवहार करता रहा, विफलता का कोई संकेत नहीं मिला।

फिर भी, समस्या का समाधान तो करना ही था। हमने संभावित बाधाओं की पहचान की और उन्हें दूर करना शुरू किया। सबसे पहले, निश्चित रूप से, हमने बाहरी अपलिंक का विस्तार किया, आंतरिक अपलिंक का संपूर्ण ऑडिट किया और सभी संभावित बाधाओं का पता लगाया। लेकिन इन सबका कोई स्पष्ट परिणाम नहीं निकला, समस्या दूर नहीं हुई।

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

यानी हमने समस्या के स्रोत की पहचान कर ली है, अड़चन की पहचान कर ली है। यह तय करना बाकी है कि हम क्या करेंगे.'

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

चूँकि कार्य ऐसा लग रहा था जैसे "जितनी जल्दी हो सके कुछ करें और हमारे पास जो हार्डवेयर है उसका उपयोग करें," पहली चीज़ जो हमने सोचा वह यह थी कि सामने से कुछ बहुत शक्तिशाली मशीनों को हटा दें, वहां Nginx डालें, जिसके साथ हम जानते हैं कि कैसे करना है काम करें और उन सभी तर्कों को लागू करने का प्रयास करें जो हार्डवेयर करता था। यानी, वास्तव में, हमने अपना हार्डवेयर छोड़ दिया, 4 और सर्वर स्थापित किए जिन्हें हमें कॉन्फ़िगर करना था, उनके लिए बाहरी डोमेन बनाए, जैसा कि 10 साल पहले था... अगर ये मशीनें गिर गईं तो हमने उपलब्धता में थोड़ा खो दिया, लेकिन इससे भी कम, उन्होंने स्थानीय स्तर पर हमारे उपयोगकर्ताओं की समस्या का समाधान किया।

तदनुसार, तर्क वही रहता है: हम Nginx स्थापित करते हैं, यह SSL-ऑफलोड कर सकता है, हम किसी तरह रूटिंग लॉजिक को प्रोग्राम कर सकते हैं, कॉन्फ़िगरेशन में स्वास्थ्य-जांच कर सकते हैं और बस उस तर्क को डुप्लिकेट कर सकते हैं जो हमारे पास पहले था।

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

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

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

इससे बचने के लिए हमने दो काम किये:

a) उन्होंने Nginx को मैन्युअल रूप से ऐसा करने से मना किया - और दुर्भाग्य से, ऐसा करने का एकमात्र तरीका केवल अधिकतम विफल सेटिंग्स सेट करना है।

बी) हमें याद आया कि अन्य परियोजनाओं में हम एक मॉड्यूल का उपयोग करते हैं जो हमें पृष्ठभूमि स्वास्थ्य जांच करने की अनुमति देता है - तदनुसार, हमने लगातार स्वास्थ्य जांच की ताकि दुर्घटना की स्थिति में डाउनटाइम न्यूनतम हो।

दुर्भाग्य से, यह सब भी नहीं है, क्योंकि वस्तुतः इस योजना के संचालन के पहले दो हफ्तों से पता चला है कि टीसीपी स्वास्थ्य-जांच भी एक अविश्वसनीय चीज है: अपस्ट्रीम सर्वर पर यह Nginx नहीं हो सकता है, या D-स्टेट में Nginx नहीं हो सकता है, और में इस स्थिति में कर्नेल कनेक्शन स्वीकार कर लेगा, स्वास्थ्य जांच पास हो जाएगी, लेकिन काम नहीं करेगी। इसलिए, हमने तुरंत इसे हेल्थ-चेक http से बदल दिया, एक विशिष्ट बनाया, जो, यदि यह 200 लौटाता है, तो सब कुछ इस स्क्रिप्ट में काम करता है। आप अतिरिक्त तर्क कर सकते हैं - उदाहरण के लिए, कैशिंग सर्वर के मामले में, जांचें कि फ़ाइल सिस्टम सही ढंग से माउंट किया गया है:

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

चूँकि एक अपस्ट्रीम के भीतर दूसरे अपस्ट्रीम पर जाना असंभव है, इसलिए यह सुनिश्चित करना आवश्यक था कि यदि मुख्य अपस्ट्रीम, जिसमें हमने बस सही, आवश्यक फोटो कैश रिकॉर्ड किया था, अनुपलब्ध था, तो हम फ़ॉलबैक के लिए केवल error_page के माध्यम से गए। जहां हम बैकअप अपस्ट्रीम में गए:

और वस्तुतः चार सर्वर जोड़कर, हमें यही मिला: हमने लोड का हिस्सा बदल दिया - हमने इसे एलटीएम से इन सर्वरों में हटा दिया, मानक हार्डवेयर और सॉफ़्टवेयर का उपयोग करके वहां वही तर्क लागू किया, और तुरंत बोनस प्राप्त किया जो ये सर्वर कर सकते हैं स्केल किया जाना चाहिए, क्योंकि उन्हें बस उतनी ही आपूर्ति की जा सकती है जितनी आवश्यकता हो। खैर, एकमात्र नकारात्मक बात यह है कि हमने बाहरी उपयोगकर्ताओं के लिए उच्च उपलब्धता खो दी है। लेकिन उस वक्त हमें इसकी कुर्बानी देनी पड़ी, क्योंकि समस्या का तुरंत समाधान करना जरूरी था।' इसलिए, हमने लोड का हिस्सा हटा दिया, उस समय यह लगभग 40% था, एलटीएम अच्छा लगा, और समस्या शुरू होने के दो सप्ताह बाद, हमने प्रति सेकंड 45k नहीं, बल्कि 55k अनुरोध भेजना शुरू किया। वास्तव में, हमने 20% की वृद्धि की - यह स्पष्ट रूप से वह ट्रैफ़िक है जो हमने उपयोगकर्ता को नहीं दिया। और उसके बाद वे सोचने लगे कि शेष समस्या को कैसे हल किया जाए - उच्च बाहरी पहुंच सुनिश्चित करने के लिए।

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

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

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

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

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

क्या है खास? - आने वाले और बाहर जाने वाले ट्रैफ़िक के बीच भारी अंतर। आने वाला ट्रैफ़िक बहुत छोटा है, बाहर जाने वाला ट्रैफ़िक बहुत बड़ा है:

अगर आप इन ग्राफ़ पर नज़र डालें तो आप देख सकते हैं कि इस समय निर्देशक को प्रति सेकंड लगभग 200 एमबी प्राप्त हो रही है, यह एक बहुत ही सामान्य दिन है। हम प्रति सेकंड 4,500 एमबी वापस देते हैं, हमारा अनुपात लगभग 1/22 है। यह पहले से ही स्पष्ट है कि 22 कार्यकर्ता सर्वरों को पूरी तरह से आउटगोइंग ट्रैफ़िक प्रदान करने के लिए, हमें केवल एक की आवश्यकता है जो इस कनेक्शन को स्वीकार करता है। यहीं पर डायरेक्ट रूटिंग एल्गोरिदम हमारी सहायता के लिए आता है।

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

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

हम बीच में कहीं रुक गए: हमारे पास एक विशिष्ट स्थान के लिए https अनुरोध है, स्क्रिप्ट को कॉल किया जाता है, यदि यह 200 वें उत्तर के साथ प्रतिक्रिया करता है, तो हम मानते हैं कि इस सर्वर के साथ सब कुछ ठीक है, यह सक्रिय है और इसे काफी हद तक चालू किया जा सकता है आसानी से।

यह फिर से व्यवहार में कैसा दिखता है? आइए रखरखाव के लिए सर्वर को बंद करें - उदाहरण के लिए, BIOS को फ्लैश करना। लॉग में, हमारे पास तुरंत एक टाइमआउट होता है, हम पहली पंक्ति देखते हैं, फिर तीन प्रयासों के बाद इसे "विफल" के रूप में चिह्नित किया जाता है, और इसे बस सूची से हटा दिया जाता है।

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

इसलिए, काफी सरल तरीके से, कम संख्या में सर्वरों की मदद से, हमने बाहरी दोष सहिष्णुता की समस्या को हल किया।

बस इतना ही कहा जाना बाकी है कि निःसंदेह, इस सब पर निगरानी रखने की जरूरत है। अलग से, यह ध्यान दिया जाना चाहिए कि Keepalivede, जैसा कि बहुत समय पहले लिखा गया सॉफ्टवेयर है, के पास इसकी निगरानी करने के कई तरीके हैं, दोनों DBus, SMTP, SNMP और मानक Zabbix के माध्यम से चेक का उपयोग करते हैं। इसके अलावा, वह खुद जानता है कि लगभग हर छींक के लिए पत्र कैसे लिखना है, और ईमानदारी से कहें तो, कुछ बिंदु पर हमने इसे बंद करने के बारे में भी सोचा, क्योंकि वह किसी भी ट्रैफिक स्विचिंग, स्विचिंग ऑन, हर आईपी कनेक्शन के लिए बहुत सारे पत्र लिखता है। और इसी तरह । बेशक, यदि बहुत सारे सर्वर हैं, तो आप इन पत्रों से खुद को अभिभूत कर सकते हैं। हम मानक तरीकों का उपयोग करके फोटो राउटर पर nginx की निगरानी करते हैं, और हार्डवेयर निगरानी दूर नहीं हुई है। हम, निश्चित रूप से, दो और चीजों की सलाह देंगे: पहला, बाहरी स्वास्थ्य-जांच और उपलब्धता, क्योंकि भले ही सब कुछ काम करता हो, वास्तव में, शायद उपयोगकर्ताओं को बाहरी प्रदाताओं के साथ समस्याओं या कुछ अधिक जटिल चीज़ों के कारण तस्वीरें नहीं मिलती हैं। यह हमेशा किसी अन्य नेटवर्क पर, अमेज़ॅन में या कहीं और रखने लायक है, एक अलग मशीन जो आपके सर्वर को बाहर से पिंग कर सकती है, और यह उन लोगों के लिए विसंगति का पता लगाने के उपयोग के लायक भी है, जो मुश्किल मशीन लर्निंग करना जानते हैं, या सरल निगरानी, ​​कम से कम यह ट्रैक करने के लिए कि क्या अनुरोधों में तेजी से गिरावट आई है, या, इसके विपरीत, वृद्धि हुई है। यह उपयोगी भी हो सकता है.

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

हमारा अंत क्या हुआ? 2018 की जनवरी की छुट्टियों के दौरान हमें एक समस्या हुई। पहले छह महीनों में जब हमने इस योजना को क्रियान्वित किया, हमने एलटीएम से सभी ट्रैफ़िक को हटाने के लिए इसे सभी ट्रैफ़िक में विस्तारित किया, हमने केवल एक डेटा सेंटर में ट्रैफ़िक को 40 गीगाबिट से 60 गीगाबिट तक बढ़ाया, और साथ ही साथ पूरे 2018 वर्ष में प्रति सेकंड लगभग तीन गुना अधिक तस्वीरें भेजने में सक्षम थे।

स्रोत: www.habr.com