О наблюдаемости для обеспечения высокой доступности
Для поддержки плана аварийного восстановления и дополнения резервных копий или повышения производительности сети и записи для географически распределенных пользователей можно настроить высокий уровень доступности для ваш экземпляр GitHub Enterprise Server. Дополнительные сведения см. в разделе "Сведения о настройке высокого уровня доступности".
После настройки высокой доступности можно заранее обеспечить избыточность, отслеживая общую работоспособность репликации и состояние каждого узла реплики экземпляра. Служебные программы командной строки можно использовать на экземпляре, панель мониторинга обзора , REST API экземпляра, или систему удаленного мониторинга, например Nagios.
При высокой доступности экземпляр использует несколько подходов для репликации данных между основными и репликами узлов. Службы баз данных, поддерживающие собственный механизм репликации, например MySQL, реплицируются с помощью собственного механизма службы. Другие службы, такие как репозитории Git, реплицируются с помощью пользовательского механизма, разработанного для GitHub Enterprise Server, или с помощью таких средств платформы, как rsync.
Мониторинг репликации из экземпляра
Чтобы отслеживать состояние репликации существующего узла реплики для ваш экземпляр GitHub Enterprise Server, подключитесь к административной консоли узла (SSH) и запустите ghe-repl-status служебную программу командной строки. Дополнительные сведения см. в разделе Служебные программы командной строки.
Вы также можете отслеживать состояние репликации на панели мониторинга обзора экземпляра. В браузере перейдите по следующему URL-адресу, заменив HOSTNAME именем узла экземпляра.
http(s)://HOSTNAME/setup/replication
Мониторинг репликации с помощью REST API
Вы можете отслеживать состояние репликации в экземпляре с помощью REST API. Дополнительные сведения см. в разделе "Управление данными GitHub Enterprise Server" в документации по REST API.
Мониторинг репликации из удаленной системы
Выходные данные из ghe-repl-status служебной программы командной строки соответствуют ожиданиям подключаемого модуля Nagios check_by_ssh. Дополнительные сведения см. в разделе Служебные программы командной строки.
Кроме того, можно отслеживать доступность экземпляра, анализируя код состояния, возвращаемый запросом по следующему URL-адресу. Например, при развертывании подсистемы балансировки нагрузки в рамках стратегии отработки отказа можно настроить проверки работоспособности, которые анализируют эти выходные данные. Дополнительные сведения см. в разделе Использование сервера GitHub Enterprise с подсистемой балансировки нагрузки.
В зависимости от того, где и как настроить мониторинг, замените HOST именем узла экземпляра или IP-адресом отдельного узла.
http(s)://HOST/status
Активный узел для георепликации, который может отвечать на запросы пользователей, вернет код 200 состояния (ОК). Запросы на отдельные узлы или имя узла экземпляра могут возвращать ошибку 503 (недоступная служба) по следующим причинам.
- Отдельный узел — это пассивный узел реплики, например узел реплики в конфигурации высокого уровня доступности двух узлов.
- Отдельный узел является частью конфигурации геореплики, но является пассивным репликой.
- Экземпляр находится в режиме обслуживания. Дополнительные сведения см. в разделе Включение и планирование режима обслуживания.
Дополнительные сведения о георепликации см. в разделе "Сведения о георепликации".
Устранение неполадок с репликацией
Чтобы устранить неполадки репликации в экземпляре, убедитесь, что репликация выполняется и что узлы могут взаимодействовать друг с другом по сети. Вы также можете использовать служебные программы командной строки для изучения подрепликации.
Репликация не выполняется
Необходимо запустить репликацию на каждом узле с помощью служебной программы командной ghe-repl-start строки. Если репликация не выполняется, подключитесь к затронутму узлу с помощью SSH, а затем выполните команду ghe-repl-start. Дополнительные сведения см. в разделе Служебные программы командной строки.
Проблемы с взаимодействием между узлами
Репликация требует, чтобы основной узел и все узлы реплики могли взаимодействовать друг с другом по сети. Как минимум, убедитесь, что порты 122/TCP и 1194/UDP открыты для двунаправленного взаимодействия между всеми узлами экземпляра. Дополнительные сведения см. в разделе Сетевые порты.
Задержка между основными и реплика узлами должна быть меньше 70 миллисекунд. Не рекомендуется настраивать брандмауэр между сетями узлов. Можно использовать ping или другую программу администрирования сети для проверки сетевого подключения между узлами.
Недорепликация
При выполнении ghe-repl-status служебной программы командной строки на узле реплики и репозиториях Git, сетях репозитория или объектах хранилища недостаточно реплицируются, один или несколько узлов реплик не полностью синхронизированы с основным узлом. Если основной узел не может взаимодействовать с узлами-репликами, может возникнуть ошибка репликации или если узлы реплики не могут взаимодействовать с основным узлом.
Если вы недавно настроили высокую доступность или георепликацию, начальная синхронизация займет некоторое время. Длительность начальной синхронизации зависит от того, сколько данных существует и сетевые условия.
Реплицированные репозитории или сети репозитория
Вы можете просмотреть состояние репликации конкретного репозитория, подключився к узлу и выполнив следующую команду command, заменив OWNER владельцем репозитория и репозиторием именем репозитория.
ghe-spokesctl check OWNER/REPOSITORY
ghe-spokesctl info OWNER/REPOSITORY
Кроме того, если вы хотите просмотреть состояние репликации сети репозитория, замените NETWORK-ID/REPOSITORY-ID номером сетевого идентификатора и идентификатора репозитория.
ghe-spokesctl check NETWORK-ID/REPOSITORY-ID
ghe-spokesctl info NETWORK-ID/REPOSITORY-ID
Нереплицированные объекты хранилища
Состояние определенного объекта хранилища можно просмотреть, подключився к узлу и выполнив следующую команду, заменив идентификатор объекта идентификатором объекта.
ghe-storage info OID
Получение поддержки от GitHub
Если вы просмотрите рекомендации по устранению неполадок репликации и продолжаете сталкиваться с проблемами в вашем экземпляре, соберите следующие сведения, а затем обратитесь к нам, перейдя к Поддержка GitHub Enterprise.
- На каждом затронутом узле выполните команду
ghe-repl-status -vv, а затем скопируйте выходные данные в билет. Дополнительные сведения см. в разделе Служебные программы командной строки. - На каждом затронутом узле создайте пакет поддержки для присоединения к вашему билету. Дополнительные сведения см. в разделе Предоставление данных для службы поддержки GitHub.