Это первая статья из цикла, рассказывающая о практике развёртывания небольшого кластера Cassandra: от дефолтного деплоя “из коробки“ до готовности к производственной эксплуатации.
Apache Cassandra — это распределенная высокомасштабируемая NoSQL СУБД, предназначенная для надежного хранения огромных массивов данных. Cassandra используют такие гиганты как Netflix, Apple, Instagram*, Twitter* (*Запрещены в РФ), Spotify и множество других известных компаний и брендов.
Здесь не будет рассказа об архитектуре Cassandra — о ней опубликовано очень много статей и снято настолько же много видео. Особо отмечу суперский «Cassandra Day Russia» на Youtube на русском языке, записанный нашими соотечественниками из Datastax. Поэтому, если вы вообще ничего не знаете о Cassandra, то посмотрите, например, вебинар «Введение в фундаментальные принципы и основы Apache Cassandra», а уже затем добро пожаловать в подготовку боевого кластера.
Что касается самого кластера, который мы будем разворачивать, то мне достался раскатанный через Ansible деплой на 5 хост‑машин с единственным образом Cassandra 4.0 в docker‑compose и дефолтными настройками. Пятерка хост‑машин представляет собой Core i5 / 64 GB RAM / 2 x 512 GB NVMe SSD / 16 TB SATA c Debian 11.
Пожалуй, это небольшой кластер (большие кластера Cassandra могут включать десятки и сотни нод, раскиданных по многим ДЦ в разных странах мира), однако для наших задач он вполне достаточен и главное решает потребности бизнеса.
Приступим?
Есть ли у вас план, мистер Фикс?
Конечно, и вот что у нас по плану:
Анализ рабочей нагрузки и требований
Разработка схемы данных
Настройка хостовых машин
Настройка конфигурации Cassandra
Настройка топологии кластера
Подключение Prometheus Cassandra Exporter
Подключение Prometheus Node Exporter
Вывод всех метрик в Grafana
Проведение нагрузочного тестирования
Дополнительный тюнинг по результатам теста
1. Анализ рабочей нагрузки и требований
Основная цель на старте — понять, как Cassandra будет использоваться в ваших процессах и рабочих задачах, какой объем данных будет обрабатываться, с какой скоростью, какая степень резервирования данных требуется, какие требования к скорости доступа и задержкам. Вот примерно необходимый (но не факт, что достаточный) список вопросов:
Тип операций и процентное соотношения чтения/записи: read-heavy, write-heavy, mixed?
Требуемый Consistency Levels: QUORUM, LOCAL_QUORUM, ONE, ALL?
Объем данных: текущий и прогнозируемый рост;
Требования к задержкам (Latency): максимально допустимое время ответа для различных типов запросов;
Требования к пропускной способности (Throughput): число операций в секунду для чтения, записи и смешанных операций;
Шаблоны доступа к данным и как будут выполняться запросы: по Primary Key, по диапазону, с агрегацией?
Очевидно, что ответы на эти вопросы можно получить только в контексте бизнес-задачи с привлечением разработчиков, продактов и других бенефициаров. Не менее очевидно, что выбор “железа” для хостовых машин в полной мере будет зависеть от полученных ответов выше.
2. Разработка схемы данных
Эту совершенно отдельную тему придется вынести за рамки материала в силу ее изрядного размера. В качестве отличной базы для знакомства порекомендую вебинар «Создание эффективной модели данных для высоконагруженных приложений» из уже упоминавшегося выше плейлиста — пожалуй, это одно из лучших и понятных введений в тему, которые приходилось встречать.
На всякий случай обращу ваше внимание, что проектирование модели данных Cassandra проводится с точностью до наоборот от реляционного подхода: вместо привычного Data→Models→Application, в Cassandra используется проектирование модели данных через Applications→Models→Data.
Не пренебрегайте этим пунктом в нашем плане и, по возможности, не рассчитывайте, что разработчики и/или дата-аналитики быстренько придумают подходящие таблицы потом, когда кластер будет готов. Вкупе с непониманием или игнорированием разработки модели данных Cassandra это крайне плохой сценарий, который будет иметь неприятные последствия. Вплоть до того что вы (ваш бизнес) вдруг узнает, что Cassandra на самом деле для выбранных задач не подходит и вообще была не нужна.
Что касается нашего случая, то готовая модель данных уже имелась на старом кластере и по этой причине мы не стали придумывать ее “с нуля".
3. Настройка хостовых машин
Это первый важный этап, поскольку некоторые дефолтные настройки ОС могут быть критически несовместимы с работой Cassandra.
Видимо, сейчас пора определиться со способом развёртывания, который вам больше подходит: практически все операции нужно будет повторить на каждой ноде. Способ, которым вы захотите это делать, остаётся ваше усмотрение, в зависимости от имеющейся инфраструктуры и количества хостов/нод.
Я использовал смешанный подход исходя из текущей задачи, например:
Настройку хостов нужно просто последовательно сделать на каждой машине любым подходящим способом;
Настройку Prometheus экспортеров удобно делать на любой одной ноде, редактируя смонтированные на хост файлы “на лету” с последующим перезапуском
docker-compose, пока экспортер не заработает, а затем перенести рабочий конфиг в деплой и раскатать на все ноды;Наконец, конфигурация Cassandra всегда должна быть синхронизирована, поэтому ее лучше сразу разворачивать на все ноды.
Это лишь подсказки, выбирайте удобный для вас способ.
Давайте уже перейдем к настройке хостов. Вот что предстоит сделать:
Синхронизацию времени NTP (обязательно!)
Отключение swap (обязательно!)
Дисковую оптимизация (рекомендуется)
Перенос Commit Log на SSD (рекомендуется)
Синхронизация времени NTP
Рассинхронизированные во времени ноды — возможно, одна из неприятных вещей, которые могут случиться с production инфраструктурой, и это касается не только Cassandra. Начните с проверки, что системное время синхронизируется, и если нет, то установите и настройте любой подходящий инструмент, например chrony.
Здесь и далее я использую sed для внесения изменений в конфиги, чтобы избежать ручных правок в пяти консолях. Перепроверьте эти команды и сделайте бэкап изменяемых файлов! Запустите вначале sed без ключа -i, чтобы увидеть предварительный результат в консоли, без внесений изменений в файл. Здесь примеры для Debian, будьте внимательны!
sudo apt update
sudo apt install -y chrony
sudo cat /etc/chrony/chrony.conf | grep -iE "pool|makestep"
# Заменяем строки с дефолтным сервером времени Debian на 4 пула NTP
sudo sed -i 's/^pool 2\.debian\.pool\.ntp\.org iburst$/pool 0.pool.ntp.org iburst\npool 1.pool.ntp.org iburst\npool 2.pool.ntp.org iburst\npool 3.pool.ntp.org iburst/' /etc/chrony/chrony.conf
# Ожидаем наличие 4 строк *.pool.ntp.org и строки с makestep
sudo cat /etc/chrony/chrony.conf | grep -iE "pool|makestep"
sudo systemctl restart chronyd
sudo systemctl enable chrony
# Проверить через несколько минут
# Ожидаем: Leap status: Normal и Reference ID с именем NTP-сервера
chronyc tracking
# Ожидаем: NTP service: active и System clock synchronized: yes.
timedatectl statusНа каждом хосте, помните? — здесь и везде далее.
Отключение swap
Это просто обязательное требование для нормальной работы Cassandra, без вариантов.
sudo swapoff -a
# Ожидаем: все нули в строке swap
free -h
# Отключим swap после перезагрузки
# Команда закомментирует строку `UUID=… none swap` в указанном файле
sudo sed -i '/[[:space:]]swap[[:space:]]/ s/^/# /' /etc/fstab
# Проверьте, что строка закомментирована
cat /etc/fstab | grep swapДисковая оптимизация
Добавление параметров noatime,nodiratime в монтирование отключает избыточное обновление метаданных и увеличивает скорость чтения основных данных. Предполагается, что эта часть файловой системы будет использоваться исключительно для Cassandra и не применяется ни для чего другого.
# Добавляем опции noatime,nodiratime после default
sudo sed -i '/\/cassandra[[:space:]]\+ext4/ s/defaults/defaults,noatime,nodiratime/' /etc/fstab
# Проверьте, что опции noatime,nodiratime были добавлены в строку
cat /etc/fstab | grep cassandra
sudo mount -o remount /cassandra
# Проверьте, что опции применились
mount | grep "/cassandra"Перенос Commit Log на SSD
Commit Log критичен к быстродействию и его перенос на SSD значительно увеличит производительность Cassandra. Заметьте, что в случае поломки SSD (и потери Commit Log) нода может потребовать серьезного ремонта. Впрочем, от поломки железа никто не застрахован, а современные SSD вполне надежны. Поэтому делаем!
Я использовал раздел 32Гб, который образовался после выключения свопа. В другой конфигурации просто создайте подходящий раздел. По моей беглой оценке, на старом плюс-минус похожем кластере общий размер Commit Log не превышал 2Гб. Commit Log периодически сбрасывается на диск (в этом его суть), поэтому он обычно имеет некоторый предельный размер и не “накапливается". Но лучше выделить раздел с избыточным запасом, на всякий случай.
Конечно, следует заменить /dev/md1 на ваш том во всех командах. Проверьте, что том НЕ смонтирован:
lsblk
# Ожидается: umount: /dev/md1: not mounted.
sudo umount /dev/md1Сделайте далее, если том не смонтирован и свободен:
sudo mkfs.ext4 -F /dev/md1
sudo mkdir -p /cassandra/commitlog_nvme
# Здесь 999:999 - Cassandra user/group
sudo chown -R 999:999 /cassandra/commitlog_nvme
# Отметьте UUID нового тома
sudo blkid /dev/md1
UUID=$(sudo blkid /dev/md1 | awk -F'UUID="' '{print $2}' | awk -F'"' '{print $1}')
# Добавьте новую точку монтирования в /etc/fstab
echo "UUID=$UUID /cassandra/commitlog_nvme ext4 defaults,noatime,nodiratime,nobarrier 0 0" | sudo tee -a /etc/fstab
sudo mount /cassandra/commitlog_nvme
# Проверьте, что том для Commit Log успешно смонтирован
lsblk | grep commitlog
mount | grep "/cassandra/commitlog_nvme"
# Проверьте, что вывод содержит "[none] mq-deadline"
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme1n1/queue/schedulerС хостовыми машинами на этом закончено и можно переходить к настройке конфигурации Cassandra.
