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

મૂળ સુધી હજી શું પહોંચે છે

કેશિંગ અધિકૃતિ દૂર કરતું નથી. ફાઇલ વાંચવાની પરવાનગી ન હોય તેવા ક્લાયન્ટને બીજાએ કેશ કર્યું છે એટલે પ્રવેશ મળતો નથી, અને મૂળ હજી પણ અધિકૃતિના પ્રશ્નનો જવાબ આપે છે અને એ સામગ્રી માહિતી પૂરી પાડે છે જે કેશ શોધ શક્ય બનાવે છે. જો મૂળ પહોંચમાં ન હોય, તો કેશ કરેલી નકલ એકલી ઑફલાઇન શેર બનતી નથી.

સામગ્રીમાં ફેરફાર પણ ધારણાને શાંતિથી તોડે છે. ફરી સાચવેલી, ફરી એન્કોડ કરેલી અથવા બેકઅપ ઉત્પાદન દ્વારા સ્પર્શાયેલી ફાઇલ કદાચ હવે કેશ કરેલા હેશ સાથે મેળ ખાતી નથી, અને આગલું વાંચન મૂળ પર પાછું જાય છે. તે સાચું વર્તન છે, અને તેથી જ જે કેશનો કાર્ય-સેટ દર કલાકે બદલાય છે તે થોડું જ આપે છે.

બહાર કાઢવું એ ત્રીજી મર્યાદા છે. કેશ મર્યાદિત છે, તેથી મોટો કાર્ય-સેટ જૂની સામગ્રીને બહાર ધકેલે છે, અને લાભ એના પર આધાર રાખે છે કે ફરી વાંચન બહાર કાઢવાના પહેલાં થાય છે, પછી નહીં. સમગ્ર શેર માટે કેશ માપવી એ ટેકનિકલી સાચા ડિપ્લોયમેન્ટથી નિરાશ થવાનો સામાન્ય રસ્તો છે.

બે પુનઃપ્રાપ્તિ અને એક અપલોડ સાથે તેને સ્વીકારો

સાચા ત્રણ પ્રવાહની કસોટી કરો અને દરેક શું દર્શાવે છે તે લખો. ક્લાયન્ટમાંથી પ્રતિનિધિ ફાઇલની પહેલી પુનઃપ્રાપ્તિ, મૂળ લિંક પર અને વપરાશકર્તાની ઘડિયાળ પર પણ માપેલી. એ જ સ્થાન-જૂથના બીજા ક્લાયન્ટમાંથી એ જ અપરિવર્તિત ફાઇલની બીજી પુનઃપ્રાપ્તિ. નવી ફાઇલનો એક અપલોડ, જે કોઈ સુધારો દર્શાવવો ન જોઈએ અને જે પુષ્ટિ કરે છે કે કેશને એવી વસ્તુનો શ્રેય અપાઈ રહ્યો નથી જે તેણે કદી કરી નથી.

જો બીજી પુનઃપ્રાપ્તિ હજી પણ મોટાભાગના બાઇટ્સ માટે મૂળ લિંક પાર કરે છે, તો કેશ વપરાઈ રહી નથી, અને કારણ સામાન્ય રીતે ખોટા મોડમાંનો ક્લાયન્ટ, મૂળ પર ગેરહાજર હેશ પ્રકાશન, અથવા મર્યાદિત લિંકની ખોટી બાજુએ હોસ્ટેડ કેશ છે. આ ત્રણ અલગ સુધારા છે, અને તેમાંથી ફક્ત એક જ નેટવર્ક સ્થાન વિશે છે.

પછી તારણને મૂળ ફરિયાદના એ જ સ્વરૂપમાં રજૂ કરો: આ મૂળથી આ વાચકો સુધીની અપરિવર્તિત સામગ્રીની વારંવારની ડાઉનલોડ આ કેશ દ્વારા પૂરી પડાય છે. શેર વિશે બાકીનું બધું અસ્પૃષ્ટ રહે છે, જેમાં અપલોડ, ફોલ્ડર યાદીકરણ અને ઑફલાઇન વાર્તા સામેલ છે, જેને હજી પોતાનો જવાબ જોઈએ છે.