Установка четырехсерверной конфигурации

При разворачивании четырехсерверной конфигурации следует учитывать, что при создании конфигурации с помощью мастера конфигураций распределение нод между серверами будет сбалансированным и равномерным из учета того, что сервера равны по мощности. Если это не так, возможно придется вносить правки в конфигурацию в ручном режиме. С одним из вариантов распределения нод между серверами можно ознакомиться в приложении Б.

Фактически в данной схеме есть 1 мастер и 3 подчиненных (slave). Два сервера имеют базу данных (обязательно мастер и любой из слэйвов). Следует учитывать, что данная схема является отказоустойчивой при падении одного сервера, максимум двух (если падает один из серверов БД и один из серверов без БД).

Установка мастер-сервера ничем не будет отличаться от установки из главы «3.2 Установка односерверной конфигурации», за исключением:

1. Указания постфикса для инстанса системы (рисунок 3.2.2);
   • Для любой многосерверной конфигурации необходимо указывать постфикс для инстанса, т.е. его нужно задать отличным от дефолтного на этапе установки мастер-сервера. При разворачивании каждого слэйв-сервера этот постфикс будет также указываться – всем экземплярам системы рекомендуется указывать один постфикс.
2. Указания, что необходима репликация, при установке PostgreSQL (рисунок 3.2.5);
   • При установке PostgreSQL на мастер-сервер, выбираем, что репликация нужна и что сервер будет в режиме мастера. Важный момент в том, что при многосерверной конфигурации PostgreSQL всегда ставится в хост, а не в докер-контейнер. Это необходимо для того, чтобы не тратить время на пробрасывание портов из хоста в докер и наоборот на каждом сервере. Таким образом остается обеспечить только сетевую доступность между серверами, что сильно упрощает установку и настройку многосерверной конфигурации.
3. Указание PSK cookie (можно также оставить дефолтным);
   • На всех экземплярах платформы должен указываться одинаковый, также, как и постфикс для инстанса. Используется нодами при обмене информацией между серверами (если отправивший сервер знает правильный ключ, значит он «свой»).
4. Создания конфигурации (на рисунках 3.2.14-3.2.19).

Таким образом, в данной главе установка мастер-сервера описываться не будет, т.к. вся необходимая для этого информация есть на рисунках 3.2.1-3.2.11.

Будем считать, что мастер-сервер уже установлен с учетом исключений выше и перейдем к установке второго сервера с базой данных.

Начало установки второго сервера с базой данных представлено на рисунке 3.3.1. Отличие от рисунков 3.2.1 и 3.2.2 исключительно в указании постфикса инстанса. Он должен совпадать с постфиксом инстанса для мастер-сервера.

Когда мы устанавливаем слэйв-сервер, установщик спрашивает с какого сервера ему забирать конфигурацию. Это показано на скриншоте 3.3.2. Важный момент в том, что строка должна быть обязательно в виде, представленном на рисунке. Если возле запятой появятся пробелы, установка не будет корректной.

Далее установщик предлагает установить http/https прокси (рисунок 3.2.4). В этом нет необходимости.

После предлагается установить PostgreSQL. Делаем аналогично рисунку 3.2.5, но на вопрос «Нужна ли вам репликация?» отвечаем «Да». Сначала установщик спрашивает, в каком режиме нам необходим этот сервер – т.к. это слэйв-сервер, то режим PostgreSQL должен быть recovery. А после установщик предлагает ввести адрес сервера и порт, на котором находится PostgreSQL в режиме мастера (рисунок 3.3.3).

Затем необходимо указать пароль для пользователя PostgreSQL, отвечающего за репликацию – рисунок 3.3.4. Важный момент в том, что на мастер-сервере и на этом сервере пароли к пользователям PostgreSQL должны совпадать.

После этого сервер начинает обращаться по адресу с рисунка 3.3.2 в попытках получить конфигурацию.

Конфигурация будет создана после установки всех 4 серверов, хотя логически ее можно создать уже при наличии двух серверов – оставшимся слэйв-серверам мастер-сервер просто не сможет отдать конфигурацию.

Установка двух оставшихся слэйв-серверов аналогична второму серверу с базой данных за исключением того, что PostgreSQL не устанавливается, т.е. согласно рисункам 3.3.1-3.3.2.

Все слэйв-сервера обращаются к мастер-серверу до тех пор, пока не смогут забрать оттуда конфигурацию.

Перед созданием конфигурации проходим этапы с рисунков 3.2.11-3.2.13 включительно. После чего в мастер-домене в разделе «Домен» на вкладке «Лицензия» создаем следующую конфигурацию (рисунок 3.3.5).

Заполняем информацию о всех серверах аналогично рисунку 3.3.6.

Далее задаем подключение к базе данных (на рисунке 3.3.7). Обязательно ставим галочку «Включить контроллер потоковой репликации».

Далее мы должны настроить контроллер потоковой репликации. Наглядно настройки показаны на рисунках 3.3.8 и 3.3.9. Поле «Имя экземпляра» заполняем следующим образом слово «era» + постфикс инстанса, который указывали на всех четырех серверах платформы. Поле «Адрес рефери (для пингов)» оставляем значением по умолчанию. Далее указываем информацию о подключении по ssh к этим серверам. Поля «Логин ssh-сервера» и «Пароль ssh-сервера» заполняем теми данными, которые указывали при установке PostgreSQL (установщик создавал пользователя в linux и просил задать ему пароль).

Нажимаем кнопку «Далее» и продолжаем настройку контроллера потоковой репликации. Если на этапе установки значения оставались дефолтными, то в данном разделе (скриншот 3.3.10) также оставляем дефолтными.

После этого мы получаем конфигурацию системы в виде JSON-файла. Далее платформа проверяет валидность конфигурации и меняет ей статус. Как только конфигурация стала корректной, ее можно активировать. Это происходит абсолютно аналогично рисункам 3.2.17-3.2.19 включительно. После активации конфигурации стоит создать рабочий домен. В данном случае это также не будет отличаться от рабочего домена в односерверной конфигурации, так что для наглядности следует опираться на рисунки 3.2.20-3.2.22 включительно.

На этом установку четырехсерверной конфигурации можно считать завершённой.

Следует учитывать, что отказоустойчивость платформы также должна обеспечиваться сетевой инфраструктурой заказчика. Например, при недоступности доменного имени рабочего домена (era-test.infinity.ru) DNS-сервер заказчика должен перенаправлять трафик на резервный адрес иначе тот же web-интерфейс перестанет быть доступным. Аналогичные требования предъявляются и к настройке ip-телефонов/софтфонов. Регистрация ip-телефонов/софтфонов детально описана в главе «3.5 Базовая настройка телефонной платформы».