Translate

четвер, 17 січня 2013 р.

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

пʼятницю, 4 січня 2013 р.

Реплікація MongoDB: ReplicaSet

Зовсім нещодавно, я писав про реплікацію MySQL, тож хотілося б продовжити традицію. Цього разу мова піде про реплікацію MongoDB.

MongoDB підтримує два типи реплікацій Master-Slave (на кшталт такої в MySQL) та ReplicaSet. Остання - це прогресивніший варант, так як по-суті одразу забезпечує failover: обирання майстра, у разі відмови попереднього проходить "голосуванням" наявних інстансів (копій).  Це вже не кажучи про те, що ReplicaSet забезпечує читання зі слейвів (або як кажуть secondary-серверів), тим самим підвищуючи швидкість читання. Запити на запис відбуваються лише на головному (primary) сервері. Коротше кажучи, все вищесказане гарно ілюструє цей малюнок:


Приступимо до конфігурації. 3 інстанси демона MongoDB будуть запущені на локалхості, проте на різних портах.
Перед налаштуванням не забуваємо встановити базу данних.
Щоб не захламлювати систему створимо папку mongodb, а вже в ній папки 1, 2, 3 для кожної копії:

mkdir mongodb
cd mongodb
mkdir 1 2 3 

Запускаємо 3 копії демону mongod на портах 2700(1|2|3):

$ mongod --replSet test --dbpath 1 --port 27001 --smallfiles --oplogSize 50 --logpath 1.log --fork
forked process: 18922
all output going to: /media/other/mongodb/replication/1.log
child process started successfully, parent exiting

$ mongod --replSet test --dbpath 2 --port 27002 --smallfiles --oplogSize 50 --logpath 2.log --fork
forked process: 18983
all output going to: /media/other/mongodb/replication/2.log
child process started successfully, parent exiting

$ mongod --replSet test --dbpath 3 --port 27003 --smallfiles --oplogSize 50 --logpath 3.log --fork
forked process: 19029
all output going to: /media/other/mongodb/replication/3.log
child process started successfully, parent exiting