Выполняем кластеризацию на примере 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

Кластеризируйте свои сервера на здоровье и да пребудет с вами Сила!

---

SIM-CLOUD — Отказоустойчивое облако в Германии

Выделенные серверы в надежных дата-центрах Германии!
Любая конфигурация, быстрая сборка и бесплатная установка