BranchCache в Windows 10 и Server 2016

Привет.

Ранее я уже написал две статьи по BranchCache – про BranchCache в изначальном варианте и про BranchCache в Windows Server 2012 R2 и Windows 8.1. Эта статья будет про новую версию – BranchCache в Windows 10 и в Windows Server 2016 – а также будет включать в себя более глубокий материал, чем по предыдущей версии.

На данный момент с BranchCache в Windows 10 сложилась странная ситуация – “новый функционал” про то, что “Ваша ОС теперь может скачивать обновления не только с Интернета, но и с соседних компьютеров!” подаётся как ультрановая фича со стороны Microsoft, а со стороны злопыхателей этот же функционал подаётся как “вот видите, злобная Windows 10 шарит по соседним компам со смутными целями, дескать обновления качает, но мы-то знаем что всё совсем не так!”. Всё это – про функционал, который есть ещё с Vista, достаточно несложный, предсказуемый, и при должной настройке очень эффективный. Давайте разберёмся в данной технологии, а заодно прикопаем один из мифов про Страшно Ворующую Данные Винду.

Предварительная подготовка

Я предполагаю, что вы владеете знаниями по Windows Server на уровне , а также установили в Central Store своего домена обновлённые ADMX-шаблоны для Windows 10 RTM. Все скриншоты и тесты я буду делать на Windows 10 и Windows Server 2016 TP2. Про специфику и ограничения BranchCache первой версии, т.е. оригинального варианта из Windows Server 2008 R2, я буду упоминать, но минимально.

Я постараюсь разобрать полноценную процедуру развёртывания BranchCache, чтобы не было как на авторизованных курсах – “установите компонент с таким названием и дальше оно как-то само”. Это не наши методы! :)

Оглавление

• Что такое BranchCache
• Требования BranchCache к операционной системе
• Сценарии BranchCache
• Роли участников в BranchCache
• Развёртывание BranchCache
• BranchCache на клиентских ОС
  • Разрешаем трафик BranchCache на клиентах
  • Включаем Offline Files для BranchCache
  • Включаем BITS для BranchCache
  • Настраиваем локальный кэш BranchCache на клиентах
  • Включаем BranchCache на клиентах
  • Настраиваем версию BranchCache для клиентов
  • Настраиваем режим работы BranchCache для клиентов
• BranchCache на файл-сервере
  • Ставим компонент BranchCache for Network Files
  • Настройка BranchCache на файл-сервере
• BranchCache на web-сервере
  • Ставим компонент BranchCache для веб-сервера
• Настройка выделенного сервера кэширования BranchCache – Hosted Cache
  • Настройка BranchCache Hosted Cache для Windows Server 2008 R2
  • Настройка BranchCache Hosted Cache для Windows Server 2012 R2 и Windows Server 2016
• Тюнинг BranchCache
  • Смена номеров портов у BranchCache
  • Дефрагментация кэша у сервера BranchCache
  • Ускорение первого ответа у контент-сервера BranchCache
  • Безопасность BranchCache
• BranchCache и обновления для Windows 10

Начнём.

Что такое BranchCache

BranchCache – это встроенный в NT 6.x механизм распределённого кэширования трафика. Кэшироваться может SMB-трафик (в том числе подписанный), HTTP и HTTPS-трафик, а также трафик протокола BITS (который, конечно, почти HTTP, но всё же API у него отдельное). Кэширование происходит прозрачно для приложения – т.е. оно, допустим, запрашивает по SMB файл, и, если BranchCache корректно настроен, то он “стягивает” этот файл с соседей. Это крайне удобно в сценариях вида “региональный офис из 5 компов без сервера”, когда файл скачивается более чем 1м клиентом и более чем 1 раз – допустим, первый пришедший на работу открывает с корпоративного SharePoint большой файл, а когда приходят другие, они, открывая этот же файл, заберут его копию из кэша первооткрывателя. Плюсов множество – это и ускорение работы, того же портала на базе SharePoint или любого другого веб-ресурса, и автоматическое ускорение скачивания обновлений Windows в сценарии, когда в филиале нет своего сервера WSUS, и более быстрая работа с удалённым файл-сервером (с поддержкой DFS или без), и множество другого.   Иными словами, любое ПО, которое обращается к штатному API для передачи данных с использованием указанных протоколов, получает преимущества BranchCache без каких-либо затрат и необходимости переписывания приложения.   В плане сетевых протоколов BranchCache поддерживает и IPv4, и IPv6.   Весь сетевой трафик BranchCache защищается, применяется алгоритм AES-128 (наилучшее соотношение скорости к надёжности защиты), который вдобавок ко всему сейчас на новых процессорах Intel ускоряется на аппаратном уровне, т.е. дополнительной защиты, например, применяя доменные политики IPSec, не нужно. Всё, что нужно, в общем-то уже есть, осталось настроить и использовать.   Технически BranchCache работает с данными, разбивая их на блоки по 64К (либо, в обновлённом варианте с Windows Server 2012, меньше) и считая хэш каждого блока. Хэш считается по алгоритму SHA-256, т.к. в NT 6.x данный алгоритм, в отличии от NT 5.x есть “из коробки” (коробка называется CNG). Пачка подряд идущих блоков называется сегментом и имеет свой личный хэш. По сути, если рамочно, BranchCache при поиске контента делает следующее – запрашивает по протоколу WS-Discovery у соседей либо у выделенного сервера “есть ли у кого сегмент с таким-то хэшем” (запрос хэша сегмента позволяет ощутимо уменьшить сетевой трафик), и если сегмент есть – заметьте, даже частично – то идёт обмен вида “давай уточним, у кого что от этого сегмента есть – если у тебя есть блок с хэшем таким-то, то отдай такой блок мне, а я тебе отсутствующие у тебя отправлю“. Т.е. единица передачи – файл – делится на блоки фиксированной длины, у каждого блока считается хэш, блоки объединяются в крупные куски – сегменты, и BranchCache позволяет синхронизировать как отсутствующие сегменты целиком, так и отдельные блоки внутри сегментов.   Дополнительный плюс в том, что если вы даже скачиваете одиночный файл, то в случае с BranchCache, если у файла есть одинаковые блоки, вы скачаете их только разово. Т.е. для начала вы обратитесь на источник контента – он пришлёт вам список хэшей; после того, как выяснится, что некоторые из них одинаковые, вы будете запрашивать или у соседей, или у выделенного сервера (зависит от сценария использования) только один экземпляр такого блока – ведь нет смысла много раз качать то, SHA-256 хэш чего одинаков.

Требования BranchCache к операционной системе

BranchCache доступен на клиентских ОС с Windows 7, начиная с редакции Enterprise. В серверных ОС он присутствует во всех редакциях (исключение составит лишь Windows Server Core 2008 R2 Standard – в этом случае роль “выделенного кэширующего сервера BranchCache” (Hosted Cache) недоступна).   Добавление поддержки BranchCache в Windows Vista / Windows Server 2008 также возможно – надо просто обновить их встроенный BITS 3.0 до BITS 4.0 (см. BITS 4.0), и всё будет ОК – в случае, когда контент будет запрашиваться с использованием BITS, они смогут искать этот контент у своих соседей по сети. Технология эта называется PeerCache, работает с BITS 3.5 (эта версия отдельно для загрузки не встречается) и мало известна.   Если вы уже чуток запутались, то всё просто:   Есть BITS – это подсистема передачи данных, используемая различными сервисами Windows (например, Windows Update).   Есть PeerCache – это фича BITS, которая появляется с версии 4.0 и позволяет запрашивать у соседей по сети список хэшей блоков скачиваемого файла.   Есть BranchCache – это технология, в которую будут входить и клиенты с BITS, и сервера, формирующие данные, и механизм обнаружения хранилищ через Active Directory, и всё остальное.

Сценарии BranchCache

Сценарии работы BranchCache делятся на 3 варианта:  

• Hosted Cache Mode – в этом случае в сети есть выделенный сервер BranchCache, с которого забирают трафик все клиенты (в регионе; в организации серверов может быть несколько). Сервер Hosted Cache может как находиться с клиентами в одной IPv4 / IPv6 – сети, так и быть доступным через роутинг.
• Distributed Cache Mode – в этом случае в сети нет выделенного сервера BranchCache, загрузка контента идёт с любого соседа по IPv4 / IPv6 – сети, у которого обнаружены нужные блоки данных.
• Hybrid Cache Mode – когда сеть большая, в части регионов может использоваться сценарий Hosted Cache, а в части – Distributed.

Сценарии не задаются глобально заранее – как развернёте, так и будет работать. Подчеркну ещё раз, что самый простой вариант – Distributed Cache – нацелен на сценарий “все в одной L3-сети”. В случае, если в регионе несколько IP-сетей (допустим, клиенты-десктопы в одной, а те, кто через WiFi – в другой), сценарий будет не рабочим – для оптимальной работы надо разворачивать Hosted Cache. Сценарий Distributed Cache привлекателен отсутствием сервера, но имеет два фундаментальных минуса:  

1. В случае отсутствия в сети или недоступности клиента, на котором закэширован исходный файл (допустим, человек с утра пришёл с ноутом, а потом ушёл на совещание), кэш недоступен. В Hosted Cache такого нет – сервер никуда не уйдёт.
2. Всё работает в пределах одного сетевого сегмента – если сетей несколько, эффективность резко снижается. Сервер же с Hosted Cache доступен из любой сети и ему не надо быть в одном L3-сегменте с клиентом.

Роли участников в BranchCache

По сути, ролей будет три:  

• Клиент (Client BranchCache) – тот, кто может использовать сервисы BranchCache. Ему нужен лишь BITS 4.0 и старше, ну и некоторые настройки через Group Policy. Он может раздавать контент другим, если применяется модель Distributed Cache.
• Кэш-сервер (Hosted Cache BranchCache) – выделенный сервер для кэширования данных BranchCache. Бывает только в части сценариев (отсутствует в Distributed Cache Mode).
• Контент-сервер (Content Server BranchCache) – тот, с кого изначально забирается контент для кэширования. Это обычный файловый или HTTP-сервер с поддержкой BranchCache.

Учтите, что контент-сервером BranchCache должна быть система, поддерживающая BranchCache и корректно настроенная – а не любой HTTP- или SMB-сервер. Ведь контент-сервер должен в ответ на обычный запрос файла высылать дополнительную информацию про хэши блоков и сегментов.   Теперь посмотрим, какие компоненты надо поставить и настроить, чтобы всё это заработало.

Развёртывание BranchCache

Начнём с самого простого – настройки клиентов.

BranchCache на клиентских ОС

Ставить ничего не надо – сервис PeerCache входит в BITS, соответственно, надо лишь обновить BITS в случае ОС Vista / 2008 до 4.0. Это несложно – качаем Windows Management Framework 4.0 и ставим. В Windows Server 2012 и Windows 8 уже входит BITS 5.0, обновлять ничего не надо. Конечно, можно обновить Windows 7 и старше и Windows 2008 R2 и старше до Windows Management Framework 5.0, но оный ещё не вышел на дату написания этой статьи.   Технически BITS реализован библиотекой QMgr.dll, лежащей в /System32, поэтому можно просто убедиться, что её версия старше 7.5.nnnn.nnnn.  

Разрешаем трафик BranchCache на клиентах

Первым делом – разрешения в Windows Advanced Firewall. Нам надо включить трафик MS-PCCRD (Peer Content Caching and Retrieval Discovery Protocol). Этот трафик идёт внутри Web Services Dynamic Discovery (WS-Discovery) и использует мультикаст – 239.255.255.250 в случае IPv4 и FF02::C в варианте IPv6. Порт одинаковый – 3702 UDP. Разрешите этот трафик как для отправки мультикаста по этим адресам наружу на указанный номер порта (чтобы клиент мог информировать соседей), так и для приёма на данный порт запросов на подключение.   В случае однорангового режима работы – Distributed Cache Mode – клиенты будут использовать порты 80 и 443й. Это потому что в BITS на клиенте встроен мини-сервер PeerCache. Эти порты также надо будет открыть для соседей по локальной сети – именно для них, подчеркну, а не для всех вообще, т.к. Distributed Cache будет работать только внутри сегмента. Поэтому данное включение безопасно – если же хочется сделать его ещё безопаснее, просто закройте трафик в пределах одной сети IPsec’ом с аутентификацией по Kerberos, и тогда ходить друг к другу смогут только хосты из одного домена, только в пределах одной IP-сети и трафик будет зашифрован.

Включаем Offline Files для BranchCache

Без механизма Offline Files BranchCache работать не будет, поэтому придётся включить этот вредный спорный в части полезности механизм.   Зайдём в групповую политику, в раздел Computer Configuration / Administrative Templates / Network / Offline Files и выберем параметр Allow of Disallow use of the Offline Files feature (настраивать лучше здесь, т.к. настройки в этом разделе перекроют пользовательские в случае наличия оных)  

и сразу же настроим шифрование папки Offline Files (параметр Encrypt the Offline Files cache) – оно не помешает:

Теперь настроим BITS.

Включаем BITS для BranchCache

Без правильно настроенного BITS работа в варианте Distributed Cache не будет возможна, т.к. именно в BITS настраивается работа сервиса PeerCache. Зайдём в Computer Configuration / Administrative Templates / Network / Background Intelligent Transfer Service и включим Allow BITS peercaching:

ОК, сам механизм PeerCache мы включили – теперь надо указать, какую роль может играть эта клиентская система – и предоставлять контент и запрашивать его, или что-то одно? Плюс, сразу же укажем, что нам надо ограничить полосу пропускания у механизма PeerCache – выберем 52428800 bps (это 50 mbit/sec). Учитывайте, что по умолчанию BITS использует максимум 30% полосы пропускания самого медленного интерфейса – это значит, что если на рабочей станции работает WiFi или Bluetooth, то будет скачиваться максимум 0.3*текущую скорость самого медленного из них, что может быть крайне мало. 50 mbit/sec же – это половина обычного LAN-интерфейса, и никак не навредит, допустим, доступу в Интернет или WAN-ресурсы предприятия. Включаем и настраиваем по порядку, вначале параметр Do not allow the BITS client to use Windows Branch Cache:

и Do not allow the computer to act as a BITS Peercaching client:

Включаем возможность отдачи контента в сценарии Distributed Cache (параметр Do not allow the computer to act as a BITS Peercaching server)- если в сети будет выделенный сервер Hosted Cache, то этот пункт надо наоборот выключить:

И устанавливаем максимальную полосу пропускания для PeerCache (параметр Limit the maximum network bandwidth used for Peercaching):

Теперь настроим размер и логику работы локального кэша BranchCache.

Настраиваем локальный кэш BranchCache на клиентах

Размер локального кэша BranchCache – важная штука, потому что он откусывает проценты пространства на том диске, который помечен как system (т.е. где %WINDIR%). По умолчанию он 1%, максимальный лимит – 80%, мы выставим в 5%. Почему это важно? Думаю, вы хорошо помните Update Rollup’ы для Windows 8.1, каждый из которых – по 800 с лишним мегабайт. Конечно же удобно, чтобы такое обновление раздавалось в локальной сети без загрузки WAN-канала – поэтому надо обеспечить, чтобы оно помещалось в кэш. Вы можете подобрать любое значение, учитывая минимальный размер системного раздела на рабочих станциях (параметр Limit the BITS Peercache size).

Устаревание блоков в кэше – тоже важный момент. По сути, особого смысла стирать старые блоки нет – но может быть такая ситуация, когда данные действительно нужны недолго – например, кэшируются часто изменяющиеся документы с корпоративного портала SharePoint (ежедневный прайс-лист и список товарных позиций), или количество абонентов невелико (3-5 локальных ноутбуков, которые ставят обновления автоматически). В этом случае можно снизить время жизни блоков в кэше до 30 дней, а то и ниже – мы же выставим (параметр Limit the age of files in the BITS Peercache) долгоживущий вариант, подходящий для большой сети – 120 дней.

Ну а теперь, настроив все подсистемы, включим на клиенте сам BranchCache.

Включаем BranchCache на клиентах

Включение самого компонента несложно и делается опять же через групповые политики (параметр Turn on BranchCache):

Эта настройка включит BranchCache именно как клиентский сервис – т.е. он включится даже на серверах, которые подпадут под неё. Поэтому будьте осмотрительны – настройка именно для клиентов, не включайте её глобально на домене, потому что во многих сценариях она не нужна (допустим, серверам в DMZ или edge-системам).

Теперь настроим версию BranchCache – это важная настройка, тут можно остановиться поподробнее

Настраиваем версию BranchCache для клиентов

В начале статьи я уже расскажывал, что BranchCache работает с разными блоками данных. В первой версии (это Windows Server 2008 R2 / Windows 7 Enterprise, и Vista с установленным BITS 4.0) данные разбивались на фиксированные блоки по 64К, от которых брался хэш, а пачка блоков называлась сегментом и тоже обладала своим хэшем. Это достаточно крупное разбиение, да и реализация этой схемы обладала неприятной деталью – в случае изменений в середине большого файла, надо было докачать не только фактически изменённый блок в 64К, но и все последующие. Что, конечно, резко снижало КПД технологии в случае сценария “часто обновляем файл, в котором правится какая-то мелочь в середине”. Этот вариант хэша называется первой версией – BranchCache V1.

В Windows Server 2012 / Windows 8 ситуация поменялась. Теперь файлы разделяются на блоки динамически, используя тот же алгоритм, что и во встроенной в Windows Server 2012 дедупликации – Rabin fingerprint. Суть достаточно проста – границы блоков подбираются исходя из контента, и количество совпадений хэша резко возрастает в отличии от ранней схемы с фиксированным размером блока в 64К. Блоков становится больше (обычно они по 16К-32К, и до 128К), но при каждом изменении надо закачать гораздо меньше данных (КПД вырастает в 3-4 раза только за счёт того, что уменьшился размер блока, а дополнительно вырастает ещё больше, потому что теперь не надо скачивать весь “хвост” файла после изменений). Также появляется эффект от синергии с дедупликацией (про это чуть дальше). Это – BranchCache V2.

Данные могут отправляться от сервера к клиенту только или в V1, или в V2, поэтому вам надо выбрать в явном виде, какой подойдёт. Иначе ваш продвинутый клиент на базе, допустим, Windows 8.1, закэширует ответ сервера, которым не сможет поделиться с системой на базе Windows 7. На момент написания этой статьи нет способа обновить BITS на Windows Server 2008 R2 / Windows 7 до версии 5.0, поэтому если в сети есть машины ниже NT 6.2, и им надо использовать BranchCache, вам придётся выбрать первый вариант. Эта настройка (параметр Configure Client BranchCache Version Support), по сути, возможность downgrade версии для старших систем. У серверов будет своя настройка “какие варианты хэшей отдавать”, она другая.

Теперь выберем между Distributed Cache и Hosted Cache.

Настраиваем режим работы BranchCache для клиентов

Клиенту надо явно указать – будет ли он, при включённом BranchCache, искать контент по соседям в своей локальной сети, или обратится к выделенному серверу. В первом случае мы включим параметр Set BranchCache Distributed Cache mode и на этом настройка режима работы закончится:

В варианте же “Использовать выделенный сервер Hosted Cache” ситуация будет различной для различных клиентских ОС. В случае NT 6.1 (Windows 7 / Windows Server 2008 R2 / примкнувшая к ним Vista) надо будет включить использование выделенного сервера параметром Set BranchCache Hosted Cache mode, явно указав его FQDN:

В новом варианте BranchCache, начиная с Windows 8 и Windows Server 2012, ситуация другая – появилось автообнаружение серверов Hosted Cache и теперь сервер BranchCache может опубликовать в Active Directory свой SCP (Service Connection Point) и клиенты автоматически найдут ближайший к себе. Это гораздо удобнее и настраивается через параметр Enable Automatic Hosted Cache Discovery by Service Connection Point:

Можно, кстати, и задать сервер в явном виде, как в предыдущей версии BranchCache – теперь это тоже стало удобнее и можно задать целый список (параметр Configure Hosted Cache Servers):

Учтите, что данные параметры для разных версий BranchCache не пересекаются – Windows 7 Enterprise будет читать свои, а Windows 8 / Windows 8.1 / Windows 10 – свои.

Что ж, клиент настроен – теперь посмотрим, как включать раздачу контента BranchCache на различных типах серверов.

BranchCache на файл-сервере

Файл-сервером с точки зрения BranchCache будет любая система, на которой есть общие папки и произведены нужные настройки. Сразу же хочу предупредить, что включать BranchCache на серверах просто так – не нужно, потому что добавление в ответ клиенту списка хэшей увеличивает сетевой трафик, и если клиент не понимает этих данных, то доступ к файлам лишь замедлится. Притом первичный доступ замедлится достаточно заметно – представьте себе, что на общей папке лежит большой файл в несколько гигабайт – вот при первом обращении к нему надо будет (если файловая система, на которой он лежит, не ReFS – там это уже сделано) посчитать хэши всех его блоков и для начала отправить клиенту этот дайджест.

Ставим компонент BranchCache for Network Files

Данный компонент отвечает за дополнительную функциональность для SMB shares. Добавить его просто, он внутри базовой роли File and Storage Services:

После его добавления включим отправку BranchCache-хэшей на новой общей папке, используя интерфейс Windows Server 2016:

и

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

ОК, но это лишь включение – давайте настроим SMB-ресурс, чтобы BranchCache работал качественно и предсказуемо.

Настройка BranchCache на файл-сервере

Настройка SMB-параметров начнётся с раздела Computer Configuration / Administrative Templates / Network / LanMan Server . Первый параметр – Hash Version support for BranchCache. Он скажет, какие хэши генерить в ответе клиенту. Здесь, в отличии от клиентской настройки, можно будет выбрать генерацию и V1 и V2-хэшей. Это удобно, потому что один сервер, раздающий контент, может одновременно генерить данные и для Vista / Windows 7 / Windows Server 2008 R2, и для более новых систем. Помните, хэши генерятся именно на content-сервере – остальные лишь кэшируют блоки данных с этими хэшами – поэтому данная настройка удобна для гибридных сценариев (хотя, конечно, первичное обращение клиента в случае включения и V1 и V2 замедляется):

Теперь выберем режим работы BranchCache – настройка позволит глобально включить BranchCache на всех общих папках, а не только на тех, которые указаны явно:

ОК, в общем всё – теперь настроим для другого вида контента, BITS / HTTP / HTTPS.

BranchCache на web-сервере

Здесь всё будет даже проще, чем с SMB.

Ставим компонент BranchCache для веб-сервера

Для работы с HTTP-содержимым нам надо будет установить на контент-сервер другой компонент:

После установки убедитесь, что сервис BranchCache запущен и работает:

Всё ОК – теперь BranchCache, если вы используете Distributed Cache, настроен – но если используете режим Hosted Cache, то теперь надо настроить сервера кэширования. Приступим.

Настройка выделенного сервера кэширования BranchCache – Hosted Cache

Настройка будет двух вариантов – для первой версии BranchCache и для современной, которая используется в Windows Server 2016 и Windows 10. Первая версия настраивается чуть дольше – ей нужно настроить сертификат для контента, вторая же не требует сертификата. Общим действием для всех версий будет установка компонента BranchCache (так же, как мы делали для веб-сервера) – поэтому не буду повторяться (хотя добавлю – можно поставить его и через PowerShell, вот так – Install-WindowsFeature BranchCache -IncludeManagementTools

Настройка BranchCache Hosted Cache для Windows Server 2008 R2

В сценарии с выделенным сервером необходимо, чтобы сервер мог подтвердить свою подлинность клиентам. Это делается путём привязки одноги из сертификатов в локальном хранилище сервера к службе BranchCache. Сделать это несложно. Зайдите на сервер, который держит роль Hosted Cache, откройте локальное хранилище сертификатов для компьютера, выберете там тот, который содержит Server Authentication в поле EKU (c OID=1.3.6.1.5.5.7.3.1) – он будет доверенным для клиентов, выберите у него поле Thumbprint и скопируйте куда-нибудь хэш (например, в блокнот), а после выполните команду: netsh http add sslcert ipPort=IP-адрес, на котором слушаются запросы BranchCache : номер порта certhash=значение поля Thumbprint у сертификата appID={d673f5ee-a714-454d-8de2-492e4c1bd8f8}

Здесь appID – GUID службы BranchCache, а IP-адрес будет нужен только если вы не хотите, чтобы клиент с несколькими L3-интерфейсами работал по всем адресам – если хотите, то поставьте адрес 0.0.0.0. Теперь BranchCache “знает”, какой сертификат предъявлять клиентам, подключающимся по HTTPS для синхронизации содержимого.

Настройка BranchCache Hosted Cache для Windows Server 2012 R2 и Windows Server 2016

Ничего привязывать не нужно – зато можно зарегистрировать в Active Directory свой SCP, чтобы клиенты могли нас найти. Если нам это не надо – просто запустим работу:   Enable-BCHostedServer   Если надо (т.е. клиенты будут использовать механизм поиска в Active Directory):   Enable-BCHostedServer -RegisterSCP   Windows Server 2016 запретит нам делать это действие, если мы пытаемся поднять роль Hosted Cache на DC – учитывайте это при планировании.   В общем всё – развёртывание завершено. Можно поговорить про дополнительные интересные функции.

Тюнинг BranchCache

Базовое развёртывание со всеми деталями завершено – а теперь чуть-чуть про доп.настройки.

Смена номеров портов у BranchCache

Эта операция нужна для сценария Hosted Cache – и будет выполняться в два этапа – смена портов со стороны сервера и со стороны клиентов. Хитрость в том, что в Hosted Cache используются оба web-порта – и 80й, и 443й, но для разных задач – по 80му порту клиенты скачивают с сервера данные (т.н. “Retrieval Protocol Port”), а по 443му – заливают ему недостающие в его кэше блоки (т.н. “Hosted Cache Protocol Port”). Поэтому смена будет выглядеть так – со стороны сервера меняем значения этих ключей:   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\PeerDist\HostedCache\Connection\   и   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\PeerDist\DiscoveryManager\Connection\   В каждом из них создаём параметр ListenPort типа DWORD32 и указываем новые значения – первый ключ отвечает за Hosted Cache Protocol, т.е. там тот порт, который вместо 443го, а второй ключ – за Retrieval Protocol, там тот порт, который вместо 80го. Менять можно и один – сервисы конфигурируются независимо.   У клиентов ключи те же, но другой подключ:   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\PeerDist\HostedCache\Peers\Connection\   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\PeerDist\DiscoveryManager\Peers\Connection\   Там создаём параметр ConnectPort типа DWORD и указываем новые номера портов.   После всех этих манипуляций надо будет обязательно перезапустить сервис Branchcache – PeerDistSvc (и на клиентах, и на сервере), можно например так: net stop peerdistsvc && net start peerdistsvc

Дефрагментация кэша у сервера BranchCache

Кэш BranchCache тоже может фрагментироваться – и это снижает его быстродействие. Для хранения данных BranchCache в сценарии Hosted Cache (только в нём – в остальных вариантах – просто каталог) используется механизм ESE – тот самый MicrosoftJet (который и в DHCP сервере, и в WINS’е, и в ADDS, и даже в Exchange) продвинутой версии – поэтому у него так же, как и у упомянутых сервисов, будет возможность онлайн-дефрагментации. Запустив команду   Set-BCCache -Defragment   вы дефрагментируете кэш. Это можно делать по расписанию, допустим, раз в сутки, создав работу в стандартном scheduler’е Windows Server.

Ускорение первого ответа у контент-сервера BranchCache

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

• Загрузить файл для прикидок, на какие куски его выгоднее поделить
• Посчитать хэши блоков

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

• Используйте дедупликатор Windows Server (начиная с 2012). Он генерит такие же хэши, как и BranchCache, и первое обращение становится таким же быстрым, как и следующие
• Используйте ReFS – там тоже генерятся хэши от частей файлов и их тоже может использовать BranchCache

Безопасность BranchCache

Система сама по себе спроектирована грамотно – ни клиент, ни кэширующий сервер Hosted Cache не может сам создать или добавить контент – список хэшей всегда запрашивается у контент-сервера и является аксиомой. Можно лишь добавить некоторые дополнительные ограничения для безопасности.   Если вы хотите, чтобы к серверу Hosted Cache могли подключаться только клиенты из его Active Directory, то включите доменную аутентификацию:   Set-BCAuthentication –ClientAuthenticationMode Domain   Если в вашем регионе два сервера Hosted Cache в кластере, то они будут кэшировать данные с контент-сервера независимо. Чтобы этого не происходило, надо задать им одинаковый preshared secret – тогда хэши сегментов будут генериться одинаково и совпадать:   Set-BCSecretKey -Passphrase atraining.ru   Если на этот момент запутались с хэшами, то всё просто:

• Контент-сервер рубит файл по мелким блокам, и от каждого считает хэш SHA-256;
• Когда много мелких блоков готовл, делается HoD – Hash of Data – это хэш от всех хэшей части мелких блоков;
• Из него вычисляется Segment Secret – берётся HMAC-функция от HoD и серверного preshared secret;

Поэтому для того, чтобы исключить возможность подделки данных со стороны недобросовестных клиентов (ведь клиент может в своём кэше поменять данные в блоке, пересчитать SHA-256 и в случае выхода на связь с сервером Hosted Cache и отсутствия у сервера этого блока, сервер заберёт его к себе и будет раздавать другим клиентам), нужно раздать всем серверам Hosted Cache разные секреты.

BranchCache и обновления для Windows 10

Ну вот, мы и добрались до страшных ужасов работы BranchCache для обновлений домашней Windows 10. Говоря просто, теперь BranchCache в Distributed Cache Mode может работать на домашней системе и в случае более чем одного хоста на Windows 10 дома вы просто получите ускорение скачивания обновлений – в случае, как понятно, если хосты в одной IP-сети.

Если вам этого не хочется – выключите этот сервис, да и всё. На клиентских ОС Windows его не получится удалить, т.к. он часть BITS – зато можно зайти в локальные настройки (через gpedit.msc) и выключить.

Думаю, дочитав до этого момента и поняв, что это за технология, вы сильно критичнее станете относиться к крикам про “тайные мистические непонятные схемы кражи данных”. Если копнуть каждое такое непонятное – в основе будет что-то вполне понимаемое, практичное и нужное для работы. Но, учитывая уровень современной IT-журналистики, да и большинства “икспертов” – безусловно, для самопиара лучше что-то погромче и пострашнее – на такое чаще кликают в Интернете.

Ну а так – сами видите, технология полезная и, в случае правильной настройки – очень эффективная.

Удачного применения!