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

ഇപ്പോഴും ഉറവിടത്തിൽ എത്തുന്നത്

കാഷിംഗ് അധികാരപ്പെടുത്തൽ നീക്കം ചെയ്യുന്നില്ല. ഒരു ഫയൽ വായിക്കാനുള്ള അനുമതിയില്ലാത്ത ഒരു ക്ലയന്റിന് മറ്റൊരാൾ അത് കാഷ് ചെയ്തതിനാൽ പ്രവേശനം ലഭിക്കുന്നില്ല, ഉറവിടം ഇപ്പോഴും അധികാരപ്പെടുത്തൽ ചോദ്യത്തിന് ഉത്തരം നൽകുകയും കാഷ് ലുക്കപ്പ് സാധ്യമാക്കുന്ന ഉള്ളടക്ക വിവരങ്ങൾ നൽകുകയും ചെയ്യുന്നു. ഉറവിടം എത്താനാകുന്നില്ലെങ്കിൽ, കാഷ് ചെയ്ത പകർപ്പ് മാത്രം ഒരു ഓഫ്ലൈൻ ഷെയർ ആകുന്നില്ല.

ഉള്ളടക്ക മാറ്റങ്ങളും ആ അനുമാനത്തെ നിശബ്ദമായി തകർക്കുന്നു. വീണ്ടും സേവ് ചെയ്യപ്പെട്ടതോ വീണ്ടും എൻകോഡ് ചെയ്യപ്പെട്ടതോ ഒരു ബാക്കപ്പ് ഉൽപ്പന്നം തൊട്ടതോ ആയ ഒരു ഫയൽ ഇനി കാഷ് ചെയ്ത ഹാഷുമായി പൊരുത്തപ്പെടണമെന്നില്ല, അടുത്ത വായന ഉറവിടത്തിലേക്ക് തിരികെ പോകുന്നു. അത് ശരിയായ സ്വഭാവമാണ്, അതുകൊണ്ടാണ് ഓരോ മണിക്കൂറിലും വർക്കിംഗ് സെറ്റ് മാറുന്ന ഒരു കാഷ് വളരെ കുറച്ച് നൽകുന്നത്.

മൂന്നാമത്തെ പരിധിയാണ് പുറന്തള്ളൽ. കാഷ് പരിമിതമാണ്, അതിനാൽ ഒരു വലിയ വർക്കിംഗ് സെറ്റ് പഴയ ഉള്ളടക്കം പുറത്തേക്ക് തള്ളുന്നു, നേട്ടം പുറന്തള്ളലിന് ശേഷമല്ല, അതിന് മുമ്പ് വീണ്ടും വായനകൾ നടക്കുന്നു എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു. മുഴുവൻ ഷെയറിനും കാഷ് അളക്കുന്നത് സാങ്കേതികമായി ശരിയായ ഒരു ഡിപ്ലോയ്മെന്റിൽ നിരാശപ്പെടാനുള്ള സാധാരണ വഴിയാണ്.

രണ്ട് റിട്രീവലുകളും ഒരു അപ്ലോഡും കൊണ്ട് അത് സ്വീകരിക്കുക

ശരിയായ മൂന്ന് ഫ്ലോകൾ പരീക്ഷിച്ച് ഓരോന്നും എന്ത് കാണിക്കുന്നു എന്ന് എഴുതിവയ്ക്കുക. ഒരു ക്ലയന്റിൽ നിന്ന് ഒരു പ്രതിനിധി ഫയലിന്റെ ആദ്യ റിട്രീവൽ, ഉറവിട ലിങ്കിലും ഉപയോക്താവിന്റെ ക്ലോക്കിലും അളക്കുന്നു. അതേ പ്ലേസ്മെന്റ് ഗ്രൂപ്പിലെ രണ്ടാമത്തെ ക്ലയന്റിൽ നിന്ന് അതേ മാറ്റമില്ലാത്ത ഫയലിന്റെ രണ്ടാം റിട്രീവൽ. പുതിയ ഒരു ഫയലിന്റെ ഒരു അപ്ലോഡ്, അത് ഒരു മെച്ചവും കാണിക്കരുത്, കാഷ് ഒരിക്കലും ചെയ്യാത്ത ഒന്നിന് അതിന് ക്രെഡിറ്റ് നൽകുന്നില്ലെന്ന് സ്ഥിരീകരിക്കുന്നു.

രണ്ടാം റിട്രീവൽ ഇപ്പോഴും ബൈറ്റുകളുടെ ഭൂരിഭാഗത്തിനും ഉറവിട ലിങ്ക് കടക്കുന്നുണ്ടെങ്കിൽ, കാഷ് ഉപയോഗിക്കുന്നില്ല, കാരണം സാധാരണയായി തെറ്റായ മോഡിലുള്ള ഒരു ക്ലയന്റ്, ഉറവിടത്തിൽ വിട്ടുപോയ ഒരു ഹാഷ് പ്രസിദ്ധീകരണം, അല്ലെങ്കിൽ പരിമിതമായ ലിങ്കിന്റെ തെറ്റായ വശത്തുള്ള ഒരു ഹോസ്റ്റഡ് കാഷ് ആണ്. അവ മൂന്ന് വ്യത്യസ്ത പരിഹാരങ്ങളാണ്, അവയിൽ ഒന്ന് മാത്രമാണ് നെറ്റ്വർക്ക് പ്ലേസ്മെന്റിനെക്കുറിച്ചുള്ളത്.

തുടർന്ന് യഥാർത്ഥ പരാതിയുടെ അതേ രൂപത്തിൽ തീരുമാനം പറയുക: ഈ ഉറവിടത്തിൽ നിന്ന് ഈ വായനക്കാർക്കുള്ള മാറ്റമില്ലാത്ത ഉള്ളടക്കത്തിന്റെ ആവർത്തിച്ചുള്ള ഡൗൺലോഡുകൾ ഈ കാഷ് നൽകുന്നു. ഷെയറിനെക്കുറിച്ചുള്ള മറ്റെല്ലാം തൊടാതെ കിടക്കുന്നു, അപ്ലോഡുകൾ, ഫോൾഡർ ലിസ്റ്റിംഗ്, ഓഫ്ലൈൻ കഥ എന്നിവ ഉൾപ്പെടെ, അതിന് ഇപ്പോഴും അതിന്റേതായ ഉത്തരം വേണം.