Skip to main content
Мы публикуем частые обновления нашей документации, и перевод этой страницы, возможно, еще выполняется. Актуальные сведения см. в документации на английском языке.

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

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

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

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

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

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

Примечание. Для 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 (Служба недоступна) по нескольким причинам:

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

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

https://HOSTNAME/setup/replication

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

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

ghe-repl-setup

Команда ghe-repl-setup переводит устройство GitHub Enterprise Server в режим ожидания реплики.

  • Зашифрованный VPN-туннель WireGuard настроен для обмена данными между двумя устройствами.
  • Службы баз данных настроены для репликации и запущены.
  • Службы приложений отключены. При попытках доступа к устройству реплики по протоколу HTTP, Git или другим поддерживаемым протоколам откроется страница, информирующая о том, что устройство находится в режиме реплики, или будет выведено сообщение об ошибке.
admin@169-254-1-2:~$ ghe-repl-setup 169.254.1.1
Verifying ssh connectivity with 169.254.1.1 ...
Connection check succeeded.
Configuring database replication against primary ...
Success: Replica mode is configured against 169.254.1.1.
To disable replica mode and undo these changes, run `ghe-repl-teardown'.
Run `ghe-repl-start' to start replicating against the newly configured primary.

ghe-repl-start

Команда ghe-repl-start включает активную репликацию всех хранилищ данных.

admin@169-254-1-2:~$ ghe-repl-start
Starting MySQL replication ...
Starting Redis replication ...
Starting Elasticsearch replication ...
Starting Pages replication ...
Starting Git replication ...
Success: replication is running for all services.
Use `ghe-repl-status' to monitor replication health and progress.

ghe-repl-status

Команда ghe-repl-status возвращает состояние OK, WARNING или CRITICAL для каждого потока репликации хранилища данных. Если любой из каналов репликации находятся в состоянии WARNING, команда завершит работу с выводом кода 1. Аналогично, если любой из каналов репликации находятся в состоянии CRITICAL, команда завершит работу с выводом кода 2.

admin@169-254-1-2:~$ ghe-repl-status
OK: mysql replication in sync
OK: redis replication is in sync
OK: elasticsearch cluster is in sync
OK: git data is in sync (10 repos, 2 wikis, 5 gists)
OK: pages data is in sync

Параметры -v и -vv предоставляют сведения о состоянии репликации каждого хранилища данных:

$ ghe-repl-status -v
OK: mysql replication in sync
  | IO running: Yes, SQL running: Yes, Delay: 0

OK: redis replication is in sync
  | master_host:169.254.1.1
  | master_port:6379
  | master_link_status:up
  | master_last_io_seconds_ago:3
  | master_sync_in_progress:0

OK: elasticsearch cluster is in sync
  | {
  |   "cluster_name" : "github-enterprise",
  |   "status" : "green",
  |   "timed_out" : false,
  |   "number_of_nodes" : 2,
  |   "number_of_data_nodes" : 2,
  |   "active_primary_shards" : 12,
  |   "active_shards" : 24,
  |   "relocating_shards" : 0,
  |   "initializing_shards" : 0,
  |   "unassigned_shards" : 0
  | }

OK: git data is in sync (366 repos, 31 wikis, 851 gists)
  |                   TOTAL         OK      FAULT    PENDING      DELAY
  | repositories        366        366          0          0        0.0
  |        wikis         31         31          0          0        0.0
  |        gists        851        851          0          0        0.0
  |        total       1248       1248          0          0        0.0

OK: pages data is in sync
  | Pages are in sync

ghe-repl-start

Команда ghe-repl-stop временно отключает репликацию для всех хранилищ данных и останавливает службы репликации. Чтобы возобновить репликацию, используйте команду ghe-repl-start.

admin@168-254-1-2:~$ ghe-repl-stop
Stopping Pages replication ...
Stopping Git replication ...
Stopping MySQL replication ...
Stopping Redis replication ...
Stopping Elasticsearch replication ...
Success: replication was stopped for all services.

ghe-repl-promote

Команда ghe-repl-promote отключает репликацию и преобразует устройство реплики в основное. Устройство настроено с теми же параметрами, что и исходное основное, и все службы включены.

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

admin@168-254-1-2:~$ ghe-repl-promote
Enabling maintenance mode on the primary to prevent writes ...
Stopping replication ...
  | Stopping Pages replication ...
  | Stopping Git replication ...
  | Stopping MySQL replication ...
  | Stopping Redis replication ...
  | Stopping Elasticsearch replication ...
  | Success: replication was stopped for all services.
Switching out of replica mode ...
  | Success: Replication configuration has been removed.
  | Run `ghe-repl-setup' to re-enable replica mode.
Applying configuration and starting services ...
Success: Replica has been promoted to primary and is now accepting requests.

ghe-repl-teardown

Команда ghe-repl-teardown полностью отключает режим репликации, удаляя конфигурацию реплики.

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