Ответы на распространенные вопросы о репликах высокого уровня доступности

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

В этой статье

Типы реплик и возможности

Какие типы реплик используются в развертывании высокого уровня доступности?

Существует три типа реплик в развертывании с высоким уровнем доступности (HA):

  • Пассивные реплики

  • Активная реплика

  • Реплики кэша (так называемые кэши репозитория).

            **Пассивные реплики** просто синхронизируют данные из основного экземпляра и не обрабатывают трафик GitHub. Однако при необходимости операторы могут повысить уровень пассивной реплики до первичной.

        **Геореплика** — это пример **активной реплики** (эти термины часто используются как взаимозаменяемые). Активные реплики синхронизируют данные с первичного сервера. Активная реплика также может обрабатывать трафик GitHub напрямую или передавать их на первичную реплику.

        **Реплики кэша** синхронизируют данные Git и Git Large File Storage (Git LFS) с базовым хранилищем. Реплики кэша предназначены для сценариев с большим количеством операций чтения, таких как фермы CI. Они принимают только операции чтения/выборки/клонирования для репозиториев, у которых есть локальная копия. Для любых других репозиториев они вернут ошибку. Они всегда отклоняют push-уведомления с сообщением об ошибке.

Можно ли повысить уровень всех типов реплик до основных?

Только пассивные и активные реплики могут быть повышены до основных. Реплики кэша не могут быть повышены до основных.

Может ли одно развертывание иметь все реплики?

Одно развертывание может включать в себя активные, пассивные реплики и реплики кэша одновременно.

Ожидает ли основной экземпляр реплики операций записи?

Основной экземпляр не ожидает реплики для записи. В HA push-запрос записывает данные в первичную реплику, а также во все пассивные и активные реплики. Однако, поскольку основной узел является единственным голосующим узлом, отправка считается принятой, если она успешно выполняется на первичном узле.

Требования к связи и сети

Какие сущности могут взаимодействовать с активными репликами?

Основной экземпляр взаимодействует с активными репликами для синхронизации данных и обработки любых запросов, которые активные реплики передают обратно в первичный экземпляр. GitHub веб, API и трафик Git (как от людей, так и от автоматизации) можно направлять непосредственно на активные реплики. Именно поэтому важно настроить DNS так, чтобы трафик, предназначенный для активной реплики, действительно доходил до нее.

Какие сущности могут взаимодействовать с пассивными репликами?

Основной экземпляр взаимодействует с пассивными репликами для синхронизации данных. Пассивные реплики не получают и не обрабатывают другой трафик GitHub.

Какие сущности могут взаимодействовать с репликами кэша?

Трафик Git, доступный только для чтения, в основном из автоматизаций, таких как CI-фермы, может направляться в реплики кэша и обрабатываться ими. Чтобы включить эту возможность, необходимо настроить DNS так, чтобы он направлял соответствующий трафик на реплику кэша. Реплики кэша не предназначены для обслуживания пользовательского трафика или отправки трафика.

Должны ли реплики располагаться рядом с основным?

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

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

Каковы требования к задержке между первичным сервером и репликой?

Первичная и активная реплики имеют строгие требования к задержке. Первичные и пассивные реплики, а также первичные реплики и реплики кэша имеют рекомендуемые требования к задержке. Дополнительные сведения см. в разделе [AUTOTITLE и Создание реплики с высоким уровнем доступности](/admin/monitoring-and-managing-your-instance/configuring-high-availability/monitoring-a-high-availability-configuration#communication-issues-between-nodes). Сетевые задержки, превышающие обязательные и рекомендуемые значения, могут привести к постоянному отставанию реплик.

Административный доступ и мониторинг

Доступен ли Консоль управления на репликах?

Функция Консоль управления недоступна ни на пассивных репликах, ни на репликах кэша. Он доступен только на активных репликах (активные реплики перенаправляют большую часть запросов на первичную).

Можно ли использовать SSH в реплики?

Оператор с доступом к административной оболочке может подключаться по SSH к любой из реплик. Операторы могут добавить свои публичные ключи в новую реплику с помощью Консоль управления до того, как реплика будет добавлена в кластер. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).

Как работают пакеты поддержки для реплик?

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

Можно ли и как контролировать реплики?

Все реплики можно отслеживать. Элемент Консоль управления на основном экземпляре предоставляет панели мониторинга для всех узлов, включая пассивные и активные узлы реплики в развертывании.

Кроме того, вы можете экспортировать метрики и журналы со всех узлов в развертывании на сторонние платформы мониторинга.

Сведения о том, как отслеживать состояние репликации данных между узлами реплики, см. в разделе AUTOTITLE.

Разница между репликами и резервными копиями

Реплики и резервные копии — это одно и то же?

Реплики и резервные копии — это не одно и то же. Они служат разным целям.

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

Реплики сами по себе являются экземплярами GitHub Enterprise Server. Backup-host не является установкой GitHub Enterprise Server.

Какое программное обеспечение работает на репликах?

Реплики — это отдельная установка GitHub Enterprise Server. Основной экземпляр и все реплики должны работать под управлением одной и той же версии GitHub Enterprise Server.

Операции по техническому обслуживанию

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

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

Горячее исправление может быть выполнено с минимальными перебоями. Вы можете сначала выполнить горячий патч для основного, а затем для реплик.

Выбор правильного типа реплики

Когда использовать пассивные реплики?

Если вам требуется высокий уровень доступности и вы хотите использовать экземпляр up-to-date для отработки отказа в случае сбоя основного сервера, вам подойдут пассивные реплики. Большинство наших клиентов используют пассивные реплики.

Когда следует использовать геореплики?

Если у вас есть географически распределенный штат разработчиков, настройка геореплик может помочь пользователям в определенных регионах. Например, представьте себе многонациональную компанию с инженерными командами в Северной Америке, Европе и Азии. Если основной экземпляр расположен в США, развертывание геореплики в Европе может значительно повысить производительность операций чтения для европейских пользователей. Однако этого нельзя сказать об операциях записи. Перед завершением операции все операции записи должны размещаться как в георепликах, так и в первичной реплике. Географическое расстояние между основным сервером и репликами увеличивает задержку, что может замедлить операции записи.

Когда следует использовать реплики кэша?

Если сценарии использования имеют большое количество операций чтения, например CI-фермы, реплики кэша лучше всего подходят. Вот несколько сценариев, в которых реплики кэша имеют смысл:

  • Компания с небольшим вспомогательным офисом в регионе с ограниченной пропускной способностью к основному дата-центру, где разработчикам нужен более быстрый доступ к репозиториям, но не требуется доступ на запись.
  • Организация, выполняющая задания CI/CD в удаленном центре обработки данных, которой необходимо часто клонировать репозитории и которая хочет свести к минимуму сетевой трафик к основному экземпляру.

По своей сути, реплики кэша имеют свои недостатки. Реплики кэша в конечном итоге согласованы и не всегда обслуживают последнее содержимое репозитория. Тем не менее, существуют веб-перехватчики на случай, если последние изменения попадут на реплику, чтобы можно было запустить соответствующие задания CI/CD. Очень немногие клиенты GitHub используют реплики кэша.