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

Що все ще доходить до джерела

Кешування не скасовує авторизацію. Клієнт без права читати файл не отримує доступ через те, що хтось інший закешував його, і джерело все ще відповідає на питання авторизації та надає відомості про вміст, які роблять можливим пошук у кеші. Якщо джерело недоступне, сама лише кешована копія не стає автономним ресурсом.

Зміни вмісту теж тихо ламають припущення. Файл, який перезбережено, перекодовано або якого торкнувся продукт резервного копіювання, може вже не збігатися із закешованим хешем, і наступне читання йде назад до джерела. Це правильна поведінка, і саме тому кеш, робочий набір якого змінюється щогодини, дає мало.

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

Прийміть це з двома отриманнями й одним вивантаженням

Перевірте правильні три потоки й запишіть, що показує кожен. Перше отримання показового файлу з клієнта, виміряне на каналі джерела й за годинником користувача. Друге отримання того самого незміненого файлу з другого клієнта в тій самій групі розміщення. Одне вивантаження нового файлу, яке не повинно показати поліпшення й підтверджує, що кешу не приписують того, чого він ніколи не робив.

Якщо друге отримання все ще перетинає канал джерела для основної частини байтів, кеш не використовується, і причина зазвичай у клієнті з неправильним режимом, у відсутній публікації хешу на джерелі або у розміщеному кеші не з того боку обмеженого каналу. Це три різні виправлення, і лише одне з них про мережеве розміщення.

Потім сформулюйте висновок у тій самій формі, що й початкова скарга: повторні завантаження незміненого вмісту з цього джерела цим читачам обслуговуються цим кешем. Усе інше в ресурсі не зачеплено, включно з вивантаженням, переліком папок і історією автономної роботи, якій усе ще потрібна власна відповідь.