डेटाबेस उपलब्धता एप्लिकेशन आर्किटेक्चर के सबसे महत्वपूर्ण पहलुओं में से एक है। जबकि डेटा सेंटर डाउनटाइम को रोकना एक दिया हुआ है, यह अंततः सभी के साथ होने वाला है। यहां तक कि सबसे अच्छे डेटा केंद्र भी समय-समय पर पूरी तरह से नीचे जाने वाले हैं। उदाहरण के लिए, अमेज़ॅन एडब्ल्यूएस 8/26/13 और 9/13/13 के आउटेज। पूछने का महत्वपूर्ण प्रश्न यह है कि क्या यह आपके आवेदन के लिए स्वीकार्य है? अधिकांश एप्लिकेशन समय-समय पर कुछ डाउनटाइम को सहन कर सकते हैं, हालांकि, कुछ एप्लिकेशन को लगभग 100% अपटाइम की आवश्यकता होती है और इन एप्लिकेशन के डेटाबेस आर्किटेक्चर के लिए अधिक जानबूझकर डिज़ाइन दृष्टिकोण की आवश्यकता होती है। डेटा केंद्रों के बीच विलंबता काफी बड़ी होती है, इसलिए आपके MongoDB होस्टिंग परिनियोजन के डिज़ाइन में सावधानीपूर्वक विचार किया जाना चाहिए।
MongoDB अपटाइम लक्ष्य
- आपका डेटाबेस ऊपर और लिखने योग्य होना चाहिए, भले ही एक पूरा डेटासेंटर नीचे चला जाए।
- सर्वर/डेटासेंटर की विफलता के मामले में आपका डेटाबेस फ़ेलओवर स्वचालित होना चाहिए।
- एक एकल सर्वर विफलता के कारण प्राथमिक को किसी भिन्न डेटासेंटर पर स्विच नहीं करना चाहिए।
डेटा सेंटर डिज़ाइन
अपने लक्ष्यों को पूरा करने के लिए, हमने 4+1 रेप्लिका सेट का उपयोग करते हुए तीन डेटा सेंटर डिज़ाइन तैयार किए:
- डेटासेंटर 1: प्राथमिक (प्राथमिकता 10), माध्यमिक 0 (प्राथमिक 9)
- डेटासेंटर 2: माध्यमिक 1 (प्राथमिकता 8), माध्यमिक 2(प्राथमिकता 7)
- डेटासेंटर 3: मध्यस्थ
हम पहले दो डेटा केंद्रों में से प्रत्येक में दो पूर्ण सदस्य और तीसरे डेटा केंद्र में एक मध्यस्थ रखते हैं। हमने प्रत्येक सर्वर के लिए प्राथमिकता को भी कॉन्फ़िगर किया है ताकि हम यह नियंत्रित कर सकें कि सर्वर की विफलता के मामले में कौन सा सदस्य प्राथमिक बन जाता है।
इस जियो में कुछ कमियां हैं- वितरित वास्तुकला:
- यदि आपके पास एक लेखन-भारी एप्लिकेशन है, तो बड़े विलंबता के कारण किसी भिन्न डेटा केंद्र में सेकेंडरी हमेशा पीछे रहेंगे। यदि कुछ डेटा महत्वपूर्ण है, तो आप यह सुनिश्चित करने के लिए "बहुमत" की एक MongoDB लेखन चिंता का उपयोग करना चाह सकते हैं कि सभी नोड डेटा को प्रतिबद्ध करते हैं।
- MongoDB कम्युनिटी बिल्ड में SSL सक्षम नहीं है। आप एसएसएल सक्षम के साथ एक बिल्ड बनाना चाहते हैं या स्केलग्रिड पर मोंगोडीबी डीबीएएएस का उपयोग कर सकते हैं ताकि सभी क्षेत्रों में बहने वाले डेटा को एन्क्रिप्ट किया जा सके।
अमेजन AWS / EC2 उपलब्धता
यदि आप AWS पर MongoDB परिनियोजित कर रहे हैं, तो इस चित्र में प्रत्येक डेटा केंद्र एक Amazon क्षेत्र से मेल खाता है, न कि उपलब्धता क्षेत्र से। Amazon एकल उपलब्धता क्षेत्र में उपलब्धता की गारंटी प्रदान नहीं करता है, SLA पूरे क्षेत्र के लिए है। यदि आप उपलब्धता क्षेत्रों में तैनात करते हैं तो आपका एसएलए 99.95% है जो अभी भी एक महान एसएलए है - हालांकि, यदि कोई पूरा क्षेत्र नीचे चला जाता है, तो आपका डेटाबेस नीचे चला जाएगा। साथ ही, कुछ एडब्ल्यूएस क्षेत्रों में केवल दो उपलब्धता क्षेत्र होते हैं, इसलिए तीसरे नोड को एक अलग क्षेत्र में रखने पर विशेष ध्यान दिया जाना चाहिए ताकि एक क्षेत्र डाउनटाइम पूरे डेटाबेस को नीचे न लाए।
सभी भौगोलिक क्षेत्रों में कम लागत उपलब्धता
एक ही आर्किटेक्चर का एक सरल संस्करण केवल तीन सर्वरों का उपयोग करता है और प्रत्येक डेटा सेंटर में केवल एक प्रतिकृति रखता है। इस दृष्टिकोण का नकारात्मक पक्ष यह है कि एक एकल सर्वर विफलता प्राथमिक को डेटासेंटर में स्थानांतरित करने का कारण बनेगी। हालांकि, इस वास्तुकला की लागत पहले वास्तुकला की तुलना में कम है। आपके परिदृश्य के आधार पर, यह आपके काम आ सकता है।
MongoDB के साथ उच्च अपटाइम प्राप्त करने के कई तरीके हैं, और यही वह तरीका है जो हमारी आवश्यकताओं के लिए काम करता है। यदि आपके पास अन्य दिलचस्प आर्किटेक्चर हैं, तो कृपया हमें [email protected] पर ईमेल करें। हमें आपके विचार सुनना अच्छा लगेगा!
