Конфигурирование кросс-кластерной репликации Elasticsearch для высокой доступности

Вы можете сделать поиск более устойчивым во время обслуживания, отказа и обновлений при развертывании с высокой доступностью, включив Elasticsearch Cross-Cluster Replication (CCR).

В этой статье

О кросс-кластерной репликации Elasticsearch

GitHub Enterprise Server Использует Elasticsearch для поиска по проблемам, pull-запросам, репозиториям, страницам проектов и релизов, а также подсчётам, отображаемым по всему веб-интерфейсу. Поскольку поиск является центральным элементом продукта, надёжность Elasticsearch напрямую влияет на повседневное управление вашим инстансом.

В конфигурации с высокой доступностью (HA) GitHub Enterprise Server используется модель лидера/последователя. Основное устройство принимает все записи и трафик, а реплики остаются синхронизированными как резервные устройства только для чтения, которые могут взять на себя управление при отказе основного. Дополнительные сведения см. в разделе Сведения о настройке высокого уровня доступности.

В ранних релизах Elasticsearch не поддерживал эту модель лидера/последователя напрямую. Для воспроизведения поисковых данных GitHub Enterprise Server был запущен один кластер Elasticsearch, охватывающий основные и реплики. Этот подход работал, но вводил ряд проблем: Elasticsearch мог переместить первичный шард (шард, отвечающий за приём и проверку записей) на реплику. Если эта реплика затем была отключена для обслуживания, экземпляр мог перейти в заблокированное состояние, потому что копия ждала восстановления Elasticsearch, а Elasticsearch не мог стать здоровым, пока реплика не воссоединится.

Elasticsearch Cross-Cluster Replication (CCR) устраняет эту зависимость. Вместо одного кластера, охватывающего каждое устройство, каждое устройство работает как независимый одноузловый кластер Elasticsearch. CCR затем реплицирует индексные данные между этими кластерами, используя нативно поддерживаемый паттерн лидер/последователь. Данные копируются только после того, как они были надёжно сохранены в базовые сегменты Lucene, поэтому реплики всегда следуют за данными, которые были безопасно записаны. В результате критически важный первичный осколок больше не может оказаться на реплике только для чтения.

Benefits

  • Меньше заблокированных обновлений и окна обслуживания. Устранение круговой зависимости между первичным и репликальным устройствами во время обслуживания снижает риск заедания экземпляра.
  • Более сильная защита данных. Данные воспроизводятся только после их надёжного сохранения, что помогает предотвратить повреждение индекса во время отказа.
  • Более простые операции. Схема снижает необходимость ручного ремонта индекса, которые ранее происходили при выполнении технических шагов вне порядка.

Availability

Elasticsearch CCR поддерживается начиная с GitHub Enterprise Server версии 3.19.1. Эта функция является опциональной. GitHub планирует сделать CCR стандартной архитектурой поиска HA в течение следующих двух лет, чтобы у вас было время протестировать её и дать обратную связь, прежде чем она станет стандартной.

Requirements

Перед тем как включить CCR, уточните следующее.

  • Ваш экземпляр работает GitHub Enterprise Server с версией 3.19.1 или выше.
  • Ваш экземпляр настроен на высокую доступность с минимум двумя устройствами (основным и одной или несколькими репликами).
  • У вас обновлённая GitHub Enterprise Server лицензия, включающая право на Elasticsearch, требуемое для CCR. Свяжитесь Команда по продажам GitHub с вашим предприятием или Служба поддержки GitHub попросите включить его для новой лицензии, затем скачайте обновлённый файл лицензии.

Внимание: Когда CCR включён, для проверки предпалётного обновления требуется действующая лицензия с поддержкой CCR. Если флаг включён, а проверка лицензии не проходит, обновление не продолжится. Убедитесь, что ваша обновлённая лицензия установлена, прежде чем включать функцию или обновлять. Если вы не уверены, включает ли ваша лицензия право на Elasticsearch, свяжитесь Служба поддержки GitHubс .

Включение кросс-кластерной репликации Elasticsearch

Примечание: Миграция может занять значительное время в зависимости от размера вашего экземпляра, поскольку данные поиска консолидируются на основной до повторного запуска репликации. Планируйте включить CCR в период обслуживания и сначала протестировать процесс в непроизводственной среде. Дополнительные сведения см. в разделе Обновление экземпляра.

  1. Свяжитесь Служба поддержки GitHub и запросите доступ к новой архитектуре поиска HA. GitHub позволит вашему предприятию скачать необходимую лицензию с поддержкой CCR.

  2. Скачайте обновлённую лицензию и загрузите её в свой инстанс. Дополнительные сведения см. в разделе Скачивание лицензии для GitHub Enterprise.

  3. На основном устройстве включите эту функцию.

    ghe-config app.elasticsearch.ccr true

  4. Примените конфигурацию, запустив запуск конфигурации или обновив экземпляр до версии 3.19.1 или новее.

    ghe-config-apply

  5. Когда экземпляр перезапускается, Elasticsearch переносит установку на новый метод репликации. Эта миграция консолидирует поисковые данные на первичном сервере, завершает кластер, ранее использовавший устройства, и восстанавливает репликацию с помощью CCR. Во время миграции GitHub Enterprise Server привязывает подписчиков к вашим существующим поисковым индексам и включает правило автоследования, чтобы любые индексы, созданные в будущем, выполнялись автоматически.

Использование кросс-кластерной репликации Elasticsearch

Проверка репликации

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

Отказ и восстановление после катастроф

Вы продолжаете использовать стандартные утилиты для репликации высокой доступности для управления репликами и отказа. Дополнительные сведения см. в разделе [AUTOTITLE и Инициализация отработки отказа на устройство реплики](/admin/monitoring-and-managing-your-instance/configuring-high-availability/recovering-a-high-availability-configuration).

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

Отключение кросс-кластерной репликации Elasticsearch

Внимание: Не отключайте CCR на производственном экземпляре без указаний от Служба поддержки GitHub. Отключение CCR — это не рутинная операция самообслуживания. Отключение функции может привести к удалению реплик данных Elasticsearch при возвращении в предыдущий режим.

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

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