Разработчики из GitHub на прошлой неделе выложили в открытый доступ исходники своего балансировщика нагрузки — GLB Director. Команда трудилась над этим проектом несколько лет.
Чем примечательно их решение, как оно устроено, и кто еще передавал системы распределения нагрузки в open source, рассказываем далее.
/ Flickr / theilr / CC
В GitHub используют облачную инфраструктуру на базе bare metal для повышения производительности. В этом случае программное обеспечение работает без дополнительных уровней виртуализации на «голом железе».
Ранее для балансировки нагрузки компания использовала haproxy с особой аппаратной конфигурацией, которая обеспечивала отказоустойчивость 10-гигабитных Ethernet-соединений. Однако такой подход плохо масштабировался (подразумевалось вертикальное масштабирование), и в GitHub решили написать свой балансировщик нагрузки, который еще мог бы работать на недорогом аппаратном обеспечении.
Балансировщик GitHub обеспечивает бесперебойность TCP-соединений, управляет нагрузкой отдельных сервисов, устойчив к DDoS-атакам и способен масштабироваться горизонтально. Он «заточен» под работу в дата-центрах, где большое количество серверов анонсируют один IP-адрес по BGP, а роутеры используют стратегию ECMP.
Балансировка нагрузки выполняется на уровнях L4 и L7. В отличие от таких решений, как LVS, GLB Director не направляет все пакеты на узел маршрутизации (director node), чтобы потом перераспределить их между другими узлами. Вместо этого, он использует вариацию хеширования рандеву (rendezvous hashing, HRW) для создания статической таблицы, чтобы выбрать для каждого входящего подключения пару прокси-серверов (первичный и вторичный). В случае если один из них выходит из строя, то пакет направляется второму. Система запоминает этот выбор, и его не нужно совершать для каждого пакета.
За «здоровьем» серверов следит решение glb-healthcheck, которое переключает первичные и вторичные системы в случае обнаружения неполадок. glb-healthcheck отслеживает правильность работы каждого GUE-туннеля (Generic UDP Encapsulation) и произвольного HTTP-порта backend-серверов.
GLB также использует систему Netfilter и утилиту iptables. Netfilter решает простую задачу: определяет, соответствует ли внутренний TCP/IP-пакет в каждом GUE-пакете требованиям TCP-стека ядра Linux. Если нет, то он перенаправляет пакет на вторичный прокси-сервер, а не декапсулирует его локально.
Схема взаимодействия компонентов выглядит так:
В GitHub надеются, что их балансировщик пригодится всем компаниям, которые имеют свои дата-центры.
Как установить GLB и начать с ним работать можно посмотреть в quick start руководстве, подготовленном разработчиками.
В мае компания Facebook тоже поделилась исходным кодом библиотеки своего балансировщика нагрузки Katran. ИТ-гигант использует его для эффективного распределения нагрузки между backend-серверами.
Предыдущий балансировщик компании — L4LB — не справлялся с задачей, так как требовал для работы выделенные сервера, что увеличивало нагрузку на сеть. Чтобы решить эту проблему, в компании и разработали Katran. Он запускается с помощью фреймворка eXpress Data Path и виртуальной машины eBPF. ВМ расширяет общий функционал, запуская программы в отдельных точках Linux-ядра.
/ Flickr / Da Sal / CC
Обновленный балансировщик эффективнее распределяет нагрузку на инфраструктуру и повышает скорость обработки пакетов. Исходники разработчики «залили» на GitHub.
Система Katran имеет ряд отличий от решения, предложенного в GitHub. Например, в системе Facebook используются XDP- и IPIP-туннели, которые работают с ядром Linux. GLB, напротив, прибегает к помощи DPDK, чтобы обрабатывать пакеты из пользовательского пространства.
Тео Жульен (Theo Julienne), разработчик GitHub, добавил, что DPDK дает оперировать большими объемами входящего трафика. Это гарантирует высокую производительность (10-гигабитное соединение) даже в сложных рабочих средах и обеспечивает определённую защиту от DDoS-атак.
Передача таких мощных инструментов, как GLB и Katran в open source откроет новые возможности для других ИТ-компаний и поспособствует более быстрому развитию ИТ-экосистемы в мире.
P.S. Пара дополнительных статей из Первого блога о корпоративном IaaS:
Мы предоставляем ряд услуг в сфере облачных вычислений и функционального ИТ-аутсорсинга:
Виртуальная инфраструктура (IaaS) | PCI DSS хостинг | Облако ФЗ-152 | SAP-хостинг | Виртуальная СХД | Шифрование данных в облаке | Облачное хранилище
Чем примечательно их решение, как оно устроено, и кто еще передавал системы распределения нагрузки в open source, рассказываем далее.
/ Flickr / theilr / CC
Зачем GitHub свой балансировщик
В GitHub используют облачную инфраструктуру на базе bare metal для повышения производительности. В этом случае программное обеспечение работает без дополнительных уровней виртуализации на «голом железе».
Ранее для балансировки нагрузки компания использовала haproxy с особой аппаратной конфигурацией, которая обеспечивала отказоустойчивость 10-гигабитных Ethernet-соединений. Однако такой подход плохо масштабировался (подразумевалось вертикальное масштабирование), и в GitHub решили написать свой балансировщик нагрузки, который еще мог бы работать на недорогом аппаратном обеспечении.
Что умеет и как работает GLB Director
Балансировщик GitHub обеспечивает бесперебойность TCP-соединений, управляет нагрузкой отдельных сервисов, устойчив к DDoS-атакам и способен масштабироваться горизонтально. Он «заточен» под работу в дата-центрах, где большое количество серверов анонсируют один IP-адрес по BGP, а роутеры используют стратегию ECMP.
Балансировка нагрузки выполняется на уровнях L4 и L7. В отличие от таких решений, как LVS, GLB Director не направляет все пакеты на узел маршрутизации (director node), чтобы потом перераспределить их между другими узлами. Вместо этого, он использует вариацию хеширования рандеву (rendezvous hashing, HRW) для создания статической таблицы, чтобы выбрать для каждого входящего подключения пару прокси-серверов (первичный и вторичный). В случае если один из них выходит из строя, то пакет направляется второму. Система запоминает этот выбор, и его не нужно совершать для каждого пакета.
За «здоровьем» серверов следит решение glb-healthcheck, которое переключает первичные и вторичные системы в случае обнаружения неполадок. glb-healthcheck отслеживает правильность работы каждого GUE-туннеля (Generic UDP Encapsulation) и произвольного HTTP-порта backend-серверов.
GLB также использует систему Netfilter и утилиту iptables. Netfilter решает простую задачу: определяет, соответствует ли внутренний TCP/IP-пакет в каждом GUE-пакете требованиям TCP-стека ядра Linux. Если нет, то он перенаправляет пакет на вторичный прокси-сервер, а не декапсулирует его локально.
Схема взаимодействия компонентов выглядит так:
В GitHub надеются, что их балансировщик пригодится всем компаниям, которые имеют свои дата-центры.
Как установить GLB и начать с ним работать можно посмотреть в quick start руководстве, подготовленном разработчиками.
Похожие разработки
В мае компания Facebook тоже поделилась исходным кодом библиотеки своего балансировщика нагрузки Katran. ИТ-гигант использует его для эффективного распределения нагрузки между backend-серверами.
Предыдущий балансировщик компании — L4LB — не справлялся с задачей, так как требовал для работы выделенные сервера, что увеличивало нагрузку на сеть. Чтобы решить эту проблему, в компании и разработали Katran. Он запускается с помощью фреймворка eXpress Data Path и виртуальной машины eBPF. ВМ расширяет общий функционал, запуская программы в отдельных точках Linux-ядра.
/ Flickr / Da Sal / CC
Обновленный балансировщик эффективнее распределяет нагрузку на инфраструктуру и повышает скорость обработки пакетов. Исходники разработчики «залили» на GitHub.
Система Katran имеет ряд отличий от решения, предложенного в GitHub. Например, в системе Facebook используются XDP- и IPIP-туннели, которые работают с ядром Linux. GLB, напротив, прибегает к помощи DPDK, чтобы обрабатывать пакеты из пользовательского пространства.
Тео Жульен (Theo Julienne), разработчик GitHub, добавил, что DPDK дает оперировать большими объемами входящего трафика. Это гарантирует высокую производительность (10-гигабитное соединение) даже в сложных рабочих средах и обеспечивает определённую защиту от DDoS-атак.
Передача таких мощных инструментов, как GLB и Katran в open source откроет новые возможности для других ИТ-компаний и поспособствует более быстрому развитию ИТ-экосистемы в мире.
P.S. Пара дополнительных статей из Первого блога о корпоративном IaaS:
- Как разместить 100% инфраструктуры в облаке IaaS-провайдера и не пожалеть об этом
- Тестирование дисковой системы в облаке: основы
- Балансировка нагрузки в облаке IaaS: Зачем нужен DRS
Мы предоставляем ряд услуг в сфере облачных вычислений и функционального ИТ-аутсорсинга:
Виртуальная инфраструктура (IaaS) | PCI DSS хостинг | Облако ФЗ-152 | SAP-хостинг | Виртуальная СХД | Шифрование данных в облаке | Облачное хранилище
mediaman
Я считаю, что чем больше компаний открывают свои решения, тем здоровее становится ИТ-среда. Тестирование совместными усилиями идет только на пользу. Хотя после покупки МС неожиданный ход
Spunreal
Как раз с Сатьей Наделлой это ожидаемый ход. Он новый глоток воздуха для MS
nafikovr
ну я бы не сказал что прямо ожидаемый. но и не такой уж удивительный