RabbitMQ Cluster. AMQP protocol

RabbitMQ - сервер черг, написаний на мові Erlang, що реалізує платформу обміну повідомленнями між компонентами програмної системи.

RabbitMQ побудований на фреймоворку Open Telecom Platform та реалізує стандарт обміну повідомленнями AMQP версії 0-9-1 (через плагіни також AMQP версії 1)

Для роботи з RabbitMQ існує багато готових бібліотек для основних мов програмування, що дозволяють без особливих надзусиль почати використовувати сервер у власній інфраструктурі.

Наразі розробкою RabbitMQ займається компанія Pivotal, що в свою чергу є підрозділом Dell. Код сервера відкритий і розповсюджується по ліцензії Mozilla Public License.

Перш за все розглянемо основні логічні одиниці, з яких складається процес роботи брокера повідомлень RabbitMQ (протоколу AMQP):

Отже, програма-генератор повідомлень (Producer) створює повідомлення і у разі, якщо в користувача, від якого вона працює, є права на їх запис у конкретний Virtual Host, повідомлення потрапляє до точки обміну (Exchange). У залежності від її типу та правил, за якою вона працює (Bindings), повідомлення записуються в черги (Queues). Далі вони відправляються до програм-споживачів (Consumers), що підписані на зміни до черг (push API), або ж останні самостійно їх забирають (pull API). У випадку push API споживачі повідомлень підписуються на зміни і, як результат, надсилають запити на реєстрацію (підписку) до черги. Кожен споживач має унікальний ідентифікатор, що зветься consumer tag. Він може використовуватись брокером для відписки останніх від черги.

Apache Kafka: Setup And Configuration

Apache Kafka - популярний сервер черг, що був створений для ефективної обробки великих обсягів даних в реальному часі. Кластер Kafka не лише гарно масштабується, але і має значно кращу продуктивність, в порівнянні з такими брокерами повідомлень, як ActiveMQ та RabbitMQ. Це зовсім не значить, що в останніх немає переваг.

Apache Kafka - це розробка компанії Linkedin, код якої було відкрито в 2011 році і пізніше переданий в інкубатор Apache. Сервер написаний на мові Scala, тож потребує Java-машину для роботи.

Що ж таке брокер повідомлень? Брокер повідомлень (сервер черг, система повідомлень) - це сервер, що відповідає за передачу даних від однієї програми (producer) до іншої (consumer). Брокер повідомлень допомагає абстрагуватись від того, як буде відбуватись обмін повідомленнями між програмами та зосередитись на написанні логіки програм, що працюють по обидва боки. Більш того, сервери черг дозволяють винести певну логіку на окремі сервери задля того, щоб основні потужності працювали швидко і без перебоїв, особливо якщо ця окрема логіка не термінова по часу виконання - щось на кшталт обробки фотографій для корисувачів і т.п. З іншого боку з брокерами повідомлень досить легко масштабувати споживачів (в т.ч. тимчасово), у разі якщо навантаження зросло чи ускладнилась логіка.

Також сервер черг корисно мати у разі, якщо програма-генератор повідомлень часом створює їх більше ніж програма-споживач може обробити, та деякі затримки у обробці цих повідомлень не є критичними. Наприклад, Rsyslog може слати логи напряму в Logstash, але якщо Rsyslog на деякий час почне генерувати їх більше, ніж останній може обробити, то Logstash може впасти, як зазвичай і відбувається. Коли ж в цю схему додати брокер Kafka між Rsyslog та Logstash, то перший буде все одразу віддавати в чергу, а останній по змозі все буде забирати з неї і обробляти. Більше того, часом Kafka-у використовують як основний лог-сервер, адже вона зберігає свої дані на диск.

Elasticsearch Cluster: Overview And Setup

Elasticsearch - це пошукова платформа майже реального часу (near real time, NRT). На практиці це означає, що існує лише мінімальна затримка (зазвичай біля секунди) між часом додавання документу до індексу і часом, коли він стає доступним для пошуку.

Elasticsearch, як і його основний конкурент Solr, базується на бібліотеці Lucene. Сам по собі Apache Lucene не являється повноцінним сервісом: це просто бібліотека для побудови пошукових систем, вона займається лише індексом та пошуком. А, власне, за введення даних, налаштування сервісу, кластеризацію, маршрутизацію пошукових запитів та ін. відповідає Elasticsearch чи інша "обгортка".

Використання та налаштування (переважно) здійснюється за допомогою RESTful API запитів. У випадку з unix-подібною OC з цим може допомогти curl. Але про це дещо далі.

Спочатку почнемо з базової термінології Elasticsearch.

Кластер (Cluster)

Сервери, що обслуговують один набір даних та забезпечують індексацію та їх пошук по всіх серверах. Кластер також може складатись лише з єдиного сервера, проте в цьому випадку не може йти мова про високу доступність.

Про те як створити кластер я напишу нижче.

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> 

GlusterFS: setup and configuration

GlusterFS — розподілена файлова система, що дозволяє організувати роботу розподіленого на кілька вузлів сховища, розгорнутого поверх штатних файлових систем POSIX, таких як Ext4, XFS і Btrfs, з використанням механізму FUSE (файлова система у просторі користувача). GlusterFS надає засоби автоматичного відновлення після збоїв і забезпечує практично необмежену масштабованість, завдяки відсутності прив'язки до централізованого серверу мета-даних (використовуються розподілені хеш-таблиці).

Цю файлову систему застосовують у хмарних обчисленнях, службах потокового медіа та у мережах постачання даних. (c) Wikipedia

Ключові особливості GlusterFS:

* Еластичність - томи зберігання даних абстраговані від заліза, на якому фізично знаходяться і можуть бути як-завгодно збільшені/зменшені/переміщені в межах фізичних систем.
* Відсутність окремого сервера метаданих - на відміну від інших розподілених файлових систем (наприклад, Lustre), GlusterFS не використовує окремого сервера для метаданих. Таким чином у неї відсутня єдина точка відмови.
* Масштабованість - досить просто збільшити або зменшити розмір файлової системи, без даунтайму. Може маштабуватись як у продуктивності так і обсягу даних.
* Висока доступність - у випадку правильного проектування тому, випадання окремого серверу не призведе до простою системи. Звісно, рівень доступності залежить від кількості реплікацій.
* Гнучкість - GlusterFS працює в просторі користувача (FUSE), тому не потрібно патчити ядро, додавати до нього модулі і т.д. Проте з іншої сторони, файлові системи в ядрі працюють швидше.
* Гео-реплікація - GlusterFS дозволяє синхронізувати всю систему збереження даних між різними датацентрами чи географічними місцями.

Налаштування GlusterFS достатньо просте. Конфігурацію будемо проводити на 3 віртуальних машинах: 2 сервера та 1 клієнт. До клієнта буде примонтований розділ GlusterFS, котрий буде попередньо створений на серверах.

MySQL/Galera replication with Haproxy balancing

MySQL/Galera - синхронний мульти-майстер кластер для MySQL/InnoDB бази данних, що володіє такими перевагами:
- синхронна реплікація.
- аctive-active мульти-майстер топологія
- читання чи запис на будь-яку ноду кластеру.
- автоматичний контроль членів кластеру: проблемні члени будуть автоматично виключені з діючого кластеру.
- автоматичне (просте) додавання додаткових серверів до кластеру. Зручне масштабування.
- справжня паралельна реплікація, на рівні рядків.

Додам, що звичайна реплікація типу master-master не є синхронною. На активному майстрі всі запити спочатку будуть записані в binlog і лише потім будуть передані на інший пасивний MySQL-майстер (слейв), запити на пасивному сервері можуть виконуватись із значною затримкою. У випадку із Galera запити на кожній ноді виконуються одночасно, або майже одночасно.

MySQL/Galera кластер використовує бібліотеку Galera для реалізації реплікації, що працює через MySQL wsrep API (патчена версія MySQL)

Як я вже згадував Galera допускає запис на будь-яку ноду кластеру, навіть одночасні записи із різних нод в одну таблицю. Все це завдяки алгоритму сертифікації транзакцій:

Логіка алгоритму сертифікації приблизно така: SQL-запити приходить на різні сервери кластеру і якщо вони конфліктують між собою (наприклад, запис в той самий рядок таблиці) відбувається роллбек і послідовне виконання запитів (виправте, якщо я помиляюсь).

Linux HA: Pacemaker / Corosync

При проектуванні високонавантажених систем високої доступності важливо задуматись про надлишковість ресурсів, тобто при падінні якогось важливого серверу (сервісу) було б добре, коли його "підстрахує" інший сервер, налаштований аналогічно. Саме задля цього компанії Red Hat та Novell розробили дуже класну штуку Pacemaker+Corosync.

Це комплекс демонів, які власне і забезпечують все вищесказане.
Даний комплекс базується чи частково використовує попередні розробки типу Heartbeat чи OpenAIS.

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

1. Не кластерні компоненти (зображені зеленим кольором) - це ресурси та скрипти, що відповідають за їхній старт, зупинку чи моніторинг.

2. Менеджер ресурсів Pacemaker  (зображений синім кольором) - "мозок" кластера, проводить обробку подій та процесів (даних, що представили нижчі рівні) та приймає рішення щодо включення/виключення нод із кластеру. Власне Pacemaker розраховує ідеальний стан кластеру шляхом слідування правилам.

3. Інфраструктура низького рівня (зображено червоним), до якої входить Corosync. Corosync забезпечує обмін повідомленнями з Pacemaker щодо стану серверів в кластері (який із серверів працює чи ні і т.д. )

Для початку опишемо конфігурацію, котру маємо:

Node-1:
Hostname: pcmk-1
IP: 192.168.1.23

Node-2:
Hostname: pcmk-2
IP: 192.168.1.24

На обох серверах встановлено CentOS 6.3 зі стандартним ядром 2.6.32. Нехай на кожному сервері працює Apache і необхідно, щоб у разі падіння одного з серверів відбувався failover, тобто перемикання на працюючий сервер. Як наслідок такий варіант забезпечить максимальну доступність, лише піде деякий час на перемикання нод. 

Переходимо до конфігурації. Редагуємо /etc/hosts (чи свій власний dns, якщо такий є) задля перетворення доменних імен в IP:

# grep pcmk /etc/hosts

192.168.1.23 pcmk-1

192.168.1.24 pcmk-2

Налаштування MySQL-реплікації типу Master - Master (Slave)

Власне налаштування  реплікації серверів баз даних - дуже важлива складова будь-якого High Load проекту. Надіюсь, що ця невеличка замітка допоможе комусь в освоєні даної теми,  або ж принаймні нагадає мені певні деталі з часом.  :)

Тож до справи!

Для початку опишимо певні деталі. Будемо вважати, що сервера мають такі айпі:

centos1 - 192.168.1.23
centos2 - 192.168.1.24

Редагуємо /etc/my.cnf сервера centos1. Додаємо до вже існуючих параметрів такі:

[mysqld]
# Номер сервера, що реплікується. У кожного має бути унікальний id.

server-id = 1

# Конфігурація сервера, як майстра. Указуємо, де будуть зберігатись бінлоги. 
# Бінлог - це список SQL-запитів (окрім SELECT та SHOW запитів ), що були виконані на сервері задля подальшої їх передачі на слейв.

log-bin = /var/lib/mysql/mysql-bin

# Конфігурація сервера, як слейва. Relay-log - лог дій, котрі були виконані на слейві за ініціативи майстра.
relay-log = /var/lib/mysql/mysql-relay-bin
relay-log-index = /var/lib/mysql/mysql-relay-bin.index
#База, що буде реплікуватись.
replicate-do-db = dbwordpress

Для сервера centos2 необхідно прописати ідентичні параметри, окрім значення 'server-id' (змініть цифру наприклад на 2).
Рестартуємо mysql на кожному сервері.