VPN फाइल शेअर्ससाठी BranchCache: कधी उपयोगी, कधी नाही

टीममधील कोणीतरी म्हणतो की VPN वरील फाइल शेअर हळू आहे, आणि पहिली सूचना नेहमी कॅश असते. रिमोट-ॲक्सेस डिझाइनमध्ये BranchCache जोडण्यापूर्वी, तक्रार तीनपैकी एका स्वरूपात विभागा: अपरिवर्तित सामग्रीचे वारंवार डाउनलोड, अपलोड, किंवा हजारो नोंदी असलेल्या फोल्डरमधून मेटाडेटा-जड ब्राउझिंग. BranchCache समर्थित सामग्रीवर पहिले स्वरूप सोडवते आणि इतर दोनसाठी उपयुक्त काहीही करत नाही. ही टाळायची मर्यादा नाही; डिप्लॉयमेंटवर आठवडा खर्च करण्यापूर्वी करायची तुलना हीच आहे.

तेच शेअर, तीन वेगळ्या तक्रारी

आठ जण एकच अपरिवर्तित प्रशिक्षण व्हिडिओ उघडतात असे शाखा कार्यालय हे या वैशिष्ट्यासाठी डिझाइन केलेले प्रकरण आहे. पहिली पुनर्प्राप्ती WAN ओलांडते, सामग्री वाचकांच्या जवळ कॅश होते, आणि त्याच अपरिवर्तित फाइलची पुढील पुनर्प्राप्ती स्थानिक पातळीवर दिली जाते. फायदा खरा आणि मर्यादित आहे: तीच सामग्री, अपरिवर्तित, अनेक वाचक.

घरच्या कनेक्शनवरून नवीन रेकॉर्डिंग अपलोड करणारा लॅपटॉप हे उलट प्रकरण आहे. अजून अस्तित्वात नसलेल्या फाइलची यापूर्वी कॅश केलेली प्रत नाही, म्हणून अपलोड नेहमीच्या त्याच मर्यादित मार्गाने जातो. डाउनलोड कॅश अपलोड काढून टाकत नाही, आणि कोणताही प्लेसमेंट पर्याय ते बदलत नाही.

तिसरे स्वरूप लोकांना निराश करते कारण ते डाउनलोड समस्येसारखे दिसते. हजारो फाइलींची डिरेक्टरी उघडणे, ती क्रमवारी लावणे आणि मेटाडेटा वाचणे हा लहान ऑपरेशन्सचा प्रवाह आहे, एका मोठ्या ऑब्जेक्टचे वारंवार हस्तांतरण नाही. फाइल बॉडी कॅश करणे यादीसाठी काहीही करत नाही.

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

वितरित मोडमध्ये, क्लायंट संगणक एकमेकांसह कॅश केलेली सामग्री सामायिक करतात, आणि Microsoft त्या मोडचे वर्णन एका सबनेटमध्ये कार्यरत असे करते. VPN क्लायंट पूल त्या अर्थाने सबनेट नाही, जरी सर्व पत्ते सलग दिसत असले तरी: पीअर शोध, क्लायंट-ते-क्लायंट उपलब्धता आणि कॅश डेटा देवाणघेवाणीची परवानगी या वेगळ्या प्रश्न आहेत, आणि नेहमीचे रिमोट-ॲक्सेस डिझाइन तिन्हींना नाही असे उत्तर देते.

क्लायंट-ते-क्लायंट रहदारीला परवानगी देऊन तुम्ही पूलाला शाखा LAN सारखे वागवू शकता, पण तो सुरक्षा निर्णय आहे, कॅशिंगचा नाही. बहुतेक रिमोट-ॲक्सेस डिझाइन क्लायंटना एकमेकांपासून वेगळे ठेवतात तेच यासाठी की एका ताबा घेतलेल्या लॅपटॉपला दुसऱ्यापर्यंत पोहोचता येऊ नये, आणि ती अलगता कॅश हिटसाठी बदलणे ही वाईट देवाणघेवाण आहे, जोपर्यंत पीअर आधीच विश्वासार्ह समान नाहीत.

एका भटक्या वापरकर्त्यासाठी, वितरित मोडमध्ये सामायिक करायला कोणी नाही. कॅश त्या एका क्लायंटच्या वारंवार वाचनांना अजूनही सेवा देऊ शकतो, पण तो क्लायंट-साइड कॅशचा फायदा आहे, शाखा प्लेसमेंटचा फायदा नाही, आणि कार्यालय वेगवान होईल अशी कोणी अपेक्षा करण्यापूर्वी ते सांगणे योग्य आहे.

होस्टेड कॅश: प्लेसमेंट ठरवते की ते मदत करते की नाही

होस्टेड कॅश सामायिक कॅश सर्व्हरवर ठेवतो, जो सबनेट्समध्ये अर्थपूर्ण असणारा एकमेव मोड आहे आणि क्लायंट एकमेकांशी बोलू शकत नाहीत तेव्हा कार्य करणारा एकमेव मोड आहे. तो सर्व्हर कुठे आहे हा तात्काळ प्रश्न आहे. उगमाप्रमाणे त्याच मर्यादित दुव्यावरून पोहोचणारा होस्टेड कॅश बाइट्स हलवतो, समस्या नाही.

ते वाचकांच्या जवळ ठेवा, त्याला मालक द्या आणि त्याची डिस्क संपूर्ण शेअरसाठी नाही, कार्यरत संचासाठी मोजा. Microsoft BranchCache आढावा दोन्ही मोड आणि क्लायंटचे वर्तन वर्णन करते, लोक विसरतात तो भागही: कॅश केलेला डेटा वापरण्यापूर्वी क्लायंट अजूनही अधिकृतता आणि सामग्री माहितीसाठी उगमाशी संपर्क साधतात.

डिप्लॉयमेंट म्हणजे एक चेकबॉक्स नाही, एकत्र नियोजित तीन भूमिका. उगम सर्व्हर सामग्रीसाठी हॅश प्रकाशित करतो, होस्टेड कॅश सक्षम आणि शोधण्यायोग्य होतो, आणि क्लायंट तो वापरण्यासाठी संरचित केले जातात. सर्व्हर बाजूला ते PowerShell मध्ये ओळखता येते:

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

क्लायंटवर, एकतर तो नामांकित सर्व्हरकडे निर्देश करा किंवा सेवा कनेक्शन पॉइंटद्वारे ते शोधू द्या; नंतर धोरण लागू झाले असे गृहीत धरण्याऐवजी त्याने प्रत्यक्षात निवडलेला मोड पुष्टी करा:

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

अजूनही उगमापर्यंत काय पोहोचते

कॅशिंग अधिकृतता काढून टाकत नाही. फाइल वाचण्याची परवानगी नसलेल्या क्लायंटला दुसऱ्याने ती कॅश केली म्हणून प्रवेश मिळत नाही, आणि उगम अजूनही अधिकृततेच्या प्रश्नाचे उत्तर देतो आणि कॅश शोध शक्य करणारी सामग्री माहिती पुरवतो. उगम पोहोचण्यायोग्य नसल्यास, फक्त कॅश केलेली प्रत ऑफलाइन शेअर होत नाही.

सामग्रीतील बदलही ती धारणा शांतपणे मोडतात. पुन्हा जतन केलेली, पुन्हा एन्कोड केलेली किंवा बॅकअप उत्पादनाने स्पर्श केलेली फाइल यापुढे कॅश केलेल्या हॅशशी जुळणार नाही, आणि पुढील वाचन उगमाकडे परत जाते. ते योग्य वर्तन आहे, आणि म्हणूनच दर तासाला कार्यरत संच बदलणारा कॅश थोडेच देतो.

बाहेर टाकणे ही तिसरी मर्यादा आहे. कॅश मर्यादित आहे, म्हणून मोठा कार्यरत संच जुनी सामग्री बाहेर ढकलतो, आणि फायदा पुनर्वाचन बाहेर टाकण्यापूर्वी होतात की नंतर यावर अवलंबून असतो. संपूर्ण शेअरसाठी कॅश मोजणे हा तांत्रिकदृष्ट्या बरोबर असलेल्या डिप्लॉयमेंटने निराश होण्याचा नेहमीचा मार्ग आहे.

दोन पुनर्प्राप्ती आणि एका अपलोडने ते स्वीकारा

योग्य तीन प्रवाह तपासा आणि प्रत्येक काय दाखवतो ते लिहा. क्लायंटकडून प्रातिनिधिक फाइलची पहिली पुनर्प्राप्ती, उगम दुव्यावर आणि वापरकर्त्याच्या घड्याळावर मोजलेली. त्याच प्लेसमेंट गटातील दुसऱ्या क्लायंटकडून त्याच अपरिवर्तित फाइलची दुसरी पुनर्प्राप्ती. नवीन फाइलचा एक अपलोड, ज्याने कोणतेही सुधारणा दाखवू नये आणि कॅशला कधीही न केलेल्या गोष्टीचे श्रेय दिले जात नाही याची पुष्टी करावी.

दुसरी पुनर्प्राप्ती अजूनही बहुतेक बाइट्ससाठी उगम दुवा ओलांडत असेल, तर कॅश वापरला जात नाही, आणि कारण सहसा चुकीच्या मोडमधील क्लायंट, उगमावरील गहाळ हॅश प्रकाशन, किंवा मर्यादित दुव्याच्या चुकीच्या बाजूला असलेला होस्टेड कॅश असते. त्या तीन वेगळ्या दुरुस्त्या आहेत, आणि त्यातील फक्त एक नेटवर्क प्लेसमेंटबद्दल आहे.

मग मूळ तक्रारीच्याच स्वरूपात निष्कर्ष सांगा: या उगमापासून या वाचकांसाठी अपरिवर्तित सामग्रीचे वारंवार डाउनलोड या कॅशद्वारे दिले जातात. शेअरबद्दल बाकी सर्व अस्पर्शित राहते, अपलोड, फोल्डर यादी आणि ऑफलाइन कथा यासह, जिला अजूनही स्वतःचे उत्तर हवे आहे.