Comments 39
Детектив это всегда интересно, а IT детектив в тройне — так что, да ждем от вас расследования.
Для затравки.
Вот два компьютера. Один на Win7, другой на WinXP, они одинаковые за исключением ОС, оба работают через оптимизаторы. Первый в полном порядке. У второго проблема: Excel не может создавать новые файлы в некоторых (не во всех) DFS шарах, начинающихся на "\\company.ru\", а Word и штатный проводник могут, а Wireshark не может (из того, что выявлено). Если путь "\\company\", то проблемы нет, как и если обращаться напрямую на файловый сервер. Воспроизводится это в 100% случаев, проблема ни разу не плавающая. Ни один другой заказчик ни с чем подобным не сталкивался, разумеется.
True story. Нечто подобное обязательно хоть где-то вылезает на начальных этапах тестирования оптимизаторов, уж больно глубоко они лезут на уровень приложения.
Вот два компьютера. Один на Win7, другой на WinXP, они одинаковые за исключением ОС, оба работают через оптимизаторы. Первый в полном порядке. У второго проблема: Excel не может создавать новые файлы в некоторых (не во всех) DFS шарах, начинающихся на "\\company.ru\", а Word и штатный проводник могут, а Wireshark не может (из того, что выявлено). Если путь "\\company\", то проблемы нет, как и если обращаться напрямую на файловый сервер. Воспроизводится это в 100% случаев, проблема ни разу не плавающая. Ни один другой заказчик ни с чем подобным не сталкивался, разумеется.
True story. Нечто подобное обязательно хоть где-то вылезает на начальных этапах тестирования оптимизаторов, уж больно глубоко они лезут на уровень приложения.
имхо, решения интересны для узких каналов связи. например, если удаленный офис висит на какой-нибудь йоте или еще хуже 3G-модеме. но опять же это только мое имхо. да и цены, подозреваю, очень кусачие… и стоит ли овчинка выделки.
Стоит. Срок окупаемости решений варьируется от 6 до 24 месяцев. В зависимости от того какие статьи доходности используются при расчете обоснования. Кроме того для маленьких каналов используется советующие достаточно маломощные модели оборудования, никто из пушки по воробьям не стреляет. И, наоборот, для репликации данных между ЦОДами на разных концах нашей страны или мира, надо использовать уже высокопроизводительное оборудование.
Я конечно не коммерсант и мне трудно судить о ценообразовании. Но на вскидку мне кажется что легче и надежней увеличить пропускную способность канала на размер стоимости данного решения.
Соглашусь с shamanis. К примеру у нас есть удаленный объект где находится 1 компьютер. Он завязан на 1С. Там только 3G И вот тут бы могло помочь это решение. Но даже минимальная цена в 100 тыс. заставляет задуматься.
Потому что на эту сумму можно своими силами уложить оптический кабель до ближайшего провайдера. Хотя повторюсь, я не коммерсант и могу сильно ошибаться в ценах.
Соглашусь с shamanis. К примеру у нас есть удаленный объект где находится 1 компьютер. Он завязан на 1С. Там только 3G И вот тут бы могло помочь это решение. Но даже минимальная цена в 100 тыс. заставляет задуматься.
Потому что на эту сумму можно своими силами уложить оптический кабель до ближайшего провайдера. Хотя повторюсь, я не коммерсант и могу сильно ошибаться в ценах.
Отчасти вы правы, но давайте фантазировать. Для вашего примера – один удалённый офис с одним компьютером – нет смысла разворачивать такое решение. Я согласен.
Если у вас офисов больше чем один, и все они маленькие (с 1 компьютером), то для этого решения мы предложим поставить в центр аппаратное решение, а для филиалов софтверный клиент устанавливаемый прямо на рабочее место. Это решение гораздо дешевле. И в тоже время позволит поднять эффективность работы приложений и пользователя.
Если же у вас в офисе количество сотрудников приближается к 10 на точку – то в этом случае мы уже рекомендуем использовать минимальную аппаратную модель оптимизатора.
Все познается в сравнении, возможно за 100 тысяч можно проложить оптику до ближайшего провайдера, но наверно это справедливо в городских условиях с высокой степенью проникновения провайдеров. А что делать производствам? Или тяжело доступным местам нахождения бизнеса?
Кстати отличный пример – почти все глобальные корпорации, которые приходят в Россию, используют это оборудование для связи со своей штаб-квартирой или ЦОДом в Европе или Америке. Хотя не такая уж большая задержка между Москвой и Европой например.
Если у вас офисов больше чем один, и все они маленькие (с 1 компьютером), то для этого решения мы предложим поставить в центр аппаратное решение, а для филиалов софтверный клиент устанавливаемый прямо на рабочее место. Это решение гораздо дешевле. И в тоже время позволит поднять эффективность работы приложений и пользователя.
Если же у вас в офисе количество сотрудников приближается к 10 на точку – то в этом случае мы уже рекомендуем использовать минимальную аппаратную модель оптимизатора.
Все познается в сравнении, возможно за 100 тысяч можно проложить оптику до ближайшего провайдера, но наверно это справедливо в городских условиях с высокой степенью проникновения провайдеров. А что делать производствам? Или тяжело доступным местам нахождения бизнеса?
Кстати отличный пример – почти все глобальные корпорации, которые приходят в Россию, используют это оборудование для связи со своей штаб-квартирой или ЦОДом в Европе или Америке. Хотя не такая уж большая задержка между Москвой и Европой например.
Лучше купить оптимизатор чем кормить зажравшегося провайдера, цены у которого не менялись последние несколько лет. Даёшь оптимизацию!
Оптимизатор, да с двух концов, да совокупность аппаратных и софтверных решений в кубе тонких настроек = + 2 точки отказа в кубе.
+ затраты на инсталляцию и пуско-наладку
+ затраты на поддержку
+ затраты на более квалифицированный ИТ персонал
+ большее время старта филиала
+ затрудненный дебаг сетевых проблем
+ через месяц выяснится, что ключевой модуль ERP который коряво написано и не переписать через улучшайзер откажется работать
По мне лучше покормить провайдера, чтобы он расширял свою магистральную сеть и закупал более мощное оборудование.
+ затраты на инсталляцию и пуско-наладку
+ затраты на поддержку
+ затраты на более квалифицированный ИТ персонал
+ большее время старта филиала
+ затрудненный дебаг сетевых проблем
+ через месяц выяснится, что ключевой модуль ERP который коряво написано и не переписать через улучшайзер откажется работать
По мне лучше покормить провайдера, чтобы он расширял свою магистральную сеть и закупал более мощное оборудование.
+ затраты на инсталляцию и пуско-наладку
Никаких затрат там нет. За исключением первоначального пилота, когда надо понять, как оно работает. Дальше инсталляция новой железки — развлечений на полчаса включая первоначальные настройку и обновление.
+ затраты на поддержку
WAAS — «включил и работает». Можно иногда посматривать на красивые графики. Иногда менять вышедшее из строя железо.
+ затраты на более квалифицированный ИТ персонал
По сравнению с чем более квалифицированный?
+ большее время старта филиала
См. п.1.
+ затрудненный дебаг сетевых проблем
Дебаг простой — взять и отключить акселерацию для конкретного юзера.
+ через месяц выяснится, что ключевой модуль ERP который коряво написано и не переписать через улучшайзер откажется работать
Добавить в исключения.
Я, на самом деле, первоначально ожидал увидеть множество подобных проблем, но пока ничего такого не выявлено. Да и выяснится такое в первые же часы пилота.
Реальная ситуация. Был корпоратив. Выложили сотни мегабайт фотографий на центральные файловые шары, разнесли весть по регионам. Регионы начали качать. Каналы загружены под 100%. QoS бессилен — этот трафик ничем не отличается от прочего файлового трафика, они толкаются друг с другом.
С акселераторами куда приятнее — они всё закешируют, каналы будут отдыхать.
Немного лукавые ответы, обозначенные мной проблемы в большей степени ни куда не делись, просто либо их никто не считал в денежном эквиваленте, либо не напарывались пока.
А про фото с корпоративов- напарываемся каждый раз, надо что-то уже придумать, DFS репликацию к примеру предварительную, до публикации ссылки на ресурс — т.е. проблему можно решить по разному.
А про фото с корпоративов- напарываемся каждый раз, надо что-то уже придумать, DFS репликацию к примеру предварительную, до публикации ссылки на ресурс — т.е. проблему можно решить по разному.
просто либо их никто не считал в денежном эквиваленте, либо не напарывались пока.
Ну допустим метрика — затраты времени у инженеров. Вот я и говорю, что их как бы и нет после того, как первоначальный пилот завершен. Вот пилот может тянуть время месяцами, пока всё не будет вылизано.
надо что-то уже придумать, DFS репликацию к примеру
Вы правда думаете, что это проще? :)
Да, это проще. Создать группу репликации -5 минут, со всеми атрибутами, с ограничением по полосе и расписанием.
После окончания юзеры будут брать контент с локальных серверов — мгновенно и удобно.
После окончания юзеры будут брать контент с локальных серверов — мгновенно и удобно.
Мне интересно — а вы вживую работали с DFSR? Например, наши винадмины ругаются на него матом и планируют от него уходить. Неподдерживаемых сценариев — море, например, в случае репликации пользовательских профилей: blogs.technet.com/b/askds/archive/2010/09/01/microsoft-s-support-statement-around-replicated-user-profile-data.aspx.
Наши винадмины умеют его готовить, знают его ограничения и не используют по не назначению.
Приведенный пример — выстрел себе в ногу, притянуто.
Приведенный пример — выстрел себе в ногу, притянуто.
Так озвученный вами пример используется на практике?
Да, работает как часы.
Как пример — DFS ресурс в который работники СБ складов локально кладут файлы с охранного видеонаблюдения, а сотрудники СБ офиса с ними работают.
Единственный затык был давно, и то по вине провайдера.
Как пример — DFS ресурс в который работники СБ складов локально кладут файлы с охранного видеонаблюдения, а сотрудники СБ офиса с ними работают.
Единственный затык был давно, и то по вине провайдера.
А до 2012 тоже работало?
Ну поздравляю. Замечу, что к данной архитектуре применяются все указанные вами ранее проблемы, в которых вы вините оптимизаторы :) И виндовый файловый сервер в сопровождении выйдет явно дороже оптимизатора.
Ну поздравляю. Замечу, что к данной архитектуре применяются все указанные вами ранее проблемы, в которых вы вините оптимизаторы :) И виндовый файловый сервер в сопровождении выйдет явно дороже оптимизатора.
Все члены репликации сервера по управлением 2008R2, скриншот снят с другого доменного сервера, который ближе))
Вот не надо, если он уже есть, почему от включения DFS службы он выйдет в сопровождении дороже?
И виндовый файловый сервер в сопровождении выйдет явно дороже оптимизатора.Вот не надо, если он уже есть, почему от включения DFS службы он выйдет в сопровождении дороже?
если он уже есть
А если нет?
Опять же — реплику всех шар на нем не сделать, никаких дисковых ресурсов и каналов не хватит, а за избранными специально следить надо. А оптимизатору по барабану, с чем работать, никаких предварительных настроек не требуется. Оптимизация SMB даже без DRE/LZ жжот напалмом, в первую очередь на XP клиентах, где на каждый чих по 50 обменов запрос-ответ между клиентом и сервером, но и SMB2 выигрывает.
Вас послушать — так прям волосы шелковистые станут сразу.
Разные задачи решаются по разному, а не тупо запихиванием всего в чудо коробки.
У меня есть лютый, жгущий лавой аргумент- БЮДЖЕТ.
И он может корректироваться только если все упало и пропало, и то со скрипом.
Обосновать затраты, в моем случае примерно в 3-5 миллиона рублей за раз, в 90% контор практически не реально.
Разные задачи решаются по разному, а не тупо запихиванием всего в чудо коробки.
У меня есть лютый, жгущий лавой аргумент- БЮДЖЕТ.
И он может корректироваться только если все упало и пропало, и то со скрипом.
Обосновать затраты, в моем случае примерно в 3-5 миллиона рублей за раз, в 90% контор практически не реально.
Разные задачи решаются по разному, а не тупо запихиванием всего в чудо коробки.
Оптимизаторы обычно ставят там, где мухосранским коллегам надо обеспечить качество работы сервиса как можно ближе к сотрудникам, работающим из соседнего с ЦОДом помещения.
Обосновать затраты, в моем случае примерно в 3-5 миллиона рублей за раз, в 90% контор практически не реально.
Конечно. 90% контор даже ISR с трудом могут себе позволить, уж больно он дорогой. Да и не нужны им WAN оптимизаторы, инфраструктура не та.
Расширение канала связи не всегда ведет к повышению скорости работы приложений. У каналов связи, тем более протяженных, такие параметры как «круговая задержка» (или RTT) и потери (пусть даже самые минимальные) гораздо выше чем в локальной сети. Именно это не позволят использовать TCP-приложениям всю доступную полосу пропускания канала связи. Два последних обращения к нам были как раз об этом.
Первый случай. Наземный канал связи Москва — Новосибирск. Сервера располагались в Москве, но затем переехали в Новосибирск. Пользователи в Москве сразу почувствовали деградацию скорости приложений. Причем утилизация каналов не поднималась выше 30%. Потери в канале минимальны. Оптимизаторы успокоили пользователей, они опять работают с «локальной» скоростью.
Второй случай. Оптический канал связи Москва — Хабаровск. Каждое соединение репликации между ЦОД проходит на скоростях менее 700 Кбит/c, а полоса пропускания канала 1 Гбит/c! Вопрос — за что платит организация?! За полосу которая недоступна. С оптимизаторами скорость соединений репликации возросла до 35 Мбит/c. Т.е. в 50 раз! Репликации проходят в 50 раз быстрее.
Первый случай. Наземный канал связи Москва — Новосибирск. Сервера располагались в Москве, но затем переехали в Новосибирск. Пользователи в Москве сразу почувствовали деградацию скорости приложений. Причем утилизация каналов не поднималась выше 30%. Потери в канале минимальны. Оптимизаторы успокоили пользователей, они опять работают с «локальной» скоростью.
Второй случай. Оптический канал связи Москва — Хабаровск. Каждое соединение репликации между ЦОД проходит на скоростях менее 700 Кбит/c, а полоса пропускания канала 1 Гбит/c! Вопрос — за что платит организация?! За полосу которая недоступна. С оптимизаторами скорость соединений репликации возросла до 35 Мбит/c. Т.е. в 50 раз! Репликации проходят в 50 раз быстрее.
Репликация — это самый простой случай. Достаточно включить window size scaling и поставить буфера пошире. Кто-то выжимал и 10G одним потоком с RTT 200мс. Если вы не упомянули об этом клиенту, но впарили ему недешевые оптимизаторы под эту задачу — ну что же, поздравляю, и попутно узнаю Кроковский подход.
Реально оптимизаторы нужны в двух сценариях:
1) Дедупликация и сжатие
2) Болтливое приложение, и оптимизатор может спуфить общение, сокращая количество обменов.
Реально оптимизаторы нужны в двух сценариях:
1) Дедупликация и сжатие
2) Болтливое приложение, и оптимизатор может спуфить общение, сокращая количество обменов.
Действительно, репликация – это один из самых показательных случаев. Действительно, за счет подкрутки TCP на серверах можно добиться лучшей утилизации канала. Если репликация происходит между несколькими серверами придется настраивать каждый сервер. Ставя оптимизаторы, вы настраиваете все на одной железке. Также нужно настроить QoS таким образом, чтобы репликации не вытесняли другой трафик. В случае использования оптимизаторов конкуренция за полосу будет равной для всего трафика, но можно настроить полнофункциональный QoS на riverbed.
Судя по RTT в 200 мс, рассматриваемый канал достаточно протяженный (не собственность организации), а полоса пропускания огромная. Наверняка, аренда у него немаленькая. Трафик репликации жмется очень сильно. Если происходит полный backup то со второй прокачки к-т сжатия будет порядка 90%. Это означает, что можно арендовать уже не 10Gbps, а 1 Gpbs. Какая экономия за год? За три года? Плюс к этому на оптимизаторах можно настроить QoS по времени. Например, днем – репликации занимают 10%, ночью – 90%.
Репликация и/или уменьшения загрузки каналов связи — хорошее применение, но основная задача оптимизаторов – это ускорение работы сетевых приложений, эффект который заметен пользователям и непосредственно влияет на их эффективность. Ускорение сетевых приложений главным образом происходит за счет адаптации TCP под канал связи и проксирования ряда основных протоколов. При этом, как правильно замечено, устраняется болтливость приложений.
Так что если решать вопрос «заплатками» — да, можно в каждом отдельно взятом случае обойтись без них, но если говорить об обслуживании организации в целом в стабильной негомогенной среде приложений — они очень и очень востребованы на практике.
Судя по RTT в 200 мс, рассматриваемый канал достаточно протяженный (не собственность организации), а полоса пропускания огромная. Наверняка, аренда у него немаленькая. Трафик репликации жмется очень сильно. Если происходит полный backup то со второй прокачки к-т сжатия будет порядка 90%. Это означает, что можно арендовать уже не 10Gbps, а 1 Gpbs. Какая экономия за год? За три года? Плюс к этому на оптимизаторах можно настроить QoS по времени. Например, днем – репликации занимают 10%, ночью – 90%.
Репликация и/или уменьшения загрузки каналов связи — хорошее применение, но основная задача оптимизаторов – это ускорение работы сетевых приложений, эффект который заметен пользователям и непосредственно влияет на их эффективность. Ускорение сетевых приложений главным образом происходит за счет адаптации TCP под канал связи и проксирования ряда основных протоколов. При этом, как правильно замечено, устраняется болтливость приложений.
Так что если решать вопрос «заплатками» — да, можно в каждом отдельно взятом случае обойтись без них, но если говорить об обслуживании организации в целом в стабильной негомогенной среде приложений — они очень и очень востребованы на практике.
Если репликация происходит между несколькими серверами придется настраивать каждый сервер.
Но это в любом случае лучше делать. Дефолтные настройки не годятся для LFN.
В случае использования оптимизаторов конкуренция за полосу будет равной для всего трафика, но можно настроить полнофункциональный QoS на riverbed.
У вас что, применяется туннелирование? Обалдеть. Лишний плюс в копилку WAAS, который не меняет заголовки L3-L4, трогая только содержимое, и лишний повод назвать Riverbed УГ.
Действительно, за счет подкрутки TCP на серверах можно добиться лучшей утилизации канала
…
Трафик репликации жмется очень сильно.
А клиенты были в курсе первой опции? Ценник-то явно был шестизначный.
Плюс к этому на оптимизаторах можно настроить QoS по времени. Например, днем – репликации занимают 10%, ночью – 90%.
А можно прямо на роутерах настроить полноценный QoS — когда трафик репликации занимает всю ширину канала всегда, но только пока он не мешает другому трафику. Полноценный QoS невозможен, когда не 100% трафика проходит через устройство, реализующее приоритезацию.
Так что если решать вопрос «заплатками» — да, можно в каждом отдельно взятом случае обойтись без них
Если use-case той компании из примера ограничивался озвученным вами, то оптимизаторы явно не нужны.
они очень и очень востребованы на практике.
Мне об этом рассказывать не надо, вот только пользуюсь я WAAS'ами. Читаю написанное про риветбеды и хватаюсь за голову.
Главное преимущество WAAS в интеграции с продуктами Cisco. Понимаю вашу точку зрения — с учётом, что у вас написано в профиле про Cisco — но все же давайте обратимся к фактам. Факты таковы, что в сегменте WOC (Wan Optimization Controllers) Riverbed уже три года подряд занимает более 50% рынка. В 2013 году Riverbed остался единственным лидером сегмента по Gartner. Gartner не делает такие смелые заключения просто так. Это всегда очень серьезные исследования, которым очень и очень доверяют на рынке. Учитывая, то что Riverbed — нишевой игрок, и его возможности ограничены по сравнению с более крупными производителями, то получить больше половины рынка они смогли только за счет большей эффективности оптимизации и более широкого функционала, чем у конкурентов. Проще говоря, их решение банально лучше для большинства покупателей. По практике в России отмечу, что Riverbed очень и очень хорошо себя показал. Я не предлагаю ставить только его — мы интегрируем и решения Cisco, и других вендоров — но при полном расчёте кейса ситуация в РФ не отличается от мировой, описанной Gartner.
Вот, продолжаю узнавать КРОК. Сейчас вы, будучи на ITшном ресурсе и беседуя с инженером, занимаетесь натуральной демагогией, прием «отсылка к авторитету», вместо технического обсуждения. Собственно, именно по этой причине я очень не люблю общаться с продажниками. Один продажник из F5 например убеждал меня, что их решение, поддерживающее лишь базовые TFO/DRE/LZ и не знающее ни одного приложения, круче всех. Я даже восхитился тем, как человек может с такой уверенностью нести такую ахинею, зная, что это ахинея. Главный его аргумент, цитирую, «я уверен, что наше решение лучше»…
Если хотите устроить обмен маркетинговыми глупостями, то не вопрос — www.cisco.com/c/dam/en/us/products/collateral/application-networking-services/application-content-networking-system-acns-software/brand_leader_report.pdf
А этого мало, учитывая примерно паритет по остальным пунктам и безусловное лидерство Cisco на сетевом транспорте?
Это имеет какое-то значение? Вот вы лично умеете думать своей головой, покупая себе какой-то товар, или ориентируетесь исключительно на обзоры, причем только те, которые восхваляют одну конкретную модель товара?
Это утверждение говорит о том, что вы не имеете ни малейшего представления об устройстве Cisco как компании.
Cisco — это много разных BU. Очень разных, занимающихся совершенно разными продуктами. Принято говорить, что это — компании внутри компании, весьма независимые. Один BU много лет подряд сильно фейлил. У другого были еще большие проблемы — смотрите бездарно проваленный рынок балансировщиков. Ну и?
Причины куда проще. Во-первых, Riverbed просто начал раньше. Во-вторых, Cisco очень долго тормозила с WAAS. Лет 5 назад эта штука была совершенно никудышной, и даже TAC понятия не имел, как с ней работать. Времена меняются, за последние пару лет WAAS весьма преобразился, развитие ускорилось. Потому как-то странно отбрасывать объективные технические факторы и зацикливаться на субъективных понятиях вроде доли рынка, которые, повторюсь, у них почти одинаковые. WAAS только недавно достиг половой зрелости, только недавно научился делать Encrypted MAPI, и наконец вроде не имеет никаких дыр в функционале, позволяющих признать его ущербным.
Бывают разные нетехнические причины, по которым интегратор может пытаться впарить клиенту даже объективно менее подходящее ему оборудование вместо более подходящего. Но не будем об этом.
Если уж вы утверждаете, что Riverbed лучше — приведите аргументы. Вот например тем несчастным, кто пользуются Lotus Notes (знаем, плавали), с WAAS не по пути. Чем не технический аргумент? А там можно плавно перейти и к другим моментам вроде недо-QoS на рекламируемом вами железе вместо полноценной реализации, возможность превратить в акселераторы уже имеющееся железо с мощными и почти простаивающими процессорами и так далее :) Даже если бы у продукции Riverbed было заметное превосходство в собственно качестве оптимизации, разные сторонние и не очень моменты могли бы это перевесить.
Если хотите устроить обмен маркетинговыми глупостями, то не вопрос — www.cisco.com/c/dam/en/us/products/collateral/application-networking-services/application-content-networking-system-acns-software/brand_leader_report.pdf
Главное преимущество WAAS в интеграции с продуктами Cisco.
А этого мало, учитывая примерно паритет по остальным пунктам и безусловное лидерство Cisco на сетевом транспорте?
Факты таковы, что в сегменте WOC (Wan Optimization Controllers) Riverbed уже три года подряд занимает более 50% рынка.
Это имеет какое-то значение? Вот вы лично умеете думать своей головой, покупая себе какой-то товар, или ориентируетесь исключительно на обзоры, причем только те, которые восхваляют одну конкретную модель товара?
Учитывая, то что Riverbed — нишевой игрок, и его возможности ограничены по сравнению с более крупными производителями
Это утверждение говорит о том, что вы не имеете ни малейшего представления об устройстве Cisco как компании.
Cisco — это много разных BU. Очень разных, занимающихся совершенно разными продуктами. Принято говорить, что это — компании внутри компании, весьма независимые. Один BU много лет подряд сильно фейлил. У другого были еще большие проблемы — смотрите бездарно проваленный рынок балансировщиков. Ну и?
получить больше половины рынка они смогли только за счет большей эффективности оптимизации и более широкого функционала, чем у конкурентов. Проще говоря, их решение банально лучше для большинства покупателей.
Причины куда проще. Во-первых, Riverbed просто начал раньше. Во-вторых, Cisco очень долго тормозила с WAAS. Лет 5 назад эта штука была совершенно никудышной, и даже TAC понятия не имел, как с ней работать. Времена меняются, за последние пару лет WAAS весьма преобразился, развитие ускорилось. Потому как-то странно отбрасывать объективные технические факторы и зацикливаться на субъективных понятиях вроде доли рынка, которые, повторюсь, у них почти одинаковые. WAAS только недавно достиг половой зрелости, только недавно научился делать Encrypted MAPI, и наконец вроде не имеет никаких дыр в функционале, позволяющих признать его ущербным.
По практике в России отмечу, что Riverbed очень и очень хорошо себя показал. Я не предлагаю ставить только его
Бывают разные нетехнические причины, по которым интегратор может пытаться впарить клиенту даже объективно менее подходящее ему оборудование вместо более подходящего. Но не будем об этом.
Если уж вы утверждаете, что Riverbed лучше — приведите аргументы. Вот например тем несчастным, кто пользуются Lotus Notes (знаем, плавали), с WAAS не по пути. Чем не технический аргумент? А там можно плавно перейти и к другим моментам вроде недо-QoS на рекламируемом вами железе вместо полноценной реализации, возможность превратить в акселераторы уже имеющееся железо с мощными и почти простаивающими процессорами и так далее :) Даже если бы у продукции Riverbed было заметное превосходство в собственно качестве оптимизации, разные сторонние и не очень моменты могли бы это перевесить.
Со многим согласен, но Lotus Notes просто надо уметь готовить. Однажды у меня некоторое время 300 человек сидели на радио-канале 1-1,5 мб/с, но размещение почтовых ящиков на локальном сервере значительно снизило накал страстей. Не говоря уже про удобство пользования разнообразными базами, справочниками, документооборотом, живущем поверх Лотуса и т.д.
Самый простой и надежный способ — «в разрыв» между граничным маршрутизатором и коммутатором ЛВС.
Нет, даже с механическим bypass. Правильнее всего PBR или WCCP, чтобы оптимизатор был в стороне от основного пути трафика.
Если оптимизатор выходит из строя, он замыкает контакты интерфейсов LAN и WAN — и трафик просто проходит через него, как через обычный кросс-кабель. Соответственно, видя неоптимизированный трафик, оптимизатор на той стороне также просто пропускает его через себя без обработки.
Тут есть небольшое лукавство.
Если оптимизатор умер в процессе работы TCP сессии, то она неизбежно должна быть разорвана, и уже новая сессия будет неоптимизированной. Надо смотреть по самому приложению, насколько критичен разрыв.
Оранжевая «пила» на графике – стандартное поведение TCP
Если сессия одна. Когда их сотни, они суммарно более-менее равномерно займут полосу.
Тут надо рассказать об основном конкуренте (Cisco WAAS). У них примерно одинаковые доли рынка, подозреваю, что эффективность работы в среднем та же. Говорю по опыту боевого внедрения WAAS.
Главное преимущество WAAS — то, как он встраивается в сеть. Основные варианты:
1) WCCP или PBR
2) Inline (тоже механический fail-to-wire, выдернуть питание — после сброса всех сессий связь восстановится). Не наш метод, уж больно очковато…
3) AppNav на ASR1k или CSR — вот это интересная штука. Допустим, региональные каналы собираются на ASR'ах (типичная ситуация). Может быть DMVPN, может быть что угодно другое, не важно, лишь бы это «что-то» опиралось на отдельные интерфейсы. С помощью короткого визарда в гуе (звучит мерзко, но на практике работает хорошо) включается акселерация на отдельно выбранных WAN интерфейсах. Каждый из ASRов запоминает все TCP соединения через эти интерфейсы и делится этой информацией с другими ASRами (тоже звучит мерзко, но ASRам не занимать процессорной мощи и памяти, влияния от этого дела нет). Каждое соединение назначается на определенный акселератор (редирект по GRE), и все ASRы в кластере знают, на какой. Соответственно, имеем поддержку любых топологий с любой асимметрией, с перестроением топологии в любую сторону по ходу передачи данных; можем без влияния на сервис вводить и выводить из эксплуатации акселераторы, и никаких отдельных железок на пути трафика ставить не надо вообще, только в стороне от него.
Работает AppNav стабильно, я нашел лишь один критический баг (условия воспроизведения такие, что не думаю, что кто-то кроме меня его находил или найдет). Из недостатков — документации по нему нет. Вообще нет. Ни в каком виде. Даже у TAC. То, что вам удастся нагуглить, это не документация, а недоразумение какое-то на уровне «протереть стекла и попинать колесо в случае проблем». Но опять же, маркетологи обещают «it simply works», и, пожалуй, не врут.
Далее — есть WAAS Express. У кого региональная сеть на ISR G2 — нужно докупить памяти до максимального объема, можно докупить лицензию для WAAS (магическое слово RTU), и включается акселерация с базовыми фичами вроде сжатия, дедуплицации, SMB (со временем будет больше). И снова никакого отдельного железа ставить не надо. По ту сторону канала нужен «взрослый» акселератор, перенаправлять трафик можно тем же AppNav, итого — для покрытия оптимизацией региональной сети на сотни офисов надо из железа покупать только пару больших акселераторов в центр и несколько килограмм оперативки, не меняя физическую топологию и не вклинивая в сеть чужеродное железо.
Сам WAAS тоже работает надежно, всего пара критических багов (для одного найден рабочий WA, для другого ищем, но снова тут довольно специфическая ситуация, мало у кого эти проблемы воспроизведутся).
Трафик, который покинул хост в расшифрованном виде, можно считать публичным. Сколько бы его не заворачивали в vpn аппаратные NSA/ФАПСИ-одобренные бэкдоры VPN-шлюзы.
Трафик, который покинул хост в расшифрованном виде, можно считать публичным.
Не все так просто.
Расскажу про WAAS. Там тоже есть шифрованные SSL и EMAPI. Если у Riverbed что-то реализовано не теми же механизмами, то официально объявляю их оптимизаторы унылым говном.
1) SSL: на ближайший к серверу акселератор загружается приватная часть сертификата, он делает MITM. Соседу-акселератору по ту сторону канала передается только сессионный ключ, тоже в защищенном виде.
2) EMAPI: ближайший к серверу акселератор видит начало обмена, обращается к контроллеру домена и получает токен кербероса для данной сессии (предварительно заводится машинная учетка с соответствующими привилегиями). Далее снова передача ключа (или токена?), MITM.
В расшифрованном виде трафик бывает только внутри акселератора, на входе/выходе он защищен. Сессионные ключи на диск не пишутся. То, что есть на диске из кеша, можно шифровать (при включении железки потребуется вводить пароль).
В общем, параноик внутри меня довольно спокоен.
Акселератор с закрытым исходным кодом, неизвестным количеством goto fail/goto cleanup в устаревших SSL-библиотеках, комплект бэкдоров и т.д.
Не верю. Приватный трафик с хоста должен выходить зашифрованным. В идеале — раздельно для сетевой инфраструктуры (openvpn/ipsec), раздельно на уровне приложения (ssl/ssh). Особо важные данные (письма, коммиты в исходный текст, обновления ПО) должны иметь отдельную криптографическую подпись (gpg).
То есть можно сколько угодно убеждать, что выпустить трафик с хоста в нешифрованном виде это безопасно и best practice, но я по-прежнему прижимаю свой кошелёк плотно к груди, не смотря на уговоры.
Не верю. Приватный трафик с хоста должен выходить зашифрованным. В идеале — раздельно для сетевой инфраструктуры (openvpn/ipsec), раздельно на уровне приложения (ssl/ssh). Особо важные данные (письма, коммиты в исходный текст, обновления ПО) должны иметь отдельную криптографическую подпись (gpg).
То есть можно сколько угодно убеждать, что выпустить трафик с хоста в нешифрованном виде это безопасно и best practice, но я по-прежнему прижимаю свой кошелёк плотно к груди, не смотря на уговоры.
Акселератор с закрытым исходным кодом, неизвестным количеством goto fail/goto cleanup в устаревших SSL-библиотеках, комплект бэкдоров и т.д.
Ну а что поделать?
Есть еще балансировщики (которым тоже пригождаются сертификаты), и виндовые сервера… Если не доверять вендору, то придется многим жертвовать.
Приватный трафик с хоста должен выходить зашифрованным.
Так именно так он и выходит. Балансировщик имеет возможность спуфить сессию, но по всем патч-кордам трафик передается в защищенном виде.
Вариантов-то нет. Если балансировщику не дать возможность спуфить обмен, то будет базовая TCP оптимизация и не более того. Ваш выбор. Я вот вижу, что почтовый трафик на первом месте по оптимизации, 70-80% выигрыша только по объему трафика.
Работаю в крупной международной компании в которой 60 производственных площадок по всму миру. Арендуем инфраструктуру одного из международных провайдеров под собственную MPLS Сеть.
Для представления о целесообразности предлагаемого автором решения приведу несколько фактов:
Сайт — это производственная площадка / склады / офисы с персоналом 150-250 сотрудников.
Критичные сайты имеют два канал связи (резервный обычно уже в половину)
Удаленные офисы подключены 1-2 Мбит/сек каналами
На всех удаленных сайтах с численностью сотрдников более 20 чел. используются WAAS акселераторы.
Стоимость WAAS решения в самом простом исполнении около 400 EUR, а в основном мы используем SM-SRE-710-K9 (4GB RAM, 500GB 7K HDD, 1CPU) = 1000 EUR + 3000 EUR License
Аренда 2МБит/с канала (типовое подключение сайта) обходится около 4000 EUR / месяц
Для представления о целесообразности предлагаемого автором решения приведу несколько фактов:
Сайт — это производственная площадка / склады / офисы с персоналом 150-250 сотрудников.
Критичные сайты имеют два канал связи (резервный обычно уже в половину)
Удаленные офисы подключены 1-2 Мбит/сек каналами
На всех удаленных сайтах с численностью сотрдников более 20 чел. используются WAAS акселераторы.
Стоимость WAAS решения в самом простом исполнении около 400 EUR, а в основном мы используем SM-SRE-710-K9 (4GB RAM, 500GB 7K HDD, 1CPU) = 1000 EUR + 3000 EUR License
Аренда 2МБит/с канала (типовое подключение сайта) обходится около 4000 EUR / месяц
Sign up to leave a comment.
Как делается оптимизация трафика