Резервирование и каскадирование серверов

Для организации сервиса видео-конференц-связи (далее ВКС) на базе Vinteo достаточно одного физического сервера, но для получения отказоустойчивой системы и системы, позволяющей выдерживать высокую нагрузку, необходимо использовать кластер из нескольких серверов.

В системе Vinteo можно выделить две роли серверов:

• коммуникационный сервер и сервер управления (далее сервер управления);
• медиасервер.

В системе во время работы может быть только один сервер управления. Количество медиасерверов определяется как N+1, минимум - один. Минимальное количество физических серверов - один, совмещающий обе роли. При использовании резервирования мы получаем еще один сервер управления для горячей замены основного сервера управления, если он выйдет из строя. Резервный сервер управления может быть лишь 1.

Сервер управления - web-сервер и сервер, обеспечивающий взаимодействие по коммуникационным протоколам (SIP, H.323, WebRTC).

Для резервирования сервера управления используется схема: primary - secondary. Primary-сервер является активным и обслуживает систему, secondary-сервер является пассивным, отслеживает состояние primary-сервера и с интервалом в 5 минут реплицирует на себя c него данные из БД и из файловой системы. Для корректной работы резервирования необходимо, чтобы основной и резервный сервер были сопоставимы по мощности.

При выходе из строя primary-сервера secondary-сервер берет роль primary на себя, поднимает интерфейсы с IP-адресами системы, прописанными в БД, включает сервисы управления и телефонии.

При возвращении в строй первого сервера (при загрузке) он (первый сервер) возьмет на себя теперь роль secondary, определив, что primary-сервер уже есть в сети на интерфейсе eth1. Таким образом, primary-сервером становится тот сервер, который будет включен первым, второй же станет secondary-сервером.

Если primary-сервер теряет связь со secondary-сервером, то лицензия становится временной и действует 72 часа с момента потери связи. За это время необходимо решить техническую проблему с вышедшим из строя сервером или, если это не представляется возможным, обратиться в техническую поддержку Vinteo для урегулирования вопроса со сроком действия временных лицензий.

При потере связи между secondary и primary-серверами на интерфейсах eth1, может произойти ситуация, когда оба сервера станут primary. Это может привести к непредсказуемым последствиям, вплоть до полной недоступности сервиса.

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

В основе медиасервера лежит модуль Multipoint Control Unit (далее MCU). MCU отвечает за такие процессы как микширование, транскодирование и трансрейтинг.

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

Для обеспечения резервирования медиасерверов в системе необходимо иметь как минимум N+1 медиасервер, где N - количество медиасерверов, необходимых для обслуживания максимального количества участников при заданных сценариях ВКС. MCU может быть также управляющий сервер.

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

При подключении к конференции первого участника, сервер управления выбирает наименее загруженный медиасервер для хостинга этой конференции. При загрузке медиасервера, обрабатывающего конференцию, свыше 40%, новые участники, не входящие в раскладку конференции, отдаются на обработку (балансируются) на другие доступные медиасерверы. Медиасерверы не получают и не отдают трафик клиентам, они лишь распределяют нагрузку декодирования и кодирования раскладок конференций между собой, обмениваясь трафиком с основным сервером (сервером управления).

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

Схема системы ВКС Vinteo при падении одного из медиасерверов кластера

Схема системы ВКС Vinteo после передачи раскладки на другой медиасервер

При использовании всех возможностей сервера Vinteo для резервирования и каскадирования, получается следующая схема сети ВКС:

Для удобства настройки рекомендуется назначить IP-адрес интерфейса eth0 на резервном сервере из одной подсети с основным сервером.

Если необходима адресация, отличная от показанной на схеме, то настроить резервирование и каскадирование самостоятельно не получится — для этого необходимо обращаться в техническую поддержку Vinteo. При невозможности подключения сотрудников технической поддержки к серверам по SSH будут выданы патчи с необходимой адресацией. Верно только для серверов с прошивкой ниже 30.0.0; в v30 и выше можно использовать любые адреса подсетей.

Интерфейсы eth0 основного и резервного сервера должны быть подключены к сети, откуда ожидаются подключения абонентов.

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

Сеть, указанная как 192.0.2.128/25, может не иметь никакого внешнего подключения, кроме как к ПК администратора для первичной настройки. Подразумевается, что она будет использоваться только для соединения медиасерверов и управляющего сервера.

1. Для самостоятельной настройки IP-адресация должна соответствовать отображенной на схеме из раздела “Схема резервирования и каскадирования серверов”.
2. Для медиасерверов, ради удобства настройки, рекомендуется назначить IP адреса на интерфейсе eth0, доступные с ПК администратора.
3. необходимо получить у технической поддержки Vinteo необходимые файлы для настройки:

• config_patch_generate_replicator_keys.bin
• config_patch_to_configure_media_servers.bin (для v30 и выше эти патчи больше не требуются)
• config_patch_prepare_slave.bin (для v30 и выше эти патчи больше не требуются)

4. необходимо установить основной, резервный и медиасерверы в соответствии с инструкцией.
5. необходимо обновить ПО всех серверов до последней версии. ПО всех серверов должно быть одинаковой версии.
6. необходимо установить лицензии на основном и резервном серверах. На основном сервере лицензия должна содержать портовые лицензии и лицензию на резервирование.

На резервном сервере лицензия должна содержать резервирование и порты, если используются серверы с Static/Dynamic лицензированием. Если используется сервер с лицензированием Enterprise, то достаточно только резервирования.

Необходимо назначить IP-адреса (добавить необходимые интерфейсы кнопкой “Добавить” в разделе Настройки → Параметры сетевых интерфейсов):

Основной сервер

• Eth0 — адрес, к которому будут подключаться абоненты (из внутренней сети или из DMZ)
• Eth1 (резервирование) - 192.0.2.1 / 255.255.255.252
• Eth2 (каскадирование) — 192.0.2.200 / 255.255.255.128

4. необходимо перезагрузить сервер для применения настроек.

Резервный сервер

1. Eth0 — адрес из подсети Eth0 основного сервера. После активации резервирования использоваться не будет
2. Eth1 (резервирование) - 192.0.2.2 / 255.255.255.252
3. Eth2 (каскадирование) — 192.0.2.199 / 255.255.255.128 (или любой свободный адрес из подсети серверов каскадирования, после активации резервирования использоваться не будет)

4. необходимо перезагрузить сервер для применения настроек.

1. на основном сервере необходимо проверить доступность резервного сервера по адресу 192.0.2.2 на странице Настройки → Диагностика → Ping

2. на основном сервере (будущем primary) в разделе “Обновление” необходимо установить патч config_patch_generate_replicator_keys.bin;
3. сразу после установки необходимо перейти в раздел “Статус” и дождаться начала отсчёта времени работы в пункте “Время работы сервера”;
4. как только начнётся отсчёт времени работы сервера, необходимо перейти по адресу https://<ip основного сервера>/config_patch_for_slave_and_media.bin и скачать файл. Важно: файл доступен для загрузки в течение 5 минут с момента начала отсчёта;
5. на резервном сервере (будущем secondary) необходимо установить скачанный патч config_patch_for_slave_and_media.bin в разделе “Обновление”. Необходимо дождаться начала отсчёта времени работы в разделе “Статус”;
6. необходимо установить патч config_patch_prepare_slave.bin на резервный сервер (будущий secondary).*;
7. необходимо выключить основной сервер, который должен стать primary-сервером (192.0.2.1);
8. на резервном сервере (будущем secondary, 192.0.2.2) в настройках резервирования необходимо прописать адрес 192.0.2.1 и сохранить настройки;

9. необходимо выключить резервный сервер;
10. необходимо включить основной (будущий primary-сервер, 192.0.2.1) и прописать в настройках резервирования адрес 192.0.2.2. Необходимо сохранить настройки;

11. необходимо перезагрузить основной сервер;
12. после загрузки основного сервера (192.0.2.1) необходимо включить резервный сервер (192.0.2.2). В результате 192.0.2.1 будет primary-сервером, а 192.0.2.2 — secondary-сервером;
13. необходимо проверить состояние синхронизации на странице “Статус”.

В v30 и выше пункт №6 более не требуется к выполнению.

1. необходимо установить сервер, который будет медиасервером, и обновить его до последней версии;
2. на странице “Параметры сетевых интерфейсов” на медиасервере для интерфейса eth0 IP-адресация должна быть: 192.0.2.201 (202, 203, …) / 255.255.255.128

3. необходимо проверить, что серверу управления доступны будущие медиасерверы по адресам 192.0.2.201 (202, 203…).

4. Важно! Если производилась настройка резервирования, необходимо перейти к пункту 8 и использовать файл, скачанный в разделе “Настройка резервирования”, п. 4. Иначе повторная установка патча config_patch_generate_replicator_keys.bin приведёт к перегенерации ключей и отключению резервирования.
5. на управляющем сервере в разделе “Обновление” необходимо установить патч config_patch_generate_replicator_keys.bin;
6. сразу после установки необходимо перейти в раздел “Статус” и дождаться начала отсчёта времени работы в пункте “Время работы сервера”;
7. как только начнётся отсчёт времени работы сервера, необходимо перейти по адресу https://<ip основного сервера>/config_patch_for_slave_and_media.bin и скачать файл. Важно: файл доступен для загрузки в течение 5 минут с момента начала отсчёта;
8. необходимо установить патч config_patch_for_slave_and_media.bin, полученный на предыдущем шаге или в процессе настройки резервирования, на будущие медиасерверы. Необходимо дождаться начала отсчёта времени работы в разделе “Статус”;
9. на управляющем сервере в разделе “Каскадирование” необходимо добавить нужное количество медиасерверов. В названии серверов рекомендуется указать mcu1, mcu2, … mcuN;
10. если на управляющем сервере также будет использоваться локальный медиасервер, в настройках для localmcu необходимо указать адрес 192.0.2.200 в полях “IP” и “Локальный IP”. Для локального MCU пароль заполнять не требуется. Для остальных медиасерверов в поле “IP” — адрес медиасервера (например, 192.0.2.201), в поле “Локальный IP” — 192.0.2.200. В поле “Пароль” — пароль пользователя admin медиасервера. В поле “Порт” — 5000;
11. необходимо сохранить изменения.

12. Необходимо дождаться, когда у всех медиасерверов в статусе отобразится зеленая галка.

13. на сервере управления в разделе “Обновление” необходимо установить патч config_patch_to_configure_media_servers.bin.* Необходимо дождаться начала отсчёта времени работы в разделе “Статус” в пункте “Время работы сервера”;
14. На главной странице управляющего сервера должны появиться дополнительные вкладки с состоянием медиасерверов:

В v30 и выше пункт №13 более не требуется к выполнению.

Для проверки активности резервирования (доступности сервера secondary) необходимо посмотреть его статус на странице веб-интерфейса Система → Статус, раздел “Резервирование”:

Расшифровка строки

Current role - текущая роль сервера. Далее стоит дата (Role set at), когда роль была установлена;

Last time db change checked at - время последней синхронизации БД между secondary и primary серверами;

Remote(IP) last seen at - время последней проверки primary-сервером secondary-сервера. Проверка происходит раз в 30 секунд.

При рабочем состоянии резервирования все три параметра будут отображаться. Если primary-сервер не видит secondary-сервер по какой-то причине, то в Remote(IP) last seen at будет написано время последней успешной проверки или never. Так же в веб-интерфейсе будет отображаться сообщение о том, что secondary-сервер не синхронизируется.

Для проверки активности каскадирования и статуса медиасерверов необходимо перейти на страницу Система → Настройки, вкладка “Каскадирование” — если сервер недоступен, в его статусе отображается красный крестик.

Если все серверы доступны, то будут зеленые галочки. Статус каждого сервера отдельно можно посмотреть на главной странице.

Если медиасервер будет недоступен, то в его вкладке будет сообщение: “Server not found”.