BigBlueButton на сервере: частые ошибки и решения

MAATRIX

BigBlueButton (BBB) — open source платформа видеоконференций, заточенная под онлайн-обучение: доска, опросы, breakout-комнаты, запись занятий. В отличие от обычного веб-приложения, BBB — это набор из десятка сервисов (FreeSWITCH, mediasoup, Kurento, HTML5-клиент, Redis, NGINX), которые общаются друг с другом через десятки портов и жёстко завязаны на DNS, время и сетевые задержки. Поэтому на практике администраторы упираются не в баги самого BBB, а в мелкие несостыковки окружения — и здесь разбираем их по порядку, от установки до записи занятий.

Почему BigBlueButton такой требовательный к серверу

BBB не просто раздаёт веб-страницу — он в реальном времени обрабатывает медиапотоки от всех участников конференции: декодирует, микширует, кодирует обратно. Это принципиально другая нагрузка по сравнению с CMS или API-бэкендом:

• CPU нагружается пропорционально числу активных видеопотоков, а не числу запросов;
• сеть требует стабильного канала с низкой задержкой и джиттером, а не просто широкой полосы;
• время на сервере должно быть точным — WebRTC чувствителен к рассинхронизации часов;
• IP-адрес сервера должен быть «чистым» — часть корпоративных и учебных сетей блокирует диапазоны, засветившиеся в спам-листах, что рвёт WebRTC-соединение ещё до входа в комнату.

Проект BigBlueButton официально поддерживает установку через собственный скрипт bbb-install.sh на чистый Ubuntu без предустановленных веб-серверов — Apache, NGINX или другой софт на портах 80/443 нужно снести до установки, иначе скрипт либо упадёт, либо сломает конфигурацию Let's Encrypt.

Ошибки на этапе установки

Самая частая причина падения bbb-install.sh — сервер не «чистый»: на нём уже стоит NGINX, Apache, Docker с чем-то на 80/443, или система не той версии, под которую собран скрипт.

Типичный сценарий: скрипт сначала отрабатывает, ставит зависимости, а потом падает на выпуске SSL-сертификата, потому что 80-й порт занят.

# проверить, что реально слушает 80 и 443 порты
sudo ss -tulpn | grep -E ':80|:443'

# если там NGINX/Apache от прошлых экспериментов — снести
sudo systemctl stop nginx apache2 2>/dev/null
sudo apt purge -y nginx nginx-common apache2 2>/dev/null

Второй частый провал — попытка ставить BBB поверх системы, где уже крутятся другие сервисы (например, тот же Docker с проброшенными портами). Официально BBB рассчитан на выделенный под него сервер: делить машину с другими продакшен-сервисами — плохая идея не из-за конфликта пакетов, а из-за того, что медиасервисы BBB съедают CPU и сеть непредсказуемыми скачками, роняя соседей.

Перед установкой стоит явно проверить DNS — домен должен указывать на IP сервера ДО запуска скрипта, иначе Let's Encrypt не сможет провалидировать домен:

dig +short ваш-домен.ru
# должен вернуть ровно IP вашего сервера, без CDN/прокси перед ним

Если с DNS и доменом раньше не приходилось разбираться — по шагам это описано в статье про настройку домена и DNS с нуля.

Сам запуск установки выглядит так:

wget -qO- https://raw.githubusercontent.com/bigbluebutton/bbb-install/v3.0.x-release/bbb-install.sh | bash -s -- \
  -w -v jammy300 -s bbb.ваш-домен.ru -e admin@ваш-домен.ru

Флаг -w ставит фронтенд Greenlight, -v задаёт версию BBB, -s — домен, -e — почту для Let's Encrypt. Версию (jammy300 и т.п.) нужно брать актуальную из официальной документации проекта на момент установки — они меняются от релиза к релизу, и подставлять её «на глаз» из старых мануалов не стоит.

Проблемы с SSL-сертификатом

Даже когда домен настроен верно, сертификат иногда не выпускается или не обновляется. Частые причины:

• Firewall блокирует порт 80 на момент валидации. Certbot (внутри BBB это часть bbb-install.sh) должен получить HTTP-доступ снаружи на 80-й порт именно в момент запроса сертификата.
• CAA-запись домена запрещает Let's Encrypt. Проверяется командой dig CAA ваш-домен.ru — если запись есть и там не указан letsencrypt.org, выпуск сертификата будет падать молча.
• Домен спрятан за Cloudflare с включённым проксированием (оранжевое облако). Для BBB это почти гарантированная поломка: WebRTC не проходит через прокси Cloudflare штатно, а сертификат путается между «настоящим» IP и прокси-IP. Для домена BBB облако Cloudflare нужно выключать (серая иконка, DNS only).

Проверить и перевыпустить сертификат вручную:

sudo certbot certificates
sudo certbot renew --dry-run
sudo systemctl restart bbb-graphql-server nginx

Не работают звук и видео у участников

Это самая частая жалоба пользователей: конференция открывается, интерфейс работает, но камера/микрофон не подключаются или видео зависает у всех, кроме локальной сети. Причина почти всегда одна — TURN/STUN-трафик не проходит через firewall.

BBB использует диапазон UDP-портов для медиапотоков (по умолчанию 16384–32768) плюс отдельный TURN-сервер (coturn), который встроен в установку по умолчанию через turn.ваш-домен.ru. Если провайдер или firewall режет UDP на этом диапазоне — участники за NAT (корпоративные сети, часть мобильных операторов) не смогут установить P2P/relay-соединение.

# проверить, что UFW открывает нужный диапазон
sudo ufw status verbose | grep -E '16384|443|80'

# если диапазон не открыт
sudo ufw allow 16384:32768/udp
sudo ufw allow 443/tcp
sudo ufw allow 80/tcp

Если с настройкой самого UFW есть путаница — общие грабли разобраны в статье про firewall UFW на сервере.

Второй момент — рассинхронизация времени на сервере. WebRTC-хендшейк чувствителен к времени, и если NTP не синхронизирован (что нередко бывает на свежих VPS сразу после установки ОС), клиенты будут получать таймауты при подключении медиа:

timedatectl status
sudo apt install -y chrony
sudo systemctl enable --now chrony

Отдельно стоит проверить журнал coturn — если участники массово не могут подключить звук, но интерфейс работает, почти всегда проблема именно там:

sudo journalctl -u coturn -n 100 --no-pager

Конференция тормозит и зависает при росте числа участников

BBB неплохо масштабируется по CPU, но упирается в ресурсы резче, чем веб-приложения — при 25-30 одновременных видеопотоках на одном сервере среднего размера уже возможны просадки. Это ориентир, а не гарантированное число: сильно зависит от того, сколько участников включают камеру одновременно, разрешения видео и того, идёт ли параллельно запись.

Официальная утилита для проверки состояния сервера:

sudo bbb-conf --check
sudo bbb-conf --network

Она показывает загрузку CPU/RAM, статус всех systemd-сервисов BBB, доступность портов и открытые конференции. Если bbb-conf --check регулярно жалуется на нехватку памяти или высокий load average — это сигнал не оптимизировать конфиг, а увеличивать ресурсы сервера: для BBB куда важнее число vCPU и стабильность сети, чем объём диска.

Практический ориентир по сайзингу (именно ориентир, не точная формула — проверяйте на своей нагрузке):

Если сервер регулярно упирается в потолок, следующий шаг — не апгрейд той же машины «до бесконечности», а Scalelite: официальный балансировщик BBB, который распределяет конференции по нескольким серверам-нодам. Разворачивать его стоит только когда один сервер уже стабильно не справляется — для одной школы или курса это обычно избыточно.

Записи не обрабатываются или занимают весь диск

Запись занятия проходит через несколько этапов обработки (bbb-rap), прежде чем попадёт в архив Greenlight. Если процесс «зависает» на статусе processing — почти всегда причина одна из двух:

Не хватает места на диске. BBB хранит сырые записи, промежуточные файлы обработки и готовые видео одновременно, пока идёт конвейер — на пике места нужно заметно больше, чем весит финальная запись.

df -h /var/bigbluebutton
du -sh /var/bigbluebutton/recording/raw/* | sort -rh | head -10

Зависший процесс обработки. Проверяется через systemd-таймеры BBB:

sudo systemctl status bbb-rap-caption-inbox
sudo journalctl -u bbb-rap-resque-worker -n 50 --no-pager
sudo systemctl restart bbb-rap-resque-worker

Если диск регулярно забивается старыми записями — стоит настроить автоочистку по возрасту через cron или переносить архивы на отдельное S3-совместимое хранилище: держать их вечно на системном диске сервера — плохая практика, диск рано или поздно закончится в самый неподходящий момент, посреди семестра.

Частые вопросы