Когда мы ехали на монтаж, рядом доставали трактор из оврага
Есть такие суровые русские мужики, которые добывают разные полезные ископаемые, которые подло сгруппировались в труднодоступных местах. Часто просто добраться и вытащить их из-под земли бывает очень и очень дорого. Поэтому развитая инфраструктура на месте добычи — явление редкое. Так вот, на Дальнем Востоке во многих местах оптоволокно — всё ещё раздел научной фантастики, а провод встречается в дикой природе только если принести его с собой в руках.
Связь там сделана через спутник. Соответственно, требования по каналу растут, но расширяться очень больно и дорого — спутниковый ресурс не самый масштабируемый, и гигабайты через него гонять не получится.
Мы решали задачу оптимизации канала за счёт сжатия трафика и приоритезации приложений в каналах, чтобы самое важное всегда ходило первым. Получился целый сетевой детектив.
Вводная
Есть канал на спутнике, и расширять его дорого. Есть решения Riverbed, которые позволяют сжимать трафик, оптимизировать обмен на уровне протокола (чтобы не передавались избыточные данные), плюс кэшировать куски словаря сжатия на себе. Всё это в целом может дать от 20% до 80% выигрыша по полосе в зависимости от того, что за данные и как летают.
Началась задача с того, что нас попросили просчитать возможность приоритезации критичного трафика, чтобы он выделялся из всего обмена, что есть на точках. После выяснилось, что оптимизация тоже очень выгодна, потому что за поднятый спутниковый канал нужно платить постоянно, а за железо — только один раз.
Обследование
Архитектура обмена — несколько «колёс со спицами» с хабами в крупных городах. Например, в Иркутске, Магадане и Москве. На хабы подходит оптика или медь. На удалённых точках на добывающих предприятиях в 90% случаев используется станция спутниковой связи, есть буквально пара радиорелейных линий и ещё на нескольких точках оптикой делятся те, кто так или иначе тащил её мимо ради магистрали.
Поставили систему диагностики, собирающую данные.
Приложений много, а пользователей мало, основной обмен — технический. Вот пример того, что может работать на одном из предприятий где-то далеко-далеко за снегами:
| Распознанное приложение |
Интерпретация наблюдаемого трафика |
| Microsoft-DS Active Directory |
Обмен файлами средствами операционной системы Windows (SMB Direct). |
| Microsoft Terminal Server (RDP) |
Удаленный рабочий стол |
| HTTPS |
Outlook Web Access |
| SMTP |
Пересылка почты между серверами Exchange |
| MS SQL |
Обращения к MS SQL серверу |
| netview-aix-2 |
Клиентское подключение 1С |
| domain |
Служба доменных имен (DNS) |
| webcache |
Доступ в Интернет через прокси-сервер |
По большей части обыденный трафик — это передача файлов, real time трафик, так же есть данные контроля добычи, учёта и сырые данные с датчиков. Многие приложения, которые отправляют информацию, «болтливые», то есть отправляют много пакетов там, где можно было бы обойтись одним. Соответственно, такие вещи решаются Riverbed достаточно просто.
Вот, сравните как работают приложения до и после оптимизации:
Например известный всем «болтливый» протокол CIFS, который используется для доступа к файлам. Файл размером 20-40 Мбайт в локальной сети будет загружен за считанные секунды. Если же загрузка файла осуществляется из удаленного офиса по WAN каналу связи, как показано на схеме выше, время загрузки может быть увеличено до 5 и более минут.
Чтобы уменьшить время загрузки в удаленный офис, нужно свести к минимуму количество проходов в обе стороны.
Для приоритезации трафика нужно было разбирать пакеты — пришлось поднимать аналог DPI и смотреть на 7-м уровне, поскольку просто разбрасывать по используемым портам было явно недостаточно — один и тот же тип трафика мог быть как показаниями важного датчика, так и болтливым обменом чего-то некритичного. Или вот надо было выделять сессии Exchange и отдавать под них полосу ещё на этапе установления соединения.
До этого, конечно, попробовали просто на роутерах, но там очень сложный контроль, плюс всё это сложно поддерживать конфигом. Чтобы было полное понимание — в нашем случае в центральном офисе в Москве нет команды поддержки. Основная сидела на равноудалённом расстоянии от точек добычи и головной организации. Место так выбрано из-за часовых поясов — есть шансы застать рабочий день и там, и там. Есть и промежуточная команда для оперативных задач, но никому из этих людей совершенно не надо было создавать столько проблем для ручных настроек. И без гарантии правильной работы в будущем.
Железо
Тут надо прерваться и сказать, что вся эта история гладко звучит только на бумаге. Сложности, конечно, были — начиная от такой банальной вещи как подключение зеркалирующих устройств анализа трафика. Просто представьте себе добывающее предприятие где-то очень-очень далеко, куда нет дороги. Добраться туда по земле можно только несколько месяцев в году. Соответственно, железо после отправки ещё где-то минимум 1 месяц добирается до точки. Как доберётся — его нужно подключить, причём подключать будет кто-то местный из службы поддержки пользователей.
Подключалось всё это, к счастью, в разрыв на выходе из серверных через байпасс, поэтому работы шли достаточно просто. Единственный момент — нужно было дать все инструкции ДО того, как инженер на точке дёрнет кабель, потому что та же телефония была завязана именно на него.
Оптимизатор — самый низ
В итоге была отработана такая схема:
- Мы получали железо на свой склад в Москве
- Делали диагностику и преднастройку, чтобы можно было сразу после подключения управлять устройством.
- Отправляли по филиалам
- Дальше играли в «Аватара», помогая специалистам на месте делать непонятные для них движения с кабелем. Иногда всё это наблюдали по видеопотоку с большим лагом. Смешно никому не было.
- Позже, через год, пришла вторая часть квеста — с некоторых точек измерительное оборудование надо было снять и поставить на другие.
Опять же, романтика Севера — один ЦОД доехал до места на салазках, хорошо хоть не собаками. ЦОД на салазках, да-да.
Продолжение
Итак, мы увидели какой трафик ходит и в каких объемах. С какими задержками, что бизнес-критично, что нет. Что для компании важно разметили, что можно «зарезать» — «зарезали», если в полосе был важный трафик. Выделили 4 класса обслуживания для разных типов информации, согласовали их с операторами связи. Собственно, мы этот трафик «раскрашивали» — а у оператора связи на месте делался шейпинг. Была ещё особенность в том, что на каждом объекте свой оператор связи: где-то нужно было заплатить дополнительно за услугу, где-то просто не было технической возможности шейпить правильно, приходилось укладываться в меньшее количество классов обслуживания и придумывать разные хаки.
Правили проблемы сетей. Наши зеркалирующие сенсоры стали идеальным средством отладки. Сенсоры ставились по всем регионам, имели копию трафика — можно было взять копию трафика с нескольких точек из филиала и из центра и сравнить. Получалось, что у нас была возможность зафиксировать каждый пакет здесь и там. В результате мы могли оценить что происходит у оператора связи с каждым из них реально. Вот пример:
Пример проведения диагностики у заказчика:
Видим на каком хопе потерялся пакет на пути от сервера к клиенту
Был случай — приехал большой босс в филиал и говорит, мол, что-то у вас тут один терминал специфический отваливается. «Прихожу с утра на включенную машину — а он отвалился». Инженер на месте просто подключился к сенсору и забрал последние пакеты сеанса, чтобы посмотреть, почему завершилось соединение. За полчаса в пакетах нашлось, что клиент сам обрывает соединение по таймауту. В пакете написана причина — и он забил её код в Google — и сразу увидел настройку, чтобы не разрывалось.
Какое железо?
Устанавливались разные модели оптимизаторов начиная от младших, заканчивая старшими — в зависимости от ширины канала связи и количества пользователей и информационных ресурсов на площадке. Подробнее про решения Riverbed я писал здесь и вот здесь в теории.
Какая итоговая экономия трафика?
Вот пример с одной из точек:
Total optimization здесь равен 57,05 за неделю для оптимизированного трафика на одном из крупных узлов.
Собственно, вот такая история. Если интересны детали конкретно по вашему проекту — могу примерно посчитать по почте AVrublevsky@croc.ru. Ну и готов ответить на любые вопросы здесь или в почте.
Комментарии (14)
gotch
29.09.2015 11:52+2Подскажите пожалуйста, какая в итоге задержка на канале? Для спутника латентность должна быть достаточно высокой. Как работает RDP?
AVrublev
29.09.2015 13:13+1Реальная задержка на каналах связи = 600 — 700 мс RTT. И в зависимости от внешних факторов может ухудшаться.
Если канал связи не загружен, то мы не увидим заметного ускорения работы RDP. Но с другой стороны, если канал связи сильно загружен, то оптимизаторы позволяют разгрузить канал связи, приоритезировать приложения и за счет этого повысить стабильность и ускорить RDP. В нашем случае мы добились заметного улучшение работы RDP.gotch
30.09.2015 10:04Вообще RDP работает приемлимо на канале в 700мс RTT? С какими приложениями? Есть ли шансы на просмотр CAD графики?
Расскажите, пожалуйста.AVrublev
01.10.2015 10:52На задержках 700ms RDP тормозит… Шанс есть, все зависит от устойчивости Вашей нервной системы или правильных успокаивающих средств? Шучу! Не все так плохо.
Здесь многое будут зависеть от наличия потерь и доступной полосы пропускания.
В случае с RDP оптимизатор может побороть тормоза связанные с потерями и полосой пропускания (за счет сжатия и прозрачного проксирования TCP), но не задержками.
easyman
29.09.2015 22:40По картинкам (вторая, третья) видно, что оборудование посылает запрос и ждет ответ, перед тем, как что-то еще отправить.
Придумаем очень простой протокол, например, для калькулятора.
На сервер будем передавать задания: пара чисел и операцию. Ожидать будем результат (допустим, он нам нужен для последующего вычисления) И что с этим может сделать эта волшебная железка?
Я правильно понял, что оптимизации поддаются только протоколы, где оптимизатор может предугадать ответ. Например, в случае SMTP будет всегда быстро отвечать «250 OK» несмотря на то, что допустим, ящик адресата на самом деле уже удален с сервера?gre
29.09.2015 23:49+2По роду деятельности я немного знаком с ривербедами, потому отвечу вам.
1. У них есть режим работы с предустановкой tcp-соединений, что на канале с высоким RTT даёт выигрыш времени на установку соединения. При типичном RTT 700ms на установку обычного TCP-соединения нужно 2.1 секунды. Если мы заранее установим сессию — мы сэкономим это время.
2. Сжатие данных, в случае простого калькулятора — эффекта будет мало, а для работы среднего приложения по API с передачей данных json/xml выгоды будет существенно больше.
AVrublev
01.10.2015 10:54С точки зрения калькулятора, есть два варианта –
1. В случае, если это приложение работает посредством «толстого» клиента, то эффекта от оптимизации будет мало. Т.к. будут выполняться короткие запросы-ответы, могу даже сделать сравнение такого приложения с работой telnet.
2. Если представить, что это приложение работает на базе http (как большинство современных приложений), то эффект будет значительный.
Во-первых за счет оптимизации http, который сжимается и оптимизируется очень хорошо – т.к. нужно как минимум загрузить web форму (того же калькулятора) в браузер клиента.
Во-вторых, если представить, что в виде ответа от сервера на заполненные поля в web форме мы получаем некий объемный отчет, который как правило избыточный, то эффект от использования оптимизатора за счет де-дупликации будет так же значительный.
Для каждого конкретного протокола прикладного уровня (из списка ускоряемых на L7) оптимизатор применяет свой специфический алгоритм оптимизации. Если мы говорим об SMTP, то здесь основной задачей является “вскрыть” шифрование. SMTP соединение устанавливается до SSL-соединения, таким образом, возникают сложности в определении момент запуска SSL-оптимизации. На помощь приходит L7 блейд оптимизатора, отвечающий за SMTP. Более того использование L7 блейда обеспечивает, что не нужно делать TLS-handshake для отправки каждого письма.
За нашу практику не встречали ситуаций когда из-за оптимизатора пользователь мог скачать удаленный файл или посмотреть удаленное письмо:)
AlexanderG
04.10.2015 16:24Между прочим (пишу комментом, т.к. с этим словом часто возникают вопросы и несколько раз спорили на работе):
Вопрос № 190204
Есть три варианта написания слов: «приоритизация», «приоритезация» и «приоритетизация». Которое из них правильное и имеет право на существование? Контекст: «Приоритизация привлекательных рынков» Спасибо
Гликин Г.Я.
— Ответ справочной службы русского языка
Слово не зафиксировано в словарях. Видимо, происходит усечение основы (ср. без усечения было бы приоритетизация), поэтому корректно: приоритизация.
Источник.
ildarz
А что это за SSL трафик, который так адски сжимается?
И, я так понимаю, на уровне приложений для оптимизации трафика там особо ничего не делалось? Для того же SMB всякие DFS и BranchCache…
AVrublev
В первую очередь SSL в отчете — это OWA.
Riverbed оптимизирует SMB с помощью нескольких техник:
— дедупликация (сжатие)
— ускорения на транспортном уровне TCP (спутниковый режим SCPS)
— ускорение на уровне приложений
Подобным образом выполняется оптимизация и других самых распространенных типов приложений.
ildarz
Я правильно понимаю, что на канале стоит пара девайсов с импортированными сертификатами, которые расшифровывают трафик, жмут и на другом конце шифруют снова?
Я о другом. «Поставили в неоптимизированную инфраструктуру и порадовались» — тоже жизненный сценарий, конечно. Но, как трафик ни оптимизируй, а всё равно файлы грузить с удаленного сервера. С другой стороны, DFS и BranchCache в винде из коробки и решают вопросы с SMB-трафиком куда более радикально (причем в случае BranchCache даже локальный сервер может не понадобиться). Вот и было бы интересно посмотреть, даст ли что-то Riverbed в ситуации, когда другие пути оптимизации тоже задействованы.
AVrublev
1. Да, все верно. Единственное добавлю, что сертификат импортируется только на один оптимизатор, установленный в ЦОД. Есть и другие варианты архитектуры, но эта в данной ситуации оптимальна.
2. Дело в том, что оптимизатор не кеширует файлы целиком в прямом понимании этого слова. Оптимизатор хранит самые часто используемые сегменты данных в словаре (механизм SDR – Scalable Data Reference) и нет привязки к протоколу, по которому будет получен файл в филиале. Например, файл презентации PowerPoint передали по почте в филиал. А затем в случае загрузки этого же файла по FTP, но с небольшими изменениями, будет переданы только изменения, остальные данные будет переданы в виде коротких ссылок на сегменты данных. Т.е. весь файл передаваться полностью не будет. В случае, если файл >10 Мбайт и канал связи спутниковый, то это значительно экономит полосу пропускания.
Lelik13a
И вообще, при смене протокола передачи файла, меняются и заголовки пакетов, которые передают содержимое, да и само содержимое может по пакетам быть распихано по другому. Как в таком случае строится словарь данных, и на сколько такое кеширование эффективно?
AVrublev
В оптимизатор встроены декодеры. Словарь оптимизатора заполняется оригинальными данными после декодирования. Это не совсем кеширование (точнее совсем не кеширование). Это дедупликация данных за счет замены уже записанных паттернов оригинальных данных ссылками. Эффективность высокая. Конкретные цифры зависят от количества избыточности в передаваемых данных. Опыт показывает, что эта избыточность есть всегда.