volrix.pm 1.1: видеовстречи в отказоустойчивом кластере - несколько серверов сигнализации, пул видеомостов, обновление без остановки встреч.
Обновлено 24.10.2026
Вышла версия **volrix.pm 1.1**. Главное в ней - **видеовстречи в отказоустойчивом кластере**. До этой версии встречи ставились только на один сервер. Теперь мастер установки кластера раскладывает их по ролям серверов: сигнализация работает на нескольких серверах одновременно, видеомосты собраны в общий пул, большая встреча растягивается на несколько мостов, а запись, стенограммы и ИИ-протокол берет любой свободный обработчик.
Отказ сервера встречу не прерывает: участники переподключаются сами. Сервер можно вывести на обслуживание, а кластер - обновить, не останавливая встреч. В выпуск вошел и хотфикс **1.0.3**: на установке, обновленной со старой версии, встречи, распознавание речи и ИИ-протокол включаются без ручной настройки. Ниже - как это устроено, что мы проверили на стенде и где пока расчет, а не замер.
Сами встречи в volrix.pm - комната, гости по ссылке, стенограмма, живые субтитры, ИИ-протокол с задачами и защита встречи - подробно описаны в статье о видеовстречах. В версии 1.0 у них было ограничение: встречи работали на одном сервере и в отказоустойчивый кластер не входили. Для небольшой компании этого достаточно. Для организации, где совещания идут весь день в десятках комнат сразу, один сервер - это и потолок мощности, и единая точка отказа: остановился сервер - остановились все встречи.
Тысячи сотрудников и десятки встреч одновременно. Мощность наращивается серверами: новый видеомост - просто еще один узел пула.
Видеосвязь, распознавание речи и ИИ-протокол работают на ваших серверах, без внешних сервисов и без интернета.
Отказ сервера, обслуживание и обновление не прерывают совещаний. Состояние каждого узла видно на одном экране.
Кластер самой системы появился раньше: база PostgreSQL с автоматическим переключением, несколько узлов приложения, обновление узел за узлом. Как он ведет себя под нагрузкой - в отчете о нагрузочных испытаниях. Версия 1.1 добавляет в этот кластер видеовстречи.
Для сотрудников ничего не меняется: та же комната, те же гости, запись и протокол. Меняется то, что под ними.
В кластере работают те же службы, что и на одном сервере: сигнализация и видеомост Jitsi, TURN на coturn, бот записи, распознавание речи и ИИ-протокол. Мастер установки раскладывает их по четырем ролям серверов, а балансировщик кластера дает пользователям один адрес.
Сервер сигнализации ведет комнату: кто в ней, кто модератор, к какому мосту подключен участник. Сигнализация Jitsi не кластеризуется изнутри, поэтому масштаб и отказоустойчивость дают несколько независимых серверов, и все они работают одновременно - по схеме active-active. Схема «основной и резервный» держала бы половину мощности без дела и все равно рвала бы встречи при переключении.
Балансировщик ведет каждую комнату на один из серверов по ее имени и запоминает выбор. Таблица закрепления общая у всех балансировщиков, поэтому участники одной встречи попадают на один сервер, через какой бы балансировщик они ни пришли. Если сервер отказал, комната переходит на живой и остается там: вернувшийся сервер ее не отбирает, иначе встреча разделилась бы на две половины.
Видеомост пересылает звук и видео между участниками. В кластере каждый мост подключен ко всем серверам сигнализации, поэтому мощность мостов не делится между ними, а добавить мост - значит добавить еще один узел. Мост для участника выбирается по региону узла, затем по нагрузке.
Для участников из интернета и закрытых сетей работает TURN (coturn) - теперь на каждом сервере с этой ролью, с общим секретом. Браузер получает весь список и сам выбирает рабочий сервер, поэтому отдельная балансировка TURN не нужна. Для сетей, где наружу открыт только HTTPS, балансировщик делит порт 443 по имени: соединения на имя TURN уходят в coturn пула, остальные - в систему. Второй внешний адрес для этого не нужен.
Бот записи, распознавание речи и ИИ-протокол работают на серверах-обработчиках и берут задания из общей очереди системы: любое задание достается любому свободному обработчику. Записи по ходу встречи сохраняются в общее хранилище системы - базу или подключенное S3 и сетевую папку, а не на диск сервера встреч. Если обработчик отказал, его задание возвращается в очередь и достается другому, а запись теряет секунды, а не встречу.
Бот записи входит в комнату через тот же балансировщик, что и участники, поэтому всегда попадает на сервер сигнализации своей комнаты.
Экран «Администрирование» → «Настройки продукта» → «Видеовстречи» в кластере показывает каждый узел: работает ли сервер сигнализации, сколько у него комнат и участников и сколько мостов он видит; конференции, нагрузку и регион каждого моста; ответ каждого TURN по UDP и TCP; обработчики на связи и свободные места бота записи. Самопроверка проходит те же пункты по узлам и сертификат балансировщика, а раздел «Порты для сетевиков» перечисляет, что открыть снаружи и между серверами.
Настройки встреч кластера меняет мастер установки, экран их показывает. Для своего мониторинга у видеомостов и серверов сигнализации есть метрики в формате Prometheus.
Мы проверили кластер встреч на стенде из трех серверов Proxmox с Ubuntu 24.04: два балансировщика с общим адресом, база на Patroni на трех узлах, два сервера сигнализации, три видеомоста, два TURN и обработчики на двух узлах. Во встрече - два сотрудника и гость по ссылке через зал ожидания.
Впущенный гость после переезда комнаты на другой сервер не возвращается в зал ожидания: система помнит, что модератор его уже впустил. Эту ошибку стенд нашел, и в 1.1 она исправлена.
Для отказов, которые на стенде отдельно не воспроизводили, ориентиры по устройству кластера такие:
Переноса живой конференции между серверами сигнализации без переподключения в Jitsi нет. Поэтому при отказе сервера сигнализации комната входит заново - сама, без действий пользователя, но с паузой в несколько секунд.
Емкость ниже - расчет по открытым данным Jitsi и формулам. Под свою нагрузку ее удобно подтвердить на пилоте.
Крупный профиль рассчитан на организацию с 50 000 пользователей, из которых 10% одновременно во встречах. Из чего складывается расчет:
Мосты в разных регионах (выбор моста по региону узла и связь мостов между регионами) заложены в устройство кластера, но на стенде не проверялись.
Кластер обновляется командой volrix-cluster apply с новым комплектом выпуска. Серверы встреч обновляются по одному, и перед каждым роль делает то же, что администратор перед обслуживанием:
Версии компонентов Jitsi закреплены и меняются только вместе с выпуском volrix.pm. На стенде обновление во время встречи дало паузу 10-20 секунд только участникам комнаты на обновляемом сервере сигнализации, сервер без комнат обновился без пауз.
Для работ на отдельном сервере его выводят из работы без разрыва встреч, а после - возвращают. Обе команды выполняются на сервере мастера:
volrix-cluster meet-drain volrix-cluster.yml srv-1 volrix-cluster meet-resume volrix-cluster.yml srv-1
Порты между серверами, установка без мастера через раздел meetings файла volrix-cluster.yml и разбор частых ошибок - в статье Кластер видеовстреч.
Пакет обновления меняет код системы. С версии 1.0.2 обновление еще и доводит установку до полного состава выпуска: кладет служебные файлы, загружает образы служб, включает встречи, распознавание речи и ИИ-протокол и проверяет результат. На установках, обновленных пакетом с 0.118.6, этот шаг в 1.0.2 срывался, и встречи не включались. Хотфикс 1.0.3 это исправил:
Как обновиться - «Администрирование» → «Обслуживание» → «Обновления» (подробнее):
Обновление до 1.1 включает все исправления 1.0.3, отдельно ставить 1.0.3 не нужно.
Разберем число участников и требования к доступности, предложим раскладку ролей по серверам и покажем встречу с записью, стенограммой и протоколом.
Включение, экран узлов, обслуживание серверов и емкость
Комната, стенограммы, ИИ-протокол и защита встреч
Как кластер системы растет с каждым узлом и переживает отказы
Что вошло в первый мажорный выпуск
Бесплатная версия на 5 пользователей и комплект для закрытого контура
