Привет! Я с коллегами оптимизирую имеющиеся каналы. Нас постоянно путают то с оптическими уплотнителями, то с инженерами-кабельщиками, то, вообще, с грузчиками.



А наша работа – это разбор стека протоколов и его полная перекомпоновка под особенности канала, настройка оптимальных размеров фрейма, сбор нескольких пакетов на канал с большим latency в один, дедупликация, обычное сжатие, разбор SSL и пересборка с тем же сертификатом. Решается это в самом простом случае установкой специального железа на принимающей и передающей стороне. Поскольку до каждой точки надо добраться, мы ещё и работаем выездными инженерами. И, как у любых выездных инженеров, историй у нас море. Ниже я расскажу несколько, только поменяю ряд второстепенных обстоятельств, чтобы нельзя было узнать заказчика.

Например, идут ночные работы в очень крупном магазине. Админ заказчика и наш инженер зашли в час ночи в серверную, работают. Инженер вышел в туалет, вернулся. Через пару минут – стук в дверь. Открывают — и сразу влетает ГБР с автоматами, сразу ногами по корпусу, мордой в пол и в наручники.

Потом подъезжают полиция и главный по магазину. Главный оценивает ситуацию и веско заявляет:
— Вот этого знаю, это наш админ. А вот этого не знаю. Забирайте.
Кончилось, к счастью, хорошо. Админ с пола шипит:
— Мы ж тебе писали!
Главный достаёт телефон, читает:
— Будут ночные работы… я и такой-то… Аааа, вон что, — поворачивается к полиции и с явной жалостью продолжает:
— Придётся отпустить.

Не заметили, как стало хорошо


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

Обратной связи нет: ну, думаем, ладно, значит, им там не надо оптимизатора. Может, канал поправили. Но! Через три месяца звонят, хотят полное. Оказалось, что триал закончился, и они внезапно заметили, как стало плохо. Что интересно – как стало хорошо, даже не пикнули, ни слова. А как обратно стало плохо – пользователи завалили жалобами руководство.

Телефонный хулиган


Делали тестовое внедрение систем диагностики сети. Развернули комплекс в дата-центре, он потихоньку обучается. А надо сказать, что местная инфраструктура росла в результате постепенного слияния компаний, поэтому не очень гомогенна. В смысле, используется много систем, и каждая показывает ситуацию на своем уровне, а целой картины по трафику приложений нет ни у кого.

В этот момент они как раз запускали новое приложение, которое хорошо показало себя в тестовом сегменте, но в промышленной сети под нагрузкой его ещё не видели. Внедрили, но из-за сложной структуры об этом знали не все ИТ-специалисты. Через 3-4 дня после включения сервиса начались проблемы с ip-телефонией. А колл-центр был на ней. Причём звонки теряли во всех направлениях. Клиентские. Полдня пытались решить проблему своими средствами, но никак не могли отловить причину – баг плавающий, и то воспроизводится, то нет.

Админы постучали к нам спросить, можно ли систему диагностики нашу использовать для детектива. Там стоит «Каскад», он как раз трафик разбирать на лету умеет. Вошли в режим отладки и начали смотреть за сетевыми аномалиями.

Выяснилось, что новый сервис использовал те же порты, что и у телефонии. Новый трафик с теми же портами начал попадать в приоритет и вытеснять голос. После этого изменили настройки классификации трафика телефонии.

Похожая ситуация была в одном крупном колл-центре оператора. Абонент звонит, он оператора слышит, а оператор его – нет. Больше месяца местные сетевики искали решение своими средствами и силами — надо сказать, что так долго, потому что баг был плавающий, и детектировать его было достаточно нетривиально. В итоге дело дошло до московской команды, точнее, до их топа. Тот постучал чем-то по столу и поставил дедлайн. Обратились к нам. Мы привезли ту же самую систему диагностики Ривербеда. Собрали трафик с разных сегментов — сравнили и в реалтайме начали смотреть качество голоса на разных сегментах. В течение 5-6 часов нашли сбойный коммутатор, у которого слетели очереди. Там была странная проблема с железом, время от времени летели настройки. С телом хулигана разбиралась уже команда – мы просто поменяли коммутатор, и это полностью закрыло вопрос.

Никогда не обновляйтесь в пятницу после обеда


С обновлением ещё история была отличная. Тоже банк, но уже другой. Админ обновил прошивки балансировщиков около 12 ночи. Примерно в два один из них начал молча дропать трафик, который ему чем-то не нравился. Далеко не весь. Случайные пакеты. Обнаружили это ещё через несколько минут, когда безопасник из Хабаровска заподозрил что-то странное с транзакцией. Ещё через 6 минут классическая тревога, «икс-команда, на выезд». Причём предварительный диагноз – аппаратный сбой в коммутаторе ядра. Как обычно, лифт, внизу ждут кладовщики с новым коммутатором, по машинам – и туда. К счастью, пока ехали, мой коллега, который подцепился удалённо, разобрался и откатил прошивки балансировщиков.

Сила прогресса


Поставили оптимизатор в режиме обучения на объект в банке. Местный админ должен был перекинуть его в боевой режим, как он «освоится» с местными потоками. Обычно от дня до недели на профилирование, потому что есть ещё особенности с безопасниками. Там была нужна небольшая перекоммутация с ночным бдением, поэтому, наверное, за два месяца ничего не происходило в плане переключения. Железка получала свою копию трафика и терпеливо училась. Банк был в процессе закупки в несколько этапов, поэтому главный админ использовал эту лицензию для другого объекта. Мол, здесь и так хорошо пока, ближе к пику поставим.

А потом у них упал (и очень серьёзно) наземный канал (а, может, он и не упал, и админ знал про то, что его придётся менять – и потому не врубил оптимизатор в период, когда придётся жить без резерва). Они прыгнули на спутник. Телепорт был прямо на крыше, им уже неоднократно пользовались, поэтому, по логике, проблем быть не должно. Предполагалось переждать на нём две недели, пока подведут новую наземную линию. Но за время, прошедшее с последнего долгого сидения на спутнике, приклад немного обновился и стал требовательнее к полосе.

Проще говоря, работать софт стал плохо.

А через сутки пришли клиенты. Обслуживание шло медленно, народ путался, кто за кем стоит, закольцовывали очереди и неплохо так виртуализировались, занимая сразу несколько из них. Виртуальных посетителей в банке стояло под три сотни, физических – раза в четыре меньше. Примерно раз в три часа у всей этой системы очередей случался kernel panic, и дело грозило дойти до драки.

У нас срочно запросили ещё одну лицензию на продажу. Так мы и узнали всю эту историю. Далее технический прогресс помог людям решить свои проблемы.

Спасибо, парни


Репликация базы между Москвой и очень далёким городом России. Полоса – спутник. Трафик гоняется сжатой базой, рывками, неоптимальными пакетами, часто теряется. Мы предложили оптимизаторы. С ними репликации пошли быстрее, очереди запросов не копились, полоса (как обычно) утилизировалась много больше. Но было ещё куда расти. Основная точка – нам очень не нравилось, что реплицировалась сжатая база. Сжатое разбирать и ускорять – толка считанные проценты. Гораздо лучше было гонять сырую базу, чтобы её разбирали сами железки.

Сырую базу не могли гонять по какой-то причине, она не проходила дальше файрволла. Мы поковырялись в настройках, и через пару дней сырая боевая база стала летать нормально. Тут подключились стандартные возможности их железа, освободилось процессорное время (уходившее на сжатие) – из 27 часов на репликацию они стали попадать в 23. При том, что мы с оптимизаторами делали 12-14. И тут нам сообщают, что всё, спасибо, мужики, задача была в SLA уложиться. Уже укладываемся. Оптимизаторы ваши крутые, но сейчас пока хватит.

Так мы сами себе во время выполнения заказа отменили этот заказ.

Сервер за бутылку


Делаем пилотное внедрение ривербедовского оптимизатора трафика на одном особо крупном промышленном объекте. Устройство большое, полноценная стойка. Серверная на объекте на втором этаже, а на первом – непосредственно цех, торчит арматура, ходят суровые чумазые мужики. Под серверной какой-то административный блок, там учёт и контроль.

Так вот, идём мы через этот цех, и тут из-за одного из станков выруливают двое прямо ярко выраженных представителей рабочего класса. Как положено – на лице следы то ли краски, то ли мазута по форме очков, на головах оцарапанные каски. Говорят:
— Слушайте, а можно вы железку пока снимать не будете?
Мы:
— В смысле? Мы как раз за ней.
Один замялся:
— А это, сколько она стоит?
Вопрос, конечно, очень насторожил. Пробуем выиграть время:
— Мы не имеем права с вами обсуждать условия контракта.
Второй рабочий сразу переходит к делу:
— Ну примерно? Мы её себе купить хотим.
Тут мы слегка окосели. Мужики не совсем верно истолковали наше молчание, и решили, что всё, можно начинать торговаться:
— Ну… за ЯЩИК водки отдадите?

Мы кое-как от них отбились, объяснили, что оптимизатор стоит не один десяток тысяч долларов и быстро-быстро дошли до серверной. Там и начали выяснять, что это было.

Оказалось, что это не просто работяги, а операторы АРМ, которые отвечают, в частности, за отчётность. И у них бывают такие жизненные периоды, когда они приходят в этот административный блок работать. Там стоит их ERP, куда надо вбивать данные. Канал DSL, причём из тех, что не очень далеко ушли от ISDN. Тонкий, шумный как пустой товарняк, отдаёт наследием 90-х, в общем – заводская классика. А приложение современное, «болтливое», гоняет кучу шифрованного трафика. Поэтому лаги между щелчком по выпадающему списку и его показом – секунд 10-20. В лучшем случае. А вбивать там ого-го сколько всего. Ситуация несколько отягчается тем, что стучат они одним пальцем и часто ошибаются, поэтому приходится возвращаться назад. Что не добавляет особой радости из-за всё тех же лагов.

Так вот, они узнали, что та чудо-железяка, которую с помпой тащили через весь завод на второй этаж – это оптимизатор трафика. В целом, они бы ничего не поняли, если бы не постояли за спиной у тех, кто тестировал этот девайс в соседнем кабинете, где всё тот же ривербед был подключен на пилот. В этот момент они сразу всё осознали и попросились на пару дней туда для детального теста. Их пустили.

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

Естественно, таких цен они просто не ждали.

Через пару часов мы выходим сказать грузчикам, что всё готово, можно забирать. На выходе уже ждут два наших героя:
— Мужики, а давайте вы её оставите для тестов ещё на месяц, а? ЯЩИК дадим.

Чем кончилось – не знаю. Руководство холдинга после тестового внедрения купило несколько десятков железных оптимизаторов. Попала ли к нашим парням железка в итоге или нет, не могу сказать, но очень хочу верить, что попала. Ну или хотя бы им установили программный агент, который умеет отвечать «большому» серверу.

Ссылки:


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


  1. BigD
    05.01.2016 12:12

    А как Riverbed работает с SQL трафиком?


    1. Ghool
      06.01.2016 14:00

      Кстати да, как вообще оцениваете Riverbed для профилирования?


    1. ARumyantsev
      06.01.2016 16:16

      В основном используются два метода.
      Во-первых, дедупликация повторяющихся данных в канале связи протокола SQL. Соответственно при этом в разы ускоряется работа SQL и доступ к данных, плюс разгружается WAN канал связи.
      Во-вторых, выполняется оптимизация взаимодействия клиента и сервера, а именно избыточное и неэффективное взаимодействие между клиентом и сервером переносится в Локальную сеть (осуществляется общение между Оптимизатором и Клиентом/Сервером), а в WAN канал связи отправляется только полезные данные.
      Конечно еще можно выполнить полноценный QoS и еще кое-что, все зависит от задачи.


      1. BigD
        06.01.2016 22:16

        Я правильно понимаю, что сначала Riverbed по сути копирует в себя результат SQL запроса, и отдает только уникальные данные? Если результат одного запроса — гигов 40 данных, все проанализирует?


  1. nikerossxp
    05.01.2016 15:12

    Оптимизаторы сети повесили систему слежения и телефонию в одном сегменте и всё упало? Я правильно понял?


    1. kets
      05.01.2016 15:56

      В этот момент они как раз запускали новое приложение, которое хорошо показало себя в тестовом сегменте, но в промышленной сети под нагрузкой его ещё не видели. Внедрили, но из-за сложной структуры об этом знали не все ИТ-специалисты. Через 3-4 дня после включения сервиса начались проблемы с ip-телефонией.

      Они — это заказчик, на сколько это понятно из текста.


      1. nikerossxp
        07.01.2016 03:11

        спасибо, был невнимателен.


  1. erlyvideo
    05.01.2016 15:58
    +1

    что такое оптимизатор трафика? Как оно работает?


    1. sohmstyle
      05.01.2016 16:18

      В их блоге есть статья про оптимизаторы.
      У автора хотелось бы спросить использовалось ли кэширование трафика на оптимизаторах Riverbed, например, как у Cisco WAAS?


      1. ARumyantsev
        06.01.2016 16:17

        У Riverbed механизм дедупликации избыточных данных в канале связи называется SDR (Scalable Data Referencing), который основан на методе словаря — файлы разбиваются на сегменты, присваиваются получившимся сегментам ссылки, далее в канал связи передаются эти короткие ссылки. Причем этот механизм работает без привязки к используемому протоколу — передаете Вы файл по FTP или CIFS, механизм будет работать.
        Кеширование файлов в обычном понимании не используется.?


  1. nikitasius
    06.01.2016 00:59
    +1

    От себя добавлю (байка, которую слышал): банк, серверная, проверки языком витой пары, подсоединена ли или нет.


  1. AndryX
    06.01.2016 19:49
    +1

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

    И что происходит если трафик идет через двухмегабитный Ривербенд если поставить его в таком месте? Он оптимизирует 1/25 канала или попросту порежет его до 2 Мб/с. И отдельно, что если только часть WAN трафика идет на какую-нибудь Индию, а остальное — по миру? (Про то, что можно купить более дорогое решение, я понимаю. Интересна механика.)


    1. ARumyantsev
      11.01.2016 17:36

      По поводу каналов 50 Мбит/c – это не совсем так. Конечно, чем хуже условия, тем более ощутим будет эффект от оптимизации трафика. Многое зависит от расстояния между офисами и, соответственно, сетевой задержки на канале связи, плюс от качества этого канала связи или от процента потерь пакетов. Так, например, при сетевой задержке в 100 мс и определенном количестве потерь на канале связи в 50 Мбит/c — реальная скорость TCP соединения будет порядка 3-5 Мбит/c и выше подняться не сможет. Возможно, это и будет причиной, что канал связи не загружен полностью. Оптимизатор в этом случае поможет и позволит максимально утилизировать канал связи и, соответственно, быстрее доставлять контент до удаленного офиса.

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

      Оптимизация – это симметричная технология, поэтому нельзя забывать, что с другой стороны канала связи должен быть установлен второй оптимизатор. Поэтому для Вашего примера – оптимизаторы (или хотя бы мобильные их версии на рабочих станциях) должны быть в Индии и на площадках по миру для успешной работы оптимизации трафика. Если это так, то для Ривербед не принципиально между какими площадками выполнять оптимизацию трафика. Оптимизатор видит в пакетах tcp флажки, указывающие на наличие Ривербеда на другой стороне, и в случае попадания трафика под правила оптимизации (ACL), начинает оптимизировать трафик.


      1. AndryX
        11.01.2016 19:40

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

        Но вы сказали что оптимизатор порежет трафик, и это очень хреново. Выходит если у нас есть 2-3 мобильных сотрудника в Индии (с приложениями на их компьютерах), то нам все равно нужно купить очень дорогостоящее оборудование или резать хороший и широкий канал до пары мегабит ради них двоих.


  1. AndryX
    11.01.2016 19:40

    Удалено, ошибся формой ответа.