Сведения о топологиях развертывания для GitHub Enterprise Server
Виртуальные машины можно развернуть для экземпляра GitHub Enterprise Server в разных топологиях в зависимости от потребностей вашей среды и пользователя.
-
Для поддержки плана аварийного восстановления и дополнения резервных копий или повышения производительности сети и записи для географически распределенных пользователей можно настроить высокий уровень доступности. В конфигурации высокого уровня доступности один узел выступает в качестве основного, а другие действуют как реплика. Дополнительные сведения см. в разделе Сведения о настройке высокого уровня доступности.
-
Чтобы обеспечить горизонтальное масштабирование для сред с десятками тысяч разработчиков, доступна топология кластера. Кластеризация устраняет ситуации, когда один первичный узел обычно испытывает исчерпание ресурсов. Для этой конфигурации требуется тщательное планирование и дополнительные административные расходы. GitHub будет работать с вами, чтобы определить право на кластеризация. Дополнительные сведения см. в разделе Сведения о кластеризации.
Сценарии сбоев
Высокий уровень доступности (HA) и кластеризация обеспечивают избыточность, устраняя один узел как точку сбоя. Они могут обеспечить доступность в следующих сценариях:
- Аварийное завершение программного обеспечения из-за сбоя операционной системы или неустранимых ошибок приложений.
- Сбои оборудования, включая оборудование для хранения данных, ЦП, ОЗУ, сетевые интерфейсы и т. д.
- Сбои системы узла виртуализации, включая незапланированные и запланированные события обслуживания для AWS, Azure или GCP.
- Обрыв логической или физической структуры сети, если резервное устройство находится в отдельной сети, не затронутой сбоем.
Масштабируемость
Кластеризация обеспечивает лучшую масштабируемость за счет распределения нагрузки между несколькими узлами. Это горизонтальное масштабирование может быть предпочтительнее для некоторых организаций с десятками тысяч разработчиков. При обеспечении высокого уровня доступности масштаб устройства зависит исключительно от основного узла, а нагрузка не распространяется на сервер-реплику.
Различия в методе отработки отказа и конфигурации
| Компонент | Конфигурация отработки отказа | Метод отработки отказа |
|---|---|---|
| Настройка высокого уровня доступности | Запись DNS с низким TTL указывает на основное устройство или подсистему балансировки нагрузки. | Необходимо вручную повысить уровень устройства реплики в конфигурациях отработки отказа DNS и подсистемы балансировки нагрузки. |
| Кластеризация | Запись DNS должна указывать на подсистему балансировки нагрузки. | Если узел за подсистемой балансировки нагрузки выходит из строя, трафик автоматически отправляется на другие функционирующие узлы. |
Резервное копирование и аварийное восстановление
Ни высокий уровень доступности, ни кластеризация не следует рассматривать как замену регулярных резервных копий. Дополнительные сведения см. в разделе Настройка резервных копий в экземпляре.
Наблюдение
Функции доступности, особенно с автоматической отработкой отказа, например кластеризация, могут маскируют сбой, так как служба обычно не нарушается при сбое. Независимо от того, используете ли вы высокий уровень доступности или кластеризация, важно отслеживать работоспособность каждого экземпляра, чтобы вы знали, когда происходит сбой. Дополнительные сведения о мониторинге см. в разделе "[AUTOTITLE" и "Рекомендуемые пороговые значения оповещений](/admin/enterprise-management/configuring-clustering/monitoring-the-health-of-your-cluster)".