mysql

Установка и использование Cassandra

Thank you for reading this post, don't forget to subscribe!

На офи­ци­аль­ном сай­те при­во­дят­ся при­ме­ры уста­нов­ки Cassandra раз­ны­ми способами:

  1. Запуск как при­ло­же­ние docker.
  2. Загруз­ка и запуск бинарника.
  3. Исполь­зо­ва­ние репозитория.

Про­ще все­го исполь­зо­вать послед­ний метод. Мы же рас­смот­рим все вари­ан­ты. Так­же, в рам­ках дан­ной инструк­ции, посмот­рим на неко­то­рые настрой­ки СУБД.

Установка с помощью репозитория

Дан­ный вари­ант удо­бен, если есть под­держ­ка исполь­зу­е­мой опе­ра­ци­он­ной систе­мы со сто­ро­ны раз­ра­бот­чи­ка Cassandra, и мы можем под­клю­чить репо­зи­то­рий. Рас­смот­рим уста­нов­ку для раз­лич­ных дис­три­бу­ти­вов Linux.

Установка OpenJDK

Неза­ви­си­мо от типа Linux, в систе­ме долж­на быть уста­нов­ле­на плат­фор­ма для обра­бот­ки Java. Самый удоб­ный спо­соб это сде­лать — уста­но­вить пакет OpenJDK.

Debian / Ubuntu

Нам необ­хо­ди­мо пра­виль­но под­клю­чить репо­зи­то­рий. Для это­го нуж­но перей­ти на стра­ни­цу загруз­ки Cassandra и вни­ма­тель­но посмот­реть на пред­ла­га­е­мые вер­сии про­грамм­но­го про­дук­та. На момент напи­са­ния инструк­ции, ста­биль­ной вер­си­ей была 4.0.х. В репо­зи­то­рии Cassandra назва­ния рели­зов стро­ят­ся исхо­дя из номе­ров вер­сий без точ­ки, то есть вер­сия 4.0.х будет рели­зом 40x.

Созда­ем файл:

vi /etc/apt/sources.list.d/cassandra.list

* где 40x соот­вет­ству­ет вер­сии 4.0.х. Есть и более све­жая вер­сия, но мы созна­тель­но выбра­ли ста­биль­ный релиз.
** если мы рабо­та­ем не с Debian, нас не долж­но сму­щать debian в назва­нии пути. Паке­ты рас­счи­та­ны для уста­нов­ки на любом DEB-дистрибутиве.

Доба­вим ключ репозитория:

curl https://downloads.apache.org/cassandra/KEYS | sudo apt-key add -

Обно­вим кэш репозиториев:

apt update

Мож­но уста­нав­ли­вать Cassandra:

apt install cassandra

Гото­во. Про­ве­рить состо­я­ние мож­но командой:

nodetool status

Rocky Linux

Содер­жи­мое кон­фи­гу­ра­ци­он­но­го фай­ла для репо­зи­то­рия зави­сит от вер­сии рели­за, кото­рую мы будем уста­нав­ли­вать. Пере­хо­дим на стра­ни­цу загруз­ки Cassandra и вни­ма­тель­но смот­рим на пред­ла­га­е­мые вер­сии про­грам­мы. Допу­стим, нам нуж­на ста­биль­ная вер­сия — на момент напи­са­ния дан­ной инструк­ции она была 4.0.х. В репо­зи­то­рии Cassandra назва­ния рели­зов стро­ят­ся исхо­дя из номе­ров вер­сий без точ­ки, то есть вер­сия 4.0.х будет рели­зом 40x.

Созда­ем файл:

vi /etc/yum.repos.d/cassandra.repo

* в нашем при­ме­ре пла­ни­ру­ет­ся уста­но­вить cassandra вер­сии 4.0.x.

Импор­ти­ру­ем GPG-клю­чи репозитория:

rpm --import https://downloads.apache.org/cassandra/KEYS

Уста­нав­ли­ва­ем СУБД:

yum install cassandra

Раз­ре­шим авто­старт и запу­стим сервис:

systemctl enable cassandra

systemctl start cassandra

Гото­во. Про­ве­рить состо­я­ние мож­но командой:

nodetool status

Установка бинарника

Это уни­вер­саль­ный спо­соб уста­нов­ки, кото­рый подой­дет для боль­шин­ства систем. Одна­ко, он тре­бу­ет допол­ни­тель­ных действий.

Для удоб­ства, разо­бьем про­цесс на этапы.

Установка OpenJDK

В систе­ме долж­на быть уста­нов­ле­на плат­фор­ма для обра­бот­ки Java. Самый удоб­ный спо­соб это сде­лать в Linux — уста­но­вить пакет OpenJDK.

Загрузка и распаковка бинарных файлов

На стра­ни­це загруз­ки Cassandra нахо­дим нуж­ную вер­сию СУБД и пере­хо­дим по ссылке.

На стра­ни­це копи­ру­ем ссыл­ку для ее загрузки:

* в нашем при­ме­ре ско­пи­ро­ва­на ссыл­ка на архив послед­ней ста­биль­ной версии.

Исполь­зуя ссыл­ку, ска­чи­ва­ем архив на сервере:

wget https://dlcdn.apache.org/cassandra/4.0.7/apache-cassandra-4.0.7-bin.tar.gz

Рас­па­ко­вы­ва­ем архив:

tar xzvf apache-cassandra-*-bin.tar.gz

Пере­но­сим содер­жи­мое в ката­лог /opt:

mv apache-cassandra-*/ /opt/cassandra

Настройка запуска

Для авто­за­пус­ка будем исполь­зо­вать сер­вис, создан­ный как юнит в systemd.

Созда­ем поль­зо­ва­те­ля, из-под кото­ро­го будет запус­кать­ся сервис:

useradd -r -c 'Cassandra database' cassandra

В каче­стве вла­дель­ца ката­ло­га /opt/cassandra зада­ем создан­но­го пользователя:

chown -R cassandra:cassandra /opt/cassandra

Созда­дим файл:

vi /etc/systemd/system/cassandra.service

Раз­ре­ша­ем сер­вис и стар­ту­ем его:

systemctl enable cassandra

systemctl start cassandra

Про­ве­рим состо­я­ние командой:

systemctl status cassandra

Настройка системных переменных и проверка работы СУБД

Так как бинар­ни­ки для запус­ка ути­лит, с помо­щью кото­рых мож­но рабо­тать с cassandra нахо­дят­ся в нестан­дарт­ном ката­ло­ге (/opt), нам нуж­но про­пи­сы­вать до них пол­ный путь. Это не очень удобно.

Созда­дим файл:

vi /etc/profile.d/cassandra.sh

* в нашем при­ме­ре мы доба­ви­ли 2 ката­ло­га — /opt/cassandra/bin и /opt/cassandra/tools/bin. При вво­де корот­кой коман­ды, систе­ма будет так­же учи­ты­вать дан­ные ката­ло­ги для поис­ка вве­ден­ной команды.

Теперь выхо­дим из теку­ще­го сеан­са (ком­би­на­ция Ctrl + D) и сно­ва вхо­дим в систе­му. Если необ­хо­ди­мо вой­ти под супер­поль­зо­ва­те­лем, исполь­зу­ем минус:

sudo su -

Про­бу­ем вве­сти команду:

nodetool status

Запуск в качестве приложения Docker

Дан­ный спо­соб удоб­нее с точ­ки зре­ния уста­нов­ки — нам не нуж­но ниче­го делать, так как при­ло­же­ние уже упа­ко­ва­но в кон­тей­нер. Одна­ко, нам необ­хо­ди­мо уметь рабо­тать с самим Docker.

Рас­смот­рим про­цесс под­го­тов­ки сце­на­рия docker-compose для запус­ка cassandra.

Установка Docker Engine

Так­же нам нуж­но уста­но­вить docker-compose. Дан­ный про­цесс так­же опи­сан в инструкции.

Создание сценария и запуск контейнера

Созда­дим ката­лог, в кото­ром будет сце­на­рий запус­ка cassandra:

mkdir /opt/cassandra

Перей­дем в него:

cd /opt/cassandra

Созда­дим сценарий:

vi docker-compose.yml

* обра­ти­те вни­ма­ние, что мы про­бра­сы­ва­ем содер­жи­мое ката­ло­га /var/lib/cassandra в кон­тей­не­ре в теку­щую дирек­то­рию (/opt/cassandra), пап­ку data.

Запус­ка­ем контейнер:

docker-compose up -d

Про­ве­рить ста­тус рабо­ты кас­сан­дры в docker мож­но командой:

docker exec -it cassandra nodetool status

Настройка подключения по сети

По умол­ча­нию, сер­вис слу­ша­ет на локаль­ном адре­се. При исполь­зо­ва­нии docker это не важ­но, но при уста­нов­ке СУБД из паке­тов или бинар­ни­ков мы не смо­жем под­клю­чить­ся к базе по сети.

Для нача­ла, убе­дим­ся, что бранд­мау­эр раз­ре­шить сете­вые запро­сы на пор­ту 9042 (на нем по умол­ча­нию рабо­та­ет cassandra). В зави­си­мо­сти от ути­ли­ты управ­ле­ния netfilter, наши дей­ствия будут отличаться.

а) Для iptables (как пра­ви­ло, на DEB):

iptables -I INPUT -p tcp --dport 9042 -j ACCEPT

Сохра­ня­ем правило:

apt install iptables-persistent

netfilter-persistent save

б) Для firewalld (как пра­ви­ло, на RPM):

firewall-cmd --permanent --add-port=9042/tcp

firewall-cmd --reload

Настрой­ка бранд­мау­э­ра завершена.

Теперь откры­ва­ем кон­фи­гу­ра­ци­он­ный файл cassandra. В зави­си­мо­сти от типа уста­нов­ки, путь до него будет отличаться.

а) При уста­нов­ке из пакетов:

vi /etc/cassandra/cassandra.yaml

б) Бинар­ни­ки:

vi /opt/cassandra/conf/cassandra.yaml

При­во­дим опцию rpc_address к виду:

rpc_address: 192.168.0.15

* где 192.168.0.15 — IP-адрес, на кото­ром слу­ша­ет наш сер­вер cassandra.

Если у нас несколь­ко сете­вых адре­сов и нуж­но, что­бы cassandra слу­ша­ла на каж­дом из них, то пра­вить нуж­но две опции:

rpc_address: 0.0.0.0
…
broadcast_rpc_address: 192.168.0.15

* rpc_address мы выстав­ля­ем на любой адрес, а в каче­стве зна­че­ния broadcast_rpc_address выстав­ля­ем адрес одно­го из интер­фей­сов, на кото­ром будет рабо­тать broadcast для вза­и­мо­дей­ствия с дру­ги­ми нода­ми (при рабо­те в режи­ме кластера).

Пере­за­пус­ка­ем сер­вер баз данных:

systemctl restart cassandra

Ждем око­ло 15 секунд. Про­ве­ря­ем, что сер­вер стал слу­шать на сете­вом адресе:

ss -tunlp | grep 9042

Мы долж­ны уви­деть что-то на подобие:

tcp    LISTEN   0        4096       192.168.0.15:9042

Для про­вер­ки под­клю­че­ния мож­но уста­но­вить cqlsh на любой дру­гой ком­пью­тер в сети.

Это мож­но выпол­нить раз­ны­ми спо­со­ба­ми, напри­мер, с помо­щью пакет­но­го мене­дже­ра pip. Сна­ча­ла его установим.

а) Для систем DEB:

apt install python3-pip

б) Для систем RPM:

yum install python3-pip

После уста­нов­ки pip мож­но перей­ти к уста­нов­ке cqlsh.

Выпол­ня­ем команду:

pip3 install cqlsh

Мож­но под­клю­чать­ся к СУБД по сети:

cqlsh 192.168.0.15

* напом­ним, что 192.168.0.15 — адрес сер­ве­ра cassandra.

Использование аутентификации

Откры­ва­ем кон­фи­гу­ра­ци­он­ный файл cassandra. В зави­си­мо­сти от типа уста­нов­ки, путь до него будет отличаться.

а) При уста­нов­ке из пакетов:

vi /etc/cassandra/cassandra.yaml

б) Бинар­ни­ки:

vi /opt/cassandra/conf/cassandra.yaml

Нахо­дим опцию:

authenticator: AllowAllAuthenticator

И меня­ем ее на:

authenticator: PasswordAuthenticator

Пере­за­пус­ка­ем cassandra:

systemctl restart cassandra

Инфор­ма­цию о логи­нах и паро­лях хра­нит­ся в систем­ной таб­ли­це. По умол­ча­нию, создан поль­зо­ва­тель cassandra с паро­лем cassandra.

Под­клю­чить­ся мож­но командой:

cqlsh -u cassandra 192.168.0.15

* где cassandra — логин; 192.168.0.15 — адрес сервера.

Систе­ма запро­сит пароль — вво­дим cassandra. В ито­ге, мы долж­ны уви­деть стро­ку вво­да команд:

cassandra@cqlsh>

Реко­мен­ду­ет­ся сра­зу создать новую учет­ную запись супер­поль­зо­ва­те­ля и отклю­чить встроенную:

* где test — логин; test111 — пароль.

Выхо­дим из команд­ной обо­лоч­ки cqlsh:

> quit

Захо­дим под создан­ной учет­ной записью:

cqlsh -u test 192.168.0.15

Для отклю­че­ния учет­ной запи­си по умол­ча­нию вводим:

> ALTER ROLE cassandra WITH SUPERUSER = false AND LOGIN = false;

SSL/TLS шифрование

Про­цесс настрой­ки шиф­ро­ван­но­го обме­на тра­фи­ка состо­ит из сле­ду­ю­щих шагов:

  1. Гене­ри­ру­ем сер­ти­фи­ка­ты для сер­ве­ра и клиента(ов).
  2. Настра­и­ва­ем сер­вер для рабо­ты с исполь­зо­ва­ни­ем создан­но­го сертификата.
  3. Настра­и­ва­ем клиента.

Рас­смот­рим эти шаги подробнее.

Создание сертификатов

Будем рабо­тать на сер­ве­ре. Созда­дим ката­лог для хра­не­ния сертификатов:

mkdir /etc/ssl/cassandra

Перей­дем в него:

cd /etc/ssl/cassandra

Вос­поль­зу­ем­ся ути­ли­той keytool для созда­ния хра­ни­ли­ща клю­чей java (keystore):

* в дан­ном при­ме­ре будет создан файл keystore.jks для хра­не­ния пар сер­ти­фи­ка­тов. Дан­ные в клю­че dname мож­но задать свои. Обра­ти­те вни­ма­ние, что в каче­стве паро­ля для keystore и клю­ча мы зада­ли cassandra.

Созда­дим сер­ти­фи­ка­ты для клиента:

* в дан­ном при­ме­ре мы созда­дим откры­тый ключ client1.pem и закры­тый client1.key. Дей­ствие дан­но­го сер­ти­фи­ка­та будет рас­про­стра­нять­ся на 1461 день (4 года). В клю­че subj пере­да­ют­ся дан­ные сер­ти­фи­ка­та — жела­тель­но, что­бы они соот­вет­ство­ва­ли вашей организации.

Экс­пор­ти­ру­ем сер­ти­фи­кат сер­ве­ра из создан­но­го ранее keystore.jks:

* в резуль­та­те мы полу­чим файл cassandra_server.pem, содер­жа­щий после­до­ва­тель­ность для шиф­ро­ва­ния дан­ных. Дан­ный файл будем исполь­зо­вать на клиентах.

Импор­ти­ру­ем кли­ент­ский сер­ти­фи­кат в кей­стор сервера:

* дан­ная коман­да создаст новый кей­стор-файл truststore.jks и импор­ти­ру­ет в него после­до­ва­тель­ность для клю­ча client1.

Под­твер­жда­ем импорт:

Сер­ти­фи­ка­ты готовы.

Настройка сервера

Откры­ва­ем файл кон­фи­гу­ра­ции. Напом­ним, что в зави­си­мо­сти от типа уста­нов­ки, путь до него будет отличаться.

а) При уста­нов­ке из пакетов:

vi /etc/cassandra/cassandra.yaml

б) Бинар­ни­ки:

vi /opt/cassandra/conf/cassandra.yaml

В открыв­шем­ся фай­ле нахо­дим дирек­ти­ву client_encryption_options.

При­во­дим ее к виду:

* где:

  • enabled — раз­ре­ша­ет исполь­зо­ва­ние шиф­ро­ва­ния меж­ду сер­ве­ром и клиентом.
  • keystore — путь до кейстор-файла.
  • keystore_password — пароль для keystore. В нашем при­ме­ре cassandra.
  • require_client_auth — тре­бу­ет про­вер­ки кли­ент­ских сертификатов.
  • truststore — путь до кей­сто­ра с дове­рен­ны­ми кли­ент­ски­ми сертификатами.
  • truststore_password — пароль для кон­тей­не­ра с дове­рен­ны­ми сер­ти­фи­ка­та­ми. В нашем при­ме­ре cassandra.

Для при­ме­не­ния настро­ек, пере­за­пу­стим сер­вис cassandra:

systemctl restart cassandra

Настрой­ка сер­ве­ра выпол­не­на. Мож­но пере­хо­дить к клиенту.

Настройка клиента и подключение к серверу

Копи­ру­ем фай­лы с сер­ве­ра на кли­ент­ский компьютер:

  • cassandra_server.pem
  • client1.key
  • client1.pem

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

mkdir /etc/ssl/cassandra

Созда­дим кон­фи­гу­ра­ци­он­ный файл для кли­ен­та cqlsh:

vi ~/.cassandra/cqlshrc

* стан­дарт­ный путь до кон­фи­гу­ра­ци­он­но­го фай­ла cqlshrc нахо­дит­ся в домаш­ней дирек­то­рии поль­зо­ва­те­ля + .cassandra/cqlshrc.

Про­пи­шем следующее:

* в дан­ном при­ме­ре мы ука­зы­ва­ем пути до после­до­ва­тель­но­стей, кото­рые долж­ны исполь­зо­вать­ся при шиф­ро­ва­нии данных.

Про­бу­ем под­клю­чить­ся к серверу:

cqlsh --ssl -u test 192.168.0.15

* для шиф­ро­ван­но­го под­клю­че­ния мы добав­ля­ем опцию --ssl.
** так как в нашем при­ме­ре мы настро­и­ли аутен­ти­фи­ка­цию, то в стро­ке под­клю­че­ния необ­хо­ди­мо ука­зать опцию -u и поль­зо­ва­те­ля (test).