Как делается оптимизация трафика

  • Tutorial

«КПД» стандартного WAN – всего около 10%

Если заглянуть в практически любой канал связи между филиалом компании и дата-центром, то можно увидеть достаточно неоптимальную картину:
  • Во-первых, передается очень много (до 60–70% канала) избыточной информации, которая так или иначе уже запрашивалась.
  • Во-вторых, канал загружен «болтливыми» приложениями, рассчитанными на работу в локальной сети, — они обмениваются короткими сообщениями, что негативно сказывается на их производительности в канале связи.
  • В-третьих, сам протокол TCP изначально создавался для локальных сетей и отлично подходит для малых задержек RTT и при отсутствии потерь пакетов в сети. В реальных каналах при потерях пакетов скорость сильно деградирует и медленно восстанавливается за счет больших RTT.

Я работаю руководителем инженерной команды департамента телекоммуникаций КРОК и регулярно оптимизирую каналы связи дата-центров как наших, так и энергетических компаний, банков и других организаций. Ниже расскажу основы и приведу наиболее интересное, на мой взгляд, решение.

Сжатие и дедупликация


Первая проблема уже описана: в канале передается очень много избыточных дублирующихся данных. Самый яркий пример — это Citrix-ферма, в которой работают филиалы какого-нибудь банка: в отдельно взятом офисе одни и те же данные могут запрашивать 20–30 разных машин. Соответственно, канал можно было бы спокойно разгрузить на 60–70% за счет дедупликации.

На самом Citrix, конечно, можно включить сжатие данных, но эффективность (сжатие) в разы ниже, чем на специализированных оптимизаторах трафика. Главным образом за счет того, что оптимизаторы не только сжимают данные, но и дедуплицируют. Через оптимизатор проходит трафик всего филиала. И чем больше пользователей в филиале, тем больше повторяющихся запросов пользователей и тем больше эффект от дедупликации. Для одного пользователя стандартное сжатие, например Limpel-Ziv, может быть даже выше, чем дедупликация, но при наличии большего количества устройств на первое место выйдет именно дедупликация.

Как правило, оптимизаторы — это ПАК, но можно внедрить и в виде виртуальных машин. Для оптимизации трафика на канале связи оптимизаторы должны быть установлены на обеих площадках. Оптимизаторы ставятся до VPN-шлюзов, поскольку дедупликация шифрованного трафика — дело бесполезное.

Алгоритм работы дедупликации следующий:
  1. Филиал делает запрос в ЦОД;
  2. Сервер отправляет данные в офис;
  3. До того, как попасть в канал связи, данные проходят через оптимизатор на стороне ЦОДа;
  4. Оптимизатор сегментирует данные и дедуплицирует их. Данные разбиваются на блоки, каждый из которых получает короткое название — ссылка на блок;


  5. Ссылки и блоки данных сохраняются в локальном хранилище — так называемом словаре;
  6. Ссылки и блоки данных передаются на оптимизатор в филиале. Но перед отправкой оптимизатор ЦОДа сжимает данные по алгоритму. В итоге данных не становится больше даже при первой (холодной) передаче данных;
  7. Оптимизатор филиала восстанавливает сжатые по алгоритму данные, полученные из ЦОДа, строит свой локальный симметричный словарь соответствий (блок данных — ссылка), убирает из данных ссылки и отправляет исходные данные клиенту;
  8. Теперь любые данные, проходящие через оптимизаторы филиала или ЦОДа, будут проверяться на наличие дуплицированных данных. Если будет обнаружено соответствие с блоком, находящимся в словаре, то этот блок сырых данных будет заменен короткой ссылкой. Известный (уже переданный) блок не передается.


Остается добавить, что словарь постоянно обновляется и, благодаря специальному алгоритму, в словаре остаются самые востребованные блоки данных.

Мы видим принципиальное отличие от традиционных кеширующих устройств. Кеширующие устройства работают на уровне файлов. Если файл претерпел какие-либо, пусть даже незначительные, изменения, то он должен быть передан заново. Оптимизаторы работают на уровне блоков данных, и при изменении ранее переданного файла в канал связи отправятся только изменения, а остальное будет заменено ссылками.

Еще одна проблема заключается в том, что скорость TCP ограничена размером окна (TCP Windows Size). Размер окна — объем данных, передаваемых отправителем до получения подтверждения от получателя. При этом для передачи уплотненного трафика требуется меньше раз передавать TCP Windows Size, что ведет к увеличению скорости передачи.

Итак, еще раз, это работает так:
  • Устройство А дедуплицирует трафик.
  • Устройство Б собирает «полную картину» из своего локального хранилища.
  • Оба этих устройства работают симметрично.
  • Оба этих устройства никак не влияют на инфраструктуру и конфигурирование всего того, что лежит за ними, то есть просто включаются в разрыв канала, например, на выходе из дата-центра и входе в региональный офис компании.
  • Устройства никак не ограничивают связь с узлами, где таких устройств нет.


Дедупликация для шифрованных каналов


Шифрованный канал явно хуже подходит для сжатия и дедупликации, то есть практической пользы от работы с уже шифрованным трафиком почти нет. Поэтому оптимизаторы включаются в разрыв до устройства шифрования: ЦОД отдает данные оптимизатору, оптимизатор отдает на шифровку (например, в защищенный VPN-канал), на той стороне трафик расшифровывается и отдается оптимизатору на месте, а тот уже отдает их в сеть. Это штатная функция «коробочек-оптимизаторов», и все это происходит без снижения рисков компрометации трафика.

Дедупликация для мобильных сотрудников


В последние годы достаточно часто с ЦОДами напрямую работают люди с ноутбуками и планшетами, которым тоже нужно достаточно много данных (те же образы виртуальных машин или выборки из БД). Для них используются не «коробочки-оптимизаторы», а специальный софт, который просто расходует часть ресурсов процессора и часть жесткого диска для тех же целей. По факту мы меняем некоторое снижение производительности ноутбука и место в кеше на жестком диске на более быстрый канал. Пользователи обычно не замечают ничего, кроме ускорения работы сетевых сервисов.

Кто делает эти оптимизаторы?


Мы используем решения компании Riverbed. Эта компания была основана в 2002 году, а в 2004 году представила свою первую модель оптимизаторов для каналов связи. Продукты и решения Riverbed, включая оптимизацию WAN-сетей, управление производительностью, доставку приложений и ускорение работы хранилищ данных, дают возможность ИТ-специалистам увеличивать производительность и управлять ею. Оптимизаторы очень просто интегрировать в сеть. Самый простой способ — установка «в разрыв» со стороны LAN до маршрутизатора или VPN-шлюза.


Конкурентные решения. Компания Riverbed в 2013 году заняла 50% рынка сегмента WAN-оптимизации.

С точки зрения коммерческого директора заказчика, это несколько коробок, которые после простого включения в сеть ускоряют медленные каналы в 2–3 раза и снижают загрузку каналов от 2 раз. За это их любят почти все!

Подключение оптимизатора


Самый простой и надежный способ — «в разрыв» между граничным маршрутизатором и коммутатором ЛВС. Если оптимизатор выходит из строя, он замыкает контакты интерфейсов LAN и WAN — и трафик просто проходит через него, как через обычный кросс-кабель. Соответственно, видя неоптимизированный трафик, оптимизатор на той стороне также просто пропускает его через себя без обработки.

Соответственно:
  • Связь филиала с оптимизатором и ЦОДа с оптимизатором – трафик оптимизируется.
  • Связь филиала без оптимизатора и ЦОДа с оптимизатором – оптимизатор ЦОДа просто прозрачно пропускает трафик без изменений.
  • Связь филиала с оптимизатором и ЦОДа с оптимизатором при выходе любого из оптимизаторов из строя – трафик просто не сжимается и ходит «как есть».

Естественно, в ЦОДах оптимизаторы кластеризуются для отказоустойчивости или наращивания мощности плюс снабжаются балансировщиками Interceptor. Но про это чуть ниже, когда дойдем до конкретного оборудования.

Ускорение TCP


Скорость работы TCP ограничена размером окна. Окно — это количество информации, которое сервер может отправить клиенту до получения подтверждения о получения.

Стандартное поведение TCP выглядит так:
  • медленный разгон соединений, размер TCP-окна увеличивается;
  • при потерях пакетов — резкое падение в скорости (уменьшение окна в 2 раза);
  • и снова медленное ее увеличение (увеличение окна);
  • снова потери пакетов и проседание полосы и так далее.



Оранжевая «пила» на графике – стандартное поведение TCP

На каналах связи с большой полосой пропускания, но наличием какого-либо уровня потерь и большими задержками RTT доступная полоса пропускания используется неэффективно, то есть канал никогда не загружается полностью.

В компании Riverbed думали примерно в том же направлении. И поскольку у нас уже есть коробки-оптимизаторы на входе и выходе, то глупо не использовать их для модификации TCP-протокола, чтобы избежать стандартных проблем. Поэтому оптимизаторы умеют не только оптимизировать трафик на уровне данных (дедупликация/сжатие), но и ускорять транспортный уровень.

Вот ряд режимов, доступных для ускорения TCP:
  • режим HighSpeed TCP — здесь скорость достигает максимума куда быстрее, чем при обычной работе с TCP. При потерях он не так низко и не так сильно проседает, как стандартный TCP;
  • режим MaxTCP — использует 100% полосы без замедлений. Пакет теряется — замедление не происходит. Однако этот режим требует настройки правил качества обслуживания QoS для определения ограничений доступной полосы пропускания, которую может занимать MX-TCP трафик;
  • режим SCPS — разработан специально для спутниковых каналов связи. Здесь полосы не ограничиваются, как в MaxTCP. SCPS отлично адаптируется к плавающим характеристикам спутниковых каналов.


Оптимизация приложений


Многие приложения «болтливы», то есть могут отправить до 50 пакетов тогда, когда достаточно одного. Как я уже говорил, это следствие проектирования под локальные сети, а не под работу через каналы «дальней» связи. С использованием оптимизаторов число проходов туда-обратно уменьшается более чем в 50 раз.

Вот как это выглядит:


Оптимизаторы выступают в роли прозрачных прокси на седьмом уровне для ряда самых распространенных прикладных протоколов.

Оптимизатор ЦОДа выступает в роли клиента по отношению к серверу. Оптимизатор филиала выступает в роли сервера по отношению к клиентам. Таким образом, неэффективное, «болтливое» общение приложений остается в локальной сети. Между оптимизаторами обмен сообщениями приложения происходит в более подходящем для каналов связи виде — уменьшается количество сообщений.

Устройства оптимизации Riverbed умеют ускорять на седьмом уровне следующие прикладные протоколы:



Что интересно, тут есть и шифрованные приложения, включая зашифрованный Citrix и MAPI. При оптимизации шифрованного трафика не происходит снижение уровня безопасности.


Примеры ускорения работы приложений. В реальной сети ускорение будет зависеть от канала связи. Чем хуже канал связи, тем больших показателей ускорения можно добиться.

Типовая схема подключения





Оптимизаторы Steelhead ставятся перед каналом передачи данных, но до устройств шифрования. Для ЦОДов с особыми требованиями также используется кластеризация для повышения надежности плюс балансировщики нагрузок Interceptor.

Результат (пример)




Зеленый – WAN-трафик. Синий – LAN-трафик. Без оптимизатора Riverbed они были бы одинаковыми.


Выделенная колонка показывает процент сжатия по TCP-портам.

Линейки железа





Мощность может быть расширена лицензией. Для повышения производительности в ряде случаев требуется аппаратный upgrade. Возможности апргейда в пределах платформы показаны зелеными стрелочками.

Младшая модель подходит даже для маленького интернет-магазина: она от 1 мегабита в секунду и 20 каналов. А флагман поддерживает до 150 000 одновременных открытых соединений на каналах 1,5 гигабита в секунду. Если этого недостаточно, используется балансировщик Inteceptor. Кластеры из балансировщиков и оптимизаторов позволяют работать с каналом до 40 гигабит в секунду с открытым одновременно 1 миллионом соединений.

Сколько стоит по прайсу?


Младшая модель — примерно от 100 тысяч рублей, устройство для средних ЦОД — 1,1 млн рублей, для крупных ЦОДов — от 5,5 млн рублей. При этом цена достаточно сильно меняется в зависимости от конкретных схем использования, плюс могут быть скидки, поэтому названные числа сугубо примерные, лучше уточняйте по почте (она есть в конце топика). Окупаемость таких решений для среднего и крупного бизнеса просчитать достаточно легко, просто прикинув, что у вас освободится от 30 до 60% канала (опять же, конкретный показатель с точностью до 10% я смогу назвать по почте в зависимости от типа утилизации канала), а пользователи не будут жаловаться на тормоза приложений.

Еще элементы Riverbed:




После того как канал оптимизирован описанным способом, мы чаще всего делаем мониторинг и решение проблем с конкретными сервисами и оборудованием. На практике — это целые детективы. О них я расскажу чуть позже. Если интересно — подписывайтесь на корпоративный блог КРОК на Хабре.

Для кого внедрял конкретно я:


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


Вопросы


Если интересно что-то конкретное, спрашивайте в комментариях или по почте AVrublevsky@croc.ru. По этой же почте могу отправить расчет цен, схемы внедрения и оценку оптимизации канала после обсуждения конкретно вашей ситуации. Понятно, что точная оценка возможна только после теста, но в среднем погрешность после обсуждения — около 10%.
КРОК
143,00
№1 по ИТ-услугам в России
Поделиться публикацией

Комментарии 39

    +5
    Детектив это всегда интересно, а IT детектив в тройне — так что, да ждем от вас расследования.
      –2
      Для затравки.

      Вот два компьютера. Один на Win7, другой на WinXP, они одинаковые за исключением ОС, оба работают через оптимизаторы. Первый в полном порядке. У второго проблема: Excel не может создавать новые файлы в некоторых (не во всех) DFS шарах, начинающихся на "\\company.ru\", а Word и штатный проводник могут, а Wireshark не может (из того, что выявлено). Если путь "\\company\", то проблемы нет, как и если обращаться напрямую на файловый сервер. Воспроизводится это в 100% случаев, проблема ни разу не плавающая. Ни один другой заказчик ни с чем подобным не сталкивался, разумеется.

      True story. Нечто подобное обязательно хоть где-то вылезает на начальных этапах тестирования оптимизаторов, уж больно глубоко они лезут на уровень приложения.
      0
      имхо, решения интересны для узких каналов связи. например, если удаленный офис висит на какой-нибудь йоте или еще хуже 3G-модеме. но опять же это только мое имхо. да и цены, подозреваю, очень кусачие… и стоит ли овчинка выделки.
        0
        Стоит. Срок окупаемости решений варьируется от 6 до 24 месяцев. В зависимости от того какие статьи доходности используются при расчете обоснования. Кроме того для маленьких каналов используется советующие достаточно маломощные модели оборудования, никто из пушки по воробьям не стреляет. И, наоборот, для репликации данных между ЦОДами на разных концах нашей страны или мира, надо использовать уже высокопроизводительное оборудование.
        0
        Я конечно не коммерсант и мне трудно судить о ценообразовании. Но на вскидку мне кажется что легче и надежней увеличить пропускную способность канала на размер стоимости данного решения.
        Соглашусь с shamanis. К примеру у нас есть удаленный объект где находится 1 компьютер. Он завязан на 1С. Там только 3G И вот тут бы могло помочь это решение. Но даже минимальная цена в 100 тыс. заставляет задуматься.
        Потому что на эту сумму можно своими силами уложить оптический кабель до ближайшего провайдера. Хотя повторюсь, я не коммерсант и могу сильно ошибаться в ценах.
          +2
          Отчасти вы правы, но давайте фантазировать. Для вашего примера – один удалённый офис с одним компьютером – нет смысла разворачивать такое решение. Я согласен.

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

          Если же у вас в офисе количество сотрудников приближается к 10 на точку – то в этом случае мы уже рекомендуем использовать минимальную аппаратную модель оптимизатора.

          Все познается в сравнении, возможно за 100 тысяч можно проложить оптику до ближайшего провайдера, но наверно это справедливо в городских условиях с высокой степенью проникновения провайдеров. А что делать производствам? Или тяжело доступным местам нахождения бизнеса?

          Кстати отличный пример – почти все глобальные корпорации, которые приходят в Россию, используют это оборудование для связи со своей штаб-квартирой или ЦОДом в Европе или Америке. Хотя не такая уж большая задержка между Москвой и Европой например.
          0
          Лучше купить оптимизатор чем кормить зажравшегося провайдера, цены у которого не менялись последние несколько лет. Даёшь оптимизацию!
            0
            Оптимизатор, да с двух концов, да совокупность аппаратных и софтверных решений в кубе тонких настроек = + 2 точки отказа в кубе.
            + затраты на инсталляцию и пуско-наладку
            + затраты на поддержку
            + затраты на более квалифицированный ИТ персонал
            + большее время старта филиала
            + затрудненный дебаг сетевых проблем
            + через месяц выяснится, что ключевой модуль ERP который коряво написано и не переписать через улучшайзер откажется работать

            По мне лучше покормить провайдера, чтобы он расширял свою магистральную сеть и закупал более мощное оборудование.
              +1
              + затраты на инсталляцию и пуско-наладку

              Никаких затрат там нет. За исключением первоначального пилота, когда надо понять, как оно работает. Дальше инсталляция новой железки — развлечений на полчаса включая первоначальные настройку и обновление.
              + затраты на поддержку

              WAAS — «включил и работает». Можно иногда посматривать на красивые графики. Иногда менять вышедшее из строя железо.
              + затраты на более квалифицированный ИТ персонал

              По сравнению с чем более квалифицированный?
              + большее время старта филиала

              См. п.1.
              + затрудненный дебаг сетевых проблем

              Дебаг простой — взять и отключить акселерацию для конкретного юзера.
              + через месяц выяснится, что ключевой модуль ERP который коряво написано и не переписать через улучшайзер откажется работать

              Добавить в исключения.
              Я, на самом деле, первоначально ожидал увидеть множество подобных проблем, но пока ничего такого не выявлено. Да и выяснится такое в первые же часы пилота.

              Реальная ситуация. Был корпоратив. Выложили сотни мегабайт фотографий на центральные файловые шары, разнесли весть по регионам. Регионы начали качать. Каналы загружены под 100%. QoS бессилен — этот трафик ничем не отличается от прочего файлового трафика, они толкаются друг с другом.
              С акселераторами куда приятнее — они всё закешируют, каналы будут отдыхать.
                –1
                Немного лукавые ответы, обозначенные мной проблемы в большей степени ни куда не делись, просто либо их никто не считал в денежном эквиваленте, либо не напарывались пока.
                А про фото с корпоративов- напарываемся каждый раз, надо что-то уже придумать, DFS репликацию к примеру предварительную, до публикации ссылки на ресурс — т.е. проблему можно решить по разному.
                  +1
                  просто либо их никто не считал в денежном эквиваленте, либо не напарывались пока.

                  Ну допустим метрика — затраты времени у инженеров. Вот я и говорю, что их как бы и нет после того, как первоначальный пилот завершен. Вот пилот может тянуть время месяцами, пока всё не будет вылизано.
                  надо что-то уже придумать, DFS репликацию к примеру

                  Вы правда думаете, что это проще? :)
                    0
                    Да, это проще. Создать группу репликации -5 минут, со всеми атрибутами, с ограничением по полосе и расписанием.
                    После окончания юзеры будут брать контент с локальных серверов — мгновенно и удобно.
                      0
                      Мне интересно — а вы вживую работали с DFSR? Например, наши винадмины ругаются на него матом и планируют от него уходить. Неподдерживаемых сценариев — море, например, в случае репликации пользовательских профилей: blogs.technet.com/b/askds/archive/2010/09/01/microsoft-s-support-statement-around-replicated-user-profile-data.aspx.
                        0
                        Наши винадмины умеют его готовить, знают его ограничения и не используют по не назначению.
                        Приведенный пример — выстрел себе в ногу, притянуто.
                          0
                          Так озвученный вами пример используется на практике?
                            0
                            Да, работает как часы.
                            Как пример — DFS ресурс в который работники СБ складов локально кладут файлы с охранного видеонаблюдения, а сотрудники СБ офиса с ними работают.

                            Единственный затык был давно, и то по вине провайдера.
                            image
                              0
                              А до 2012 тоже работало?

                              Ну поздравляю. Замечу, что к данной архитектуре применяются все указанные вами ранее проблемы, в которых вы вините оптимизаторы :) И виндовый файловый сервер в сопровождении выйдет явно дороже оптимизатора.
                                0
                                Все члены репликации сервера по управлением 2008R2, скриншот снят с другого доменного сервера, который ближе))
                                И виндовый файловый сервер в сопровождении выйдет явно дороже оптимизатора.
                                Вот не надо, если он уже есть, почему от включения DFS службы он выйдет в сопровождении дороже?
                                  0
                                  если он уже есть

                                  А если нет?

                                  Опять же — реплику всех шар на нем не сделать, никаких дисковых ресурсов и каналов не хватит, а за избранными специально следить надо. А оптимизатору по барабану, с чем работать, никаких предварительных настроек не требуется. Оптимизация SMB даже без DRE/LZ жжот напалмом, в первую очередь на XP клиентах, где на каждый чих по 50 обменов запрос-ответ между клиентом и сервером, но и SMB2 выигрывает.
                                    +1
                                    Вас послушать — так прям волосы шелковистые станут сразу.
                                    Разные задачи решаются по разному, а не тупо запихиванием всего в чудо коробки.

                                    У меня есть лютый, жгущий лавой аргумент- БЮДЖЕТ.
                                    И он может корректироваться только если все упало и пропало, и то со скрипом.

                                    Обосновать затраты, в моем случае примерно в 3-5 миллиона рублей за раз, в 90% контор практически не реально.
                                      0
                                      Разные задачи решаются по разному, а не тупо запихиванием всего в чудо коробки.

                                      Оптимизаторы обычно ставят там, где мухосранским коллегам надо обеспечить качество работы сервиса как можно ближе к сотрудникам, работающим из соседнего с ЦОДом помещения.
                                      Обосновать затраты, в моем случае примерно в 3-5 миллиона рублей за раз, в 90% контор практически не реально.

                                      Конечно. 90% контор даже ISR с трудом могут себе позволить, уж больно он дорогой. Да и не нужны им WAN оптимизаторы, инфраструктура не та.
                +2
                Расширение канала связи не всегда ведет к повышению скорости работы приложений. У каналов связи, тем более протяженных, такие параметры как «круговая задержка» (или RTT) и потери (пусть даже самые минимальные) гораздо выше чем в локальной сети. Именно это не позволят использовать TCP-приложениям всю доступную полосу пропускания канала связи. Два последних обращения к нам были как раз об этом.

                Первый случай. Наземный канал связи Москва — Новосибирск. Сервера располагались в Москве, но затем переехали в Новосибирск. Пользователи в Москве сразу почувствовали деградацию скорости приложений. Причем утилизация каналов не поднималась выше 30%. Потери в канале минимальны. Оптимизаторы успокоили пользователей, они опять работают с «локальной» скоростью.

                Второй случай. Оптический канал связи Москва — Хабаровск. Каждое соединение репликации между ЦОД проходит на скоростях менее 700 Кбит/c, а полоса пропускания канала 1 Гбит/c! Вопрос — за что платит организация?! За полосу которая недоступна. С оптимизаторами скорость соединений репликации возросла до 35 Мбит/c. Т.е. в 50 раз! Репликации проходят в 50 раз быстрее.
                  0
                  Репликация — это самый простой случай. Достаточно включить window size scaling и поставить буфера пошире. Кто-то выжимал и 10G одним потоком с RTT 200мс. Если вы не упомянули об этом клиенту, но впарили ему недешевые оптимизаторы под эту задачу — ну что же, поздравляю, и попутно узнаю Кроковский подход.

                  Реально оптимизаторы нужны в двух сценариях:
                  1) Дедупликация и сжатие
                  2) Болтливое приложение, и оптимизатор может спуфить общение, сокращая количество обменов.
                    0
                    Действительно, репликация – это один из самых показательных случаев. Действительно, за счет подкрутки TCP на серверах можно добиться лучшей утилизации канала. Если репликация происходит между несколькими серверами придется настраивать каждый сервер. Ставя оптимизаторы, вы настраиваете все на одной железке. Также нужно настроить QoS таким образом, чтобы репликации не вытесняли другой трафик. В случае использования оптимизаторов конкуренция за полосу будет равной для всего трафика, но можно настроить полнофункциональный QoS на riverbed.

                    Судя по RTT в 200 мс, рассматриваемый канал достаточно протяженный (не собственность организации), а полоса пропускания огромная. Наверняка, аренда у него немаленькая. Трафик репликации жмется очень сильно. Если происходит полный backup то со второй прокачки к-т сжатия будет порядка 90%. Это означает, что можно арендовать уже не 10Gbps, а 1 Gpbs. Какая экономия за год? За три года? Плюс к этому на оптимизаторах можно настроить QoS по времени. Например, днем – репликации занимают 10%, ночью – 90%.

                    Репликация и/или уменьшения загрузки каналов связи — хорошее применение, но основная задача оптимизаторов – это ускорение работы сетевых приложений, эффект который заметен пользователям и непосредственно влияет на их эффективность. Ускорение сетевых приложений главным образом происходит за счет адаптации TCP под канал связи и проксирования ряда основных протоколов. При этом, как правильно замечено, устраняется болтливость приложений.

                    Так что если решать вопрос «заплатками» — да, можно в каждом отдельно взятом случае обойтись без них, но если говорить об обслуживании организации в целом в стабильной негомогенной среде приложений — они очень и очень востребованы на практике.
                      –1
                      Если репликация происходит между несколькими серверами придется настраивать каждый сервер.

                      Но это в любом случае лучше делать. Дефолтные настройки не годятся для LFN.
                      В случае использования оптимизаторов конкуренция за полосу будет равной для всего трафика, но можно настроить полнофункциональный QoS на riverbed.

                      У вас что, применяется туннелирование? Обалдеть. Лишний плюс в копилку WAAS, который не меняет заголовки L3-L4, трогая только содержимое, и лишний повод назвать Riverbed УГ.
                      Действительно, за счет подкрутки TCP на серверах можно добиться лучшей утилизации канала

                      Трафик репликации жмется очень сильно.

                      А клиенты были в курсе первой опции? Ценник-то явно был шестизначный.
                      Плюс к этому на оптимизаторах можно настроить QoS по времени. Например, днем – репликации занимают 10%, ночью – 90%.

                      А можно прямо на роутерах настроить полноценный QoS — когда трафик репликации занимает всю ширину канала всегда, но только пока он не мешает другому трафику. Полноценный QoS невозможен, когда не 100% трафика проходит через устройство, реализующее приоритезацию.
                      Так что если решать вопрос «заплатками» — да, можно в каждом отдельно взятом случае обойтись без них

                      Если use-case той компании из примера ограничивался озвученным вами, то оптимизаторы явно не нужны.
                      они очень и очень востребованы на практике.

                      Мне об этом рассказывать не надо, вот только пользуюсь я WAAS'ами. Читаю написанное про риветбеды и хватаюсь за голову.
                        0
                        Главное преимущество WAAS в интеграции с продуктами Cisco. Понимаю вашу точку зрения — с учётом, что у вас написано в профиле про Cisco — но все же давайте обратимся к фактам. Факты таковы, что в сегменте WOC (Wan Optimization Controllers) Riverbed уже три года подряд занимает более 50% рынка. В 2013 году Riverbed остался единственным лидером сегмента по Gartner. Gartner не делает такие смелые заключения просто так. Это всегда очень серьезные исследования, которым очень и очень доверяют на рынке. Учитывая, то что Riverbed — нишевой игрок, и его возможности ограничены по сравнению с более крупными производителями, то получить больше половины рынка они смогли только за счет большей эффективности оптимизации и более широкого функционала, чем у конкурентов. Проще говоря, их решение банально лучше для большинства покупателей. По практике в России отмечу, что Riverbed очень и очень хорошо себя показал. Я не предлагаю ставить только его — мы интегрируем и решения Cisco, и других вендоров — но при полном расчёте кейса ситуация в РФ не отличается от мировой, описанной Gartner.
                          –2
                          Вот, продолжаю узнавать КРОК. Сейчас вы, будучи на 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
                          Главное преимущество 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 было заметное превосходство в собственно качестве оптимизации, разные сторонние и не очень моменты могли бы это перевесить.
                            0
                            Со многим согласен, но Lotus Notes просто надо уметь готовить. Однажды у меня некоторое время 300 человек сидели на радио-канале 1-1,5 мб/с, но размещение почтовых ящиков на локальном сервере значительно снизило накал страстей. Не говоря уже про удобство пользования разнообразными базами, справочниками, документооборотом, живущем поверх Лотуса и т.д.
                              0
                              Так Lotus Notes — могучая штука, кто же спорит? Только все равно авторы никогда не слышали слова «юзабилити».
                                0
                                Подскажите плз, а в чем проблема с Lotus и WAAS?
                                  0
                                  В том, что WAAS банально не имеет нужного AO.
                –3
                Самый простой и надежный способ — «в разрыв» между граничным маршрутизатором и коммутатором ЛВС.

                Нет, даже с механическим 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, для другого ищем, но снова тут довольно специфическая ситуация, мало у кого эти проблемы воспроизведутся).
                  0
                  Вот это решение уже выглядит интереснее, чем у ТС
                    –1
                    Маркетологи любят кричать «экономится >9000% полосы!», но забывают о куче других нюансов, которые делают одно решение привлекательнее другого…
                  +2
                  Трафик, который покинул хост в расшифрованном виде, можно считать публичным. Сколько бы его не заворачивали в vpn аппаратные NSA/ФАПСИ-одобренные бэкдоры VPN-шлюзы.
                    –1
                    Трафик, который покинул хост в расшифрованном виде, можно считать публичным.

                    Не все так просто.

                    Расскажу про WAAS. Там тоже есть шифрованные SSL и EMAPI. Если у Riverbed что-то реализовано не теми же механизмами, то официально объявляю их оптимизаторы унылым говном.
                    1) SSL: на ближайший к серверу акселератор загружается приватная часть сертификата, он делает MITM. Соседу-акселератору по ту сторону канала передается только сессионный ключ, тоже в защищенном виде.
                    2) EMAPI: ближайший к серверу акселератор видит начало обмена, обращается к контроллеру домена и получает токен кербероса для данной сессии (предварительно заводится машинная учетка с соответствующими привилегиями). Далее снова передача ключа (или токена?), MITM.

                    В расшифрованном виде трафик бывает только внутри акселератора, на входе/выходе он защищен. Сессионные ключи на диск не пишутся. То, что есть на диске из кеша, можно шифровать (при включении железки потребуется вводить пароль).

                    В общем, параноик внутри меня довольно спокоен.
                      +1
                      Акселератор с закрытым исходным кодом, неизвестным количеством goto fail/goto cleanup в устаревших SSL-библиотеках, комплект бэкдоров и т.д.

                      Не верю. Приватный трафик с хоста должен выходить зашифрованным. В идеале — раздельно для сетевой инфраструктуры (openvpn/ipsec), раздельно на уровне приложения (ssl/ssh). Особо важные данные (письма, коммиты в исходный текст, обновления ПО) должны иметь отдельную криптографическую подпись (gpg).

                      То есть можно сколько угодно убеждать, что выпустить трафик с хоста в нешифрованном виде это безопасно и best practice, но я по-прежнему прижимаю свой кошелёк плотно к груди, не смотря на уговоры.
                        0
                        Акселератор с закрытым исходным кодом, неизвестным количеством goto fail/goto cleanup в устаревших SSL-библиотеках, комплект бэкдоров и т.д.

                        Ну а что поделать?
                        Есть еще балансировщики (которым тоже пригождаются сертификаты), и виндовые сервера… Если не доверять вендору, то придется многим жертвовать.
                        Приватный трафик с хоста должен выходить зашифрованным.

                        Так именно так он и выходит. Балансировщик имеет возможность спуфить сессию, но по всем патч-кордам трафик передается в защищенном виде.
                        Вариантов-то нет. Если балансировщику не дать возможность спуфить обмен, то будет базовая TCP оптимизация и не более того. Ваш выбор. Я вот вижу, что почтовый трафик на первом месте по оптимизации, 70-80% выигрыша только по объему трафика.
                    +1
                    Работаю в крупной международной компании в которой 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 / месяц

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

                    Самое читаемое