Комментарии 64
проприетарненько. да и что-то я мало себе представляю офисов, где стоят w7 enterprise и 2008r2.
да и кэширование только от иис-а расстраивает.
да и кэширование только от иис-а расстраивает.
Проприетарненько — это не упрек для хорошей технологии. Поверьте, в средне-крупных компаниях как раз W7+W2K8R2 стоят. И по логике Branchcache отлично может разгрузить каналы. Тут стоит упомянуть что технология хорошо работает вместе с Sharepoint2010, который в свою очередь часто используется как общее место хранения пользовательских данных. Так вот вместо того чтобы делать зеркало ContentDB (а это, читай — ставить SQL) для небольшого филиала — тут и приходит на помощь эта технология.
В единственной известной мне изнутри крупной компании на серверах были какие угодно юниксы, но только юниксы. А на рабочие машинки разрешалось ставить Windows при письменном обосновании необходимости и с обязательным соблюдением немаленького перечня инструкций по безопасности (ежедневный антивирус и т.д.), остальные же использовали юниксы… на вкус сотрудника.
Проприетарность — не упрёк хорошей технологии, но может сильно повлиять на решение о её внедрении или не внедрении.
Проприетарность — не упрёк хорошей технологии, но может сильно повлиять на решение о её внедрении или не внедрении.
Выборка нерепрезентативна? :D
А мне известно очень много крупных компаний где в основе инфраструктуры используются технологии Microsoft. Причем есть среди них и телеком бывший традиционным прибежищем Unix/Linux.
ИМХО ваши наблюдения не полны и строить на них какие либо выводы невозможно.
ИМХО ваши наблюдения не полны и строить на них какие либо выводы невозможно.
>>> Поверьте, в средне-крупных компаниях как раз W7+W2K8R2 стоят.
Это утверждение опровергается примером. Я его привёл. Ведь вы тоже не все в мире средне-крупные компании видели.
Это утверждение опровергается примером. Я его привёл. Ведь вы тоже не все в мире средне-крупные компании видели.
Есть подозрение что как сотрудник Microsoft я общаюсь с достаточно гораздо большим количеством компаний чем вы. Хотя и не со всеми. :)
А вообще есть статистика от IDC по долям продаж на серверном рынке для каждого вендора www.idc.com/getdoc.jsp?containerId=prUS22100809
Если смотреть на нее то:
Microsoft Windows server — 43%
Linux servers -14.8%
Unix Servers — 26.9%
А вообще есть статистика от IDC по долям продаж на серверном рынке для каждого вендора www.idc.com/getdoc.jsp?containerId=prUS22100809
Если смотреть на нее то:
Microsoft Windows server — 43%
Linux servers -14.8%
Unix Servers — 26.9%
НЛО прилетело и опубликовало эту надпись здесь
Конечно, это ведь статистика продаж, а не инсталяций.
Вы сморозили редкостную глупость и чрезвычайно повеселили.
Это ведь очевидно что сервера с Windows покупают чтобы снести установленную ОС и поставить Linux.
Именно так с Microsoft и нужно бороться. :)
Это ведь очевидно что сервера с Windows покупают чтобы снести установленную ОС и поставить Linux.
Именно так с Microsoft и нужно бороться. :)
Примером российской компании, где внедрен BranchCache, может послужить «Вимм-Билль-Данн». А вообще, если компания уже использует Windows 7, то почему бы не задействовать встроенную возможность. Если речь идет о принятии решения, то BranchCache может доолнительно на это решение повлиять. Но, безусловно, окончательный выбор — дело конкретной компании.
На мой взгляд, таких офисов предостаточно, особенно если у организации заключен Enterprise Agreement. Что касается кэширования. Веб-сервер должен уметь взаимодействовать с сервисом генерации метаданных и отдавать эти самые метаданные в ответ на запрос клиента. Иными словами, веб-сервер «должен знать» о существовании BranchCache. Такая поддержка и была добавлена в IIS 7.5. Apache, например, по умолчанию конечно же ничего про BranchCache «не знает». Поэтому и кэширование при его использовании работать не будет. Однако BranchCache имеет соответствующий API, и поддержка BranchCache может быть добавлена в другие приложения.
Что-то с заголовками в Хроме чепуха творится, квадратики-с.
хорошо пИшите, с нетерпением жду про DirectAccess
раз просите, будет и про DirectAccess!
Да, тоже интересно почитать.
Если я правильно понял то, что писали про этот Direct Access — это очень сложная и бесполезная технология, требующая ipv6 и развернутого PKI, жутко сложная в настройке и непонятно зачем нужная, когда уже есть VPN лет эдак много.
Если я правильно понял то, что писали про этот Direct Access — это очень сложная и бесполезная технология, требующая ipv6 и развернутого PKI, жутко сложная в настройке и непонятно зачем нужная, когда уже есть VPN лет эдак много.
Мда.
VPN — это on-demand технология, надо юзверю — «позвонил» в офис, поработал отключился; админ доступа к этой машине не имеет.
DA — это always on технология, как только есть хоть какая-то возможность зацепиться к офису — цепляемся и получаем полный доступ к сети офиса; админ со товарищи (wsus, sc*, dc, gpo) имеют доступ к машине.
Для развертывания нужен PKI внутри (т.к. шифрование), IPv6 так же нужен только внутри, снаружи достаточно двух последовательных IPv4 адресов для DA сервера.
VPN — это on-demand технология, надо юзверю — «позвонил» в офис, поработал отключился; админ доступа к этой машине не имеет.
DA — это always on технология, как только есть хоть какая-то возможность зацепиться к офису — цепляемся и получаем полный доступ к сети офиса; админ со товарищи (wsus, sc*, dc, gpo) имеют доступ к машине.
Для развертывания нужен PKI внутри (т.к. шифрование), IPv6 так же нужен только внутри, снаружи достаточно двух последовательных IPv4 адресов для DA сервера.
Ну, теоретически — тот же VPN можно, немного поизвращавшись, заставить подключаться всегда, как только есть выход в инет :)
Вот для чего было придумывать целое новое слово «DirectAccess» — не понятно. Каким бы фанатом MS я ни был.
Вот для чего было придумывать целое новое слово «DirectAccess» — не понятно. Каким бы фанатом MS я ни был.
«Небольшая» разница тут в том, что при VPN-соединении начинают использоваться внутренние DNS-ы, интернет соответственно тоже черпается изнутри корпоративной сети, что явно не добавляет удобства. Хорошо, можно назвать этол новшество «VPN без потери интернета», но это не так уж и мало!
Во-вторых, так проще пользователю — ему не надо задумываться про «Установить VPN-соединение».
«Очень сложная» — не сказал бы, посмотрите вебкасты и статьи по теме (кажется на itband была хорошая, кстати), все там достаточно ясно.
IPv6 по умолчанию в линейке W2K8R2 и W7, и эта технология собственно с ними и работает.
PKI это уже практически must-have для всех продуктов, ничего тут страшного.
Про IPv6 уже написали — трюки с Teredo, 6to4, isatap, ip-https позволяют иметь IPv6 только на очень малом сегменте внутренней сети.
P.S. Вот надеюсь через неделю-две чуть-чуть времени прибавится — буду пробовать, постараюсь отчитаться как оно.
Во-вторых, так проще пользователю — ему не надо задумываться про «Установить VPN-соединение».
«Очень сложная» — не сказал бы, посмотрите вебкасты и статьи по теме (кажется на itband была хорошая, кстати), все там достаточно ясно.
IPv6 по умолчанию в линейке W2K8R2 и W7, и эта технология собственно с ними и работает.
PKI это уже практически must-have для всех продуктов, ничего тут страшного.
Про IPv6 уже написали — трюки с Teredo, 6to4, isatap, ip-https позволяют иметь IPv6 только на очень малом сегменте внутренней сети.
P.S. Вот надеюсь через неделю-две чуть-чуть времени прибавится — буду пробовать, постараюсь отчитаться как оно.
А зачем там IPv6? Неужели нельзя использовать обычный IPSec и IPv4?
Теоретически наверное и можно бы было… Но IPv6 как раз и понадобится для устранения таких технологий как NAT (привет, публикации и VPN) и устранения понятия «внутренний адрес» как такого. Да, в стандарте есть про внутренние диапазоны, но их использование будет необходимо скорее для полной изоляции внутренней сети, чем от самого факта нехватки IP-адресов (что по сути сейчас и заставляет использовать приватные диапазоны). Так что я бы рассматривал DirectAccess и в качестве технологии инкапсуляции IPv6 со всеми вытекающими ее прелестями в IPv4.
Это-то как раз полезно. Извечная проблема: у нас с одной стороны 192.168.0/24 и с другой стороны 192.168.0/24 — как понять куда трафик кидать? Никак. Уйдет по метрике — либо туда, либо туда.
У IPv6 есть несколько существенных преимуществ. Одно из них — огромное адресное пространство, которое позволяет присвоить уникальный айпишник любому устройству. Как следствие, можно забыть про NAT и связанные с ним проблемы. Одну проблему Roy уже упомянул. Вторая проблема — приложения, которые должны уметь работать через NAT. Еще одно преимущество IPv6 — это как раз IPSec. Да, он давно есть для IPv4, но появился существенно позже самого протокола IP. В результате, есть несколько различных реализаций IPSec. Легко можно столкнуться с ситуацией, когда, скажем, роутеры разных производителей не могут «дружить» по IPSec. Или поддержка IPSec вообще отсутствует. Для IPv6 IPSec проектировался изначально и является обязательным для реализации. Вы можете использовать IPv6 и при этом не использовать IPSec. Но если в документации на ваше устройство сказано, что поддерживается IPv6, по определению поддерживается и IPSec. Есть еще несколько деталей, о которых напишу в посте по DirectAccess.
> Хорошо, можно назвать этол новшество «VPN без потери интернета», но это не так уж и мало!
«VPN без потери интернета» — это split-tunneling, какие-то сети уходят в туннель, остальное (Интернет) напрямую.
DNS вообще всегда сначала используются локальные. Чтобы это поведение изменить нужно в реестре порядок интерфейсов менять.
«VPN без потери интернета» — это split-tunneling, какие-то сети уходят в туннель, остальное (Интернет) напрямую.
DNS вообще всегда сначала используются локальные. Чтобы это поведение изменить нужно в реестре порядок интерфейсов менять.
Спасибо! Тема и правда интересная, напишу.
Саша сейчас в Америке, поэтому на возможные вопросы сможет ответить только поздно вечером
Microsoft на Хабре — торт ;)
А то на новостных сайтах, интервью и даже оф. сайте всё больше красивые маркетоидные слова и миллионы кубометров воды.
А то на новостных сайтах, интервью и даже оф. сайте всё больше красивые маркетоидные слова и миллионы кубометров воды.
НЛО прилетело и опубликовало эту надпись здесь
Да нет, вы что-то путаете, Microsoft для этого давно уж придумал robocopy. Не подскажете ли, кстати, где почитать про open-source аналог DirectAccess?
НЛО прилетело и опубликовало эту надпись здесь
Комментарий дельный, но все же добавлю. Положим, вы установили VPN-соединение — что теперь у вас является шлюзом по умолчанию и primary DNS? Как приложение будет знать — ему в интернет надо либо к ресурсу в VPN-сети? Основная фишка DirectAccess как раз в том, что запросы к интернет-ресурсам продолжают идти через чистый интернет в обход DA-сервера и разрешаются внешними DNS, тогда как запросы к внутренним ресурсам (и только к ним) идут через DA-сервер. Причем все это прозрачно. Кроме того, DirectAccess устанавливает соединение до логона пользователя, что позволяет применяться групповым политикам и управлять компьютером даже в незалогиненном состоянии, обратите на это внимание.
НЛО прилетело и опубликовало эту надпись здесь
Вы меня почти убедили, за исключением только вот DNS. К сожалению, если primary-сервер дал ответ (пусть даже «отфутбол», что такого хоста нету у него, но все же какой-то ответ дал) — второй прописанный сервер уже опрашиваться не будет, и вот тут уже начинаются сложности. И да, DirectAccess ведь бесплатная роль, почему не использовать если банально проще в настройке и поддержке?
>>в таблицу машрутизации прописывается, что всё в 10.0.0.0/8 идёт через VPN
я посмотрю как оно пойдёт, если комп в этот момент сам сидит в 10./8
я посмотрю как оно пойдёт, если комп в этот момент сам сидит в 10./8
Вы бы сначала ознакомились с теорией, потому уж DA втаптывали…
DA предназначен для соединения мобильных клиентов с внутренней сетью предприятия (как со всей сетью, так и с (!) выборочными хостами), при этом есть несколько транспортов для достижения данной цели, ipv6, ipv4 (ipv6 over ipv4), https; также из-за наличия нескольких транспортов, DA может работать из «серых», сильно порезанных сетей, необходимый минимум — доступный DNS и HTTPS.
DA предназначен для соединения мобильных клиентов с внутренней сетью предприятия (как со всей сетью, так и с (!) выборочными хостами), при этом есть несколько транспортов для достижения данной цели, ipv6, ipv4 (ipv6 over ipv4), https; также из-за наличия нескольких транспортов, DA может работать из «серых», сильно порезанных сетей, необходимый минимум — доступный DNS и HTTPS.
НЛО прилетело и опубликовало эту надпись здесь
Как жеж тяжело общаться с человеком, который не хочет сам узнать про технологию, но «имеет мнение».
Да, 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
Да, 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
спасибо, интересно узнать, используется ли технология remote differential compression внутри BranchCache. Если да, то копирование файлов по SMB должно работать примерно также, как в rsync, еще одна возможность ускорить работу по WAN. Кроме того, M$ сам бог велел организовать дополнительную оптимизацию при передаче файлов собственных форматов (doc/xls/ppt/mdb/pst etc.)
В целом, BranchCache выглядит своевременной попыткой вторгнуться с решением программным на рынок компаний, выпускающих «железные» решения, вроде Bluecoat.
С учетом большой стоимости и закрытости железяк, возможно, BranchCache будет востребованным, жаль, что для реализации требуются весьма дорогие версии Windows 7.
В целом, BranchCache выглядит своевременной попыткой вторгнуться с решением программным на рынок компаний, выпускающих «железные» решения, вроде Bluecoat.
С учетом большой стоимости и закрытости железяк, возможно, BranchCache будет востребованным, жаль, что для реализации требуются весьма дорогие версии Windows 7.
Классное начало: «С выхода Windows 7 прошел ПОЧТИ год, чем не повод вспомнить...». Очень напоминает «Сегодня отличный денек! Не вижу повода не выпить!» :)
чем-то это напоминает битторрент…
а вот с HTTP не очень понятно, в условиях указан W7 + W2008 сервер — но вот допустим я открываю страницу из Firefox — будет ли работать кеширование?
а вот с HTTP не очень понятно, в условиях указан W7 + W2008 сервер — но вот допустим я открываю страницу из Firefox — будет ли работать кеширование?
Начнем с HTTP. Поскольку модуль BranchCache встроен только в Windows Server 2008 R2 и Windows 7, наверное уже понятно, что BranchCache для HTTP применим, только если в качестве веб-сервера используется IIS 7.5 из состава Windows Server 2008 R2.
Тут имеется ввиду для внутренних корпоративных сайтов — OWA, Sharepoint и т.д.
Да, на одном из семинаров так и сказали: «О, Microsoft написала свой торрент». Если Firefox использует HTTP, встроенный в Windows, кэширование будет работать.
Наконец, в силу того, что BranchCache фактически отрабатывает до транспортных механизмов,…
Я думаю отсюда понятно, что каким браузером смотреть — по сути фиолетово должно быть. Если тут конечно правильная формулировка в статье.
Все страннее и страннее логика решений от Microsoft: с одной стороны на лицо сужение используемого трафика при обращении к справочной информации, с другой при частом изменение файлов в филиалах трафик сужается незначительно, но возрастает нагрузка на сервера, высчитывающих хэш-суммы.
Еще смущает модульность технологий — технология кэширования отдельно и технология безопасности отдельно, т.е. недостаточно настроить только одну службу Branchcashe, а надо дополнительно поднимать службы безопасности. И это коробочное проприетарное решение.
Такая разорванность с виду связанных технологий характерна для Microsoft. Возможно это связано в слабом горизонтальном взаимодействие департаментов в большой корпорации.
Еще смущает модульность технологий — технология кэширования отдельно и технология безопасности отдельно, т.е. недостаточно настроить только одну службу Branchcashe, а надо дополнительно поднимать службы безопасности. И это коробочное проприетарное решение.
Такая разорванность с виду связанных технологий характерна для Microsoft. Возможно это связано в слабом горизонтальном взаимодействие департаментов в большой корпорации.
Это ни в коем случае не значит, что я думаю, что данная технология не найдет широкое применение в enterprise.
Мне, честно говоря, логика самого решения не кажется странной. Данные в BrancheCache всегда актуальны. Это — принципиальный момент. Отсюда вытекает логика работы, а за ней и сфера применения. Понимая логику работы и зная специфику своих данных, Вы решаете насколько в Вашей конкретной ситуации (для конкретных серверов и даже шар) будет эффективен этот механизм.
Что касается безопасности — достаточно настроить только BranchCache. Он гарантирует безопасное общение с «соседями». Но если нужно дополнительно закрутить безопасность, то Вы включаете дополнительные службы. Ведь речь идет об обыкновенных файлах, с которыми работает пользователь, а не о каких-то особенных конфиденциальных документах. Есть смысл по умолчанию шифровать кэш, если, скачав файл, пользователь сохраняет его в незашифрованной папке «Мои документы»?
Что касается безопасности — достаточно настроить только BranchCache. Он гарантирует безопасное общение с «соседями». Но если нужно дополнительно закрутить безопасность, то Вы включаете дополнительные службы. Ведь речь идет об обыкновенных файлах, с которыми работает пользователь, а не о каких-то особенных конфиденциальных документах. Есть смысл по умолчанию шифровать кэш, если, скачав файл, пользователь сохраняет его в незашифрованной папке «Мои документы»?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
BranchCache в Windows 7