BigBlueButton 伺服器需求： 500 個同時使用者的實用容量規劃指南

範例場景：假設有一所虛構的社區大學，預計會有 500 人同時在線上參加五個班級的課程，每個班級大約 100 名學生。這只是一個規劃範例，並非基準測試、客戶案例或測試結果。關鍵的設計選擇在於根據多個會議分佈在多個伺服器上的情況來調整伺服器規模；一次 500 人的大型會議存在不同的風險。

BigBlueButton 官方要求是什麼？

目前的 BigBlueButton 安裝指南列出了專用伺服器的生產級最低配置：Ubuntu 22.04 64 位元作業系統、8 個單執行緒效能高的 CPU 核心、啟用交換空間的 16 GB 記憶體以及 250 Mbit/s 或更高的對稱頻寬。指南要求在保留錄製內容時至少有 500 GB 的可用磁碟空間，如果停用錄製，則至少需要 50 GB。此外，指南還要求提供公共 TCP 連接埠 80 和 443、UDP 連接埠 16384–32768、主機名稱和有效的 SSL 證書，以及 IPv4 和 IPv6 支援。這些是伺服器的最低安裝要求，並不保證能夠滿足特定會議組合的需求。請查看您計劃部署版本的安裝頁面，因為作業系統和軟體包要求可能會變更。

專案常見問題解答中歷來將大約 200 個並髮用戶作為滿足最低要求的伺服器的經驗法則。這只是一個粗略的規劃參考，並非服務等級保證或每個節點的通用限制。 BigBlueButton 本身也提醒用戶，伺服器的 CPU、記憶體、頻寬、相機和螢幕共享的使用情況、配置以及軟體版本都會影響最終結果。請將 200 位使用者視為初始假設，並需依據您自身的工作負載進行驗證。

適用於 500 個同時使用者的實用起點

對於這所虛構的大學而言，一個合理的初始架構評估方案是使用一個四節點的 BigBlueButton 集群，每個媒體節點都達到或超過當前生產環境的最低配置要求，並使用專用的高頻 CPU。假設有 500 位參與者均勻分佈，則平均每個節點可容納 125 位參與者。第四個節點的加入是為了因應會議分佈不均的情況以及便於維護規劃；但它並不能自動保護正在故障伺服器上運行的會議。

四節點配置建議是基於官方最低配置和先前200用戶經驗法則推斷出的工程起點。 BigBlueButton並未發布針對500用戶工作負載的通用規範，即每4台伺服器必須滿足特定需求。例如，如果一台伺服器不可用，只有在會議可以重新分配或用戶重新連接，且剩餘伺服器仍保持在測試限制範圍內的情況下，其他三台伺服器平均只能承載約167個用戶（共500個用戶）。在故障節點上進行的會議不會自動遷移到另一個節點。如果節點故障期間的正常運作時間至關重要，請測試復原流程，並考慮超出此簡單模型的額外容量。

為什麼五個百人班與一個五百人會議不同

BigBlueButton 叢集會將會議分佈在不同的伺服器上。它不會將多個節點合併到一個共享的媒體處理器中來處理單一會議。五個 100 人的班級可以作為完整的會議分佈在四個伺服器上，但一個 500 人的班級仍然會在一個 BigBlueButton 伺服器上運行。此專案的版本化常見問題解答建議不要將 200 多人的單一會議視為常規支援用途。如果確實需要 500 人的單一會議，請務必與 BigBlueButton 團隊或合格的服務提供者確認具體的方案；並考慮是否可以將會議分成更小的互動式會議室，或者作為單獨的直播進行，並限制參與者的互動。

虛擬教室的參與者組成也很重要。如果大多數學生只聽音訊、看投影片，只有教師開啟鏡頭，那麼媒體負載會比許多參與者開啟攝影機和共享螢幕的會議低得多。 BigBlueButton 在其常見問題解答中提供了不同解析度的攝影機位元速率範例，並提供了一種根據開啟攝影機和觀看者的數量來估算伺服器入站和出站流量的方法。使用該模型可以初步估算頻寬，但務必將音訊、信令、螢幕共享、重傳和協定開銷都考慮在內。不要簡單地將 500 乘以一個估計的位元率就稱之為容量規劃。

設計中需包含網路、房間及錄音功能。

為媒體流量提供直接路徑

使用允許瀏覽器用戶端透過所需的 TCP 和 UDP 連接埠存取每個指定媒體節點的網路設計。 BigBlueButton 的叢集代理文件解釋說，媒體流和 WebSocket 連線直接與託管會議的伺服器交換；公共代理主要轉發客戶端介面和相關的 Web 資源。如果反向代理錯誤地將所有媒體都集中到一個小型網關，則可能會成為瓶頸。在進行負載測試之前，請確認防火牆規則、公用位址、DNS、憑證以及雙向頻寬。

記錄儲存規模取決於保留時間，而非與會者人數

以某所大學為例，估算每天錄製課程的數量和時長，然後測量實際發佈版本和設定下具有代表性的錄製檔案的大小。將預期的每日產量乘以保留天數，並加上營運餘裕。安裝指南中建議的 500 GB 可用空間只是一個最低起始值，並不能保證特定的保留策略一定適用。請監控可用空間和錄製處理佇列，並且僅透過經過測試的工作流程來移動歸檔檔案。

如何在發布前驗證估算

1. 描述工作負載。記錄預期並髮用戶數、會議數、每場會議用戶數、攝影機發布者和觀看者數、螢幕共享次數、音訊使用情況、錄製策略、會話持續時間和加入突發情況。僅當五類範例與您的實際模式相似時才使用。
2. 選擇與生產環境相同的節點。確保 CPU 代數和時脈頻率、記憶體、作業系統、網路路徑、儲存以及 BigBlueButton 版本都相符。共用實例或 CPU 限速實例的行為可能與專用計算實例有所不同。
3. 測試分階段負載。先從小組開始，然後逐步增加同時參與人數，同時使用逼真的攝影機、音訊、幻燈片、螢幕共享和錄製功能。設定一個同步加入階段，而不僅僅是穩定的會議狀態。
4. 同時監控使用者可見訊號和伺服器指標。追蹤 CPU 飽和度和運行佇列、記憶體壓力和交換空間、網路吞吐量和丟包率、磁碟空間和 I/O、服務重啟，以及諸如音訊延遲或中斷、視訊卡頓、共享失敗或重連循環等故障症狀。
5. 重複峰值和恢復測試。保持預期峰值足夠長的時間，以暴露熱壓力或記憶體壓力，然後測試當節點不可用時會發生什麼。驗證新會議是否路由到正常節點，並記錄受影響使用者如何重新加入。
6. 設定安全的操作上限。公佈的並髮用戶限制應基於可重複測試且預留充足容量的情況，而不是基於首次成功運行的結果。軟體升級、相機策略變更、錄製配置變更或主機硬體變更後，均應重新測試。

500 用戶部署的最終結論

對於多個普通會議中 500 位同時與會者的情況，評估初期應使用四個專用的 BigBlueButton 媒體節點，每個會議的配置均達到官方生產環境的最低要求，並採用穩健的會議感知集群架構。網路容量預算應預留充足，錄製儲存容量應根據實際保留需求進行規劃，並測試會議室和媒體的具體組合。此設計僅為容量估算假設，並非證明任何給定的雲端實例都能支援 500 位元使用者。單一 500 人會議室的工作負載與叢集總容量不同，不應從叢集總容量推斷。

官方參考資料

• BigBlueButton 安裝要求
• BigBlueButton 2.5 常見問題：並發指南和工作負載變量
• BigBlueButton 4.0 常見問題：頻寬指南和網路攝影機頻寬範例（文件中將 4.0 標記為開發中）
• BigBlueButton 叢集代理配置