Архитектура

Обновлено 11 февраля 2025

Состав поставки

Серверная часть ПО SaluteJazz поставляется как набор Docker-образов. Образы доступны для скачивания из репозиториев SaluteJazz (jazz.nx.s2b.tech) или, в случае установки ПО в закрытый контур, передаются в виде архива.

Клиентская часть для мобильных приложений доступна в приложениях AppStore и Google Play.

Desktop версии доступны для операционных систем Windows, macOS и Linux/Unix.

Данные (логин/пароль) для загрузки ПО передаются отдельно.

Чтобы узнать о массовой установке на устройства desktop, смотрите Использование SCCM для массовой установки Desktop.

Варианты установки

Установка SaluteJazz доступна в следующих вариантах:

• All-in-One — однонодовая конфигурация, все компоненты SaluteJazz устанавливаются в пределах одной виртуальной машины. Подходит для небольших и тестовых сценариев использования ВКС (до 250 одновременных подключений к ВКС).
• Enterprise — многонодовая конфигурация, масштабируемое решение. Компоненты SaluteJazz распределены по разным виртуальным машинам. Распределение происходит по ролям.

Роли виртуальных машин:

• server_host — kubernetes мастер, компоненты мониторинга;
• node_proxy — компоненты coturn, nginx-ingress;
• node_jvb — компоненты ВКС;
• nope_app — компоненты сервисов авторизации, лицензирования;
• node_persistent — сервисы требующие персистентного хранилища — postgres, s3-minio, elasticsearch-fts, kafka, prometheus;
• node_sip — сервис sip gateway (sip signaling);
• node_transcode — сервис транскодирования для компонентов webinar, sip, запись конференции.

Одна виртуальная машина может одновременно иметь несколько ролей.

Роли node_proxy и node_sip не должны быть на одной и той же машине.

В качестве операционной системы возможно использование следующих ОС (но не ограничено):

• Astra Linux;
• РЕД ОС;
• Basealt;
• Ubuntu;
• CentOS.

All-in-One

Все роли расположены на одной виртуальной машине. Включена функция ВКС. Функции sip, webinar, messenger и запись на сервер выключены.

Минимальные требования к виртуальной машине:

Ресурс	Значение
CPU	16
Memory	64 GB
System Disk	200 GB
Network Interface	1 x 1Gbps
Private IPv4	1
Public IPv4	1

Для подключения и управления ВКС требуется:

• 3 DNS записи типа A;
• 3 SSL/TLS сертификата (или wildcard сертификат);
• 1 приватный IPv4 адрес.

В случае публикации сервиса в интернет дополнительно требуется:

• 1 публичный IPv4 адрес;
• 1 DNS запись типа А.

Enterprise

Вариант распределенной установки обусловлен количеством пользователей, одновременно подключенных к ВКС. Одна виртуальная машина node_jvb может обслуживать до 250 одновременных подключений. Виртуальная машина типа node_proxy ограничена пропускной способностью сетевого интерфейса. База данных node_persistent и server_host представлены в единичных экземплярах. Дополнительные компоненты node_app масштабируются в зависимости от нагрузки программного комплекса в целом и обычно представлены в экземпляре 1—2 штуки.

Роли могут быть распределены по разным виртуальным машинам. Иногда роли могут быть совмещены на одной виртуальной машине.

Отказоустойчивость решения строится на уровне инфраструктуры.

На рисунке ниже представлен типовой сценарий масштабирования. Распределение нагрузки происходит за счет балансировки DNS RR (round robin). Подключение пользователей к ВКС из сети Internet проходит через компоненты node_proxy и обусловлено прохождением сетевого трафика от конечных устройств пользователя через NAT. В случае подключения к ВКС из сети LAN, если NAT не используется, подключение происходит непосредственно к сервисам node_jvb.

Подключения SIP терминируются на node_sip. В случае организации централизованной точки входа node_proxy перенаправляет udp/5060 соединения на node_sip. node_sip и node_proxy слушают порт udp/5060, поэтому не могут быть развернуты на одной виртуальной машине.

Во время создания кластера kubernetes для каждой ноды создается метка. Затем микросервисы равномерно распределяются по нодам в соответствии с меткой.

Для подключения и управления ВКС требуется:

• L3-L7 Load Balancer с поддержкой websocket или 1 DNS запись типа A на каждую ноду node_proxy, при этом FQDN будет один и тот же (DNS RR);
• 3 DNS записи типа A для панелей управления;
• 3 SSL/TLS сертификата;
• 1 приватный IPv4 адрес на каждую ноду вне зависимости от роли.

В случае публикации сервиса в интернет дополнительно требуется:

• 1 публичный IPv4 адрес на каждую ноду node_proxy;
• 1 DNS запись типа A на каждую ноду node_proxy, при этом FQDN будет один и тот же (DNS RR).

Требования для установки Webinar, SIP, Запись на сервер

Для транскодирования медиа используется нода node_transcode. В таблице представлены максимальные значения CPU/RAM для сервиса при использовании дополнительных компонентов:

	Webinar	SIP 720p30	SIP 720p60	SIP 1080p30	SIP 1080p60	Запись на сервер
CPU (X1)	7	-	-	-	-	-
RAM (Y1)	3	-	-	-	-	-
CPU (X2)	-	1	2	4	8	-
RAM (Y2)	-	2	4	8	16	-
CPU (X3)	-	-	-	-	-	4
RAM (Y3)	-	-	-	-	-	2.3

Расчет потребления ресурсов на одну виртуальную машину при условии, что все три сервиса включены и используются одновременно:

CPU = 2 + X1 + X2 + X3

RAM = 4 + Y1 + Y2 + Y3

При горизонтальном масштабировании на каждую виртуальную машину:

CPU = 2 + ((X1 + X2 + X3) / n)

RAM = 4 + ((Y1 + Y2 + Y3) / n)

n — количество виртуальных машин. Задается как список IP-адресов нод node_transcode.