Pull to refresh

Comments 43

Часть с «подняли туннели — распихиваем трафик, на сервере собираем» — понятна, всё последующее — какой-то оверкилл.

Локального демона, который бы динамически дёргал метрики для route'ов в зависимости от загруженности tx queue у сетевого адаптера (или туннеля) — мне кажется, было бы достаточно. Частично нужно было бы ещё как-то учитывать разные flow, чтобы одна флоу попадала только в один канал в один момент времени…

Вообще, задача с админской точки зрения интересная.
Локального демона, который бы динамически дёргал метрики для route'ов в зависимости от загруженности tx queue у сетевого адаптера (или туннеля) — мне кажется, было бы достаточно

Накопление очереди, и вообще любые локальные метрики интерфейсов — это уже последствия. В нашем случае, если будем смотреть только на них, то словим системные проблемы потери пакетов, ведь если очередь начала расти — со связью что-то не так.
Поэтому, первичными метриками являются показатели качества связи самого оператора, а локальные метрики используются только как обратная связь от автоматической развесовки каналов.
А как вы определяете качество связи без отправики реальных пакетов?
Существующие системы определяют качество канала искусственно нагружая его. В нашем случае это неприемлемо, поскольку отнимает значительную полосу пропускания.
Мы опираемся на первичные признаки качества канала — это метрики оператора сотовой связи и вторичные признаки — локальные метрики туннеля.
Пропускную способностью каждого тоннеля конечно же измеряем, но на основе реально передаваемых данных, без искусственной нагрузки.
Эм… Я понял, что меня смущает.

Что это за волшебные метрики оператора сотовой связи, которые позволяют оценить качество канала без передачи данных?

Я бы в качестве признака «фигни в канале» использовал бы ещё метрики vpn-сервера. Например, сранивая rx и tx на приёмнике и отправителе. Если дельта начинает расти — канал плохеет.

А что такого интересного про канал может рассказать сотовый оператор?
От какого-нибудь Крока ожидал бы такое прочесть, а от Mail.ru… Это в рамках покрытия инетом поездов, чтобы сервисы mail.ru имели большее проникновение (хотя — куда уж больше-то)?
А вы статью точно читали? До конца?
Это сарказм был, если что. Для сетевиков как такое сотворить — данность, частая задача, и самый интерес в алгоритмах. А вы как-то его-то и пропустили. Остается спрашивать о том, что я и озвучил.
Не, я к тому, что статья не от мейла совсем :) Она в нашем блоге, но внешняя. Там и подпись автора имеется.
Прямо как в анекдоте: «А что, можно было и так?»
Мы наивно ранее полагали, что подпись автора с должностью и компанией внизу кабэ намекает на авторство статьи. Теперь, вот, призадумались.
На мой взгляд статья в стиле «как нарисовать сову». Во всей этой воде заинтересовало то, как именно распределялся трафик по априори нестабильным каналам. И тут на тебе — вместо этого рассказали в какой базе данные хранятся.
Поскольку это заказная разработка, мы серьезно ограничены NDA и детали публиковать не имеем никакой возможности. Если заметили, даже не привели название заказчика. Логика алгоритма достаточно проста, но потребовалось почти полтора года экспериментов, чтобы опытным путем выстроить правильную модель принятия решения.
Главной задачей было суммирование емкости доступных каналов и при этом избежать потери пакетов.
Потерю пакетов удалось свести к минимуму только за счет упреждающих решений. В результате самое простое решение оказалось самым надежным. Устройство составляет карту покрытия сотовиков на пути следования. При приближении транспорта к зоне отсутствия или неуверенного приема, идет упреждающее переключение на более стабильные каналы.
Чем больше ездим — тем точнее карта покрытия. В нашем случае все маршруты статичны и меняются очень редко.
Карта составляется на основании чего?
Удалось ли в результате суммировать пропускную способность? Или просто переключаете на разные каналы?
Что используется для улучшения приема? Направленные антенны? Их же можно вертеть…?
>Карта составляется на основании чего?
Карта пропускной способности очень простая. в конкреной точке (широта/долгота) измеряется качество сигнала оператора сотовой связи и текущие показтели Rx/Tx для каждого тунеля

>Удалось ли в результате суммировать пропускную способность?
Это основная задача которую решали. Да, удалось.

>Что используется для улучшения приема? Направленные антенны?
Направленные антенны бесполезны на движущемся транспорте.
Качество сигнала в чем выражается? Что такое показатели Rx|Tx?

Про основную задачу как раз подробностей хотелось бы больше…

Направленные антенны очень даже полезны, почитайте например про управление дронами и следящим за ними станциям
Если вас это действительно интересует, то существуют алгоритмы управления потоком (congestion control), рассчитанные на работу с несколькими каналами сразу. Они «перетягивают одеяло» на разные каналы, в зависимости от потери пакетов, длины очереди отправки, времени отклика.

Если интересуют практические описания, то рекомендую начать с этого и этого документа, далее:
RFC6356
https://tools.ietf.org/html/draft-khalili-mptcp-congestion-control-05
https://tools.ietf.org/html/draft-walid-mptcp-congestion-control-04
Читал, думал, что расскажут про используемое оборудование, антенны, трудности при монтаже и выявленные во время эксплуатации, а здесь всего лишь поверхностное описание.
Если интересно, могу написать про это большую отдельную статью. Какое железо было выбрано, как оно было смонтировано, какие сложности и проблемы удалось решить, а какие не удалось. Если этот пост наберет хотя-бы два десятка плюсов — сделаю отдельную статью.

Уже набрал, пишите ;-)

Имелось в виду плюсы к комментарию, а не статье.

я не могу ставить «плюсы», но мне интересно!
Спасибо за статью. Есть вопрос.
1.Позволил ли Вам сбор метрик операторов связи получить стабильную инфу о перфомансе каждого линка? Дело в том, что метрики волотильны и имеют высокую дисперсию, так же сильно подвержены влиянию стохастической компаненты (проехал грузовик, пролетела стая птиц), дополнительно влияние оказывает загрузка БС.
2.Ваше решение работает на уровне пакетов или сессий?
1. Чем больше проездов по маршруту, тем меньше влияние случайных помех. В нашем случае проблему решили полностью
2. Пакетов
А какова эффективность объединения? доля накладных расходов?
Накладные расходы составляют дополнительные 2 байта для каждого пакета, поскольку в каждый пересылаемый пакет включается информация об его очередности и принадлежности к туннелю
Если вы балансируете пакеты, что вы делаете с TCP? Гоняете по туннелю, или локально терминируете его каким-нибудь TCP-прокси?
TCP-стеки очень разные, часто неэффективные, и локальное терминирование будет заведомо быстрее и эффективнее балансировки пакетов.

Вообще, странная статья. Хочется каких-нибудь подробностей, хотя бы поверхностных. Вы используете ARQ-протокол, собственной разработки? Как вы боретесь с bufferbloat? Как вы управляете потоком (congestion control)? Почему вы не воспользовались готовыми решениями, например, mptcp или mlvpn?
> Почему вы не воспользовались готовыми решениями, например, mptcp ....?
MPTCP идентифицирует несколько маршрутов за счет наличия у компьютера нескольких адресов. Комбинации этих адресов позволяет сформировать дополнительные маршруты.
Это значит, что на терминирующем сервере, должно быть сотни внешних IP адресов

>… или mlvpn
аналогично

Главное, почему пришлось писать свое решение, и это обозначено в статье, необходимость упреждающего мониторинга каналов ПД оператора сотовой связи и последующей тонкой развесовки каналов.

Нам не удалось найти готовое решение, которое это умеет.
Это значит, что на терминирующем сервере, должно быть сотни внешних IP адресов
Хм, нет. Несколько адресов должно быть на клиенте, а не на сервере. На сервере может быть один IP-адрес.

необходимость упреждающего мониторинга каналов ПД оператора сотовой связи и последующей тонкой развесовки каналов.
Здорово, конечно, что вы реализовали свой congestion control, который учитывает, в том числе, и данные от БС, но можно обойтись и без него. Существующие алгоритмы работают без какой-либо внешней информации.
>Существующие алгоритмы работают без какой-либо внешней информации.
пруф?

>На сервере может быть один IP-адрес.
Буду признателен за конкретные ссылки
Подтверждение чего? Если про первое, почитайте на сайте MPTCP как он работает, или сами соберите ядро и проверьте. Он отлично работает в том числе и за NAT, никаких проблем (но через прокси не работает).
он прекрасно работает, также как и нативный бондинг в ядре linux, до тех пор пока у вас энтропия внешней среды не растет. каналы стабильные.
Прекрасно работает из коробки на обычных проводных каналах ПД.

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

Как я писал ранее, наблюдение за количеством ошибок интерфейса и длинной очереди — это наблюдение случившейся проблемы. Это приводит к тому, что риск безвозвратно потерянных пакетов почти 100%.

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

Локальные метрики всех интерфейсов естестсвенно мониторятся, но уже как проверочный и корректирующий, а значит вторичный механизм.

Во всех существующих системах агрегации — локальные метрики интерфейса — это первичный механизм
он прекрасно работает, также как и нативный бондинг в ядре linux, до тех пор пока у вас энтропия внешней среды не растет. каналы стабильные.
Не знаю, почему вы так решили. Бондинг совсем не подходит для комбинирования разных каналов, это верно, но MPTCP задумывался для комбинирования разных, в том числе и плохих, каналов. Его используют на iOS и некоторых моделях Samsung. Siri на iOS работает с MPTCP, объединяя Wi-Fi и LTE. В MPTCP 4 разных протокола управления потоком, по умолчанию используется не самый лучший.

Вы правильно сделали, что мониторите метрики ошибок, но это не должно быть основной идеей для балансировки между каналами. Впрочем, вы не раскрываете каких-либо деталей, чтобы об этом можно было конструктивно говорить. Я считаю, что балансировка TCP на уровне пакетов проиграет в 100% случаев локальному терминированию TCP. Китайцы, с их медленными каналами с большими потерями на запад, используют различные терминирующие прокси, реализующие свой ARQ-протокол поверх UDP, с быстрыми ретрансмиссиями, и они им сильно помогают.
Прекрасные сутевые вопросы.
Отписал в личку.
> по умолчанию используется не самый лучший.
это по каким критериям не лучший?
По «дружелюбности» к соседнему трафику («fairness»).
>почитайте на сайте MPTCP как он работает
почитайте
http://book.itep.ru/4/44/mptcp.htm
Там очень много текста, вы что-то конкретное хотите сказать? MPTCP работает с одним IP-адресом на стороне сервера.

Возможно я сейчас глупость спрошу, но тем не менее: как вы исходящий трафик балансируете более-менее ясно. А как вы решаете проблему с балансировкой обратного трафика, который возвращается от сервера к клиенту?

Это хороший вопрос.
Решается эта задача достаточно просто.
Демон-агрегатор, который обслуживает передачу трафика по разным туннелям, работает следующим образом.
1. Каждый тоннель обслуживается собственным потоком. Чтение и запись идут последовательно — это основы IP сетей.
2. Соединение части пакетов пришедших по разным туннелям, идут в другом потоке, в который они попадают через промежуточный буфер.

Отвечая на ваш вопрос, программист не заботится о том кто отвечает и кто посылает. он просто последовательно читает и пишет в поток.
Как работает туннель — понятно. Как работает IP-маршрутизация поверх 3-х туннелей — не понятно.
Если серверов аггрегации столько же сколько туннелей — тогда тоже понятно.
Если сервер аггрегации один, то не понятно.
Классический пример: BGP с двумя провайдерами… Вы можете выбрать через какого провайдера отправить пакет, но через какого он вернётся — повлиять достаточно проблематично.
Классический пример: BGP с двумя провайдерами… Вы можете выбрать через какого провайдера отправить пакет, но через какого он вернётся

В нашем случае все гораздо проще. Ответ пишется в тот-же туннель всегда.

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

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

Автор vtrunkd очень подробно описывает этот момент
смотрите сразу шаг 2

Sign up to leave a comment.