Кластеризация на примере 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;'
Выделенные Серверы

Выделенные серверы

Смотрите мощные готовые конфигурации серверов SIM-Networks

Смотреть пакеты

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

[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

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

Тэги:

#server

Понравилась статья?

Согласие на использование файлов cookie

Нажимая «Я согласен», вы даете согласие на использование файлов cookie на нашем веб-сайте, чтобы предоставить вам наиболее релевантный опыт, запоминая ваши предпочтения и повторные посещения. Однако вы можете посетить «Управление файлами cookie», чтобы предоставить контролируемое согласие. Подробнее

Настройки файлов cookie

Функциональные

Необходимые файлы cookie имеют решающее значение для основных функций веб-сайта, и без них веб-сайт не будет работать должным образом.

Аналитические

Аналитические файлы cookie используются для понимания того, как посетители взаимодействуют с веб-сайтом.

Рекламные

Рекламные файлы cookie используются для предоставления посетителям релевантной рекламы и маркетинговых кампаний.