GitHub представила новый режим высокой доступности для GitHub Enterprise Server (GHES), который делает поисковую инфраструктуру быстрее и устойчивее для клиентов, использующих High Availability (HA) конфигурации.
Поиск затрагивает почти все пользовательские сценарии в GitHub: от строк поиска и фильтрации в Issues до страниц релизов и проектов, а также подсчёта задач и pull request. Поэтому инженеры GitHub в течение последнего года переработали архитектуру поиска, чтобы администраторы тратили меньше времени на сопровождение GHES и больше — на задачи пользователей.
Ранее администраторам GitHub Enterprise Server приходилось внимательно следить за состоянием поисковых индексов — специальных таблиц базы данных, оптимизированных под поиск. Если во время обслуживания или обновления нарушалась последовательность действий, индексы могли повреждаться или блокироваться, что вызывало проблемы при апгрейдах.
HA-конфигурации GHES используют схему с основным узлом и репликами: primary-сервер принимает весь трафик и записи, а реплики остаются доступными только для чтения и могут взять нагрузку в случае сбоя. Эта модель пронизывает всю работу GitHub Enterprise Server.
На старых версиях Elasticsearch, выбранного поискового движка, GitHub был вынужден разворачивать общий кластер Elasticsearch между primary и replica-узлами. Это упрощало репликацию данных и давало выигрыш в производительности, так как каждый узел обрабатывал поисковые запросы локально.
Со временем минусы такой схемы перевесили плюсы. Например, Elasticsearch мог в любой момент перенести primary-shard, принимающий записи, на реплику. Если эту реплику затем выключали для обслуживания, GHES мог переходить в заблокированное состояние: реплика ждёт, когда Elasticsearch станет здоровым, а Elasticsearch не может прийти в норму без возврата реплики.
Инженеры GitHub несколько релизов пытались стабилизировать этот режим: добавляли проверки состояния Elasticsearch, процессы для исправления «расходящихся» состояний и разрабатывали систему «зеркалирования поиска», чтобы уйти от кластерного режима. Однако надёжная репликация баз данных требует строгой согласованности, и этих попыток было недостаточно.
После многолетней работы GitHub перешёл к использованию функции Elasticsearch Cross Cluster Replication (CCR) для поддержки HA-инсталляций GHES. Это позволило перейти на конфигурацию из нескольких независимых одновузловых кластеров Elasticsearch вместо одного общего кластера.
CCR даёт возможность передавать данные индексов между узлами контролируемым образом и средствами самого Elasticsearch. Данные копируются после их записи в сегменты Lucene, базовый хранилище Elasticsearch. Это гарантирует, что репликация затрагивает уже надёжно сохранённые данные в кластере.
Иными словами, благодаря поддержке модели «ведущий/ведомый» в Elasticsearch администраторы GHES больше не окажутся в ситуации, когда критичные данные оказываются на узлах «только для чтения» без корректной репликации.
У Elasticsearch есть auto-follow API, но оно работает только для индексов, созданных после настройки политики. HA-инсталляции GHES используют набор индексов, который живёт долго, поэтому GitHub добавил специальный начальный шаг: привязка «ведомых» индексов к уже существующим и включение auto-follow для будущих индексов. Это оформлено в виде нового рабочего процесса.
Помимо начального подключения CCR, GitHub разработал специальные внутренние сценарии для фейловера, удаления индексов и обновлений версий. Elasticsearch отвечает только за репликацию документов, а полный жизненный цикл индекса GitHub реализует самостоятельно.
Чтобы включить новый режим CCR, администратору GHES нужно обратиться в поддержку GitHub по адресу support@github.com и сообщить о желании использовать новый HA-режим. Поддержка настроит организацию так, чтобы можно было скачать необходимую лицензию.
После получения лицензии необходимо задать параметр конфигурации `ghe-config app.elasticsearch.ccr true`, а затем выполнить `config-apply` или обновиться до версии 3.19.1 — это первый релиз GHES с поддержкой новой архитектуры поиска.
При перезапуске GitHub Enterprise Server Elasticsearch автоматически переведёт установку на новую схему репликации: данные будут консолидированы на primary-узлах, межузловой кластер будет отключён, а репликация возобновится с использованием CCR. Время миграции зависит от размера инсталляции GHES.
Новый HA-режим пока опционален, но в течение ближайших двух лет GitHub планирует сделать его режимом по умолчанию. Компания хочет собрать максимум отзывов от администраторов GHES, поэтому уже сейчас предлагает тестировать новую архитектуру поиска.
GitHub приглашает клиентов, использующих High Availability GitHub Enterprise Server, перейти на новый режим, чтобы улучшить надёжность и управляемость поиска и сократить операционные затраты по сопровождению сервера.
Источник: материалы GitHub.
