Несколько активных реплик могут обеспечить сокращенное расстояние до ближайшей реплики. Например, организация с офисами в Сан-Франциско, Нью-Йорке и Лондоне может запустить основное устройство в центре обработки данных недалеко от Нью-Йорка и две реплики в центрах обработки данных недалеко от Сан-Франциско и Лондона. С помощью DNS с поддержкой геолокации пользователей можно направлять на ближайший сервер, доступный и быстрее получать доступ к данным репозитория. Назначение устройства недалеко от Нью-Йорка в качестве основного устройства помогает снизить задержку между узлами, по сравнению с устройством, расположенным неподалеку от Сан-Франциско, в качестве основного, которое имеет более высокую задержку при передаче данных до Лондона.
Запросы активных прокси-серверов реплики, которые оно не может обрабатывать самостоятельно в основном экземпляре. Реплики работают как точка присутствия, которая завершает все SSL-подключения. Трафик между узлами отправляется через зашифрованное VPN-соединение, аналогично конфигурации высокого уровня доступности с двумя узлами без георепликации.
Запросы Git и конкретные запросы файлового сервера, такие как LFS и отправка файлов, можно обслуживать непосредственно из реплики без загрузки данных с основного сервера. Веб-запросы всегда маршрутизируются в основное устройство, но если реплика ближе к пользователю, запросы выполняются быстрее из-за завершения SSL в ближайшее время.
Для безупречной работы георепликации требуется Geo DNS, например служба Amazon Route 53. Имя узла для экземпляра должно разрешаться в реплику, расположенную ближе всего к расположению пользователя.
Ограничения
Для записи запросов к реплике требуется отправка данных на основное устройство и все реплики. Это означает, что производительность всех операций записи ограничена самой медленной репликой, хотя новые геореплики могут заполнять большую часть своих данных из существующих геореплик, расположенных совместно, а не из основного устройства.
Чтобы уменьшить задержку и пропускную способность, вызванную распределенными командами и большими фермами CI, не влияя на пропускную способность записи, можно настроить кэширование репозитория. Дополнительные сведения см. в разделе Сведения о кэшировании репозитория.
Георепликация не будет добавлять емкость в экземпляр GitHub Enterprise Server или устранять проблемы с производительностью, связанные с нехваткой ресурсов ЦП или памяти. Если основное устройство находится в автономном режиме, активные реплики не смогут обслуживать запросы на чтение или запись.
Примечание. Для GitHub Enterprise Server разрешено не более 8 высокодоступных реплик (как пассивных, так и активных/геореплик).
Мониторинг конфигурации георепликации
Вы можете отслеживать доступность GitHub Enterprise Server, проверяя код статуса, возвращаемый для URL-адреса https://HOSTNAME/status. Устройство, которое может обслуживать трафик пользователя, возвращает код статуса 200 (ОК). (модуль) может возвращать 503 (служба недоступна) для этого URL-адреса и других запросов веб-или API по нескольким причинам:
- Устройство является пассивной репликой, например репликой в конфигурации высокой доступности с двумя узлами.
- Устройство переведено в режим обслуживания.
- Устройство является частью конфигурации георепликации, но является неактивной репликой.
Вы также можете использовать панель мониторинга "Обзор репликации", доступную по адресу:
https://HOSTNAME/setup/replication