सक्रिय सेवाओं को अत्यधिक उपलब्ध कैसे करें?

Question

मुझे पता है कि Network Load Balancing और Failover Clustering के साथ हम निष्क्रिय सेवाएं अत्यधिक उपलब्ध करा सकते हैं। लेकिन सक्रिय ऐप्स के बारे में क्या?

उदाहरण: मेरे ऐप्स में से एक एक निश्चित अंतराल में बाहरी संसाधन से कुछ सामग्री पुनर्प्राप्त करता है। मैंने निम्नलिखित परिदृश्यों की कल्पना की है:

1. इसे एक मशीन में चलाएं। समस्या: यदि यह उदाहरण गिरता है, तो सामग्री को पुनर्प्राप्त नहीं किया जाएगा
2. क्लस्टर की प्रत्येक मशीन में इसे चलाएं। समस्या: सामग्री को कई बार पुनर्प्राप्त किया जाएगा
3. इसे क्लस्टर की प्रत्येक मशीन में रखें, लेकिन इसे केवल उनमें से एक में चलाएं। प्रत्येक उदाहरण को यह तय करने के लिए किसी प्रकार का सामान्य संसाधन जांचना होगा कि क्या यह कार्य करने की बारी है या नहीं।

जब मैं समाधान # 3 के बारे में सोच रहा था तो मुझे आश्चर्य हुआ कि आम संसाधन क्या होना चाहिए। मैंने डेटाबेस में एक टेबल बनाने का विचार किया है, जहां हम इसे वैश्विक लॉक प्राप्त करने के लिए उपयोग कर सकते हैं।

क्या यह सबसे अच्छा समाधान है? लोग आमतौर पर ऐसा कैसे करते हैं?

वैसे यह एक सी # .NET WCF विंडोज सर्वर 2008

Answer 1

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

मैं दुनिया के जावा ईई पक्ष पर कर रहा हूँ तो कोडिंग विवरण

Answer 2

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

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

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

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

Answer 3

मैंने एक बार आपके समाधान # 3 का उपयोग करके कुछ ऐसा ही लागू किया है।

कॉलम के साथ resource_lock जैसे कुछ तालिका बनाएं (उदा।locking_key) जिसमें लॉकिंग कुंजी होगी।

प्रत्येक अंतराल पर

फिर, अपने एप्लिकेशन के सभी उदाहरण होगा:

1. भागो एक 'update resource_lock set resource_key = 1 where resource_key is null' जैसी क्वेरी। (आप निश्चित रूप से एक सर्वर-विशिष्ट आईडी, एक टाइमस्टैम्प इत्यादि भी डाल सकते हैं)
2. यदि 0 पंक्तियां अपडेट की गई हैं: कुछ भी नहीं करें - एक और ऐप इंस्टेंस पहले ही संसाधन ला रहा है।
3. यदि 1 पंक्ति अपडेट की गई है: संसाधन प्राप्त करें और locking_key पर null पर सेट करें।

इस के साथ दो फायदे होते हैं:

• अपने सर्वरों में से एक विफल रहता है, संसाधन अभी भी सर्वर अभी भी चल रहे द्वारा दिलवाया जाएगा।
• आप लॉकिंग को डेटाबेस में छोड़ देते हैं, यह आपको इसे स्वयं लागू करने से बचाता है।

Answer 4

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

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

आपके आवेदन के लिए "सक्रिय" होने के नाते, यह आवश्यकता इस समीकरण में कारक नहीं है क्योंकि 'सक्रिय' या 'निष्क्रिय', एप्लिकेशन अभी भी आपके सर्वर से अनुरोध करता है।

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

Win2k8 में कॉन्फ़िगर करने के तरीके के बारे में अधिक जानकारी के लिए, this आलेख देखें।

this article अधिक तकनीकी है और एक्सचेंज के साथ एनएलबी का उपयोग करने पर केंद्रित है, लेकिन सिद्धांतों को अभी भी आपकी स्थिति पर लागू होना चाहिए।

see here एनएलबी सेटअप और कॉन्फ़िगरेशन के एक और विस्तृत चलने के लिए।

विफल होने पर, आपको सर्वरफॉल्ट पर खोज/पोस्ट करके अच्छी तरह से सेवा दी जा सकती है, क्योंकि आपका आवेदन कोड (और नहीं होना चाहिए) सख्ती से पता है कि एनएलबी भी मौजूद है।

संपादित करें: एक और लिंक जोड़ा गया।

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

Answer 5

ऐसी कुछ आवश्यकताएं हैं जिन्हें आप शायद जानते हैं लेकिन इस प्रश्न में वर्णित नहीं किया गया है कि एक सूचित उत्तर चुनौतीपूर्ण है। इनमें से कुछ प्रश्न हैं:

• क्या कार्य को सफलतापूर्वक पूरा करना है?
• यदि कार्य सफलतापूर्वक पूरा नहीं होता है, तो "कौन" को जानने की आवश्यकता है और किस प्रकार के कार्यों को करने की आवश्यकता है?
• यदि कार्य फिर से चलाने के लिए समय आता है तो कार्य पूरा नहीं हुआ है तो व्यवहार क्या है? क्या इसे चलाना चाहिए या नहीं?
• यह कितना महत्वपूर्ण है कि निर्दिष्ट अंतराल पर नौकरियां चलती हैं? यदि अंतराल हर 5 मिनट में होता है तो क्या यह हर 5 मिनट हो सकता है या क्या कार्य 5 मिनट और 10 सेकंड के बाद चल सकता है?

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

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

एक और विकल्प कतार मॉडल का उपयोग करेगा। यह ज्यादातर स्थितियों में सबसे विश्वसनीय होगा। जैसे SQL सर्वर एजेंट एक कतार तालिका में रिकॉर्ड दर्ज करने के लिए संग्रहीत प्रक्रिया निष्पादित कर सकता है। फिर प्रत्येक एप्लिकेशन सर्वर पर एक सेवा प्रक्रिया के लिए एक कतारबद्ध रिकॉर्ड की तलाश कर सकता है। कतार में रिकॉर्ड तक पहुंच डेटाबेस द्वारा क्रमबद्ध की जाएगी ताकि पहला सर्वर नौकरी चलाएगा (और वह नौकरी केवल एक बार चलती है)।

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

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

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

Answer 6

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

भी Netflix क्यूरेटर व्यंजनों के बहुत पहले से ही किया है और उपयोग करने के लिए है। पसंद: नेता चुनाव, वितरित ताला और कई और।

मुझे लगता है हम सी # के लिए चिड़ियाघर संचालक की ग्राहक है। आपको निश्चित रूप से इन विकल्पों का प्रयास करना चाहिए। # Option3