Skip to main content

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

Различия между кластеризацией и высоким уровнем доступности (HA)

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

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

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

Сведения о топологиях развертывания для GitHub Enterprise Server

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

  • Для поддержки плана аварийного восстановления и дополнения резервных копий или повышения производительности сети и записи для географически распределенных пользователей можно настроить высокий уровень доступности. В конфигурации высокой доступности один узел выступает в качестве основного, а другие — в качестве реплик. Дополнительные сведения см. в разделе Сведения о настройке высокого уровня доступности.

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

Сценарии сбоев

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

  • Аварийное завершение программного обеспечения из-за сбоя операционной системы или неустранимых ошибок приложений.
  • Сбои оборудования, включая оборудование для хранения данных, ЦП, ОЗУ, сетевые интерфейсы и т. д.
  • Сбои системы узла виртуализации, включая незапланированные и запланированные события обслуживания для AWS, Azure или GCP.
  • Обрыв логической или физической структуры сети, если резервное устройство находится в отдельной сети, не затронутой сбоем.

Масштабируемость

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

Различия в методе отработки отказа и конфигурации

ФункцияКонфигурация отработки отказаМетод отработки отказа
Настройка высокого уровня доступностиЗапись DNS с низким TTL указывает на основное устройство или подсистему балансировки нагрузки.Необходимо вручную повысить уровень устройства реплики в конфигурациях отработки отказа DNS и подсистемы балансировки нагрузки.
КластеризацияЗапись DNS должна указывать на подсистему балансировки нагрузки.Если узел за подсистемой балансировки нагрузки выходит из строя, трафик автоматически отправляется на другие функционирующие узлы.

Резервное копирование и аварийное восстановление

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

Наблюдение

Функции доступности, особенно с автоматической отработкой отказа, например кластеризация, могут маскируют сбой, так как служба обычно не нарушается при сбое. Независимо от того, используете ли вы высокий уровень доступности или кластеризации, важно отслеживать работоспособность каждого экземпляра, чтобы вы знали, когда происходит сбой. Дополнительные сведения о мониторинге см. в разделе "[AUTOTITLE" и "Рекомендуемые пороговые значения оповещений](/admin/enterprise-management/configuring-clustering/monitoring-the-health-of-your-cluster)".