Тиждень тому я опублікував першу статтю про базу даних 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
Немає коментарів:
Дописати коментар