IPVS

IPVS — это модуль балансировки нагрузки на уровне ядра операционной системы Linux, входящий в состав проекта Linux Virtual Server (LVS). Он реализует распределение входящих сетевых запросов между несколькими серверами (реальными серверами) на основе правил, определённых администратором, и работает на транспортном уровне (4-й уровень модели OSI), обрабатывая протоколы TCP и UDP.

История

Разработка IPVS началась в конце 1990-х годов в рамках проекта Linux Virtual Server, основанного Уэньцзуном Чжаном (Wensong Zhang) из Национальной лаборатории программного обеспечения Китая. Первые версии были включены в ядро Linux начиная с версии 2.4.0 (2001 год). Изначально IPVS позиционировался как решение для построения высоконагруженных веб-кластеров, способных обрабатывать миллионы запросов в секунду.

С течением времени функциональность модуля расширялась: были добавлены поддержка IPv6, механизмы сохранения сессий (persistence), алгоритмы взвешенного распределения нагрузки и интеграция с современными сетевыми технологиями, такими как VXLAN и Geneve. IPVS остаётся частью основного ядра Linux и поддерживается сообществом разработчиков.

Архитектура и принцип работы

IPVS работает в пространстве ядра (kernel space) и обрабатывает сетевые пакеты до того, как они достигнут пользовательского пространства. Система состоит из трёх основных компонентов:

• Балансировщик (Director) — сервер, на котором запущен IPVS. Он принимает входящие запросы от клиентов и перенаправляет их на один из реальных серверов.
• Реальные серверы (Real Servers) — серверы, которые фактически обрабатывают запросы (например, веб-серверы, базы данных).
• Виртуальный сервер (Virtual Server) — абстрактная сущность, определяющая IP-адрес и порт, которые балансировщик слушает для приёма запросов. Каждому виртуальному серверу назначается один или несколько реальных серверов.

При поступлении пакета на виртуальный сервер IPVS применяет заданный алгоритм планирования (scheduling algorithm) для выбора реального сервера, которому будет передан запрос. Затем пакет модифицируется (например, заменяется IP-адрес назначения) и отправляется на выбранный сервер. Ответ от реального сервера может проходить обратно через балансировщик (в режимах NAT и TUN) или напрямую клиенту (в режиме DR).

Режимы работы

IPVS поддерживает три основных режима перенаправления трафика, отличающихся способом обработки пакетов и требованиями к сети:

NAT (Network Address Translation)

Балансировщик заменяет IP-адрес назначения в пакете на адрес выбранного реального сервера. Ответ от сервера также проходит через балансировщик, который заменяет обратный адрес на адрес виртуального сервера. Этот режим прост в настройке, но создаёт узкое место на балансировщике, так как через него проходит как входящий, так и исходящий трафик. Реальные серверы могут находиться в одной локальной сети с балансировщиком и использовать частные IP-адреса.

DR (Direct Routing)

Балансировщик изменяет MAC-адрес назначения в пакете на MAC-адрес выбранного реального сервера, но оставляет исходный IP-адрес назначения (адрес виртуального сервера) без изменений. Реальные серверы должны быть настроены на приём пакетов, адресованных виртуальному серверу (например, с помощью добавления псевдонима IP-адреса на loopback-интерфейс). Ответы от серверов отправляются напрямую клиенту, минуя балансировщик, что снижает нагрузку на последний. Этот режим требует, чтобы все реальные серверы находились в одном широковещательном сегменте сети с балансировщиком (или использовали маршрутизацию с поддержкой ARP).

TUN (IP Tunneling)

Балансировщик инкапсулирует исходный пакет в новый IP-пакет (с использованием IP-туннелирования, обычно IPIP) и отправляет его на выбранный реальный сервер. Сервер декапсулирует пакет и обрабатывает его. Ответы отправляются напрямую клиенту. Этот режим позволяет размещать реальные серверы в разных сетях (в том числе в разных географических регионах), но требует настройки туннелей на серверах.

Алгоритмы планирования

IPVS предоставляет более десятка алгоритмов распределения запросов, которые можно разделить на статические и динамические.

Статические алгоритмы

• Round Robin (rr) — запросы распределяются по кругу, каждому серверу по очереди.
• Weighted Round Robin (wrr) — то же, но с учётом веса сервера (больший вес получает больше запросов).
• Source Hashing (sh) — сервер выбирается на основе хеша от IP-адреса источника, что обеспечивает привязку запросов одного клиента к одному серверу.
• Destination Hashing (dh) — сервер выбирается на основе хеша от IP-адреса назначения.

Динамические алгоритмы

• Least Connections (lc) — запрос направляется серверу с наименьшим количеством активных соединений.
• Weighted Least Connections (wlc) — то же, но с учётом веса сервера.
• Shortest Expected Delay (sed) — выбирается сервер с наименьшим ожидаемым временем ожидания (средняя длина очереди, делённая на вес).
• Never Queue (nq) — если сервер свободен, запрос направляется ему, иначе используется алгоритм SED.
• Locality-Based Least Connections (lblc) — для кластеров кэширующих прокси-серверов; запросы от одного клиента направляются одному серверу, если это возможно.
• Locality-Based Least Connections with Replication (lblcr) — расширение lblc с возможностью репликации данных между серверами.

Настройка и управление

Управление IPVS осуществляется через утилиту ipvsadm, которая предоставляет интерфейс командной строки для добавления, удаления и модификации виртуальных серверов и реальных серверов, а также для просмотра статистики.

Пример базовой настройки:

1. Создание виртуального сервера: ipvsadm -A -t 192.168.1.100:80 -s rr
2. Добавление реальных серверов: ipvsadm -a -t 192.168.1.100:80 -r 10.0.0.1:80 -m (режим NAT)
3. Просмотр текущего состояния: ipvsadm -L -n

Параметры настройки включают:

• Виртуальный адрес и порт (TCP, UDP, SCTP).
• Режим перенаправления (NAT, DR, TUN).
• Алгоритм планирования.
• Вес сервера (для взвешенных алгоритмов).
• Порог соединений (для ограничения нагрузки на сервер).
• Тайм-ауты для различных типов соединений.

Применение

IPVS широко используется для построения отказоустойчивых и масштабируемых серверных кластеров. Основные области применения:

• Веб-кластеры — распределение HTTP/HTTPS-запросов между несколькими веб-серверами (например, Nginx, Apache).
• Балансировка нагрузки баз данных — распределение запросов к MySQL, PostgreSQL или другим СУБД.
• Почтовые серверы — балансировка SMTP, IMAP, POP3-трафика.
• Кластеры кэширования — распределение запросов между серверами Memcached или Redis.
• Прокси-серверы и шлюзы — балансировка трафика через несколько прокси (например, Squid).

IPVS часто используется в сочетании с инструментами мониторинга и автоматизации, такими как Keepalived (для обеспечения высокой доступности балансировщика) и Pacemaker (для управления кластером).

Преимущества и недостатки

Преимущества

• Высокая производительность — работа на уровне ядра Linux обеспечивает минимальные накладные расходы и высокую пропускную способность.
• Низкая задержка — обработка пакетов происходит без переключения в пользовательское пространство.
• Поддержка большого количества протоколов и алгоритмов — гибкость настройки под различные сценарии.
• Открытый исходный код — IPVS является частью ядра Linux и не требует лицензионных отчислений.
• Интеграция с другими инструментами — совместимость с Keepalived, Pacemaker, iptables/nftables.

Недостатки

• Ограниченная гибкость на транспортном уровне — IPVS не может анализировать содержимое пакетов (например, HTTP-заголовки), что делает его непригодным для балансировки на уровне приложений (7-й уровень OSI).
• Сложность настройки режима DR — требует специальной конфигурации сетевых интерфейсов на реальных серверах.
• Отсутствие встроенного мониторинга здоровья серверов — для автоматического исключения неработающих серверов необходимо использовать внешние инструменты (например, Keepalived).
• Зависимость от ядра Linux — IPVS не работает на других операционных системах.

Сравнение с другими решениями

IPVS часто сравнивают с пользовательскими балансировщиками, такими как HAProxy, Nginx и Envoy. Основное отличие — IPVS работает в пространстве ядра, что обеспечивает более высокую производительность и меньшую задержку, но ограничивает функциональность. HAProxy и Nginx, работающие в пользовательском пространстве, могут анализировать HTTP-заголовки, выполнять проверки состояния серверов и поддерживать более сложные сценарии маршрутизации, но уступают IPVS в скорости обработки сырого трафика.

В современных высоконагруженных системах часто используется комбинированный подход: IPVS применяется для первичного распределения трафика на уровне транспортного протокола, а HAProxy или Nginx — для более тонкой балансировки на уровне приложений.

Источники

• Wensong Zhang, "Linux Virtual Server Project", официальная документация проекта LVS.
• Документация ядра Linux: Documentation/networking/ipvs-sysctl.txt.
• Man-страницы: ipvsadm(8).
• Книга: "Linux Kernel Networking: Implementation and Theory" by Rami Rosen (Apress, 2014).
• Статья: "Performance Comparison of Linux Virtual Server vs. HAProxy" (Linux Journal, 2016).