BranchCache за мрежови файлови папки през VPN: кога помага и кога не

Някой в екипа казва, че файловата папка през VPN е бавна, и първото предложение винаги е кеш. Преди да добавите BranchCache към дизайна на отдалечения достъп, разделете оплакването в една от три форми: повторни изтегляния на непроменено съдържание, качвания или разглеждане с много метаданни през папки с хиляди записи. BranchCache решава първата форма при поддържано съдържание и не прави нищо полезно за другите две. Това не е ограничение, което да се заобикаля; това е сравнението, което трябва да направите, преди да отделите седмица за внедряване.

Същата папка, три различни оплаквания

Клонов офис, където осем души отварят едно и също непроменено учебно видео, е случаят, за който функцията е създадена. Първото извличане минава през WAN, съдържанието се кешира близо до читателите и следващите извличания на същия непроменен файл се обслужват локално. Ползата е реална и тясна: същото съдържание, непроменено, много читатели.

Лаптоп, който качва нов запис през домашна връзка, е обратният случай. Няма предварително кеширано копие на файл, който още не съществува, така че качването следва същия ограничен път, както винаги. Кешът за изтегляне не премахва качването и никакъв избор на разположение не променя това.

Третата форма е тази, която разочарова хората, защото изглежда като проблем с изтеглянето. Отварянето на директория с десетки хиляди файлове, сортирането й и четенето на метаданни е поток от малки операции, а не повтарящо се прехвърляне на един голям обект. Кеширането на телата на файловете не помага за изброяването.

Разпределен кеш: VPN пулът не е клонова LAN

В разпределен режим клиентските компютри споделят кеширано съдържание помежду си и Microsoft документира този режим като работещ в рамките на една подмрежа. VPN пулът от клиенти не е подмрежа в този смисъл, дори когато всички адреси изглеждат последователни: откриването на партньори, достижимостта клиент-към-клиент и разрешението за обмен на кеширани данни са отделни въпроси и обичайният дизайн на отдалечен достъп отговаря на трите с не.

Можете да накарате пула да се държи като клонова LAN, като разрешите трафик между клиентите, но това е решение за сигурност, а не за кеширане. Повечето дизайни за отдалечен достъп изолират клиентите един от друг точно за да не може един компрометиран лаптоп да достигне друг, и размяната на тази изолация срещу попадение в кеша е лоша сделка, освен ако партньорите вече не са доверени равни.

За един пътуващ потребител разпределеният режим няма с кого да споделя. Кешът все още може да обслужва повторните четения на този един клиент, но това е полза от кеш на клиентската страна, а не полза от клоново разположение, и си струва да се каже, преди някой да очаква офисът да стане по-бърз.

Хостван кеш: разположението решава дали ще помогне

Хостваният кеш поставя споделения кеш на сървър, което е единственият режим, който има смисъл между подмрежи, и единственият, който работи, когато клиентите не могат да говорят помежду си. Непосредственият въпрос е къде стои този сървър. Хостван кеш, достиган през същата ограничена връзка като източника, е преместил байтовете, а не проблема.

Поставете го близо до читателите, дайте му собственик и оразмерете диска за работния набор, а не за цялата папка. Преглед на 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

Какво все още достига до източника

Кеширането не премахва оторизацията. Клиент без разрешение да чете файл не получава достъп, защото някой друг го е кеширал, и източникът все още отговаря на въпроса за оторизацията и предоставя информацията за съдържанието, която прави възможно търсенето в кеша. Ако източникът е недостъпен, кешираното копие само по себе си не се превръща в офлайн папка.

Промените в съдържанието също тихо нарушават предположението. Файл, който е презаписан, прекодиран или докоснат от продукт за архивиране, може вече да не съответства на кеширания хеш и следващото четене се връща към източника. Това е правилно поведение и е причината кеш, чийто работен набор се променя всеки час, да дава малко.

Изместването е третата граница. Кешът е краен, така че големият работен набор изтласква по-старото съдържание и ползата зависи от това повторните четения да се случват преди изместването, а не след него. Оразмеряването на кеша за цялата папка е обичайният начин да бъдете разочаровани от технически правилно внедряване.

Приемете го с две извличания и едно качване

Тествайте правилните три потока и запишете какво показва всеки. Първо извличане на представителен файл от клиент, измерено на връзката към източника, както и по часовника на потребителя. Второ извличане на същия непроменен файл от втори клиент в същата група за разположение. Едно качване на нов файл, което не трябва да показва подобрение и потвърждава, че кешът не получава заслуга за нещо, което никога не е правил.

Ако второто извличане все още пресича връзката към източника за по-голямата част от байтовете, кешът не се използва и причината обикновено е клиент в грешен режим, липсващо публикуване на хешове на източника или хостван кеш от грешната страна на ограничената връзка. Това са три различни поправки и само една от тях е за мрежово разположение.

След това формулирайте заключението в същата форма като първоначалното оплакване: повторните изтегляния на непроменено съдържание от този източник до тези читатели се обслужват от този кеш. Всичко останало около папката остава незасегнато, включително качванията, изброяването на папки и офлайн сценарият, който все още изисква свой собствен отговор.