davidcoles/vc5Горизонтально масштабируемый балансировщик нагрузки уровня 4 с прямым возвратом сервера (Direct Server Return) для Linux, использующий XDP/eBPF
# VC5 <picture> <img src="https://assets.kitploit.com/production/public/readmes/9322/203eb45ff2205aa56eaf10f0d0ea7be21a35972366b34252c91fc6e78a40818c.png" width="25%"> </picture> **Этот README в настоящее время обновляется с учётом последних изменений – некоторая информация может не соответствовать текущей кодовой базе. Эта итерация кода ещё не готова к бою – используйте релиз v0.2 для production.** Горизонтально масштабируемый L4-балансировщик нагрузки с прямым ответом сервера ([DSR](https://www.loadbalancer.org/blog/direct-server-return-is-simply-awesome-and-heres-why/)) для Linux, использующий [XDP/eBPF](https://www.datadoghq.com/blog/xdp-intro/). Если вы считаете, что это может быть полезно, или у вас есть вопросы/предложения, свяжитесь со мной по адресу [email protected] или создайте issue на GitHub. **Теперь поддерживается IPv6 и распределение на 3-м уровне (AKA туннелирование)!** Библиотека XVS была обновлена, чтобы включить эти функции, а также избавляет от необходимости запускать проверки работоспособности из сетевого пространства имён, что значительно упрощает код. Это положит конец требованию, чтобы все бэкенды находились в одной VLAN с балансировщиком. Текущие ограничения кода не позволяют включать туннелирование для отдельных служб. Использование опции `-tunnel` позволяет глобально включить туннелирование на 3-м уровне с использованием одной схемы (IP-in-IP, GRE, FOU или GUE). В будущем код будет обновлён, чтобы туннелирование можно было настраивать на уровне службы. Балансировка нагрузки на 2-м уровне по-прежнему будет поддерживаться – основной причиной запуска проекта было отсутствие поддержки 2-го уровня в [балансировщике Katran от Facebook](https://github.com/facebookincubator/katran). [Пример конфигурационного файла IPv6/L3](https://github.com/davidcoles/vc5/blob/main/doc/ipv6-l3.yaml) включён – более подробная документация появится позже. ## О проекте 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/](https://github.com/davidcoles/vc5/blob/main/examples)). Никаких модулей ядра или сложных настроек не требуется, хотя для достижения наилучшей производительности рекомендуется драйвер сетевой карты с поддержкой режима XDP native (например: mlx4, mlx5, i40e, ixgbe, ixgbevf, nfp, bnxt, thunder, dpaa2, qede). Полный список доступен на [странице поддержки драйверов проекта XDP](https://github.com/xdp-project/xdp-project/blob/master/areas/drivers/README.org). ## Цели/статус * ✅ Простое развёртывание с помощью одного бинарного файла * ✅ Стабильный выбор бэкенда с помощью хэш-алгоритма 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](https://github.com/libbpf/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](https://www.kernel.org/doc/Documentation/networking/scaling.txt)) будет последовательно направлять пакеты одного потока на одно и то же ядро ЦП в случае, если ваш коммутатор выберет другой интерфейс при изменении топологии LACP. Отключите irqbalance, убедитесь, что настройки каналов одинаковы на каждом интерфейсе (`ethtool -l/-L`) и что косвенность хэша потока RSS совпадает (`ethtool -x/-X`). Этот сценарий можно проверить, запустив длительное соединение (например, используя iperf с опцией -t) к набору серверов бэкенда, затем отключив выбранный бэкенд, добавив звёздочку после IP-адреса в конфигурационном файле (см. [документацию по серверам](https://github.com/davidcoles/vc5/blob/main/doc/servers.md)), определив, какой интерфейс на балансировщике принимает поток (например, `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"](https://www.youtube.com/watch?v=bxhYNfFeVF4&t=1060s) и [докладе Нитики Широковой о Katran](https://www.youtube.com/watch?v=da9Qw7v5qLM). Включена базовая веб-консоль и сервер метрик 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 пока не поддерживается).
