Skip to main content

Эта версия GitHub Enterprise Server была прекращена 2024-03-26. Исправления выпускаться не будут даже при критических проблемах безопасности. Для повышения производительности, повышения безопасности и новых функций выполните обновление до последней версии GitHub Enterprise Server. Чтобы получить справку по обновлению, обратитесь в службу поддержки GitHub Enterprise.

Сведения об узлах кластера

В кластере GitHub Enterprise Server узлы являются отдельными виртуальными машинами ( виртуальными машинами) с программным обеспечением GitHub Enterprise Server в составе экземпляра. Каждый узел запускает набор служб.

Кто эту функцию можно использовать?

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

Сведения о узлах кластера GitHub Enterprise Server

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

Примечание. Кластеризация GitHub Enterprise Server должна быть настроена с помощью протокола HTTPS.

Требования к аппаратному обеспечению

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

СлужбыМинимальная необходимая памятьМинимальное свободное место на томе данных, необходимое
job-server,
memcache-server,
web-server
14 ГБ1 ГБ
consul-server,
mysql-server,
redis-server
14 ГБ10 ГБ
git-server,
metrics-server,
pages-server,
storage-server
14 ГБ10 ГБ
elasticsearch-server14 ГБ10 ГБ

Службы, необходимые для кластеризации

GitHub Enterprise Server состоит из набора служб. В кластере эти службы выполняются между несколькими узлами, а экземпляр балансирует запросы между узлами. Экземпляр автоматически сохраняет избыточные копии данных на отдельных узлах. Большинство служб равны одноранговые с другими экземплярами одной и той же службы. Исключениями этого распределения являются mysql-server службы и redis-server службы, которые работают с одним первичным узлом с одним или несколькими реплика узлами.

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

Примечание. Требования к масштабированию среды зависят от многих факторов, включая размер и количество репозиториев, количество пользователей и общее использование.

Пример конфигурации кластера

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

УровниСлужбыМинимальные необходимые узлы
Внешний интерфейсjob-server,
memcache-server,
web-server
2
База данныхconsul-server,
mysql-server,
redis-server
3
Хранилищеgit-server,
metrics-server,
pages-server,
storage-server
3
Searchelasticsearch-server3

Рекомендации по проектированию кластеров

Кластеризация позволяет службам, составляющим GitHub Enterprise Server, масштабироваться независимо друг от друга. Такие гибкие возможности можно использовать для проектирования и реализации кластера, который соответствует требованиям к масштабированию для различных организаций. Например, некоторым организациям может потребоваться больше пропускной способности хранилища для крупных или регулярных выборок, однако объем потребления ресурсов веб-сервера может быть относительно низким. В другой организации может быть высокая производительность при меньшем объеме ресурсов хранилища, однако требуется много узлов, где запущен pages-server или elasticsearch-server. Возможно множество различных комбинаций. Обратитесь к своему менеджеру по работе с клиентами, чтобы определить оптимальную конфигурацию кластера для конкретных потребностей.

  • Распределите избыточные узлы по различным независимым единицам оборудования. При совместном использовании ресурсов ЦП, памяти или устройств хранения снижается производительность и добавляются отдельные точки отказа. Общие сетевые компоненты также могут снижать пропускную способность и повышать риск потери соединения в случае сбоя.
  • Используйте быстрое хранение. Сети хранения данных (SAN) зачастую оптимизированы для максимального потребления ресурсов пространства, доступности и отказоустойчивости, а не для абсолютной пропускной способности. Кластеризация GitHub Enterprise Server обеспечивает избыточность и доступность и оптимальную производительность при использовании максимально быстрого хранилища. Рекомендуется использовать локальное хранилище SSD.