GitHub откроет код собственного балансировщика нагрузки GLB


    GitHub обслуживает миллиарды HTTP, Git и SSH-соединений ежедневно. Для улучшения производительности в компании начали использовать «голое железо», то есть компьютеры без дополнительных уровней виртуализации. Однако исторически сложилось, что более сложным для оптимизации является сетевая балансировка нагрузки.

    Для этого в GitHub использовали вертикальное масштабирование с запуском малого количества больших машин и haproxy. Кроме того, была установлена специфическая аппаратная конфигурация, обеспечивающая отказоустойчивость 10G-линков.

    В итоге инженеры GitHub поняли, что понадобится создать собственное решение, которое будет работать для индивидуальных нужд ресурса. Поэтому они разработали балансировщик нагрузки (GitHub Load Balancer – GLB). Теперь GitHub принял решение превратить свою разработку в open source проект.

    Инженеры сообщили, что одной реализации горизонтального масштабирования и других стандартных схем балансировки для GitHub недостаточно.
    При увеличении нагрузки или посещаемости проекта, рано или поздно вертикальное масштабирование (увеличение ресурсов сервера, таких как память, скорость диска и т.д) упирается в некий предел и не дает ощутимого прироста. В таком случае в ход идет горизонтальное масштабирование — добавление новых серверов c перераспределением нагрузки между ними.

    Принимая во внимание узкие места в прежней системе, разработчики остановились на следующих требованиях к новой системе балансировки:

    • Работает на стандартном сетевом оборудовании.
    • Масштабируется горизонтально.
    • Обеспечивает высокое качество доступа, стабильность TCP-соединения и отказоустойчивость.
    • Поддерживает блокировку новых соединений.
    • Балансировка нагрузки для отдельных сервисов и хостов для множества сервисов.
    • Поддерживает итерационную разработку и разворачивается как обычное ПО.
    • Позволяет проводить тестирование каждого слоя, а не интеграционные тесты.
    • Работает для нескольких точек присутствия и дата-центров.
    • Обладает сопротивлением к распространенным DDoS-атакам и инструментарием для борьбы с новым видами атак.

    Работа с IP


    В обычных случаях один внешний публичный IP-адрес связывается с одной реальной машиной. DNS может быть использован для разделения трафика на несколько IP. Это дает возможность распределить трафик по нескольким серверам. GitHub нужно было решение, которое позволит связать один IP-адрес с несколькими машинами.

    Для этого в компании использовали ECMP-маршрутизацию (Equal-Cost Multi-Path routing), которая решает эту задачу и позволяет делать балансировку на уровне соединений.

    Разделение L4/L7


    Балансировка нагрузки выполняется отдельно на уровнях L4 и L7. На уровне L4 маршрутизатор использует ECMP и передает трафик на L7, который запускает необходимый софт (haproxy, например).

    В следующих постах инженеры GitHub обещают описать новую разработку более детально, а также рассказать о процессе перехода на новую систему балансировки нагрузки.
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 7

      +1
      «Для улучшения производительности в компании начали использовать «голое железо», то есть компьютеры без операционной системы»

      А можно подробнее?
        0
        похоже имеется ввиду " — An Ubuntu PXE image" из http://githubengineering.com/githubs-metal-cloud/
          +1
          http://githubengineering.com/githubs-metal-cloud/
          Если коротко, то никакого голого железа без ОС там естественно нет, просто их софт работает без виртуализации прямо на хостовой ОС. Облаком они это называют потому что у них автоматизировано создание и конфигурирование серверов.
          0
          XEN по сравнению с «bare metal» теряет считанные проценты производительности.
          Возможно, если у вас больше 50 000 серверов одинаковых серверов, это имеет значение, во всех остальных случаях выгоднее использовать xen и удобное управление конфигурациями и железом.
            0
            XEN мертв, да здравствует KVM
              0
              Давно?
            0
            Наверное, они не нашли поиском другое решение — Direct Server Return (DSR) load balancing с помощью коммутатора и DSCP

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое