इंटरनेट परियोजना की स्थिरता: कैसे करें // Mail.Ru प्रौद्योगिकी फोरम 2011 से रिपोर्ट: रिपोर्ट, वीडियो, प्रस्तुति का पाठ

रिपोर्ट " वेबसाइट की स्थिरता: कैसे " Mail.Ru प्रौद्योगिकी फोरम 2011 से टेप की एक श्रृंखला में अगले है। रिपोर्ट को डिक्रिप्ट करने की प्रणाली कैसे काम करती है, इसके विवरण के लिए, Mail.Ru टेक्नोलॉजी फोरम का “इनसाइड आउट” लेख देखें : इवेंट-मैनेजमेंट में उच्च तकनीक । वहाँ, साथ ही साथ फोरम की वेबसाइट ( http://techforum.mail.ru ) पर - अन्य रिपोर्टों के लिपियों के लिंक।

(मोबाइल उपकरणों के लिए वीडियो संस्करण डाउनलोड करें - iOS / Android H.264 480 × 368, आकार 170 एमबी, वीडियो बिटरेट 500 केबीपीएस, ऑडियो - 64 केबीपीएस)
(उच्च संकल्प वीडियो संस्करण H.264 624 × 480 डाउनलोड करें , आकार 610 एमबी, वीडियो बिटरेट 1500 केबीपीएस, ऑडियो 128 केबीपीएस)
(प्रेजेंटेशन स्लाइड्स डाउनलोड करें , 5.5Mb)

यह शायद आपके लिए एक रहस्य नहीं है कि हर बार जब किसी बड़ी साइट को काम, रुकावटों की समस्या होती है, तो यह बड़ी मात्रा में चर्चा का कारण बनता है। मैं आपको यह बताने की कोशिश करूंगा कि कैसे सुनिश्चित करें कि आपकी साइट दुर्घटनाग्रस्त न हो, या कम से कम दुर्घटनाग्रस्त हो। हम Mail.Ru में इसके लिए क्या करते हैं, किन तरीकों का इस्तेमाल करते हैं।

स्थिरता महत्वपूर्ण है।

एक वेबसाइट के लिए स्थिरता - क्या यह सिद्धांत रूप में महत्वपूर्ण है? इस विषय पर कई राय हैं - किसी का मानना ​​है कि यह महत्वपूर्ण है, किसी का मानना ​​है कि, दूसरों के बीच, यह सबसे महत्वपूर्ण कारक नहीं है। हम इसे बहुत महत्वपूर्ण मानते हैं, और हमारे पास तीन मुख्य कारण हैं।



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

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

तीसरा कारण इंटरनेट के बारे में नहीं है। हम सभी को यह समझना चाहिए कि एक व्यक्ति को इस तरह से संरचित किया जाता है कि नकारात्मक भावनाएं हमेशा सकारात्मक लोगों की तुलना में मजबूत होती हैं, और आपकी साइट पर एक दुर्घटना, एक नियम के रूप में, स्थिर कार्य समय, सेवा की गुणवत्ता आदि की एक बड़ी मात्रा को कवर करती है।

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

दुर्घटनाओं के कारण

Mail.ru के आंकड़ों के आधार पर, हमने उन कारणों को वर्गीकृत किया है जो रूसी इंटरनेट पर हमारे और अन्य साइटों पर दुर्घटनाएं होती हैं। यदि हम मात्रात्मक वितरण के बारे में बात करते हैं, तो मेरा मतलब है कि दुर्घटनाओं की संख्या जिसके कारण साइट का एक या कोई अन्य कार्य नहीं करता है, साइट झूठ आदि, इंटरनेट पर वेबसाइट क्रैश के आधे गलत सॉफ़्टवेयर रिलीज़ के कारण, बग के साथ सॉफ़्टवेयर रिलीज़ के साथ होते हैं। टेढ़े-मेढ़े विन्यास। तदनुसार, आधे मामलों में, मैं फिर से ध्यान देना चाहता हूं - मात्रात्मक रूप से, डेवलपर्स, सिस्टम प्रशासक जो परीक्षण नहीं किए जाते हैं, बुरी तरह से जारी किए जाते हैं, आदि को दोष देना है। अन्य 25% मामलों में सॉफ़्टवेयर क्रैश होते हैं, जिनमें मैं साइट पर लोड भी शामिल करता हूं, 16% मामले नेटवर्क क्रैश होते हैं, 8% सर्वरों के क्रैश होते हैं, जिन पर कंप्यूटर काम करते हैं।



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

निगरानी

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




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

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

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



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

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

फिर से, अच्छी निगरानी आपको समय बचाएगी, क्योंकि यह न केवल आपको चेतावनी देगा कि आपको समस्याएं हैं, बल्कि यह भी कहेगा कि यह इस समय काम नहीं कर रहा है, और यह आपको समझने और एक बाद के समाधान के लिए समय बचाएगा।

आपको हर समय समस्या के बारे में पता होना चाहिए। केवल रूस में नौ समय क्षेत्र हैं, और दुनिया भर में आपके पास उन जगहों पर उपयोगकर्ता हो सकते हैं जहां, कहते हैं, यह पहले ही दिन है, जबकि हमारे पास रात है।

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

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

हम Mail.Ru में क्या निगरानी रखते हैं

वास्तव में, Mail.Ru में लगभग 140 विभिन्न प्रकार के मॉनिटर हैं, मैं उन सभी को सूचीबद्ध नहीं करूंगा, कुल मिलाकर हम अपने सर्वर पर लगभग 150,000 वस्तुओं की निगरानी करेंगे। हमारे पास सेवा की निगरानी है। उदाहरण के लिए, यह HTTP पर सेवा प्रतिक्रिया हो सकती है। हमारे पास सेवाओं की कार्यात्मक निगरानी है, हम हमेशा जांचते हैं कि क्या पत्र हम तक पहुंचते हैं, चाहे वे पीओपी 3 के माध्यम से डाउनलोड किए जाएं, क्या कोई उपयोगकर्ता किसी अन्य उपयोगकर्ता को दोस्त के रूप में जोड़ सकता है, आदि। हम नेटवर्क उपलब्धता की निगरानी करेंगे। हम जाँचते हैं कि क्या हम दुनिया भर में दिखाई दे रहे हैं। हम अपने डेटा स्टोरेज के अधिभोग की निगरानी करते हैं, क्योंकि अधिकांश सॉफ्टवेयर इस तरह से लिखे जाते हैं कि यदि डिस्क भर जाती है, तो यह डेटा बस बिगड़ जाएगा, और हम बैकअप से पुनर्प्राप्त करने के लिए मजबूर हो जाएंगे। हम साइट की गति की निगरानी भी करते हैं, क्योंकि थ्रेशोल्ड मान हैं, जिस पर अब यह मायने नहीं रखता है कि आपकी साइट आधे घंटे में खुल जाती है। उपयोगकर्ता के लिए, इसका मतलब यह होगा कि आपकी साइट बस काम नहीं करती है। हम सभी सांख्यिकीय उत्सर्जन की निगरानी करते हैं। हम Mail.Ru पर बड़ी मात्रा में आंकड़े एकत्र करते हैं, उदाहरण के लिए, हम जानते हैं कि हम प्रति दिन कितने पत्र भेजते हैं, हम जानते हैं कि हम प्रति दिन कितने संदेश भेजते हैं, सामाजिक नेटवर्क पर हमारी कितनी मित्रता है। हम इन मात्रात्मक मेट्रिक्स का निरीक्षण करने की कोशिश करते हैं, और यदि उनमें से कोई भी तेजी से बढ़ना या बदलना शुरू कर देता है, या किसी प्रकार का "आउटबर्स्ट" दिखाई देता है, तो हमने इसे निगरानी में उजागर किया है, फिर संभावना है कि यह विश्लेषण क्यों हुआ, क्या हुआ यह किया जा सकता है, आदि। और ये उपलब्ध निगरानी के कुछ प्रकार हैं।


लेकिन एक और महत्वपूर्ण बना रहा। यदि आपके पास निगरानी नहीं है, तो यह बहुत बुरा है। लेकिन जब आप निगरानी करते हैं, लेकिन यह काम नहीं करता है, तो यह भयानक है, क्योंकि आपको यह गलत धारणा है कि आपकी साइट वास्तव में अब काम कर रही है। इसलिए, Mail.Ru में सबसे महत्वपूर्ण और बहुत पहली निगरानी यह निगरानी कर रही है कि निगरानी काम कर रही है।

आरक्षण और संतुलन

और अब बात करते हैं कि हमें अभी भी क्या करने की आवश्यकता है ताकि हमारी साइट गिर न जाए, क्योंकि हम इन मुद्दों पर Mail.Ru से संपर्क करते हैं। हम, निश्चित रूप से, अतिरेक और संतुलन के साथ शुरू करते हैं।

हमारे पास एक सार्वभौमिक तालिका है जिसे हम अपनी सेवाओं पर लागू करते हैं। यह काफी सामान्य है, लेकिन कम से कम एक या किसी अन्य सेवा के लिए इस पर प्रयास करते हुए, हम समझ सकते हैं कि यह कितना सुरक्षित है, यह कितना मेल खाता है जो हम प्राप्त करना चाहते हैं।

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

Mail.Ru में नेटवर्क इंफ्रास्ट्रक्चर द्वारा स्वीकृत स्टॉक 35% है। यह "चोटियों" को जीवित करने के लिए पर्याप्त है जो कुछ घटनाओं से जुड़े हैं। यह उपस्थिति की आमद को जीवित रखने के लिए पर्याप्त है जिसे हम अनुभव करते हैं जब हमारे प्रतियोगी काम नहीं करते हैं। सामान्य तौर पर, एक औसत साइट के लिए 35% नेटवर्क का बुनियादी ढांचा उन सभी आपदाओं से बचे रहने के लिए पर्याप्त है जो इसके साथ हो सकती हैं।

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

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



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



यहां हमारे पास हमारे सर्वर का एक समूह है। मान लीजिए कि ये दृश्य हैं। वे HTTP के माध्यम से उपयोगकर्ता के अनुरोधों का जवाब देते हैं। हमारे पास वही विवरण है जो मैंने वर्णित किया है, जो उन्हें सर्वेक्षण करता है और, यदि वे काम करते हैं, तो यह आईपीएलएस में इन वास्तविक सर्वरों की तालिका को अपडेट करता है। यदि IPVS में वास्तव में काम करने वाले सर्वरों की संख्या उस सीमा मूल्य से अधिक है, जिसे हमने अपनी सेवा के लिए पर्याप्त निर्धारित किया है, तो IPVS बैलेंसर पर आपकी सेवा का वर्चुअल IP पता बढ़ाता है। Mail.Ru के मामले में, आप देख सकते हैं कि ये चार आईपी पते, चार अलग-अलग समूहों के बैलेंसर हैं। राउटर के साथ संचार करने वाला वही डेमन इसे सूचित करना शुरू कर देता है कि Mail.Ru का मार्ग इसी बैलेंसर से होकर गुजरता है। इसके अलावा, जब कोई उपयोगकर्ता अनुरोध हमारे पास आता है, तो राउटर बैलेंसर से संपर्क करने के लिए राउटिंग टेबल का उपयोग करता है, बैलेंसर आईपी-इन-आईपी में इस ट्रैफ़िक को एनकैप्सुलेट करता है (यह हमें प्रति पैकेट केवल 20 बाइट जोड़ता है) और इसे वास्तविक सर्वर पर भेजता है। और असली सर्वर इसे सीधे, राउटर को एनकैप्सुलेशन के बिना, राउटर - सीधे उपयोगकर्ता को भेजता है।

यह योजना आपको प्रति सेकंड लगभग 600,000 पैकेट संसाधित करने की अनुमति देती है, जो लोकप्रिय विक्रेताओं के लोहे के लिए भी बुरा नहीं है।



इस समाधान का लाभ, विक्रेता से खरीदे गए हार्डवेयर की तुलना में, यह है कि यह आपके द्वारा पूरी तरह से नियंत्रित है, आप पूरी तरह से समझते हैं कि इस समय वहां क्या हो रहा है, आप अपनी जरूरत के अनुसार सब कुछ जोड़ सकते हैं, खत्म कर सकते हैं, फिर से तैयार कर सकते हैं। यदि कई सर्वर हमारे लिए काम नहीं करते हैं, तो इसे तुरंत रखा जाएगा और यह हमारे बैलेंसर के असली सर्वर की तालिका में इन सर्वरों को बंद कर देगा। मामले में हमारा खेत टूट गया, यानी , , , , keepalived, IPVS, IP-address . , , , , .

, . . , RIP- , , , . , - , , keepalived, , , , .



, , — . , , . RIP- Quagga, , , .


, Quagga , RIP-, , poison -. , , - . , IPVS , 20 IP-. Keepalived , , , 1500 , , - MTU — .


: , , 600 000 , irqbalance, . C , keepalived . , MSI-X, . Mail.Ru.



. , . . , . , , . - , - . , , . - , . — «» . - - , . , , , , , , . , , , .

, — . clientside — AJAX, , , , , , . , . — , frontend-a, .. .

-

- . , -, . , , , Mail.Ru .

-, . , - . - , , , , , , « », « », « », « »? , … Mail.Ru — « , ». , - -, - , - — , , . , , -, , , . -, , .. , , , .

, , , , . Mail.Ru -. - — . - — , , , , . -, , , - , .

, - — . , , - , - . , , , — , . , — . , , - - , . , -, , , , , .



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

. , . , , , , 20 . , , .

, , — , , , . , , , , — . Mail.Ru , , , - . . -, ,
60-
. , , .

. , , , , -, . , . , . , , . — - , , , , . . ? , , . , - . , , - , , , , , . «-» . , , . , - , «internal server error 500».

, , , , : ( ) « , , , . .»

, , , , - , . , , . , , « ». - , , . , , , — . , . , , .



— . , , , -, - , . , , , , — , , , ? - , - , - , , , . , , , . . , , , .

, , , « ». 10% . - - , - - , - . , , — , .

, , , , , , , , . — , -, .

, , , BGP-, . , Mail.Ru . , , , , , . , . , , , , .

सवाल

— , , . , , . , ?

- 15, .

. , . : ?

, . , , . , , .. , .

, , . : , — - ?

— . , , . , , . - — , , .

. ? - , - ?

. - . , . . , , , , , — « , , », . — , .

, « ». , , , , - . -. , -?

- . , , «».

. . — , — . , — - . ? ..

. , . , , , — «, - , ?». . , , - , , .

— — «, »? ?

. — « — ». , . , , — . : - , , — «, , », , . . « , », « », « , ?» ..

सेर्गेई, रूसबीटेक। आपने बताया कि आप विभाजन परीक्षण का उपयोग करते हैं। यानी कुछ उपयोगकर्ता जिन्हें आप लूप करते हैं वे सॉफ़्टवेयर उत्पाद के नए संस्करणों पर चलते हैं। आप कैसे निर्धारित करते हैं कि ये उपयोगकर्ता कौन हैं? उनके अनुरोध पर या मूल सिद्धांत के अनुसार किसी तरह? आप परीक्षण ट्रैफ़िक कैसे वितरित करते हैं?

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

रहस्य की खोज करें, क्षेत्र - कौन से क्षेत्र? रूस के मध्य क्षेत्र या ...

निर्भर करता है कि हम क्या परीक्षण कर रहे हैं। अलग। हम अपने दर्शकों को बारीकी से काट सकते हैं, हम एक शहर और पूरे क्षेत्र में परीक्षण कर रहे हैं, जो अब हम लॉन्च और परीक्षण करना चाहते हैं, उसके आधार पर।

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

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

व्लादिमीर। निगरानी के बारे में सवाल। क्या आप खुले स्रोत निगरानी समाधान का उपयोग करते हैं या क्या आप स्व-लिखित का उपयोग करते हैं। उदाहरण के लिए, यैंडेक्स बहुत लंबे समय से ओपनसोर्स समाधान का उपयोग कर रहा है और वर्तमान में इसका उपयोग जारी है, लेकिन पहले से ही इसकी निगरानी लिख रहा है।

हम अपनी निगरानी का उपयोग करते हैं। आईटी उद्योग में 13 साल का अनुभव है। उस समय जब हमें इसकी आवश्यकता थी, हमें कुछ भी स्वीकार्य नहीं मिला, इसलिए हमने लिखा और तब से हम अपनी निगरानी का समर्थन करते हैं। Mail.ru में बहुत सी इकाइयाँ हैं जिनकी निगरानी करने की आवश्यकता है, और उन्हें जल्दी से निगरानी करने की आवश्यकता है। इसलिए, हम अपने स्वयं के उत्पाद का उपयोग करते हैं।

आप रिपोर्ट में, सिद्धांत रूप में, सवाल नहीं कर सकते। सूचना सुरक्षा के बारे में। हैकर के हमले या किसी अन्य चीज को रोकने के लिए आप अपने सिस्टम के सभी हिस्सों को कैसे प्रदान करते हैं, क्या आप किसी निगरानी प्रणाली, तकनीक का उपयोग करते हैं?

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

यूजीन। स्थिरता के सवाल के लिए - क्या आप DoS के हमलों को पीछे हटाने के लिए किसी विशेष हार्डवेयर का उपयोग करते हैं?

नहीं।

यानी क्षमता के कारण सभी?

शक्ति की कीमत पर नहीं - मस्तिष्क की कीमत पर।

दूसरा सवाल: Mail.Ru समूह नए डेटा केंद्रों को आकर्षित करने के लिए एक नए प्रौद्योगिकी मंच में रुचि रखता है?

हां, जरूर। हम नए डेटा केंद्रों के प्रस्तावों और नए डेटा केंद्रों के निर्माण के प्रस्तावों पर विचार करके प्रसन्न हैं। हम अपने डेटा सेंटर बना रहे हैं और यह बहुत दिलचस्प है।

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

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

---

यह पाठ मेल.रु टेक्नोलॉजी फोरम 2011 में व्लादिमीर गैब्रिएलियन की रिपोर्ट का एक प्रतिलेख है, जो 16 नवंबर को इन्फॉस्पेस सेंटर में हुआ था। वीडियो रिपोर्ट के लिए पाठ बनाने के लिए तकनीक के बारे में विवरण के लिए, यहां देखें: द इनसाइड आउट ऑफ द मेल.रु टेक्नोलॉजी फोरम: हाई-टेक इवेंट-मैनेजमेंट । अन्य रिपोर्ट (मोबाइल उपकरणों के लिए संस्करण सहित) के वीडियो संस्करण फोरम वेबसाइट - techforum.mail.ru पर उपलब्ध हैं। रिपोर्ट के पाठ संस्करण हर हफ्ते या फ़ोरम वेबसाइट पर एक समान प्रारूप में प्रायः या कुछ कम प्रकाशित किए जाएंगे। कृपया पाठ में टाइपो के बारे में पीएम को सूचित करें।