Установка Apache Cassandra на Ubuntu 20.04

Краткое содержание

• Что такое Apache Cassandra и когда её использовать
• Подготовка системы и зависимости
• Установка OpenJDK и Cassandra (репозиторий 3.11x)
• Базовая настройка и проверка кластера
• Безопасность и мониторинг
• Удаление и откат изменений
• Расширенные советы: тюнинг, отладка, миграция

Введение

Apache Cassandra — это распределённая NoSQL СУБД с открытым исходным кодом. Она проектировалась для масштабируемости по горизонтали, высокой доступности и отказоустойчивости без единой точки отказа. Cassandra хорошо подходит для сценариев с высокой нагрузкой на запись и с требованием к отказоустойчивому хранению данных.

Коротко об особенностях:

• Линейное масштабирование: при добавлении узлов пропускная способность записи растёт.
• Полностью распределённая архитектура: шардинг по обычным серверам без единой точки отказа.
• Простота запуска на commodity hardware.
• Самоисцеление: при выходе узла из кластера данные реплицируются и синхронизируются.

Важно: в этом руководстве мы используем Ubuntu Server 20.04 и ветку Cassandra 3.11.x, совместимую с OpenJDK 8. Для более новых версий Cassandra проверьте совместимость с Java 11+

Предварительные требования

• Сервер с Ubuntu Server 20.04 (или виртуальная машина).
• Пользователь с правами sudo.
• Доступ к интернету для загрузки пакетов и ключей.
• Минимум базовой системной памяти и дискового пространства (проверяйте требования под вашу нагрузку).

Важно: перед изменением конфигурации Cassandra сделайте резервную копию конфигурационных файлов и данных.

Быстрая контрольная таблица (перед началом)

• У вас есть snapshot текущей системы или тестовая машина
• Пользователь с sudo
• Свободное место на /var и /var/lib
• Понимание модели отказоустойчивости (репликации и стратегий)

Обновление системы

Перед установкой пакетов обновите индекс и установленные пакеты:

sudo apt update -y

sudo apt upgrade -y

Опция -y отвечает автоматически “yes” для всех запросов. Команда update обновляет индекс пакетов, upgrade — реально обновляет установленные пакеты.

Пример вывода (скриншоты в оригинале):

ALT: Экран терминала с результатом выполнения команды apt update

ALT: Экран терминала с процессом apt upgrade

Установка зависимостей

Cassandra требует нескольких утилит и транспортов для безопасного получения пакетов.

sudo apt install apt-transport-https wget gnupg -y

Коротко:

• apt-transport-https: позволяет apt обращаться к репозиториям по HTTPS.
• wget: утилита для загрузки файлов по HTTP/HTTPS.
• gnupg: управление GPG-ключами и проверка целостности загружаемых пакетов.

Пример вывода:

ALT: Терминал во время установки зависимостей

Установка Java

Apache Cassandra требует JVM. Для Cassandra 3.11 рекомендуем OpenJDK 8.

sudo apt install openjdk-8-jdk -y

Проверьте установку:

java -version

Пример вывода:

ALT: Вывод команды java -version показывающий установленную версию Java

Совет: если планируете устанавливать Cassandra 4.x, уточните требуемую версию Java (обычно Java 11 или выше).

Установка Apache Cassandra

1. Импортируйте GPG-ключ проекта Apache Cassandra:

wget -q -O - https://www.apache.org/dist/cassandra/KEYS | sudo apt-key add -

Опция -q подавляет лишний вывод. apt-key добавляет ключ для проверки пакетов репозитория.

Пример вывода: импорт ключа GPG

2. Добавьте репозиторий Cassandra (ветка 3.11.x) в список источников:

sudo sh -c 'echo "deb http://www.apache.org/dist/cassandra/debian 311x main" > /etc/apt/sources.list.d/cassandra.list'

Объяснение: эта команда создаёт файл /etc/apt/sources.list.d/cassandra.list с записью репозитория 311x.

3. Обновите индекс пакетов и установите Cassandra:

sudo apt-get update
sudo apt install cassandra -y

Пример вывода:

ALT: Процесс установки пакета cassandra в терминале

4. Проверка статуса сервиса systemd:

sudo systemctl status cassandra

Пример вывода:

ALT: Вывод systemctl status cassandra с информацией о состоянии службы

Если нужно перезапустить:

sudo systemctl restart cassandra

Проверка состояния узла Cassandra (nodetool требует прав и доступен после установки):

sudo nodetool status

Пример вывода:

ALT: Вывод команды nodetool status с информацией о кластере

Вход в CQL shell (интерактивный клиент):

cqlsh

Пример экрана входа:

ALT: Экран входа в cqlsh

Для выхода используйте exit.

Базовая настройка Cassandra

Основные файлы и директории:

• Данные: /var/lib/cassandra/data/
• Конфигурация: /etc/cassandra/
• Логи: /var/log/cassandra/

Перед изменениями сделайте резервную копию конфигураций:

sudo cp -a /etc/cassandra /etc/cassandra.bak-$(date +%F)

Изменение имени кластера

По умолчанию имя кластера — test cluster. Чтобы изменить его:

1. Запустите cqlsh:

cqlsh

2. Выполните команду:

UPDATE system.local SET cluster_name = 'Howtoforge Cluster' WHERE KEY = 'local';

3. Перезапустите Cassandra:

sudo systemctl restart cassandra

После перезапуска интерфейс покажет новое имя кластера.

ALT: Скриншот cqlsh с изменённым именем кластера

Правила именования: избегайте пробелов и специальных символов; имена чувствительны к регистру.

Важные параметры в cassandra.yaml

Ключевые поля, которые стоит проверить при развёртывании в продакшн:

• cluster_name: имя кластера.
• seeds: список seed-узлов (обычно 1–3 адреса для небольшого кластера).
• listen_address: IP для межузловой связи.
• rpc_address: IP для клиентских соединений (CQL over native protocol, порт 9042).
• endpoint_snitch: определяет стратегию размещения реплик (например, GossipingPropertyFileSnitch).
• data_file_directories, commitlog_directory, saved_caches_directory: директории на диске.
• num_tokens: количество виртуальных токенов на узел (по умолчанию 256 для 3.11).

Совет: при развёртывании на виртуальных машинах или облаке убедитесь, что listen_address и rpc_address указывают на корректные интерфейсы.

Безопасность и сетевые настройки

Рекомендации по безопасности:

• Включите аутентификацию и авторизацию в cassandra.yaml:
  • authenticator: PasswordAuthenticator
  • authorizer: CassandraAuthorizer
• Включите шифрование транспорта (SSL/TLS) для межузловой и клиентской связи (internode_encryption и client_encryption_options).
• Ограничьте доступ к JMX (используйте локальные туннели или SSL+пароли для удалённого доступа).
• Разрешите только необходимые порты через UFW или другой брандмауэр: по умолчанию 7000/7001 (internode), 7199 (JMX), 9042 (CQL), 9160 (Thrift — устарел).

Пример открытия порта 9042 для конкретного IP с использованием UFW:

sudo ufw allow from 10.0.0.0/24 to any port 9042 proto tcp

Создайте административного пользователя, если включили PasswordAuthenticator:

cqlsh
CREATE ROLE admin WITH PASSWORD = 'strongpassword' AND SUPERUSER = true AND LOGIN = true;

Замените ‘strongpassword’ на надёжный пароль и сохраните его в надежном хранилище.

Мониторинг и метрики

Cassandra предоставляет JMX-интерфейс для метрик. Популярные подходы мониторинга:

• JMX -> Prometheus JMX Exporter -> Grafana
• DataDog / New Relic интеграции
• Использование nodetool для оперативной диагностики (nodetool status, nodetool ring, nodetool cfstats).

Минимальный набор метрик для наблюдения:

• latency по операциям чтения/записи
• поток записей на диск (commit log throughput)
• использование хипа JVM и GC pauses
• размер и состояние очередей compaction
• состояние узлов (Up/Down)

Тесты и критерии приёмки

Критерии приёмки

• Cassandra сервис успешно запущен и находится в состоянии active (systemd).
• nodetool status показывает узел(ы) в состоянии UN (Up/Normal).
• Можно подключиться через cqlsh и выполнить простые запросы создания keyspace и таблицы.
• Созданный ключевойspace сохраняет данные после рестарта узла.

Пример теста:

cqlsh
CREATE KEYSPACE testks WITH replication = {'class':'SimpleStrategy','replication_factor' : 1};
USE testks;
CREATE TABLE users (id uuid PRIMARY KEY, name text);
INSERT INTO users (id, name) VALUES (uuid(), 'alice');
SELECT * FROM users;

Если выборка возвращает вставленную запись и узел остаётся в состоянии Up после перезапуска, тест пройден.

Удаление Cassandra и откат изменений

Шаги для чистого удаления Cassandra и связанных директорий.

1. Остановите сервис:

sudo service cassandra stop

2. Удалите каталоги с данными и логами (внимание: это удалит все данные):

sudo rm -r /var/lib/cassandra
sudo rm -r /var/log/cassandra
sudo rm -r /usr/lib/cassandra
sudo rm -r /etc/apache-cassandra
sudo rm -r ~/.cassandra

3. Удалите пакет:

sudo apt purge cassandra -y
sudo apt autoremove -y

После удаления проверьте, не осталось ли служб или портов, слушающих 9042/7199.

План отката в случае проблем

• Если после изменения конфигурации Cassandra не стартует, восстановите /etc/cassandra из резервной копии и перезапустите сервис.
• Если узел потерял данные, используйте snapshot/backup, если они были сделаны заранее.
• Для синхронизации узла в кластере используйте nodetool repair и nodetool rebuild по необходимости.

Устранение неполадок (Troubleshooting)

Общие проблемы и шаги диагностики:

1. “Unable to create native thread” — причина: нехватка памяти или лимитов для процессов. Проверьте dmesg и /var/log/syslog. Увеличьте лимиты или добавьте оперативной памяти.

2. Ошибка “error while loading shared libraries: libcurl.so” — обычно связана с проблемной установкой библиотек OpenSSL или curl. Установите необходимые зависимости: sudo apt install libcurl4 (проверьте пакет в вашей системе).

3. Нет init-скрипта в /etc/init.d — для systemd используйте systemctl или выполните update-rc.d cassandra defaults && service cassandra restart для восстановления скриптов.

4. Cassandra не запускается после правок в cassandra.yaml — ошибки в синтаксисе. Проверьте логи в /var/log/cassandra/system.log и debug.log. Частые причины: некорректные IP в listen_address, отсутствие прав на директории данных, некорректный формат YAML.

5. Проблемы с узлами в кластере (узел в статусе DN) — проверьте связь по сети, разделение seed-узлов, настройки snitch, синхронизацию времени (NTP). Cassandra чувствительна к рассинхронизации времени.

Полезные команды для диагностики:

sudo journalctl -u cassandra -b
sudo tail -n 200 /var/log/cassandra/system.log
sudo nodetool status
sudo nodetool info
sudo nodetool cfstats

Производительность и тюнинг (основы)

• CPU и диски: Cassandra чувствительна к I/O. Используйте быстрые диски для commitlog (опция: SSD для commitlog). Разнесите директории данных и commitlog при высокой нагрузке.
• Heap JVM: настройте heap в /etc/cassandra/jvm.options в зависимости от объёма памяти. Следите за GC pause.
• compaction: настройте стратегию compact (SizeTieredCompaction, LeveledCompaction) в зависимости от типа нагрузки.
• replication_factor: для продакшн-окружения часто используют RF >= 3 для отказоустойчивости.

Замечание: настройки сильно зависят от профиля нагрузки. Тестируйте изменения в нагрузочном стенде перед продакшеном.

Миграция данных и совместимость

• При миграции с других СУБД подумайте о потоковой загрузке данных (bulk loading) или использовании ETL-инструментов.
• Совместимость Java: Cassandra 3.11 официально поддерживает Java 8. Для Cassandra 4.x используйте Java 11 и выше. Всегда проверяйте release notes.
• Если вы обновляете Cassandra между мажорными версиями, следуйте официальной дорожной карте обновлений и делайте snapshot перед обновлением.

Роли и контрольные списки

DBA / инженер по базам данных:

• Проверить конфигурацию cassandra.yaml и резервные копии.
• Настроить политики репликации и тестировать восстановление из snapshot.
• Планировать и контролировать compaction и backup.

DevOps / Системный инженер:

• Установить пакеты и зависимости, настроить systemd-сервисы.
• Настроить мониторинг (JMX, Prometheus) и алерты.
• Управлять firewall и сертификатами для TLS.

Разработчик:

• Тестировать запросы CQL и схемы данных в тестовом кластере.
• Проверять латентность и поведением при высокой нагрузке.
• Учитывать eventual consistency в дизайне приложения.

Тест-кейсы и критерии приёмки

• Подключение к cqlsh и выполнение SELECT/INSERT/UPDATE.
• Создание keyspace с заданным replication_factor и проверка репликации на разных узлах.
• Рестарт узла и проверка, что после восстановления узел синхронизируется (nodetool repair).
• Проверка мониторинга: метрики JVM, latency и нагрузка на диск отображаются.

Быстрая шпаргалка команд

• Проверить статус сервиса: sudo systemctl status cassandra
• Перезапустить: sudo systemctl restart cassandra
• Проверить узлы: sudo nodetool status
• Войти в CQL shell: cqlsh
• Остановить сервис: sudo service cassandra stop

Decision flowchart (меридиан) установки и удаления

flowchart TD
  A[Начало] --> B{У вас есть тестовая среда?}
  B -- Да --> C[Обновить Ubuntu и установить зависимости]
  B -- Нет --> D[Создать тестовую VM или снимок]
  C --> E[Установить Java]
  E --> F[Импорт GPG и добавить репозиторий]
  F --> G[Установить cassandra]
  G --> H[Проверить сервис и выполнить базовые тесты]
  H --> I{Планы на продакшен?}
  I -- Да --> J[Настроить безопасность, мониторинг и развернуть кластер]
  I -- Нет --> K[Использовать на тестовой среде]
  J --> L[Мониторинг и резервные копии]
  K --> L
  D --> C

Безопасность данных и соответствие (коротко)

• Шифруйте трафик между узлами и клиентами при переносе персональных данных.
• Применяйте политики доступа и аудит действий для соответствия требованиям безопасности.
• При работе с персональными данными продумывайте механизмы удаления/анонимизации для соответствия требованиям регуляторов.

Местные заметки для развёртывания (локальные подводные камни)

• В облачных окружениях проверьте настройки сетевых интерфейсов и приватных IP — неправильный listen_address часто вызывает проблемы.
• На маленьких VM уменьшите num_tokens и heap JVM, чтобы избежать OOM.
• Бэкенды на файловых системах с сжатиями могут влиять на производительность записи.

Альтернативные подходы

Если Cassandra не подходит по модели данных или требованиям консистентности, рассмотрите:

• Apache HBase — для сильной целевой консистентности и интеграции с Hadoop.
• ScyllaDB — drop-in замена Cassandra, написана на C++ для высокой производительности.
• DynamoDB (облачный) — если хотите полностью управляемое решение.

Заключение

Мы прошли весь цикл: от подготовки Ubuntu 20.04 и установки OpenJDK до установки Apache Cassandra 3.11, базовой настройки, проверки состояния и удаления. Вы получили также рекомендации по безопасности, мониторингу, тестам приёмки и плану отката.

Важно: перед развертыванием в продакшн протестируйте конфигурацию, выполните резервное копирование и убедитесь, что мониторинг и алерты настроены.

Если статья была полезна — поделитесь ею с коллегами и подпишитесь на обновления.

Краткое резюме:

• Cassandra хороша для масштабируемых и отказоустойчивых систем с высокой нагрузкой на запись.
• Тщательно настройте сеть, ресурсы JVM и параметры репликации.
• Всегда делайте резервные копии и настраивайте мониторинг.