BranchCache за VPN дељење датотека: када помаже, а када не

Неко у тиму каже да је дељење датотека преко 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

Шта још стиже до извора

Кеширање не уклања ауторизацију. Клијент без дозволе за читање датотеке не добија приступ зато што ју је неко други кеширао, а извор још одговара на питање ауторизације и пружа податке о садржају који омогућавају претрагу кеша. Ако извор није доступан, сама кеширана копија не постаје ванмрежно дељење.

Промене садржаја такође тихо руше ту претпоставку. Датотека која је поново сачувана, поново кодирана или коју је дотакао производ за резервне копије можда више не одговара кешираном хешу, а следеће читање се враћа на извор. То је исправно понашање и зато кеш чији се радни скуп мења сваког сата даје мало.

Избацивање је трећа граница. Кеш је коначан, па велики радни скуп избацује старији садржај, а корист зависи од тога да ли се поновна читања дешавају пре избацивања, а не после. Одмерити кеш за цело дељење уобичајен је начин да вас разочара технички исправно постављање.

Прихватите то са два преузимања и једним отпремањем

Тестирајте три права тока и запишите шта сваки показује. Прво преузимање репрезентативне датотеке са клијента, мерено на изворној вези као и на корисниковом сату. Друго преузимање исте непромењене датотеке са другог клијента у истој групи смештаја. Једно отпремање нове датотеке, које не би требало да покаже побољшање и потврђује да се кешу не приписује нешто што никада није учинио.

Ако друго преузимање још прелази изворну везу за већину бајтова, кеш се не користи, а узрок је обично клијент у погрешном режиму, недостајућа објава хеша на извору или хостован кеш на погрешној страни ограничене везе. То су три различите поправке, а само једна се односи на мрежни смештај.

Затим изговорите закључак у истом облику као првобитна примедба: поновна преузимања непромењеног садржаја са овог извора тим читаоцима служи овај кеш. Све остало о дељењу остаје нетакнуто, укључујући отпремања, пописивање фасцикли и ванмрежну причу, која још тражи свој одговор.