davidcoles/vc5Горизонтально масштабируемый балансировщик нагрузки уровня 4 с прямым возвратом сервера (Direct Server Return) для Linux, использующий XDP/eBPF
Этот 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.
Для достижения наилучших результатов следует отключить/удалить 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.gitcd vc5/cmdcp config.sample.yaml config.yaml (отредактируйте config.yaml в соответствии с вашими требованиями)make (загружает библиотеку libbpf, собирает бинарник и JSON-конфигурационный файл)./vc5 10.1.10.100 config.json eth0 (измените на IP-адрес вашего сервера и Ethernet-интерфейс)ip addr add 192.168.101.1/32 dev lo)Почти наверняка проще использовать бинарник из последнего GitHub-релиза (скомпилирован для x86-64). Он был протестирован в production, поэтому должен быть надёжным. Убедитесь, что ваша конфигурация совместима с этой версией, используя скрипт config.pl из тегированного релиза (или, конечно, вы можете собрать свой собственный JSON-конфиг любым удобным способом).