Разработчики из GitHub на прошлой неделе выложили ^[1] в открытый доступ исходники своего балансировщика нагрузки — GLB Director. Команда трудилась над этим проектом несколько лет.

Чем примечательно их решение, как оно устроено, и кто еще передавал системы распределения нагрузки в open source, рассказываем далее.

^[2]
/ Flickr / theilr ^[3] / CC ^[4]

Зачем GitHub свой балансировщик

В GitHub используют облачную инфраструктуру на базе bare metal ^[5] для повышения производительности. В этом случае программное обеспечение работает без дополнительных уровней виртуализации на «голом железе».

Ранее для балансировки нагрузки компания использовала haproxy ^[6] с особой аппаратной конфигурацией, которая обеспечивала отказоустойчивость 10-гигабитных Ethernet-соединений. Однако такой подход плохо масштабировался (подразумевалось вертикальное масштабирование), и в GitHub решили написать свой балансировщик нагрузки, который еще мог бы работать на недорогом аппаратном обеспечении.

Что умеет и как работает GLB Director

Балансировщик GitHub обеспечивает бесперебойность TCP-соединений, управляет нагрузкой отдельных сервисов, устойчив к DDoS-атакам и способен масштабироваться горизонтально. Он «заточен ^[1]» под работу в дата-центрах, где большое количество серверов анонсируют один IP-адрес по BGP ^[7], а роутеры используют стратегию ECMP ^[8].

Балансировка нагрузки выполняется ^[1] на уровнях L4 и L7. В отличие от таких решений, как LVS ^[9], GLB Director не направляет все пакеты на узел маршрутизации (director node), чтобы потом перераспределить их между другими узлами. Вместо этого, он использует ^[10] вариацию хеширования рандеву (rendezvous hashing, HRW ^[11]) для создания статической таблицы, чтобы выбрать для каждого входящего подключения пару прокси-серверов (первичный и вторичный). В случае если один из них выходит из строя, то пакет направляется второму. Система запоминает этот выбор, и его не нужно совершать для каждого пакета.

За «здоровьем» серверов следит решение glb-healthcheck, которое переключает первичные и вторичные системы в случае обнаружения неполадок. glb-healthcheck отслеживает ^[12] правильность работы каждого GUE ^[13]-туннеля (Generic UDP Encapsulation) и произвольного HTTP-порта backend-серверов.

GLB также использует систему Netfilter ^[14] и утилиту iptables ^[15]. Netfilter решает простую задачу: определяет, соответствует ли внутренний TCP/IP-пакет в каждом GUE-пакете требованиям TCP-стека ядра Linux. Если нет, то он перенаправляет пакет на вторичный прокси-сервер, а не декапсулирует его локально.

Схема взаимодействия компонентов выглядит так:

В GitHub надеются ^[12], что их балансировщик пригодится всем компаниям, которые имеют свои дата-центры.

Как установить GLB и начать с ним работать можно посмотреть в quick start руководстве, подготовленном разработчиками ^[16].

Похожие разработки

В мае компания Facebook тоже поделилась ^[17] исходным кодом библиотеки своего балансировщика нагрузки Katran. ИТ-гигант использует ^[18] его для эффективного распределения нагрузки между backend-серверами.

Предыдущий балансировщик компании — L4LB — не справлялся с задачей, так как требовал для работы выделенные сервера, что увеличивало нагрузку на сеть. Чтобы решить эту проблему, в компании и разработали Katran. Он запускается с помощью фреймворка eXpress Data Path и виртуальной машины eBPF. ВМ расширяет общий функционал, запуская программы в отдельных точках Linux-ядра.

/ Flickr / Da Sal ^[19] / CC ^[20]

Обновленный балансировщик эффективнее распределяет ^[18] нагрузку на инфраструктуру и повышает скорость обработки пакетов. Исходники разработчики «залили» ^[21] на GitHub.

Система Katran имеет ряд ^[22] отличий от решения, предложенного в GitHub. Например, в системе Facebook используются XDP- и IPIP-туннели, которые работают с ядром Linux. GLB, напротив, прибегает к помощи DPDK, чтобы обрабатывать пакеты из пользовательского пространства.

Тео Жульен (Theo Julienne), разработчик GitHub, добавил ^[23], что DPDK ^[24] дает оперировать большими объемами входящего трафика. Это гарантирует высокую производительность (10-гигабитное соединение) даже в сложных рабочих средах и обеспечивает определённую защиту от DDoS-атак.

Передача таких мощных инструментов, как GLB и Katran в open source откроет новые возможности для других ИТ-компаний и поспособствует более быстрому развитию ИТ-экосистемы в мире.

---

P.S. Пара дополнительных статей из Первого блога о корпоративном IaaS:

• Как разместить 100% инфраструктуры в облаке IaaS-провайдера и не пожалеть об этом ^[25]
• Тестирование дисковой системы в облаке: основы ^[26]
• Балансировка нагрузки в облаке IaaS: Зачем нужен DRS ^[27]

P.P.S. Другие материалы из нашего блога на Хабре:

• WireGuard «придет» в ядро Linux — почему? ^[28]
• Как дела в облаке, и что движет IaaS вперед: обсуждаем технологические тренды ^[29]

Автор: it_man

Источник ^[30]