Сведения о топологиях развертывания для GitHub Enterprise Server
Виртуальные машины можно развернуть для экземпляра GitHub Enterprise Server в разных топологиях в зависимости от потребностей вашей среды и пользователя.
-
Для поддержки плана аварийного восстановления и дополнения резервных копий, а также для повышения производительности сети и записи для географически распределенных пользователей можно настроить высокий уровень доступности. В конфигурации с высоким уровнем доступности один узел выступает в качестве основного, а другие — в качестве реплик.
-
Чтобы обеспечить горизонтальное масштабирование для сред с десятками тысяч разработчиков, доступна топология кластера. Кластеризация решает ситуации, когда на одном первичном узле обычно возникает нехватка ресурсов. Эта конфигурация требует тщательного планирования и дополнительных административных издержек. GitHub будет работать с вами, чтобы определить ваши права на кластеризация.
Сценарии сбоев
Высокий уровень доступности (HA) и кластеризация обеспечивают избыточность, устраняя один узел в качестве точки отказа. Они могут обеспечить доступность в следующих сценариях:
- Аварийное завершение программного обеспечения из-за сбоя операционной системы или неустранимых ошибок приложений.
- Сбои оборудования, включая оборудование для хранения данных, ЦП, ОЗУ, сетевые интерфейсы и т. д.
- Сбои системы узла виртуализации, включая незапланированные и запланированные события обслуживания для AWS, Azure или GCP.
- Обрыв логической или физической структуры сети, если резервное устройство находится в отдельной сети, не затронутой сбоем.
Масштабируемость
Кластеризация обеспечивает лучшую масштабируемость за счет распределения нагрузки между несколькими узлами. Это горизонтальное масштабирование может быть предпочтительнее для некоторых организаций с десятками тысяч разработчиков. При обеспечении высокого уровня доступности масштаб устройства зависит исключительно от основного узла, а нагрузка не распространяется на сервер-реплику.
Различия в методе отработки отказа и конфигурации
| Компонент | Конфигурация отработки отказа | Метод отработки отказа |
|---|---|---|
| Настройка высокого уровня доступности | Запись DNS с низким TTL указывает на основное устройство или подсистему балансировки нагрузки. | Необходимо вручную повысить уровень устройства реплики в конфигурациях отработки отказа DNS и подсистемы балансировки нагрузки. |
| Кластеризация | Запись DNS должна указывать на подсистему балансировки нагрузки. | Если узел за подсистемой балансировки нагрузки выходит из строя, трафик автоматически отправляется на другие функционирующие узлы. |
Резервное копирование и аварийное восстановление
Ни высокий уровень доступности, ни кластеризация не следует рассматривать как замену регулярного резервного копирования. Дополнительные сведения см. в разделе Настройка резервных копий на устройстве.
Наблюдение
Функции доступности, особенно с автоматической отработкой отказа, такие как кластеризация, могут скрыть сбой, так как служба обычно не прерывается при сбое. Независимо от того, используете ли вы высокий уровень доступности или кластеризация, важно отслеживать работоспособность каждого экземпляра, чтобы вы знали, когда происходит сбой. Дополнительные сведения о мониторинге см. в разделах Рекомендуемые пороговые значения оповещений и Мониторинг узлов кластера.
Дополнительные материалы
- Дополнительные сведения о кластеризация GitHub Enterprise Server см. в разделе Сведения о кластеризация.
- Дополнительные сведения о высокой доступности см. в разделе Настройка высокого уровня доступности.