Будуємо своє власне надійне хмару на базі OpenNebula з Ceph, MariaDB Galera Cluster і OpenvSwitch



На цей раз я б хотів розповісти, як налаштувати цей сабж, в часності кожен окремий компонент, що б у підсумку отримати своє власне, розширюване, отказоустойчеавое хмару на базі OpenNebula. У даній статті я розгляну наступні моменти:

Теми самі по собі дуже цікаві, так що навіть якщо вас не цікавить кінцева мета, але цікавить налаштування якого-небудь окремого компонента. Ласкаво прошу під кат.



image

Невеликий вступ

І так, що ж ми отримаємо в результаті?
Після прочитання цієї статті ви зможете розгорнути своє власне гнучка, розширювана і до того ж надійне хмару на базі OpenNebula. Що ж означають ці слова? — Давайте розберемо:

  • Розширюване — це означає, що вам не доведеться перебудовувати ваше хмара при розширенні. У будь-який момент ви зможете розширити ваше місце в хмарі, всього лише додавши додаткові жорсткі диски в пул ceph. Ще ви можете без проблем налаштувати нову ноду і ввести її в кластер при бажанні.

  • Гнучке — девіз OpenNebula так і звучить «Flexible Enterprise Cloud Made Simple». OpenNebula дуже проста в освоєнні і до того ж дуже гнучка система. Вам не складе труднощів розібратися з нею, а так само при необхідності написати для неї свій модуль, оскільки вся система стоїть так, що б бути максимально простий і модульної.

  • Отказоустойчевое — У разі виходу з ладу жорсткого диска, кластер сам пересторится так, що б забезпечити необхідну кількість реплік ваших даних. У разі виходу з ладу однієї ноди, ви не втратите управління, а хмара продовжить функціонувати до усунення вами проблеми.


image
Що нам для цього треба?

  • Я буду описувати установку на 3 ноди, але у вашому випадку їх може бути скільки завгодно.
    Ви так само можете встановити OpenNebula на одну ноду, але в цьому випадку ви не зможете побудувати отказоустойчевый кластер, а вся ваша установка з цього керівництву зведеться лише до встановлення самої OpenNebula, і наприклад, OpenvSwitch.
    до Речі, ще ви можете встановити CentOS ZFS, прочитавши мою попередню статтю (не для продакшену) і налаштувати OpenNebula на ZFS, використовуючи написаний мною ZFS-драйвер

  • Так само, для функционировния Ceph, вкрай бажана 10G мережа. В іншому випадку, вам не має сенсу піднімати окремий кеш-пул, так як швидкісні характеристики вашої мережі будуть навіть нижче, ніж швидкість запису на пул з одних тільки HDD.

  • На всіх ноди встановлено CentOS 7.

  • Так само кожна нода містить:
    • 2SSD за 256GB — для кеш-пулу
    • 3HDD за 6TB — для основного пулу

    • Оперативної пам'яті, достатньої для функціонування Ceph (1GB ОЗУ на 1TB даних)
    • Ну і ресурси, необхідні для самого хмари, CPU і пам'ять, які ми будемо використовувати для запуску віртуальних машин
  • Ще хотів додати, що установка і робота майже всіх компонентів вимагає відключеного SELINUX. Так що на всіх трьох ноди він відключений:
    sed -i s/SELINUX=enforcing/SELINUX=disabled/g /etc/selinux/config
    setenforce 0
    

  • На кожній ноде встановлено EPEL-репозиторій:
    yum install epel-release
    


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

І табличка з характеристиками кожної ноди:









Hostname kvm1 kvm2 kvm3 Network Interface enp1 enp1 enp1 IP address 192.168.100.201 192.168.100.202 192.168.100.203 HDD sdb sdb sdb HDD sdc sdc sdc HDD sdd sdd sdd SSD sde sde sde SSD sdf sdf sdf


Все, тепер можна приступати до налаштування! І почнемо ми мабуть з побудови сховища.



Ceph
Про ceph на хабре вже не раз писали. Наприклад, teraflops досить детально описав його пристрій і базові поняття у своїй статті. Рекомендовано до прочитання.

Тут же опишу налаштування ceph для зберігання блокових пристроїв RBD (RADOS Block Device) для наших віртуальних машин, а так само налаштування кеш-пулу для прискорення операцій введення-ввывода в ньому.

Отже ми маємо три ноди kvm1, kvm2, kvm3. Кожна з них має 2 SSD диска і 3 HDD. На цих дисках ми й піднімемо два пула, один — основний на HDD, другий — кеш на SSD. В цілому у нас должо вийти щось подібне:
image

Підготовка

Установка буде здійснюватися за допомогою ceph-deploy, а вона передбачає встановлення так званого админского сервера.
Як админского сервера може служити будь-який комп'ютер c встановленим ceph-depoy і ssh-клієнт, у нашому випадку таким сервером буде виступати одна з нод kvm1.

Нам необхідно на кожній ноде мати користувача ceph, а так само дозволити йому безпарольно ходити між нодами і виконувати будь-які команди через sudo так само без пароля.

На кожній ноде виконуємо:

sudo useradd -d /home/ceph -m ceph
sudo passwd ceph
sudo echo "ceph ALL = (root) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/ceph
sudo chmod 0440 /etc/sudoers.d/ceph


Заходимо на kvm1.

Тепер згенеруємо ключ і скопіюємо його на інші ноди
sudo ssh-keygen -f /home/ceph/.ssh/id_rsa
sudo cat /home/ceph/.ssh/id_rsa.pub >> /home/ceph/.ssh/authorized_keys
sudo chown -R ceph:users /home/ceph/.ssh
for i in 2 3; do
scp /home/ceph/.ssh/* ceph@kvm$i:/home/ceph/.ssh/
done


Установка
Додаємо ключ, встановимо репозиторій ceph і ceph-depoy з нього:

sudo rpm --import 'https://download.ceph.com/keys/release.asc'
sudo yum -y localinstall http://download.ceph.com/rpm/el7/noarch/ceph-release-1-1.el7.noarch.rpm
sudo yum install -y ceph-deploy


Ок, тепер заходимо за юзера ceph і створюємо папку, в якій ми будемо зберігати конфіги і ключі для ceph.
sudo su - ceph
mkdir ceph-admin
cd ceph-admin


Тепер встановимо ceph на всі наші ноди:
ceph-deploy install kvm{1,2,3}


Тепер створимо кластер
ceph-deploy new kvm{1,2,3}


Створимо монітори і отримаємо ключі:
ceph-deploy mon create kvm{1,2,3}
ceph-deploy gatherkeys kvm{1,2,3}


Тепер згідно нашої первісної схеми підготуємо наші диски, і запустимо OSD-демони:
# Flush disks
ceph-deploy disk zap kvm{1,2,3}:sd{b,c,d,e,f} 
# SSD-disks
ceph-deploy osd create kvm{1,2,3}:sd{e,f}
# HDD-disks
ceph-deploy osd create kvm{1,2,3}:sd{b,c,d}


Подивимося що у нас вийшло:
ceph osd tree
висновок
ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY 
-1 3.00000 root default 
-2 1.00000 host kvm1 
0 1.00000 osd.0 up 1.00000 1.00000 
1 1.00000 osd.1 up 1.00000 1.00000 
6 1.00000 osd.6 up 1.00000 1.00000 
7 1.00000 osd.7 up 1.00000 1.00000 
8 1.00000 osd.8 up 1.00000 1.00000 
-3 1.00000 host kvm2 
2 1.00000 osd.2 up 1.00000 1.00000 
3 1.00000 osd.3 up 1.00000 1.00000 
9 1.00000 osd.9 up 1.00000 1.00000 
10 1.00000 osd.10 up 1.00000 1.00000 
11 1.00000 osd.11 up 1.00000 1.00000 
-4 1.00000 host kvm3 
4 1.00000 osd.4 up 1.00000 1.00000 
5 1.00000 osd.5 up 1.00000 1.00000 
12 1.00000 osd.12 up 1.00000 1.00000 
13 1.00000 osd.13 up 1.00000 1.00000 
14 1.00000 osd.14 up 1.00000 1.00000 


Перевіряємо стан кластера:
ceph -s


Налаштування кеш-пулу
image
Отже, у нас є повноцінний ceph-кластер.
Давайте ж налаштуємо для нього кешуючий пул, для початку нам треба відредагувати карти CRUSH що б визначити правила, за якими у нас будуть розподілятися дані. Що б наш кеш-пул перебував тільки на SSD-дисках, а основний пул тільки на HDD.

Для початку нам потрібно заборонити ceph оновлювати карту автоматично, допишемо в ceph.conf
osd_crush_update_on_start = false


І оновимо його на наших ноди:
ceph-deploy admin kvm{1,2,3}


Збережемо нашу нинішню карту і переведемо її в текстовий формат:
ceph osd getcrushmap -o map.running
crushtool -d map.running -o map.decompile


давайте приведемо її до такого виду:

map.decompile
# begin crush map
tunable choose_local_tries 0
tunable choose_local_fallback_tries 0
tunable choose_total_tries 50
tunable chooseleaf_descend_once 1
tunable straw_calc_version 1

# devices
device 0 osd.0
device 1 osd.1
device 2 osd.2
device 3 osd.3
device 4 osd.4
device 5 osd.5
device 6 osd.6
device 7 osd.7
device 8 osd.8
device 9 osd.9
device 10 osd.10
device 11 osd.11
device 12 osd.12
device 13 osd.13
device 14 osd.14

# types
type 0 osd
type 1 host
type 2 chassis
type 3 rack
type row 4
type 5 pdu
type 6 pod
type 7 room
type 8 datacenter
type 9 region
type 10 root

# buckets
host kvm1-ssd-cache {
id -2 # do not change unnecessarily
# weight 0.000
alg straw
hash 0 # rjenkins1
item osd.0 weight 1.000
item osd.1 weight 1.000
}
host kvm2-ssd-cache {
id -3 # do not change unnecessarily
# weight 0.000
alg straw
hash 0 # rjenkins1
item osd.2 weight 1.000
item osd.3 weight 1.000
}
host kvm3-ssd-cache {
id -4 # do not change unnecessarily
# weight 0.000
alg straw
hash 0 # rjenkins1
item osd.4 weight 1.000
item osd.5 weight 1.000
}
host kvm1-hdd {
id -102 # do not change unnecessarily
# weight 0.000
alg straw
hash 0 # rjenkins1
item osd.6 weight 1.000
item osd.7 weight 1.000
item osd.8 weight 1.000
}
host kvm2-hdd {
id -103 # do not change unnecessarily
# weight 0.000
alg straw
hash 0 # rjenkins1
item osd.9 weight 1.000
item osd.10 weight 1.000
item osd.11 weight 1.000
}
host kvm3-hdd {
id -104 # do not change unnecessarily
# weight 0.000
alg straw
hash 0 # rjenkins1
item osd.12 weight 1.000
item osd.13 weight 1.000
item osd.14 weight 1.000
}
root ssd-cache {
id -1 # do not change unnecessarily
# weight 0.000
alg straw
hash 0 # rjenkins1
item kvm1-ssd-cache weight 1.000
item kvm2-ssd-cache weight 1.000
item kvm3-ssd-cache weight 1.000
}
root hdd {
id -100 # do not change unnecessarily
# weight 0.000
alg straw
hash 0 # rjenkins1
item kvm1-hdd weight 1.000
item kvm2-hdd weight 1.000
item kvm3-hdd weight 1.000
}

# rules
rule ssd-cache {
ruleset 0
type replicated
min_size 1
max_size 10
step take ssd-cache
step chooseleaf firstn 0 type host
step emit
}

rule hdd {
ruleset 1
type replicated
min_size 1
max_size 10
step take hdd
step chooseleaf firstn 0 type host
step emit
}# end crush map


Можна помітити, що замість одного root я зробив два, для hdd і ssd, теж саме сталося з rule і кожним host.
При редагуванні карти вручну будьте гранично уважні і не заплутатися в id'шниках!

Тепер скомпилируем і призначимо її:
crushtool -c map.decompile -o map.new
ceph osd setcrushmap -i map.new


Подивимося що у нас вийшло:
ceph osd tree
висновок
ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY 
-100 3.00000 root hdd 
-102 1.00000 host kvm1-hdd 
6 1.00000 osd.6 up 1.00000 1.00000 
7 1.00000 osd.7 up 1.00000 1.00000 
8 1.00000 osd.8 up 1.00000 1.00000 
-103 1.00000 host kvm2-hdd 
9 1.00000 osd.9 up 1.00000 1.00000 
10 1.00000 osd.10 up 1.00000 1.00000 
11 1.00000 osd.11 up 1.00000 1.00000 
-104 1.00000 host kvm3-hdd 
12 1.00000 osd.12 up 1.00000 1.00000 
13 1.00000 osd.13 up 1.00000 1.00000 
14 1.00000 osd.14 up 1.00000 1.00000 
-1 3.00000 root ssd-cache 
-2 1.00000 host kvm1-ssd-cache 
0 1.00000 osd.0 up 1.00000 1.00000 
1 1.00000 osd.1 up 1.00000 1.00000 
-3 1.00000 host kvm2-ssd-cache 
2 1.00000 osd.2 up 1.00000 1.00000 
3 1.00000 osd.3 up 1.00000 1.00000 
-4 1.00000 host kvm3-ssd-cache 
4 1.00000 osd.4 up 1.00000 1.00000 
5 1.00000 osd.5 up 1.00000 1.00000 


Тепер опишемо нашу конфігурацію в конфіг ceph.conf, а зокрема запишемо дані про моніторах і osd.

У мене вийшов такий конфіг:

ceph.conf
[global]
fsid = 586df1be-40c5-4389-99ab-342bd78566c3
mon_initial_members = kvm1, kvm2, kvm3
mon_host = 192.168.100.201,192.168.100.202,192.168.100.203
auth_cluster_required = cephx
auth_service_required = cephx
auth_client_required = cephx
filestore_xattr_use_omap = true
osd_crush_update_on_start = false

[mon.kvm1]
host = kvm1
mon_addr = 192.168.100.201:6789
mon-clock-drift-allowed = 0.5

[mon.kvm2]
host = kvm2
mon_addr = 192.168.100.202:6789
mon-clock-drift-allowed = 0.5

[mon.kvm3]
host = kvm3
mon_addr = 192.168.100.203:6789
mon-clock-drift-allowed = 0.5

[client.admin]
keyring = /etc/ceph/ceph.client.admin.keyring

[osd.0]
host = kvm1

[osd.1]
host = kvm1

[osd.2]
host = kvm2

[osd.3]
host = kvm2

[osd.4]
host = kvm3

[osd.5]
host = kvm3

[osd.6]
host = kvm1

[osd.7]
host = kvm1

[osd.8]
host = kvm1

[osd.9]
host = kvm2

[osd.10]
host = kvm2

[osd.11]
host = kvm2

[osd.12]
host = kvm3

[osd.13]
host = kvm3

[osd.14]
host = kvm3


І роздамо його нашим хостам:
ceph-deploy admin kvm{1,2,3}


Перевіряємо стан кластера:
ceph -s


Створення пулів
image
Для створення пулів, нам потрібно порахувати правильне кількість pg (Placment Group), вони потрібні для алгоритму CRUSH. Формула розрахунку така:
(OSDs * 100)
Total PGs = ------------
Replicas
і окруление вгору, до найближчої ступеня числа 2

Тобто в нашому випадку, якщо ми плануємо мати тільки один пул на SSD і один пул на HDD з реплікою 2, формула розрахунку виходить наступна:
HDD pool pg = 9*100/2 = 450[округляємо] = 512
SSD pool pg = 6*100/2 = 300[округляємо] = 512

Якщо пулів на наш root планується кілька, то отримане значення слід розділити на кількість пулів

Створюємо пули, призначаємо їм size 2 — розмір репліки, це означає що записані в нього дані будуть дублюватися на різних дисках, і min_size 1 — мінімальний розмір репліки в момент запису, тобто скільки потрібно зробити реплік в момент запису, що б «відпустити» операцію запису.

ceph osd pool create ssd-cache 512
ceph osd set pool ssd-cache min_size 1
ceph osd set pool ssd-cache size 2
ceph osd pool create one 512
ceph osd pool set one min_size 1
ceph osd pool set one size 2
Пул one — ясна річ буде використовуватися для зберігання образів OpenNebula

Призначаємо правила нашим пулам:
ceph osd set pool ssd-cache crush_ruleset 0
ceph osd pool set one crush_ruleset 1


Налаштовуємо що запис в пул one буде проводитися через наш кеш-пул:
ceph osd tier add one ssd-cache
ceph osd tier cache-mode ssd-cache writeback
ceph osd tier set-overlay one ssd-cache


Ceph використовують 2 основних операції очищення кешу:
  • Flushing (промивка): агент визначає остиглі об'єкти і скидає їх в пул зберігання
  • Evicting (виселення): агент визначає неостывшие об'єкти і починаючи з самих старих, скидає їх в пул зберігання
Для визначення «гарячих» об'єктів використовується так званий Фільтр Блума.

Налаштовуємо параметри нашого кешу:
# Включем фільтр bloom
ceph osd set pool ssd-cache hit_set_type bloom
# Скільки звернень до об'єкту що б він вважався гарячим
ceph osd set pool ssd-cache hit_set_count 4
# Скільки часу об'єкт буде вважатися гарячим
ceph osd set pool ssd-cache hit_set_period 1200


Так само налаштовуємо
# Скільки байтів має заповнитися перш ніж включиться механізм очищення кешу
ceph osd set pool ssd-cache target_max_bytes 200000000000
# Відсоток заповнення сховища, при якому починається операція промивання
ceph osd set pool ssd-cache cache_target_dirty_ratio 0.4
# Відсоток заповнення сховища, при якому починається операція виселення
ceph osd set pool ssd-cache cache_target_full_ratio 0.8 
# Мінімальну кількість часу, перш ніж об'єкт буде промитий
ceph osd set pool ssd-cache cache_min_flush_age 300 
# Мінімальну кількість часу, перш ніж об'єкт буде виселений
ceph osd set pool ssd-cache cache_min_evict_age 300 


Ключі

Створимо користувача one і згенеруємо для нього ключ
ceph auth get-or-create client.one mon 'allow r' osd 'allow rw pool=ssd-cache' -o /etc/ceph/ceph.client.one.keyring

Так як він не буде писати безпосередньо в основний пул, надамо йому права тільки на ssd-cache пул.

На цьому налаштування Ceph можна вважати завершеною.



MariaDB Galera Cluster
image

Тепер налаштуємо відмовостійку MySQL базу даних на наших ноди, в якій ми будемо зберігати конфігурацію нашого дата-центру.
MariaDB Galera Cluster — це MariaDB кластер з майстер-майстер реплікацією використовує для синхронізації galera-бібліотеку.
Плюс до всього він досить простий в налаштуванні:

Установка

На всіх ноди
Встановимо репозиторій:
cat << EOT > /etc/yum.repos.d/mariadb.repo
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.0/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG KEY-MariaDB
gpgcheck=1
EOT


І сам сервер:
yum install MariaDB-Galera-server MariaDB-client rsync galera


запустимо демон, і зробимо початкову установку:
service mysql start
chkconfig on mysql
mysql_secure_installation


Налаштовуємо кластер:

На кожній ноде створимо користувача для реплікації:
mysql -p
GRANT USAGE ON *.* to sst_user@'%' IDENTIFIED BY 'PASS';
GRANT ALL PRIVILEGES on *.* to sst_user@'%';
FLUSH PRIVILEGES;
exit
service mysql stop


Наведемо конфіг /etc/my.cnf до наступного вигляду:
Для kvm1:
cat << EOT > /etc/my.cnf
collation-server = utf8_general_ci
init-connect = 'SET NAMES utf8'
character-set-server = utf8
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
innodb_locks_unsafe_for_binlog=1
query_cache_size=0
query_cache_type=0
bind-address=0.0.0.0
datadir=/var/lib/mysql
innodb_log_file_size=100M
innodb_file_per_table
innodb_flush_log_at_trx_commit=2
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://192.168.100.202,192.168.100.203"
wsrep_cluster_name='galera_cluster'
wsrep_node_address='192.168.100.201' # setup real node ip
wsrep_node_name='kvm1' # setup real node name
wsrep_sst_method=rsync
wsrep_sst_auth=sst_user:PASS
EOT


За аналогією з kvm1 запишемо конфіги для інших нсд:
kvm2
cat << EOT > /etc/my.cnf
collation-server = utf8_general_ci
init-connect = 'SET NAMES utf8'
character-set-server = utf8
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
innodb_locks_unsafe_for_binlog=1
query_cache_size=0
query_cache_type=0
bind-address=0.0.0.0
datadir=/var/lib/mysql
innodb_log_file_size=100M
innodb_file_per_table
innodb_flush_log_at_trx_commit=2
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://192.168.100.201,192.168.100.203"
wsrep_cluster_name='galera_cluster'
wsrep_node_address='192.168.100.202' # setup real node ip
wsrep_node_name='kvm2' # setup real node name
wsrep_sst_method=rsync
wsrep_sst_auth=sst_user:PASS
EOT
kvm3
cat << EOT > /etc/my.cnf
collation-server = utf8_general_ci
init-connect = 'SET NAMES utf8'
character-set-server = utf8
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
innodb_locks_unsafe_for_binlog=1
query_cache_size=0
query_cache_type=0
bind-address=0.0.0.0
datadir=/var/lib/mysql
innodb_log_file_size=100M
innodb_file_per_table
innodb_flush_log_at_trx_commit=2
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://192.168.100.201,192.168.100.202"
wsrep_cluster_name='galera_cluster'
wsrep_node_address='192.168.100.203' # setup real node ip
wsrep_node_name='kvm3' # setup real node name
wsrep_sst_method=rsync
wsrep_sst_auth=sst_user:PASS
EOT


Готово, настав час запустити наш кластер, на першій ноде запускаємо:
/etc/init.d/mysql start --wsrep-new-cluster


На інших ноди:
/etc/init.d/mysql start


Перевіримо наш кластер, на кожній ноде запустимо:
mysql -p
SHOW STATUS LIKE 'wsrep%';

Приклад виводу
+------------------------------+----------------------------------------------------------------+
| Variable_name | Value |
+------------------------------+----------------------------------------------------------------+
| wsrep_local_state_uuid | 5b32cb2c-39df-11e5-b26b-6e85dd52910e |
| wsrep_protocol_version | 7 |
| wsrep_last_committed | 4200745 |
| wsrep_replicated | 978815 |
| wsrep_replicated_bytes | 4842987031 |
| wsrep_repl_keys | 3294690 |
| wsrep_repl_keys_bytes | 48870270 |
| wsrep_repl_data_bytes | 4717590703 |
| wsrep_repl_other_bytes | 0 |
| wsrep_received | 7785 |
| wsrep_received_bytes | 62814 |
| wsrep_local_commits | 978814 |
| wsrep_local_cert_failures | 0 |
| wsrep_local_replays | 0 |
| wsrep_local_send_queue | 0 |
| wsrep_local_send_queue_max | 2 |
| wsrep_local_send_queue_min | 0 |
| wsrep_local_send_queue_avg | 0.002781 |
| wsrep_local_recv_queue | 0 |
| wsrep_local_recv_queue_max | 2 |
| wsrep_local_recv_queue_min | 0 |
| wsrep_local_recv_queue_avg | 0.002954 |
| wsrep_local_cached_downto | 4174040 |
| wsrep_flow_control_paused_ns | 0 |
| wsrep_flow_control_paused | 0.000000 |
| wsrep_flow_control_sent | 0 |
| wsrep_flow_control_recv | 0 |
| wsrep_cert_deps_distance | 40.254320 |
| wsrep_apply_oooe | 0.004932 |
| wsrep_apply_oool | 0.000000 |
| wsrep_apply_window | 1.004932 |
| wsrep_commit_oooe | 0.000000 |
| wsrep_commit_oool | 0.000000 |
| wsrep_commit_window | 1.000000 |
| wsrep_local_state | 4 |
| wsrep_local_state_comment | Synced |
| wsrep_cert_index_size | 43 |
| wsrep_causal_reads | 0 |
| wsrep_cert_interval | 0.023937 |
| wsrep_incoming_addresses| 192.168.100.202:3306,192.168.100.201:3306,192.168.100.203:3306 |
| wsrep_evs_delayed | |
| wsrep_evs_evict_list | |
| wsrep_evs_repl_latency | 0/0/0/0/0 |
| wsrep_evs_state | OPERATIONAL |
| wsrep_gcomm_uuid | 91e4b4f9-62cc-11e5-9422-2b8fd270e336 |
| wsrep_cluster_conf_id | 0 |
| wsrep_cluster_size | 3 |
| wsrep_cluster_state_uuid | 5b32cb2c-39df-11e5-b26b-6e85dd52910e |
| wsrep_cluster_status | Primary |
| wsrep_connected | ON |
| wsrep_local_bf_aborts | 0 |
| wsrep_local_index | 1 |
| wsrep_provider_name | Galera |
| wsrep_provider_vendor | Codership Oy <info@codership.com> |
| wsrep_provider_version | 25.3.9(r3387) |
| wsrep_ready | ON |
| wsrep_thread_count | 2 |
+------------------------------+----------------------------------------------------------------+

От і все. Просто – чи не правда?

Увага: якщо всі ваші ноди будуть выключенны в одне і теж час, MySQL не підніметься сам, ви повинні будете вибрати найбільш актуальну ноду, і запустити демон з опцією --wsrep-new-cluster, що б решта ноди змогли прореплицировать з неї інформацію.



OpenvSwitch

Про OpenvSwitch ls1 написав класну статті, рекомендую до прочитання.

Установка
Так як OpenvSwitch немає в стандартних пакетах в CentOS ми скомпилируем і встановимо його окремо.

Для початку встановимо всі необхідні залежності:
ням -y install wget openssl-devel gcc make python-devel openssl-devel kernel-devel graphviz kernel-debug-devel autoconf automake rpm-build redhat-rpm-config libtool


Для компіляції OpenvSwitch створимо користувача ovs і залогинимся під ним, подальші дії будемо виконувати від його імені.
adduser ovs
su - ovs


Завантажити вихідні коди, за рекомендацією n40lab відключимо openvswitch-kmod, і скомпилируем їх.
mkdir -p ~/rpmbuild/SOURCES
wget http://openvswitch.org/releases/openvswitch-2.3.2.tar.gz
cp openvswitch-2.3.2.tar.gz ~/rpmbuild/SOURCES/
tar xfz openvswitch-2.3.2.tar.gz
sed 's/openvswitch-kmod, //g' openvswitch-2.3.2/rhel/openvswitch.spec > openvswitch-2.3.2/rhel/openvswitch_no_kmod.spec
rpmbuild -bb --дозволяє nochex ~/openvswitch-2.3.2/rhel/openvswitch_no_kmod.spec
exit


Створимо папку для конфіги
mkdir /etc/openvswitch


Встановимо отриманий нами RPM-пакет
ням localinstall /home/ovs/rpmbuild/RPMS/x86_64/openvswitch-2.3.2-1.x86_64.rpm


Запустимо демон:
systemctl start openvswitch.service
chkconfig openvswitch on


Створення мосту

Зараз ми налаштуємо мережевий брідж в який будуть додаватися порти

ovs-vsctl add-br ovs-br0
ovs-vsctl add-port ovs-br0 enp1


Поправимо конфіги наших інтерфейсів для автозапуску:

/etc/sysconfig/network-scripts/ifcfg-enp1
DEVICE="enp1"
NM_CONTROLLED="так"
ONBOOT="так"
IPV6INIT=no
TYPE="OVSPort"
DEVICETYPE="OVSIntPort"
OVS_BRIDGE=ovs-br0


/etc/sysconfig/network-scripts/ifcfg-ovs-br0

Для kvm1:
DEVICE="ovs-br0"
NM_CONTROLLED="ні"
ONBOOT="так"
TYPE="OVSBridge"
BOOTPROTO="static"
IPADDR="192.168.100.201"
NETMASK="255.255.255.0"
HOTPLUG="ні"

kvm2
DEVICE="ovs-br0"
NM_CONTROLLED="ні"
ONBOOT="так"
TYPE="OVSBridge"
BOOTPROTO="static"
IPADDR="192.168.100.202"
NETMASK="255.255.255.0"
HOTPLUG="ні"

kvm3
DEVICE="ovs-br0"
NM_CONTROLLED="ні"
ONBOOT="так"
TYPE="OVSBridge"
BOOTPROTO="static"
IPADDR="192.168.100.203"
NETMASK="255.255.255.0"
HOTPLUG="ні"

Перезапустим мережа, все повинно завестися:
systemctl restart network




OpenNebula

Установка
Ось і настав час встановити OpenNebula

На всіх ноди:

Встановимо репозиторій OpenNebula:
cat << EOT > /etc/yum.repos.d/opennebula.repo
[opennebula]
name=opennebula
baseurl=http://downloads.opennebula.org/repo/4.14/CentOS/7/x86_64/
enabled=1
gpgcheck=0
EOT


Встановимо сервер OpenNebula, web-інтерфейс до нього Sunstone і ноду
yum install -y opennebula-server opennebula-sunstone opennebula-node-kvm 


Запустимо інтерактивний скрипт, який встановить в нашу систему необхідні gems:
/usr/share/one/install_gems


Налаштування нод

На кожній ноде у нас з'явився користувач one, потрібно дозволити йому безпарольно ходити між нодами і виконувати будь-які команди через sudo без пароля, так само як ми і робили з користувачем ceph.

На кожній ноде виконуємо:

passwd oneadmin
sudo echo "ceph ALL = (root) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/one
sudo chmod 0440 /etc/sudoers.d/one


Запустимо сервіси Libvirt і MessageBus:
systemctl start messagebus.service libvirtd.service
systemctl enable messagebus.service libvirtd.service


Заходимо на kvm1

Тепер згенеруємо ключ і скопіюємо його на інші ноди:
sudo ssh-keygen -f /home/ceph/.ssh/id_rsa
sudo cat /var/lib/one/.ssh/id_rsa.pub >> /var/lib/one/.ssh/authorized_keys
sudo chown -R oneadmin: /var/lib/one/.ssh
for i in 2 3; do
scp /var/lib/one/.ssh/* one@kvm$i:/var/lib/one/.ssh/
done


На кожній ноде виконуємо:

Дозволимо Sunstone слухати на будь-який IP, не тільки на локальний:
sed -i 's/host:\ 127\.0\.0\.1/host:\ 0\.0\.0\.0/g' /etc/one/sunstone-server.conf


Налаштування БД

Заходимо на kvm1.

Створимо базу даних для OpenNebula:
mysql -p
create database opennebula;
GRANT USAGE ON opennebula.* to oneadmin@'%' IDENTIFIED BY 'PASS';
GRANT ALL PRIVILEGES on opennebula.* to oneadmin@'%';
FLUSH PRIVILEGES;


Тепер перенесемо базу даних sqlite в mysql:

Завантажити скрипт sqlite3-to-mysql.py:
curl -O http://www.redmine.org/attachments/download/6239/sqlite3-to-mysql.py


Сконвертируем і запишемо нашу базу:
sqlite3 /var/lib/one/one.db .dump | ./sqlite3-to-mysql.py > mysql.sql 
mysql -u oneadmin -pPASS < mysql.sql


Тепер скажемо OpenNebula підключатися до нашої бд, поправимо конфіг /etc/one/oned.conf:

Замінимо
DB = [ backend = "sqlite" ]

на
DB = [ backend = "mysql",
server = "localhost",
port = 0,
user = "oneadmin",
passwd = "PASS",
db_name = "opennebula" ]


Скопіюємо його на інші ноди:
for i in 2 3; do
scp /etc/one/oned.conf one@kvm$i:/etc/one/oned.conf
done


Так само ми повинні скопіювати ключ авторизації oneadmin в кластері на інші ноди, так як все управління кластером OpenNebula здійснюється саме під ним.
for i in 2 3; do
scp /var/lib/one/.one/one_auth one@kvm$i:/var/lib/one/.one/one_auth
done


Перевірка
Тепер на кожній ноде спробуємо запустити серивис OpenNebula і перевірити чи працює він чи ні:

Запускаємо
systemctl start opennebula opennebula-sunstone

  • Перевіряємо:
    http://node:9869
  • Перевіряємо логи на помилки (
    /var/log/one/oned.log /var/log/one/sched.log /var/log/one/sunstone.log
    ).
Якщо все добре, вимикаємо:
systemctl stop opennebula opennebula-sunstone




Налаштування отказоустойчевого кластера

Настав час настроїти HA-кластер OpenNebula
З незрозумілих причин pcs конфліктує з OpenNebula. З цього ми будемо використовувати pacemaker, corosync and crmsh.

На всіх ноди:

Відключимо автозапуск демонів OpenNebula
systemctl disable opennebula opennebula-sunstone opennebula-novnc


Додамо репозиторій:
cat << EOT > /etc/yum.repos.d/network\:ha-clustering\:Stable.repo
[network_ha-clustering_Stable]
name=Stable High Availability/Clustering packages (CentOS_CentOS-7)
type=rpm-md
baseurl=http://download.opensuse.org/repositories/network:/ha-clustering:/Stable/CentOS_CentOS-7/
gpgcheck=1
gpgkey=http://download.opensuse.org/repositories/network:/ha-clustering:/Stable/CentOS_CentOS-7/repodata/repomd.xml.key
enabled=1
EOT


Уствновим необхідні пакети:
yum install corosync pacemaker crmsh resource-agents -y


kvm1:

Відредагуємо /etc/corosync/corosync.conf, наведемо його до такого вигляду:
corosync.conf
totem {
версія: 2
crypto_cipher: none
crypto_hash: none
interface {
ringnumber: 0
bindnetaddr: 192.168.100.0
mcastaddr: 226.94.1.1
mcastport: 4000
ttl: 1
}
}
logging {
fileline: off
to_stderr: no
to_logfile: yes
logfile: /var/log/cluster/corosync.log
to_syslog: yes
debug: off
timestamp: on
logger_subsys {
subsys: QUORUM
debug: off
}
}
quorum {
provider: corosync_votequorum
}
service {
name: pacemaker
ver: 1
}
nodelist {
node {
ring0_addr: kvm1
nodeid: 1
}
node {
ring0_addr: kvm2
nodeid: 2
}
node {
ring0_addr: kvm3
nodeid: 3
}
}


Згенеруємо ключі:
cd /etc/corosync
corosync-keygen


Скопіюємо конфіг і ключі на інші ноди:
for i in 2 3; do
scp /etc/corosync/{corosync.conf,authkey} one@kvm$i:/etc/corosync
ls 
done


І запустимо HA-сервіси:
systemctl start pacemaker corosync
systemctl enable pacemaker corosync


Перевіримо:
crm status

Висновок
Last updated: Mon Nov 16 15:02:03 2015
Last change: Fri Sep 25 16:36:31 2015
Stack: corosync
Current DC: kvm1 (1) - partition with quorum
Версія: 1.1.12-a14efad
3 Nodes configured
0 Resources configured
Online: [ kvm1 kvm2 kvm3 ]

Відключимо STONITH (механізм добивання несправної ноди)
crm configure property stonith-enabled=false

Якщо у вас всього дві ноди вимкніть кворум, під уникнення splitbrain-ситуації
crm configure property no-quorum-policy=stop


Тепер створимо ресурси:
crm
configure
primitive ClusterIP ocf:heartbeat:IPaddr2 params ip="192.168.100.200" cidr_netmask="24" op monitor interval="30s"
primitive opennebula_p systemd:opennebula \
op monitor interval=60s timeout=20s \
op start interval="0" timeout="120s" \
op stop interval="0" timeout="120s" 
primitive opennebula-sunstone_p systemd:opennebula-sunstone \
op monitor interval=60s timeout=20s \
op start interval="0" timeout="120s" \
op stop interval="0" timeout="120s" 
primitive opennebula-novnc_p systemd:opennebula-novnc \
op monitor interval=60s timeout=20s \
op start interval="0" timeout="120s" \
op stop interval="0" timeout="120s" 
group Opennebula_HA ClusterIP opennebula_p opennebula-sunstone_p opennebula-novnc_p
exit


Цими діями ми створили віртуальний IP (192.168.100.200), додали три наших сервісу в HA-кластер і об'єднали їх в групу Opennebula_HA.

Перевіримо:
crm status

Висновок
Last updated: Mon Nov 16 15:02:03 2015
Last change: Fri Sep 25 16:36:31 2015
Stack: corosync
Current DC: kvm1 (1) - partition with quorum
Версія: 1.1.12-a14efad
3 Nodes configured
4 Resources configured


Online: [ kvm1 kvm2 kvm3 ]

Resource Group: Opennebula_HA
ClusterIP (ocf::heartbeat:IPaddr2): Started kvm1 
opennebula_p (systemd:opennebula): Started kvm1 
opennebula-sunstone_p (systemd:opennebula-sunstone): Started kvm1 
opennebula-novnc_p (systemd:opennebula-novnc): Started kvm1




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

Веб інтерфейс завжди буде доступний за адресою
http://192.168.100.200:9869

логін: oneadmin
пароль в /var/lib/one/.one/one_auth

  • Створіть кластер
  • Додайте ноди
  • Додайте вашу віртуальну мережу:
    cat << EOT > ovs.net
    NAME="main"
    BRIDGE="ovs-br0"
    DNS="192.168.100.1"
    GATEWAY="192.168.100.1"
    NETWORK_ADDRESS="192.168.100.0"
    NETWORK_MASK="255.255.255.0"
    VLAN="НІ"
    VLAN_ID=""
    EOT
    
    onevnet create ovs.net
    

  • Додайте ваше Ceph сховище:
    cat << EOT > rbd.conf
    NAME = "cephds"
    DS_MAD = ceph
    TM_MAD = ceph
    DISK_TYPE = RBD
    POOL_NAME = one
    BRIDGE_LIST ="192.168.100.201 192.168.100.202 192.168.100.203"
    CEPH_HOST ="192.168.100.201:6789 192.168.100.202:6789 192.168.100.203:6789"
    CEPH_SECRET ="cfb34c4b-d95c-4abc-a4cc-f8a2ae532cb5" #uuid key, looked at libvirt for authentication ceph
    CEPH_USER = oneadmin
    
    onedatastore create rbd.conf

  • Додайте ноди, мережі, ваші сховища до створеного кластеру через веб-інтерфейс


HA VM
Тепер, якщо хочете налаштувати High Availability(високу доступність) для ваших віртуальних машин, дотримуючись офіційної документации просто додайте в /etc/one/oned.conf
HOST_HOOK = [
name = "error",
on = "ERROR",
command = "ft/host_error.rb",
arguments = "$ID -m -p 5",
remote = "ні" ]

І скопіюйте його на інші ноди:
for i in 2 3; do
scp /etc/one/oned.conf one@kvm$i:/etc/one/oned.conf
done




Джерела


PS: Прошу, якщо ви помітили якісь недоліки чи помилки, пишіть мені в особисті повідомлення

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.