Przykładowy scenariusz: Wyobraź sobie fikcyjną uczelnię, która oczekuje jednoczesnego dostępu 500 osób online w pięciu klasach, po około 100 uczestników każda. To przykład planowania, a nie benchmark, historia klienta czy wynik testu. Kluczowym wyborem w projekcie jest skalowanie spotkań rozproszonych na kilku serwerach; jedno bardzo duże spotkanie z udziałem 500 osób ma inny profil ryzyka.
Aktualny podręcznik instalacji BigBlueButton zawiera minimalne wymagania produkcyjne dla serwera dedykowanego: Ubuntu 22.04 64-bit, 8 rdzeni procesora o wysokiej wydajności jednowątkowej, 16 GB pamięci z włączoną funkcją wymiany i przepustowość symetryczną 250 Mb/s lub wyższą. Wymaga co najmniej 500 GB wolnego miejsca na dysku w przypadku przechowywania nagrań lub 50 GB w przypadku wyłączenia nagrywania. Podręcznik wymaga również publicznych portów TCP 80 i 443, portów UDP 16384–32768, nazwy hosta i ważnego certyfikatu SSL oraz obsługi protokołów IPv4 i IPv6. Są to minimalne wymagania instalacyjne serwera; nie obiecują one pojemności dla konkretnego miksu konferencyjnego. Sprawdź stronę instalacyjną wersji, którą planujesz wdrożyć, ponieważ wymagania dotyczące systemu operacyjnego i pakietów mogą ulec zmianie.
W FAQ projektu historycznie określano około 200 jednoczesnych użytkowników jako regułę dla serwera spełniającego minimalne wymagania. Jest to przybliżone odniesienie do planowania, a nie gwarancja poziomu usług ani uniwersalny limit na węzeł. Sam BigBlueButton ostrzega, że procesor serwera, pamięć, przepustowość, korzystanie z kamery internetowej i udostępniania ekranu, konfiguracja i wersja oprogramowania wpływają na wynik. Potraktuj liczbę 200 użytkowników jako wstępną hipotezę, którą musisz zweryfikować we własnym zakresie.
W przypadku fikcyjnej uczelni rozsądną architekturą do wstępnej oceny jest czterowęzłowy klaster BigBlueButton, w którym każdy węzeł medialny spełnia lub przekracza obecne minimalne wymagania produkcyjne i korzysta z dedykowanego procesora o wysokiej częstotliwości. Przy 500 uczestnikach rozłożonych równomiernie, daje to średnio 125 uczestników na węzeł. Czwarty węzeł zapewnia możliwość nierównomiernego rozmieszczenia spotkań i planowania konserwacji; nie stanowi on automatycznej ochrony dla spotkania już trwającego na uszkodzonym serwerze.
| Część | Rozpoczęcie planowania celu | Dlaczego to ważne |
|---|---|---|
| Węzły multimedialne BigBlueButton | 4 dedykowane serwery; każdy z co najmniej 8 mocnymi rdzeniami procesora i 16 GB pamięci RAM | Rozdziela pracę z mediami na żywo i zapewnia więcej miejsca na rozmieszczenie wielu spotkań niż jeden organizator o minimalnej liczbie uczestników. |
| Sieć na węzeł multimedialny | Rozsądnym celem do oceny jest co najmniej 1 Gb/s symetrycznej przepustowości; w kontekście należy zachować oficjalne minimum 250 Mb/s | Dźwięk, kamery internetowe, udostępnianie ekranu i pobieranie danych przez uczestników – wszystkie te funkcje wykorzystują przepustowość sieci. Zmierz rzeczywistą szczytową przepustowość i utratę pakietów. |
| Dysk i nagrania | Co najmniej 500 GB wolnego miejsca na węzeł w przypadku nagrywania lokalnego, zgodnie z instrukcją instalacji; w przeciwnym razie należy spełnić minimalne wymagania dotyczące 50 GB w przypadku nagrywania niestacjonarnego | Wzrost liczby nagrań zależy od czasu trwania, liczby sesji i retencji. Zaplanuj pojemność archiwum osobno. |
| Trasowanie klastra | Obsługiwany skalator lub moduł równoważenia obciążenia obsługujący spotkania, a także przetestowana, wspólna konfiguracja klienta/serwera proxy w razie potrzeby | Nowe spotkania muszą zostać przypisane do węzła, natomiast każde trwające spotkanie pozostaje na przypisanym do niego serwerze. |
Zalecenie czterech węzłów to punkt wyjścia dla inżynierii, wynikający z oficjalnej minimalnej konfiguracji i starszej reguły 200 użytkowników. BigBlueButton nie publikuje uniwersalnej specyfikacji, która certyfikuje cztery konkretne serwery dla każdego obciążenia 500 użytkowników. Na przykład, jeśli jeden serwer jest niedostępny, pozostałe trzy będą obsługiwać średnio około 167 z 500 użytkowników, tylko pod warunkiem, że spotkania zostaną ponownie przypisane lub użytkownicy połączą się ponownie, a pozostałe serwery pozostaną w przetestowanych limitach. Aktywne spotkanie na utraconym węźle nie jest transparentnie migrowane do innego węzła. Jeśli wymagany jest czas sprawności podczas awarii węzła, należy przetestować procedurę odzyskiwania i rozważyć dodatkową pojemność wykraczającą poza ten prosty model.
Klastry BigBlueButton rozdzielają spotkania między serwery. Nie łączą kilku węzłów w jeden współdzielony procesor multimediów dla pojedynczego spotkania. Pięć klas po 100 można rozmieścić jako całe spotkania na czterech serwerach, ale jedna klasa po 500 nadal będzie działać na jednym serwerze BigBlueButton. Wersjonowane FAQ projektu odradza traktowanie pojedynczego spotkania z udziałem ponad 200 użytkowników jak standardowego, obsługiwanego użytkowania. Jeśli wymagana jest jedna publiczność licząca 500 osób, należy zweryfikować ten projekt z zespołem BigBlueButton lub wykwalifikowanym dostawcą; należy rozważyć, czy wydarzenie można podzielić na mniejsze sale interaktywne lub dostarczyć jako osobną transmisję z ograniczoną interakcją uczestników.
Fikcyjny skład klasy również ma znaczenie. Jeśli większość studentów słucha dźwięku i ogląda slajdy, podczas gdy tylko instruktorzy udostępniają kamery internetowe, obciążenie mediów może być znacznie niższe niż podczas spotkania, w którym wielu uczestników udostępnia kamery i ekrany. W swoim FAQ BigBlueButton podaje przykładowe przepływności transmisji danych z kamer internetowych według rozdzielczości oraz sposób szacowania ruchu przychodzącego i wychodzącego z serwera na podstawie liczby publikujących kamer internetowych i widzów. Użyj tego modelu do utworzenia wstępnego oszacowania przepustowości, ale uwzględnij dźwięk, sygnalizację, udostępnianie ekranu, retransmisje i narzut protokołu. Nie mnoż 500 przez jeden oszacowany bitrate i nie nazywaj wyniku planem pojemności.
Należy zastosować projekt sieciowy, który umożliwia klientom przeglądarkowym dostęp do każdego przypisanego węzła multimedialnego za pośrednictwem wymaganych portów TCP i UDP. Dokumentacja serwera proxy klastra BigBlueButton wyjaśnia, że strumienie multimedialne i połączenia WebSocket są wymieniane bezpośrednio z serwerem obsługującym konferencję; wspólny serwer proxy przekazuje głównie interfejs klienta i powiązane zasoby sieciowe. Odwrotny serwer proxy, który przypadkowo kieruje wszystkie media przez jedną małą bramę, może stać się wąskim gardłem. Przed testem obciążeniowym należy potwierdzić reguły zapory sieciowej, adresowanie publiczne, DNS, certyfikaty i przepustowość w obu kierunkach.
Dla przykładowej uczelni oszacuj liczbę i długość nagrywanych zajęć dziennie, a następnie zmierz rozmiar reprezentatywnych nagrań na podstawie rzeczywistego wydania i ustawień. Pomnóż oczekiwaną dzienną wydajność przez liczbę dni retencji i dodaj margines operacyjny. Zalecenie dotyczące 500 GB wolnego miejsca w przewodniku instalacji to minimalne wymagania początkowe, a nie gwarancja, że dana polityka retencji będzie odpowiednia. Monitoruj wolne miejsce i kolejki przetwarzania nagrań oraz przenoś zarchiwizowane pliki wyłącznie za pośrednictwem przetestowanego przepływu pracy.
W przypadku 500 uczestników jednocześnie na kilku zwykłych spotkaniach, rozpocznij ewaluację od czterech dedykowanych węzłów multimedialnych BigBlueButton, z których każdy spełnia oficjalne minimum produkcyjne, oraz solidnego klastra obsługującego spotkania. Zaplanuj hojnie pojemność sieci, zaplanuj miejsce na nagrania na podstawie zmierzonych potrzeb w zakresie retencji i przetestuj dokładny zestaw sal i multimediów. Ten projekt jest hipotezą dotyczącą rozmiaru, a nie dowodem na to, że dana instancja chmury może obsłużyć 500 użytkowników. Pojedyncza sala na 500 osób to osobne obciążenie i nie należy jej wnioskować na podstawie całkowitej liczby użytkowników w klastrze.
Porównaj 10 narzędzi do pingowania, które umożliwiają szybkie wykrywanie sieci LAN, skanowanie międzyplatformowe i zarządzanie adresami IP. Dowiedz się, co narzędzie pingujące może Ci powiedzieć, a czego nie.
Porównaj sześć narzędzi do zarządzania siecią służących do monitorowania wydajności, obejmujących zasięg SNMP, mapowanie, alerty, modele wdrażania i kompromisy kosztów.
Porównaj siedem darmowych i otwartych monitorów pingów — od kompletnych pakietów sieciowych po ukierunkowane sondy opóźnień — i wybierz odpowiedni monitor pod kątem dostępności, utraty pakietów i historii.
Dowiedz się, co oznacza QoS w sieciach, w jaki sposób oznaczenia DSCP i kolejki ruchu nadają priorytet aplikacjom głosowym, wideo i biznesowym oraz czego QoS nie jest w stanie naprawić.
Porównaj niezawodne oprogramowanie serwera SFTP dla systemów Windows i Linux, w tym OpenSSH, Bitvise, SolarWinds i SFTPGo. Znajdź rozwiązanie odpowiednie dla swoich potrzeb w zakresie bezpieczeństwa i transferu plików.
Porównaj siedem narzędzi do zarządzania adresami IP służących do wykrywania podsieci, koordynacji DNS i DHCP, inwentaryzacji sieci i otwartego oprogramowania IPAM.
Porównaj sześć narzędzi do monitorowania systemu Windows Server pod kątem zbierania danych systemu Windows, widoczności aplikacji, modelu wdrażania i licencjonowania, aby znaleźć odpowiednie rozwiązanie.
Porównaj narzędzia do skanowania sieciowego umożliwiające szybkie wykrywanie urządzeń, skanowanie adresów IP na wielu platformach oraz zarządzanie IPAM w przedsiębiorstwie. Znajdziesz tu wskazówki dotyczące dopasowania każdej opcji do swojej sieci.
Zbuduj praktyczny monitoring sieci z przejrzystym zakresem urządzeń, przydatnymi wskaźnikami wydajności, przydatnymi alertami oraz porównaniem SolarWinds NPM, PRTG i OpManager.
Użyj opcji --traceroute programu Nmap, aby mapować przeskoki do autoryzowanego hosta, zrozumieć dane wyjściowe dotyczące przeskoków i czasu RTT oraz rozwiązywać problemy z brakującymi odpowiedziami bez nadmiernego skanowania.
