Проблема миграции больших кластеров на Cassandra

В сфере искусственного интеллекта произошло заметное событие. dbraincloud 25 минут назад Проблема миграции больших кластеров на Cassandra Средний 13 мин 618 Блог компании dBrain Базы данных * DevOps * IT-инфраструктура * Микросервисы * Кейс Миграция Cassandra выглядит простой задачей ровно до того момента, пока кластер не становится действительно большим. На определенном масштабе перестают работать привычные рецепты. Перенос и восстановление из snapshot’ов оказывается слишком медленным, репликация между дата-центрами требует заметных ресурсов и не всегда возможна, а процедура repair начинает измеряться не минутами и даже не часами.

В результате главный вопрос миграции звучит уже не «как перенести данные», а «как сделать это с минимальным риском и простоями». В платформе контейнеризации dBrain. cloud нам пришлось пройти через несколько сценариев миграции Cassandra на разных проектах и в различных средах: от перехода со StatefulSet на оператор до переноса кластеров между дата-центрами.

Технические детали

За это время сформировалось несколько практических подходов, каждый из которых работает только в определенных условиях. Разберем, где достаточно snapshot, когда стоит использовать междатацентровую репликацию, а в каких случаях лучше вообще отказаться от переноса исторических данных. Как работала Cassandra в dBrain.

cloudПервая версия сервиса БД Cassandra в платформе dBrain. cloud была максимально простой. Каждый кластер представлял собой обычный StatefulSet в Kubernetes.

Мы собирали собственный образ Cassandra, использовали стандартные абстракции k8s, такие как ConfigMap, Secrets, Service, подключали экспортер метрик в виде сайдкара. Никаких операторов тогда не было, только наш специализированный контроллер-менеджер развертывания БД. Данный контроллер-менеджер (первая версия нашего сервиса управления Cassandra) по jinja2-шаблону генерировал и применял в namespace весь набор объектов кластера, включая, помимо перечисленных выше, еще ServiceAccount и Role/RoleBinding, а параметры cassandra.

Отраслевые последствия

options (heap, concurrent_, memtable_, commitlog) рассчитывал исходя из выданных кластеру CPU, RAM и объема диска. Операции над нодами — repair, cleanup, compaction, flush, garbage collect, drain, decommission, removenode, очистка snapshot’ов и truncate hints — менеджер выполнял через JMX (по Jolokia) как по запросу, так и по расписанию (через создаваемые k8s CronJob). А масштабирование, изменение ресурсов и heap, ресайз дисков и правку конфигов с rolling-restart — уже через Kubernetes API.

Автоматического резервного копирования в самом сервисе при этом не было: снапшоты при необходимости снимались вручную. Фактически кластером управляли сама Cassandra и базовые механизмы Kubernetes. Узлы находили друг друга по gossip-протоколу, используя headless-сервис, данные хранились на постоянных томах, а все операции по обновлению и сопровождению выполнялись вручную.

Такой подход долгое время нас устраивал. Но по мере роста количества кластеров и их объемов сопровождать инфраструктуру становилось все сложнее.

Событие, по словам экспертов, усилит конкуренцию в сфере ИИ.