बजट विफल-सुरक्षित ऑनलाइन सेवा 24x7 बनाने का अनुभव

समस्याओं

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

हम क्या पाना चाहते थे

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

सेवा में ऑनलाइन बिलिंग शामिल है, डेटाबेस में डेटा लगातार अपडेट किया जाता है और सभी मामलों में संरक्षित रहना चाहिए। 24x7 उपलब्धता बहुत महत्वपूर्ण है।

हमारे सामने चुनौतियां:

1. उपकरण विफलता के जोखिम से बचाव करें
2. सॉफ़्टवेयर विफलता से जुड़े जोखिमों से खुद को सुरक्षित रखें (उदाहरण के लिए, क्रैश डेटाबेस, "अजीब हैंग" - कुछ भी)
3. डेटा सेंटर में इंटरनेट और बिजली के नुकसान से जुड़े जोखिमों से खुद को बचाएं
4. आपात स्थिति के बाद, यह सेवा एक डोमेन नाम 2kengu.ru के तहत ग्राहकों के लिए उपलब्ध होनी चाहिए
5. हम शांति से सोना चाहते हैं - ताकि दुर्घटना की स्थिति में 15 मिनट के भीतर वसूली के लिए आवश्यक कुल डाउनटाइम में सब कुछ खुद ही बहाल हो जाए
6. हम चाहते हैं कि समाधान सस्ता हो, उदाहरण के लिए, अतिरिक्त उपकरण खरीदने के बिना 8,000 रूबल / माह से अधिक नहीं।

मानक सरल समाधान

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

मैं केवल कुछ बिंदुओं पर ध्यान केन्द्रित करूंगा:

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

आपका विनम्र सेवक उस विषय में "अमेरिका की खोज" होने का ढोंग नहीं करता है जो उठाया जा रहा है। समाधान जो हमने अपने एसएमएस मेलिंग प्रोजेक्ट के लिए लागू किया था, वह कई प्रसिद्ध विचारों पर आधारित है।

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

नुस्खा। सभी सरल सरल है

1. हम 2 सोर्स सर्वर लेते हैं। यह VPS / VDS या वास्तविक सर्वर हो सकता है - कोई फर्क नहीं पड़ता। एक समय में, सेवा केवल एक सर्वर पर काम करेगी, अर्थात। यह एक क्लस्टर नहीं है।
2. हम सर्वर को विभिन्न साइटों पर रखते हैं। यह एक बहुत महत्वपूर्ण बिंदु है - जैसा कि अभ्यास से पता चलता है, डेटा सेंटर में समस्याएं (मुख्य राउटर की विफलता, पावर आउटेज और यहां तक ​​कि आग) आपके हार्डवेयर और सॉफ़्टवेयर की समस्याओं की तुलना में लगभग अधिक बार हो सकती है।
3. हम प्रत्येक सर्वर पर व्यावसायिक सॉफ़्टवेयर, डीबीएमएस स्थापित करते हैं, डेटाबेस को सिंक्रनाइज़ करते हैं। हम डेटाबेस प्रतिकृति को एक सर्वर से दूसरे में कॉन्फ़िगर करते हैं। हम सॉफ्टवेयर और स्क्रिप्ट के दैनिक सिंक्रनाइज़ेशन को कॉन्फ़िगर करते हैं।
4. हम समय में सर्वर को सिंक्रनाइज़ करते हैं।

इस प्रकार प्रत्येक सर्वर के लिए हमारे पास दो ऑपरेटिंग मोड हो सकते हैं: मास्टर और दास।
केवल मास्टर हमेशा सार्वजनिक डोमेन में होता है। उस समय, गुलाम केवल डेटाबेस तुल्यकालन से संबंधित है।

सबसे दिलचस्प

संपूर्ण समाधान बैश में लिखी गई लिपियों पर बनाया गया है। दोनों सर्वरों की स्क्रिप्ट बिल्कुल एक जैसी हैं।
हमें एक तीसरे लिंक की आवश्यकता है (हमारे दो सर्वरों को छोड़कर): कुछ भरोसेमंद प्रदाता से डीएनएस होस्टिंग।
हमने अपनी परियोजना में यैंडेक्स डीएनएस होस्टिंग का इस्तेमाल किया।

DNS होस्टिंग का उपयोग दो चीजों के लिए किया जाता है:

1. मास्टर सर्वर के वर्तमान आईपी पते का भंडारण, जिसके लिए डोमेन नाम से सेवा का उपयोग करने वाले ग्राहकों को पुनर्निर्देशित किया जाना चाहिए
2. टाइमस्टैम्प भंडारण। एक टाइमस्टैम्प सिर्फ एक स्ट्रिंग (TXT रिकॉर्ड) है जिसमें आपकी लिपियों के लिए सशर्त परिवर्तनीय नाम है और वास्तविक मूल्य टाइमस्टैम्प है।

Yandex अपने उपयोगकर्ताओं को एक अद्भुत चीज प्रदान करता है - DNS रिकॉर्ड के साथ काम करने के लिए एपीआई। इस API का उपयोग करके, हमारे सर्वर DNS रिकॉर्ड पढ़ और लिख सकते हैं।

मास्टर मोड में सर्वर तर्क

क्रोन के अनुसार, हर 5 मिनट में एक बार निम्नलिखित क्रियाएं की जाती हैं:

1. DNS रिकॉर्ड यह देखने के लिए जांचा जाता है कि क्या वर्तमान कामकाजी IP पता इस मशीन के पते से मेल खाता है या नहीं। यदि यह मेल खाता है, तो सर्वर अभी भी एक मास्टर है और विज़ार्ड एल्गोरिथम के अनुसार कार्य करना जारी रखता है। यदि आईपी पता बदल गया है, तो यह चेकिंग सर्वर अब मास्टर नहीं है - इसे दास को संक्रमण प्रक्रिया करना होगा।
2. अगली बार स्टाम्प रिकॉर्ड किया गया है - "दिल की धड़कन" - वर्तमान सर्वर समय TXT DNS रिकॉर्ड में दर्ज किया गया है।

MASTER से SLAVE मोड में स्विच करने की प्रक्रिया

मास्टर सर्वर पर यह प्रक्रिया तब की जाती है जब यह "समझता है" कि यह अब मास्टर नहीं है। ऐसा किसी दुर्घटना के होने के बाद हो सकता है और SLAVE को यह पता चल जाता है कि मास्टर सर्वर अनुपलब्ध है, स्वयं मास्टर बन जाता है। दुर्घटना समाप्त होने के बाद (डेटा सेंटर में बिजली दी गई), "पुराना" मास्टर उगता है - हमारा कार्य दो सर्वरों को एक ही समय में मुकाबला मास्टर मोड में काम करने से रोकना है। इससे डेटा को सिंक से बाहर किया जा सकता है - इसके लिए, जैसे ही कोई दुर्घटना होती है, गुलाम DNS में अपना खुद का आईपी पता लिखता है, जो एक तरफ ग्राहकों को एक नए आईपी में रीडायरेक्ट करता है, और दूसरी ओर, "पुराने" मास्टर के लिए एक झंडा होता है कि वह अब मास्टर नहीं है ।

दास के लिए स्विच करते समय, पूर्व स्वामी निम्नलिखित क्रियाएं करता है:

1. एक वेब सर्वर को रोकता है जो मूल व्यावसायिक कार्य करता है
2. एक और WEB सर्वर लॉन्च करता है जो PROXY की तरह काम करता है, जो क्लाइंट से दूसरे तक सभी अनुरोधों को पुनर्निर्देशित करता है - एक नया मास्टर सर्वर। ऐसे अनुरोध तब जा सकते हैं यदि सेवा के ग्राहकों ने अभी तक DNS कैश को अपडेट नहीं किया है और वे अभी भी "पुराने" आईपी पते को संदर्भित करते हैं।
3. नए मास्टर से पूर्ण डेटाबेस डंप की प्रतिलिपि बनाता है। यह एक तरफ इस तथ्य के कारण किया जाना चाहिए कि दुर्घटना के दौरान (जब पुराना मास्टर अनुपलब्ध था) पहले से ही कई अपडेट जमा हो गए हैं, और दूसरी तरफ, क्योंकि दुर्घटना खुद डेटाबेस को नुकसान पहुंचा सकती है।
4. डंप की नकल करने के बाद दास मोड में डेटाबेस प्रतिकृति शुरू होता है
5. दास मोड में सर्वर ऑपरेशन लॉजिक शुरू करता है।

दास मोड में सर्वर तर्क

क्रोन के अनुसार, हर 5 मिनट में एक बार निम्नलिखित क्रिया की जाती है:

• यह मास्टर सर्वर द्वारा लिखे गए टाइमस्टैम्प को स्टोर करने वाले DNS TXT रिकॉर्ड (केवल पढ़ने के लिए) की जाँच करता है। यदि लेबल में पढ़ा गया समय सर्वर के समय से 10 मिनट से अधिक है, तो यह संकेत है कि मास्टर को कुछ हुआ है, इस स्थिति में दास मास्टर मोड में जाने की प्रक्रिया शुरू करता है। अन्यथा, दास दूसरे 5 मिनट तक सोता रहता है

SLAVE से मास्टर मोड में स्विच करने की प्रक्रिया

जैसा कि पहले ही उल्लेख किया गया है, इस प्रक्रिया को दास सर्वर पर लॉन्च किया जाता है जब यह "समझता है" कि यह मास्टर से साझा टाइमस्टैंप के माध्यम से अगली टाइमस्टैम्प प्राप्त नहीं करता है।

इस मामले में, आपको आवश्यकता है:

1. DNS ए-रिकॉर्ड को अपडेट करें - उपयोगकर्ताओं को एक नए सर्वर पर पुनर्निर्देशित करने के लिए अपना आईपी पता रिकॉर्ड करें। (केवल एक दास ऐसा करता है, गुरु के लिए स्विचन)।
2. मास्टर मोड में काम करने के लिए DBMS स्विच करें और एक डंप तैयार करें ताकि यह दिखाई देने पर एक नए गुलाम पर लोड हो सके। (दास पर स्विच करने की प्रक्रिया देखें)।
3. आपको WEB- सर्वर को बंद करने की जरूरत है, जो क्लाइंट से मास्टर-सर्वर के सभी अनुरोधों को पुनर्निर्देशित करने के कार्यों को निष्पादित करता है।
4. मुख्य व्यवसाय तर्क के साथ एक वेब सर्वर शुरू करें।

कमजोर अंक

लेकिन क्या होगा अगर यैंडेक्स डीएनएस होस्टिंग टूट जाती है?

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

DNS कैश से निपटने के लिए उपयोगकर्ताओं को एक "मृत" सर्वर पर पुनर्निर्देशित कैसे करें।

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

निष्कर्ष में

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

कुल:

लागत: 2 सर्वर (आप किराए पर ले सकते हैं) - स्क्रिप्ट सेट करने के लिए आपके स्वाद + एक बार के काम के लिए।
दुर्घटना की स्थिति में सेवा समय: डायग्नोस्टिक्स के लिए 10 मिनट + स्विचिंग के लिए 10 मिनट, कुल 20 मिनट - दिन या रात के किसी भी समय - और आप शांति से सुबह उठते हैं, एक कप कॉफी पीते हैं और अक्षरों को छांटते हुए हर चीज के बारे में पता लगाते हैं।