कैसे हेट ने प्रति सेकंड 200k फ़ोटो देना संभव बना दिया

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

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

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





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



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

हालांकि ...

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



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

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

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



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

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

तदनुसार, तर्क एक ही रहता है: हम नगनेक्स डालते हैं, यह एसएसएल-ऑफलोड कर सकता है, हम किसी तरह राउटिंग लॉजिक, हेल्थ-चेक इनफॉर्म्स पर प्रोग्राम कर सकते हैं और उस लॉजिक को डुप्लिकेट कर सकते हैं जो हमारे पास पहले था।

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

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



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



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

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

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

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



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



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



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



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



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

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



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



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

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



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

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

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

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

, , . — BIOS, . , , «», .



, VS , . , Nginx, health-check' , , , , . . — . , , .

, , .

, , , . , Keepalivede, , , DBus, SMTP, SNMP, Zabbix'. , , , - , , , IP- . , , . nginx -, . , , : -, health-check' , , , , - - . - , amazon -, , , anomaly detection, , machine learning, , , , , , . .

: , , , - , , , HTTPS health-check'. , , , , , .

? 2018-. , , LTM, - 40 60 , 2018- .