कसरी 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 को कार्यसम्पादनमा ध्यान दिएका छौं, र यहाँ हामीले ग्राफहरूमा एउटा दुखद तस्विर देख्यौं: सबै CPU हरूमा लोड सहज रूपमा जान थाल्छ, तर त्यसपछि अचानक पठारमा आउँछ। एकै समयमा, LTM ले स्वास्थ्य जाँच र अपलिङ्कहरूलाई पर्याप्त रूपमा प्रतिक्रिया दिन रोक्छ र अनियमित रूपमा तिनीहरूलाई बन्द गर्न थाल्छ, जसले गम्भीर कार्यसम्पादनमा ह्रास निम्त्याउँछ।

त्यो हो, हामीले समस्याको स्रोत पहिचान गरेका छौं, अवरोध पहिचान गरेका छौं। हामीले के गर्ने भन्ने निर्णय गर्न बाँकी छ।

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

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

तदनुसार, तर्क उस्तै रहन्छ: हामी Nginx स्थापना गर्छौं, यसले SSL-offload गर्न सक्छ, हामी कुनै पनि तरिकाले राउटिंग तर्क, कन्फिगमा स्वास्थ्य-जाँचहरू प्रोग्राम गर्न सक्छौं र हामीले पहिले भएको तर्कको नक्कल गर्न सक्छौं।

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

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

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

यसबाट बच्न हामीले दुईवटा कुरा गर्यौं:

a) तिनीहरूले Nginx लाई यो म्यानुअल रूपमा गर्नबाट निषेध गरे - र दुर्भाग्यवश, यो गर्ने एक मात्र तरिका भनेको अधिकतम असफल सेटिङहरू सेट गर्नु हो।

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

दुर्भाग्यवश, यो सबै होइन, किनभने शाब्दिक रूपमा यस योजनाको सञ्चालनको पहिलो दुई हप्ताले TCP स्वास्थ्य-जाँच पनि एक अविश्वसनीय चीज हो भनेर देखाएको छ: अपस्ट्रीम सर्भरमा यो Nginx, वा Nginx D-state मा, र भित्र हुन सक्दैन। यस अवस्थामा कर्नेलले जडान स्वीकार गर्नेछ, स्वास्थ्य जाँच पास हुनेछ, तर काम गर्दैन। तसर्थ, हामीले यसलाई तुरुन्तै स्वास्थ्य-जाँच http बाट प्रतिस्थापन गर्यौं, एक विशिष्ट बनायौं, जुन, यदि यसले 200 फर्काउँछ भने, सबै कुरा यस लिपिमा काम गर्दछ। तपाइँ अतिरिक्त तर्क गर्न सक्नुहुन्छ - उदाहरण को लागी, क्यासिङ सर्भर को मामला मा, जाँच गर्नुहोस् कि फाइल प्रणाली सही माउन्ट गरिएको छ:

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

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

र शाब्दिक रूपमा चार सर्भरहरू थपेर, हामीले यो पायौं: हामीले लोडको अंश बदल्यौं - हामीले यसलाई LTM बाट यी सर्भरहरूमा हटायौं, त्यहाँ समान तर्क लागू गर्‍यौं, मानक हार्डवेयर र सफ्टवेयर प्रयोग गरेर, र तुरुन्तै यी सर्भरहरूले गर्न सक्ने बोनस प्राप्त गर्‍यौं। मापन गर्नुहोस्, किनभने तिनीहरू केवल आवश्यकता अनुसार आपूर्ति गर्न सकिन्छ। खैर, केवल नकारात्मक यो हो कि हामीले बाह्य प्रयोगकर्ताहरूको लागि उच्च उपलब्धता गुमाएका छौं। तर त्यो क्षण हामीले यो त्याग गर्नुपर्‍यो, किनभने यो तुरुन्तै समस्या समाधान गर्न आवश्यक थियो। त्यसोभए, हामीले लोडको अंश हटायौं, त्यो समयमा लगभग 40% थियो, LTM राम्रो लाग्यो, र शाब्दिक रूपमा समस्या सुरु भएको दुई हप्ता पछि, हामीले प्रति सेकेन्ड 45k अनुरोधहरू पठाउन थाल्यौं, तर 55k। वास्तवमा, हामीले 20% ले वृद्धि गर्‍यौं - यो स्पष्ट रूपमा ट्राफिक हो जुन हामीले प्रयोगकर्तालाई दिएनौं। र त्यस पछि तिनीहरूले बाँकी समस्या कसरी समाधान गर्ने बारे सोच्न थाले - उच्च बाह्य पहुँच सुनिश्चित गर्न।

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

सुरुमा, Keepalived के समावेश छ? पहिलो VRRP प्रोटोकल हो, नेटवर्करहरूलाई व्यापक रूपमा चिनिन्छ, नेटवर्क उपकरणहरूमा अवस्थित छ जसले क्लाइन्टहरू जडान गर्ने बाह्य IP ठेगानामा त्रुटि सहिष्णुता प्रदान गर्दछ। दोस्रो भाग हो IPVS, IP भर्चुअल सर्भर, फोटो राउटरहरू बीच सन्तुलन र यस स्तरमा त्रुटि सहिष्णुता सुनिश्चित गर्नको लागि। र तेस्रो - स्वास्थ्य जाँच।

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

यो व्यवहारमा कस्तो देखिन्छ? यदि कुनै सर्भर असफल भयो भने के हुन्छ? मास्टर गायब हुने बित्तिकै, हाम्रो ब्याकअपले विज्ञापनहरू प्राप्त गर्न रोक्छ र स्वचालित रूपमा मास्टर बन्छ। केहि समय पछि, हामीले मास्टर मर्मत गर्यौं, रिबुट गर्‍यौं, Keepalived उठायौं - ब्याकअप भन्दा उच्च प्राथमिकताका साथ विज्ञापनहरू आउँछन्, र ब्याकअप स्वतः फिर्ता हुन्छ, IP ठेगानाहरू हटाउँदछ, कुनै म्यानुअल कार्यहरू गर्नु पर्दैन।

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

खास के छ? - आगमन र बाहिर जाने यातायात बीच ठूलो भिन्नता। आगमन ट्राफिक धेरै सानो छ, बाहिर जाने ट्राफिक धेरै ठूलो छ:

यदि तपाइँ यी ग्राफहरू हेर्नुभयो भने, तपाइँ देख्न सक्नुहुन्छ कि यस समयमा निर्देशकले प्रति सेकेन्ड लगभग 200 एमबी प्राप्त गरिरहेको छ, यो धेरै सामान्य दिन हो। हामी प्रति सेकेन्ड 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