Skip to main content

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

Сведения о настройке высокого уровня доступности

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

При конфигурации высокого уровня доступности происходит автоматическая настройка односторонней асинхронной репликации всех хранилищ данных (репозиториев Git, MySQL, Redis и Elasticsearch) с основного устройства на устройство реплики. Также реплицируется большинство параметров конфигурации GitHub Enterprise Server, включая пароль Консоль управления. Дополнительные сведения см. в разделе Администратор создание экземпляра из пользовательского веб-интерфейса.

GitHub Enterprise Server поддерживает активную или пассивный конфигурацию, где реплика (модуль) выполняются в режиме ожидания с службами баз данных, работающими в режиме реплика, но службы приложений остановлены.

После выполнения репликации Консоль управления больше недоступна на устройствах реплики. Если перейти к IP-адресу или имени узла реплика через порт 8443, появится сообщение "Сервер в режиме реплика tion", указывающее, что в настоящее время (модуль) настроен в качестве реплика.

Реплики (модуль) принимают клиентские запросы Git, а эти запросы перенаправляются в активный (модуль).

Примечание. Для GitHub Enterprise Server разрешено не более 8 высокодоступных реплик (как пассивных, так и активных/геореплик).

Целевые сценарии сбоев

Используйте конфигурацию высокого уровня доступности для защиты от:

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

Конфигурация высокого уровня доступности не подходит для использования в следующих случаях:

  • Горизонтальное масштабирование. Хотя трафик можно распределять географически с помощью георепликации, производительность операций записи ограничена скоростью и доступностью основного устройства. Дополнительные сведения см. в разделе Сведения о георепликации.
  • Нагрузка CI/CD. При наличии большого количества клиентов CI, географически удаленных от основного экземпляра, можно настроить кэш репозитория. Дополнительные сведения см. в разделе Сведения о кэшировании репозитория.
  • Резервное копирование основного устройства. Реплика высокого уровня доступности не заменяет резервные копии вне сайта в плане аварийного восстановления. Некоторые формы повреждения или потери данных могут быть реплицированы немедленно с основного устройства на реплику. Чтобы обеспечить безопасный откат к стабильному прошлому состоянию, необходимо выполнять регулярные операции резервного копирования с историческими моментальными снимками.
  • Обновления без простоя. Чтобы предотвратить потерю данных и возникновение ситуаций с разделением вычислительных мощностей в контролируемых сценариях повышения уровня, переведите основное устройство в режим обслуживания и дождитесь завершения всех операций записи перед повышением уровня реплики.

Стратегии отработки отказа сетевого трафика

Во время отработки отказа необходимо отдельно настроить и контролировать перенаправление сетевого трафика с основного устройства на реплику.

Отработка отказа DNS

При отработке отказа DNS используйте короткие значения TTL в записях DNS, указывающие на основное устройство GitHub Enterprise Server. Рекомендуемое значение TTL — от 60 секунд до пяти минут.

Во время отработки отказа необходимо перевести основное устройство в режим обслуживания и перенаправлять записи DNS на IP-адрес устройства реплики. Время, необходимое для перенаправления трафика с основного устройства, будет зависеть от TTL и времени, необходимого для обновления записей DNS.

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

Подсистема балансировки нагрузки

Проект подсистемы балансировки нагрузки использует сетевое устройство для направления трафика Git и HTTP на отдельные устройства GitHub Enterprise Server. Подсистему балансировки нагрузки можно использовать для ограничения прямого трафика на устройство в целях безопасности или перенаправления трафика при необходимости оставить без изменений записи DNS. Настоятельно рекомендуется использовать подсистему балансировки нагрузки на основе TCP, поддерживающую протокол PROXY. Поиски DNS для имени узла GitHub Enterprise Server должны разрешаться в подсистему балансировки нагрузки. Рекомендуется включить изоляцию поддомена. Если изоляция поддомена включена, дополнительная запись с подстановочными знаками (*.HOSTNAME) также должна разрешаться в подсистему балансировки нагрузки. Дополнительные сведения см. в разделе Включение изоляции поддомена.

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

Вы можете отслеживать доступность GitHub Enterprise Server, проверяя код статуса, возвращаемый для URL-адреса https://HOSTNAME/status. Устройство, которое может обслуживать трафик пользователя, возвращает код статуса 200 (ОК). (модуль) может возвращать 503 (служба недоступна) для этого URL-адреса и других запросов веб-или API по нескольким причинам:

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

Вы также можете использовать панель мониторинга "Обзор репликации", доступную по адресу:

https://HOSTNAME/setup/replication

Служебные программы для управления репликацией

Люди с административным доступом SSH к экземпляру в конфигурации высокой доступности может использовать служебные программы командной строки для управления реплика. Дополнительные сведения см. в разделе Служебные программы командной строки.

Дополнительные материалы