BranchCache для сеткавых папак праз VPN: калі гэта дапамагае, а калі не

Хтосьці ў камандзе кажа, што сеткавая папка праз VPN працуе павольна, і першая прапанова заўсёды — кэш. Перш чым дадаваць BranchCache у схему выдаленага доступу, падзяліце скаргу на адну з трох формаў: паўторныя загрузкі нязменнага змесціва, загрузкі на сервер або прагляд з вялікай колькасцю метаданых па папках з тысячамі запісаў. BranchCache вырашае першую форму на падтрыманым змесціве і не робіць нічога карыснага для дзвюх іншых. Гэта не абмежаванне, якое трэба абыйсці; гэта параўнанне, якое варта правесці, перш чым марнаваць тыдзень на разгортванне.

Адна і тая ж папка, тры розныя скаргі

Філіял, дзе восем чалавек адкрываюць адно і тое ж нязменнае навучальнае відэа, — гэта менавіта той выпадак, для якога стваралася функцыя. Першае атрыманне ідзе праз WAN, змесціва кэшуецца побач з чытачамі, а наступныя атрыманні таго ж нязменнага файла абслугоўваюцца лакальна. Карысць рэальная і вузкая: тое ж змесціва, нязменнае, некалькі чытачоў.

Наўтбук, які загружае новы запіс праз хатняе злучэнне, — гэта процілеглы выпадак. Раней закэшаванай копіі файла, якога яшчэ не існуе, няма, таму загрузка ідзе тым жа абмежаваным шляхам, што і заўсёды. Кэш загрузак не выдаляе загрузку, і ніякі выбар размяшчэння гэтага не змяняе.

Трэцяя форма — тая, што расчароўвае людзей, бо выглядае як праблема загрузкі. Адкрыццё каталога з дзесяткамі тысяч файлаў, яго сартаванне і чытанне метаданых — гэта паток дробных аперацый, а не паўторная перадача аднаго вялікага аб'екта. Кэшаванне целаў файлаў нічога не дае для пераліку.

Размеркаваны кэш: пул VPN — гэта не лакальная сетка філіяла

У размеркаваным рэжыме кліенцкія камп'ютары дзеляцца закэшаваным змесцівам адзін з адным, і Microsoft апісвае гэты рэжым як такі, што працуе ў межах адной падсеткі. Пул VPN-кліентаў не з'яўляецца падсеткай у гэтым сэнсе, нават калі ўсе адрасы выглядаюць сумежнымі: выяўленне аднарангавых вузлоў, дасягальнасць кліент-кліент і дазвол на абмен кэшавымі данымі — гэта асобныя пытанні, і звычайная схема выдаленага доступу адказвае на ўсе тры не.

Можна прымусіць пул паводзіць сябе як лакальная сетка філіяла, дазволіўшы трафік паміж кліентамі, але гэта рашэнне пра бяспеку, а не пра кэшаванне. Большасць схем выдаленага доступу ізалюе кліентаў адзін ад аднаго менавіта каб адзін скампраметаваны наўтбук не мог дасягнуць іншага, і абменьваць гэтую ізаляцыю на трапленне ў кэш — дрэнны абмен, калі толькі аднарангавыя вузлы ўжо не з'яўляюцца даверанымі роўнымі.

Для аднаго вандроўнага карыстальніка размеркаваны рэжым не мае з кім дзяліцца. Кэш усё яшчэ можа абслугоўваць паўторныя чытанні гэтага аднаго кліента, але гэта карысць кэша на баку кліента, а не карысць ад размяшчэння ў філіяле, і пра гэта варта сказаць раней, чым хтосьці чакае, што офіс стане хутчэйшым.

Размешчаны кэш: размяшчэнне вызначае, ці будзе карысць

Размешчаны кэш ставіць агульны кэш на сервер; гэта адзіны рэжым, які мае сэнс паміж падсеткамі і адзіны, які працуе, калі кліенты не могуць размаўляць адзін з адным. Непасрэднае пытанне — дзе гэты сервер стаіць. Размешчаны кэш, дасяжны праз тое ж абмежаванае злучэнне, што і крыніца, перамясціў байты, а не праблему.

Размясціце яго блізка да чытачоў, прызначце ўладальніка і падбярыце дыск пад рабочы набор, а не пад усю папку. Агляд 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

Што ўсё яшчэ дасягае крыніцы

Кэшаванне не адмяняе аўтарызацыю. Кліент без дазволу чытаць файл не атрымлівае доступ толькі таму, што нехта іншы закэшаваў яго, і крыніца ўсё яшчэ адказвае на пытанне аўтарызацыі і дае інфармацыю пра змесціва, якая робіць магчымым пошук у кэшы. Калі крыніца недасяжная, закэшаваная копія сама па сабе не становіцца аўтаномнай папкай.

Змены змесціва таксама ціха ламаюць здагадку. Файл, які перазахавалі, перавыкарысталі або чапаў прадукт рэзервовага капіявання, можа больш не адпавядаць закэшаванаму хэшу, і наступнае чытанне вяртаецца да крыніцы. Гэта правільныя паводзіны, і менавіта таму кэш, рабочы набор якога змяняецца кожную гадзіну, дае мала.

Выцясненне — гэта трэцяя мяжа. Кэш канчатковы, таму вялікі рабочы набор выштурхвае старое змесціва, і карысць залежыць ад таго, ці адбываюцца паўторныя чытанні да выцяснення, а не пасля. Падбор памеру кэша пад усю папку — звычайны шлях да расчаравання разгортваннем, якое было тэхнічна правільным.

Прыміце гэта з двума атрыманнямі і адной загрузкай

Праверце правільныя тры патокі і запішыце, што кожны з іх паказвае. Першае атрыманне рэпрэзентатыўнага файла з кліента, вымеранае на злучэнні крыніцы, а таксама па гадзінніку карыстальніка. Другое атрыманне таго ж нязменнага файла з другога кліента ў той жа групе размяшчэння. Адна загрузка новага файла, якая не павінна паказаць паляпшэння і пацвярджае, што кэшу не прыпісваюць тое, чаго ён ніколі не рабіў.

Калі другое атрыманне ўсё яшчэ перасякае злучэнне крыніцы для большай часткі байтаў, кэш не выкарыстоўваецца, і прычына звычайна — кліент у няправільным рэжыме, адсутная публікацыя хэшаў на крыніцы або размешчаны кэш не на тым баку абмежаванага злучэння. Гэта тры розныя выпраўленні, і толькі адно з іх пра сеткавае размяшчэнне.

Затым выкладзіце выснову ў той жа форме, што і першапачатковая скарга: паўторныя загрузкі нязменнага змесціва з гэтай крыніцы гэтым чытачам абслугоўваюцца гэтым кэшам. Усё астатняе пра папку не закранута, уключаючы загрузкі на сервер, пералік папак і аўтаномны сцэнар, які ўсё яшчэ патрабуе ўласнага адказу.