VC5

Этот README в настоящее время обновляется с учётом последних изменений – некоторая информация может не соответствовать текущей кодовой базе. Эта итерация кода ещё не готова к бою – используйте релиз v0.2 для production.

Горизонтально масштабируемый L4-балансировщик нагрузки с прямым ответом сервера (DSR) для Linux, использующий XDP/eBPF.

Если вы считаете, что это может быть полезно, или у вас есть вопросы/предложения, свяжитесь со мной по адресу [email protected] или создайте issue на GitHub.

Теперь поддерживается IPv6 и распределение на 3-м уровне (AKA туннелирование)! Библиотека XVS была обновлена, чтобы включить эти функции, а также избавляет от необходимости запускать проверки работоспособности из сетевого пространства имён, что значительно упрощает код. Это положит конец требованию, чтобы все бэкенды находились в одной VLAN с балансировщиком.

Текущие ограничения кода не позволяют включать туннелирование для отдельных служб. Использование опции -tunnel позволяет глобально включить туннелирование на 3-м уровне с использованием одной схемы (IP-in-IP, GRE, FOU или GUE). В будущем код будет обновлён, чтобы туннелирование можно было настраивать на уровне службы.

Балансировка нагрузки на 2-м уровне по-прежнему будет поддерживаться – основной причиной запуска проекта было отсутствие поддержки 2-го уровня в балансировщике Katran от Facebook.

Пример конфигурационного файла IPv6/L3 включён – более подробная документация появится позже.

О проекте

VC5 – это сетевой балансировщик нагрузки, предназначенный для замены устаревших аппаратных устройств. Он позволяет распределять службы с виртуальными IP-адресами (VIP) по наборам серверов бэкенда («реальных»). Реальные серверы могут либо сами запускать службы, либо действовать как прокси для другого уровня серверов (например, HAProxy, выступающий в роли HTTP-маршрутизатора 7-го уровня/разгрузчика SSL, когда необходимо принимать решения на уровне приложений). Единственное требование – VIP-адреса должны быть настроены на loopback-устройстве на каждом реальном сервере, например: ip addr add 192.168.101.1/32 dev lo

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

Теперь поддерживается распределение трафика как на 2-м, так и на 3-м уровне. Распределение на 2-м уровне требует, чтобы реальные серверы находились в одной VLAN с балансировщиком; при получении пакета для распределения балансировщик обновляет аппаратные адреса Ethernet в пакете, устанавливая MAC-адрес реального сервера как адрес назначения, а свой MAC-адрес как адрес источника, и пересылает пакет через соответствующий интерфейс, обновляя идентификатор VLAN 802.1Q, если пакеты имеют теги VLAN.

Распределение на 3-м уровне требует инкапсуляции пакетов в туннельный протокол, адресованный IP реального сервера, и пересылку через маршрутизатор (если только сервер и балансировщик не находятся в одной VLAN). Если при инкапсуляции пакет превышает максимальный размер передачи в сети, то источнику отправляется ICMP-сообщение с рекомендацией подходящего MTU. Серверы бэкенда должны только декапсулировать пакеты – двустороннее туннелирование с балансировщиком не требуется.

Один сервер с сетевым интерфейсом 10 Гбит/с должен быть способен поддерживать HTTP-службу с пропускной способностью более 100 Гбит/с на исходящем трафике благодаря асимметричной природе большинства интернет-трафика. Для небольших служб одной-двух скромных виртуальных машин, вероятно, будет достаточно для обслуживания службы, генерирующей несколько гигабит/с исходящего трафика.

Если одного экземпляра недостаточно, можно добавить больше серверов для горизонтального масштабирования ёмкости (и обеспечения избыточности), используя функцию ECMP вашего маршрутизатора. Поддерживаются агрегированные интерфейсы 802.3ad и транки VLAN 802.1Q (см. каталог examples/).

Никаких модулей ядра или сложных настроек не требуется, хотя для достижения наилучшей производительности рекомендуется драйвер сетевой карты с поддержкой режима XDP native (например: mlx4, mlx5, i40e, ixgbe, ixgbevf, nfp, bnxt, thunder, dpaa2, qede). Полный список доступен на странице поддержки драйверов проекта XDP.

Цели/статус

• ✅ Простое развёртывание с помощью одного бинарного файла
• ✅ Стабильный выбор бэкенда с помощью хэш-алгоритма Maglev
• ✅ Автоматическая инъекция маршрутов здоровья; нет необходимости в запуске другого ПО, такого как ExaBGP
• ✅ Минимальное вмешательство; не требует изменения правил iptables на балансировщике
• ✅ Не требуется модификация серверов бэкенда, кроме добавления VIP на loopback-устройство/терминации туннеля при L3-распределении
• ✅ Проверки работоспособности выполняются по VIP на серверах бэкенда, а не по их реальным адресам
• ✅ Встроенные проверки работоспособности HTTP/HTTPS, половинного открытия SYN и DNS через UDP/TCP
• ✅ Коммутация пакетов в ядре с помощью eBPF/XDP; драйверы в режиме native избегают выделения sk_buff
• ✅ Поддержка нескольких VLAN
• ✅ Поддержка нескольких сетевых карт для приложений с низкой пропускной способностью/разработки
• ✅ Тегированные / агрегированные сетевые устройства для обеспечения высокой доступности / высокой пропускной способности
• ✅ Наблюдаемость через веб-консоль, ведение журналов в Elasticsearch (в разработке) и метрики Prometheus
• ✅ Поддержка IPv6 и возможность использовать бэкенды на IPv4 и IPv6 с любым типом VIP.
• ✅ Распределение трафика на 3-м уровне с поддержкой IP-in-IP, GRE, FOU и GUE.

Быстрый старт

Для достижения наилучших результатов следует отключить/удалить irqbalance.

Вам потребуется выбрать основной IP для передачи балансировщику. Он используется в качестве идентификатора маршрутизатора BGP.

Простой пример на сервере с одним нетегированным Ethernet-интерфейсом:

• apt-get install git make libelf-dev golang-1.20 libyaml-perl libjson-perl ethtool (или эквивалент вашего дистрибутива)
• ln -s /usr/lib/go-1.20/bin/go /usr/local/bin/go (убедитесь, что Go-бинарник находится в вашем PATH)
• git clone https://github.com/davidcoles/vc5.git
• cd vc5/cmd
• cp config.sample.yaml config.yaml (отредактируйте config.yaml в соответствии с вашими требованиями)
• make (загружает библиотеку libbpf, собирает бинарник и JSON-конфигурационный файл)
• ./vc5 10.1.10.100 config.json eth0 (измените на IP-адрес вашего сервера и Ethernet-интерфейс)
• Веб-консоль будет по умолчанию доступна на порту 80 сервера-балансировщика.
• Добавьте ваш VIP на loopback-устройство ваших серверов бэкенда (например: ip addr add 192.168.101.1/32 dev lo)
• Настройте вашу сеть/клиент для отправки трафика для вашего VIP на балансировщик, либо через BGP (см. конфигурационный файл), либо через статическую маршрутизацию

Почти наверняка проще использовать бинарник из последнего GitHub-релиза (скомпилирован для x86-64). Он был протестирован в production, поэтому должен быть надёжным. Убедитесь, что ваша конфигурация совместима с этой версией, используя скрипт config.pl из тегированного релиза (или, конечно, вы можете собрать свой собственный JSON-конфиг любым удобным способом).

Если вы обновите YAML-конфигурационный файл и перегенерируете JSON (make config.json), вы можете перезагрузить новую конфигурацию, отправив процессу сигнал SIGINT (Ctrl-C) или SIGUSR2. SIGQUIT (Ctrl-) или SIGTERM вызовут корректное завершение BGP-соединений и выход из процесса.

Более сложный пример с LACP-агрегированным Ethernet-устройством, состоящим из двух интерфейсов (на моём тестовом сервере Intel X520 10 Гбит/с), с включённым native-режимом XDP-драйвера и тегированными VLAN:

Запись vlans в config.yaml:

vlans:
  10: 10.1.10.0/24
  20: 10.1.20.0/24
  30: 10.1.30.0/24

Командная строка:

./vc5 -n 10.1.10.100 config.json enp130s0f0 enp130s0f1

Бинарник обнаружит ваши VLAN-интерфейсы, ища устройства с IP-адресами, входящими в префиксы VLAN из конфигурационного файла. Если вы используете отдельные нетегированные физические интерфейсы, это теперь должно работать прозрачно без дополнительной настройки – просто перечислите все интерфейсы в командной строке, чтобы eBPF-код загрузился в каждый из них.

Поскольку состояние соединения отслеживается для каждого ядра (BPF_MAP_TYPE_LRU_PERCPU_HASH), вы должны убедиться, что RSS (Receive Side Scaling) будет последовательно направлять пакеты одного потока на одно и то же ядро ЦП в случае, если ваш коммутатор выберет другой интерфейс при изменении топологии LACP. Отключите irqbalance, убедитесь, что настройки каналов одинаковы на каждом интерфейсе (ethtool -l/-L) и что косвенность хэша потока RSS совпадает (ethtool -x/-X).

Этот сценарий можно проверить, запустив длительное соединение (например, используя iperf с опцией -t) к набору серверов бэкенда, затем отключив выбранный бэкенд, добавив звёздочку после IP-адреса в конфигурационном файле (см. документацию по серверам), определив, какой интерфейс на балансировщике принимает поток (например, watch -d 'cat /proc/interrupts | grep enp130s0f' и смотря на быстро растущий счётчик IRQ), а затем выведя этот интерфейс из LACP (ifenslave -d bond0 enp130s0f0). Вы должны увидеть, что поток перемещается на другой сетевой интерфейс, но по-прежнему обрабатывается тем же ядром.

При использовании бэкендов в нескольких подсетях для достижения наилучшей производительности вы должны убедиться, что все VLAN тегированы на одном транковом интерфейсе (LACP-агрегированном, если у вас больше одного физического интерфейса), а отображения подсеть/ID VLAN указаны в разделе vlans конфигурационного файла.

Если это невозможно (например, создание транковых интерфейсов на vSphere не является тривиальной задачей), то вы можете назначить каждую подсеть на отдельный нетегированный интерфейс:

./vc5 10.1.10.100 config.json eth0 eth1 eth2

Предыстория / дополнительная информация

Хорошее описание используемых концепций обсуждается в докладе Патрика Шуффа "Building a Billion User Load Balancer" и докладе Нитики Широковой о Katran.

Включена базовая веб-консоль и сервер метрик Prometheus:

Теперь добавлена экспериментальная поддержка ведения журнала в Elasticsearch (напрямую в ваш кластер, без необходимости собирать системные журналы). Регистрируется каждый зонд к серверам бэкенда, поэтому если один из них выходит из строя, вы можете точно увидеть, какая ошибка была возвращена, а также множество других условий. Это потребует значительной доработки и более разумного именования параметров журнала и т.д. (если у вас есть какие-либо идеи, свяжитесь со мной), но это должно позволить получить хорошие сведения о том, что происходит в системе – мой очень неуклюжий первый опыт создания панели Kibana в качестве примера:

Производительность

В основном тестировалось с серверами бэкенда Icecast, клиенты которых получали смесь потоков с низким и высоким битрейтом (48 кбит/с – 192 кбит/с).

Похоже, что гость VMWare (4 ядра, 8 ГБ) с использованием generic-драйвера XDP поддерживает 100 тыс. одновременных клиентов, пропускную способность 380 Мбит/с / 700 тыс. пакетов/с через балансировщик и 8 Гбит/с трафика от бэкендов напрямую к клиентам.

На одном (невиртуализированном) процессоре Intel Xeon Gold 6314U (2,30 ГГц, 32 физических ядра, с включённым гипертредингом для 64 логических ядер) и сетевой карте Intel 10G 4P X710-T4L-t мне удалось выполнить 700 тыс. потоков при входящем трафике 2 Гбит/с / 3,8 млн. пакетов/с и исходящем трафике 46,5 Гбит/с. Сервер был загружен менее чем на 10%. К сожалению, у меня не было ресурсов для создания большего количества клиентов/серверов.

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

Существует три режима работы: простой, VLAN и многоНИК. В простом режиме все хосты должны находиться в одной подсети с основным адресом балансировщика. В режиме VLAN (включается объявлением записей в разделе "vlans" конфигурационного файла YAML/JSON) записи серверов должны соответствовать записи подсети/CIDR в VLAN. VLAN-интерфейсы с тегированием необходимо создать в ОС и присвоить им IP-адрес в пределах подсети. В многоНИК-режиме подсетям присваиваются идентификаторы так же, как и VLAN, но для отправки трафика через соответствующий настроенный интерфейс используется bpf_redirect() (вместо изменения идентификатора VLAN и использования XDP_TX).

В режиме VLAN весь трафик для балансировщика должен идти через тегированную VLAN (ни добавление, ни удаление тегов 802.1Q пока не поддерживается).