BranchCache в Windows 8.1 и Windows Server 2012 R2

Привет.

В прошлый раз я рассказывал про BranchCache в её первой ипостаси. Теперь можно и нужно рассказать, как эта крайне неплохая технология изменилась в Windows 8.1 / Windows Server 2012 R2.

Изменение требований к операционной системе
Упрощение настройки рабочих станций и серверов
Упрощение конфигурации сервера с ролью HOSTEDCACHE
Улучшения работы подсистемы хранения BranchCache
Экономия полосы пропускания
Ещё безопаснее, чем было
Возможные сценарии применения
Пример настройки BranchCache в сценарии Distributed Cache
Пример настройки BranchCache в сценарии Hosted Cache

Начнём.

Изменение требований к операционной системе

В предыдущем варианте BranchCache ограничивалась так: для рабочих станций – только Windows 7 Enterprise или Ultimate (самая распространённая Windows 7 Professional данную технологию, увы, не поддерживала). Для серверов тоже были ограничения – в случае Windows Server Core 2008 R2 Standard роль “выделенного кэширующего сервера BranchCache” отсутствовала. Теперь ситуация проще – технология есть на Windows 8 Enterprise и на всех серверах линейки Windows Server 2012, поэтому её (саму Feature) имеет смысл поставить в базовый образ сервера. Отличный плюс.

Серьёзным минусом же, по моей точке зрения, является упорное желание Microsoft отодвигать BranchCache (да и тот же DirectAccess) в Enterprise-версию, переход на которую с обычной Professional требует переустановки. Незначительное повышение цены делает Enterprise-версию экзотичной, т.к. её не ставят OEM’ы, в результате данные технологии изначально обречены на крайне малую задействованность.

Интересное про поддержку Vista / Windows Server 2008

В состав линейки NT 6.1 – это Windows 7 и Windows Server 2008 R2 – входит служба BITS 4.0. В состав предыдущей линейки NT 6.0 – BITS 3.0. Интересное состоит в том, что если на висту / 2008й сервер поставить BITS 4.0, то в случае, когда контент будет запрашиваться по BITS, они смогут искать этот контент у своих соседей по сети, на которых есть кэши BranchCache. Это изменение в работе PeerCache прошло малозаметным, но по сути, оно говорит о том, что некоторыми преимуществами BranchCache смогут пользоваться и ОС старой линейки – Vista и Server 2008. Это тоже плюс, притом неожиданный. Замечу, что редакции Vista должны быть “не домашними” – Business, Enterprise, Ultimate, а Windows Server 2008 может быть любым.

Упрощение настройки Branch Cache для рабочих станций и серверов

Теперь можно через политику сказать всем рабочим станциям, какой (или какие) сервер(а) будут являться hosted cache’ами. Ранее можно было средствами групповых политик установить режим работы BranchCache – а теперь можно в варианте hosted cache ещё и указать FQDN серверов.

Указываем FQDN сервера с ролью hosted cache в BranchCache для Windows 8.1 / Windows Server 2012 R2
(кликните для увеличения до 700 px на 643 px)

Фактически, вся настройка теперь делается через групповые политики, использование netsh не особо нужно. Да и Microsoft уже объявляет netsh как уходящее решение – лучше пользоваться PowerShell, как единообразным шеллом для всех задач, что тоже, в общем-то, плюс.

Ещё интереснее новый способ автообнаружения серверов. Теперь сервер BranchCache может опубликовать в Active Directory свой SCP (Service Connection Point), и клиенты автоматически найдут ближайший к себе сервер. Чтобы это сделать, достаточно включить BranchCache на нужном хосте (ограничение – хост не должен быть контроллером домена) в режим сервера HostedCache:

Enable-BCHostedServer

и опубликовать SCP:

Enable-BCHostedServer -RegisterSCP

Теперь клиенты, которые обнаружат эту SCP, сами переключатся в HostedClient, если Вы, конечно, в явном виде не укажете им в настройках, что им надо вести себя иначе. Вот соответствующая настройка в Group Policy:

Автоматическое обнаружение ближайшего сервера BranchCache через SCP
(кликните для увеличения до 700 px на 643 px)

Упрощение конфигурации сервера с ролью HOSTEDCACHE

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

Улучшения работы подсистемы хранения BranchCache

В сценарии “с выделенным сервером” появился дополнительный плюс – теперь для хранения данных BranchCache используется механизм ESE – тот самый MicrosoftJet (который и в DHCP сервере, и в WINS’е, и в ADDS, и даже в Exchange) продвинутой версии. Соответственно, в сценариях, когда сервер обслуживает много клиентов, количество IOPS ощутимо упало, да и всякие полезные задачи типа дефрагментации и организации доступа у ESE получше, чем у просто каталога на диске.

Достаточно интересной и полезной является интеграция с новой файловой подсистемой NT 6.2, в частности – с подсистемой дедупликации данных. В случае, когда BranchCache хранит данные, он “понимает”, что в некоторых файлах есть общие сегменты, и хранит их в единственном экземпляре. Это не нужно отдельно настраивать – достаточно включить дедупликацию на разделе, где хранятся данные BranchCache. Более того, теперь при дедупликации хэши сегментов файлов высчитываются сразу же, поэтому на разделе, где включена дедупликация, BranchCache берёт их уже готовыми, а не считает при первом запросе. От типа контента это не зависит – что передаваемый по HTTP, что по SMB 2.0 и выше, контент сразу хранится с хэшами, и BranchCache это грамотно использует, разгружая CPU от двойной работы.

Теперь файлы разделяются блоки динамически, используя тот же алгоритм, что и во встроенной в Windows Server 2012 дедупликации – Rabin fingerprint. Суть достаточно проста – границы блоков теперь подбираются динамически, исходя из контента, и количество совпадений хэша резко возрастает в отличии от ранней схемы с фиксированным размером блока в 64К. Количество хэшей, соответственно, уменьшается, а эффект от синергии с дедупликацией возрастёт.

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

Настройка времени рефреша кэша BranchCache через групповую политику
(кликните для увеличения до 700 px на 643 px)

Экономия полосы пропускания

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

Установка версии генерируемых сервером BranchCache хэшей содержимого
(кликните для увеличения до 700 px на 643 px)

При настройке учитывайте, что будет генериться или один, или другой тип хэшей, и отдаваться клиенту тоже только один (иначе экономии бы не было). Поэтому сценарий с “Только v2” подойдёт, если все рабочие станции используют Windows 8 и Windows Server 2012.

Ещё безопаснее, чем было

Кэш BranchCache теперь шифруется – это, конечно, не отменяет тот же Bitlocker, но добавляет уровень безопасности при несанкционированном физ.доступе к кэшу.

Возможные сценарии применения

Если суммировать всё то, что теперь сделано в сервисе BranchCache, то можно сказать следующее.

Сервис ощутимо улучшился, имеет смысл включать его через Group Policy на всех клиентских рабочих станциях – даже без выделенного сервера это крайне поможет в разгрузке сети. Один сотрудник открыл редко меняющийся документ с файл-сервера (“наш типовой договор”, “наш прайс-лист”), остальные, при запросе, заберут его у него локально.
Выделенный сервер BranchCache имеет смысл делать в любом регионе – его настройка упростилась, клиенты найдут его сами, в случае роуминга доп.настроек не надо – клиент видит Active Directory, знает свой сайт, видит SCP и подключается к ближайшему серверу.
Скорость первого подключения к серверу с кэшированным контентом ощутимо выросла – с хэшами новой версии тратится меньше трафика, плюс BranchCache “быстрее” предоставит клиенту список хэшей файла, к которому обращаются первый раз – хэши-то готовые уже лежат, дедупликатор их сгенерил, плюс отдавать будет хранилище на базе ESE, а не “просто папка на сервере”.
4. Всё это встроено в ОС и не нуждается в доп.лицензировании.

Сплошные плюсы – ну, а как Вы будете использовать эту технологию, думается, Вы придумаете сами.

Удач!

Возможно, вам будет также интересно почитать другие статьи про BranchCache на нашей Knowledge Base