peerdistsvc что это за служба
990x.top
Простой компьютерный блог для души)
BranchCache что это за служба? (PeerDistSvc)
Всем привет. Ребята, будем говорить сегодня про службу BranchCache, я постараюсь узнать для чего она и все такое. Значит покопался в интернете и выяснил, что BranchCache это технология кэширования, которая позволяет оптимизировать сетевой трафик. И даже его уменьшить, это конечно круто, я даже и не знал о таком..
Эта технология есть в Windows 7, но у меня Windows 10 и она тут тоже есть. BranchCache помогает в сетях с медленными линиями передачи, короче если соединение не очень, то BranchCache может помочь. Еще узнал что в Windows 7 только в версиях Ultimate или Enterprise работает BranchCache. Возможно это касается и Windows 10.
Вот еще читаю, что для использования BranchCache нужно настроить эту технологию на обеих сторонах. То есть и у вас, и там, где это трафик будет приниматься. Есть два режима BranchCache, это распределенный кэш (distributed cache) и выделенный кэш (hosted cache), хотя вам это вряд ли интересно.
В общем я не буду писать о режимах, эта инфа так бы сказать для спецов и если что ее можно найти в интернете.
У меня в Windows 10 эта служба остановлена, то есть она не работает. Мое мнение что эту службу трогать не стоит — она ну никак не сможет нагружать комп, да и она скорее у вас будет отключена. Но с другой стороны, мне кажется что если ее полностью отключить, то проблем не будет, в общем смотрите уже как вам лучше.
Теперь посмотрим что к чему.. Заходим в диспетчер задач:
Далее идем на вкладку Службы, там будет список служб, вот только там она называется не BranchCache, а PeerDistSvc:
И вот тут в колонке Состояние видите, тут указано что служба Остановлена. То есть она не работает. Но посмотрим на службу внимательнее — на этой вкладке внизу нажимаем на Открыть службы:
И вот наша служба BranchCache, если ее у вас нет вначале списка, то попробуйте отсортировать список служб — нажмите на название первой колонки, то есть на Имя. Ладно, смотрите, вот эта служба:
Нажимаю по ней два раза, появилось такое окошко:
Служба зависит от еще одной службы — HTTP-службы, в общем все сходится, мне просто было интересно посмотреть на эту вкладку.
Ну вот и все ребята, кажется мы разобрались. На этом все, удачи вам и пусть у вас все будет хорошо!
BranchCache в Windows Server 2012
В этой статье мы познакомимся с основными изменениями, которые коснулись технологии BranchCache в Windows Server 2012 и Windows 8, а также рассмотрим практический пример разворачивания инфраструктуры BranchCache.
Что такое BranchCache
Вкратце напомним, о том, что же за зверь такой BranchCache. Итак, BranchCache (BC) это технология, которая впервые была представлена в Windows Server 2008 R2 и Windows 7. Технология позволяет минимизировать трафик между удаленным офисом и центральными файл – серверами, располагающимися в центральном офисе /дата центре компании. Выглядит это примерно так: при доступе пользователя филиала к некому файлу на центральном файл (веб) сервере с включенной функцией BranchCache, он автоматически кэширует данный файл и при следующей попытке компьютера из этого же сайта открыть этот же файл, он получает его не с центрального файлового сервера, а из локального кэша (с рабочей станции или сервера внутри LAN сети филиала). Тем самым минимизируется трафик на WAN канале и увеличивается скорость доставки контента пользователю. Естественно, максимальная производительность BranchCache в Windows достигается при работе со статическими данными большого размера. BranchCache позволяет осуществлять кэширования данных, передаваемых по протоколам SMB и HTTP/HTTPS.
BranchCache может работать в двух режимах.
Что нового в BranchCache в Windows Server 2012 / Windows 8
Рассмотрим основные новшества, которые появились в технологии Branch Cache в новой платформе Microsoft (Windows Server 2012 + Windows 8).
Новая версия BranchCache работает на Windows 8 Professional (Enterprise) и на всех редакциях Windows Server 2012 (в том числе Core).
Настройка BranchCache в сети на базе Windows Server 2012 и Windows 8
Разберем практический пример использования технологии BranchCache с выделенным кэш-сервером (режим hosted cache).
Предположим, у нас имеется домен из двух сайтов – «Центральный», «Региональный». В центральном филиале находится некий файл сервер, с которым работают пользователи филиала. В сети филиала находится отдельный сервер, который, в том числе, возможно задействовать под задачи кэширования данных (hosted cache). Предполагается, что все сервера работают под управлением Windows Server 2012, а на клиентах стоит Windows 8 Pro.
Настройка центрального файлового сервера
Установим на центральном файловом сервере компонент BranchCache. Проще всего это сделать с помощью Powershell:
После чего сервер необходимо перезагрузить:
Следующий шаг – необходимо включить на файловом сервере генерацию хешей для данных в общих папках. Сделать это можно с помощью групповой политики, которую необходимо применить к файловому серверу.
Примените данную политику к файловому серверу:
Затем с помощью GUI активируем BranchCache для выбранной общей папки (в свойствах шары достаточно отметить опцию «Enable BranchCache»).
На этом операции с центральным севером завершены, а мы переходим к настройке инфраструктуры BranchCache в сети филиала.
Настройка кеширующего сервера BranchCache на Windows 2012
Итак, мы решили задействовать один из серверов филиала (на Windows Server 2012) в качестве кэширующего сервера BranchCache. Естественно, мы подразумеваем, что данный сервер не является выделенным под эту задачу, а сочетает ее с одной продуктивных функций. Установим модуль BranchCache следующей командной Powershell:
Далее необходимо указать, что сервер будет работать в режиме выделенного сервера BC (Hosted Server): В том случае, если сервер включен в домен Active Directory, выполните команду, которая в том числе активирует автоматическое определение клиентов BranchCache:
Если сервер не в домене, выполните:
Проверить, что все прошло успешно и данный сервер может работать в качестве кэширующего сервера BranchCache, выполните команду:
Команда должна вернуть примерно следующее: 
Настройка клиентов Branch Cache на Windows 8
Переходим к настройкам компьютеров филиала с ОС Windows 8, которые будут пользоваться преимуществами технологии BranchCache. Как всегда, проще всего это сделать с помощью групповой политики. Создайте и прилинкуйте политику к OU с компьютерами филиала (в случае необходимости можно отграничить применение политик, включив wmi фильтрацию).
Включив одновременно «Distributed cache mode» и «Automatic hosted cache discovery», мы отправим клиентов искать сервер hosted cache в Active Directory. Они должны обнаружить локальный кэширующий сервер BC, а если таковой отсутствует – задействовать механизм распределенного кэша (distributed mode).
Осталось применить политики на клиентах и перезапустить службу BrachCache:
Проверим статус BrachCache
Убедимся, что клиенты увидели выделенный hosted cache сервер и настроены на его использование.
Теперь в случае открытия любым пользователем данных из общей папки на центральном файловом сервере, они автоматически будут кэшироваться на сервере филиала и в дальнейшем при попытке открыть этот же файл, другие пользователи будут получать локальную копию данных, не прокачивая их заново по WAN-сети.
BranchCache в Windows 7
С момента выхода финальных версий Windows 7 и Windows Server 2008 R2 прошел почти год. Чем не повод еще раз вспомнить об этих ОС. Я хотел бы обратить внимание на две наиболее интересные, с моей точки зрения, возможности новых Windows: BranchCache и DirectAccess. В этой статье речь пойдет о BranchCache.
Что такое BranchCache
BranchCache – технология кэширования, встроенная в Windows 7 и Windows Server 2008 R2, и призванная оптимизировать (сократить) сетевой трафик, передаваемый по WAN-каналам связи. Соответственно, основная сфера применения BranchCache – организации с филиалами и удаленными офисами, которые связаны между собой и центральным офисом сравнительно медленными линиями передачи данных.
BranchCache поддерживает кэширование HTTP- и SMB-трафика. При этом на клиентских компьютерах должна быть установлена Windows 7 (редакции Ultimate или Enterprise, в других редакциях BranchCache не работает), а на серверах – Windows Server 2008 R2. Таким образом, BranchCache работает только в связке Windows 7 + Windows Server 2008 R2. Если с этого места у вас не пропало желание читать дальше, давайте обсудим главные особенности рассматриваемой технологии.
В чем ключевое отличие BranchCache от других технологий кэширования, таких как Offline Files или кэш ISA Server? Данные возвращаются клиентскому приложению из кэша только в том случае, если оригинальные данные не изменились. Поясню на примере. Предположим, что пользователь в филиале пытается открыть с файлового сервера в центральном офисе некий документ, ну скажем, шаблон заявления об увольнении о предоставлении отпуска. Модуль BranchCache компьютера пользователя запрашивает с сервера информацию о файле и проверяет, есть ли запрашиваемый файл в локальном кэше. Если нет, то файл, разумеется, скачивается с сервера центрального офиса. Если файл уже находится в локальном кэше, то все равно происходит обращение к серверу в центральном офисе, чтобы проверить, не изменился ли оригинальный файл на сервере. Если изменился, то файл опять же скачивается с сервера. И только если оригинальный файл на сервере и файл в кэше абсолютно идентичны, используются данные из кэша. Реальный алгоритм обработки запроса сложнее, но для понимания сути, мне кажется, информации достаточно.
Две важные характеристики BranchCache, которые следуют из приведенного примера.
1. Данные в BranchCache всегда актуальны. Выражаясь точнее, если приложение получает данные из кэша, технология BranchCache гарантирует, что эти данные актуальны.
2. Нет доступа к серверу – нет доступа к кэшу. Иными словами, если модуль BranchCache не может проверить идентичность оригинального и кэшированного файлов (сервер выключен, проблемы с каналом связи и пр.), то данные из кэша не используются.
Ну, и стоит добавить, что работа BranchCache прозрачна для приложений и пользователей. Интерфейс Windows никак не отражает тот факт, что открытый только что пользователем документ взят из кэша. В отличие, например, от механизма Offline Files.
Зададимся теперь принципиальным вопросом, а именно: каким образом происходит проверка кэша и сравнение оригинальной и кэшированной информации? BranchCache использует так называемые метаданные. Запрашиваемый файл (документ на файловом сервере, html-страница на веб-сервере и пр.) разбивается на сегменты по 32 MB. Если файл меньше 32 MB, он по определению состоит из одного сегмента. Сегменты, в свою очередь, разбиваются на блоки по 64 KB. Если файл меньше 64 KB, он всегда напрямую скачивается с сервера, и BranchCache при этом не используется. Для каждого блока и сегмента по алгоритму SHA 256 вычисляется хэш. Все эти вычисления происходят на сервере с включенной поддержкой BranchCache, где располагается запрашиваемый файл. Совокупность хэш-значений сегментов и блоков образуют хэш-лист (hashlist) и служат основой метаданных файла. Именно эти метаданные и передаются на клиентский компьютер, где сравниваются с хэш-листом кэшированного файла. Размер хэша данных приблизительно в 2000 раза меньше размера самих данных, поэтому нагрузка на WAN-канал при передаче метаданных минимальна.
Разбиение на сегменты и блоки позволяет оптимизировать операции поиска и скачивания данных. Хэш сегмента является единицей поиска. Как уже было упомянуто, при обращении к файлу на удаленном сервере – в центральном офисе или другом филиале – первое, что делает модуль BranchCache клиентского компьютера, запрашивает с сервера метаданные файла. На основе полученного хэш-листа BranchCache проверяет, есть ли в локальном кэше сегменты файла. Если да, файл открывается из локального кэша. Если нет, то клиентский компьютер посылает в сеть поисковый запрос: «У кого есть сегмент с таким-то хэшем?» В зависимости от режима работы BranchCache (см. ниже) этот запрос направляется либо специально сконфигурированному серверу с Windows Server 2008 R2 в этом же филиале, либо находящимся в этой же IP-подсети компьютерам с Windows 7. В случае положительного ответа искомый сегмент данных блоками скачивается с «соседа». В этом смысле, блок – единица скачивания. Таким образом, наличие сегментов позволяет сократить количество поисковых запросов, а наличие блоков – более быстро передать запрашиваемые данные приложению.
Режимы работы BranchCache
Для использования BranchCache необходимо настроить эту технологию, как на клиенте, так и на сервере. При этом возможны два режима работы BranchCache: распределенный кэш (distributed cache) и выделенный кэш (hosted cache).
В распределенном режиме данные кэшируются на том компьютере с Windows 7, который первым в филиале, а точнее в IP-подсети, эти данные скачал с удаленного сервера. После чего эти данные становятся доступными для других компьютеров филиала. Динамика работы BranchCache выглядит следующим образом:
1. Пользователь за компьютером в филиале пытается открыть документ с удаленного сервера. При этом компьютер устанавливает с сервером соединение и запрашивает требуемый файл так, как если бы BranchCache не было вообще.
2. Сервер авторизует клиента и проверяет, что у клиента есть соответствующие права доступа к файлу. Если прав нет, доступ к файлу отклоняется.
3. Если на сервере и клиенте сконфигурирован модуль BranchCache, сервер вместо файла возвращает метаданные, включая хэш-лист.
4. Если в локальном кэше сегменты файла отсутствуют, и скорость канала связи до сервера низкая (латентность превышает заданный порог, по умолчанию 80 мс), клиент генерирует запросы на поиск отсутствующих сегментов с помощью протокола Web Service Dynamic Discovery (WS-Discovery). Это групповые (multicast) запросы, которые распространяются только в пределах подсети, если маршрутизаторы не настроены иначе.
5. Если у кого-то есть запрашиваемые сегменты, они блоками возвращаются на клиентский компьютер. Компьютер проверяет целостность полученных блоков, сохраняет их в своем кэше и передает данные приложению. Пользователь видит открывшийся документ.
6. Если ни у кого из «соседей» нет нужных данных, они закачиваются с сервера по WAN-каналу и сохраняются в локальном кэше.
Распределенный режим рекомендуется для небольших филиалов, где все машины расположены в рамках одной подсети. BranchCache на клиентских машинах легко настроить с помощью групповых политик, при этом наличие сервера Windows Server 2008 R2 не требуется. Однако надо помнить, что при выключении компьютера его кэш становится недоступным другим клиентам филиала.
В этом режиме кэш (выделенный кэш) сосредоточен на филиальном сервере с Windows Server 2008 R2, сконфигурированном соответствующим образом. Любой компьютер с Windows 7 обращается с поисковыми запросами именно к серверу выделенным кэшем, и только к нему. Динамика такова:
1. Пользователь за компьютером в филиале пытается открыть документ с удаленного сервера. При этом компьютер устанавливает с сервером соединение и запрашивает требуемый файл так, как если бы BranchCache не было вообще.
2. Сервер авторизует клиента и проверяет, что у клиента есть соответствующие права доступа к файлу. Если прав нет, доступ к файлу отклоняется.
3. Если на сервере и клиенте сконфигурирован модуль BranchCache, сервер вместо файла возвращает метаданные, включая хэш-лист.
4. Если в локальном кэше сегменты файла отсутствуют, и скорость канала связи до сервера низкая (латентность превышает заданный порог, по умолчанию 80 мс), клиент напрямую обращается к локальному серверу с выделенным кэшем. IP-адрес или FQDN сервера с выделенным кэшем должен быть прописан в настройках клиента вручную или с помощью групповых политик. При этом, как уже понятно, запрашивается сегмент или сегменты.
5. Если данные в выделенном кэше есть, они блоками возвращаются на клиентский компьютер. Компьютер проверяет целостность полученных блоков, сохраняет их в своем кэше и передает данные приложению. Пользователь видит открывшийся документ.
6. Если же в выделенном кэше нет запрашиваемых данных, то клиент скачивает их с удаленного сервера и сохраняет в локальном кэше.
7. После чего клиент посылает серверу с выделенным кэшем пакет-оповещение о доступности новых данных для выделенного кэша.
8. Сервер посылает запрос клиенту на получение новых данных.
9. Клиент копирует блоки на сервер в выделенный кэш, чтобы этой информацией могли воспользоваться другие машины филиала.
Выделенный кэш обеспечивает более высокий уровень доступности данных, поскольку в отличие от клиентских компьютеров сервер работает постоянно и не выключается. Как правило. Хотя в небольших офисах чего только не бывает. Кроме того, нет ограничений на сетевую топологию. Запрос к выделенному кэшу – это unicast запрос, который маршрутизируется обычным образом. Однако описанный режим работы предполагает наличие в филиале сервера с Windows Server 2008 R2.
Завершая обзор режимов работы BranchCache, надо отметить, что эти режимы взаимоисключающие. Конкретный клиент с Windows 7 не может работать одновременно и в одном, и в другом режиме.
BranchCache поддерживает кэширование HTTP- и SMB-трафика. Существуют некоторые особенности, присущие рассматриваемому механизму кэширования, в контексте этих протоколов.
Начнем с HTTP. Поскольку модуль BranchCache встроен только в Windows Server 2008 R2 и Windows 7, наверное уже понятно, что BranchCache для HTTP применим, только если в качестве веб-сервера используется IIS 7.5 из состава Windows Server 2008 R2.
Вторая особенность связана с генерацией хэш-листов для файлов веб-сайтов. Хэш-лист для любого файла веб-сайта (html, jpg и т. д.) генерируется после первого обращения к этому файлу. Это приводит к тому, что только на третье обращение к файлу, тело файла может быть получено из BranchCache. Предположим, клиент из филиала впервые обращается к некоторой веб-странице. IIS отдает клиенту страницу по HTTP или HTTPS и генерирует для нее метаданные. Стало быть, клиент на свой запрос получил страницу, но не получил хэш-лист, а потому не может эту страницу поместить в свой или выделенный кэш. При втором обращении клиента к этой же странице IIS в ответ возвращает не данные, а имеющиеся уже теперь метаданные. Однако поскольку после первого запроса данные не были закэшированы, клиенту ничего не остается, как скачивать всю страницу заново. Но на этот раз ее можно поместить в кэш. И третий запрос к этой странице может быть обслужен из BranchCache.
Наконец, в силу того, что BranchCache фактически отрабатывает до транспортных механизмов, кэширование никак не влияет на SSL и наоборот. То есть BranchCache эффективно работает как при использовании HTTP, так и при HTTPS. Кстати это в равной степени относится и к IPSec по той же причине. В этом ролике я продемонстрировал настройку и принцип работы BranchCache для HTTP.
Объем данных на файловых серверах может быть очень большим и при высокой нагрузке вычисление хэшей оказывается весьма затратной операцией. Как следствие, в случае с SMB генерация метаданных происходит заранее. Поэтому в ответ на первый запрос клиент получает хэш-лист, и уже второе обращение к этому файлу может быть обслужено из кэша. После первичной генерации метаданные автоматически обновляются каждый раз после изменения файла. Плюс к этому у администратора есть возможность обновить хэш-лист для заданного файла или папки с помощью утилиты командной строки hashgen.
На клиентской стороне BranchCache для SMB, в том числе, использует службу Offline Files. Если эту службу отключить, кэширование SMB-трафика перестанет работать. На кэширование HTTP-трафика это никак не скажется.
Можно посмотреть на настройки и особенности работы BranchCache для SMB.
Приложения и данные
С точки зрения архитектуры BranchCache располагается ниже драйверов SMB и HTTP. Работа этого модуля прозрачна для приложений. Иными словами, кэширование будет работать при использовании любого приложения, которое задействует встроенный в Windows стек SMB или HTTP.
Тем не менее, я бы отметил, что эффект от BranchCache во многом зависит от характера используемых данных. Поясню. Вспомним уже рассмотренный пример, когда пользователь в филиале открывает с удаленного сервера документ. Клиент получает с сервера хэш-лист и закачивает тело файла либо с удаленного сервера, либо из BranchCache (своего или «соседского»). Что будет, если пользователь меняет содержимое этого документа и закрывает его с сохранением изменений? Весь файл сохраняется на удаленном сервере! Раз изменился файл, значит необходимо пересчитать хэш-лист, а этим занимает серверная сторона, поэтому сохранять модифицированный файл сразу в кэш нельзя. Если пользователь тут же попытается открыть файл заново, то согласно рассмотренному алгоритму, клиентский компьютер получит с сервера обновленные метаданные, и ничего не останется, как полностью скачивать тело файла с сервера. Вывод простой: BranchCache даст ощутимый эффект для относительно статичных данных.
Тема безопасности BranchCache вполне заслуживает отдельного топика, поэтому если читателям Хабра будет интересно, я готов написать о безопасности BranchCache более подробно. Пока же хотел бы отметить лишь несколько важных моментов.
Во-первых, BranchCache не предусматривает каких-либо специальных защитных мер при передаче данных с удаленного сервера в филиал. Если, например, файл скачивается по HTTP, а не HTTPS, то тело файла передается в открытом виде, и BranchCache со своей стороны никакого шифрования для данных не добавляет.
Во-вторых, сам по себе кэш, то есть файл на жестком диске, внутри которого хранятся кэшированные блоки, не шифруется. Если нужны дополнительные меры защиты, можно воспользоваться соответствующими средствами, например, встроенными в Windows EFS или BitLocker.
И наконец, механизмы безопасности BranchCache вступают в силу при обмене информацией с «соседними» компьютерами или сервером с выделенным кэшем. Все запросы и ответы в рамках такого обмена шифруются, чтобы предотвратить намеренную подстановку некорректных данных со стороны злоумышлинника.
Подводя итоги, хотелось бы еще раз подчеркнуть, BranchCache:
— снижает нагрузку на WAN-каналы, связывающие филиалы предприятия, и сокращает соответствующие расходы;
— повышает скорость отклика приложений в филиалах;
— является встроенной возможностью Windows 7 и Windows Server 2008 R2 и управляется штатными средставми.
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, достаточно несложный, предсказуемый, и при должной настройке очень эффективный. Давайте разберёмся в данной технологии, а заодно прикопаем один из мифов про Страшно Ворующую Данные Винду.
Предварительная подготовка
Я постараюсь разобрать полноценную процедуру развёртывания BranchCache, чтобы не было как на авторизованных курсах – “установите компонент с таким названием и дальше оно как-то само”. Это не наши методы! 🙂
Оглавление
Что такое BranchCache
Требования BranchCache к операционной системе
Сценарии BranchCache
Роли участников в BranchCache
Развёртывание BranchCache
BranchCache на клиентских ОС
Разрешаем трафик BranchCache на клиентах
Включаем Offline Files для BranchCache
и сразу же настроим шифрование папки 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 на файл-сервере
Теперь выберем режим работы BranchCache – настройка позволит глобально включить BranchCache на всех общих папках, а не только на тех, которые указаны явно:
ОК, в общем всё – теперь настроим для другого вида контента, BITS / HTTP / HTTPS.
BranchCache на web-сервере
Здесь всё будет даже проще, чем с SMB.
Ставим компонент BranchCache для веб-сервера
Для работы с HTTP-содержимым нам надо будет установить на контент-сервер другой компонент:
После установки убедитесь, что сервис BranchCache запущен и работает:
Всё ОК – теперь BranchCache, если вы используете Distributed Cache, настроен – но если используете режим Hosted Cache, то теперь надо настроить сервера кэширования. Приступим.
Настройка выделенного сервера кэширования BranchCache – Hosted Cache
Настройка 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=
Здесь appID – GUID службы BranchCache, а IP-адрес будет нужен только если вы не хотите, чтобы клиент с несколькими L3-интерфейсами работал по всем адресам – если хотите, то поставьте адрес 0.0.0.0. Теперь BranchCache “знает”, какой сертификат предъявлять клиентам, подключающимся по HTTPS для синхронизации содержимого.
Настройка BranchCache Hosted Cache для Windows Server 2012 R2 и Windows Server 2016
Тюнинг 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
Поэтому для того, чтобы исключить возможность подделки данных со стороны недобросовестных клиентов (ведь клиент может в своём кэше поменять данные в блоке, пересчитать SHA-256 и в случае выхода на связь с сервером Hosted Cache и отсутствия у сервера этого блока, сервер заберёт его к себе и будет раздавать другим клиентам), нужно раздать всем серверам Hosted Cache разные секреты.
BranchCache и обновления для Windows 10
Ну вот, мы и добрались до страшных ужасов работы BranchCache для обновлений домашней Windows 10. Говоря просто, теперь BranchCache в Distributed Cache Mode может работать на домашней системе и в случае более чем одного хоста на Windows 10 дома вы просто получите ускорение скачивания обновлений – в случае, как понятно, если хосты в одной IP-сети.
Если вам этого не хочется – выключите этот сервис, да и всё. На клиентских ОС Windows его не получится удалить, т.к. он часть BITS – зато можно зайти в локальные настройки (через gpedit.msc) и выключить.
Думаю, дочитав до этого момента и поняв, что это за технология, вы сильно критичнее станете относиться к крикам про “тайные мистические непонятные схемы кражи данных”. Если копнуть каждое такое непонятное – в основе будет что-то вполне понимаемое, практичное и нужное для работы. Но, учитывая уровень современной IT-журналистики, да и большинства “икспертов” – безусловно, для самопиара лучше что-то погромче и пострашнее – на такое чаще кликают в Интернете.
Ну а так – сами видите, технология полезная и, в случае правильной настройки – очень эффективная.