= __Вариант настройки отказоустойчивого сервера FreeSwitch__ = == Исходные данные == Имеется ubuntu-16.04 c настроенным и работающим сервером !FreeSwitch, установленным из нашего репозитория, и используемым для организации диспетчерской связи. Требуется сделать резервирование из двух идентичных серверов !FreeSwitch. == Переносим базы данных !FreeSwitch в MySQL == === Устанавливаем драйвер MyODBC и настраиваем доступ к базе данных === ===== Устанавливаем необходимые пакеты ===== {{{ $ sudo apt-get install libodbc1 odbcinst unixodbc }}} ===== Установим драйвер myodbc ===== * Скачиваем архив mysql-connector-odbc-5.3.7-linux-ubuntu16.04-x86-64bit.tar.gz [https://dev.mysql.com/downloads/connector/odbc/ отсюда]; * Распаковываем архив: {{{ $ tar zxvf mysql-connector-odbc-5.3.7-linux-ubuntu16.04-x86-64bit.tar.gz }}} * Переходим в распакованный каталог: {{{ $ cd mysql-connector-odbc-5.3.7-linux-ubuntu16.04-x86-64bit }}} * Скопируем драйвер в каталог odbc: {{{ $ sudo cp lib/* /usr/lib/x86_64-linux-gnu/odbc/ }}} * Конфигурируем установленный драйвер с помощью инсталлятора: {{{ $ sudo bin/myodbc-installer -d -a -n MySQL -t "DRIVER=/usr/lib/x86_64-linux-gnu/odbc/libmyodbc5w.so;" }}} * Конфигурирвем источник: {{{ $ sudo bin/myodbc-installer -s -a -n freeswitch -t "DRIVER=MySQL;SERVER=127.0.0.1;DATABASE=dispatcher;OPTION=67108864" }}} где "dispatcher" - имя нашей базы данных на сервере MySQL. В результате в каталоге /etc должны быть созданы файлы odbc.ini и odbcinst.ini с приблизительно таким содержанием: odbc.ini: {{{ [freeswitch] Driver=MySQL SERVER=127.0.0.1 DATABASE=dispatcher PORT=3306 MULTI_STATEMENTS=1 }}} odbcinst.ini: {{{ [MySQL] Driver=/usr/lib/x86_64-linux-gnu/odbc/libmyodbc5w.so UsageCount=1 FileUsage=1 }}} ===== Проверим работу с базой данных MySQL серез ODBC ===== {{{ $ isql freeswitch +---------------------------------------+ | Connected! | | | | sql-statement | | help [tablename] | | quit | | | +---------------------------------------+ SQL> show tables; +-----------------------------------------------------------------+ | Tables_in_dispatcher | +-----------------------------------------------------------------+ | cdr | | options | | recordings | +-----------------------------------------------------------------+ SQLRowCount returns 10 10 rows fetched SQL> quit }}} где и - имя и пароль, установленные для доступа !FreeSwitch к базе данных при конфигурации !FreeSwitch. Теперь необходимо установить базе данных charset по умолчанию utf8, чтобы новые таблицы, которые создаст !FreeSwitch, использовали именно его: {{{ mysql> alter database character set utf8; Query OK, 1 row affected (0,00 sec) }}} где - имя базы данных. ==== Конфигурируем !FreeSwitch для хранения его данных в MySQL ==== ===== Конфигурируем SIP профили !FreeSwitch для хранения данных в MySQL ===== В файлах конфигурации SIP профилей в разделе добавляем такой параметр: {{{ }}} где и - имя и пароль, установленные для доступа !FreeSwitch к базе данных при конфигурации !FreeSwitch. Например: {{{ }}} Здесь же включаем track-calls: {{{ }}} Теперь в консоли !FreeSwitch перезапускаем профили командой: {{{ > sofia profile restart }}} где - имя SIP профиля, например: {{{ > sofia profile internal restart }}} Контролируем, что профили перезупустились с помощью команды в консоли FreeSwitch: {{{ > sofia status }}} В нашей базе данных должны создаться новые таблицы. Проверим это: {{{ $ mysql -u -p -e 'show tables' Enter password: +-------------------------------------+ | Tables_in_dispatcher | +-------------------------------------+ | cdr | | options | | recordings | | sip_authentication | | sip_dialogs | | sip_presence | | sip_registrations | | sip_shared_appearance_dialogs | | sip_shared_appearance_subscriptions | | sip_subscriptions | +-------------------------------------+ }}} ===== Конфигурируем хранение core-db в MySQL ===== Одна из таблиц (а именно, channels) при попытке ее создания с использованием кодировки utf8 превосходила лимит на максимальный размер строки в таблице mysql. Поэтому создаем эту таблицу вручную, немного изменив тип некоторых особо "жирных" столбцов: {{{ CREATE TABLE channels ( uuid VARCHAR(256), direction VARCHAR(32), created VARCHAR(128), created_epoch INTEGER, name VARCHAR(1024), state VARCHAR(64), cid_name VARCHAR(1024), cid_num VARCHAR(256), ip_addr VARCHAR(256), dest VARCHAR(1024), application VARCHAR(128), application_data TEXT(4096), dialplan VARCHAR(128), context VARCHAR(128), read_codec VARCHAR(128), read_rate VARCHAR(32), read_bit_rate VARCHAR(32), write_codec VARCHAR(128), write_rate VARCHAR(32), write_bit_rate VARCHAR(32), secure VARCHAR(64), hostname VARCHAR(256), presence_id TEXT(4096), presence_data TEXT(4096), accountcode VARCHAR(256), callstate VARCHAR(64), callee_name VARCHAR(1024), callee_num VARCHAR(256), callee_direction VARCHAR(5), call_uuid VARCHAR(256), sent_callee_name VARCHAR(1024), sent_callee_num VARCHAR(256), initial_cid_name VARCHAR(1024), initial_cid_num VARCHAR(256), initial_ip_addr VARCHAR(256), initial_dest VARCHAR(1024), initial_dialplan VARCHAR(128), initial_context VARCHAR(128) ); }}} В конфиг-файле switch.conf.xml добавляем параметр: {{{ }}} где и - имя и пароль, установленные для доступа !FreeSwitch к базе данных при конфигурации !FreeSwitch. Здесь же устанавливаем имя коммутатора: {{{ }}} Теперь выполняем рестарт !FreeSwitch: {{{ $ sudo service freeswitch restart }}} Убедимся, что в базе данных появились новые таблицы: {{{ $ mysql -u root -p dispatcher -e 'show tables' Enter password: +-------------------------------------+ | Tables_in_dispatcher | +-------------------------------------+ | aliases | | basic_calls | | calls | | cdr | | channels | | complete | | detailed_calls | | interfaces | | nat | | options | | recordings | | recovery | | registrations | | sip_authentication | | sip_dialogs | | sip_presence | | sip_registrations | | sip_shared_appearance_dialogs | | sip_shared_appearance_subscriptions | | sip_subscriptions | | tasks | +-------------------------------------+ }}} == Конфигурируем второй сервер == Устанавливаем и конфигурируем второй сервер полностью аналогично первому. Проверим, что установлены все необходимые модули. Конфигурацию нового сервера (/etc/freeswitch) можно целиком скопировать с первого. == Настраиваем репликацию между двумя серверами mysql == Останавливаем !FreeSwitch на обоих серверах: {{{ $ sudo service freeswitch stop }}} В конфиг-файлы mysqld добавляем следующее: {{{ server-id = 1 log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 10 max_binlog_size = 100M binlog_do_db = dispatcher }}} где {{{server-id}}} - идентификатор сервера, он должен быть разный у разных серверов. Перезапускаем mysqld на обоих серверах: {{{ $ sudo service mysql restart }}} Подключаемся к mysql серверу и создаем пользователя для репликации: {{{ mysql> CREATE USER 'replicator'@'%' IDENTIFIED BY 'password'; }}} заменив "password" каким-нибудь паролем. Даем пользователю право на репликацию: {{{ mysql> GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'%'; }}} На сервере 1 блокируем базу данных на запись: {{{ mysql> FLUSH TABLES WITH READ LOCK; }}} Выводим состояние мастера: {{{ mysql> SHOW MASTER STATUS; }}} Будет выведена примерно такая таблица: {{{ +------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+-------------------+ | mysql-bin.000002 | 62249651 | dispatcher | | | +------------------+----------+--------------+------------------+-------------------+ 1 row in set (0.00 sec) }}} Не выходя из консоли mysql (при выходе снимется блокировка), из другого терминала дампим базу данных: {{{ $ mysqldump -u root -p dispatcher >dispatcher.dump }}} Когда дамп будет готов, снова выведем {{{SHOW MASTER STATUS;}}} и убедимся, что значение {{{Position}}} не изменилось. Теперь можно снять блокировку: {{{ mysql> UNLOCK TABLES; }}} или просто выйти из консоли mysql. Копируем сделанный дамп базы на второй сервер. Записываем дамп в базу данных: {{{ $ mysql -u root -p dispatcher STOP SLAVE; mysql> CHANGE MASTER TO MASTER_HOST = '' , MASTER_USER = 'replicator', MASTER_PASSWORD = 'password', MASTER_LOG_FILE = 'mysql-bin.000002', MASTER_LOG_POS = 62249651; mysql> START SLAVE; }}} заменив "password" на тот пароль, который установили пользователю replicator ранее. Проверим, что репликация активирована: {{{ mysql> SHOW SLAVE STATUS\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.0.64 Master_User: replicator Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000003 Read_Master_Log_Pos: 118750 Relay_Log_File: r3-relay-bin.000002 Relay_Log_Pos: 82017 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: 118750 Relay_Log_Space: 82221 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_UUID: 7603167a-1081-11e6-9637-902b3433882b Master_Info_File: /var/lib/mysql/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: Executed_Gtid_Set: Auto_Position: 0 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version: 1 row in set (0.00 sec) }}} Аналогично, только без выполнения/восстановления дампа настраиваем репликацию сервера 2 на сервер 1. == Настраиваем общий адрес == Общий адрес - это IP адрес, используя который один из двух серверов (активный) будет предоставлять сервис. Пусть для определенности это будет адрес {{{192.168.0.63}}}. Для начала установим пакет arping: {{{ $ sudo apt-get install arping }}} В файле /etc/network/interfaces обоих серверов добавляем настройку для общего адреса: {{{ iface eth0:0 inet static address 192.168.0.63 netmask 255.255.255.0 }}} где вместо "eth0" следует вписать имя используемого сетевого интерфейса. Отредактируем файл /etc/default/arping, вписав в него {{{IPUP=1}}} и {{{DOWN=1}}}. На первом сервере выполняем команду {{{ $ sudo ifup eth0:0 }}} Выполнение этой команды на втором сервере должно дать ошибку, так как адрес уже присутствует в сети: {{{ $ sudo ifup eth0:0 * Using arping to check duplicity of 192.168.0.63... ...fail! run-parts: /etc/network/if-up.d/arping exited with return code 1 Failed to bring up eth0:0. }}} Теперь необходимо изменить настройки odbc таким образом, чтобы оба сервера !FreeSwitch подключались к базе данных используя общий адрес и, таким образом, подключались к одному и тому же серверу mysql. Для этого в ранее созданном файле /etc/odbc.ini указываем адрес сервера {{{192.168.0.63}}}. Устанавливаем параметр sysctl net.ipv4.ip_nonlocal_bind в значение 1 чтобы дать возможность неактивному серверу !FreeSwitch слушать адрес, отсутствующий на его интерфейсах: {{{ $ sudo sysctl net.ipv4.ip_nonlocal_bind=1 }}} Для автоматической установки этого значения в файл /etc/sysctl.conf добавляем строку {{{ net.ipv4.ip_nonlocal_bind=1 }}} В конфигурации профилей !FreeSwitch устанавливаем параметры {{{sip-ip}}}, {{{rtp-ip}}}, {{{presence-hosts}}}, {{{ext-sip-ip}}} и {{{ext-rtp-ip}}} в значение {{{192.168.0.63}}}. Теперь можно запустить сервера !FreeSwitch: {{{ $ sudo service freeswitch start }}} == Синхронизация файлов конфигурации и записей переговоров == Синхронизацию файлов конфигурации и записей переговоров сделаем с помощью rsync. Чтобы схема была симметричной, каждый из серверов будет копировать свои обновившиеся файлы на другой сервер. Копирование будет производиться по SSH. Для начала проверим, что в /etc/passwd пользователю freeswitch установлен реальный shell (а не /bin/false или что-то аналогичное). При необходимости установим шелл командой: {{{ $ sudo usermod -s /bin/sh freeswitch }}} Генерируем пользователю freeswitch rsa ключ для ssh: {{{ $ sudo su -l freeswitch $ ssh-keygen -t rsa -b 4096 }}} В результате в домашнем каталоге пользователя freeswitch будет создан файл {{{.ssh/id_rsa.pub}}}. Добавляем содержимое этого файла в файл {{{.ssh/authorized_keys}}} в домашнем каталоге пользователя freeswitch на другом сервере. Проверим, что пользователь freeswitch с одного сервера может войти по ssh на другой сервер без ввода пароля: {{{ $ sudo su -l freeswitch $ ssh
Welcome to Ubuntu 16.04.2 LTS (GNU/Linux 4.4.0-62-generic x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage Last login: Wed Feb 22 11:27:59 2017 from 192.168.0.61 $ }}} Теперь, когда каждый из серверов может соединиться по SSH со своим собратом, настроим синхронизацию файлов конфигурации и записей переговоров. Для этого добавим в /etc/crontab каждого сервера такие записи: {{{ */5 * * * * freeswitch rsync -au -e ssh /etc/freeswitch/
:/etc/freeswitch/ */5 * * * * freeswitch rsync -au -e ssh /var/lib/freeswitch/recordings/
:/var/lib/freeswitch/recordings/ }}} В вышеприведенном примере файлы синхронизируются каждые 5 минут. Для более равномерного распределения нагрузки на сеть можно настроить серверам разное время синхронизации, например: {{{ 0-59/5 * * * * freeswitch rsync -au -e ssh /etc/freeswitch/ ....... 1-59/5 * * * * freeswitch rsync -au -e ssh /var/lib/freeswitch/recordings/ ........ }}} на первом сервере и {{{ 2-59/5 * * * * freeswitch rsync -au -e ssh /etc/freeswitch/ ....... 3-59/5 * * * * freeswitch rsync -au -e ssh /var/lib/freeswitch/recordings/ ........ }}} на втором сервере. Проверим работу синхронизации: на первом сервере создадим новый файл в /var/lib/freeswitch/recordings/ и изменим какой-нибудь файл в /etc/freeswitch/. Подождем 5 минут и убедимся, что на втором сервере появился новый файл в /var/lib/freeswitch/recordings/ и отразилось изменение файла в /etc/freeswitch/. Аналогично проверим копирование в обратном направлении. == Переключение на резерв == Далее будет описано два варианта настройки переключения на резервный сервер: * автоматическое переключение; * ручное переключение. === Автоматическое переключение === Для автоматического переключения будем использовать протокол VRRP и демон keepalived. Устанавливаем пакет keepalived: {{{ $ sudo apt-get install keepalived }}} Конфигурируем keepalived. Сначала создадим скрипт /etc/keepalived/ka-master.pl, который будет передавать !FreeSwitch команду sofia recover при переходе сервера в состояние MASTER: {{{#!perl #!/usr/bin/perl my $password = "secret"; open(STDOUT, "|/usr/bin/logger -t ka-master"); print "Instance went to master, issuing sofia recover.\n"; system("/usr/bin/fs_cli", "-p$password", "-x", "sofia recover"); }}} где "secret" меняем на наш пароль доступа к event-socket !FreeSwitch. Так как файл содержит пароль, не забываем установить ему права доступа, разрешающие чтение только для пользователя root: {{{ $ sudo chown root:root /etc/keepalived/ka-master.pl $ sudo chmod 700 /etc/keepalived/ka-master.pl }}} Создаем базовый файл конфигурации /etc/keepalived/keepalived.conf: {{{ global_defs { router_id FREESW } vrrp_instance VI_FREESW { state BACKUP interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass labuda25 } notify_master "/etc/keepalived/ka-master.pl" virtual_ipaddress { 192.168.0.63/24 dev eth0 label eth0:0 } } }}} где "eth0" - имя сетевого интерфейса, "eth0:0" - алиас с общим адресом - меняем их в соответствии с именем интерфейса каждого сервера. Запускаем keepalived на одном из серверов: {{{ $ sudo service keepalived start }}} Контролируем в /var/log/syslog, что демон успешно запустился и, так как на втором сервере keepalived еще не запуцщен, сразу после запуска keepalived должен перейти в состояние MASTER. Контролируем, что у сервера появился адрес 192.168.0.63. Теперь запускаем keepalived на втором сервере. Контролируем, что демон запустился, на находится в состоянии BACKUP, так как в сети уже есть MASTER. Контролируем переход сервера из состояния BACKUP в состояние MASTER. Для этого на несколько секунд отключаем активный в данный момент MASTER от сети (или просто останавливаем на нем демон keepalived). Контролируцем, что сервер, находившийся в состоянии BACKUP, перешел в состояние MASTER. На данном этапе у нас настроен переход сервера из резерва в активное состояние по единственному критерию - недоступности мастера, определяемой по протоколу VRRP. Теперь добавим сюда контроль работоспособности !FreeSwitch. Для этого создаем скрипт /etc/keepalived/ka-status.sh: {{{#!sh #!/bin/sh password="secret"; profiles="internal internal6"; # Если общий адрес еще не поднят, возвращаем успех. arping -q -c3 -W0.1 192.168.0.63 || exit 0 # Если общий адрес поднят, проверяем работоспособность FreeSwitch RESULT=`/usr/bin/fs_cli -p$password -x "sofia xmlstatus"` for P in $profiles; do echo $RESULT | grep -q "$P" || exit 1 done exit 0; }}} где "secert" заменяем на пароль доступа к event-socket !FreeSwitch-сервера, а переменной {{{profiles}}} присваиваем имена SIP-профилей, наличие которых необходимо контролировать. Теперь, если все перечисленные в {{{profiles}}} профили запущены, скрипт вернет 0, иначе - 1. Если требуется контролировать только один профиль, скрипт можно сделать более лаконичным: {{{#!sh #!/bin/sh password="secret"; profile="internal"; # Если общий адрес еще не поднят, возвращаем успех. arping -q -c3 -W0.1 192.168.0.63 || exit 0 # Если общий адрес поднят, проверяем работоспособность FreeSwitch /usr/bin/fs_cli -p$password -x "sofia xmlstatus" | grep -q "${profile}" || exit 1 exit 0; }}} arping в начале скрипта нужен для разрешения проблемы яйца и курицы: keepalived не перейдет в состояние MASTER и не поднимет на сетевом интерфейсе общий адрес, пока наш скрипт не вернет 0, в то же время профиль !FreeSwitch не сможет стартовать, пока в сети не поднят общий адрес, так как именно этот адрес используется для подключения к базе данных. Благодаря строчке с arping при включении первого из двух серверов, когда общего адреса еще нет, скрипт вернет 0, keepalived успешно перейдет в состояние MASTER и активирует общий адрес. Проверим функционирование скрипта, запустив его вручную. Если все хорошо, укажем keepalived проверять работоспособность !FreeSwitch каждые 10 секунд. Для этого в /etc/keepalived/keepalived.conf добавляем секцию с описанием скрипта: {{{ vrrp_script chk_fs { script "/etc/keepalived/ka-status.sh" interval 10 } }}} и в секцию {{{vrrp_instance VI_FREESW}}} добавляем указание использовать этот скрипт: {{{ track_script { chk_fs } }}} Перезапустим keepalived: {{{ $ sudo service keepalived restart }}} Контролируем, что сервер в состоянии BACKUP. Теперь подключаемся к консоли !FreeSwitch и останавливаем профиль internal: {{{ > sofia profile internal stop }}} Ждем 10 секунд и контролируем, что keepalived перешел в состояние FAULT. === Ручное переключение ===