VPN फ़ाइल शेयरों के लिए BranchCache: कब मदद करता है, कब नहीं

टीम में कोई कहता है कि VPN पर फ़ाइल शेयर धीमा है, और पहला सुझाव हमेशा कैश होता है। रिमोट-एक्सेस डिज़ाइन में BranchCache जोड़ने से पहले शिकायत को तीन रूपों में से एक में बाँटें: बिना बदले कंटेंट के दोहराए जाने वाले डाउनलोड, अपलोड, या हज़ारों प्रविष्टियों वाले फ़ोल्डरों में मेटाडेटा-भारी ब्राउज़िंग। BranchCache समर्थित कंटेंट पर पहले रूप को संबोधित करता है और बाकी दो के लिए कुछ उपयोगी नहीं करता। यह ऐसी सीमा नहीं है जिसे दरकिनार करना हो; यह वह तुलना है जो आपको परिनियोजन पर एक हफ़्ता लगाने से पहले करनी चाहिए।

वही शेयर, तीन अलग शिकायतें

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

घरेलू कनेक्शन से नई रिकॉर्डिंग अपलोड करता लैपटॉप उल्टा मामला है। ऐसी फ़ाइल की पहले से कैश की गई प्रति नहीं होती जो अभी बनी ही नहीं, इसलिए अपलोड वही सीमित रास्ता लेता है जो हमेशा लेता था। डाउनलोड कैश अपलोड को नहीं हटाता, और कोई भी प्लेसमेंट विकल्प इसे नहीं बदलता।

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

वितरित कैश: VPN पूल शाखा LAN नहीं है

वितरित मोड में क्लाइंट कंप्यूटर एक-दूसरे के साथ कैश किया गया कंटेंट साझा करते हैं, और Microsoft उस मोड को एक ही सबनेट के भीतर काम करने वाला बताता है। VPN क्लाइंट पूल उस अर्थ में सबनेट नहीं है, भले ही सभी पते सटे हुए लगें: पीयर खोज, क्लाइंट-से-क्लाइंट पहुँच, और कैश डेटा का आदान-प्रदान करने की अनुमति अलग-अलग प्रश्न हैं, और सामान्य रिमोट-एक्सेस डिज़ाइन तीनों का उत्तर «नहीं» देता है।

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

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

होस्टेड कैश: प्लेसमेंट तय करता है कि वह मदद करेगा या नहीं

होस्टेड कैश साझा कैश को सर्वर पर रखता है, जो सबनेट के पार एकमात्र समझदार मोड है और तब काम करने वाला एकमात्र मोड है जब क्लाइंट आपस में बात नहीं कर सकते। तुरंत सवाल यह है कि वह सर्वर कहाँ है। यदि होस्टेड कैश उसी सीमित लिंक से पहुँचा जाता है जिससे ओरिजिन, तो उसने बाइट्स को स्थानांतरित किया है, समस्या को नहीं।

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

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

Enable-BCHostedServer -RegisterSCP
Get-BCStatus | Select-Object BranchCacheIsEnabled, ClientMode, HostedCacheServerList

क्लाइंट पर या तो उसे नामित सर्वरों की ओर इंगित करें या उसे सेवा कनेक्शन पॉइंट के माध्यम से उन्हें खोजने दें; फिर उस मोड की पुष्टि करें जो उसने वास्तव में चुना, बजाय यह मानने के कि नीति लागू हो गई:

Enable-BCHostedClient -ServerNames cache1.corp.example -UseSCP
Get-BCStatus | Select-Object BranchCacheIsEnabled, ClientMode

ओरिजिन तक अब भी क्या पहुँचता है

कैश अधिकृति को नहीं हटाता। जिस क्लाइंट के पास फ़ाइल पढ़ने की अनुमति नहीं है, उसे इसलिए पहुँच नहीं मिल जाती कि किसी और ने उसे कैश किया, और ओरिजिन अब भी अधिकृति के प्रश्न का उत्तर देता है और वह कंटेंट जानकारी देता है जिससे कैश में खोज संभव होती है। यदि ओरिजिन तक पहुँच न हो, तो अकेली कैश की गई प्रति ऑफ़लाइन शेयर नहीं बन जाती।

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

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

इसे दो पुनःप्राप्तियों और एक अपलोड के साथ स्वीकार करें

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

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

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