Кластеризація на прикладі BitrixVM: просто та зрозуміло

Забезпечення відмовостійкості – запорука безперервної роботи та взагалі повного задоволення як користувачів, так і адмінів. У цьому матеріалі йтиметься про те, як можна виконати кластеризацію BitrixVM за допомогою простих і доступних засобів, щоб усім було радісно і ніщо не заважало спокійно працювати.

Отже, маємо два сервери з BitrixVM та розгорнутими на них системами Bitrix24. Перше, що слід зробити для збереження однотипності даних на обох вузлах, виконати синхронізацію як між базами даних, так і між файлами bitrix.

Bitrix1 — 172.16.10.1
Bitrix2 — 172.16.10.2

Обов'язково пропишемо у файлах hosts рядки на обох машинах:

172.16.10.1 bitrix1
172.16.10.2 bitrix2

Для бази даних використовуватимемо реплікацію даних типу master-master. Для цього нам необхідно виправити налаштування у файлах /etc/my.cnf

Bitrix рекомендує для перевизначення своїх власних налаштувань створити файл /etc/mysql/conf.d/z_bx_custom.cnf, в якому слід проводити редагування:

[root@bitrix1 /]# cat /etc/my.cnf
#
# Basic mysql configuration. Use bvat for advanced settings.
# Parameters set by bvat are stored in /etc/mysql/conf.d/bvat.cnf
# If you want to change any parameter, you'll have to redefine it in #/etc/mysql/conf.d/z_bx_custom.cnf
#

Створимо файл відповідно до рекомендації:

touch /etc/mysql/conf.d/z_bx_custom.cnf

[root@bitrix1 /]# nano /etc/mysql/conf.d/z_bx_custom.cnf [mysqld]

Унікальний ідентифікатор сервера серед учасників реплікації:

server-id = 1

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

Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is #READ #COMMITTED or READ UNCOMMITTED.
binlog_format=row

Логи помилок:

log=/var/log/mysqld.log
log_error = /var/log/mysqld.log

Шлях до логів транзакцій сервера (binlog, який веде майстер):

log-bin = /var/lib/mysql/server-mysql-bin
log-bin-index = /var/lib/mysql/server-mysql-bin.index

Шлях до relay-логів slave (binlog, завантажений з майстра):

relay-log = /var/lib/mysql/slave-mysql-relay-bin
relay-log-index = /var/lib/mysql/slave-mysql-relay-bin.index

БД, які потрібно або не потрібно реплікувати (виконуємо лише реплікацію для стандартної бази bitrix - sitemanager0):

replicate-do-db = sitemanager0
replicate-ignore-db=test
replicate-ignore-db=information_schema
replicate-ignore-db=mysql
replicate-ignore-db=performance_schema

Не вести журнал binlog для бази даних:

binlog-ignore-db = information_schema
binlog-ignore-db = mysql
binlog-ignore-db = performance_schema

Щоб уникнути конфліктів автоінкремента, повідомляємо серверу, щоб ID генерувалися, починаючи з 3-го, додаючи по 10, тобто. 13, 23, 33, 43 і надалі:

auto_increment_increment = 10
auto_increment_offset = 3

Зберігати логи з майстра у свій binlog, щоб передати слейву:

log-slave-updates

Після цього перезапускаємо mysql:

[root@bitrix1 /]# /etc/init.d/mysqld restart

Далі необхідно перейти на другий BitrixVM, тобто bitrix2, і виконати аналогічні налаштування для mysql, попередньо також створивши файл z_bx_custom.cnf /etc/mysql/conf.d/, при цьому помінявши server-id і auto_increment_offset:

[root@bitrix2 ~]# cat /etc/mysql/conf.d/z_bx_custom.cnf [mysqld]
server-id = 2
binlog_format=row

log=/var/log/mysqld.log
log_error = /var/log/mysqld.log

log-bin = /var/lib/mysql/server-mysql-bin
log-bin-index = /var/lib/mysql/server-mysql-bin.index

relay-log = /var/lib/mysql/slave-mysql-relay-bin
relay-log-index = /var/lib/mysql/slave-mysql-relay-bin.index

replicate-do-db = sitemanager0
replicate-ignore-db=test
replicate-ignore-db=information_schema
replicate-ignore-db=mysql
replicate-ignore-db=performance_schema

binlog-ignore-db = information_schema
binlog-ignore-db = mysql
binlog-ignore-db = performance_schema
auto_increment_increment = 10
auto_increment_offset = 4

log-slave-updates

Виконаємо рестарт mysql на другій машині:

[root@bitrix2 ~]# /etc/init.d/mysqld restart

Для реплікації створимо користувача replicator на обох машинах:

root@bitrix1 /]# mysql -u root -p
Enter password:
mysql> create user 'replicator'@'%' identified by 'aGiV4uac';
mysql> grant replication slave on *.* to 'replicator'@'%';

root@bitrix2 /]# mysql -u root -p
Enter password:
mysql> create user 'replicator'@'%' identified by 'aGiV4uac';
mysql> grant replication slave on *.* to 'replicator'@'%';

Знову переходимо на першу машину та запустимо реплікацію. Для цього знадобиться ім'я master_log та master_log_position другої машини bitrix2:

[root@bitrix2 /]# mysql -u root -p -e 'show master status;'

+-----------------------+--------+------------+-------------------------------------------+
| File |Position|Binlog_Do_DB| Binlog_Ignore_DB |
+-----------------------+--------+------------+-------------------------------------------+
|server-mysql-bin.000029| 819 | |information_schema,mysql,performance_schema|
+-----------------------+--------+------------+------------------------------------------+

З отриманого списку випливає, що MASTER_LOG_FILE = server-mysql-bin.000029, а MASTER_LOG_POS = 819

Використовуємо ці дані для налаштування реплікації на першій машині:

[root@bitrix1 /]# root -p -e "CHANGE MASTER TO MASTER_HOST = '172.16.10.2', MASTER_USER = 'replicator', MASTER_PASSWORD = 'aGiV4uac', MASTER_LOG_FILE = 'server-mysql-bin.000029', MASTER_LOG_POS = 819;"

Запускаємо slave:

[root@bitrix1 /]# mysql -u root -p -e 'start slave;'

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

[root@bitrix1 /]# mysql -u root -p -e 'show slave status \G;'
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 172.16.10.2
Master_User: replicator
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: server-mysql-bin.000029
Read_Master_Log_Pos: 819
Relay_Log_File: slave-mysql-relay-bin.000002
Relay_Log_Pos: 72951
Relay_Master_Log_File: server-mysql-bin.000029
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: sitemanager0
Replicate_Ignore_DB: test,information_schema,mysql,performance_schema
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 819
Relay_Log_Space: 73113
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 2

Параметр Seconds_Behind_Master (час відставання репліки від майстра) має дорівнювати нулю: Slave_IO_State має повідомляти: «Waiting for master to send even» Slave_IO_Running = Yes Slave_SQL_Running = Yes

Якщо значення у рядку Slave_IO_State відсутнє, а Seconds_Behind_Master дорівнює NULL,то реплікація не почалася.

Дізнаємося master_log і master_log_position першої машини bitrix1:

[root@bitrix1 /]# mysql -u root -p -e 'show master status;'

+-----------------------+--------+------------+-------------------------------------------+
| File |Position|Binlog_Do_DB| Binlog_Ignore_DB |
+-----------------------+--------+------------+-------------------------------------------+
|server-mysql-bin.000026| 2930 | |information_schema,mysql,performance_schema|
+-----------------------+--------+------------+-------------------------------------------+

На другій машині bitrix2 налаштовуємо реплікацію:

[root@bitrix2 ~]# mysql -u root -p -e "CHANGE MASTER TO MASTER_HOST = '172.16.10.1', MASTER_USER = 'replicator', MASTER_PASSWORD = 'aGiV4uac', MASTER_LOG_FILE = 'server-mysql-bin.000026', MASTER_LOG_POS = 2930;"

[root@bitrix2 ~]# mysql -u root -p -e 'stop slave;'
[root@bitrix2 ~]# mysql -u root -p -e 'show slave status \G;'

Потрібно відобразити параметри: Seconds_Behind_Master, Slave_IO_State, Slave_IO_Running, Slave_SQL_Running з параметрами, аналогічними, як і у випадку з налаштуванням реплікації на машині bitrix1.

Далі необхідно перейти до синхронізації самих даних між Bitrix24. Синхронізацію файлів виконуватимемо через csync2.

Установка csync має бути виконана на обох машинах:

[root@bitrix1 /]# yum install csync2
[root@bitrix2 /]# yum install csync2

Включаємо на обох машинах:

chkconfig xinetd on
chkconfig csync2 on

Генеруємо сертифікати, перебуваючи на першій машині bitrix1:

[root@bitrix1 /]# openssl genrsa -out /etc/csync2/csync2_ssl_key.pem 1024
[root@bitrix1 /]# openssl req -new -key /etc/csync2/csync2_ssl_key.pem -out /etc/csync2/csync2_ssl_cert.csr
[root@bitrix1 /]# openssl x509 -req -days 600 -in /etc/csync2/csync2_ssl_cert.csr -signkey /etc/csync2/csync2_ssl_key.pem -out /etc/csync2/csync2_ssl_cert.pem

Генеруємо ключ csync2:

csync2 -k /etc/csync2/csync2.cluster.key

Після досить тривалого процесу генерування ключ csync2.cluster.key з'явиться в папці /etc/csync2/

Налаштування конфігу для csync виглядає так:

[root@bitrix1 /]# cat /etc/csync2/csync2.cfg
group cluster
{
host bitrix1 bitrix2;

key /etc/csync2/csync2.cluster.key;

include /home/bitrix/www;

Виключаємо файли налаштувань з'єднання з БД, оскільки використовуємо різні паролі на обох машинах. Також виключаємо директорії з кешем:

exclude /home/bitrix/www/bitrix/php_interface/dbconn.php;
exclude /home/bitrix/www/bitrix/.settings.php;
exclude /home/bitrix/www/bitrix/cache;
exclude /home/bitrix/www/bitrix/managed_cache;

Задаємо параметр відбору файлів: залишається той, що найновіший:

auto younger;
}

Копіюємо згенеровані ключі разом із конфігураційним файлом csync2.cfg з bitrix1 на bitrix2, наприклад, по scp:

scp /etc/csync2/csync2* root@172.16.10.2:/test

Побудуємо локальну базу всіх файлів проекту, з якою працюватиме csync2.

[root@bitrix1 csync2]# csync2 -cr /

Після – запускаємо:

[root@bitrix1 /]# /usr/sbin/csync2 –xv

У разі помилок можна використати /usr/sbin/csync2 –Tv

Якщо команда завершилася без помилок, можна додавати запис в /etc/crontab на обох машинах для запуску csync кожну хвилину:

*/1 * * * * root /usr/sbin/csync2 -x >/dev/null 2>&1

Залишається зробити перевірку: створивши, наприклад, повідомлення в самому порталі, чаті bitrix24, видалити, створити файл і переконатися, що зміни, що вносяться, переносяться між вузлами.

Як один з варіантів єдиної точки входу можна використовувати HAProxy, розташований на додатковому сервері. Огляд установки та налаштування HAProxy розглядати у цій статті не будемо, т.к. посібників з цього питання достатньо, але для прикладу наведемо конфіг файлу /etc/haproxy/haproxy.cfg:

[root@haproxy haproxy]# cat haproxy.cfg global
log 127.0.0.1 local2 notice

chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 4000
user haproxy
group haproxy
daemon
nbproc 1 # Number of processing cores.
ulimit-n 65536
# turn on stats unix socket
stats socket /var/lib/haproxy/stats

defaults
mode http
log global
option httplog
option dontlognull
option http-server-close
option forwardfor except 127.0.0.0/8
option redispatch
retries 3
timeout http-request 5000
timeout queue 5000
timeout connect 5000
timeout client 5000
timeout server 5000
timeout http-keep-alive 30
timeout check 20 #
maxconn 3000

frontend bitrix.local
mode http
bind :80
default_backend bitrix

backend bitrix
mode http
balance roundrobin
option httpchk
option httpclose
server bitrix1 172.16.10.1:80 check
server bitrix2 172.16.10.2:80 check

Кластеризуйте свої сервери на здоров'я і нехай буде з вами Сила!

Сподобалася стаття?