Настройка Elasticsearch Cross-Cluster Replication

Представьте: у вас два дата-центра в разных регионах, и нужно, чтобы поиск работал с минимальной задержкой из любого места. Или вы строите Disaster Recovery с RTO менее минуты и RPO в 30 секунд. Cross-Cluster Replication (CCR) в Elasticsearch — это не бэкап и не failover «из коробки», а активная однонаправленная репликация: все изменения в leader-индексе автоматически воспроизводятся в follower-индексе на удалённом кластере. Мы настраиваем CCR под ключ: от аудита до документации и обучения. Более 50 проектов Elasticsearch за 5 лет работы — это позволяет нам гарантировать результат.

Зачем нужна Cross-Cluster Replication (CCR)?

CCR решает три сценария: геораспределение поиска (читаем из ближайшего кластера), Disaster Recovery с автоматическим переключением и read-scaling (снятие нагрузки с leader). В отличие от snapshot/restore, задержка репликации — секунды, а не минуты. Экономия от внедрения CCR достигает 70% на операционных расходах по сравнению с ручным восстановлением. Наши клиенты экономят до 80% времени на настройку благодаря готовым конфигурациям.

Как работает CCR изнутри?

Follower-индекс на целевом кластере постоянно читает операции из translog leader-индекса через специальный API. Это не snapshotting — изменения реплицируются практически в реальном времени (задержка обычно 2–5 секунд, зависит от сети). Требования: оба кластера одной мажорной версии (с некоторыми исключениями для minor) и лицензия Basic или выше (Basic достаточно с Elasticsearch 7.8+). Официальное руководство Elasticsearch описывает это подробно.

Первый шаг — настройка remote cluster на follower-кластере:

PUT _cluster/settings
{
  "persistent": {
    "cluster.remote.leader-cluster.seeds": [
      "es-master-01.leader.internal:9300",
      "es-master-02.leader.internal:9300",
      "es-master-03.leader.internal:9300"
    ],
    "cluster.remote.leader-cluster.transport.ping_schedule": "30s"
  }
}

Проверяем связность. Если connected: true — можно создавать follower-индекс.

Как создать follower-индекс и auto-follow?

Для одного индекса:

PUT /follower-logs-000001/_ccr/follow
{
  "remote_cluster": "leader-cluster",
  "leader_index": "logs-000001",
  "settings": {
    "index.number_of_replicas": 1
  },
  "max_read_request_operation_count": 5120,
  "max_outstanding_read_requests": 12,
  "max_read_request_size": "32mb",
  "max_write_request_operation_count": 5120,
  "max_write_buffer_count": 512,
  "max_retry_delay": "500ms",
  "read_poll_timeout": "1m"
}

Для автоматической репликации всех новых индексов по паттерну — Auto-follow pattern:

PUT /_ccr/auto_follow/logs-pattern
{
  "remote_cluster": "leader-cluster",
  "leader_index_patterns": ["logs-*"],
  "follow_index_pattern": "{{leader_index}}",
  "settings": {
    "index.number_of_replicas": 1
  }
}

С auto-follow каждый новый индекс на leader-кластере, подходящий под паттерн, автоматически получает follower на целевом кластере. Это критично при использовании ILM rollover — без auto-follow придётся вручную создавать follower для каждого нового индекса после rollover.

Почему интеграция CCR с ILM вызывает проблемы?

Самая частая проблема при настройке CCR поверх ILM — ILM на leader-кластере делает rollover и shrink, а follower-кластер не успевает реплицировать данные до того, как индекс уходит в warm/freeze. Follower-индекс при этом «отстаёт» и застревает. Решение — использовать CCR pause перед shrink на лидере, или настроить wait_for_data_replication_timeout в ILM политике leader-кластера. Либо — держать follower в «горячем» состоянии дольше, применяя отдельную ILM-политику только на follower-кластере.

На follower-кластере индекс read-only по умолчанию. Перед тем как переключить приложение на follower (в случае disaster recovery), нужно промотировать его до обычного индекса:

POST /follower-logs-000001/_ccr/unfollow 

После этого индекс становится обычным writable-индексом, но репликация с leader прекращается.

Как мониторить репликацию?

GET /follower-logs-000001/_ccr/stats 

Смотрим follower_global_checkpoint vs leader_global_checkpoint — разница показывает отставание в операциях. Если разрыв растёт — проблема с сетью или производительностью follower-нод. Prometheus-алерты через elasticsearch-exporter:

• elasticsearch_ccr_follower_operations_written должен расти постоянно (в норме > 100 ops/s)
• elasticsearch_ccr_follower_time_since_last_read_millis > 60000 — репликация остановилась

Типичные сложности при настройке CCR

CCR требует, чтобы оба кластера были доступны по transport-порту (9300). В облаке это означает VPN или VPC Peering между регионами — не просто открыть 443. Latency между кластерами прямо влияет на задержку репликации. При большой начальной репликации (сотни GB) follower-индекс проходит фазу восстановления через snapshot — это медленнее, чем транзакционная репликация. Нужно учитывать при планировании окна первоначальной синхронизации (обычно 1–2 часа на 100 GB).

Сравнение CCR с другими подходами

CCR лучше snapshot/restore в 10–100 раз по RTO и RPO, но требует правильно настроенной сети и ILM-интеграции.

Требования к сети для CCR

Что входит в работу

Процесс и сроки

Настройка CCR между двумя кластерами с нуля — 2-3 дня: настройка remote cluster, проверка сети и TLS, создание auto-follow паттернов, интеграция с ILM, тестирование failover (промоут follower → переключение трафика → откат). Если кластера ещё нет — добавьте время на его развёртывание (1-2 дня).

Стоимость рассчитывается индивидуально после аудита текущих кластеров и требований по RTO/RPO. Закажите консультацию — мы пришлём коммерческое предложение в течение дня. Обращайтесь, чтобы получить прозрачную оценку вашего проекта. Свяжитесь с нами, чтобы обсудить детали.