Налаштування кластера Cassandra (multi-datacenter)
При переході на гео-розподілену архітектуру багато хто стикається з тим, що Cassandra кластер, який працює в одному датацентрі, перестає справлятися з навантаженням або вимогами відмовостійкості. Ми допомагаємо налаштувати multi-datacenter конфігурацію під ключ — вона витримує втрату цілого датацентру без втрати даних і простою. Наш досвід — 5+ років, понад 30 проєктів з multi-datacenter Cassandra. За цей час ми накопичили методики, які дозволяють уникнути типових помилок: неправильного вибору snitch, невірних seed-вузлів та неоптимальних рівнів консистентності. Оцінимо ваш проєкт і запропонуємо архітектуру з урахуванням ваших RPO та RTO.
Multi-datacenter Cassandra — це не просто «поставити ноди в двох місцях». Це окрема дисципліна: вибір snitch, стратегія реплікації, консистентність запитів, обробка network partition між датацентрами. Без розуміння CAP-теореми в контексті Cassandra мультидатацентровий кластер перетворюється на машину для генерації hint-черг та stale-даних. Нижче розбираємо ключові аспекти багатоцентрового налаштування.
Як забезпечити гео-надлишковість?
Для одиночного датацентру використовують SimpleStrategy. Для мультидатацентрової конфігурації — тільки NetworkTopologyStrategy. Вона дозволяє задати різний replication factor для кожного датацентру:
CREATE KEYSPACE app_data WITH REPLICATION = { 'class': 'NetworkTopologyStrategy', 'DC1': 3, 'DC2': 3 }; RF=3 у кожному датацентрі означає: кластер переживе повну втрату одного датацентру без втрати даних. При DC1 в Amsterdam та DC2 в Frankfurt — це реальна гео-надлишковість. Порівняйте: при використанні SimpleStrategy втрата одного датацентру призвела б до втрати всіх даних у ньому.
Який snitch обрати для production?
Cassandra повинна знати, в якому датацентрі та на якій стійці знаходиться кожна нода. Це робота snitch. GossipingPropertyFileSnitch — стандартний вибір для production. Кожна нода читає /etc/cassandra/cassandra-rackdc.properties:
dc=DC1 rack=RACK1 У cassandra.yaml на всіх нодах вказуємо однакове ім'я кластера та seeds з обох датацентрів:
---
cluster_name: 'global-cluster'
endpoint_snitch: GossipingPropertyFileSnitch
seed_provider:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
parameters:
- seeds: "10.0.1.10,10.0.1.11,10.1.1.10,10.1.1.11"
---Seeds повинні бути в обох датацентрах — це важливо для bootstrap нових нод та відновлення після split-brain.
Чому варто обрати LOCAL_QUORUM?
Тут починаються реальні архітектурні рішення. QUORUM рахує кворум від усіх реплік усіх датацентрів. При RF=3 у двох датацентрах (6 реплік разом) — потрібне підтвердження від 4 реплік. Якщо один датацентр недоступний, запис падає. Для більшості сценаріїв це занадто суворо.
LOCAL_QUORUM рахує кворум тільки в локальному датацентрі. Запис успішний, якщо більшість локальних реплік підтвердили. Це стандартний вибір для мультидатацентрового кластера — додаток пише з LOCAL_QUORUM, читає з LOCAL_QUORUM, і при втраті датацентру продовжує працювати. Фактично LOCAL_QUORUM дає приріст продуктивності в 2 рази порівняно з глобальним QUORUM при відмові одного датацентру: для запису достатньо 2 з 3 реплік у локальному DC, а не 4 з 6.
EACH_QUORUM вимагає кворуму в кожному датацентрі — використовується, коли не можна допустити розходження даних між датацентрами навіть тимчасово. На практиці: write з LOCAL_QUORUM, read з LOCAL_QUORUM. Якщо потрібно гарантувати читання свіжих даних в іншому регіоні — SERIAL або LOCAL_SERIAL для lightweight transactions.
Порівняння рівнів консистентності:
| Рівень | Кворум | Продуктивність при втраті DC |
|---|---|---|
| QUORUM | Глобальний | Запис падає |
| LOCAL_QUORUM | Локальний | Працює |
| EACH_QUORUM | По всьому DC | Працює, але повільніше |
Як ми це робимо: кейс з практики
Нещодавно ми розгортали multi-datacenter для клієнта з нодами в AWS (us-east-1) та Azure (west-europe). Вимога: RPO < 1 хвилина, автоматичне перемикання при відмові одного DC. Ми використали GossipingPropertyFileSnitch, RF=3 у кожному датацентрі, LOCAL_QUORUM для запису та читання. Для мінімізації затримок налаштували cross-datacenter repair з throttling 50 MB/s. В результаті при відмові AWS-регіону додаток продовжив роботу без втрати даних та ручного втручання. Економія часу на відновлення — до кількох годин вручну.
Типові проблеми мультидатацентрового кластера
- Різні версії Cassandra в датацентрах. При rolling upgrade потрібно оновлювати ноди по одній, не допускаючи несумісних версій протоколу між датацентрами. Cassandra підтримує rolling upgrade тільки між сусідніми minor-версіями.
- Неправильні seeds. Якщо seeds вказують тільки на один датацентр, ноди другого датацентру при рестарті можуть не бачити перший. Seeds повинні бути в кожному DC.
- Firewall між датацентрами. Cassandra потребує порт 7000 (міжнодова взаємодія) та 9042 (CQL) між усіма нодами всіх датацентрів. Часткове закриття призводить до split-brain.
- Timezone при TTL. Cassandra обчислює TTL в UTC. Якщо сервери в різних датацентрах мають різні timezone і час не синхронізований через NTP — дані з TTL видаляються несинхронно.
Команди для repair:
# Repair тільки локального датацентру
nodetool repair -dc DC1 -pr keyspace_name
# Full repair кластера (навантажить міжцентровий канал!)
nodetool repair keyspace_nameМіжцентровий repair — важка операція. На кластерах з терабайтами даних запускати в години мінімального навантаження, з throttling:
nodetool setstreamthroughput 50 nodetool setcompactionthroughput 50 Процес розгортання
Починаємо з одного датацентру — розгортаємо кластер, перевіряємо реплікацію, навантажуємо тестами. Тільки після цього додаємо другий датацентр.
При додаванні другого DC: запускаємо ноди другого датацентру з тими ж seeds, чекаємо поки gossip розійдеться (nodetool status показує ноди обох DC), потім запускаємо nodetool rebuild -- DC1 на кожній ноді DC2 для копіювання даних з першого датацентру. Після rebuild оновлюємо keyspace для включення реплікації в DC2 і запускаємо repair.
| Етап | Термін |
|---|---|
| Аудит поточної топології (якщо є) | 0.5 дня |
| Розгортання першого DC | 1-2 дні |
| Додавання другого DC + rebuild | 1-2 дні |
| Тестування failover + документація | 1 день |
Що входить в роботу
- Аудит поточної архітектури та рекомендації щодо топології.
- Розгортання кластера в одному або кількох датацентрах.
- Налаштування NetworkTopologyStrategy, snitch, рівнів консистентності.
- Конфігурація моніторингу (Prometheus + Grafana) та алертів.
- Документація з експлуатації та runbook для failover.
- Навчання команди замовника (2-3 сесії).
- Пост-релізна підтримка 2 тижні.
Вартість розраховується індивідуально після аналізу вимог до RPO/RTO та обсягу даних. Зв'яжіться з нами для оцінки проєкту — отримайте консультацію щодо вашої архітектури.
Apache Cassandra — розподілена система управління базами даних. Вікіпедія
