Масштабований хостинг BigBlueButton пояснено: від одного сервера до інтелектуальних кластерів

Глибокий огляд інфраструктури відеоконференцій: розуміння переходу від монолітних серверів до самовідновлюваних кластерів із високою доступністю.


BigBlueButton утвердився як провідне рішення з відкритим кодом для віртуальних класів і конференцій. Проте зі зростанням організацій вони неминуче впираються у «стелю продуктивності». Питання змінюється з «Як це встановити?» на «Як стабільно обслуговувати 2000 одночасних користувачів?».

Масштабування BigBlueButton — це не лише додавання більшої потужності CPU одній машині (вертикальне масштабування); воно вимагає фундаментальної зміни архітектури (горизонтальне масштабування). Нижче ми пояснюємо три етапи еволюції хостингу.

01

Односерверна конфігурація

У стандартній «монолітній» інсталяції кожен компонент розміщується на одній фізичній або віртуальній машині. Це включає клієнт HTML5, медіасервер Kurento/MediaSoup, Redis і базу даних дошки.

Аналогія: невелике кафе

Уявіть один сервер як сусідське кафе з одним баристою. Воно ідеально працює для 50–200 відвідувачів. Обслуговування швидке й пряме. Але якщо одночасно спробують зайти 500 людей, черга тягнутиметься за двері, замовлення плутатимуться, і система різко сповільниться.

Технічне вузьке місце: Node.js, на якому працює HTML5‑клієнт BigBlueButton, є однопотоковим. Навіть якщо у вас сервер із 64 ядрами, одна зустріч із надто великою кількістю користувачів може наситити головний потік, спричиняючи затримки для всіх. Зазвичай практична межа — 200–300 одночасних користувачів на сервер.
02

Кластер з відкритим кодом: Scalelite

Щоб обійти обмеження одного сервера, спільнота розробила Scalelite. Scalelite — це балансувальник навантаження, який знаходиться між вашим фронтендом (Moodle/Greenlight) та пулом серверів BigBlueButton.

Як працює Scalelite

Scalelite покладається на складний стек, що включає базу даних PostgreSQL для відстеження зустрічей і Redis для кешування. Він періодично опитує зареєстровані сервери, перевіряючи їхнє навантаження на CPU та кількість користувачів. Коли надходить запит на нову зустріч, Scalelite скеровує її на найменш завантажений сервер.

  • Горизонтальне масштабування: Теоретично ви можете додати до пулу необмежену кількість серверів.
  • Кошмар із записами: Найбільший головний біль із Scalelite — це керування записами. Оскільки зустрічі розкидані по різних серверах, потрібно налаштовувати складні спільні сховища (NFS або S3) для агрегування записів. Якщо сервер відмовить до того, як запис буде передано, дані часто втрачаються.
Аналогія: адміністратор готелю

Scalelite працює як адміністратор готелю. Гості підходять до стійки, і адміністратор призначає їм номер (сервер). Проте відстеження «знахідок і втрат» (тобто записів) зі сотень різних номерів стає серйозною логістичною проблемою.

Обмеження: Scalelite змінює запити API перед переданням їх на сервери. Це часто порушує сумісність із певними інтеграціями сторонніх розробників, які очікують прямого з’єднання зі стандартним API BigBlueButton.
03
Рекомендоване рішення

Наступний рівень: інтелектуальне балансування bbbserver

У bbbserver ми усвідомили обмеження стандартних інсталяцій Scalelite. Ми побудували власну архітектуру балансування навантаження, розроблену для максимальної стабільності, чистоти та прозорості.

Вирішено: збирання записів

Ми повністю усунули проблему «зниклих записів», що трапляється у стандартних кластерах. Наша система автоматично збирає, обробляє та централізує записи з усіх вузлів без необхідності в крихких монтуваннях NFS. Ви отримуєте єдине надійне сховище для всіх своїх даних.

24‑годинний цикл перевстановлення

Сервери BigBlueButton з часом накопичують «цифровий пил» — тимчасові файли та витоки пам’яті. Наш унікальний протокол «Свіжий старт» автоматично ізолює сервери, переводить їх у режим обслуговування та повністю перевстановлює ПЗ кожні 24 години. Фактично ви щодня отримуєте абсолютно новий сервер.

100% сумісність з API

На відміну від Scalelite, який може маскувати функції API, наш інтелектуальний балансувальник забезпечує 100% наскрізну сумісність. Чи використовуєте ви власний плагін Moodle, корпоративну LMS або спеціалізований скрипт — усе працюватиме так, ніби під’єднано до одного сервера.

Самовідновлювана інфраструктура

Якщо вузол повідомляє про помилку Kurento або затримки звуку, наша система миттєво ізолює його, переводить у режим обслуговування та розгортає заміну за лічені хвилини. Жодного ручного втручання не потрібно.

Аналогія: розкішний курорт, що самоочищається

Уявіть курорт, де після від’їзду кожного гостя номер не просто прибирають — його повністю оновлюють. Консьєрж (наш балансувальник навантаження) також стежить, щоб увесь багаж гостей (записи) автоматично доправляли до центрального лобі, тож у номерах нічого не залишається.

Поширені запитання щодо масштабування

Перезавантаження очищає оперативну пам’ять (RAM), але не виправляє дрейф конфігурації, пошкоджені тимчасові файли або змінені залежності пакетів. Повне перевстановлення гарантує, що програмний стек ідентичний нашому «Golden Image», усуваючи 99% «випадкових» помилок.

Ні. На відміну від самостійно розгорнутих інсталяцій Scalelite, де потрібно керувати монтуваннями NFS і скриптами передавання, bbbserver бере на себе весь життєвий цикл. Ми збираємо сирі дані, обробляємо запис і безшовно надаємо його вам.

Звісно. Оскільки наша система на 100% сумісна з API, міграція зазвичай зводиться до зміни «Base URL» і «Secret» у вашій LMS або фронтенд-застосунку.

Відчуйте стабільність «свіжого» сервера

Припиніть перейматися конфігураціями балансування навантаження, синхронізацією баз даних і конфліктами API. Перейдіть на bbbserver, щоб отримати кероване, самовідновне кластерне середовище.

Переглянути плани та ціни