Как стать автором
Обновить

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

Интересно, спасибо!
Спасибо, очень интересная статья! В свое время именно из-за таких сайтов, реагирующих на смену IP отказался от двух каналов, надоело прописывать их в списки исключения. По поводу разделения трафика была идея, но реализовать ее не получилось корректно… Ждем статью и про динамический шейпинг!
Разделение трафика по портам не напоминает костыль? А если один канал упадет?

Может лучше поднять на обоих каналах ВПН с каким-то сервером в ДЦ, который падает крайне редко (и имеет канал шире, чем суммарный в офисе) и пустить трафик через него?

Тогда не будет проблемы с ip и будет защита от падения канала, заодно и нормальное распределение нагрузки (ваш канал забьется, если все неожиданно начнут вместо торрентов видео какое-то на ютубе смотреть).
ВПН до еще одного сервера, это по моему еще больший костыль.
Тогда уж логичнее BGP и AS.
ВПН универсальне. Я такую схему баллансировки рассматривал при попытке собрать из нескольких телефонов с GPRS и 3G модемов портативную станцию для мобильного интренета с максимальной скоростью.

BGP это точно такая-же схема, как и ВПН по логике, только маршрутизатор стоит не в офисе, а в качественном датацентре. Но могут быть сложности, при попытке собрать ВГП на основе домашних провайдеров, 3G модемов и подобной мешанины (по факту, эта мешанина может быть надежнее резерва от корпоративного провайдера средней руки за счет отсуствия единой точки отказа). ВПН к удаленному серверу будет через что угодно работать.
Некоторые клиенты отказываются работать через туннель, например банки с их IPsec.
Даже, если тунель не на тех машинах, где стоит клиент, а где-то на шлюзе?
Думаю будут сложности с MTU, точно не уверен — не тестировал в таком режиме. Почитать можно тут.
Разве рутер не должен реассемблить пакеты?
ВGP не позволит выполнить точную балансировку (обычно сетки меньше чем с 24 маской не позволяют раздавать), плюс некоторая инерционность метода.
Решение для большого количества абонентов, когда начинает работать статистика и к примеру 1000 абонентов не начнут одновременно смотреть ютуб. У меня днем распределяемый трафик (торренты) составляет 25-30% от общей полосы, что вполне достаточно для выравнивания нагрузки учитывая что абоненты предварительно распределены по каналам.
grep для строки, а не регэкспа? Почему не fgrep?
Думаю не критично, но с замечанием согласен, спасибо, учту.
Балансировка IP-пакетов через линукс — это всегда такой костыль… который работает лишь до достижения определенного объема трафика, а потом наступает северный пушной зверек.
Самое лучшее, что можно сделать в таком случае — это использовать BGP+аналитику
1. Устанавливаем BGP сессии по всем доступным каналам с fullview
2. Дампим трафик и узнаем, на какие автономные сети или просто сети идет больше всего траффика.
3. эти сетии группируем по кол-ву каналов так, чтобы маршрут до каждой сети был самым коротким по AS-path
т.е. если допустим по одному каналу сеть 1.0.0.0/24 видна через 3 автономки, а по второму каналу через 6 автономок, то пихать мы будем эту сеть в группу для второго канала. Это не обязательно, но очень желательно, дабы уменьшить задержки на траффик.
4. формируем префикс листы для приема траффика для каждого канала — так мы сбалансируем исходящий трафик
для балансировки исходящего трафика так же надо будет проводить аналитику, но это слишком долго описывать в рамках одного коммента.
поправка, дампим не траффик, а собираем по netflow
Думаю каждое решение существует для определенных условий. Что будет если 5-6 каналов? Принимать 6 таблиц fullview? Каковы действия если добавится еще канал? Надо будет заново составлять аналитику?
Согласен если каналы не подвергаются особым изменениям, предложенный Вами метод более чем приемлем.
Интересует значение «определенного объема трафика», скажем 4Гб/с это ниже этого значения?
6 таблиц фулвью тоже реально, главное оперативной памяти побольше =) Аппаратные железки вроде циски хорошо жуют подобное, а для большого траффика они в самый раз, никакой сервак не сравнится.
Аналитику надо проводить скриптом пару раз в месяц и при подкючении нового канала.
Определенный объем трафика скорее зависит от типа трафика и кол-ва пакетов. Вот если вы еще мультикаст начнете гонять — станет совсем все печально, ну или множество мелких фрагментированных пакетов обрабатывать\собирать. Но вообще 4 Гб/с(т.е. 2Гб/с на вход и 2Гб/с на выход) линукс точно прожует на какой-нибудь многопроцессорной дуре. Но все равно он будет слабее аппаратной железки, скажем циски 6500/7600 с sup720
В моем случае трафик 3.2Гб/с на вход и 3.2Гб/с на выход на одной сетевой, на второй около 1Гб/с туда и обратно, сервер однопроцессорный, проц — Intel Xeon 4х3.4Ghz, загрузка — 70%. На сервере NAT, BGP, OSPF.
70% — это уже псц, наверняка задержки через этот сервер выростают в районе 5мс. я писал про фулдуплекс на вход\выход. в смысле сколько трафика сервак принимает и отдает в одну сеть и в другие.
в пределах 0,5мс
+не надо забывать про задержки, вносимые на проходящий траффик. Линукс — это же софтроутер, так что не стоит ждать от него чудес.
еще одна опечатка:
>для балансировки исходящего трафика так же надо будет проводить аналитику,
для балансировки входящего трафика так же надо будет проводить аналитику,
Есть операционная система RouterOS (MikroTik), на базе Linux, в ней можно сделать балансировку нагрузки с помощью PCC (Per Connection Classifier). Это позволяет с легкостью создать правила подключения клиентов. Думаю в вашем случае подойдет «src address», чтоб не было проблем типа «запрос шел через другой канал». То есть, если клиент попал при подключении на первый канал, он будет оставаться на нём до конца сессии. Документация нам говорит, что таймаут выбирается ядром Linux. Еще можно выбрать тип «dst address» или «both address» (в этом случаи балансировка будет равномерней), тогда если абонент зайдёт на habrahabr.ru, то он пойдет по первому каналу и будет на нем оставаться до смены адреса, а если зайдет на google.com, то по второму (каждый новый dst. адрес — другой канал). Во всех случаях когда адрес не меняется, клиент не будет перебрасываться на другую линию. Реализация этого механизма возможна на Ubuntu, так-как это тоже Linux-based Operating System. Кому интересно вот ссылка на WiKi MikroTik по этой теме PCC. Если кто-нибудь сделает скрипт под Ubuntu, это было бы очень не плохо.
Спасибо за ссылку, весьма познавательно.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории