Skalowalny hosting BigBlueButton: od pojedynczego serwera do inteligentnych klastrów

Dogłębne spojrzenie na infrastrukturę wideokonferencji: zrozumienie przejścia od serwerów monolitycznych do samonaprawiających się klastrów o wysokiej dostępności.


BigBlueButton ugruntował pozycję wiodącego rozwiązania open source dla wirtualnych klas i konferencji. Jednak w miarę rozwoju organizacji nieuchronnie napotyka się „ścianę wydajności”. Pytanie zmienia się z „Jak to zainstalować?” na „Jak stabilnie obsłużyć 2 000 jednoczesnych użytkowników?”

Skalowanie BigBlueButton to nie tylko dokładanie mocy CPU do jednej maszyny (skalowanie pionowe); wymaga to zasadniczej zmiany architektury (skalowanie poziome). Poniżej wyjaśniamy trzy etapy ewolucji hostingu.

01

Konfiguracja pojedynczego serwera

W standardowej instalacji „monolitycznej” każdy komponent działa na jednej fizycznej lub wirtualnej maszynie. Obejmuje to klienta HTML5, serwer multimediów Kurento/MediaSoup, Redis oraz bazę danych tablicy.

Analogia: mała kawiarnia

Pomyśl o pojedynczym serwerze jak o osiedlowej kawiarni z jednym baristą. Działa świetnie dla 50–200 klientów. Obsługa jest szybka i bezpośrednia. Jednak gdy naraz próbuje wejść 500 osób, kolejka wychodzi na zewnątrz, zamówienia się mieszają, a system zaczyna się wlec.

Wąskie gardło techniczne: Node.js, który napędza klienta HTML5 BigBlueButton, jest jednowątkowy. Nawet jeśli masz serwer 64‑rdzeniowy, jedno zbyt liczne spotkanie może nasycić główny wątek, powodując opóźnienia u wszystkich. Zwykle praktyczny limit to 200–300 jednoczesnych użytkowników na serwer.
02

Klaster open source: Scalelite

Aby obejść ograniczenie pojedynczego serwera, społeczność opracowała „Scalelite”. Scalelite to load balancer, który znajduje się między frontendem (Moodle/Greenlight) a pulą serwerów BigBlueButton.

Jak działa Scalelite

Scalelite opiera się na złożonym stosie, wykorzystując bazę PostgreSQL do śledzenia spotkań i Redis do buforowania. Regularnie odpytuje zarejestrowane serwery, aby sprawdzać ich obciążenie CPU i liczbę użytkowników. Gdy pojawia się nowe żądanie spotkania, Scalelite kieruje je na najmniej obciążony serwer.

  • Skalowanie poziome: Teoretycznie możesz dodać do puli nieskończenie wiele serwerów.
  • Koszmar nagrań: Dużym problemem Scalelite jest zarządzanie nagraniami. Ponieważ spotkania są rozproszone na różnych serwerach, trzeba skonfigurować złożone współdzielone systemy przechowywania (NFS lub S3), aby agregować nagrania. Jeśli serwer ulegnie awarii, zanim nagranie zostanie przeniesione, dane często przepadają.
Analogia: recepcjonista hotelowy

Scalelite działa jak recepcjonista hotelowy. Goście przychodzą do recepcji, a recepcjonista przydziela im pokój (serwer). Jednak śledzenie „rzeczy znalezionych” (nagrań) ze setek różnych pokoi staje się logistycznym wyzwaniem.

Ograniczenie: Scalelite modyfikuje żądania API przed przekazaniem ich do serwerów. To często psuje kompatybilność z określonymi integracjami firm trzecich, które oczekują bezpośredniego połączenia ze standardowym API BigBlueButton.
03
Rekomendowane rozwiązanie

Kolejny poziom: bbbserver Intelligent Balancing

W bbbserver rozpoznaliśmy ograniczenia standardowych wdrożeń Scalelite. Zbudowaliśmy zastrzeżoną architekturę równoważenia obciążenia zaprojektowaną z myślą o maksymalnej stabilności, higienie i przejrzystości.

Rozwiązane: zbieranie nagrań

Całkowicie wyeliminowaliśmy problem „zaginionych nagrań” występujący w standardowych klastrach. Nasz system automatycznie zbiera, przetwarza i centralizuje nagrania ze wszystkich węzłów bez konieczności stosowania podatnych na awarie montowań NFS. Otrzymujesz pojedyncze, niezawodne repozytorium wszystkich swoich danych.

24‑godzinny cykl reinstalacji

Serwery BigBlueButton z czasem gromadzą „cyfrowy kurz” — pliki tymczasowe i wycieki pamięci. Nasz unikalny protokół „Fresh Start” automatycznie opróżnia serwery i co 24 godziny przeprowadza pełną reinstalację oprogramowania. W praktyce każdego dnia otrzymujesz zupełnie nowy serwer.

100% zgodność z API

W odróżnieniu od Scalelite, które może maskować funkcje API, nasz inteligentny balanser oferuje 100% zgodność typu pass-through. Niezależnie od tego, czy używasz niestandardowej wtyczki Moodle, firmowego LMS, czy wyspecjalizowanego skryptu — wszystko działa dokładnie tak, jak przy połączeniu z pojedynczym serwerem.

Samonaprawiająca się infrastruktura

Jeśli węzeł zgłosi błąd Kurento lub opóźnienia dźwięku, nasz system natychmiast go izoluje, przełącza w tryb konserwacji i w ciągu kilku minut uruchamia jego zamiennik. Nie jest wymagana żadna ręczna interwencja.

Analogia: samoczyszczący się luksusowy kurort

Wyobraź sobie ośrodek, w którym po wyjeździe każdego gościa pokój nie tylko jest sprzątany — jest całkowicie odnowiony. Konsjerż (nasz Load Balancer) również dba o to, aby cały bagaż gości (nagrania) był automatycznie przenoszony do głównego lobby, tak aby w pokojach nigdy nic nie zostawało.

Najczęściej zadawane pytania dotyczące skalowania

Ponowne uruchomienie czyści pamięć (RAM), ale nie naprawia odchyleń konfiguracji, uszkodzonych plików tymczasowych ani zaktualizowanych zależności pakietów. Pełna reinstalacja zapewnia, że stos oprogramowania jest identyczny z naszym „Golden Image”, eliminując 99% „losowych” błędów.

Nie. W przeciwieństwie do samodzielnie hostowanych wdrożeń Scalelite, gdzie trzeba zarządzać punktami montowania NFS i skryptami przesyłania, bbbserver obsługuje cały cykl życia. Zbieramy dane surowe, przetwarzamy nagranie i dostarczamy je bezproblemowo.

Jak najbardziej. Ponieważ nasz system jest w 100% zgodny z API, migracja zwykle sprowadza się do zmiany „Base URL” i „Secret” w twoim LMS lub aplikacji frontendowej.

Poznaj stabilność „świeżego” serwera

Przestań martwić się konfiguracją równoważenia obciążenia, synchronizacją baz danych i konfliktami API. Przejdź na bbbserver, aby korzystać z zarządzanego, samonaprawiającego się środowiska klastrowego.

Zobacz plany i ceny