वैश्विक उच्च उपलब्धता सेटअप प्रश्न


10

मैं विज़ुअलाइवसाइटॉप्टीमाइज़र.कॉम / का स्वामित्व और संचालन करता हूं । ऐप एक कोड स्निपेट प्रदान करता है जिसे मेरे ग्राहक अपनी वेबसाइट में कुछ मीट्रिक को ट्रैक करने के लिए डालते हैं। चूंकि कोड स्निपेट बाहरी जावास्क्रिप्ट (साइट कोड के शीर्ष पर) है, ग्राहक वेबसाइट दिखाने से पहले, एक आगंतुक ब्राउज़र हमारे ऐप सर्वर से संपर्क करता है। यदि हमारा ऐप सर्वर नीचे चला जाता है, तो ब्राउज़र बार (आमतौर पर 60 सेकंड) से पहले कनेक्शन स्थापित करने का प्रयास करता रहेगा। जैसा कि आप कल्पना कर सकते हैं, हम अपने ऐप सर्वर को किसी भी परिदृश्य में रखने का जोखिम नहीं उठा सकते क्योंकि यह न केवल हमारी वेबसाइट आगंतुकों बल्कि हमारे ग्राहकों की वेबसाइट आगंतुकों के अनुभव को भी नकारात्मक रूप से प्रभावित करेगा!

हम वर्तमान में एक अलग डेटा सेंटर (वास्तव में अलग महाद्वीप) में स्थित एक बैकअप सर्वर के साथ डीएनएस फेलओवर तंत्र का उपयोग कर रहे हैं। यही है, हम अपने ऐप सर्वर को 3 अलग-अलग स्थानों से मॉनिटर करते हैं और जैसे ही इसका पता चलता है, हम बैक अप सर्वर आईपी को इंगित करने के लिए एक रिकॉर्ड बदलते हैं। यह अधिकांश ब्राउज़रों के लिए ठीक काम करता है (जैसा कि हमारा टीटीएल 2 मिनट है) लेकिन IE 30 मिनट के लिए डीएनएस को कैश करता है जो एक सौदा हत्यारा हो सकता है। हमारा हाल ही का यह पोस्ट देखें visualwebsiteoptimizer.com/split-testing-blog/maximum-theoretical-downtime-for-a-website-30-minutes/

तो, ऐप डेटा सेंटर प्रमुख आउटेज से पीड़ित होने पर लगभग तत्काल विफलता सुनिश्चित करने के लिए हम किस तरह के सेटअप का उपयोग कर सकते हैं? मैंने यहां पढ़ा www.tenereillo.com/GSLBPageOfShame.htm कि एकाधिक ए रिकॉर्ड होना एक समाधान है, लेकिन हम सत्र तुल्यकालन (अभी तक) बर्दाश्त नहीं कर सकते। एक और रणनीति जो हम खोज रहे हैं, दो ए रिकॉर्ड्स हैं, एक ऐप सर्वर की ओर इशारा करता है और दूसरा एक रिवर्स प्रॉक्सी (एक अलग डेटा सेंटर में स्थित) के लिए है जो मुख्य ऐप सर्वर पर होता है, अगर यह ऊपर है और बैकअप सर्वर के लिए है। क्या आपको लगता है कि यह रणनीति उचित है?

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

संदर्भ: मैंने इस सूत्र को पढ़ा था जो उपयोगी सर्वरफॉल्ट.com/questions/69870/multiple-data-centers- and- http-traffic-dns-round-robin-is-the-only-way-to-assure

जवाबों:


6

आपकी स्थिति काफी हद तक हमारे जैसी ही है। हम स्प्लिट डेटासेंटर और नेटवर्क-लेयर टाइप फेलओवर चाहते हैं।

यदि आपको इसे करने के लिए बजट मिल गया है, तो आप जो चाहते हैं, वह है दो डाटाकेंटर, कई आईपी प्रत्येक में पारगमन, एक एज राउटर की एक जोड़ी जो आपके ट्रांजिट प्रदाताओं को बीजीपी सत्र कर रही है, आपके आईपी पते को वैश्विक इंटरनेट पर विज्ञापित करती है।

यह सच्चा असफल होने का एकमात्र तरीका है। जब राउटर यह नोटिस करते हैं कि आपके सर्वर का मार्ग अब वैध नहीं है (जो आप कई तरीकों से कर सकते हैं), तो वे उस मार्ग का विज्ञापन करना बंद कर देते हैं, और ट्रैफ़िक दूसरी साइट पर चला जाता है।

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

बीजीपी मल्टीहोमेड / बहु-स्थान सर्वोत्तम अभ्यास और लचीलापन में सुधार करने का सबसे अच्छा तरीका? ऐसे सवाल हैं जो मैंने इसी तरह के मुद्दों के बारे में पूछा।

शर्म का GSLB पेज कुछ महत्वपूर्ण बिंदुओं को बढ़ाता है, यही कारण है कि, व्यक्तिगत रूप से मैं कभी भी बीजीपी रूटिंग का काम करने के लिए जीएसएलबी नहीं चुनूंगा।

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

मूल रूप से, मल्टीपल A रिकॉर्ड्स के माध्यम से DNS "लोड बैलेंसिंग" सिर्फ "लोड-शेयरिंग" है क्योंकि DNS सर्वर के पास इस बात की कोई अवधारणा नहीं है कि प्रत्येक सर्वर पर कितना लोड है। यह सस्ता (मुफ्त) है।

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

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


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

1
मैं आज रात अपने ब्लॉग पर एक निबंध के रूप में लिखने जा रहा हूं, मुझे लगता है। आपके लिए एज राउटर के लिए सबसे सस्ता समाधान, डेल आर 200 की एक जोड़ी होगी, जिसमें कुछ अतिरिक्त एनआईसी और प्रत्येक के साथ रैम (4-6 जीबी पर्याप्त होना चाहिए) है, फिर फ्रीबीएसडी और क्वागा, या सीआईआरडी जैसे कुछ चलाएं।
टॉम ओ'कॉनर

बहुत खुबस! मैं इसे जांचना सुनिश्चित करूंगा। कृपया इस धागे को लिंक से अपडेट करें ताकि मैं इसे याद न करूँ।
पारस चोपड़ा

एल-टाइपो राउटर समाधान पर +1 - हम वास्तव में महान परिणामों के साथ मेरी कंपनी में फ्रीबीएसडी राउटर चला रहे हैं। यदि आप कुछ अधिक वाणिज्यिक चाहते हैं (लेकिन अभी भी तुलनीय सिस्को गियर की तुलना में सस्ता है) जुनिपर नेटवर्क गियर (www.juniper.net) भी एक अच्छा विकल्प हो सकता है।
voretaq7

4

ठीक है, यह कुछ समय पहले पूछा गया था, लेकिन मैं इसे अब देख रहा हूं।

कोड स्निपेट बाहरी जावास्क्रिप्ट है (साइट कोड के शीर्ष पर), ग्राहक वेबसाइट दिखाने से पहले, एक आगंतुक ब्राउज़र हमारे ऐप सर्वर से संपर्क करता है।

तुम्हे करना चाहिए:

  1. अपनी जावास्क्रिप्ट फ़ाइल को एक अच्छे, पेशेवर कंटेंट डिलीवरी नेटवर्क पर रखें, यानी किसी ऐसे व्यक्ति से जावास्क्रिप्ट की सेवा लें जो पहले से ही उस विशेषज्ञता का है।
  2. अपने जावास्क्रिप्ट को प्रोग्राम करें ताकि एक अच्छी कमबैक स्थिति हो, यानी यदि आपका ऐप सर्वर जल्दी से प्रतिक्रिया नहीं देता है, तो अंतिम उपयोगकर्ता एक सामान्य, अनमॉडिफाइड पृष्ठ देखता है।

और कुछ भी करना गैर जिम्मेदाराना है। मुझे लगता है कि आपके पास पहले से ही यह जगह है।

आपको अपनी सेवा को बीजीपी रूटिंग ट्रिक पर आधारित नहीं करना चाहिए, जब तक कि आपके पास ऐसा करने के लिए पता या प्राप्त न हो। जटिल बीजीपी रूटिंग परिदृश्यों को लागू करने के लिए निश्चित रूप से गैर-तुच्छ हैं; यदि आपके पास डोमेन विशिष्ट ज्ञान नहीं है, तो इसे स्वयं न करें।

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


1

वास्तव में, आप जो चाहते हैं, उसे आपकी विभाजित परीक्षण गतिविधियों में मदद करने के लिए अपग्रेड किया जा सकता है, यदि आप जियोडन्स और डीएनएस फेलओवर को जोड़ते हैं।

समूह ए को आईपी 1 और ग्रुप बी को आईपी 2 में भेजना, भले ही वे एक ही सर्वर पर हों, आपको अपने परीक्षण समूहों को अलग करने देगा। ग्रुप ए और ग्रुप बी विभिन्न भौगोलिक क्षेत्रों से हैं। निष्पक्ष होने के लिए, अगले दिन / सप्ताह / महीने, आप समूहों को फ्लिप करते हैं ताकि यह सुनिश्चित हो सके कि आप भौगोलिक अंतर के लिए अनुमति देते हैं। बस अपनी कार्यप्रणाली में कठोर होना चाहिए।

पर geodns / विफलता DNS सेवा http://edgedirector.com ऐसा कर सकते हैं

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.