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

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

В этой статье

Примечание.

Возможность добавлять дополнительные вычислительные узлы в HA находится в public preview и может измениться. Во время предварительного просмотра, пожалуйста, поделитесь отзывами с вашей командой по успеху клиентов.

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

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

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

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

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

Критерии

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

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

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

Каждый узел, который вы добавляете в развертывание HA, — это виртуальная машина (VM), на которой работает программное обеспечение 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 команда требует добавления узлов без состояния.

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

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

Чтобы удалить узел, запускайте ghe-remove-node с нужного узла. Затем, на первичном узле, нужно выполнить:

Shell
ghe-config-apply

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

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

Перепропорция узла, который ранее хранил 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 для генерации и загрузки кластерных или одноузловых пакетов.

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

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