HowTo: деплой Apache Cassandra DB и компонентов для её мониторинга

Привет! Меня зовут Сергей Тетерюков, и я работаю инженером инфраструктуры и автоматизации в X5 Tech. Недавно я написал для коллег обзорную статью о БД Apache Cassandra DB и её деплое, и теперь хочу поделиться ей с вами.

Краткое и поверхностное описание Cassandra DB

Apache Cassandra — высокопроизводительная, отказоустойчивая распределённая не реляционная (NoSQL) БД, позволяющая создать надёжное масштабируемое хранилище данных.

Cassandra использует язык CQL, синтаксис которого аналогичен SQL.

Компоненты cassandra db:

• Нода(Node) или узел – основной элемент хранилища cassandra db. 

• Дата-центр (Data-center) – состоит из одной или нескольких нод, связанных между собой. Может быть физическим или виртуальным.

  Деление на дата-центры позволяет распределять рабочую нагрузку, обеспечивает те самые reliability и fault tolerance.

  В каждый дата-центр обычно входят несколько нод, как минимум одна из которых выполняет роль раздающей (Seed); рекомендуется делать более одной seed-ноды на один дата-центр.

• Кластер (Cluster) – объединение дата-центров.

Для более детального изучения архитектуры и того, как работает Cassandra рекомендую ознакомиться с основными разделами из официальной документации:

• Архитектура Cassandra DB.

• Cassandra Query Language (CQL).

• Конфигурация.

Рассмотрим практическую продуктовую задачу

1. Задеплоить кластер Apache Cassandra DB в нескольких окружениях (например, dev, stage, и prod).

2. Установить компоненты, необходимые для мониторинга Cassandra DB (экспортеры для сбора метрик состояния и ресурсов серверов, на которых развернуты ноды БД кассандры, и непосредственно метрик самой БД).

Варианты реализации деплоя

1. В докер-контейнерах.
   Плюсы:
   — Есть готовые докер-образы, как для Cassandra DB, так и для node-exporter, cassandra-exporter => минимум настроек.

   Минусы (выявленные методом проб и ошибок на личном опыте):
   — Требуется подготовка хостов — установка и настройка docker и сопутствующих пакетов.
   — Для более гибкой настройки потребуется модификация образов.
   — Для успешного объединения отдельных нод Cassandra DB в кластер могут потребоваться дополнительные танцы с бубном: так, например, у меня при одновременном запуске контейнеров ноды как минимум одна из нод не могла корректно получить токены, и не проходила проверку для получения статуса UN (Up, Normal). Пришлось настроить ожидание с запуском каждого следующего контейнера только после завершения запуска и инициализации предыдущего, начиная с seed-ноды.
   — Сложности с настройками контейнеров экспортеров (например, node-exporter официально не рекомендуется деплоить в докер-контейнере, т.к. для корректной работы ему требуется доступ к системе хоста).
   — Сложности взаимодействия контейнеров БД и экспортеров между собой. У меня, например, так и не удалось подружить контейнер cassandra-exporter с контейнером самой cassandra-db.

2. В k8s-кластере.
   Плюсы:
   — Как и в случае с docker: готовые докер-образы всех компонентов.
   — Возможности настроить автомасштабирование.
   — Высокая доступность и отказоустойчивость.
   — GAP-стек хорошо адаптирован для мониторинга kubernetes, в т.ч. есть готовые решения в виде helm-chart'ов.

   Минусы:
   — Дополнительные сложности, связанные с реализацией деплоя stateful-приложения.
   — Для более гибкой настройки потребуется модификация образов.
   — Необходимо будет решать проблемы с объединением cassandra-узлов в единый cassandra-кластер и их идентификацией (для которой требуются ip-адреса узлов).
   — Масса сложностей (согласно информации с просторов сети) с настройками cassandra-exporter'а, чтобы он мог корректно забирать метрики.

   В сети можно найти несколько готовых helm-chart'ов для cassandra-db, например: один, второй (более не поддерживается разработчиками). Также есть несколько kubernetes-операторов разной степени готовности и поддержки, со своими плюсами и минусами.

3. Установка пакетов на хостах.
   Плюсы:
   — Отсутствие проблем взаимодействия компонентов между собой, описанных для реализации в докер-контейнерах.
   — Возможность более гибкой настройки компонентов.

   Минусы:
   —Требуются дополнительные настройка для организации работы cassandra как сервиса с автозапуском при старте хоста.

Для production среды рекомендуется деплой БД на хостах, этот вариант и будет рассмотрен далее.

В качестве основного инструмента для деплоя был выбран ansible. Соответственно для каждого компонента (БД и 2 экспортера) у нас будет своя ansible-role.

Общие особенности реализации процесса:

• ansible.cfg:

[defaults]
host_key_checking = False
deprecation_warnings = False
interpreter_python = /usr/bin/python3
vault_password_file = vault_secret.sh
stdout_callback = yaml

Пара пояснений:

1. [stdout_callback = yaml] — вывод при исполнении роли становится более читаемым
2. [vault_password_file = vault_secret.sh] — данный параметр позволит хранить пароль от ansible-vault в качестве переменной окружения и не передавать его при запуске роли.

В скрипт-файле vault_secret.sh:

#!/bin/bash
echo $ANSIBLE_VAULT_PASS

• Организация директории group_vars:

group_vars
├── all
│   └── var.yml
├── dev
│   ├── var.yml
│   └── vault.yml
├── prod
│   ├── var.yml
│   └── vault.yml
└── stage
    ├── var.yml
    └── vault.yml

Все секреты храним в group_vars/<environment>/vault.yml, шифруемые c помощью ansible-vault.

Например, пароль от учётной записи, под которой будет осуществляться ssh-подключение к хостам — в group_vars/all/var.yml:

ansible_password: "{{ vault_ansible_password }}"

В group_vars/<environment>/vault.yml:

ansible__vault_password: "MySecr3tP@s$w0rd!"

И шифруем:

$ ansible-vault encrypt group_vars/test/vault.yml

После чего файл с паролем выглядит примерно вот так:

$ANSIBLE_VAULT;1.1;AES256
64613635303233376461643834326339343535303763353731643762383136656566666336646636
3866666162383666656137346365663631333532633762610a373733353863666230383630643661
61613262366138373537663866303434643565313262366133383732313062393531636431653862
3263653434313938320a386638653734376330646136303231323966393837333934373764306230
32306266366237393137303961633232666636643062306264633633623930666339326637643835
61396237386263613761626439303831313939366365303431616432656563366261633065636261
32623861653736386266343866386135373866636632316533363531356561643833326636303632
65613230323333383364323938376539303432656538353564383735373237306231366561383637
6338

• Файл hosts(inventory):

[seeds]
    csnd1 ansible_host=10.10.10.10
    csnd2 ansible_host=10.10.10.11
[workers]  
    csnd3 ansible_host=10.10.10.12    
[prod:children]
    seeds
    workers
[dc1:children]
    seeds
    workers
[all:vars]
    ansible_connection=ssh
    ansible_become=yes
    ansible_become_user=root

• Объявление группы 'seeds' необходимо для дальнейшего определения seed-нод кластера.

• Формирование остальных групп — в соответствии с требуемой в вашей задаче реализацией.

Далее рассмотрим роли для деплоя каждого компонента

1. Ansible-role для Cassandra DB:

   В качестве основы была выбрана готовая роль от LoCP (League of Crafty Programmers Ltd). Было изучено несколько вариантов, но роль LoCP, на мой субъективный взгляд, наиболее понятная и подходящая.

   Структура роли:

roles/cassandra-db
├── defaults
│   └── main.yml
├── handlers
│   └── main.yml
├── tasks
│   ├── assertions.yml
│   ├── configure.yml
│   ├── hotfixes.yml
│   ├── install
│   │   ├── Debian.yml
│   │   └── RedHat.yml
│   ├── join_cluster.yml
│   ├── main.yml
│   ├── service.yml
│   └── variables.yml
├── templates
│   ├── cassandra.yaml.j2
│   └── etc
│       └── systemd
│           └── system
│               └── cassandra.service.j2
└── vars
    ├── Debian.yml
    ├── RedHat.yml
    └── main.yml

В целом роль самодостаточная:

• Позволяет развернуть кластер cassandra как на серверах семейства RedHat, так и Debian.

• Содержит шаги, необходимые для добавления cassandra в систему в качестве сервиса.

• Есть таски для добавления новых нод в кластер.

Пояснения и советы:

• Для корректного создания основного конфигурационного файла cassandra — cassandra.yaml — не забудьте добавить в defaults/main.yml либо в yaml-конфиг, вызывающий роль (по аналогии с примером из README.md данной роли), параметры cassandra_configuration и cassandra_regex_replacements:

cassandra_datacenter1_name: "dc1"
cassandra_rack_name: "rack1"
seeds: "{{ seeds_list | join(',') }}"
 
 
cassandra_regex_replacements:
    - path: cassandra-env.sh
      line: MAX_HEAP_SIZE="{{ cassandra_max_heapsize_mb }}M"
      regexp: ^#MAX_HEAP_SIZE="4G"
    - path: cassandra-env.sh
      line: HEAP_NEWSIZE="{{ cassandra_heap_new_size_mb }}M"
      regexp: ^#HEAP_NEWSIZE="800M"
    - path: cassandra-rackdc.properties
      line: 'dc={{ cassandra_datacenter1_name }}'
      regexp: '^dc='
    - path: cassandra-rackdc.properties
      line: 'rack={{ cassandra_rack_name }}'
      regexp: '^rack='
 
 
сassandra_configuration:
    authenticator: PasswordAuthenticator
    cluster_name: "{{ envname }}-cluster"
    commitlog_directory: /data/cassandra/commitlog
    commitlog_sync: periodic
    commitlog_sync_period_in_ms: 10000
    data_file_directories:
        - /data/cassandra/data
    endpoint_snitch: GossipingPropertyFileSnitch
    hints_directory: "/data/cassandra/hints"
    listen_address: "{{ ansible_default_ipv4.address }}"
    rpc_address: "{{ ansible_default_ipv4.address }}"
    partitioner: org.apache.cassandra.dht.Murmur3Partitioner
    num_tokens: 256
    saved_caches_directory: /data/cassandra/saved_caches
    seed_provider:
        - class_name: "org.apache.cassandra.locator.SimpleSeedProvider"
          parameters:
              - seeds: "{{ seeds }}"
    start_native_transport: true

• Значения cassandra_max_heapsize_mb и cassandra_heap_new_size_mb рассчитываются автоматически (на основе фактических технических параметров серверов) в тасках, описанных в tasks/variables.yml

• seedslist определяется следующей конструкцией в groupvars/all.yml:

seeds_list: "{{ groups['seeds'] | map('extract',hostvars,'ansible_host') | list }}"

Соответственно в hosts(inventory) должна быть группа seeds, которые и будут определены в качестве сидов кластера.

• В качестве бонуса, если вдруг в вашей задаче требуется первоначальная конфигурация БД, например, добавить пространство ключей (keyspace) и пользователя (user):

  а. Для начала надо дождаться, что кластер поднялся и слушает порты для подключения к нему (9042) и взаимодействия нод между собой (7000). Для этого можно добавить следующую таску после всех задач конфигурации и запуска:

- name: Wait for the Cassandra Listener
  wait_for:
    timeout: 120
    host: "{{ ansible_default_ipv4.address }}"
    port: "{{ item }}"
  loop:
    - 9042
    - 7000

b. В templates/ добавить шаблон cqlsh-скрипта, например, в моём случае было достаточно такого:

ALTER KEYSPACE system_auth
    WITH replication = {
        'class': 'NetworkTopologyStrategy',
        '{{ cassandra_datacenter1_name }}': {{ cass_dc1_nodes_number }}
    };
CREATE ROLE IF NOT EXISTS {{ cassandra_user }} 
WITH PASSWORD = '{{ cassandra_user_password }}'
AND LOGIN = true;
CREATE KEYSPACE IF NOT EXISTS {{ cassandra_keyspace }} 
    WITH replication = {
        'class': 'NetworkTopologyStrategy',
        '{{ cassandra_datacenter1_name }}': {{ cass_dc1_nodes_number }}
    };

Не забыть объявить необходимые переменные:

cassandra_user: "test_user"
cassandra_keyspace: "test_keyspace"
cassandra_datacenter1_name: "dc1"
cassandra_rack_name: "rack1"
cass_dc1_nodes_number: "{{ groups['dc1'] | length }}"
 
cqlsh_script_template: "cqlsh_script.txt.j2"
cqlsh_script_path: "/root/cqlsh_script.txt"

cassandra_user_password — добавить в ansible-vault

c.    Скопировать скрипт на одну ноду кластера, выполнить его и после удалить:

- block:

  - name: Apply cqlsh_script
    template:
      src: "{{ cqlsh_script_template }}"
      dest: "{{ cqlsh_script_path }}"
      owner: root
      group: root
      mode: '0644'

  - name: add DB data (keyspace, user)
    shell: "cqlsh {{ ansible_default_ipv4.address }}  -u cassandra -p cassandra -f  {{ cqlsh_script_path }}"

  - name: Remove cqlsh_script file
    file:
      path: "{{ cqlsh_script_path }}"
      state: absent

when: inventory_hostname == groups['seeds'][0]

2. 2.    Ansible-role для node-exporter'а:

   Основа — готовая роль под авторством cloudalchemy. Структура роли:

roles/node-exporter
├── defaults
│   └── main.yml
├── handlers
│   └── main.yml
├── tasks
│   ├── configure.yml
│   ├── install.yml
│   ├── main.yml
│   ├── preflight.yml
│   └── selinux.yml
├── templates
│   ├── config.yaml.j2
│   └── node_exporter.service.j2
└── vars
    └── main.yml

Необходимости в модификации данной роли почти нет (за исключением моментов, связанных с особенностями инфраструктуры (например, доступность внешних репозиториев из внутренней сети вашей компании), например, node_exporter_repo_url), собственная документация роли, на мой взгляд исчерпывающая.

Пояснения и советы:

• Роль адаптирована под дистрибутивы семейств RHEL, Fedora, ClearLinux.

• Node-exporter будет функционировать в качестве systemd service unit.

• Предусмотрены два варианта установки экспортера:

  a.    Бинарник скачивается из репозитория, адрес которого передаётся в переменной node_exporter_repo_url. В случае, если ваше окружение имеет ограничения в доступе к официальному репозиторию, следует заменить его на адрес своего, доступного репозитория.

  b.    Бинарник заранее помещается в директорию с файлами роли (roles/node-exporter/files), либо по другому удобному вам пути, который далее передаётся в переменной node_exporter_binary_local_dir

Выбирайте более подходящий для вас вариант, но не передавайте одновременно значения и в node_exporter_repo_url, и в node_exporter_binary_local_dir, т.к. они отвечают за взаимозаменяемые сценарии.

• Для изменения версии экспортера — поменять значение параметра node_exporter_version в defaults/main.yml. Здесь же найдутся параметры для более гибкой настройки конфигурации (config.yaml) — параметры:

node_exporter_tls_server_config: {}
node_exporter_http_server_config: {}
node_exporter_basic_auth_users: {}

• При необходимости внести кастомные изменения в конфигурационные файлы настройки экспортера (config.yaml) и настройки сервиса (node_exporter.service): шаблоны файлов расположены в каталоге templates/.

• Если по каким-то причинам вам потребуется поменять порт, на котором будет работать экспортер — меняйте переменную node_exporter_web_listen_address (стандартное значение "0.0.0.0:9100"). Аналогично с эндпоинтом для метрик — переменная node_exporter_web_telemetry_path (стандартное значение "/metrics").

3.Ansible-role для cassandra-exporter'а:

В качестве основы была выбрана роль от criteo. Струтура:

roles/cassandra-exporter
├── README.md
├── defaults
│   └── main.yml
├── files
│   └── config.yml
├── handlers
│   └── main.yml
├── tasks
│   └── main.yml
└── templates
    ├── cassandra_exporter.sh.j2
    └── etc
        └── systemd
            └── system
                └── prometheus-cassandra-exporter.service.j2

Изначально эта роль является развитием оригинального JMX exporter, но доработана для более лёгкой интеграции с Cassandra DB. По сути, установки экспортера с помощью этой роли достаточно, чтобы после настройки прометеуса на забор метрик с этого экспортера и установки в графане этого дашборда получить исчерпывающий набор информативных графиков для мониторинга нашего кассандра-кластера в разрезе работы БД.

Также важно отметить, что в рамках этой роли экпортер устанавливается в формате standalone, т.е. как отдельный компонент. Если у вас на проекте предполагается высокая нагрузка на cassandra DB, что закономерно повлечёт за собой увеличение количества метрик, то возможно вам стоит рассмотреть установку cassandra-exporter как java-agent (что позволит ускорить сбор метрик и снизить нагрузку на систему; из минусов — необходимость встраивать агент в конфигурацию cassandra DB, и, как следствие, потенциальные проблемы с совместимостью); в этом случае советую ознакомиться со следующей реализацией экспортера.

Пояснения и советы:

• cassandra-exporter будет функционировать в качестве systemd service unit.

• Версия экспортера задаётся в defaults/main.yml в переменной cassandra_exporter_version. Актуальную версию можно посмотреть здесь.

• Порт, на котором будет висеть экспортер задаётся в defaults/main.yml в переменной cassandra_exporter_listen_port (значение по умолчанию в роли — 8080, но вообще стандартный порт для cassandra-exporter — 9500). Этот же порт следует прописывать в конфиге прометеуса для стягивания метрик.

• Бинарник и конфиг-файл скачиваются из репозитория, адреса передаются в переменных cassandra_exporter_binary_url и cassandra_exporter_config_url. В случае, если ваша инфраструктура имеет ограничения в доступе к официальному репозиторию, следует заменить значения переменных на адреса своего, доступного репозитория.

• Если вам потребуется, чтобы установочный бинарник и/или файл конфигурации сразу были в проекте, и не нужно было их скачивать в процессе отработки роли, то потребуются следующие доработки роли:
  
  — Закинуть эти файлы (по аналогии с node-exporter'ом,) в директорию с файлами роли (roles/cassandra-exporter/files) либо в другую директорию проекта.
  — Добавить переменные cassandra_exporter_binary, cassandra_exporter_config, в которых будут указаны пути до файлов в проекте (если файлы будут помещены в roles/cassandra-exporter/files, то в значениях переменных достаточно будет указать только имена этих файлов, например: 'cassandra_exporter.jar', 'config.yml').
  — Добавить следующие исполнительные таски:

	- name: 'copy cassandra exporter binary'
  copy:
    src: '{{ cassandra_exporter_binary }}'
    dest: '{{ cassandra_exporter_dist_dir }}/cassandra.jar'
    owner: '{{ cassandra_exporter_user }}'
    group: '{{ cassandra_exporter_group }}'
    mode: '0644'
  when: cassandra_exporter_binary is defined

А в таске 'download cassandra exporter binary' добавить условие выполнения:

when: cassandra_exporter_binary is not defined

	- name: 'сopy cassandra exporter config'
  copy:
    src: '{{ cassandra_exporter_config }}'
    dest: '{{ cassandra_exporter_config_dir }}/config.yml'
    owner: '{{ cassandra_exporter_user }}'
    group: '{{ cassandra_exporter_group }}'
    mode: '0644'
  when: cassandra_exporter_config is defined

Переменные cassandra_exporter_dist_dir и cassandra_exporter_config_dir - уже заданы в роли.

Конфиг-файл экспортера советую именно таким образом держать в проекте, чтобы при необходимости иметь возможность вносить доработки/изменения через код.

Итог

Имеем набор ролей, который позволит тремя командами:

$ ansible-playbook -i ansible/hosts ansible/install-cassandra-db.yml
$ ansible-playbook -i ansible/hosts ansible/install-cassandra-exporter.yml
$ ansible-playbook -i ansible/hosts ansible/install-node-exporter.yml

Развернуть полный набор — кластер БД cassandra и его мониторинг как на уровне ресурсов системы, так и на уровне самой БД. Все три компонента установятся на хостах в качестве systemd service unit'ов, перезапускаемых при старте системы, так что в случае перезагрузки хостов, не потребуется ручного запуска.

При установке желательно придерживаться последовательности:

1. cassandra-db

2. cassandra-exporter — в этом случае cassandra-exporter сразу найдёт запущенный сервис; node-exporter от остальных компонентов не зависит, и его можно устанавливать в любой момент.

В заключение, для проверки работы каждого компонента:

1. БД должна быть доступна при обращении к любой из нод кластера на порт 9042.

   — Для удалённого подключения через консоль нам понадобится клиент cqlsh:

$ cqlsh <cassandra_node1_ip-address>:9042 -u my_cass_user

Более подробно о работе с клиентом cqlsh.

— Для диагностики кластера при локальном подключении к хостам-нодам cassandra можно использовать инструмент — nodetool, устанавливается автоматически вместе с cassandra-db. Более подробно о работе с nodetool.

2. Метрики node-exporter должны быть доступны при обращении к каждому хосту-ноде кластера на порт 9100,

3. Метрики cassandra-exporter — на порт 9500.