В рамках этого поста я хотел бы обсудить изменения, которые претерпела технология BranchCache в Windows Server 2012 и Windows 8. Принцип работы и архитектура технологии уже обсуждались в одном из предыдущих постов, поэтому в основном сосредоточусь на новых возможностях и усовершенствованиях.

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

Две важные характеристики BranchCache, выделяющие ее на фоне других технологий кэширования:

Данные в BranchCache всегда актуальны. Выражаясь точнее, если приложение получает данные из кэша, технология BranchCache гарантирует, что эти данные актуальны.
Нет доступа к серверу – нет доступа к кэшу. Иными словами, если модуль BranchCache не может проверить идентичность оригинального и кэшированного файлов (сервер выключен, проблемы с каналом связи и пр.), то данные из кэша не используются.

Для использования BranchCache файловый сервер или веб-сервер должны располагаться на Windows Server 2008 R2 или Windows Server 2012, на клиентских компьютерах должна быть установлена одна из следующих ОС: Windows 7 Enterprise, Windows 7 Ultimate или Windows 8 Enterprise.

Все изменения в BranchCache в Windows Server 2012 и Windows 8 можно сгруппировать по трем направлениям: производительность, управление, масштабируемость. Рассмотрим последовательно каждое направление.

Производительность

Изменился принцип разбиения исходных файлов на блоки для вычисления метаданных (хэша для каждого блока). Если раньше файл разбивался на блоки равного размера (64 KB), то теперь границы блоков для каждого файла определяются на основе метода Rabin fingerprint.

Что это дает? Предположим, на странице веб-сайта есть некая картинка размером 100 KB. Эту же картинку вставляют в документ, который сохраняется на файловой шаре. При обработке и страницы сайта, и документа с помощью fingerprint границы блоков будут расставлены таким образом, что картинка и там, и там будет выделена в отдельный блок размером 100 KB. И поскольку содержимое этих блоков в обоих случаях одинаковое, будут совпадать и хэши этих блоков (например, ID2 на рисунке выше). Пользователь из филиала впервые обращается к веб-странице, и она поблочно скачивается с веб-сайта и помещается в кэш. Теперь если тот же или другой пользователь данного филиала открывает с удаленной шары упомянутый документ, то содержимое документа также поблочно скачивается с файлового сервера, за исключением картинки, блок с которой уже находится в филиале.

Следует добавить, что точно такой же алгоритм определения границ блоков используется службой дедупликации Windows Server 2012. Поэтому если раздел, на котором располагается содержимое веб-сайта и/или файловой шары, дедуплицирован, то файлы на блоки уже разбиты, хэши уже вычислены, и BranchCache использует эти метаданные, не проводя повторные разбиения/вычисления.

Управление

Ранее фактически приходилось для каждого филиала создавать свой GPO для настройки BranchCache на клиентах филиала. Это особенно верно, если в филиале применялся выделенный кэш-сервер (hosted cache), поскольку именно в GPO указывалось имя этого сервера, и клиенты, таким образом, понимали, где располагается выделенный кэш.

Hosted cache сервер под управлением Windows Server 2012 может регистрировать Service Connection Point (SCP) в Active Directory. Клиенты с Windows 8 Enterprise, обращаясь к AD, используют SCP для обнаружения кэш-сервера, причем сервера ближайшего к ним, то есть расположенного в том же сайте AD. Это, в свою очередь, позволяет потенциально иметь всего один GPO для настройки всех BranchCache-клиентов организации.

Традиционно для Windows Server 2012 и Windows 8 весь спектр задач администрирования BranchCache – установка, настройка, проверка статуса – можно реализовать с помощью PowerShell, что я тоже отношу к плюсам. В Windows 7, например, для проверки статуса или сброса кэша необходимо было использовать менее дружелюбный Netsh. Возвращаясь к hosted cache, установка необходимых компонентов BranchCache, конфигурация сервера в качестве кэш-сервера и регистрация SCP осуществляется двумя командлетами:

Install-WindowsFeature BranchCache –IncludeManagementTools
Enable-BCHostedServer –RegisterSCP

После чего, запустив Get-BCStatus, необходимо убедиться в том, что два параметра в секции HostedCacheServerConfiguration имеют значение True.

Чтобы клиенты с Windows 8 использовали SCP для поиска кэш-сервера, в GPO необходимо включить новый параметр Enable Automatic Hosted Cache Discovery by Service Connection Point.

Замечу, что если вместе с этим параметром включен параметр Set BranchCache Distributed Cache mode, то клиент сначала пытается через SCP обнаружить и использовать hosted cache, а если это не удается, то переключается в режим distributed cache.

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

Publish-BCFileContent 'D:\Branch Documents' -StageData
Export-BCCachePackage -Destination D:\Temp

Первая строчка генерирует метаданные для файлов в указанной папке и добавляет блоки данных этих файлов в так называемый пакет данных (data package) для последующего экспорта. Аналогичный командлет для веб-сайта называется Publish-BCWebContent. Вторая строчка собственно экспортирует набор хэшей и блоки данных в архивный файл со стандартным именем PeerDistPackage.zip в указанную директорию. Структура архива выглядит следующим образом:

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

Import-BCCachePackage -Path D:\Temp\PeerDistPackage.zip

Таким образом, мы получаем «разогретый» кэш.

Последнее нововведение, которое я хотел бы отметить в контексте управления, заключается в том, что кэшированные данные по умолчанию хранятся в зашифрованном виде. От администратора более не требуются никакие дополнительные телодвижения, как то: включение BitLocker, настройка EFS и пр., для обеспечения безопасности кэша. Также не требуется настройка сертификата на hosted cache сервере, что еще более разгрузит и без того занятого сисадмина. :) Правда сертификат все-таки понадобится, если к кэш-серверу будут обращаться клиенты с Windows 7.

Масштабируемость

Филиал филиалу рознь. После появления BranchCache в Windows Server 2008 R2 и Windows 7 мы столкнулись со сценариями использования технологии в филиалах с количеством сотрудников в несколько тысяч и объемом кэша в сотни гигабайт. Исходная реализация BranchCache не была оптимизирована для таких масштабов. Теперь BranchCache в качестве хранилища использует Extensible Storage Engine (ESE), позволяя обрабатывать терабайты данных.

Кроме того, если раньше можно было сконфигурировать только один hosted cache сервер на филиал, то теперь, в частности за счет SCP, такого ограничения нет. Вы можете масштабировать кэш филиала как вертикально за счет движка ESE, так и горизонтально, развертывая столько кэш-серверов, сколько необходимо.

В целом, мне кажется, изменения весьма интересны. Ряд новых настроек (см. п. New BranchCache Group Policy settings по ссылке) BranchCache в групповых политиках помогут обеспечить корректную работу в одном филиале клиентов Windows 7 и Windows 8. И, стало быть, поводов не использовать технологию становится еще меньше.

Получить дополнительную информацию по этой и другим возможностям Windows Server 2012 и Windows 8 вы можете, просмотрев бесплатные курсы на портале Microsoft Virtual Academy:
• Новые возможности Windows Server 2012. Часть 1. Виртуализация, сети, хранилища
• Новые возможности Windows Server 2012. Часть 2. Безопасность, управление, удаленный доступ, веб-платформа

Надеюсь, материал был полезен.
Спасибо!