Microsoft — мировой лидер в области ПО и ИТ-услуг
185,27
рейтинг
21 июля 2010 в 01:08

Разное → 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

В чем ключевое отличие 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 не может работать одновременно и в одном, и в другом режиме.

Поддержка HTTP

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

Объем данных на файловых серверах может быть очень большим и при высокой нагрузке вычисление хэшей оказывается весьма затратной операцией. Как следствие, в случае с 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 и управляется штатными средставми.
Автор: @ashapo
Microsoft
рейтинг 185,27
Microsoft — мировой лидер в области ПО и ИТ-услуг

Комментарии (64)

  • –9
    проприетарненько. да и что-то я мало себе представляю офисов, где стоят w7 enterprise и 2008r2.
    да и кэширование только от иис-а расстраивает.
    • +9
      Проприетарненько — это не упрек для хорошей технологии. Поверьте, в средне-крупных компаниях как раз W7+W2K8R2 стоят. И по логике Branchcache отлично может разгрузить каналы. Тут стоит упомянуть что технология хорошо работает вместе с Sharepoint2010, который в свою очередь часто используется как общее место хранения пользовательских данных. Так вот вместо того чтобы делать зеркало ContentDB (а это, читай — ставить SQL) для небольшого филиала — тут и приходит на помощь эта технология.
      • –3
        В единственной известной мне изнутри крупной компании на серверах были какие угодно юниксы, но только юниксы. А на рабочие машинки разрешалось ставить Windows при письменном обосновании необходимости и с обязательным соблюдением немаленького перечня инструкций по безопасности (ежедневный антивирус и т.д.), остальные же использовали юниксы… на вкус сотрудника.

        Проприетарность — не упрёк хорошей технологии, но может сильно повлиять на решение о её внедрении или не внедрении.
        • +1
          Выборка нерепрезентативна? :D
          • –1
            :D Я вам не мешаю?
            • 0
              Разговаривать с плюсами-минусами на Хабре — норма. Большинству посетителей лень печатать ответ.
        • +1
          А мне известно очень много крупных компаний где в основе инфраструктуры используются технологии Microsoft. Причем есть среди них и телеком бывший традиционным прибежищем Unix/Linux.

          ИМХО ваши наблюдения не полны и строить на них какие либо выводы невозможно.
          • 0
            >>> Поверьте, в средне-крупных компаниях как раз W7+W2K8R2 стоят.

            Это утверждение опровергается примером. Я его привёл. Ведь вы тоже не все в мире средне-крупные компании видели.
            • +1
              Есть подозрение что как сотрудник Microsoft я общаюсь с достаточно гораздо большим количеством компаний чем вы. Хотя и не со всеми. :)

              А вообще есть статистика от IDC по долям продаж на серверном рынке для каждого вендора www.idc.com/getdoc.jsp?containerId=prUS22100809

              Если смотреть на нее то:
              Microsoft Windows server — 43%
              Linux servers -14.8%
              Unix Servers — 26.9%
              • НЛО прилетело и опубликовало эту надпись здесь
                • 0
                  Я как раз специализируюсь на победе над конкурентами в крупных клиентах. Так что видел много компаний которые когда то использовали Unix.

                  Теперь они используют и Microsoft.
                  • –1
                    Адепт зла :)
                    • 0
                      Я просто профессионал знающий свою работу.

                      Зло и добро к таким категориям как внедрение тех или иных продуктов врядли применимо. :)
              • 0
                Конечно, это ведь статистика продаж, а не инсталяций.
                • 0
                  Вы сморозили редкостную глупость и чрезвычайно повеселили.

                  Это ведь очевидно что сервера с Windows покупают чтобы снести установленную ОС и поставить Linux.

                  Именно так с Microsoft и нужно бороться. :)
                  • 0
                    Вы сравнили статистику сферических продаж (да еще с неработающим пруф-линком). А выше вас написали об ИСПОЛЬЗОВАНИИ ОС от Microsoft и Unix-like.

                    Ясен перец бесплатная операционная система (красную шапку в расчет не берем) проиграет платному продукту в продажах, уважаемый Тролль.
                    • 0
                      А вам в голову не приходило что покупают Windows для того чтобы использовать?

                      Или вы считаете что люди тратят миллиарды просто для того чтобы потролить?

                      RedHat занимает 80% рынка платных Linux. И вы таки верите что бесплатный Linux используют все?

        • +1
          Примером российской компании, где внедрен BranchCache, может послужить «Вимм-Билль-Данн». А вообще, если компания уже использует Windows 7, то почему бы не задействовать встроенную возможность. Если речь идет о принятии решения, то BranchCache может доолнительно на это решение повлиять. Но, безусловно, окончательный выбор — дело конкретной компании.
    • +1
      На мой взгляд, таких офисов предостаточно, особенно если у организации заключен Enterprise Agreement. Что касается кэширования. Веб-сервер должен уметь взаимодействовать с сервисом генерации метаданных и отдавать эти самые метаданные в ответ на запрос клиента. Иными словами, веб-сервер «должен знать» о существовании BranchCache. Такая поддержка и была добавлена в IIS 7.5. Apache, например, по умолчанию конечно же ничего про BranchCache «не знает». Поэтому и кэширование при его использовании работать не будет. Однако BranchCache имеет соответствующий API, и поддержка BranchCache может быть добавлена в другие приложения.
  • 0
    Что-то с заголовками в Хроме чепуха творится, квадратики-с.
    • 0
      у меня в Хроме все окей, изменений не вносил
    • 0
      У меня 5,0,375,99 все нормально
  • +6
    хорошо пИшите, с нетерпением жду про DirectAccess
    • 0
      раз просите, будет и про DirectAccess!
    • +3
      Да, тоже интересно почитать.
      Если я правильно понял то, что писали про этот Direct Access — это очень сложная и бесполезная технология, требующая ipv6 и развернутого PKI, жутко сложная в настройке и непонятно зачем нужная, когда уже есть VPN лет эдак много.
      • +1
        Мда.
        VPN — это on-demand технология, надо юзверю — «позвонил» в офис, поработал отключился; админ доступа к этой машине не имеет.
        DA — это always on технология, как только есть хоть какая-то возможность зацепиться к офису — цепляемся и получаем полный доступ к сети офиса; админ со товарищи (wsus, sc*, dc, gpo) имеют доступ к машине.

        Для развертывания нужен PKI внутри (т.к. шифрование), IPv6 так же нужен только внутри, снаружи достаточно двух последовательных IPv4 адресов для DA сервера.
        • +1
          Ну, теоретически — тот же VPN можно, немного поизвращавшись, заставить подключаться всегда, как только есть выход в инет :)
          Вот для чего было придумывать целое новое слово «DirectAccess» — не понятно. Каким бы фанатом MS я ни был.
          • 0
            «Небольшая» разница тут в том, что при VPN-соединении начинают использоваться внутренние DNS-ы, интернет соответственно тоже черпается изнутри корпоративной сети, что явно не добавляет удобства. Хорошо, можно назвать этол новшество «VPN без потери интернета», но это не так уж и мало!
            Во-вторых, так проще пользователю — ему не надо задумываться про «Установить VPN-соединение».
            «Очень сложная» — не сказал бы, посмотрите вебкасты и статьи по теме (кажется на itband была хорошая, кстати), все там достаточно ясно.
            IPv6 по умолчанию в линейке W2K8R2 и W7, и эта технология собственно с ними и работает.
            PKI это уже практически must-have для всех продуктов, ничего тут страшного.
            Про IPv6 уже написали — трюки с Teredo, 6to4, isatap, ip-https позволяют иметь IPv6 только на очень малом сегменте внутренней сети.
            P.S. Вот надеюсь через неделю-две чуть-чуть времени прибавится — буду пробовать, постараюсь отчитаться как оно.
            • 0
              А зачем там IPv6? Неужели нельзя использовать обычный IPSec и IPv4?
              • 0
                Теоретически наверное и можно бы было… Но IPv6 как раз и понадобится для устранения таких технологий как NAT (привет, публикации и VPN) и устранения понятия «внутренний адрес» как такого. Да, в стандарте есть про внутренние диапазоны, но их использование будет необходимо скорее для полной изоляции внутренней сети, чем от самого факта нехватки IP-адресов (что по сути сейчас и заставляет использовать приватные диапазоны). Так что я бы рассматривал DirectAccess и в качестве технологии инкапсуляции IPv6 со всеми вытекающими ее прелестями в IPv4.
              • 0
                Это-то как раз полезно. Извечная проблема: у нас с одной стороны 192.168.0/24 и с другой стороны 192.168.0/24 — как понять куда трафик кидать? Никак. Уйдет по метрике — либо туда, либо туда.
              • +2
                У IPv6 есть несколько существенных преимуществ. Одно из них — огромное адресное пространство, которое позволяет присвоить уникальный айпишник любому устройству. Как следствие, можно забыть про NAT и связанные с ним проблемы. Одну проблему Roy уже упомянул. Вторая проблема — приложения, которые должны уметь работать через NAT. Еще одно преимущество IPv6 — это как раз IPSec. Да, он давно есть для IPv4, но появился существенно позже самого протокола IP. В результате, есть несколько различных реализаций IPSec. Легко можно столкнуться с ситуацией, когда, скажем, роутеры разных производителей не могут «дружить» по IPSec. Или поддержка IPSec вообще отсутствует. Для IPv6 IPSec проектировался изначально и является обязательным для реализации. Вы можете использовать IPv6 и при этом не использовать IPSec. Но если в документации на ваше устройство сказано, что поддерживается IPv6, по определению поддерживается и IPSec. Есть еще несколько деталей, о которых напишу в посте по DirectAccess.
            • 0
              > Хорошо, можно назвать этол новшество «VPN без потери интернета», но это не так уж и мало!
              «VPN без потери интернета» — это split-tunneling, какие-то сети уходят в туннель, остальное (Интернет) напрямую.
              DNS вообще всегда сначала используются локальные. Чтобы это поведение изменить нужно в реестре порядок интерфейсов менять.

    • +1
      Спасибо! Тема и правда интересная, напишу.
  • 0
    Саша сейчас в Америке, поэтому на возможные вопросы сможет ответить только поздно вечером
  • +4
    Microsoft на Хабре — торт ;)

    А то на новостных сайтах, интервью и даже оф. сайте всё больше красивые маркетоидные слова и миллионы кубометров воды.
    • 0
      стараемся и будем стараться!
      • 0
        Это жорошо! Это просто отлично! Долой воду, даёшь тех подробности! А то кроме Руссиновича читать и нечего толком… Разве что вас всех по частным блогам выискивать (:
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Да нет, вы что-то путаете, Microsoft для этого давно уж придумал robocopy. Не подскажете ли, кстати, где почитать про open-source аналог DirectAccess?
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Комментарий дельный, но все же добавлю. Положим, вы установили VPN-соединение — что теперь у вас является шлюзом по умолчанию и primary DNS? Как приложение будет знать — ему в интернет надо либо к ресурсу в VPN-сети? Основная фишка DirectAccess как раз в том, что запросы к интернет-ресурсам продолжают идти через чистый интернет в обход DA-сервера и разрешаются внешними DNS, тогда как запросы к внутренним ресурсам (и только к ним) идут через DA-сервер. Причем все это прозрачно. Кроме того, DirectAccess устанавливает соединение до логона пользователя, что позволяет применяться групповым политикам и управлять компьютером даже в незалогиненном состоянии, обратите на это внимание.
          • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              Вы меня почти убедили, за исключением только вот DNS. К сожалению, если primary-сервер дал ответ (пусть даже «отфутбол», что такого хоста нету у него, но все же какой-то ответ дал) — второй прописанный сервер уже опрашиваться не будет, и вот тут уже начинаются сложности. И да, DirectAccess ведь бесплатная роль, почему не использовать если банально проще в настройке и поддержке?
              • НЛО прилетело и опубликовало эту надпись здесь
                • 0
                  А в семёрке нельзя настроить серверы имён для определённых доменов (через политики и т.п.)? Или эта фишка работает только для DA?
                  • 0
                    Можно, собственно для DA это настраивается обычными политиками DNS client'а.
            • 0
              >>в таблицу машрутизации прописывается, что всё в 10.0.0.0/8 идёт через VPN
              я посмотрю как оно пойдёт, если комп в этот момент сам сидит в 10./8
            • 0
              Вы бы сначала ознакомились с теорией, потому уж DA втаптывали…
              DA предназначен для соединения мобильных клиентов с внутренней сетью предприятия (как со всей сетью, так и с (!) выборочными хостами), при этом есть несколько транспортов для достижения данной цели, ipv6, ipv4 (ipv6 over ipv4), https; также из-за наличия нескольких транспортов, DA может работать из «серых», сильно порезанных сетей, необходимый минимум — доступный DNS и HTTPS.
              • НЛО прилетело и опубликовало эту надпись здесь
                • +1
                  Как жеж тяжело общаться с человеком, который не хочет сам узнать про технологию, но «имеет мнение».
                  Да, VPN может работать поверх чего угодно, хоть avian carriers; да, можно настроить vpn сервер и его фаервол чтобы клиенты могли ходить только куда надо, а не только по всей сетке; да, можно засунуть rasdial в user-startup чтобы соединение поднималось сразу при входе пользователя. Это всё можно сделать и так, но на это понадобится неимоверное кол-во времени для внедрения, и неимоверное количество ресурсов для поддержки, и, самое главное, это будет делаться разными инструментами. Ибо VPN клиент — это инструмент, не более, точно так же GPO и фаервол на VPN сервере.
                  DA же — это комплекс, который позволяет добится всего выше описанного из одной, единой точки администрирования, и не тратить время на решение ненужных проблем.
                  Крайне рекомендую ознакомится с blogs.technet.com/b/abeshkov/archive/2009/06/28/direct-access.aspx
                  , особенно с www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=70723e47-3d57-415b-9182-744ceaf8c04a#tm и unifiedcommunicationrus.spaces.live.com/blog/cns!CFE8060EACAACE49!186.entry?wa=wsignin1.0&sa=147536323
  • 0
    спасибо, интересно узнать, используется ли технология remote differential compression внутри BranchCache. Если да, то копирование файлов по SMB должно работать примерно также, как в rsync, еще одна возможность ускорить работу по WAN. Кроме того, M$ сам бог велел организовать дополнительную оптимизацию при передаче файлов собственных форматов (doc/xls/ppt/mdb/pst etc.)
    В целом, BranchCache выглядит своевременной попыткой вторгнуться с решением программным на рынок компаний, выпускающих «железные» решения, вроде Bluecoat.
    С учетом большой стоимости и закрытости железяк, возможно, BranchCache будет востребованным, жаль, что для реализации требуются весьма дорогие версии Windows 7.
  • 0
    Классное начало: «С выхода Windows 7 прошел ПОЧТИ год, чем не повод вспомнить...». Очень напоминает «Сегодня отличный денек! Не вижу повода не выпить!» :)
    • +1
      А почему бы нет? :) Хотя для меня, как наверное и для многих моих коллег, выход Семерки — это более чем значимое событие
  • 0
    чем-то это напоминает битторрент…
    а вот с HTTP не очень понятно, в условиях указан W7 + W2008 сервер — но вот допустим я открываю страницу из Firefox — будет ли работать кеширование?
    • 0
      Начнем с HTTP. Поскольку модуль BranchCache встроен только в Windows Server 2008 R2 и Windows 7, наверное уже понятно, что BranchCache для HTTP применим, только если в качестве веб-сервера используется IIS 7.5 из состава Windows Server 2008 R2.

      Тут имеется ввиду для внутренних корпоративных сайтов — OWA, Sharepoint и т.д.
      • 0
        ну так ни слова про IE, только про серверную часть!
        так IE или FF?
        • 0
          Есть смутное подозрение, что будет работать только с клиентами, использующими WinINet (функции InternetOpenUrl и подобные). То есть, FF — вряд ли:)
          • 0
            Ну и WinHTTP, конечно же. И аналогичные обертки в .NET.
    • +1
      Да, на одном из семинаров так и сказали: «О, Microsoft написала свой торрент». Если Firefox использует HTTP, встроенный в Windows, кэширование будет работать.
  • 0
    Наконец, в силу того, что BranchCache фактически отрабатывает до транспортных механизмов,…

    Я думаю отсюда понятно, что каким браузером смотреть — по сути фиолетово должно быть. Если тут конечно правильная формулировка в статье.
  • 0
    Все страннее и страннее логика решений от Microsoft: с одной стороны на лицо сужение используемого трафика при обращении к справочной информации, с другой при частом изменение файлов в филиалах трафик сужается незначительно, но возрастает нагрузка на сервера, высчитывающих хэш-суммы.
    Еще смущает модульность технологий — технология кэширования отдельно и технология безопасности отдельно, т.е. недостаточно настроить только одну службу Branchcashe, а надо дополнительно поднимать службы безопасности. И это коробочное проприетарное решение.
    Такая разорванность с виду связанных технологий характерна для Microsoft. Возможно это связано в слабом горизонтальном взаимодействие департаментов в большой корпорации.
    • 0
      Это ни в коем случае не значит, что я думаю, что данная технология не найдет широкое применение в enterprise.
    • +1
      Мне, честно говоря, логика самого решения не кажется странной. Данные в BrancheCache всегда актуальны. Это — принципиальный момент. Отсюда вытекает логика работы, а за ней и сфера применения. Понимая логику работы и зная специфику своих данных, Вы решаете насколько в Вашей конкретной ситуации (для конкретных серверов и даже шар) будет эффективен этот механизм.
      Что касается безопасности — достаточно настроить только BranchCache. Он гарантирует безопасное общение с «соседями». Но если нужно дополнительно закрутить безопасность, то Вы включаете дополнительные службы. Ведь речь идет об обыкновенных файлах, с которыми работает пользователь, а не о каких-то особенных конфиденциальных документах. Есть смысл по умолчанию шифровать кэш, если, скачав файл, пользователь сохраняет его в незашифрованной папке «Мои документы»?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное