Linux load balancing network
В Linux load balancing может заключаться в распределении запросов пользователей по серверам — web или почтовым серверами.
Также load balancing может быть на уровне сети. Он будет рассмотрен далее. В частности подключение локальной сети к двум провайдерам одновременно.
Схему работу можно представить так:
Local Network — Router — Provider1
Принцип маршрутизации трафика неизменен. Маршрут включает в себя интерфейс на роутере, IP адрес, заданный для интерфейса и ip адрес gateway на стороне провайдера.
Правила могут иметь такой вид (имена и структура позаимствованы отсюда)
Для каждого провайдера должна быть своя таблица iptables.
Правила для входящего трафика теперь добавлены.
Правила для исходящего трафика.
Сначала определяем адрес для трафика, уходящего с определенного интерфейса.
Маршрут по умолчанию
Теперь правила маршрутизации
Получена простая схема раздельного доступа.
Настройка Linux load balancing
Сама настройка балансировки заключается в замене дефолтного маршрута правилом, дающим системе гибкость.
С данным правилом трафик будут распределяться между провайдерами с учетом весов.
«Щадящая» балансировка между несколькими провайдерами на офисном шлюзе
Эта статья описывает конфигурацию шлюза под управлением 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
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
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
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
Обратите внимание: в основную таблицу маршрутизации всё равно попадает только один 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).
# 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
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». Каждая из них отправляет пакеты с соответсвующей маркировкой на маршрутизацию в указанную таблицу. В моём примере числа перемешаны между интерфейсами ради равномерности.