Это продолжение цикла, рассказывающего о практике развёртывания производственного кластера Cassandra. В первой части мы начали продвигаться вот по такому плану:

1. Анализ рабочей нагрузки и требований
2. Разработка схемы данных
3. Настройка хостовых машин
= ВЫ НАХОДИТЕСЬ ЗДЕСЬ =
4. Настройка конфигурации Cassandra
5. Настройка топологии кластера
6. Подключение Prometheus Cassandra Exporter
7. Подключение Prometheus Node Exporter
8. Вывод всех метрик в Grafana
9. Проведение нагрузочного тестирования
10. Дополнительный тюнинг по результатам теста

Продолжим?

Это первая статья из цикла, рассказывающая о практике развёртывания небольшого кластера 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 могут включать десятки и сотни нод, раскиданных по многим ДЦ в разных странах мира), однако для наших задач он вполне достаточен и главное решает потребности бизнеса.

Приступим?

Это небольшой туториал о том, как ускорить pull и push тяжелых Docker образов, которые вы собираете локально, но их запуск возможен только в удаленной среде. Например, потому что контейнер использует специфическое окружение, приложения или ресурсы, которые трудно или невозможно воспроизвести локально.

Решение “в лоб” состоит в том, чтобы запушить собранный образ в Dockerhub. А там, где вы будете его использовать, просто указать ссылку на образ. Очевидно, что у этого простого способа есть недостатки.

Найденное решение оказалось без этих недостатков, простым, работающим и весьма изящным. Вот 3 шага, которые нужно сделать:

Поделюсь с коллегами практикой создания Docker-сборок на базе Spark разных версий, которые могут запускаться как Spark Kubernetes Executors для параллельного выполнения Spark-задач в кластере.

В нашем конкретном случае сборки включают Pyspark и Cassandra Connector, однако вы можете использовать этот материал как набор практических примеров, чтобы сконструировать собственные Docker-сборки для Spark на другом стеке или с другими приложениями.

В рамках поставленной задачи мне понадобилось подготовить, как минимум, пару Docker-сборок: одну для поддержки легаси кода и другую вполне современную для последующей миграции. Ниже я расскажу об этапах создания таких Docker-сборок, погружаясь в детали по ходу дела.