Skip to main content

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

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

In a GitHub Enterprise Server cluster, nodes are individual virtual machines (VMs) running the GitHub Enterprise Server software that comprise the instance. Each node runs a set of services.

GitHub determines eligibility for clustering, and must enable the configuration for your instance's license. Clustering requires careful planning and additional administrative overhead. For more information, see "About clustering."

Сведения о узлах кластера 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.