Налаштування Elasticsearch Cross-Cluster Replication

Уявіть: у вас два дата-центри в різних регіонах, і потрібно, щоб пошук працював із мінімальною затримкою з будь-якого місця. Або ви будуєте Disaster Recovery з RTO менше хвилини та RPO в 30 секунд. Cross-Cluster Replication (CCR) в Elasticsearch — це не бекап і не failover «з коробки», а активна односпрямована реплікація: всі зміни в leader-індексі автоматично відтворюються у follower-індексі на віддаленому кластері. Ми налаштовуємо CCR під ключ: від аудиту до документації та навчання. Понад 50 проектів Elasticsearch — це дозволяє нам гарантувати результат.

Навіщо потрібна 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. Замовте консультацію — ми надішлемо комерційну пропозицію протягом дня. Звертайтеся, щоб отримати прозору оцінку вашого проекту. Зв'яжіться з нами, щоб обговорити деталі.