При переходе на гео-распределённую архитектуру many сталкиваются с тем, что 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 новых нод и восстановления после сплит-брейна.
Почему стоит выбрать 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 — распределённая система управления базами данных. Википедия
