Использование BigBlueButton

Использование BigBlueButton

от Виталий Лавров -
Количество ответов: 9
Изображение пользователя Эксперт по Moodle

Вопрос к тем, кто использует ВВВ в moodle. Поделитесь  наблюдениями.

Столкнулнулись со следующим ограничением: в одной комнате не может быть более 200 подключений.
Все простьо сильно тормозит  (на сервере в тот момент было 280 слушателей и  20 видео и трафик порядка 180Мбит/с).
Правда разработчики честно указали в документации - интерфейс не расчитывался больше чем на 100 человек в одном мероприятии.

По наблюдениям, после примерно 180 аудио+20видео подключений начинаются мелкие звуковые помехи.

Используемое железо: старинный сервер (не виртуальный) xeon E31230 3.2GHz + 8Gb RAM (asus R100-X7).
8 потоков загрузить почти не удается. Помяти хватает. Чтоб загрузить нормальный сервер потребуется несколько инсталяций (в LXD).

Есть проблема - оно не успевает обрабатывать записи. У нас за день умудряются записать больше 20 часов записей!
Скрипт который конвертирует аудио/видео - однопоточный! Ночью, когда нет мероприятий, система почти простаивает, несмотря на большую очередь заданий. Я подправил скрипт так, что его можно безопасно запускать одновременно много раз (добавил блокировочный файл на обрабатываемую запись).  Пилить PR в гитхабе - времени нет. Если кто заинтересуетсь, то могу выложить куда-нибудь.

Плохо, что ссылки на файлы записей никак не защищены. С этим точно нужно что-то делать.

bbb-record - это конечно хорошо, но оно тормозное (на bash), но для работы с большим числом записей нужно что-то другое.

Теперь про проблемы с плагином в  moodle.

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

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

Нет ограничения сверху на число участников мероприятия! Лечится мелким патчем.

Нет никакой информации о записи ( той, что выдает bbb-record ). IMHO дописать краткое состояние записи не сложно, т.к. оно может быть получено через API ВВВ. Я раздумываю об отдельном локальном плагине, который бы админам мог показать состояние записей без необходимости ssh доступа на сервер.

Нет возможности использовать разные ВВВ-сервера в разных мероприятиях. Хотя эту проблему я пытаюсь разрешить.
( Теоретически есть проект балансировки между фермой ВВВ-серверов, но состояние его не очень радует)

Хорошо, что есть configurable report! Без него невозможно понять кто и что делал в ВВВ.


Сумма оценок: -
В ответ на Виталий Лавров

Re: Использование BigBlueButton

от Yevgenii Losonogov -
"в одной комнате не может быть более 200 подключений." - так и должно быть. Большое подключение числа пользователей не обходится одним физическим сервером, для реализации данной задачи необходима процедура балансировки нагрузки на обработку потов распределённая между несколькими серверами. 8-мью потоками одного процессора xeon E31230 3.2GHz вам не обойтись при обработке потокового видео имеющего HD формат. Всё что касается обработки видео, для этих целей необходимо хорошее производительное железо уровне не ниже xeon gold или xeon platinum...

Особенностью режима записи у "bbb" является синхронная запись несколько отдельных потоков входящей в состав одной открытой сессионной конференции в формате HD. В данном случае на данная техническая характеристика полностью зависит от пропускной способности RAID-массивов.
Сумма оценок: -
В ответ на Yevgenii Losonogov

Re: Использование BigBlueButton

от Виталий Лавров -
Изображение пользователя Эксперт по Moodle
Формат HD? Где? В ВВВ?
Вы про внутренний формат при перекодировки видео/аудио ?

Особенностью режима записи у "bbb" является синхронная запись несколько отдельных потоков входящей в состав одной открытой сессионной конференции в формате HD. В данном случае на данная техническая характеристика полностью зависит от пропускной способности RAID-массивов.
Про загруженность дисков могу сказать одно  - в нее ни разу не упирались.
На сервере 2 диска - 1 ssd 240Gb и 1 hdd 2Тб. На hdd было вынесено /var/lib/kurento /var/bigbluebutton/published /var/bigbluebutton/recording

Возможно машинка с приличной видеокартой поможет ffmpeg-у значительно быстрее перекодировать.

Сумма оценок: -
В ответ на Виталий Лавров

Re: Использование BigBlueButton

от Yevgenii Losonogov -
"Формат HD? Где? В ВВВ?" - да, веб-камеры могут работать в режиме HD 720p при передаче видеопотока.
Об этом упоминается в инструкции (What are the bandwidth requirements for running a BigBlueButton serverAnchor link for: what are the bandwidth requirements for running a bigbluebutton server) - "When sharing a webcam as a moderator, BigBlueButton lets you select 320x240, 640x480, or 1280x720 ... = 0.60 Mbits/sec video stream"

"Все просто сильно тормозит  (на сервере в тот момент было 280 слушателей и  20 видео и трафик порядка 180Мбит/с)." - конечно будет тормозить 
Даже если использовать скромное разрешение веб-камеры 320x240px = .25 Mbits/sec


Например, если в комнате с 20 веб-камерами работают 20 пользователей, то пропускная способность вычисляется следующим образом:

Вычисляем по формуле

Y = .25 Мбит/с
W = количество веб-камер, которые транслируются
U = количество пользователей, которые смотрят конференцию

Для расчетов применим следующую формулу:

    Пропускная способность входящего трафика сервера: W * Y
    Исходящая пропускная способность трафика сервера: W * (U-1) * Y (минус один, так как вещатель не должен подписываться на свой собственный поток)


- Входящий трафик: 20 *.25 = 5 Мбит/с входящая пропускная способность, необходимая для сервера;
- Исходящий трафик: 20*(20-1)*.25 = 95 Мбит/сек требуется для исходящей пропускной способности сервера ;

Теперь ваш пример 20 камер, 280 слушателей:
- Входящий трафик: 20 *.25 = 5 Мбит/с входящая пропускная способность, необходимая для сервера;
- Исходящий трафик: 20*(280-1)*.25 = 1 396 Мбит/с требуется для исходящей пропускной способности сервера ;

Вопрос, - Каким образом вы получило цифру 180 Мбит/с ?

В вашем случае, сетевой адаптер на сервере требуется с поддержкой 10G, а также широкополосный канал выделенного интернета не менее 1,5 Гбит/сек

Минимальные требования к серверу "BBB":
4 CPU cores (8 is better) -  ваш процессор Xeon E31230 идентичен данной характеристике;
8 GB of memory with swap enabled (16 GB of memory is better);

С HDD диском, вы укладываетесь под данный параметр, только на сервере отсутствует резерв СХД.



Сумма оценок: -
В ответ на Yevgenii Losonogov

Re: Использование BigBlueButton

от Виталий Лавров -
Изображение пользователя Эксперт по Moodle

Про 280+20 - всего было на сервере.
В большом собрании было чуть больше 200 человек, но там всего было 2 камеры. 2*200*0.25 = 200Мбит/с
т.ч. формула примерно верна.

Вопрос  собственно такой - можно ли ограничить подключения по достижению предельной загрузки сервера?
В плагин для  moodle  не сложно подправить. Вопрос в вычислении загрузки.

Хорошо бы иметь ограничение на число видео в одном собрании. Но это ограничение плагином не реализовать.

Сумма оценок: -
В ответ на Виталий Лавров

Re: Использование BigBlueButton

от Yevgenii Losonogov -
Можно на стороне сервера в Nginx прописать необходимые настройки по ограничению доступа по максимальному числу подключений.

Для проведения массовых мероприятий с числом подключений "200 +" данный инструмент "BBB" в обычной конфигурации не совсем подходит.

Если необходим инструмент для собрания с числом подключений "300 +" , это лучше это реализовывать на сервисе Youtube, с включением чата. Или создать отдельный веб-ресурс, куда можно интегрировать окно Youtube и форму обратной связи (чат, голосовые или видео сообщения). Тогда собрание будет интерактивным). Сама реализация стрима собрания в режиме реального времени на Youtube возможна при помощи бесплатного инструмента OBS Studio...
Сумма оценок: -
В ответ на Yevgenii Losonogov

Re: Использование BigBlueButton

от Vadim Dvorovenko -
Изображение пользователя Developers Изображение пользователя Майнтейнер перевода

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

Прелесть BBB в сочетании с интеграции с moodle в том, что организацию множества подобных мелких мероприятий на 10-30 человек можно снять с плеч it-подразделений, обучив преподавателей и подготовив инструкции для студентов.

Что касается мероприятий на 100+ человек, то мне кажется, ситуация, когда больше ста человек целенаправленно собираются слушать кого-то, подразумевает достаточно высокую стоимость времени докладчика, существенно более высокую, чем стоимость времени обслуживающего персонала. При этом, зачастую, чем дороже докладчик, тем дальше от эффективного владения компьютером. Поэтому для таких дорогих докладчиков/мероприятий вполне рационально выделять специалиста который настроит камеру, звук, стрим, полистает за докладчика слайды, зачитает ему вопросы с чата. OBS тут реально то, что нужно. Даже если докладчиков несколько и они находятся в разных местах, достаточно будет одного человека обслуживающего персонала. Ведь в тот же OBS-стрим можно завернуть звонок по скайпу.

Сумма оценок: -
В ответ на Виталий Лавров

Re: Использование BigBlueButton

от Vadim Dvorovenko -
Изображение пользователя Developers Изображение пользователя Майнтейнер перевода

1. Если хотите масштабировать bbb - есть проект https://github.com/blindsidenetworks/scalelite . Он сам раскидывает между серверами мероприятия в зависимости от нагрузки. Изучите, может и нам расскажете.

2. Искал про обработку видео bbb отдельными серверами - ничего не нашел. Глубоко не копался, но записи bbb можно выносить на nfs диск. nsf диск можно подключить к нескольким копиям bbb, сделанным в виде виртуалок, возможно они смогут делать обработку засчёт работы в несколько потоков, каждый на одной машине, без модификаций bbb

3. Запретить все новые подключения к bbb можно просто отключив плагин в списке плагинов, тогда никто не увидит этих элементов курса, и не сможет подключиться. Ну и экстремальные варианты - временно менять в настройках имя сервера bbb на невалидное

4. bbb отдает записи как простой веб-сервер, можно попробовать навесить какие-то ограничения на эти папки средствами веб-сервера. Например, сделать регулярку на referer, чтобы только при переходах из moodle работало, хотя это, конечно, не панацея. 

Я так понимаю, что архитектура bbb такова, что не имея api, которое вернет название папки с записью угадать её нереально. Но вот после этого, уже как с доступом по ссылке в google - можно делиться с кем угодно. Но получив доступ однократно, можно выкачать файлы и поделиться ими по другим каналам. Можете описать, как хотелось бы, чтобы работала защита контента, и от чего она должна защищать

Можно попробовать подцепить в moodle папку с записями bbb по nfs и сделать из неё репозиторий, а потом как-то делать изменение адресов bbb на адреса этого репозитория в moodle, тогда все запросы будут проходить через систему авторизации в moodle. Но нужно ли так усложнять?

5. Общее число соединений можно попробовать порезать средствами iptables. Если решитесь на использование scalelite, см. процедуру https://github.com/blindsidenetworks/scalelite/blob/8baebede0546935b5227514e37dd9b5d0d7f438d/app/models/server.rb#L118, она находит наименее загруженный сервер или выдает ошибку, если свободных серверов нет. Можно допилить эту процедуру, чтобы при совокупной нагрузке больше N тоже возвращала ошибку.

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

Сумма оценок: -
В ответ на Vadim Dvorovenko

Re: Использование BigBlueButton

от Виталий Лавров -
Изображение пользователя Эксперт по Moodle
1. Да, про scalelite я читал, но issue пока не воодушевили. Возможно попробую, но позже.

2. Да. только я думаю, что наоборот будет лучше (с BBB экспортировать каталог с данными). Зачем держать все яйца в одной карзине ?
У меня была мысль сделать обёртку для запуска ffmpeg на удаленной машине (сильно упрощенный вариант distcc), которая имеет доступ к данным всех ВВВ серверов. Пока нет уверенности, что в ffmpeg возможно аппаратное кодирование в vp9.
Но если удасться научиться использовать аппаратные средства кодирования, то будет вообще супер.
Проблема в том, что нормальную видеокарту в 1-2U сервер не запихнуть улыбаюсь

3. Мест, где клиент обращается к ВВВ-серверу всего 2. Там сделать заглушки очень просто.

4. Добавить бы проверку cookie от сессии moodle. Внутри одного домена это не сложно.
В nginx ограничить доступ к playback через internal, в плагине изменить url для playback, а дальше своим скриптом проверять сессию и делать внутреннюю переадресацию.

5. В плагине всего 1 место для подключение/создания собрания. Там можно проверять все, что угодно.
Со стороны ВВВ нужен какой-то быстрый сервис отдающий загрузку. IMHO это не сложно.

6. При наличии сервиса в п.5 оно просто реализуется.
Я пока не могу оценить ресурсоемкость getMeetings. Там как раз есть все, что нужно. На ее основе у меня мониторится состояние ввв-сервера.
Сумма оценок: -
В ответ на Виталий Лавров

Re: Использование BigBlueButton

от Alex Craglorn -
1) Ограничение в примерно 100-150 человек на одну конференцию на сервере ЛЮБОЙ конфигурации, даже запредельной (20+ ядер 64ГБ етс) связана только с одним - html 5 клиент, а именно node.js, который там используется.

Он не может нормально использовать много ядер,только одно.

Соответственно, лимит по количеству пользователей в одном вэбинаре будет примерно 100-150, а потмо начнутся проблемы с подвисаием интерфейса, невозможностью присоединиться и тд.

Вы можете увеличить ОБЩЕЕ количество пользователей БББ инраструктуры,если заведете несколкьо БББ серверов и воспользуетесь балансировщиком scalite от создателей БББ, но это НЕ ПОМОЖЕТ вам избавиться от лимита в 100-150 пользователей на одну конференцию.

2) что касается записей.. по-моему он быстрее обрабатывает их,если форсировать мп4 формат в настройках БББ вместо webm или как он там называется.


Вообще, конечно хотелось бы чтобы у нас была возможность включать МНОГОПОТОЧную кодировку (на ночь например) по арсписанию, а еще лучше если бы была поддержка встроенных видеокарт для энкодинга посредством видеокарты. встроенной.

3) Если нужно транслировать вэбинар для несколько сотен\тысячи+ человек- используйте OBS и транслируйте на ютуб (захват всего экрана или окна браузера с БББ ,зависит от условий)


Сумма оценок: -