वास्तुकला सिफारिश लोड संतुलित ASP.NET साइट

Question

अद्यतन 2009-05-21

मैं एक ही साझा नेटवर्क का उपयोग करने का # 2 विधि का परीक्षण किया गया है। यह लोड के अंतर्गत Windows Server 2003 के साथ कुछ मुद्दों में जिसके परिणामस्वरूप है:

http://support.microsoft.com/kb/810886

अंत अद्यतन

इस प्रकार है मुझे लगता है कि काम करता है एक ASP.NET वेबसाइट के लिए एक प्रस्ताव प्राप्त किया:

हार्डवेयर लोड संतुलन -> 4 IIS6 वेब सर्वर - विफलता क्लस्टर

यहाँ के साथ> एसक्यूएल सर्वर डीबी समस्या नहीं है ...

हम वेब फाइलों (एएसपीएक्स, एचटीएमएल, सीएसएस, छवियों) को स्टोर करने के लिए चुन रहे हैं। दो विकल्प प्रस्तावित किए गए हैं:

1) 4 आईआईएस सर्वरों में से प्रत्येक पर वेब फ़ाइलों की समान प्रतियां बनाएं।

2) 4 वेब सर्वरों द्वारा सुलभ नेटवर्क शेयर पर वेब फ़ाइलों की एक प्रतिलिपि रखें। 4 आईआईएस सर्वर पर वेबूटॉट को एकल नेटवर्क शेयर में मैप किया जाएगा।

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

परिप्रेक्ष्य देने के लिए, यह ऐसी वेबसाइट के लिए है जो वर्तमान में प्रति माह ~ 20 मिलियन हिट प्राप्त करती है। हालिया चोटी पर, यह प्रति सेकेंड 200 हिट प्राप्त कर रहा था।

अगर आपको ऐसे सेटअप के साथ विशेष अनुभव है तो कृपया मुझे बताएं। इनपुट के लिए धन्यवाद।

अद्यतन 2009-03-05

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

Answer 1

मैं 4 सर्वरों के बीच लोड साझा करता हूं। यह बहुत से नहीं है।

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

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

हमने 200+ वेब सर्वर फार्म में इस रणनीति का उपयोग किया और यह सेवा बाधा के बिना तैनाती के लिए अच्छी तरह से काम किया।

Answer 2

यदि आपकी मुख्य चिंता प्रदर्शन है, जो मुझे लगता है कि यह है कि आप हार्डवेयर पर यह पैसा खर्च कर रहे हैं, तो यह वास्तव में सुविधा के लिए नेटवर्क फाइल सिस्टम साझा करने के लिए समझ में नहीं आता है। यहां तक ​​कि यदि नेटवर्क ड्राइव अत्यधिक प्रदर्शन कर रहे हैं, तो वे देशी ड्राइव के साथ-साथ प्रदर्शन नहीं करेंगे।

अपनी वेब संपत्तियों को तैनात करना वैसे भी स्वचालित है (दाएं?) तो इसे गुणकों में करना वास्तव में असुविधा का अधिक नहीं है।

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

Answer 3

एक कारण केंद्रीय शेयर खराब है क्योंकि यह शेयर सर्वर पर एनआईसी को पूरे खेत के लिए बाधा बनाता है और विफलता का एक बिंदु बनाता है।

Answer 4

4 आईआईएस के साथ एनएलबी पर आपको क्या लाभ होता है, जिसे आपने ऐप सर्वर के साथ बोतलनेक के साथ खोला है।

स्केलेबिलिटी के लिए मैं फ्रंट एंड वेब सर्वर पर एप्लिकेशन की अनुशंसा करूंगा।

यहां मेरी कंपनी में हम उस समाधान को लागू कर रहे हैं। फ्रंट एंड में .NET ऐप और शेयरपॉइंट + एसक्यूएल 2008 क्लस्टर के लिए एक एपीपी सर्वर।

उम्मीद है कि यह मदद करता है!

संबंध!

Answer 5

एक समय पर एक को तैनात करने वाली प्रक्रिया के साथ एक तैनाती उपकरण का उपयोग करें और शेष प्रणाली काम करता रहता है (मुफका ने कहा)। यह एक कोशिश की गई प्रक्रिया है जो दोनों सामग्री फ़ाइलों और एप्लिकेशन के किसी भी संकलित टुकड़े (जो तैनाती एएसपीनेट प्रक्रिया के रीसायकल का कारण बनती है) के साथ काम करेगी।

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

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

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

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

अद्यतन 2: सुनिश्चित करें कि आपके डीबी परिवर्तन पीछे संगत हैं। यह वास्तव में महत्वपूर्ण है, जब आप अलग-अलग सर्वरों में परिवर्तनों को दबा रहे हैं।

Answer 6

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

हमारे पास प्रकाशक पर एक कॉन्फ़िगरेशन फ़ाइल में सेट किए गए ग्राहक हैं लेकिन आप पूरे हॉग पर जा सकते हैं और वेब ऐप ऐप स्टार्टअप पर सदस्यता स्वयं ही प्रबंधित करना आसान बनाने के लिए कर सकते हैं।

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

Answer 7

एकाधिक सर्वरों को तैनात करने की एक बहुत ही सरल विधि (एक बार नोड्स सही तरीके से सेट हो जाने पर) रोबोकॉपी का उपयोग करना है।

पसंदीदा रूप से आपके पास परीक्षण के लिए एक छोटा स्टेजिंग सर्वर होगा और फिर आप सभी परिनियोजन सर्वर (नेटवर्क शेयर का उपयोग करने के बजाय) 'robocopy' करेंगे।

रोबोकॉपी MS ResourceKit में शामिल है - इसे/एमआईआर स्विच के साथ उपयोग करें।

Answer 8

आपको विचार के लिए कुछ खाना देने के लिए आप Microsoft's Live Mesh जैसे कुछ देख सकते हैं। मैं यह नहीं कह रहा हूं कि यह आपके लिए जवाब है लेकिन इसका उपयोग करने वाला स्टोरेज मॉडल हो सकता है।

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

उदाहरण के तौर पर मैं अपने सभी कोड स्रोत फ़ाइलों को मेष फ़ोल्डर में रखता हूं और उन्हें कार्य और घर के बीच समन्वयित करता हूं। मुझे वीएस.Net, नोटपैड या किसी अन्य ऐप में फ़ाइल को सहेजने की क्रिया को सिंक करने के लिए उन्हें कुछ भी करने की ज़रूरत नहीं है, अद्यतन को शुरू करता है।

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

Answer 9

आईआईएस 6 और 7 के साथ, एन संलग्न वेब/ऐप सर्वर मशीनों में नेटवर्क एकल साझा करने का परिदृश्य स्पष्ट रूप से समर्थित है। यह सुनिश्चित करने के लिए कि यह परिदृश्य अच्छी तरह से काम करता है, एमएस ने पेर्फ परीक्षण का एक टन किया था। हाँ, कैशिंग का उपयोग किया जाता है। एक दोहरी-एनआईसी सर्वर के साथ, एक सार्वजनिक इंटरनेट के लिए और एक निजी नेटवर्क के लिए, आपको वास्तव में अच्छा प्रदर्शन मिल जाएगा। तैनाती बुलेटप्रूफ है।

इसे बेंचमार्क करने के लिए समय निकालना उचित है।

आप एएसपी.NET वर्चुअल पाथ प्रदाता का भी मूल्यांकन कर सकते हैं, जो आपको पूरे ऐप के लिए एक ज़िप फ़ाइल को तैनात करने की अनुमति देगा। या, एक सीएमएस के साथ, आप एक फाइल सिस्टम के बजाय सामग्री डेटाबेस से बाहर सामग्री की सेवा कर सकते हैं। यह संस्करण के लिए कुछ वाकई अच्छा विकल्प प्रस्तुत करता है।

VPP For ZIP via #ZipLib।

VPP for ZIP via DotNetZip।

Answer 10

अपने आईआईएस सर्वर मान लिया जाये कि विंडोज सर्वर 2003 R2 या बेहतर चल रहे हैं, निश्चित रूप से DFS Replication पर गौर। प्रत्येक सर्वर की फाइलों की अपनी प्रतिलिपि होती है जो साझा नेटवर्क बाधा को समाप्त करती है जैसे कई अन्य लोगों ने चेतावनी दी है। प्रतिस्थापन समूह (पूर्ण जाल टोपोलॉजी मानते हुए) में किसी भी सर्वर में अपने परिवर्तनों की प्रतिलिपि बनाने के रूप में परिनियोजन उतना आसान है। प्रतिलिपि स्वचालित रूप से बाकी हिस्सों का ख्याल रखती है जिसमें दूरस्थ अंतर संपीड़न का उपयोग किया जाता है, केवल बदले गए फ़ाइलों के डेल्टा भेजने के लिए।

Answer 11

मैं एक गेम वेबसाइट के विकास के प्रभारी था जिसकी एक महीने में 60 मिलियन हिट थीं। हमने जिस तरह से किया वह विकल्प # 1 था। उपयोगकर्ता के पास छवियों को अपलोड करने की क्षमता थी और ऐसे में उन लोगों को NAS में रखा गया था जो सर्वर के बीच साझा किए गए थे। यह बहुत अच्छी तरह से काम किया। मुझे लगता है कि आप घर के आवेदन पक्ष पर पेज कैशिंग भी कर रहे हैं। मैं मांग पर तैनात करता हूं, सभी सर्वरों को एक साथ सभी सर्वरों पर भी तैनात करता हूं।

Answer 12

एक आदर्श उच्च उपलब्धता की स्थिति में, विफलता का कोई भी बिंदु नहीं होना चाहिए।

उस पर वेब पृष्ठों के साथ एक बॉक्स इसका मतलब है कि नहीं-नहीं है। एक प्रमुख तेलको के लिए एचए काम करने के बाद, मैं शुरू में निम्नलिखित प्रस्तावों का प्रस्ताव दूंगा:

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

कि आप इसे कैसे अतिरिक्त हार्डवेयर के बिना कर सकते हैं। टेल्को की गुदा-धारण दुनिया में मैं के लिए काम किया, यहाँ है कि हम क्या किया होता:

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

Answer 13

हम पृष्ठों की स्थानीय प्रति और क्लस्टर पर विफल होने के साथ एक SQL सर्वर के साथ 4 वेब सर्वर का उपयोग करके बहुत खुश हैं।