Eltex Knowledge Base
Дерево страниц
Перейти к концу метаданных
Переход к началу метаданных

В статье будет рассмотрена настройка резервирования 2 серверов EMS при помощи протокола vrrp и репликации баз данных.

Предварительная подготовка:

Для начала потребуется 2 сервера с Ubuntu 20 или более новой и установленными на них EMS  одинаковой версии, в примере будет использоваться версия 3.35.

Шаг 1: Установка и настройка keepalived

Описание пакет

Пакет keepalived - это open source программное обеспечение, предназначенное для обеспечения функций высокой надежности (high availabilitty) и балансировки нагрузки (load-balancing). За первую функцию отвечает реализация протокола VRRP, а вторая основывается на модуле ядра Linux Vitrual Server (IPVS). Keepalived не разрабатывается сотрудниками Eltex и не включает доработок, за исключением конфигурации. Keepalived используется для организации резервирования контроллеров SoftWLC, при этом используется только функционал VRRP.

Установка keepalived

Для установки пакета, необходимо загрузить его на сервер и выполнить следующую команду (установка должна производиться от имени суперпользователя root на обоих серверах):

sudo apt update
sudo apt install keepalived

После установки необходимо добавить демона Keepalived в автозагрузку и запустить его:

sudo systemctl enable keepalived
sudo systemctl start keepalived

Основной файл конфигурации

На обоих серверах в файле /etc/keepalived/keepalived.conf меняем следующие параметры: 

<interface> - наименование сетевого интерфейса (свой для каждого сервера);

<virtual_ip> - виртуальный ip-адрес (с указанием префикса);

<ip_адрес другого сервера> - ip-адрес другого сервера;

Шаг 2: Создание и настройка конфигурационного файла:

Создать файл конфигурации для keepalived в папке /etc/keepalived/keepalived.conf

! Configuration File for keepalived
  
global_defs {
  
   script_user root
   enable_script_security
}
 
vrrp_script check_network {
    script "/etc/keepalived/check_mysql.sh"
    interval 5
    weight 50
    fall 3
    rise 3
    init_fail
    user root
}
 
vrrp_instance VI_SWLC {
#    state  MASTER
    interface <interface>
    virtual_router_id 1
    track_script {
        check_network
    }
    track_interface {
        <interface> weight 50
    }
    priority 150
    advert_int 1
    nopreempt
    # Uncomment and comment "nopreempt" if preemption needed
    #preempt_delay 180
    authentication {
        auth_type PASS
        auth_pass eltex
    }
    virtual_ipaddress {
        <virtual ip> dev <interface> label <interface>:1
    }
  
    notify_master "/etc/keepalived/keep_notify.sh master"
    notify_backup "/etc/keepalived/keep_notify.sh backup"
    notify_fault "/etc/keepalived/keep_notify.sh fault"
  
    unicast_peer {
        <ip address 2 server>
    }
}

Шаг 3 Настройка скриптов проверки состояния 2 сервера и изменения мастера при помощи скриптов:

Скрипт проверяет активность mysql server соседней машины и возвращает код результата. Таким образом, при успешном выполнении скрипта, гарантируется, что SoftWLC достижим для внешних клиентов. 

В текущей реализации на обоих серверах, в качестве тестового скрипта, предлагается использовать следующий:
/etc/keepalived/check_mysql.sh 

где <default_ip> - шлюз по умолчанию для этого сервера аналогично записи.

#!/bin/bash
 
# host to ping
# there - default gw
HOST=<default_ip>
# -q quiet
# -c nb of pings to perform
mysqladmin -ujavauser -pjavapassword ping -h $HOST > /dev/null
 
# $? var keeping result of execution
# previous command
if [ $? -eq 0 ]
    then
        echo `date +"%T %F"` "OK mysql reachable"
        EXIT_CODE=0
    else
        echo `date +"%T %F"` "ERROR mysql unreacheble!"
        EXIT_CODE=1
fi
 
exit $EXIT_CODE

Конфигурация смены роли

При смене состояния сервера, выполняется скрипт keep_notify.sh.
/etc/keepalived/keep_notify.sh

#!/bin/bash

if ! lockfile-create --use-pid -r 5 /tmp/keep.mode.lock; then
    echo "Unable to lock"
    echo "Unable to lock" > /tmp/keep.mode.lock.fail
    exit 0
fi
 
case "$1" in
    master)
    echo "MASTER" > /tmp/keep.mode
 
    service eltex-ems restart
  ;;
 backup)
    echo "BACKUP" > /tmp/keep.mode
 
    service eltex-ems stop
 ;;
 fault)
    echo "FAULT" > /tmp/keep.mode
 ;;
 *)
    echo "Usage: $0 {master|backup|fault}"
    exit 1
esac
 
lockfile-remove /tmp/keep.mode.lock;
 
exit 0

Необходимо добавить права 

sudo chmod +x /etc/keepalived/check_mysql.sh
sudo chmod +x /etc/keepalived/keep_notify.sh

Шаг 4:Выделение лога в отдельный файл

По умолчанию keepalived записывает лог в файл /var/log/syslog . Для удобства отладки, мониторинга и контроля работы keepalived, можно настроить ведение собственного, отдельного лог-файла.

Ниже приведен пример настройки rsyslog:

sudo nano -w /etc/rsyslog.d/10-keepalived.conf

Добавьте в файл 10-keepalived.conf следующее:
/etc/rsyslog.d/10-keepalived.conf

if $programname contains 'Keepalived' then /var/log/keepalived.log
if $programname contains 'Keepalived' then ~

Затем, нужно перезапустить rsyslog командой:

sudo service rsyslog restart

Теперь сообщения от демона keepalived попадут только в лог-файл /var/log/keepalived.log и не попадут в /var/log/syslog .

4.1 Способ запуска/остановки keepalived

Для запуска сервиса воспользуйтесь командой:

sudo service keepalived start

Остановка сервиса:

sudo service keepalived stop

Проверить состояние сервиса можно командой:

sudo service keepalived status

Шаг 5: Настройка репликации MariaDB

Резервирование данных, хранящихся СУБД MySQL, осуществляется путём встречной репликации по принципу master-master (ведущий-ведущий). То есть, каждый из серверов одновременно является и master и slave. При такой схеме работы, все изменения в БД на одном сервере записываются в специальный бинарный лог, который в реальном времени вычитывает второй сервер и применяет изменения. Второй сервер реплицирует данные с первого, а первый со второго. Это позволяет получить актуальную копию БД на двух хостах одновременно. При разрыве связи, изменения накапливаются, после восстановления происходит синхронизация.

5.1 Перенос дампа данных и перенос на второй сервер

При настройке резервирования в процессе эксплуатации (то есть если в MySQL на действующем сервере уже имеются данные), необходимо перенести эти данные на второй сервер. Это можно сделать при помощи утилиты mysqldump.

Для этого, необходимо на первом сервере заблокировать таблицы, снять дамп, разблокировать таблицы и скопировать получившийся файл на второй сервер:

1) sudo mysql -uroot -proot -e "FLUSH TABLES WITH READ LOCK;"
2) sudo mysqldump -uroot -proot --databases eltex_alert eltex_bruce eltex_ems eltex_jobs eltex_ont wireless eltex_pcrf eltex_wifi_customer_cab eltex_sorm2 eltex_ott eltex_jerry > mysqldump_master.sql
3) sudo mysql -uroot -proot -e "UNLOCK TABLES;"
4) sudo scp mysqldump_master.sql <username>@<ip_server2>:/home/<username>/

Затем, развернуть dump на втором сервере:

sudo mysql -uroot -proot < /home/<username>/mysqldump_master.sql

5.2 Настройка конфигурациионного файла MariaDB

Конфигурация самого демона mysqld заключается в настройке параметров ведения бинарных логов. Обозначения первый сервер и второй сервер далее условны, и применяются лишь для обозначения различий в конфигурации серверов.

В секции [mysqld] файла конфигурации /etc/mysql/mariadb.conf.d/50-server.cnf произвести следующие изменения:

Закомментировать либо удалить строку на обоих серверах:

bind-address = 127.0.0.1

Указать server-id. Для серверов необходимо задать уникальные идентификаторы, к примеру, для первого:

server-id = 1

для второго:

server-id = 2

Включить бинарные логи на обоих серверах:

log_bin = /var/log/mysql/mysql-bin.log

Включаем GTID  и обеспечиваем согласованность на обоих серверах 

gtid_strict_mode=1
ssl=0

Перезапустить сервис mysql на каждом сервер и создать БД для репликации:

sudo service mysql restart

5.3 Создание учетных записей

Для работы репликации необходима служебная учетная запись на каждом из серверов. Под этой учетной записью, сервер будет подключаться к master-серверу и получать изменения в данных.

Создать в консоли MySQL учетную запись для репликации на первом сервере:
Выполнять из mysql-client (mysql -uroot -proot)

GRANT SELECT, SUPER, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'replication'@'<ip_server2>' IDENTIFIED BY 'password';
GRANT SELECT, SUPER, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'replication'@'<ip_server1>' IDENTIFIED BY 'password'; #необходимо для проверки состояния репликации из EMS
FLUSH PRIVILEGES;

Создать в консоли MySQL учетную запись для репликации на втором сервере:
Выполнять из mysql-client (mysql -uroot -proot)

GRANT SELECT, SUPER, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'replication'@'<ip_server1>' IDENTIFIED BY 'password';
GRANT SELECT, SUPER, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'replication'@'<ip_server2>' IDENTIFIED BY 'password'; #необходимо для проверки состояния репликации из EMS
FLUSH PRIVILEGES;


Привилегия SELECT необходима для работы проверки репликации из GUI EMS

5.4 Выдача прав сервисным пользователям

Открыть /usr/lib/eltex-ems/conf/config.txt, посмотреть какие username / password используются (по умолчанию - javauser / javapassword)

Выдаем им права на внешний доступ на обоих серверах:
Выполнять из mysql-client (mysql -uroot -proot)

GRANT ALL PRIVILEGES ON *.* TO 'javauser'@'%' IDENTIFIED BY 'javapassword';
GRANT ALL PRIVILEGES ON `wireless`.* TO 'javauser'@'%';          
GRANT ALL PRIVILEGES ON `Syslog`.* TO 'javauser'@'%';            
GRANT ALL PRIVILEGES ON `eltex_ems`.* TO 'javauser'@'%';         
GRANT ALL PRIVILEGES ON `eltex_alert`.* TO 'javauser'@'%';       
GRANT ALL PRIVILEGES ON `eltex_bruce`.* TO 'javauser'@'%';
GRANT ALL PRIVILEGES ON `eltex_pcrf`.* TO 'javauser'@'%';
GRANT ALL PRIVILEGES ON `eltex_wids`.* TO 'javauser'@'%';
GRANT ALL PRIVILEGES ON `eltex_wifi_customer_cab`.* TO 'javauser'@'%';
GRANT ALL PRIVILEGES ON `eltex_jobs`.* TO 'javauser'@'%';
GRANT ALL PRIVILEGES ON `eltex_sorm2`.* TO 'javauser'@'%';
GRANT ALL PRIVILEGES ON `eltex_ott`.* TO 'javauser'@'%';
GRANT ALL PRIVILEGES ON `eltex_jerry`.* TO 'javauser'@'%';
GRANT ALL PRIVILEGES ON `eltex_ont`.* TO 'javauser'@'%';
FLUSH PRIVILEGES;

5.5 Включение репликации

Настроить и запустить репликацию второго сервера с первого (выполнить действия на втором сервере):

STOP SLAVE;
CHANGE MASTER TO MASTER_HOST='<ip_server1>', MASTER_USER='replication', MASTER_PASSWORD='password', MASTER_USE_GTID=slave_pos;
START SLAVE;

Проверить состояние репликации:

MariaDB [(none)]> show slave status \G;
*************************** 1. row ***************************
                Slave_IO_State:
                   Master_Host: <ip_server2>
                   Master_User: replication
                   Master_Port: 3306
                 Connect_Retry: 60
               Master_Log_File: mysql-bin.000013
           Read_Master_Log_Pos: 3332141
                Relay_Log_File: localhost-relay-bin.000062
                 Relay_Log_Pos: 320
         Relay_Master_Log_File: mysql-bin.000013
              Slave_IO_Running: No
             Slave_SQL_Running: No
               Replicate_Do_DB:
           Replicate_Ignore_DB:
            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: 3332141
               Relay_Log_Space: 0
               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: NULL
 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: 0
                Master_SSL_Crl:
            Master_SSL_Crlpath:
                    Using_Gtid: No
                   Gtid_IO_Pos:
       Replicate_Do_Domain_Ids:
   Replicate_Ignore_Domain_Ids:
                 Parallel_Mode: optimistic
                     SQL_Delay: 0
           SQL_Remaining_Delay: NULL
       Slave_SQL_Running_State:
              Slave_DDL_Groups: 0
Slave_Non_Transactional_Groups: 0
    Slave_Transactional_Groups: 0
1 row in set (0.000 sec)

Выведем состояние параметров gtid:

MariaDB [(none)]> show global variables like '%gtid%';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| gtid_binlog_pos         | 0-2-4217  |
| gtid_binlog_state       | 0-2-4217  |
| gtid_cleanup_batch_size | 64        |
| gtid_current_pos        | 0-1-13665 |
| gtid_domain_id          | 0         |
| gtid_ignore_duplicates  | OFF       |
| gtid_pos_auto_engines   |           |
| gtid_slave_pos          | 0-1-13665 |
| gtid_strict_mode        | ON        |
| wsrep_gtid_domain_id    | 0         |
| wsrep_gtid_mode         | OFF       |
+-------------------------+-----------+
11 rows in set (0.001 sec)

Структура значения GTID выглядит следующим образом:

X-Y-Z:

X - номер домена кластера;

Y - server_id ноды кластера;

Z - gjpbwbz 

На 1-ом сервере 

STOP SLAVE;
CHANGE MASTER TO MASTER_HOST='<ip_server2>', MASTER_USER='replication', MASTER_PASSWORD='password',MASTER_USE_GTID=slave_pos;
START SLAVE;

Проверить состояние репликации:

MariaDB [(none)]> show slave status\G
*************************** 1. row ***************************
                Slave_IO_State: Waiting for master to send event
                   Master_Host: <ip_server1>
                   Master_User: replication
                   Master_Port: 5890
                 Connect_Retry: 60
               Master_Log_File: mysql-bin.000003
           Read_Master_Log_Pos: 2682485
                Relay_Log_File: mysqld-relay-bin.000002
                 Relay_Log_Pos: 2674921
         Relay_Master_Log_File: mysql-bin.000003
              Slave_IO_Running: Yes
             Slave_SQL_Running: Yes
               Replicate_Do_DB:
           Replicate_Ignore_DB:
            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: 2682485
               Relay_Log_Space: 2675231
               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: 1
                Master_SSL_Crl:
            Master_SSL_Crlpath:
                    Using_Gtid: Slave_Pos
                   Gtid_IO_Pos: 0-1-13677
       Replicate_Do_Domain_Ids:
   Replicate_Ignore_Domain_Ids:
                 Parallel_Mode: optimistic
                     SQL_Delay: 0
           SQL_Remaining_Delay: NULL
       Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
              Slave_DDL_Groups: 740
Slave_Non_Transactional_Groups: 0
    Slave_Transactional_Groups: 12844
1 row in set (0.001 sec)

После сохранения изменений, состояние репликации можно отслеживать в GUI EMS в разделе Информация → Состояние системы резервирования → MySQL.

Шаг 6: Проверка корректной настройки MariaDB 

Проверить что реплиакация работает можно как через GUI ems перейдя на вкладку Информация >> состояние системы резервирования >> MySQL.

Еще можно проверить непосредственно перейдя в саму БД.  На обоих серверах должен быть статус слейва 
Выполнять из mysql-client (mysql -uroot -proot)

show slave status \G
*************************** 1. row ***************************
......
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
......

Slave_IO_Running — состояние работы получения бинарного лога с сервера Master. Если состояние будет NO, то репликация не работает.
Slave_SQL_Running — статус выполнения команд из лога на сервере Slave. Если состояние будет NO, то репликация не работает.

  • Нет меток