Translate

неділю, 18 жовтня 2015 р.

Cassandra. Part II: Cluster

Тиждень тому я опублікував першу статтю про базу даних Cassandra. Це була теоретична стаття, у якій переважно було про те як влаштована Cassandra та її особливості. Цього разу я розповім як налаштувати власний кластер Cassandra.

Для побудови кластера будемо використовувати 4 віртуальні машини з такими адресами і хостнеймами:

10.131.75.141  cs-1
10.131.75.142  cs-2
10.131.75.143  cs-3
10.131.75.144  cs-4

Із них і буде складатись кільце кластеру (Token Ring). Отже, створимо ці віртуальні машини та додамо цей список адрес до кожної із них в /etc/hosts. У якості ОС я обрав Ubuntu 14.04. Кількість оперативної пам'яті для кожної віртуальної машини рівна 1 ГБ, що звісно достатньо лише для тестових цілей.

Установлюємо Java:

# add-apt-repository ppa:webupd8team/java
# apt-get update
# apt-get install oracle-java8-installer

# apt-get install oracle-java8-set-default

Та останню версію Cassandra з репозиторіїв DataStax:

# echo "deb http://debian.datastax.com/community stable main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list
# curl -L http://debian.datastax.com/debian/repo_key | sudo apt-key add -

# apt-get update
# aptitude install cassandra
The following NEW packages will be installed:
  cassandra libopts25{a} ntp{a} python-support{a} 
0 packages upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 24.9 MB of archives. After unpacking 34.0 MB will be used.
Do you want to continue? [Y/n/?]

Java та Cassandra, очевидно, необхідні на всіх нодах кластеру. Після установки перевіримо роботу бази, підключившись до неї через CQLSH:

# cqlsh
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 2.2.1 | CQL spec 3.3.0 | Native protocol v4]
Use HELP for help.
cqlsh> 

Зупиняємо Касандру на всіх нодах та чистимо дані баз:

# service cassandra stop
# rm -rf /var/lib/cassandra/data/system/*

Перший тип кластеру, який буде розглянуто - це SimpleSnitch (значення параметру endpoint_snitch). Це значення по-замовчуванню, що вказує на розподіл реплік баз без урахування топології чи фізичного розміщення серверів. Використовувати його має сенс у разі знаходження всіх серверів у одній локації. Для цього редагуємо (чи перевіряємо на правильність значення параметрів) конфігураційний файл Касандри на всіх нодах:

# vim /etc/cassandra/cassandra.yaml
...
cluster_name: 'MyFirstCluster'
seeds: "10.131.75.141, 10.131.75.142"
listen_address: current_ip_of_node
rpc_address: current_ip_of_node
endpoint_snitch: SimpleSnitch
...

current_ip_of_node - IP-адреса відповідного сервера, необхідно заповнити IP-адресу для кожної із нод;
seeds - сервера, котрі використовуються як еталонні ноди з сервісними даними на початку старту нових вузлів кластеру.

Запускаємо Касандру спочатку на seeds (за адресами 10.131.75.141, 10.131.75.142 ), а потім всіх інших вузлах:

# service cassandra start

Перевіряємо статус кластеру:

root@cs-1:~# nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens       Owns    Host ID                               Rack
UJ  10.131.75.144  88.06 KB   256          ?       bd1b2ef8-1b38-4c43-ab6b-0f419d6f971f  rack1
UN  10.131.75.143  141.68 KB  256          ?       e8f29b7d-31c5-4b03-ac04-db05750b79d9  rack1
UN  10.131.75.142  150.83 KB  256          ?       96e1a76e-9950-43c0-a666-17ad4477ada8  rack1
UN  10.131.75.141  111.3 KB   256          ?       f67876fc-4741-4a5d-bd33-426fc11120e5  rack1

З виводу видно, що 10.131.75.143, 10.131.75.142, 10.131.75.141 ноди кластеру знаходяться в стані підключеному до кластера "UP Normal (UN)", а 10.131.75.144 ще лише підключається і в стані "UP Joining (UJ)".

Всі ноди в результаті сприймаються як вузли, що знаходяться в одному дата-центрі і в одній rack-стійці.

Щоб більш убезпечити дані, варто розподіляти ноди кластеру між датацентрами і стійками. Саме для цього існує інший режим реплікації/організації кластеру - "PropertyFileSnitch". Налаштуємо цей режим, попередньо зупинивши демони Касандри та очистивши сервісні дані на всіх нодах кластеру:

# rm -rf /var/lib/cassandra/data/system/*
# service cassandra stop 

Припустимо, що попередньо описані ноди мають таке розміщення по датацентрам/стійкам:

10.131.75.141 - Датацентр 1, Rack-стійка 1
10.131.75.142 - Датацентр 1, Rack-стійка 2
10.131.75.143 - Датацентр 2, Rack-стійка 1
10.131.75.144 - Датацентр 2, Rack-стійка 2

Дамо знати Касандрі про цю топологію, описавши її в конфігураційному файлі:

# vim /etc/cassandra/cassandra-topology.properties

10.131.75.141=DC1:RAC1
10.131.75.142=DC1:RAC2
10.131.75.143=DC2:RAC1
10.131.75.144=DC2:RAC2

default=DC1:RAC1

DC та RAC - віртуальні поняття, не обов’язково ноди мають дійсно знаходитись в різних локаціях.

Наразі також необхідно поправити /etc/cassandra/cassandra.yaml:

# vim /etc/cassandra/cassandra.yaml
...
endpoint_snitch: PropertyFileSnitch
...
seeds: "10.131.75.141, 10.131.75.143"
...

У якості seeds було обрано 2 сервера, що лежать в різних датацентрах задля підвищення відмовостійкості та продуктивності: сервери в одному датацентрі по можливості будуть опитувати свій seed-сервер.

Перевіримо знову стан кластеру, після запуску процесу на всіх нодах:

# nodetool status
Datacenter: DC1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens       Owns    Host ID                               Rack
UN  10.131.75.142  449.42 KB  256          ?       d032b36b-ffb6-496a-b814-bab399ce8a1f  RAC2
UN  10.131.75.141  458.81 KB  256          ?       739c1e5f-2ff4-4bfa-9ae8-4f64ff061ce9  RAC1
Datacenter: DC2
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens       Owns    Host ID                               Rack
UN  10.131.75.144  549.85 KB  256          ?       47430976-dee6-40bb-bce2-2a9f8d401aba  RAC2
UN  10.131.75.143  422.95 KB  256          ?       7b3faef4-ba62-4d1d-87f8-9b0b082a0011  RAC1

Як варіант можна скористатись іншими режимами реплікації: GossipingPropertyFileSnitch, Ec2Snitch, Ec2MultiRegionSnitch, RackInferringSnitch. Про них можна почитати в офіційній документації.

Є можливість створювати свій рівень реплікації для кожної окремої бази:

root@cs-4:~# cqlsh 10.131.75.144 9042

CREATE KEYSPACE "testdb" WITH REPLICATION = { 'class' : 'SimpleStrategy' , 'replication_factor' :3 };

Тобто в кластері база з 'replication_factor' :3 буде існувати в 3 копіях, проте інші бази можуть мати відмінний від цього значення рівень.

Наразі можна записати дані в один вузол кластеру і перевірити їх наявність на іншому, що і буде слугувати коректністю налаштування кластеру.

Посилання:
http://blog.bissquit.com/?p=1061
http://arturmkrtchyan.com/how-to-setup-multi-node-cassandra-2-cluster
http://eax.me/cassandra/
http://docs.datastax.com/en/cassandra/2.1/cassandra/initialize/initializeMultipleDS.html

Немає коментарів:

Дописати коментар