विंडोज सर्वर AppFabric का परिचय। कैशिंग सेवा

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

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

Windows सर्वर AppFabric की पहली रिलीज़ में दो भाग हैं ( संस्करण 1.1 आज कई नवाचारों के साथ उपलब्ध है। - नोट प्रति। ) ।

• AppFabric कैशिंग सेवा, जो अक्सर उपयोग किए गए एप्लिकेशन डेटा तक पहुंच को तेज करता है
• सेवा AppFabric होस्टिंग सेवा, जो आपको WCF के आधार पर बनाई गई सेवाओं के लॉन्च और प्रबंधन को आसान बनाने की अनुमति देती है और विशेष रूप से विंडोज वर्कफ़्लो फाउंडेशन के आधार पर बनाई गई है

Windows Server AppFabric एप्लिकेशन सर्वर भूमिका के लिए एक्सटेंशन प्रदान करता है और ये एक्सटेंशन एक साथ या अलग से उपयोग करने के लिए स्वतंत्र हैं। यह परिचय AppFabric के दोनों हिस्सों को शामिल करता है।

AppFabric कैशिंग सेवाएँ

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

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

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

कैसे AppFabric कैशिंग सेवाओं काम करता है

AppFabric कैशिंग सेवाओं का मुख्य घटक एक कैश क्लाइंट है, जैसे ASP.NET पृष्ठ, जो कैश क्लस्टर तक पहुँचता है जिसमें कई कैश सर्वर होते हैं। प्रत्येक कैश सर्वर AppFabric कैशिंग सेवाओं का एक उदाहरण लॉन्च करता है और कैश्ड डेटा के कुछ सेट तक पहुंच बनाए रखता है। प्रत्येक कैश क्लाइंट AppFabric कैशिंग सेवाओं के साथ आपूर्ति किए गए विशेष घटकों का उपयोग करके, अपने स्थानीय डेटा कैश को भी बनाए रख सकता है। चित्र 1 सभी घटकों का आरेख दिखाता है:


चित्र 1। AppFabric कैशिंग सेवा संगठन चार्ट

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

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

विकास के स्तर पर AppFabric कैशिंग सेवाओं को "वेलोसिटी" नाम दिया गया था, एक ऐसा नाम जो इस सर्वर को ठीक से परिभाषित करता है: यह आपको डेटा को तेजी से बार-बार अनुरोध करने की अनुमति देता है। डेटाबेस में कई समान प्रश्न करने के बजाय, यह सेवा आपको स्थानीय या वितरित मेमोरी से सीधे डेटा प्राप्त करने की अनुमति देती है। उन अनुप्रयोगों के लिए जो अक्सर एक ही डेटा का अनुरोध करते हैं, लेकिन उनमें से बहुत सारे हैं, कैशिंग काफी प्रदर्शन और मापनीयता में सुधार करते हैं।

AppFabric कैशिंग सेवाओं को .NET अनुप्रयोगों के साथ उपयोग के लिए डिज़ाइन किया गया है, इसलिए कैश्ड डेटा को .NET ऑब्जेक्ट में क्रमबद्ध किया जा सकता है। एक बार कैश में एक वस्तु रखने के बाद, क्लाइंट इसे अपडेट कर सकता है या कैश से निकाल सकता है। स्टोरेज अवधि समाप्त होने या कैश में अधिक प्रासंगिक डेटा रखने की आवश्यकता के कारण कैश में संग्रहीत आइटम को सेवा से कैश से भी हटाया जा सकता है। स्थानीय कैश में डेटा पुराना भी हो सकता है, इसके अलावा, स्थानीय डेटा को परिवर्तनों और तुल्यकालिक विलोपन के लिए वितरित कैश से समान डेटा के साथ सिंक्रनाइज़ किया जा सकता है।

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

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

लेकिन क्या होगा जब लगातार बदलते रहने वाले डेटा को बड़ी संख्या में ग्राहकों द्वारा एक साथ उपभोग किया जाना चाहिए? इस मामले में कैशिंग का भी उपयोग किया जा सकता है, लेकिन एक चेतावनी के साथ: एक साथ अभिगम नियंत्रण आवश्यक है। इस समस्या को हल करने के लिए, AppFabric कैशिंग सेवाएँ स्पष्ट लॉक का उपयोग करके संस्करण संख्या असाइनमेंट और निराशावादी समवर्ती अभिगम नियंत्रण के आधार पर दोनों आशावादी समवर्ती अभिगम नियंत्रण का समर्थन करती हैं।

परिदृश्य: ASP.NET अनुप्रयोग में कैशिंग का उपयोग करना

ASP.NET अनुप्रयोग AppFabric कैशिंग सेवाओं के लिए सबसे महत्वपूर्ण ग्राहक हैं। जैसा कि पहले कहा गया है, ASP.NET सत्र ऑब्जेक्ट में संग्रहीत डेटा कैशिंग के लिए सबसे स्पष्ट उम्मीदवार है। वास्तव में, सेवा इसके लिए अंतर्निहित समर्थन प्रदान करती है - डेवलपर को केवल कॉन्फ़िगरेशन विकल्प सेट करने की आवश्यकता होती है और सत्र ऑब्जेक्ट पारदर्शी रूप से कैश क्लस्टर में संग्रहीत किया जाएगा। कृपया ध्यान दें: इसका मतलब है कि ASP.NET डेवलपर्स अपने एप्लिकेशन कोड को संशोधित किए बिना वितरित कैशिंग का लाभ उठा सकते हैं। यह सत्र डेटा को संग्रहीत करने के लिए SQL सर्वर का उपयोग किए बिना ASP.NET के चल रहे इंस्टेंस के वेब सर्वरों की कई प्रतियों की अनुमति देता है। चित्र 2 दिखाता है कि यह तंत्र कैसे काम करता है:


अंजीर। २। कैसे ASP.NET अनुप्रयोग AppFabric कैशिंग सेवाओं के साथ काम करते हैं

यह सरल परिदृश्य उपयोगकर्ता द्वारा कुछ जानकारी भेजने के साथ शुरू होता है जो ASP.NET उपयोगकर्ता सत्र ऑब्जेक्ट (चरण 1) में संग्रहीत करता है। अनुरोध को संसाधित करने वाले वेब सर्वर को AppFabric कैशिंग सेवाओं के क्लस्टर में सत्र सत्र ऑब्जेक्ट के लिए कॉन्फ़िगर किया गया है और इसलिए उपयोगकर्ता डेटा को एक या अधिक कैश सर्वर (चरण 2) के लिए लिखा जाता है। उपयोगकर्ता से अगला अनुरोध चरण 1 में संग्रहीत डेटा पर आधारित है, लेकिन यह अनुरोध पहले से ही किसी अन्य सर्वर (चरण 3) द्वारा संसाधित किया जा रहा है। इस सर्वर पर ASP.NET कोड समान सत्र ऑब्जेक्ट तक पहुँचता है, जिसका अर्थ है डेटा एक्सेस (चरण 4) के लिए कैश क्लस्टर के लिए पारदर्शी पहुंच। यह चरण 1 में प्राप्त जानकारी को आवेदन के लिए उपलब्ध होने की अनुमति देता है। कृपया ध्यान दें कि हमें जानकारी संग्रहीत करने के लिए डेटाबेस के साथ काम नहीं करना था, और उपयोगकर्ता अनुरोधों को संसाधित करने के लिए हमें उसी सर्वर की भी आवश्यकता नहीं है। इस बुनियादी ढांचे का परिणाम प्रदर्शन में वृद्धि हुई है और ASP.NET अनुप्रयोगों की बेहतर क्षमता है।

परिदृश्य: उच्च उपलब्धता का उपयोग करना

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


चित्र 3। उच्च उपलब्धता AppFabric कैशिंग सेवाएँ

इस उदाहरण में, HA तंत्र को बंद कर दिया गया है, ताकि कैश्ड डेटा के प्रत्येक आइटम को दो अलग-अलग कैश सर्वरों में संग्रहीत किया जाए। प्राथमिक प्रतिलिपि, आंकड़े में बाढ़ के रूप में दिखाई गई, डेटा के साथ सभी परिवर्तनों को स्वीकार करती है। इन परिवर्तनों को स्वचालित रूप से द्वितीयक प्रतिलिपि के लिए दोहराया जाता है, एक खाली आकृति के रूप में प्रस्तुत किया जाता है। यहां, X डेटा की प्राथमिक प्रतिलिपि वाले कैश सर्वर अनुपलब्ध (अनुसूचित या यादृच्छिक, चरण 1) बन जाता है। जब कैश क्लाइंट X डेटा (चरण 2) का अनुरोध करता है, तो कैश क्लस्टर द्वितीयक प्रतिलिपि के अनुरोध को सावधानीपूर्वक पुनर्निर्देशित करता है और मान (चरण 3) लौटाता है।

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

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

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

शुरू किया जाए, जारी रखा जाए।