Linux балансировка два канала

Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра. + 7 495 103 1508

Балансировка и резервирование каналов

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

Справедливости ради надо отметить, что данное решение можно реализовать и другими средствами( ipfw на FreeBSD,и sla и др. в cisco) , но вот так — одной командой, только на Linux. К стати, просто «гордость берет» за державу и нашего соотечественника Алексея Кузнецова — создавшего данный пакет. Но буду краток, схема:

Создаем две отдельные таблицы маршрутизации для каждого провайдера (isp1,isp2 названия таблиц маршрутизации — произвольно но лучше должны нести смысловую нагрузку — например название провайдера).

echo 200 isp1 >> /etc/iproute2/rt_tables
echo 201 isp2 >> /etc/iproute2/rt_tables

Определим политику маршрутизации (RPDB — Routing Policy DataBase, база данных политик маршрутизации, управляющая алгоритмом выбора маршрута) для пакетов пришедших с данного интерфейса( $ip1,$ip2 соответственно ip адреса интерфейсов каждого провайдера):

ip ru add from $ip1 table isp1
ip ru add from $ip2 table isp2

И настроим маршрутизацию по умолчанию( $ip1-gw,$ip2-gw соответственно ip адреса шлюзов каждого провайдера):

ip route add default via $ip1-gw table isp1
ip route add default via $ip2-gw table isp2

С этого момента мы получаем возможность распределять пакеты по любому признаку (http, www,ftp или промаркировав по своему усмотрению с помощью iptables), и по любому направлению.Но в данной статье, главная цель — балансировка нагрузки! Легким движением руки «брюки превращаются в шорты»:

ip route add default scope global equalize nexthop via $ip1-gw dev eth-isp1 weight 3 nexthop via $ip2-gw dev eth-isp2 weight 2

При этом загрузка каналов соответственно составит 3:2. Меняем параметр — weight так, как требуется( или по пропускной способности, или по стоимости. ). И наконец немного творческой работы — организация резервирования.Создадим исполняемый файл /home/balanc. И задачу на выполнение с интервалом 5 минут.

crontab -e
0-59/5 * * * * /home/balanc 2 > /dev/null

Для того что бы отслеживать состояние каналов, будем производить определение доступности шлюзов провайдеров (поскольку самым узким местом, все же является «последняя миля», хотя можно отслеживать состояние и по хостам находящимся в сети). Логика работы заключается в следующем:

отправляем icmp пакеты на шлюзы провайдеров
анализируем ответ и делаем вывод о доступности сети
сравниваем предыдущее состояние каналов записанное в файл /home/balconf ( для того, что бы лишний раз не «дергать» маршрутизацию)
выполняем установку маршрута по умолчанию

Источник

«Щадящая» балансировка между несколькими провайдерами на офисном шлюзе

Эта статья описывает конфигурацию шлюза под управлением Linux для балансировки трафика между каналами разных провайдеров.

Результат, достигаемый в этом руководстве, отличается от результата подобных руководств: для каждого клиента используется один и тот же внешний IP-адрес, что избавляет от проблем с интернет-сервисами, которые не готовы к смене IP-адреса клиента в рамках одной сессии.

Проблемы

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

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

Вторая задача, которую нужно решить, состоит в том, как разумно распределить нагрузку от клиентов.

Балансировка с использованием многолучевых маршрутов (как по ссылке в начале статьи) осуществляется по адресу назначения и не всегда выглядит привлекательным решением. Там, где стоило бы иметь одинаковый внешний адрес, у клиента в одной сессии может получиться разный и наоборот — при обращении к популярным ресурсам, все клиенты будут использовать один общий канал.

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

Инструменты

В ядре Linux есть возможность использовать одновременно несколько разных таблиц в зависимости от того, каким критериям соответствует пакет. Часто этот механизм называют policy based routing (PBR). Управление этим механизмом осуществляется через набор утилит iproute2.

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

Что же касается балансировки по отправителю, то для этого можно воспользоваться сетевым фильтром ядра — netfilter (iptables). С помощью действия HMARK мы промаркируем пакет хэшом от адреса. По критерию fwmark в правилах маршрутизации (команда ip rule) мы направим пакет в нужную таблицу маршрутизации. iproute2 и iptables здесь неплохо играют в паре.

Пример

В качестве примера возьму шлюз на базе Debian, который предоставляет доступ к интернету через три канала от двух разных провайдеров. Такой пример выбран специально, так как он рассматривает щекотливую ситуацию, когда один и тот же вышестоящий шлюз одного провайдера доступен через 2 разных провода. Описываемая конфигурация будет иметь схожий вид и во всех других debian-подобных операционных системах, включая Ubuntu.

Шлюз имеет 4 рабочих интерфейса:

Инт.	Описание	Ёмкость	Адрес	Шлюз
eth0	локальная сеть	10.0.0.1/16	—
eth1	первый канал первого провайдера	100 Мбит/с	100.1.1.92/24	100.1.1.1
eth2	единственный канал от второго провайдера	80 Мбит/с	200.2.2.22/24	200.2.2.1
eth3	второй канал первого провайдера	100 Мбит/с	100.1.1.93/24	100.1.1.1

Каждый канал подключен через обычный ethernet со статическим адресом.

Начальное состояние

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 10.0.0.1
netmask 255.255.0.0

auto eth1
iface eth1 inet static
address 100.1.1.92
gateway 100.1.1.1
netmask 255.255.255.0

auto eth2
iface eth2 inet static
address 200.2.2.22
# gateway 200.2.2.1 #correct gateway value, but commented out to avoid routing conflicts
netmask 255.255.255.0

auto eth3
iface eth3 inet dhcp
address 100.1.1.93
# gateway 100.1.1.1 # correct gateway value, but commented out to avoid routing conflicts
netmask 255.255.255.0

Как видите, только на одном из интерфейсов обозначен маршрут по умолчанию.

В /etc/sysctl.conf значение net.ipv4.ip_forward установлено равным 1. Пакет iptables-persistent установлен и содержимое файла /etc/iptables/rules.v4 таково:

Только три правила для трансляции адресов у пакетов, исходящих через три внешних интерфейса. Не принципиально использовать именно маскарад, но я остановился на нём. Поскольку в данный момент шлюз настроен только на одном интерфейсе, на деле работает только первое правило.

Правила маршрутизации

#
# reserved values
#
255 local
254 main
253 default
0 unspec
#
# local
#
#1 inr.ruhep

10 Provider1_Cable1
20 Provider2
30 Provider1_Cable2

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback
up ip route add 127.0.0.0/8 dev lo table Provider1_Cable1
up ip route add 127.0.0.0/8 dev lo table Provider2
up ip route add 127.0.0.0/8 dev lo table Provider1_Cable2

auto eth0
iface eth0 inet static
address 10.0.0.1
netmask 255.255.0.0
up ip route add 10.0.0.0/16 dev eth0 table Provider1_Cable1
up ip route add 10.0.0.0/16 dev eth0 table Provider2
up ip route add 10.0.0.0/16 dev eth0 table Provider1_Cable2

Обратите внимание: в основную таблицу маршрутизации всё равно попадает только один gateway — все директивы gateway, кроме одной, закомментированы.
Здесь дополнительные маршруты и правила оформлены директивами up, которые просто выполняют команду при поднятии интерфейса. Команды добавления маршрутов и правил сгруппированы под интерфейсами, через которые они могут быть реализованы — яснее всего это видно на примере интерфейса lo.

Перезагрузив сеть, мы можем заметить, как изменился вывод списка правил в команде ip rule list:

Соответствующую таблицу можно просмотреть командой «ip ro li table XXX».

Уже в таком положении сервер готов использовать все интерфейсы сразу. Проверим это, попробовав воспользоваться всеми интерфейсами по очереди и сверяя наблюдаемый внешней стороной адрес:

Если на внешних интерфейсах реальные «белые» адреса, то можно попробовать присоединиться к серверу, используя любой адрес — сервер будет общаться через каждый из них через правильный канал и правильного провайдера. Если всё так, то самое сложное позади.

Балансировка

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

auto eth1
iface eth1 inet static
address 100.1.1.92
gateway 100.1.1.1
netmask 255.255.255.0
up ip route add 100.1.1.0/24 dev eth1 table Provider1_Cable1
up ip route add default dev eth1 via 100.1.1.1 table Provider1_Cable1
up ip rule add from 100.1.1.92 table Provider1_Cable1
up ip rule add from 10.0.0.0/8 fwmark 10000 table Provider1_Cable1
up ip rule add from 10.0.0.0/8 fwmark 10003 table Provider1_Cable1
up ip rule add from 10.0.0.0/8 fwmark 10006 table Provider1_Cable1
up ip rule add from 10.0.0.0/8 fwmark 10009 table Provider1_Cable1
up ip rule add from 10.0.0.0/8 fwmark 10012 table Provider1_Cable1

auto eth2
iface eth2 inet static
address 200.2.2.22
# gateway 200.2.2.1 #correct gateway value, but commented out to avoid routing conflicts
netmask 255.255.255.0
up ip route add 200.2.2.22/24 dev eth2 table Provider2
up ip route add default dev eth2 via 200.2.2.1 table Provider2
up ip rule add from 200.2.2.22 table Provider2
up ip rule add from 10.0.0.0/8 fwmark 10002 table Provider2
up ip rule add from 10.0.0.0/8 fwmark 10005 table Provider2
up ip rule add from 10.0.0.0/8 fwmark 10008 table Provider2
up ip rule add from 10.0.0.0/8 fwmark 10011 table Provider2

auto eth3
iface eth3 inet dhcp
address 100.1.1.93
# gateway 100.1.1.1 # correct gateway value, but commented out to avoid routing conflicts
netmask 255.255.255.0
up ip route add 100.1.1.0/24 dev eth3 table Provider1_Cable2
up ip route add default dev eth3 via 100.1.1.1 table Provider1_Cable2
up ip rule add from 100.1.1.93 table Provider1_Cable2
up ip rule add from 10.0.0.0/8 fwmark 10001 table Provider1_Cable2
up ip rule add from 10.0.0.0/8 fwmark 10004 table Provider1_Cable2
up ip rule add from 10.0.0.0/8 fwmark 10007 table Provider1_Cable2
up ip rule add from 10.0.0.0/8 fwmark 10010 table Provider1_Cable2
up ip rule add from 10.0.0.0/8 fwmark 10013 table Provider1_Cable2

Для каждого интерфейса добавились строчки вида «up ip rule add from 10.0.0.0/8 fwmark MARK table TABLE». Каждая из них отправляет пакеты с соответсвующей маркировкой на маршрутизацию в указанную таблицу. В моём примере числа перемешаны между интерфейсами ради равномерности.

Источник

Linux балансировка два канала

IP-Балансировка: объединяем несколько интернет-каналов в один

Содержание

Цели и средства

Способ 1

Способ 2

Способ 3

Установка

IP-Балансировка: объединяем несколько интернет-каналов в один

Содержание

Цели и средства

Способ 1

Способ 2

Способ 3

Установка