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

अझै उद्गमसम्म के पुग्छ

क्यासिङले अधिकृतता हटाउँदैन। फाइल पढ्न अनुमति नभएको क्लाइन्टले अरू कसैले क्यास गरेको भरमा पहुँच पाउँदैन, र उद्गमले अझै अधिकृतताको प्रश्नको जवाफ दिन्छ र क्यास खोज सम्भव बनाउने सामग्री जानकारी दिन्छ। उद्गम पुग्न नसकेमा, क्यास गरिएको प्रतिलिपि मात्रै अफलाइन साझेदारी बन्दैन।

सामग्रीका परिवर्तनले पनि त्यो अनुमान चुपचाप तोड्छ। पुनः सुरक्षित गरिएको, पुनः इन्कोड गरिएको वा ब्याकअप उत्पादनले छोएको फाइल क्यास गरिएको ह्याससँग नमिल्न सक्छ, र अर्को पढाइ उद्गममा फर्किन्छ। त्यो सही व्यवहार हो, र त्यसैले हरेक घण्टा कार्यशील सेट फेरिने क्यासले थोरै मात्र दिन्छ।

बाहिर निकाल्नु तेस्रो सीमा हो। क्यास सीमित छ, त्यसैले ठूलो कार्यशील सेटले पुरानो सामग्री बाहिर धकेल्छ, र फाइदा पुनःपढाइ बाहिर निकाल्नु अघि हुन्छ कि पछि भन्नेमा निर्भर छ। सम्पूर्ण साझेदारीका लागि क्यास नाप्नु तात्त्विक रूपमा सही डिप्लोयमेन्टबाट निराश हुने सामान्य तरिका हो।

दुई पुनःप्राप्ति र एक अपलोडसँग यसलाई स्वीकार गर्नुहोस्

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

दोस्रो पुनःप्राप्तिले अझै अधिकांश बाइटका लागि उद्गम लिङ्क पार गर्छ भने, क्यास प्रयोग भइरहेको छैन, र कारण प्रायः गलत मोडमा रहेको क्लाइन्ट, उद्गममा छुटेको ह्यास प्रकाशन, वा सीमित लिङ्कको गलत तर्फ रहेको होस्टेड क्यास हो। ती तीन फरक सुधार हुन्, र तीमध्ये एक मात्र नेटवर्क प्लेसमेन्टसँग सम्बन्धित छ।

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