Создание многоузлового кластера Cassandra

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

В этом руководстве вы установите Cassandra и запустите многоузловой кластер на сервере Ubuntu 22.04.

Требования

  • Минимум 2 сервера Ubuntu 22.04, настроенных с помощью этого руководства. На серверах должен быть пользователь без полномочий root, брандмауэр и не менее 2 ГБ ОЗУ. Cassandra не будет работать на сервере с 1 ГБ памяти. Дополнительную информацию см. в официальном руководстве Cassandra. Хорошо, если все ноды в кластере одинаковые или имеют похожие характеристики (но это не обязательно).
  • ​​Среда выполнения Java. Вы можете установить OpenJDK 8, OpenJDK 11, Oracle Java Standard Edition 8 или Oracle Java Standard Edition 11, выполнив раздел 1 мануала Установка Java с помощью apt в Ubuntu 20.04.
  • Установка Cassandra, которая описана здесь.

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

1: Настройка брандмауэра для Cassandra

Для работы многоузлового кластера все ноды должны иметь возможность обмениваться данными, а для этого брандмауэр должен пропускать трафик Cassandra. На этом шаге мы настроим брандмауэр, чтобы разрешить этот трафик.

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

  • 7000 — TCP-порт для команд и данных.
  • 9042 —TCP-порт собственного транспортного сервера. Утилита командной строки Cassandra cqlsh будет подключаться к кластеру через этот порт.

В соответствии с передовой практикой обеспечения безопасности вся связь для всех нод в центре обработки данных должна осуществляться через внутренние сетевые интерфейсы, а не через сетевые интерфейсы с выходом в Интернет. Обычно для этих целей используется сетевой интерфейс частной сети. Для каждой ноды в вашем кластере вам понадобится IP-адрес этого интерфейса.

Чтобы извлечь эту информацию через командную строку, используйте эту команду:

hostname -I | cut -d' ' -f3

Параметр I команды hostname выводит все IPv4-адреса, связанные с сервером, в одной строке, причем каждый адрес отделяется одним пробелом (кроме loopback 127.0.0.1). Затем этот вывод передается команде cut. Опция d сообщает команде cut, как отделить полученный вывод. В этом случае они разделены одним пробелом.

Параметр f3 указывает команде cut выводить третье поле, которое представляет собой IP-адрес нужного вам интерфейса частной сети.

Выполните эту команду на каждой ноде. После этого у вас должны быть IP-адреса частного сетевого интерфейса всех нод. Следующий шаг – изменение правил брандмауэра на каждом узле, использующем эти IP-адреса.

В этом руководстве первую ноду мы назовем node1, а вторую – node2. Если в командах вы увидите node1-internal-ip-address или node2-internal-ip-address, замените их извлеченными только что IP-адресами.

На node1 выполните следующую команду:

sudo ufw allow from node2-internal-ip-address to node1-internal-ip-address proto tcp port 7000,9042

На node2:

sudo ufw allow from node1-internal-ip-address to node2-internal-ip-address proto tcp port 7000,9042

Повторите команду для каждой ноды в вашем кластере, только измените последовательность IP-адресов. То есть, если в вашем кластере N узлов, вам нужно будет выполнить N – 1 эту команду на каждом узле.

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

sudo ufw status numbered

Вывод покажет правила, которые вы только что добавили:

Status: active

     To                         Action      From
     --                         ------      ----
[ 1] OpenSSH                    ALLOW IN    Anywhere                 
[ 2] 10.124.0.3 7000,9042/tcp  ALLOW IN    10.124.0.2               
[ 3] OpenSSH (v6)               ALLOW IN    Anywhere (v6)

При наличии правил брандмауэра вы сможете пинговать одну ноду с другой. Используйте эту команду в терминале для одной из ваших нод, чтобы отправить три пакета другой ноде:

ping -c 3 internal-ip-address-of-other-node

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

PING internal-ip-address-of-other-node (internal-ip-address-of-other-node) 56(84) bytes of data.
64 bytes from internal-ip-address-of-other-node: icmp_seq=1 ttl=64 time=0.043 ms
64 bytes from internal-ip-address-of-other-node: icmp_seq=2 ttl=64 time=0.061 ms
64 bytes from internal-ip-address-of-other-node: icmp_seq=3 ttl=64 time=0.066 ms

--- internal-ip-address-of-other-node ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2036ms
rtt min/avg/max/mdev = 0.043/0.056/0.066/0.009 ms

Если что-то пошло не так, проверьте правила брандмауэра, чтобы найти в них ошибку. Если вы не можете пропинговать одну ноду с другой, вы не сможете настроить свой многоузловой кластер Cassandra.

После настройки брандмауэра можно приступать к настройке Cassandra.

2: Удаление стандартных данных

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

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

Остановите демон Cassandra:

sudo systemctl stop cassandra

После этого удалите стандартные наборы данных:

sudo rm -rf /var/lib/cassandra/*

Опция r рекурсивно удаляет все файлы и папки в целевом каталоге. Опция f отключает запрос пользовательского ввода.

Когда вы сделаете это на всех нодах, которые должны стать частью вашего кластера, они будут готовы к настройке.

3: Настройка кластера Cassandra

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

Конфигурационный файл /etc/cassandra/cassandra.yaml содержит множество директив и очень хорошо прокомментирован. Начнем с ноды node1, откройте файл:

sudo nano /etc/cassandra/cassandra.yaml

Изменить нужно только следующие директивы в файле, чтобы настроить кластер Cassandra с несколькими нодами:

...
cluster_name: 'CassandraCluster'
...
seed_provider:
  - class_name: org.apache.cassandra.locator.SimpleSeedProvider
    parameters:
         - seeds: "node1-internal-ip-address"
...
listen_address: "targetnode-internal-ip-address"
...
rpc_address: "targetnode-internal-ip-address"
...
endpoint_snitch: GossipingPropertyFileSnitch
...
auto_bootstrap: false

Обновите cluster_name, указав имя вашего кластера. В этом примере используется CassandraCluster.

В разделе seed_provider находится разделенный запятыми список внутренних IP-адресов seed нод вашего кластера. В конфигурационном файле для каждой ноды в разделе – seed будет указан IP-адрес seeds ноды. Seed-нода уникальна, поскольку на ней вы будете запускать Cassandra.

По умолчанию listen_address и rpc_address имеют значение localhost, но его нужно заменить на внутренний IP-адрес целевой ноды. В файл на node1 вы поместите один и тот же внутренний IP-адрес node1 во всех трех местах. Для ноды node2 мы поместим node1-internal-ip-address в seed и используем node2-internal-ip-address для listen_address и rpc_address. Сделайте это для всех нод в вашем кластере.

endpoint_snitch задает имя класса snitch, который будет использоваться для обнаружения нод и маршрутизации запросов в кластере Cassandra. По умолчанию тут установлено значение SimpleSnitch, которое будет работать только для кластера Cassandra, чьи ноды находятся в одном центре обработки данных. Для производственных развертываний рекомендуется GossipingPropertyFileSnitch.

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

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

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

После того, как все ноды будут правильно настроены, перезапустите демон Cassandra на каждой из них.

4: Перезапуск Cassandra

После настройки всех нод вы можете перезапустить демон Cassandra, начиная с seed ноды.

Сначала выполните следующую команду в терминале для seed ноды:

sudo systemctl start cassandra

Убедитесь, что демон активен:

sudo systemctl status cassandra

Вы увидите такой вывод:

cassandra.service - LSB: distributed storage system for structured data
     Loaded: loaded (/etc/init.d/cassandra; generated)
     Active: active (running) since Sat 2022-07-09 22:43:19 UTC; 22h ago
       Docs: man:systemd-sysv-generator(8)
      Tasks: 70 (limit: 2327)
     Memory: 1.2G
        CPU: 44min 311ms
     CGroup: /system.slice/cassandra.service
             └─18800 /usr/bin/java -ea -da:net.openhft... -XX:+UseThreadPriorities -XX:+HeapDumpOnOutOfMemoryError -Xss256k -XX:+A>

Jul 09 22:43:19 cassa-1 systemd[1]: Starting LSB: distributed storage system for structured data...
Jul 09 22:43:19 cassa-1 systemd[1]: Started LSB: distributed storage system for structured data.

Используя те же команды, перезапустите демон на других нодах и убедитесь, что он работает.

Нам осталось только проверить состояние кластера и подключиться к нему.

5: Подключение к многоузловому кластеру Cassandra

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

Во-первых, убедитесь, что ноды обмениваются данными:

sudo nodetool status

Вы получите такой вывод:

Datacenter: dc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load        Tokens  Owns (effective)  Host ID                               Rack
UN  10.124.0.3  991.64 KiB  256     100.0%            9ab882d9-b408-4e75-bd00-79f278e81277  rack1
UN  10.124.0.2  413.57 KiB  256     100.0%            92fc1d95-cf4e-4a68-b1cf-d7e2507fc003  rack1

Если вы видите все настроенные вами ноды, значит, вы успешно настроили многоузловой кластер Cassandra.

Затем подключитесь к кластеру с помощью cqlsh. При использовании cqlsh можно указать IP-адрес любой ноды в кластере:

cqlsh server-internal-ip-address 9042

9042 — это TCP-порт, который cqlsh будет использовать для подключения к кластеру.

Вы увидите следующее:

Connected to CassandraCluster at 10.124.0.2:9042
[cqlsh 6.0.0 | Cassandra 4.0.4 | CQL spec 3.4.5 | Native protocol v5]
Use HELP for help.
cqlsh>

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

describe cluster

Вывод будет выглядеть так:

Cluster: CassandraCluster
Partitioner: Murmur3Partitioner
Snitch: DynamicEndpointSnitch

Введите exit, чтобы закрыть строку:

exit

Заключение

Теперь у вас есть многоузловой кластер Cassandra, работающий на сервере Ubuntu 22.04. Более подробная информация о Cassandra – на сайте проекта. Дополнительные сведения о seed нодах – здесь. Если вам нужно устранить неполадки кластера, проверьте файлы журналов в каталоге /var/log/cassandra.

Tags: , , , ,

Добавить комментарий