Dodanie serwerów Jitsi Videobridge (JVB) to standardowy sposób na zwiększenie przepustowości multimediów dla jednego wdrożenia Jitsi Meet. Zachowaj usługi internetowe, Prosody i Jicofo na istniejącym hoście Meet, a następnie dodaj niezależne maszyny mostowe, które zarejestrują się w tej samej sali odnajdywania mostów Prosody. Jicofo może następnie umieszczać nowe konferencje na dostępnym moście. W tym podstawowym projekcie uczestnicy konferencji korzystają z jednego wybranego mostu; nie potrzebujesz Octo tylko dlatego, że wdrożenie obejmuje kilka serwerów JVB.
Ten przewodnik jest zgodny z opisem konfiguracji skalowalnej opartej na pakietach Debian/Ubuntu z podręcznika Jitsi Handbook, sprawdzonej 6 października 2026 r. Dokładne zależności pakietów i wygenerowana konfiguracja mogą się różnić w zależności od dystrybucji, wersji pakietu Jitsi oraz od tego, czy serwer został zainstalowany za pomocą Dockera, czy inną metodą. Skorzystaj z oficjalnego przewodnika instalacji dla swojego obecnego wdrożenia.
Zweryfikowano: Pojedyncza instalacja Jitsi Meet może korzystać z wielu mostów wideo. Jicofo monitoruje mosty i przypisuje do nich nową konferencję. Uproszczony przykład z podręcznika Jitsi umieszcza usługi Meet na jednym serwerze, a trzy mosty JVB na oddzielnych serwerach. Każdy most musi być dostępny dla uczestników spotkania w celu obsługi multimediów oraz dla infrastruktury Meet w celu sygnalizacji.
Powszechne nieporozumienie: „Potrzebuję modułu równoważenia obciążenia przed mostami JVB”. W udokumentowanym projekcie wielomostowym, Jicofo wybiera most; klienci następnie wysyłają media do tego mostu. Ogólny moduł równoważenia obciążenia HTTP przed mediami UDP nie zastępuje wykrywania mostów ani nawiązywania konferencji. Działanie: Dodaj każdy JVB do puli mostów Prosody/Jicofo i opublikuj jego osiągalny adres medialny. Nie kieruj ruchu medialnego każdego mostu do jednego dowolnego adresu VIP UDP.
Powszechne błędne przekonanie: „Większa liczba mostów automatycznie obejmuje wszystkie serwery, a jedno spotkanie obejmuje wszystkie serwery”. W podstawowej konfiguracji Jicofo przypisuje konferencję do mostu. Rozproszenie uczestników z jednej konferencji między regionami lub mostami to osobna topologia przekaźników zwana Octo (bezpieczne przekaźniki w aktualnej dokumentacji JVB). Działanie: Zacznij od zwykłego grupowania mostów, jeśli chcesz obsługiwać więcej jednoczesnych spotkań; rozważ Octo tylko wtedy, gdy jedna konferencja musi korzystać z mostów w wielu lokalizacjach lub potrzebujesz takiego zachowania przekaźników.
Wybierz jedną publiczną, stabilną nazwę hosta lub adres dla każdego JVB. Nadaj każdej maszynie wirtualnej unikalny identyfikator systemu operacyjnego i unikalny pseudonim instancji JVB, gdy konfiguracja korzysta z obecności XMPP MUC. Wszystkie mosty powinny mieć dostęp do tej samej usługi Prosody i pomieszczenia, w którym znajduje się browar. Zachowaj zgodność wersji: Jicofo nie będzie mieszać mostów o różnych wersjach w tej samej konferencji, a aktualna dokumentacja przekaźnika powtarza to ograniczenie dla Octo.
| Ścieżka | Użyj tego, kiedy | Co dodaje |
|---|---|---|
| Wiele JVB, jeden region | Potrzebujesz większej pojemności na potrzeby równoległych spotkań. | Instalacja mostu, rejestracja, dostęp do sieci i walidacja. |
| Sztafety Octo między regionami | Aby konferencja mogła się odbyć, potrzebni są uczestnicy lub media pośredniczące w więcej niż jednym regionie. | Ustawienia tożsamości i regionu przekaźnika, łączność Colibri WebSocket, strategia Jicofo i prawidłowe informacje o regionie klienta. |
Zależy od środowiska: Nie ma uniwersalnej liczby uczestników na maszynę wirtualną. Własna dokumentacja wymagań Jitsi kładzie nacisk na przepustowość sieci i obciążenie, a nie na pojedynczą, stałą liczbę. Kodek, rozdzielczość, transmisja symultaniczna, przepływność pakietów, konferencje równoczesne i przepustowość dostawcy – wszystkie te czynniki wpływają na przepustowość. Działanie: Ustal punkt odniesienia dla rzeczywistego obciążenia, a następnie dodawaj po jednym moście i obserwuj moc obliczeniową procesora, przepustowość sieci, utratę pakietów i jakość konferencji.
Przed dodaniem maszyn sprawdź, czy istniejąca strona Meet się ładuje, Prosody i Jicofo działają, a połączenie testowe kończy się przez bieżący most. Zapisz wersje pakietów Jitsi. Nieprawidłowa konfiguracja sygnalizacji lub certyfikatu na serwerze głównym sprawi, że nowy most będzie wyglądał na źle skonfigurowany, nawet gdy jego sieć działa prawidłowo.
Podczas instalacji pakietu Debian/Ubuntu, sprawdź usługi za pomocą funkcji inspekcji systemctl status prosody jicofo jitsi-videobridge2i przejrzyj logi usług. Użyj nazw usług obecnych w instalacji; wdrożenia kontenerowe udostępniają różne polecenia i lokalizacje logów.
Nadaj każdemu mostowi własny adres publiczny lub poprawnie skonfigurowane mapowanie NAT typu jeden do jednego. Przewodnik po skalowalnej konfiguracji zawiera listę typowych ścieżek: klienci publiczni docierają do hosta internetowego przez TCP 80/443; serwery JVB docierają do Prosody przez TCP 5222; a klienci docierają do każdego mostu wideo przez UDP 10000 w celu uzyskania multimediów. Protokół TCP 80 jest zazwyczaj używany do konfiguracji certyfikatów lub przekierowań, natomiast produkcyjna witryna Meet powinna korzystać z protokołu HTTPS.
Zależy to od sieci: NAT, grupy zabezpieczeń w chmurze, IPv6, TURN i restrykcyjne sieci korporacyjne mogą wymagać dodatkowych kandydatów lub ścieżek. Domyślna lista portów nie stanowi dowodu na to, że media działają przez daną zaporę sieciową. Działanie: Sprawdź przepływ pakietów do każdego publicznego adresu mostu z zewnętrznej sieci klienckiej i przetestuj rzeczywiste połączenie; samo udane połączenie XMPP nie weryfikuje mediów UDP.
Użyj repozytorium Jitsi i instrukcji dotyczących pakietów, które odpowiadają dystrybucji hosta Meet. Na każdym nowym węźle Debian/Ubuntu zainstaluj jitsi-videobridge2i odpowiedz na monity konfiguracji pakietu, podając nazwę hosta Meet, zgodnie z oficjalną konfiguracją skalowalną. W podręczniku podano, że w przypadku udokumentowanej konfiguracji opartej na pakietach, most nie wymaga żadnych dodatkowych zmian poza domyślną konfiguracją po instalacji.
Nie instaluj pełnego drugiego stosu Jitsi Meet na każdym moście, chyba że celowo chcesz niezależnych wdrożeń Meet. W przypadku puli mostów zachowaj role web, Prosody i Jicofo na hoście głównym i dodaj usługi JVB do pozostałych maszyn. Używaj tej samej obsługiwanej wersji JVB w całej puli; przeprowadzaj aktualizacje etapami, aby nie pozostawiać puli wersji mieszanych dłużej niż to konieczne.
W konfiguracji opartej na pakiecie, najpierw pozwól, aby oficjalna konfiguracja pakietu wygenerowała oczekiwane ustawienia. JVB muszą połączyć się z Prosody i ogłosić obecność mostu do tego samego MUC browaru, który monitoruje Jicofo. Jeśli korzystasz z bieżącej ścieżki konfiguracji klienta XMPP, dokumentacja JVB zawiera odpowiednie elementy w videobridge.statsi videobridge.apis.xmpp-client.configs; Jicofo musi połączyć się z odpowiednim browarem za pomocą jicofo.bridge.brewery-jid.
Typowa nowoczesna konfiguracja ma taki kształt; zastąp wszystkie przykładowe wartości wartościami ze swojej instalacji i chroń współdzielony sekret:
videobridge {
stats {
enabled = true
transports = [{ type = "muc" }]
}
apis {
xmpp-client {
configs {
xmpp-server-1 {
hostname = "meet.example.com"
domain = "auth.meet.example.com"
username = "jvb"
password = "REPLACE_WITH_SECRET"
muc_jids = "JvbBrewery@internal.auth.meet.example.com"
muc_nickname = "bridge-01"
}
}
}
}
}Użyj innego muc_nicknamedla każdego mostu (na przykład, bridge-02i bridge-03). Projekt JVB ostrzega, że pseudonimy muszą być unikalne w różnych instancjach. Dokładna nazwa pliku konfiguracyjnego i to, czy ten jawny blok jest potrzebny, zależą od pakietu i istniejącej konfiguracji; unikaj nakładania ręcznie napisanej, nowoczesnej konfiguracji na wygenerowane ustawienia starszego pakietu bez sprawdzenia dokumentacji zainstalowanej wersji.
Zrestartuj lub uruchom JVB na każdym nowym hoście, a następnie sprawdź, czy pozostaje aktywny i łączy się z Prosody. Przewodnik po konfiguracji skalowalnej zaleca sprawdzenie logów Prosody i Jicofo w celu potwierdzenia połączeń mostów i ich wykrycia przez Jicofo. Jeśli żaden z nich się nie pojawi, sprawdź w następującej kolejności: rozpoznawanie nazw DNS i dostępność TCP 5222; dane uwierzytelniające XMPP i domenę; dokładną pisownię nazwy browaru MUC; zduplikowany pseudonim; a następnie zgodność wersji JVB/Jicofo.
Rozpocznij kilka nowych spotkań testowych i sprawdź, czy Jicofo umieszcza je w dostępnej puli w miarę upływu czasu. Oczekuje się, że jedno spotkanie trafi na jeden most; nie oznacza to, że równoważenie nie powiodło się. Użyj interfejsu debugowania Jicofo, jeśli jest włączony i ma ograniczony dostęp, aby sprawdzić dostępne mosty i aktywne konferencje. Dokumentacja JVB podaje curl http://localhost:8888/debugprzykład lokalnego debugowania; powiąż interfejsy diagnostyczne lub zapory sieciowej, aby zachować ich prywatność.
Przetestuj z klientami spoza sieci serwera. Upewnij się, że dźwięk i obraz działają, a następnie sprawdź wybrany adres mostu i przepływ UDP. Jeśli most pojawia się w Jicofo, ale połączenia kończą się niepowodzeniem tylko po jego wybraniu, sprawdź jego adres publiczny, mapowanie NAT, zaporę UDP i rozgłaszanych kandydatów. Wyłącz jeden most z rotacji podczas konserwacji tylko za pomocą obsługiwanej procedury opróżniania lub wdrażania dla zainstalowanej wersji; ponowne uruchomienie aktywnego mostu może przerwać przypisane do niego spotkania.
Octo to właściwy temat, gdy pojedyncza konferencja powinna korzystać z wielu mostów, często ze względu na rozproszenie uczestników w różnych regionach. Nie jest to warunek konieczny do dodawania JVB w celu zapewnienia standardowej przepustowości. Aktualna dokumentacja przekaźników JVB wymaga konfiguracji przekaźników na każdym uczestniczącym moście, Colibri WebSockets dla połączeń między mostami oraz odpowiedniej strategii wyboru mostu Jicofo. Działanie uwzględniające regiony zależy również od podania dokładnych informacji o regionie klienta w obsługiwanej konfiguracji Meet.
Konfiguracja przekaźnika obejmuje unikatowy adres relay-idi region dla każdego mostu, podczas gdy Jicofo włącza Octo i wybiera strategię, taką jak RegionBasedBridgeSelectionStrategy. Punkty końcowe WebSocket przekaźnika również muszą być poprawnie kierowane przez dowolny serwer proxy. Ustawienia te zmieniają się w zależności od wersji i topologii, dlatego należy postępować zgodnie z aktualnym przewodnikiem dotyczącym przekaźnika i zweryfikować dokładne ścieżki proxy przed wdrożeniem.
Działanie: Pozostaw Octo wyłączone dla prostej puli mostów jednoregionowych. Jeśli wymagane jest wiele regionów, przetestuj udokumentowaną strategię podziału w środowisku przejściowym, sprawdź selektor mostu Jicofo i stan konferencji, a następnie skonfiguruj regiony klientów i wybór oparty na regionach. Nie ustawiaj etykiet regionów, dopóki nie będziesz wiedzieć, jak klienci będą odbierać pasujące metadane regionu.
Jeśli użytkownicy zgłaszają problemy tylko z jednym JVB, należy porównać ścieżkę sieciową i konfigurację tego węzła z działającym węzłem, zanim rozszerzy się cały klaster. Jeśli wszystkie mosty ulegną degradacji jednocześnie, wąskim gardłem może być współdzielona przepustowość, usługi sygnalizacji rdzeniowej lub sieć uczestników. Skalowanie działa, gdy nowe mosty są niezależnie osiągalne, poprawnie zarejestrowane i mierzalnie zmniejszają obciążenie podczas realistycznych testów.
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.
