Обеспечение отказоустойчивости – залог непрерывной работы и в целом полного удовлетворения как пользователей, так и администраторов.
В нашем сегодняшнем материале мы поговорим о том, как можно выполнить кластеризацию BitrixVM с помощью простых и доступных инструментов, чтобы все были довольны и ничто не мешало их работе.
Итак, у нас есть два сервера с развернутыми на них системами BitrixVM и Bitrix24. Первое, что нужно сделать, это поддерживать однотипность данных на обоих узлах, синхронизировать как между базами данных, так и между файлами битрикс.
Битрикс1 - 172.16.10.1 Битрикс2 — 172.16.10.2 Обязательно пропишите в файлах хостов на обеих машинах следующие строки:
Для базы данных мы будем использовать репликацию данных типа мастер-мастер.172.16.10.1 bitrix1 172.16.10.2 bitrix2
Для этого нам необходимо исправить настройки в файлах /etc/my.cnf
Битрикс рекомендует создать файл для переопределения собственных настроек /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
Измененные двоичные данные записываются в журналы.
Без указания этой опции может возникнуть ошибка как в логах, так и при входе на сам портал Битрикс: 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
Путь к логам ведомого реле (binlog скачан с ведущего): relay-log = /var/lib/mysql/slave-mysql-relay-bin
relay-log-index = /var/lib/mysql/slave-mysql-relay-bin.index
БД, которые нужно или не нужно реплицировать (мы выполняем репликацию только для стандартной базы битрикс - менеджер сайта0 ): 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
Чтобы избежать конфликтов автоинкремента, мы приказываем серверу генерировать идентификаторы, начиная с третьего, добавляя по 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
Далее необходимо переключиться на вторую БитриксВМ, т.е.
битрикс2, и произвести аналогичные настройки для mysql, также предварительно создав файл z_bx_custom.cnf В /etc/mysql/conf.d/ , при этом меняя идентификатор сервера И 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
Для репликации создайте пользователя репликатора на обеих машинах: 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 вторая машина битрикс2: [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 = сервер-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;"
Запустим раба: [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 (время отставания реплики от мастера) должно быть равно нулю: Ведомое_IO_State должен сообщить: «Ожидание отправки от мастера» Ведомый_IO_Running = Да Slave_SQL_Running = Да
Если значения в строке Ведомое_IO_State отсутствует и Seconds_Behind_Master равно НУЛЕВОЙ , что означает, что репликация не началась.
Давай выясним master_log И master_log_position первая машина битрикс1: [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|
+-----------------------+--------+------------+-------------------------------------------+
На второй машине битрикс2 настраиваем репликацию: [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 , Ведомое_IO_State , Ведомый_IO_Работает , Slave_SQL_Running с параметрами, аналогичными настройкам репликации на машине Битрикс1.
Далее нужно перейти к синхронизации самих данных между Битрикс24. Синхронизировать файлы будем через csync2.
Установка csync должна быть выполнена на обеих машинах: [root@bitrix1 /]# yum install csync2
[root@bitrix2 /]# yum install csync2
Включите на обеих машинах: chkconfig xinetd on
chkconfig csync2 on
Генерируем сертификаты находясь на первой машине битрикс1: [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 с битрикс1 на битрикс2, например, через scp: scp /etc/csync2/csync2* [email protected]:/test
Давайте создадим локальную базу данных всех файлов проекта, с которыми будет работать csync2. [root@bitrix1 csync2]# csync2 -cr /
После этого запускаем: [root@bitrix1 /]# /usr/sbin/csync2 –xv
В случае ошибок вы можете использовать /usr/sbin/csync2 –ТВ
Если команда выполнена без ошибок, то вы можете добавить запись в /etc/crontab на обеих машинах запускать csync каждую минуту: */1 * * * * root /usr/sbin/csync2 -x >/dev/null 2>&1
Остается только проверить: создав, например, сообщение в самом портале, чате битрикс24, удалив его, создав файл и убедившись, что внесенные изменения передаются между узлами.
Одним из вариантов единой точки входа является 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 - Отказоустойчивое облако в Германии Выделенные серверы в надежных дата-центрах Германии! Любая конфигурация, быстрая сборка и бесплатная установка.
Теги: #it-инфраструктура #Системное администрирование #Администрирование серверов #Администрирование баз данных #кластеризация #MySQL #haproxy #VM #виртуальная машина #bitrix #bitrix24 #кластеризация #csync2
-
Рецепт «Кулинарии» Программиста
19 Oct, 24 -
Асинхронная Связь Через Http
19 Oct, 24 -
Poolcoin — Новая Криптовалюта
19 Oct, 24 -
Мобильная Разработка Hh.ru И Где Она Живет
19 Oct, 24 -
О Странице «Доступ К Публикации Ограничен»
19 Oct, 24
