Enterprise Server 3.22 в настоящее время доступен в качестве кандидата на выпуск.

Добавление узлов в конфигурацию с высокой доступностью

Добавить узлы в основной дата-центр высокой доступности (HA). Это предназначено для разгрузки задач с большим объемом ЦП с первичного GitHub Enterprise Server узла, что позволяет горизонтально масштабировать экземпляр.

В этой статье

Для GitHub Enterprise Server клиентов, желающих горизонтально масштабироваться, миграция в кластер и работа с ней является вариантом, но является ресурсоемким и трудоемким. В качестве альтернативы мы рекомендуем добавлять узлы в конфигурацию HA.

Термины «дополнительный узел» и «бессостоятельный узел» используются взаимозаменяемо на протяжении всей этой статьи. Безсостоятельные узлы можно добавлять только в развертывания HA, содержащие хотя бы одну реплику.

Дополнительные узлы

Из всех служб, работающих на GitHub Enterprise Server устройстве, Юникорн часто является наиболее интенсивным ЦП и памятью, за которым следует Aqueduct, Git и MySQL. Поскольку Unicorn и Aqueduct являются сервисами без состояния, они хорошо подходят для горизонтального масштабирования и могут работать на отдельном наборе узлов. Оставшиеся сервисы могут продолжать работу с одним экземпляром на каждый дата-центр.

Дополнительные узлы позволяют масштабировать веб- и задачи горизонтально. Они также могут перезагружать Unicorn и Aqueduct с основного узла, освобождая значительные вычислительные ресурсы и ресурсы памяти для оставшихся сервисов с состоянием. Если у вас возникают сбои с производительностью из-за высокой загрузки процессора экземплярами Unicorn, рекомендуется добавлять дополнительные узлы. Нет значительных ограничений на количество этих узлов, которые можно добавить в дата-центре.

Критерии

Если у вас ухудшается производительность из-за перегруженности основного узла в конфигурации HA, стоит рассмотреть возможность добавления дополнительных узлов в вашу среду HA. Масштабируя веб- и должностные роли горизонтально за пределы основного узла, эти дополнительные узлы помогают снизить нагрузку на основной хост.

Например, если вы заметили задержки в очередях Unicorn или Aqueduct, либо сталкиваетесь с другими типами борьбы за ресурсы, стоит рассмотреть этот подход. Даже если нет видимой очереди, исчерпание процессора на основном узле — ещё один чистый сигнал. В таких случаях можно добавить дополнительные узлы и уменьшить количество работников на узел, чтобы первичный узел справлялся с меньшей объёмной нагрузкой.

Добавление узла

Каждый узел, добавляемый в развертывание высокой доступности, — это виртуальная машина под управлением программного GitHub Enterprise Server обеспечения. Он должен работать с тем же программным обеспечением, что и основная. Как правило, безсостоятельный узел не обязан соответствовать характеристикам памяти, процессора или хранилища основного устройства. Однако и бессостоятельный узел, и первичный экземпляр требуют субмиллисекундной связи. Требования к подключению реплик остаются без изменений.

Чтобы добавить узлы в основной дата-центр в конфигурации HA, используйте команду ghe-add-node . Эта ghe-add-node команда настраивает текущее устройство как узел внутри развертывания HA и предназначена для перегрузки задач, нагруженных процессором, с основного узла данных, обеспечивая горизонтальное масштабирование. Эти узлы разработаны для обработки веб- и рабочих нагрузок, что позволяет более эффективно распределять и управлять рабочими нагрузками. Эта команда имеет форму:

Shell
/usr/local/share/enterprise/ghe-add-node PRIMARY_IP [--hostname HOSTNAME]
  • PRIMARY_IP: IP-адрес основного узла.
  • HOSTNAME (по желанию): Желаемое имя хозяина для добавленного хоста.

Например, чтобы добавить узел с именем ghes-node-1 хоста в основной экземпляр HA с IP-адресом 192.168.1.1 в основном дата-центре HA, нужно выполнить следующую команду:

Shell
/usr/local/share/enterprise/ghe-add-node 192.168.1.1 --hostname ghes-node-1

Затем, на основном узле, необходимо выполнить следующие команды:

Shell
ghe-config-apply
ghe-cluster-balance rebalance --yes

Эта ghe-config-apply команда требует добавления узлов без состояния.

Рекомендуется использовать период обслуживания для добавления узлов без отслеживания состояния.

Удаление дополнительного узла

Перед удалением дополнительного узла установите тот же последний исправление для выпуска компонентов на каждом узле развертывания высокого уровня доступности и запланируйте период обслуживания. Дождитесь завершения обновления или настройки перед началом удаления.

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

    Shell
    ghe-cluster-nodes
ghe-cluster-nodes --offline
nomad node status
ghe-cluster-status --extended --verbose

    Убедитесь, что обе ghe-cluster-nodes команды перечисляют одинаковые имена узлов и включают имя узла, который вы планируете удалить. Убедитесь, что каждый узел имеет состояние readyNomad и connect-ssh``enterprise-version имеет ok значение для каждого узла. Убедитесь, что службы с отслеживанием состояния в первичной и любой реплике работоспособны. Если реплика не останется, предупреждение о том, что не найдена реплика MySQL. Сбои, ограниченные рабочими нагрузками web, job или memcache в целевом объекте, не блокируют удаление. Если проверка на уровне узла или службы с отслеживанием состояния завершается ошибкой, обратитесь Служба поддержки GitHub перед удалением.

  2. В основном узле высокого уровня доступности удалите дополнительный узел. Замените HOSTNAME именем узла дополнительного узла.

    Shell
    ghe-remove-node --verbose HOSTNAME

    Если другой не первичный узел остается, команда очищает целевой объект, удаляет его из конфигурации высокого уровня доступности и выполняется ghe-config-apply. Если не основной узел остается, команда удаляет метаданные кластера и преобразует основной в автономный экземпляр без выполнения ghe-config-apply. Не выполняйтесь ghe-config-apply отдельно в любом случае.

  3. Проверьте удаление.

    Если еще один не-первичный узел остается, выполните следующие команды на первичном сервере высокого уровня доступности. Убедитесь, что имя узла отсутствует и что конфигурация высокого уровня доступности работоспособна.

    Shell
    ghe-cluster-nodes --offline
ghe-cluster-status --extended --verbose

    Если не основной узел остается, не выполняйте команды только для кластера. Убедитесь, что выходные данные удаления содержатся Cluster artifacts removed; now standalone., а затем убедитесь, что основной обслуживает трафик пользователя и обрабатывает рабочие нагрузки веб-и заданий.

Если дополнительный узел находится в автономном режиме, недоступен или в другой версии или если ghe-remove-node проверка проверки завершается ошибкой, обратитесь в службу Служба поддержки GitHub. Не редактируйте cluster.conf вручную.

Повторное создание узла, размещенного ранее GitHub Enterprise Server

Можно использовать узел, который ранее размещался и выполнялся GitHub Enterprise Server как узел без отслеживания состояния. Для этого узел должен быть обновлён до версии 3.18 или выше, и все узлы в развертывании должны работать на одной и той же версии. На этом узле проверьте, существует /data/user/common/cluster.conf ли он уже. Если это так, вам придётся провести очистку перед запуском ghe-add-node команды на безсостоятельном узле.

Рассмотрим пример.

Shell
sudo rm -f /etc/github/cluster /data/user/common/cluster.conf
sudo timeout -k4 10 systemctl stop wireguard 2>/dev/null || sudo ip link delete tun0 || true

Ограничения и поведение

Теоретического ограничения на количество узлов, которые можно добавить, нет. Однако на практике добавление слишком большого количества узлов может вызвать проблемы и повлиять на стабильность или производительность. В это время новые узлы будут обрабатывать заранее определённый набор задач. Вы не можете выбрать, какие типы задач распределяются. Все API могут обрабатываться дополнительным узлом.

Если операция Git находится на пути, существует логика для обработки операций Git только на первичном узле. Операции с Git не обрабатываются дополнительным узлом. Например, удаление ветви — это операция Git, и она не будет выполняться узлом без состояния.

Безсостоятельные узлы не выполняют рабочие нагрузки Elasticsearch, но выполняют kafka-lite.

Требования к системе и сетям

Как правило, безсостоятельные узлы не обязаны совпадать с характеристиками памяти, процессора и хранилища основного узла. Системные требования должны учитывать существующее потребление ресурсов веб- и сервисов заданий на первичном узле, а также то, полностью ли основной узел перенесет эти нагрузки на новый узел.

Безсостоятельный узел и первичный экземпляр требуют субмиллисекундной связности. Как правило, все узлы в основном дата-центре требуют подключения до миллисекунды. Требования к подключению реплик остаются без изменений.

Маршрутизация трафика и обработка запросов

Первичный маршрутизирует трафик к дополнительным узлам. В случае нескольких безсостоятельных узлов первичный отправляет новые соединения на сервер с наименьшим количеством активных соединений в данный момент.

Обновление развертывания HA с добавлением дополнительных узлов

Ниже приведён пример последовательности модернизации:

  • Начало окна обслуживания.
  • Остановите реплики.
  • Параллельно обновляйте узлы без состояния.
  • Обновите основной узел.
  • Обновляйте реплики. Их можно обновлять параллельно или последовательно, в зависимости от ваших предпочтений по восстановлению после катастрофы.
  • Начните делать реплики.
  • Уберите окно обслуживания.

Дополнительные узлы не должны вызывать дополнительных простоев во время обновлений.

Отказное переключение и поведение при восстановлении после катастроф

Нет необходимости «разрушать» дополнительные узлы, так как они не содержат данных.

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

Если основной узел работает и вы хотите сделать реплику первичной, следует удалить безсостоятельные узлы с основного узла с помощью команды ghe-remove-node , прежде чем добавить их обратно в продвигаемый узел.

Если основной узел недоступен и невосстановим, безсостоятельные узлы можно добавить заново, не удаляя их из исходного.

Мониторинг, логи и пакеты поддержки

На первичном узле панели мониторинга Management Console отображают метрики для всех узлов, включая безсостоятельные узлы. Команды, такие как ghe-cluster-nodes и ghe-cluster-status содержат, содержат детали о узлах без состояния. Все запросы в Management Console обслуживаются основным узлом.

Логи хранятся локально на узлах без состояния. Их можно экспортировать из этих узлов в сторонние сервисы управления журналами.

Вы можете использовать ghe-cluster-support-bundle команды and ghe-support-bundle для генерации и загрузки кластерных или одноузловых пакетов.

Устранение насыщенности softirq с одним ядром

Добавление узла без отслеживания состояния в GitHub Enterprise Server развертывание с высоким уровнем доступности отправляет весь трафик между двумя узлами через один туннель WireGuard. Так как каждый пакет для этой пары узлов использует один порт UDP, сетевая карта управляет им в одну очередь получения, а один ядро ЦП обрабатывает все входящие пакеты. При интенсивном трафике, который ядро достигает 100 процентов, а остальные остаются бездействующими, а узел удаляет пакеты. GitHub Enterprise Server включает встроенные способы устранения рисков, описанные ниже.

1. Горизонтальное масштабирование с большим числом узлов без отслеживания состояния

Каждый узел без отслеживания состояния достигает первичного по своему туннелю WireGuard, поэтому основной обрабатывает трафик каждого узла в отдельной очереди получения и ядре ЦП. Распределение рабочих нагрузок между более мелкими узлами без отслеживания состояния позволяет подсистеме балансировки нагрузки между туннелями распределять нагрузку между ядрами основного объекта, и это не зависит от хэширования на уровне туннеля. Два узла примерно сократили нагрузку приема на ядро, и три отрезали ее примерно на треть.

GitHub Enterprise Server размер веб-рабочих ролей каждого узла из своей памяти и заверяет собственное значение в 30. Держите app.github.github-workers около 30 на узел; большее число затрат памяти и, во время туннелирования, добавьте глубину очереди, а не пропускную способность, так как дополнительные рабочие блоки на основном. Для получения дополнительной емкости добавьте дополнительные узлы без отслеживания состояния.

2. Multi-tunnel WireGuard (opt-in)

GitHub Enterprise Server может распространять трафик между узлами по нескольким туннелям WireGuard. Каждый туннель использует собственный порт UDP, поэтому разные подключения помещаются в разные очереди получения и разные ядра ЦП совместно используют работу. Задайте для счетчика туннелей наименьшее количество очередей приема на узлах кластера, значение ethtool -l eth0"Объединенный" .

Shell
ghe-config wireguard.num-tunnels 8
ghe-config-apply

Значение по умолчанию — 1. Максимальное значение — 16; Более высокие значения ограничены. Больше туннелей, чем интерфейс имеет очереди получения, не добавляет преимущества. Чтобы вернуться, удалите параметр и примените его.

Shell
ghe-config --unset wireguard.num-tunnels
ghe-config-apply

Перед включением (один раз):

  • В внешней группе брандмауэра или облачной безопасности откройте дополнительные порты UDP туннеля между всеми узлами, включая все реплики. Число портов от 1194 года, поэтому 8 туннелей используют UDP 1194 до 1201. Для полного диапазона требуется UDP 1194–1209.
  • Включение нескольких туннелей обновляет брандмауэр узла. Примените его один раз, перезагрузив все узлы или перезагрузив брандмауэр с sudo ufw reload каждым узлом. Убедитесь, что группа безопасности сети уже ограничивает входящий доступ первым, так как перезагрузите UFW кратко удаляет и повторно создает правила. Последующие num-tunnels изменения не требуют этого шага.

3. Локальная маршрутизация git-proxy на первичном (автоматическом)

Git запрашивает, что узел без отслеживания состояния в противном случае отправляется обратно через туннель, теперь остается на основном месте, где данные Git уже находятся. Это удаляет большую долю пакетов между туннелями и не требует никаких действий. Основной сервер сначала использует локальный прокси-сервер Git и возвращается к удаленному узлу только в том случае, если локальный прокси-сервер недоступен.

4. Вес веб-запроса на основе емкости (согласие)

Если узлы выполняют разные числа веб-рабочих ролей, GitHub Enterprise Server могут распределять запросы в пропорции к числу рабочих ролей каждого узла, а не равномерно. Включите его, если количество рабочих ролей неровно, например первичный с 100 рабочими рабочая роль и узел без отслеживания состояния с 30.

Shell
ghe-config app.github.unicorn-weight-by-capacity true
ghe-config-apply

Значение по умолчанию отключено.

Выбор того, что нужно включить

Начните с масштабирования до более узлов без отслеживания состояния. Это самый полный вариант, распределяет нагрузку по большей части ядер основного источника через подсистему балансировки нагрузки и не требует флага функции. Если одно ядро по-прежнему насыщено, включите multi-tunnel WireGuard. Включите вес на основе емкости, только если число рабочих ролей отличается между узлами.

Известные ограничения

Эта функция не предназначена для монорепозиторий, но добавление новых безсостоятельных узлов может косвенно улучшить операции монорепозитория, снижая нагрузку на веб и задачи на основном узле. Функции автомасштабирования и уменьшения нет.