BranchCache для файловых ресурсов через VPN: когда он помогает, а когда нет

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

Тот же ресурс, три разные жалобы

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

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

Третья форма разочаровывает, потому что выглядит как проблема загрузки. Открытие каталога с десятками тысяч файлов, сортировка и чтение метаданных — это поток мелких операций, а не повторная передача одного крупного объекта. Кэширование тела файлов ничего не даёт для перечисления.

Распределённый кэш: пул VPN — не сеть филиала

В распределённом режиме клиентские компьютеры делятся кэшированным содержимым друг с другом, и Microsoft описывает этот режим как работающий в пределах одной подсети. Пул клиентов VPN в этом смысле не подсеть, даже когда все адреса выглядят смежными: обнаружение узлов, доступность клиент-клиент и разрешение на обмен кэшированными данными — отдельные вопросы, и обычный проект удалённого доступа отвечает на все три «нет».

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

Для одного мобильного пользователя распределённому режиму не с кем делиться. Кэш всё ещё может обслуживать повторные чтения этого одного клиента, но это выгода кэша на стороне клиента, а не выгода размещения в филиале, и об этом стоит сказать, прежде чем кто-то начнёт ждать, что офис станет быстрее.

Размещённый кэш: размещение решает, поможет ли он

Размещённый кэш помещает общий кэш на сервер — это единственный режим, который имеет смысл между подсетями, и единственный, который работает, когда клиенты не могут общаться друг с другом. Первый вопрос — где стоит этот сервер. Размещённый кэш, доступный через тот же ограниченный канал, что и источник, перенёс байты, а не проблему.

Разместите его рядом с читателями, назначьте владельца и рассчитайте диск под рабочий набор, а не под весь ресурс. Обзор BranchCache от Microsoft описывает оба режима и поведение клиента, включая ту часть, которую забывают: клиенты по-прежнему обращаются к источнику за авторизацией и сведениями о содержимом, прежде чем использовать кэшированные данные.

Развёртывание — это три роли, спланированные вместе, а не одна галочка. Сервер-источник публикует хэши содержимого, размещённый кэш включён и обнаруживается, а клиенты настроены на его использование. На стороне сервера это узнаётся в PowerShell:

Enable-BCHostedServer -RegisterSCP
Get-BCStatus | Select-Object BranchCacheIsEnabled, ClientMode, HostedCacheServerList

На клиенте укажите именованные серверы или разрешите ему найти их через точку подключения службы; затем подтвердите режим, который он действительно выбрал, вместо того чтобы предполагать, что политика применилась:

Enable-BCHostedClient -ServerNames cache1.corp.example -UseSCP
Get-BCStatus | Select-Object BranchCacheIsEnabled, ClientMode

Что по-прежнему доходит до источника

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

Изменения содержимого тоже тихо ломают допущение. Файл, который пересохранён, перекодирован или затронут продуктом резервного копирования, может больше не совпадать с закэшированным хэшем, и следующее чтение уходит обратно к источнику. Это правильное поведение, и поэтому кэш, рабочий набор которого меняется каждый час, даёт мало.

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

Примите это с двумя получениями и одной выгрузкой

Проверьте правильные три потока и запишите, что показывает каждый. Первое получение представительного файла с клиента, измеренное на канале источника и по часам пользователя. Второе получение того же неизменённого файла со второго клиента в той же группе размещения. Одна выгрузка нового файла, которая не должна показать улучшения и подтверждает, что кэшу не приписывают того, чего он никогда не делал.

Если второе получение по-прежнему пересекает канал источника для основной части байтов, кэш не используется, и причина обычно в клиенте с неправильным режимом, в отсутствующей публикации хэша на источнике или в размещённом кэше не с той стороны ограниченного канала. Это три разных исправления, и только одно из них про сетевое размещение.

Затем сформулируйте вывод в той же форме, что и исходная жалоба: повторные загрузки неизменённого содержимого из этого источника этим читателям обслуживаются этим кэшем. Всё остальное в ресурсе не затронуто, включая выгрузку, перечисление папок и историю с автономной работой, которой всё ещё нужен собственный ответ.