Тема: Балансировка: вечная проблема

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

Два модема от Укртела с максимальными тарифными планами, корпоративная сетка и сервер для внутренних нужд. Нужно сделать автоматическую балансировку нагрузки по каналам. Из всех исследований, которые я проводил на протяжении длительного времени я сделал вывод, что без гемора не возможно сделать балансировку, а нормальную балансировку сделать вообще не возможно (чтобы учитывалась загрузка канала), тем более оборудованием для SoHo.

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

Что я придумал:
На сервере поднять DHCP, который бы выдавал клиентам адреса одного диапазона (192.168.5.ххх маска 255.255.255.0) но случайным образом выдавал бы один из двух адресов шлюзов. (сревер на убунте, предположительно, или на другом линуксе, но не венда). Причём выдавать короткосрочную аренду. Чтобы клиенты чаще обращались за адресами.

В сети процентов 65 венды, 15 линух и 20 макось.

Сможет ли такая система удовлетворять требованиям и как так настроить DHCP?
Можно ли как-то контролировать при такой системе сколько клиентов на каком шлюзе? Может это может быть какой-то скрипт, который считает выданные аренды и переключает адрес шлюза, который будет выдаваться следующему.
Короткосрочная аренда заставит клиента переспрашивать адрес у DHCP или клиент на это может "забить"? (короткосрочная имеется ввиду не более суток или новый адрес/шлюз при каждом подключении, заню, что в винде есть опция "предлагать ранее назначенный адрес" это не должно работать).


В принципе каждый модем имеет свой DHCP. Поэтому рассматривается ещё другой вариант:

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

В общем какие есть идеи? За и против?

А если сервер proxi поставить после модемов перед свичем, один канал инэта основной (шире) второй резервный (уже) при пропадании основного перекл на резервный. Незнаю как у кого у нас Укртелеком падает где то раз в месяц, и все исправляется передергиванием модема (иногда конечно и бинд падает).

Привет.
Понимаешь, тут и обсуждать-то нечего. ;) Это:

Сообщение от yaroslavvv

Что я придумал:
На сервере поднять DHCP, который бы выдавал клиентам адреса одного диапазона (192.168.5.ххх маска 255.255.255.0) но случайным образом выдавал бы один из двух адресов шлюзов. (сревер на убунте, предположительно, или на другом линуксе, но не венда). Причём выдавать короткосрочную аренду. Чтобы клиенты чаще обращались за адресами.

хоть и рабочая, но глупая затея.
Во-первых, исходя из специфики протокола DHCP наверняка будет продлён уже выданный адрес ;)
Во-вторых, это лишь полумера :)
Не знаю, может что-то и изменилось в ядре линукса в плане баллансировки с 2004-го года ;)... Опишу по шагам...
После того как, в своё время, был прочитан LARTC было найдено решение описанной тобой проблемы, но... Тогда я столкнулся с неприятной штукой, с сервера балансировка работала отлично, а вот для клиентов сети выливалась неприятными боками. Объясню вкратце: tcp-сессия могла начаться на одном канале, с одним реальным ip, а закончиться на другом, с совершенно другим реальным ip. Естественно, что в момент смены адреса источника сессия затыкалась вовсе, так как дестинейшену просто непонятно, что реально это одна и та-же сессия, ведь продолжалась она с разных ip соурса (клиенты то у нас за маскарадом?). Сумбурно, но где-то так. В далёком 2004-м вышел из положения следующим образом. Поставил Squid и прозрачно проксировал все запросы к ftp и web, а ведь именно это основной поток трафика. В итоге все соединения с дестинейшеном инициировались самим сервером и разрыва сессий не происходило ;) Минус тут огромный именно в самом наличии Squid'а... зачем нам этот лишний монстр и дополнительная нагрузка на сервер? ;) Потом мы получили AS, подняли BGP, клиентам раздали реальные ip и описанная проблема решилась сама-собой. ;)
Теперь вот какие мысли.
Первая. На Cisco есть такая штука как ip cef. После её включения вполне нормально проходит баллансировка между двумя провайдерами, двумя разными ip с соурса, так как ip cef помогает отслеживать сессии и весь трафик в пределах одной сессии не рвётся на разных каналах.
Вторая. В Linux'е есть такая мощная штука как conntrack, также позволяющая отслеживать сессии. Т.е. получается, что нам её надо задействовать. Как это сделать? Достаточно просто, просто упомянув её в правилах iptables'а, например так:

Код:

-A FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m conntrack --ctstate NEW -j netbios_in_reject
-A FORWARD -m conntrack --ctstate NEW -s 192.168.0.0/24 -i eth0 -o eth1 -j ACCEPT
-A FORWARD -m conntrack --ctstate NEW -d 192.168.0.0/24 -o eth0 -i eth1 -j ACCEPT
-A FORWARD -m conntrack --ctstate NEW -s 192.168.0.0/24 -i eth0 -o eth2 -j ACCEPT
-A FORWARD -m conntrack --ctstate NEW -d 192.168.0.0/24 -o eth0 -i eth2 -j ACCEPT
-A FORWARD -j LOG
-A FORWARD -j DROP
-A netbios_in_reject -p tcp -m tcp --dport 135:139 -j reject_func 
-A netbios_in_reject -p udp -m udp --dport 135:139 -j reject_func 
-A netbios_in_reject -p tcp -m tcp --dport 445 -j reject_func
-A reject_func -p tcp -j REJECT --reject-with tcp-reset 
-A reject_func -p udp -j REJECT --reject-with icmp-port-unreachable 
-A reject_func -j REJECT --reject-with icmp-proto-unreachable

Оффтоп

Кстати, через состояние UNTRACKED можно организовать, к примеру, эффективный фильтр против Китая и прочего нежелательного трафика ;)

Код:

sudo iptables -t raw -N nochina
sudo iptables -I INPUT -m conntrack --ctstate UNTRACKED -j DROP
sudo iptables -I FORWARD -m conntrack --ctstate UNTRACKED -j DROP
sudo iptables -t raw -A nochina -s 58.16.0.0/13 -j NOTRACK
sudo iptables -t raw -A nochina -s ... и т.д. ... -j NOTRACK

Взять списки можно тут www.find-ip-address.org

Потом делаем что-то наподобие:

Код:

# echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter
# echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter
# ip r r default \
        nexthop via NN.NN.NN.NN dev eth1 weight 50 \
        nexthop via MM.MM.MM.MM dev eth2 weight 50

"Играясь" со значением веса можно отдать предпочтение одному или другому каналу. ;)

Ну где-то так...

ps: Естественно никто не избавляет от необходимости нарисовать подробные правила для цепочек INPUT и OUTPUT, а так-же FORWARD, в таблице filter для iptables, но это выходит за пределы данной дискуссии.

пс: Интерфейсы eth0, eth1 и eth2 использованы исключительно для примера, любое совпадение с действительностью случайно ;) А вдруг у тебя не eth, а vlan или ppp, так что... ;)

зы: А модемы я действительно бы перевёл в режим моста и соединения поднимал с сервера ;)

Сообщение от mlx

Идея интересная, но крайне инертная. Любой из пользователей одного из шлюзов может полностью утилизировать его своим торрент-клиентом, например. В общем, на мой взгляд, идея скорее более интересна с точки зрения упражнений в скриптинге:).

Да там скриптов рисовать не надо... ;)
А настроить баллансировку гораздо интереснее на какой-нибудь киске... ;) На той-же, кстати, 871-й ;)

Сообщение от mlx

Идея интересная, но крайне инертная. Любой из пользователей одного из шлюзов может полностью утилизировать его своим торрент-клиентом, например. В общем, на мой взгляд, идея скорее более интересна с точки зрения упражнений в скриптинге:). Однозначно оба шлюза должны быть включены в устройство, которое может управлять траффиком к ним - это может быть коммутатор с VRRP, но мне кажется что тут лучше использовать программный роутер с iptables и iproute2 - где-то тут обсуждались варианты балансировки с весовыми коэффициентами двух таблиц маршрутизации, да и вообще... - фантазировать можно сколько угодно. А вот более правильным решением было бы иметь на обоих каналах BGP4 и балансировать нагрузку по-настоящему, но увы - Укртелеком...

Идея в том, чтобы довести до ума то, что есть с тем оборудованием, что есть. А есть два ADSL+WiFi модема (zyxel и dlink), свитчи и компьютер.
Текущая конфигурация сети с натяжкой устраивает. Просто нет связи между сетями, ну и не кошерно это, то, что есть. Хочется сделать красивее.

Сообщение от Zorge

А если сервер proxi поставить после модемов перед свичем, один канал инэта основной (шире) второй резервный (уже) при пропадании основного перекл на резервный. Незнаю как у кого у нас Укртелеком падает где то раз в месяц, и все исправляется передергиванием модема (иногда конечно и бинд падает).

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

Оффтоп

Сообщение от yaroslavvv

О каком резерве можно говорить имея два канала от одного провайдера?

Хочется поделится просто наблюдением.
В конторе 2 инэта оба от Укртелекома один (основной со статическим IP) второй резервный (с динамическим IP) оба живут на одном шкафу тел №№ 49-**-**
Так вот тот что со статическим падает на порядок реже (уж не знаю по какой причине, то ли Укртелеком за ним лучше следит, то ли планеты так сошлись).
Просто Вам как информация к размышлению.

И еще все таки прячьте все за proxi.

Сообщение от oldengremlin

Привет.
Понимаешь, тут и обсуждать-то нечего. ;) Это:хоть и рабочая, но глупая затея.
Во-первых, исходя из специфики протокола DHCP наверняка будет продлён уже выданный адрес ;)
Во-вторых, это лишь полумера :)
Не знаю, может что-то и изменилось в ядре линукса в плане баллансировки с 2004-го года ;)... Опишу по шагам...

[SKIP]

ps: Естественно никто не избавляет от необходимости нарисовать подробные правила для цепочек INPUT и OUTPUT, а так-же FORWARD, в таблице filter для iptables, но это выходит за пределы данной дискуссии.

пс: Интерфейсы eth0, eth1 и eth2 использованы исключительно для примера, любое совпадение с действительностью случайно ;) А вдруг у тебя не eth, а vlan или ppp, так что... ;)

зы: А модемы я действительно бы перевёл в режим моста и соединения поднимал с сервера ;)

Да там скриптов рисовать не надо... ;)
А настроить баллансировку гораздо интереснее на какой-нибудь киске... ;) На той-же, кстати, 871-й ;)

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

На счёт глупой затеи: если был бы уверен, то не задавал бы вопросов. А так понятно, что у предложенных мною вариатов есть масса недостатков.

Немного не понял на счёт Китая и нежелательного трафика. Имеется ввиду трафик с ботнетов, спамерский, вирусный и прочая с заведомо "левых" сегментов сети?

По поводу сайта www.find-ip-address.org: на сколько этой информации можно доверять? Т.е. на сколько я могу быть уверен, что, скажем, в списке украинских адресов присутствуют только украинские адреса и присутствуют _все_ украинские адреса? Они наверное берут эту информацию с каких-то публичных достоверных источников о маршрутизации между провайдерами? Это же общедоступно, вроде как?

Ну а теперь непосредственно по делу:

вариант со сквидом нас спасает только отчасти, так как у нас некоторую (очень не малую) долю трафика составляет svn, скайп аудио/видео, трафик к удалённым БД, SSH, SCP и прочее специфичное.

Предложенный вариант с маршрутизатором и двумя внешними каналами у него мне очень по душе и это наверняка самый "кошерный" но тут появляются следующие "НО":

во-первых когда мы пытались что-то подобное настроить на вендовом сервере, то была проблема с VPN (PPTP) сквозь всё это. Он просто не работал. Постоянно обрывался. После некоторых шаманств с размером MTU и ещё чем-то удалось настроить работу одной сессии в один момент. Остальные курили. Не будет ли такого с данной реализацией?

во-вторых (это самое интересное) модемы у нас вместе с вайфаЁм. И пловина народу сидит именно на вайфае. Поэтому поставив модемы "с другой стороны" от кабельной сети мы ещё разделим кабельные и беспроводныек соединения. На сколько усложнится система, если учесть этот фактор?

Чёрными стрелками показал излишний трафик, котоый в этом случае должен будет идти с модема в сервер и потом обратно.
Пунктиром — WiFi

Отдельно хотел обсудить подключение модемов мостом или маршрутизатором. Учитывая моё "во-вторых" если модем будет настроен как мост, то любой, кто подключается вайфаем, будет наблюдать иконку в "мой компьютер" о существующем соединении с инетом, правда они не знают паролей и подключиться всё равно не смогут, но как-то не красиво.
Следующий вариант — всё таки паразитного трафика действительно в сети много и так от него отбивается модем самостоятельно, а так эти все какашки будут попадать на сервеер. И как следствие лишняя нагрузка интерфейса, который и так уже будет излишне нагружен двойной циркуляцией по вайфаю. Ну и локальными соединениями вайфайщиков в проводную сеть. (или это можно как-то всё таки организовать иначе? модемы, сервер и проводных клиентов воткнуть всё таки с одной и той же стороны?)
Ну и вопрос защиты, конечно. Так или иначе в ОС находятся уязвимости. И на сервере прийдётся городить лишние огороды, когда модемы ввиду их функциональной ограниченности более стабильны в этом плане. Или это не более, чем мои фантазии?

Сообщение от mlx

1 - современные линуховые ядра умеют нормально натить впн-соединения через себя
2 - на стоимость апешки, потому что не получится организовать нормальное подключение клиентов к вай-фаю рутеров, ну разве что только если кроме инета им совсем ничего не надо будет

По первому вопросу понятно.
А по второму я не был бы так категоричен. Не получится и будет не красиво это разные вещи. Это всё реально. Клиенты подключаются по WiFi, получают адреса с адресом шлюза, который присвоен серверу. Т.е. перый этам пройден — трафик на все не "соседние" адреса будет посылаться через сервер. Далее на сервере эта же сетевая карта будет иметь второй интерфейс с адресом из другой сети, в которой же будут находиться и модемы.
просто это всё не красиво из-за избыточного трафика, который через вайфай и локальный порт модема будет идти в сервер, потом обрабатываться на сервере и идти на тот же модем обратно или на другой модем. Но так как инет только 8 мегабит на всех, то запас "прочности" имеется. Да, это немного не красиво, но это НЕ невозможно.

PS Кстати тоже интересный вопрос: какое количество трафика сможет обрабатывать программный макршрутизатор? На сколько мне известно ни о каких 100 мегабитах речь даже близко идти не может. Помнится мы хотели слинковать две сети (по 250 хостов в каждой) маршрутизатором программным или аппаратным. И нас отговорили, мол, программный точно не вытянет и близко, а аппаратные только несколько дорогущих моделей. Требовалась именно маршрутизашия на "третьем уровне". У кого есть данные о подобных тестах?

Отвечает Александр Русских?

Сообщение от yaroslavvv

А по второму я не был бы так категоричен. Не получится и будет не красиво это разные вещи. Это всё реально. Клиенты подключаются по WiFi, получают адреса с адресом шлюза, который присвоен серверу. Т.е. перый этам пройден — трафик на все не "соседние" адреса будет посылаться через сервер. Далее на сервере эта же сетевая карта будет иметь второй интерфейс с адресом из другой сети, в которой же будут находиться и модемы.
просто это всё не красиво из-за избыточного трафика, который через вайфай и локальный порт модема будет идти в сервер, потом обрабатываться на сервере и идти на тот же модем обратно или на другой модем. Но так как инет только 8 мегабит на всех, то запас "прочности" имеется. Да, это немного не красиво, но это НЕ невозможно.

Возможно.... Всё возможно... Даже можно и без бриджа. Просто настроить на модемах, если это возможно маршрутизацию. Клиентов Wi-Fi в отдельные подсети, запретить прямой выход в Инет. С поднятого соединения DMZ на сервер. Но... Не кошерно это...

Сообщение от yaroslavvv

PS Кстати тоже интересный вопрос: какое количество трафика сможет обрабатывать программный макршрутизатор? На сколько мне известно ни о каких 100 мегабитах речь даже близко идти не может. Помнится мы хотели слинковать две сети (по 250 хостов в каждой) маршрутизатором программным или аппаратным. И нас отговорили, мол, программный точно не вытянет и близко, а аппаратные только несколько дорогущих моделей. Требовалась именно маршрутизашия на "третьем уровне". У кого есть данные о подобных тестах?

Кто-то захотел заработать денег...
В принципе возможно. Просто опять-таки классифицировать трафик, поставить его в разную полосу пропускания и приоритеты. Но... Этим надо заниматься и в двух словах не расскажешь ;) Относительно классификации, под Linux есть замечательный инструмент tcng позволяет красиво описать правила, а затем получить директивы для tc... Но это выходит за пределы данного топика ;) Почитать можно тут unixforum.org.

Сообщение от yaroslavvv

Отвечает Александр Русских?

Не понял, имеет какое-то значение, кто именно отвечает?