वेब साइट के लिए उच्च उपलब्धता को पेश करने का सही समय कब है?

Question

वेब साइट के लिए उच्च उपलब्धता को पेश करने का सही समय कब है?

उच्च उपलब्धता विकल्पों पर कई लेख हैं। हालांकि यह स्पष्ट नहीं है कि एकल सर्वर से उच्च उपलब्धता कॉन्फ़िगरेशन पर स्विच करने का सही समय कब है।

कृपया मेरी स्थिति पर विचार करें:
http://www.postjobfree.com महत्वपूर्ण यातायात के साथ 24/7 वेब साइट है:
http://www.similarweb.com/website/postjobfree.com

वर्तमान में मैं इसे एक एकल सर्वर पर चलाता हूं: IIS 7.0 वेब सर्वर और SQL Server 2008 दोनों एक ही हार्डवेयर बॉक्स पर चलते हैं।

सामयिक (~ प्रति माह एक) ~ 5 मिनट डाउनटाइम आमतौर पर कुछ विंडोज सर्वर अपडेट द्वारा आवश्यक रिबूट के कारण होता है। आमतौर पर डाउनटाइम निर्धारित होता है और रात में होता है। अभी भी यह अप्रिय है, क्योंकि Google बीओटी और कुछ उपयोगकर्ता अभी भी रात में सक्रिय हैं।

वर्तमान वेब साइट का राजस्व ~ $ 8K / माह है।

मैं दो-सर्वर कॉन्फ़िगरेशन (2 वेब सर्वर के वेब फार्म और 2 हार्डवेयर सर्वर पर होस्ट किए गए 2 SQL सर्वर के क्लस्टर) पर स्विच करने पर विचार करता हूं।

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

विपक्ष:
1) ऐसे कॉन्फ़िगरेशन को सेटअप करने और बनाए रखने के लिए अधिक प्रयास।
2) उच्च होस्टिंग लागत। ~ $ 600 / माह के बजाय यह लगभग $ 1200 / महीना होगा।

आपकी सिफारिश क्या होगी?

Comments

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

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

— इवान लेथ

मुझे लगता है कि परियोजना की अवधारणा के पहले क्षण से उच्च उपलब्धता की योजना बनाई जानी चाहिए।

— टॉम ओ'कॉनर

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

— डेनिस गोरेलिक

Windows अद्यतन सुरक्षा अद्यतन के साथ आ रहे हैं। यदि मैं अपने सर्वर को पैच नहीं करता हूं, तो यह हमलों के लिए असुरक्षित हो सकता है। Windows उत्पादन सर्वर के लिए आप किस अद्यतन आवृत्ति की सिफारिश करेंगे?

— डेनिस गोरेलिक

Answer 1

संक्षिप्त उत्तर: जब समय कम होता है या इसका जोखिम आपको अधिक होता है तो आपको इसकी उपलब्धता अधिक होगी।

यह मौलिक रूप से एक आर्थिक निर्णय है। उदाहरण के तौर पे। $ 8k / महीना का तात्पर्य है कि 2 घंटे का एक आउटेज आपको $ 22 का खर्च देगा। यदि आप अपने सिस्टम को इस तरह कॉन्फ़िगर कर सकते हैं कि आप स्क्रैच से पूरी तरह कार्यात्मक साइट पर 2 घंटे में जा सकते हैं, तो उच्च उपलब्धता आपको केवल इसके ऊपर $ 22 की कार्यक्षमता प्राप्त होगी।

एक और तरीका रखो, आप पैसे को तब तक बचा सकते हैं जब तक / जब तक आपके पास किसी दिए गए महीने में 54 घंटे की अनुपलब्ध डाउन-टाइम न हो।

Comments

आपको प्रतिष्ठा के लिए भी जोखिम पर विचार करना होगा

— gbn

सर्वर डाउन होने पर डाउनटाइम की प्रति घंटे की लागत लगभग निश्चित रूप से बस पर निर्भर करेगी। लेन-देन 24 घंटे की अवधि में समान रूप से फैलने की संभावना नहीं है। यह केवल कुछ पीक घंटों के दौरान होने के लिए सामान्य है, जिस समय नुकसान बहुत अधिक होगा।

— जॉन गार्डनियर्स

Slartibartfast, मैं आपके उत्तर को इस तरह से समझता हूं: सुनिश्चित करें कि विनाशकारी विफलता के बाद की वसूली का समय उचित है (कुछ घंटे), डेटा हानि उचित (कुछ घंटे) है, और अपने आप को समय-समय पर कम समय (कम से कम अब) करने की अनुमति दें । इसका मतलब यह होगा कि दैनिक बैकअप, वृद्धिशील आंशिक बैकअप, और एक सर्वर उपलब्ध है जो उस कॉन्फ़िगरेशन को पुनर्स्थापित करने के लिए उपलब्ध है। क्या यह सही लगता है?

— डेनिस गोरेलिक

प्रतिक्रियाएं: gbn: सहमत; मैं एक सरल स्पष्टीकरण के लिए जा रहा था, लेकिन प्रतिष्ठा आसानी से एक महत्वपूर्ण कारक हो सकती है। जॉन गार्डनियर्स: ज़रूर, लेकिन अगर साइट का उपयोग केवल रविवार को सुबह 11 बजे और 1 बजे के बीच किया जाता है, तो निर्धारित समय वास्तव में कोई समस्या नहीं है, जबकि अनियोजित 2 घंटे के आउटेज के लिए $ 2k मूल्य का टैग right_then है। उस बिंदु पर आपको यह पता लगाना होगा कि Addnl सर्वर के लिए $ 600 / माह के शुल्क के मुकाबले असमान रूप से आउटेज ($ 2k राजस्व लागत पर) कितना है। संकेत: जब तक कि महत्वपूर्ण अवधि के दौरान यादृच्छिक विफलता 4 / वर्ष से अधिक बार न हो, यह इसके लायक नहीं है।

— Slartibartfast

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

— Slartibartfast

Answer 2

आपके हितधारकों / व्यापार लोक (जो आप हो सकते हैं!) को तय करना होगा

• राजस्व का स्वीकार्य नुकसान
• प्रतिष्ठा, सम्माननीयता आदि की हानि
• स्वीकार्य डेटा हानि ( पुनर्प्राप्ति बिंदु उद्देश्य )
• स्वीकार्य डाउनटाइम ( रिकवरी टाइम ऑब्जेक्टिव )

राजस्व का नुकसान आसान है: बाकी का जवाब यहां नहीं दिया जा सकता है ...

Answer 3

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

यदि आप वास्तव में केवल एक महीने में 5 मिनट की बात कर रहे हैं, तो आप इसे उस परिप्रेक्ष्य में रखेंगे, आप sysadmin के रूप में काफी अच्छा काम कर रहे हैं।

Answer 4

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

Answer 5

ध्यान रखें कि सुरक्षा की तरह हा, एक उत्पाद नहीं है, बल्कि एक प्रक्रिया है।

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

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

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

Answer 6

जब आप इस बारे में सोचते हैं तो मुझे लगता है कि आप "विफल व्हेल" पृष्ठ स्थापित करने पर विचार करते हैं।

ऐसा करने के लिए बहुत सारे तरीके हैं लेकिन मार्ग53 और 3 के कॉम्बो aws मेरे छोटे साइटों पर अच्छी तरह से काम करते हैं।

मैंने Healthchecks के साथ डोमेन सेटअप किया है ताकि विफलताओं पर DNS उपयोगकर्ताओं को उपयोगकर्ताओं को s3 में बैठे एक स्थिर HTML पेज पर भेज सके; कुछ भी नहीं के बगल में लागत।

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

यह "प्रतिष्ठा की हानि" को कम करने के लिए एक लंबा रास्ता तय करता है जो एक आउटेज का सबसे महत्वपूर्ण प्रभाव हो सकता है।

देखें: https://aws.amazon.com/blogs/aws/create-a-backup-website-use-route-53-dns-failover-and-s3-website-hosting/ इसे स्थापित करने के लिए एक गाइड के लिए।

डायडन्स की सामाजिक विफलता http://dyn.com/managed-dns/social-failover/ एक प्रकार की चीज़ है।

आप अपना रोल कर सकते हैं और अपने स्वास्थ्य परीक्षण कर सकते हैं और फिर डीएनएस परिवर्तनों को स्क्रिप्ट कर सकते हैं, बशर्ते आपके डीएनएस रिकॉर्ड में कम टीटीएल हो और आपके पास प्रोग्राम में हेरफेर करने का कोई तरीका हो।

Comments

क्या इन स्वास्थ्य सेवाओं को उसी सर्वर से निष्पादित किया जाना है जो DNS को होस्ट करता है? मैं सशर्त DNS अद्यतन बनाने के लिए चित्र नहीं कर सकता।

— डेनिस गोरेलिक

@DennisGorelik नहीं necesaririly लेकिन आपके DNS रिकॉर्ड्स को एक छोटे TTL की आवश्यकता है और जो कुछ भी कर रहा है वह आपके स्वास्थ्य परीक्षण को जल्दी से रिकॉर्ड बदलने में सक्षम होने की आवश्यकता है। इसे प्राप्त करने के तरीके के बारे में अधिक जानकारी के साथ उत्तर को अपडेट करें।

— नाथ

स्वास्थ्य जांच पर निर्भरता के साथ संयोजन में DNS के लिए शॉर्ट टीटीएल समग्र प्रणाली को थोड़ा कम स्थिर बना सकता है (यह मुख्य सर्वर के ठीक काम करने पर भी स्विच हो सकता है)। यह वास्तव में अंत उपयोगकर्ताओं के लिए स्थिति को बदतर बना सकता है, बेहतर नहीं।

— डेनिस गोरेलिक

शॉर्ट टीटीएल अपने आप में किसी भी सभ्य डीएनएस प्रदाता के साथ एक मुद्दा नहीं होना चाहिए और यदि आप अपने हेल्थकेयर पर बहुत कम बार सेट करते हैं (यानी विफलता अगर कोई http 200 मिनट 10 मिनट के लिए नहीं है) तो स्थिरता एक मुद्दा नहीं है। वैकल्पिक रूप से आप स्वास्थ्यवर्धक भाग को छोड़ सकते हैं और मैन्युअल कटओवर कर सकते हैं। इसका मतलब यह होगा कि आपके उपयोगकर्ताओं को "कनेक्शन टाइम आउट" और अन्य बदसूरत त्रुटियों के समय की लंबी अवधि मिलेगी, लेकिन झूठी सकारात्मकता का कोई मौका नहीं।

— नाथ

Answer 7

क्या आपने EC2 जैसी किसी चीज़ का उपयोग करने पर विचार किया है जो आपको लचीले ढंग से स्केल करेगा और आपके विपक्ष को भी नकार देगा? यह अंततः एक आर्थिक निर्णय है यदि EC2 का उपयोग करना इसके लायक है या नहीं, लेकिन यह कम से कम, विचार करने का एक विकल्प है।

Answer 8

डेटा हानि से बचने के लिए, आपको क्लस्टर से पहले RAID कॉन्फ़िगरेशन में देखना चाहिए। आपको Failover IP को भी कॉन्फ़िगर करना चाहिए जिसे आप DNS प्रसार के लिए प्रतीक्षा किए बिना आपदा के मामले में एक सर्वर से दूसरे सर्वर पर स्विच कर सकते हैं।

Comments

यह कहां से आता है? आपको क्या लगता है कि पोस्टर पहले से ही RAID का उपयोग नहीं कर रहा है?

— चॉपर 3

Chopper3। मैंने केवल इतना कहा है कि RAID अपनी डेटा हानि की समस्या को हल करेगा।

— 14:14 बजे

कैसे? अगर एक डिस्क निश्चित रूप से मर गया, लेकिन क्या हुआ अगर उसका नियंत्रक खराब हो गया

— चॉपर 3