Привет.
Внутренние соц.сети – уже пройденный вопрос; берёте SharePoint 2010 да делаете, странички сотрудников лайкаете, новости в ленте публикуете. Внутренние FTP/Web-сайты – тоже. Внутренний торрент для технических задач, притом бесплатный, притом встроенный в ОС – это ещё круче. Давайте включим наш локальный трекер.
Встроенный торрент-клиент в Windows : BranchCache
- Зачем нужен и как работает BranchCache
- Вариант “с сервером” – BranchCache Hosted Mode
- Вариант “без сервера” – BranchCache Distributed Mode
- Требования к ОС и клиентскому ПО
- Включаем BranchCache
- Включение BranchCache на сервере-источнике
- Включение BranchCache на кэширующем сервере
- Включение BranchCache на peer-клиенте
- Сетевые настройки BranchCache
- Привязка сертификата для подтверждения подлинности сервера BranchCache
- Смена номеров портов у BranchCache
- Включаем BranchCache на выбранных общих папках
- Мониторинг BranchCache
Приступим.
Зачем нужен и как работает BranchCache
BranchCache – это встроенный в NT 6.1 механизм распределённого кэширования трафика. Кэшироваться может SMB-трафик (в том числе подписанный), HTTP и HTTPS-трафик, а также трафик протокола BITS (который, конечно, почти HTTP, но всё же API у него отдельное). Кэширование происходит прозрачно для приложения – т.е. оно, допустим, запрашивает по SMB файл, и есть BranchCache корректно настроен, то “стягивает” этот файл с соседей. Это крайне удобно в сценариях вида “региональный офис из 5 компов без сервера”, когда файл скачивается более чем 1м клиентом и более чем 1 раз. Плюсов множество – это и ускорение работы, к примеру, портала на базе SharePoint, и автоматическое ускорение скачивания обновлений в сценарии, когда в филиале нет своего сервера WSUS, и более быстрая работа с удалённым файл-сервером, и множество другого. Даже TotalCommander’ом файлы качаются быстрее, т.к. по SMB.
Иными словами, любое ПО, которое обращается к штатному API для передачи данных с использованием указанных протоколов, получает преимущества BranchCache без каких-либо затрат и необходимости переписывания приложения.
В плане сетевых протоколов BranchCache поддерживает и IPv4, и IPv6.
Весь трафик BranchCache защищается, применяется алгоритм AES-128 (наилучшее соотношение скорости к надёжности защиты), который вдобавок ко всему сейчас на новых процессорах Intel ускоряется на аппаратном уровне, т.е. дополнительной защиты, например, применяя доменные политики IPSec, не нужно. Всё, что нужно, в общем-то уже есть, осталось настроить и использовать.
Технически BranchCache работает с данными, разбивая их на блоки по 64К и считая хэш каждого блока. Хэш считается по алгоритму SHA-256, т.к. в NT 6.x данный алгоритм, в отличии от NT 5.x есть “из коробки” (коробка называется CNG). Пачка подряд идущих блоков называется сегментом и имеет свой личный хэш. По сути, если рамочно, BranchCache при поиске контента делает следующее – запрашивает по протоколу WS-Discovery у соседей либо у выделенного сервера “есть ли у кого сегмент с таким-то хэшем (запрос хэша сегмента позволяет ощутимо уменьшить сетевой трафик)”. Если сегмент есть – заметьте, даже частично – то идёт обмен вида “давай уточним, у кого что от этого сегмента есть – если у тебя есть блок с хэшем таким-то, то отдай такой блок мне, а я тебе отсутствующие у тебя отправлю). Т.е., ещё раз – единица передачи – файл – делится на блоки фиксированной длины, у каждого блока считается хэш, блоки объединяются в крупные куски – сегменты, и BranchCache позволяет синхронизировать как отсутствующие сегменты целиком, так и отдельные блоки внутри сегментов.
Функционирование BranchCache будет различным в двух разных сценариях его применения – давайте рассмотрим каждый из них по отдельности.
Вариант “с сервером” – BranchCache Hosted Mode
Этот вариант удобен, когда в региональном филиале есть хотя бы один сервер на базе Windows Server 2008 R2. Вариант установки роли не играет, т.к. BranchCache поддерживается в Server Core. Второй плюс такого варианта – возможность аудита “кто что когда скачивал”, в варианте “без сервера” это крайне проблематично.Работа в этом случае выглядит так:
- Клиент хочет скачать какие-то данные, подключается к целевому серверу (например, к файл-серверу в центральном офисе) и декларирует наличие у себя технологии BranchCache. С точки зрения клиентского ПО эта модификация запроса клиента не заметна.
- Сервер понимает, что клиент с поддержкой BranchCache и отдаёт клиенту данные о хэшах сегментов. Заметьте – до самих данных. Т.е. Вы запросили файл – Вам вначале сольют метаданные “на какие сегменты он разделен и какие у них хэши”.
- Клиент останавливает работу с сервером, откуда планировал брать содержимое, и идёт на локальный сервер, на котором расположен кэш BranchCache. Это важно, т.к. если на локальном кэширующем сервере уже есть указанные сегменты, то качаться даже в случае первого обращения уже будет с него, а не с того сервера, куда изначально шёл запрос.
- То, что получится, клиент получит с локального сервера, а остальное – с того, к кому изначально обращался.
- После окончания операции клиент уведомит локальный кэш, что “вот я к тебе обращался за контентом, у тебя было не 100% сегментов/блоков, теперь у меня всё есть, синхронизируемся”. Это важный момент – таким образом, даже единичное успешное скачивание файла “наполнит” локальный кэширующий сервер.
Когда второй клиент захочет тот же файл по SMB – схема повторится – сервер, на котором контент, вернёт метаданные, клиент пойдёт в локальный кэширующий сервер, найдёт там все нужные сегменты, запросит их у сервера, тот их зашифрует и передаст ему поблочно, а клиент расшифрует и сверит хэши блоков – те, которые вернул сервер с контентом, и те, которые вернул локальный сервер.
Важный момент – трафик, в случае поддержки BranchCache со стороны и клиента и сервера, несколько вырастет, но крайне малозаметно – примерно на 0,05%, так как данные BranchCache (хэши блоков и сегментов) занимают примерно в 2000 раз меньше места, чем сами передаваемые данные. Т.е. можно говорить о том, что рост трафика при BranchCache крайне незначителен и может не учитываться как отдельная нагрузка на сеть. Есть распространённое заблуждение, мол, “BranchCache не используется, потому что тогда непонятно когда компы будут трафик постоянно по сети гонять и всё тормозить будет, ведь как торренты ж”. BranchCache, коллеги, не используется, потому что не все умеют его готовить, а в плане нагрузки на сеть он незаметен. :)
Вариант “без сервера” – BranchCache Distributed Mode
Этот вариант удобен, когда в региональном филиале мало рабочих станций и нет сервера. Напомню, что речь только о Windows 7 – на предыдущих ОС всё это не работает. Схема работы будет очень похожа – разве что клиент будет не ходить на локальный кэширующий сервер, а по протоколу WS-Discovery искать других, у кого в кэше есть этот контент.Замечу, что тут тоже есть миф – про то, что “раз оно ищет мультикастом, то работает это всё только в пределах одной подсети”. Типа если в регионе несколько IP-подсетей, то BranchCache не будет “понимать”, что контент уже есть, в случае, когда контент есть в кэше рабочей станции, которая в другом сегменте, нежели запрашивающая. Это не так – рабочие станции с поддержкой BranchCache в случае наличия подключения к нескольким IP-сетям (без разницы – с одним сетевым адаптером или несколькими) будут форвардить запрос на контент, поэтому всё работать будет, притом без оглядки на сетевой протокол – запрос, полученый по IPv4, может уйти дальше по IPv6.
Интересно? Включаем.
Требования к ОС и клиентскому ПО
Технология есть на всех серверных ОС Windows Server 2008 R2; исключение лишь в варианте Server Core Standard, там будут ограничения, рассматриваемые ниже.
Из клиентских ОС поддержка есть в Windows 7 Enterprise и Ultimate; это ещё один повод использовать Enterprise-версию.
Специфичная поддержка со стороны клиентского ПО не требуется; надо лишь, чтобы ПО использовало стандартное API для работы с SMB 2.0 и выше, а также для HTTP/BITS. То есть, к примеру, клиентские браузеры, имеющие свою реализацию передачи HTTP-запросов на сервер, поддерживать BranchCache не смогут – равно как, впрочем, и не-Windows клиенты, у которых с SMB 2.0 до сих пор (с 2006 года, несмотря на открытую документацию) проблемы.
Включаем BranchCache
Включение “движка” BranchCache достаточно просто – в Features у сервера на базе Windows Server 2008 R2 есть компонент с таким названием и нулём дополнительных опций. В Windows 7 компонент встроен, устанавливать его не надо, надо лишь включить. В случае Server Core есть особенность – работа в режиме Hosted Mode возможна только у редакций Enterprise и Datacenter, в Standard его нет – однако, в режиме distributed работать может и Standard. Включить на Server Core надо будет такой компонент:
dism.exe /online /Enable-Feature /FeatureName:PeerDist
Заметим, что это ограничение лишь для выделенного сервера, который хранит централизованный кэш. Для сервера-источника контента такого ограничения нет, т.е. файл-сервер, развёрнутый на базе Windows Server 2008 R2 Standard нормально отдаёт контент и поддерживает BranchCache.
Включение BranchCache на сервере-источнике
Оно будет различаться в зависимости от того, для какой технологии передачи данных Вы будете включать поддержку.
Включение BranchCache на файл-сервере
У роли File Server есть компонент BranchCache for remote files – включите его. Настроек при установке нет. Для ServerCore:
dism.exe /online /Enable-Feature /FeatureName:SMBHashGeneration
Далее мы рассмотрим, как указать какие именно общие папки будут использовать BranchCache.
Тонкость – технологией поддерживается лишь SMBv2. Поэтому целесообразно выключить SMBv1, что настройками на уровне сетевого интерфейса, что с помощью ATcmd.
Вторая тонкость – если у Вас несколько серверов с поддержкой BranchCache в кластере, то надо синхронизировать на них криптографические операции, чтобы не получилось так, что благодаря кластеризации клиент думает, что берёт данные с одного сервера, на самом деле ему отвечают в целях балансировки нагрузки двое, а у этих двоих разные ключи шифрования. Делается это просто – зайдите на все сервера и выполните там разово команду:
netsh branchcache set key passphrase=“случайный ключ, который будет одинаковым на всех серверах в кластере"
Включение BranchCache для WSUS
Аналогично тому, как для файл-сервера – в самом WSUS ничего настраивать не нужно. Клиенты будут обращаться к нему так же, как и без BranchCache, только фактическое копирование файлов будет идти с использованием всех преимуществ BranchCache.
Включение BranchCache для веб-сервера
Достаточно установить фичу BranchCache, и веб-сервер уже поддерживает технологию – что в случае обычных HTTP-запросов, что с BITS. Внимание – в Features есть специальный компонент, находящийся внутри фичи BITS – называется он IIS Server Extension. Его устанавливать для работы BranchCache не нужно, он нужен, когда клиент по BITS закачивает на сервер данные, а не наоборот.
Зайдите в групповую политику, в раздел Computer Configuration / Policies / Administrative Templates / Network / Background Intelligent Transfer Service (BITS), там будет политика Do not allow the BITS client to use BranchCache – убедитесь, что она выключена, чтобы BITS-клиент мог пользоваться преимуществами BranchCache.
Вкратце всё – на источнике контента всё включено. Теперь на клиентах.
Включение BranchCache на клиентах
Общие действия будут просты. Первым делом, зайдём в групповые политики и найдём там такой раздел:
Computer Configuration / Policies / Administrative Templates / BranchCache
В нём поставим политику Turn on BranchCache в предсказуемое значение Enabled. Там же, используя политику Set percentage of disk used by client cache мы сможем указать, сколько процентов от ёмкости диска может быть использовано под кэш. Считаются они от ёмкости дискового раздела, помеченного как active. Замечу, что всё это – настройки на уровне рабочей станции, поэтому на квоты пользователей и подобное это не влияет. Кстати, Вы можете в явном виде указать, где хранить кэшированные данные – для этого есть команда:
set localcache directory=путь вида c:\cacheddata, без закрывающего слэша
Второй параметр – это Configure BranchCache for network files. Он указывает барьерное значение задержки, при котором файлы, получаемые по SMBv2, целесообразно кэшировать – по умолчанию это 80ms, проще всего выставить данный параметр в нуль, тогда файлы будут кэшироваться всегда.
Включение BranchCache на кэширующем сервере
Из специфических действий тут ничего не нужно – та же политика применится, что и в общем случае. Разве что замечу, что для улучшения безопасности лучше в явном виде указать то, что все клиенты должны быть аутентифицированы и быть из одного домена:
netsh branchcache set service mode=HOSTEDSERVER clientauthentication=DOMAIN
DOMAIN – это не название домена, а слово DOMAIN.
Включение BranchCache на peer-клиенте
Из специфических действий тут тоже негусто. Если работаем в режиме “с выделенным сервером”, то укажем его FQDN:
netsh branchcache set service mode=HOSTEDCLIENT location=FQDN сервера с ролью кэша
Режим Если в режиме “без выделенного сервера”:
netsh branchcache set service mode=DISTRIBUTED
В случае настроек рабочей станции можно также указать логику работы в случае “я в режиме экономии электроэнергии, а ко мне по WS-Discovery приходят и просят данные, что делать – включаться и обрабатывать запрос, или нет?”. Команда для включения работыв такой ситуации выглядит так:
netsh branchcache set service serveonbattery=TRUE
, ну а если не хотите – то укажите FALSE.
Все упомянутые команды будут автоматически создавать исключения во встроенном advfirewall’е для BranchCache-трафика в случае HTTP/HTTPS. В случае SMBv2 специальных исключений в advfirewall создавать не нужно.
Сетевые настройки BranchCache
Специфический трафик, используемый BranchCache для общения между участниками при поиске кэшированных данных – это UDP с портом номер 3702, мультикастовые адреса – 239.255.255.250 для IPv4, ff02::c для IPv6. Имеет смысл разрешить данный трафик централизованно, через групповые политики. Но в том случае, если у Вас “безсерверный режим” (distributed cache который), ведь только тогда клиенты “на ощупь” ищут соседей, у которых уже закэширован контент. В случае работы с выделенным сервером этот порт не используется, т.к. клиент сразу знает, к кому обращаться с запросом “ближней” копии контента.
В случае режима без выделенного сервера также необходимо добавить на клиентах разрешение на входящий/исходящий HTTP(S)-трафик на стандартные TCP-порты 80 и 443, потому что скачивание данных будет идти путём подключения одного клиента к другому. Для повышения безопасности лучше в явном виде указать, что обмен этим трафиком идёт внутри сетей предприятия, т.е. не разрешать доступ на каждую рабочую станцию на HTTP(S) порты откуда угодно, а только из внутренних IP-сетей.
Привязка сертификата для подтверждения подлинности сервера BranchCache
В сценарии с выделенным сервером необходимо, чтобы сервер мог подтвердить свою подлинность клиентам. Это делается путём привязки одноги из сертификатов в локальном хранилище сервера к службе BranchCache. Сделать это несложно. Зайдите на сервер, который держит роль HOSTEDSERVER, откройте локальное хранилище сертификатов для компьютера, выберете там тот, который содержит 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}
В случае, если запросы слушаются без ограничения по IP-адресам на сервере, укажите адрес 0.0.0.0. Теперь BranchCache “знает”, какой сертификат предъявлять клиентам, подключающимся по HTTPS для синхронизации содержимого.
Смена номеров портов у BranchCache
Данная операция будет выполняться опять же в два этапа – смена портов со стороны сервера и со стороны клиентов. Хитрость в том, что в этом сценарии используются оба порта – и 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 и указываем новые значения – первый ключ отвечает за 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\
Там – DWORD32 с названием ConnectPort, где и укажем новые номера портов.
После всех этих манипуляций надо будет перезапустить сервис (и на клиентах, и на сервере), можно например так:
net stop peerdistsvc && net start peerdistsvc
Теперь осталось разве что включить BranchCache на выбранных общих папках
Включаем BranchCache на выбранных общих папках
Это несложно – зайдите на сервере в настройки нужной папки, там во вкладке Sharing есть Advanced Sharing, а там – кнопка “Caching”. Если BranchCache включен, то будет доступен пункт с предсказуемым названием – Enable BranchCache. Технология работает.
Мониторинг BranchCache
Самый простой способ – выполнить в netsh команду netsh branchcache show status ALL. Остальное хорошо мониторится путём просмотра локальной серверной папки, где хранится кэш (в ней должны появляться кэшируемые файлы), ну и изучением логов. Сервис BranchCache, на самом деле, не обладает огромным числом функций и сломать его довольно сложно, поэтому какой-то ультра-продвинутый траблшутинг тут проводить особо смысла не имеет – выбрали нужный сценарий (с сервером или без), поставили компонент куда надо, включили через политику, сконфигурировали опциональные возможности (типа размера локального кэша и места его хранения). В общем-то всё.
Заключение
Данная технология, увы, используется редко, хотя достаточно полезна и существует уже несколько лет. Думаю, что теперь Вы сможете пользоваться ей ощутимо свободнее и проще, чем раньше.
Удач!
