Requisitos do servidor BigBlueButton: um guia prático de dimensionamento para 500 usuários simultâneos.

Exemplo de cenário: Imagine uma faculdade comunitária fictícia que espera 500 pessoas online simultaneamente, distribuídas em cinco turmas de aproximadamente 100 participantes cada. Este é um exemplo de planejamento, não um benchmark, um caso de sucesso ou um resultado de teste. A principal decisão de projeto é dimensionar a infraestrutura para múltiplas reuniões distribuídas em vários servidores; uma única reunião com 500 pessoas apresenta um perfil de risco diferente.

Quais são os requisitos oficiais do BigBlueButton?

O guia de instalação atual do BigBlueButton lista os requisitos mínimos de produção para um servidor dedicado: Ubuntu 22.04 de 64 bits, 8 núcleos de CPU com alto desempenho em single-thread, 16 GB de memória com swap habilitado e largura de banda simétrica de 250 Mbit/s ou superior. Recomenda-se pelo menos 500 GB de espaço livre em disco quando as gravações são mantidas, ou 50 GB se a gravação estiver desabilitada. O guia também exige as portas TCP públicas 80 e 443, as portas UDP 16384–32768, um nome de host e um certificado SSL válido, além de suporte a IPv4 e IPv6. Esses são os requisitos mínimos de instalação para um servidor; eles não garantem capacidade para uma determinada configuração de reunião. Consulte a página de instalação da versão que você pretende implantar, pois os requisitos de sistema operacional e pacotes podem mudar.

Historicamente, as perguntas frequentes do projeto descrevem cerca de 200 usuários simultâneos como uma regra geral para um servidor que atenda aos requisitos mínimos. Essa é uma referência aproximada para planejamento, não uma garantia de nível de serviço ou um limite universal por nó. O próprio BigBlueButton alerta que o uso de CPU, memória, largura de banda, webcam e compartilhamento de tela, a configuração e a versão do software do servidor podem alterar o resultado. Considere o número de 200 usuários como uma hipótese inicial que sua própria carga de trabalho deve validar.

Um ponto de partida prático para 500 usuários simultâneos.

Para a faculdade fictícia, uma arquitetura inicial razoável para avaliação é um cluster BigBlueButton de quatro nós, com cada nó de mídia atendendo ou excedendo o mínimo de produção atual e utilizando CPU dedicada de alta frequência. Com 500 participantes distribuídos uniformemente, isso resulta em uma média de 125 participantes por nó. O quarto nó adiciona margem para alocação desigual de reuniões e planejamento de manutenção; ele não oferece proteção automática para uma reunião já em andamento em um servidor com falha.

A recomendação de quatro nós é um ponto de partida de engenharia inferido da configuração mínima oficial e da antiga regra prática de 200 usuários. A BigBlueButton não publica uma especificação universal que certifique quatro servidores específicos para cada carga de trabalho de 500 usuários. Por exemplo, se um servidor estiver indisponível, os outros três suportariam, em média, cerca de 167 dos 500 usuários, somente se as reuniões puderem ser reatribuídas ou os usuários se reconectarem e os servidores restantes permanecerem dentro de seus limites testados. Uma reunião ativa em um nó perdido não migra automaticamente para outro nó. Se o tempo de atividade durante a falha de um nó for imprescindível, teste o procedimento de recuperação e considere capacidade adicional além deste modelo simplificado.

Por que cinco turmas de 100 pessoas são diferentes de uma reunião de 500 pessoas?

Os clusters do BigBlueButton distribuem as reuniões entre servidores. Eles não combinam vários nós em um único processador de mídia compartilhado para uma única reunião. Cinco turmas de 100 participantes podem ser distribuídas como reuniões completas em quatro servidores, mas uma única turma de 500 participantes ainda seria executada em um único servidor BigBlueButton. O FAQ do projeto recomenda não tratar uma única reunião com mais de 200 usuários como um uso comum. Se a necessidade for uma audiência de 500 pessoas, valide esse projeto específico com a equipe do BigBlueButton ou um fornecedor qualificado; considere se o evento pode ser dividido em salas interativas menores ou transmitido como uma transmissão separada com interação limitada dos participantes.

A composição da turma fictícia também importa. Se a maioria dos alunos ouvir o áudio e assistir aos slides, enquanto apenas os instrutores compartilharem webcams, a carga de mídia pode ser muito menor do que em uma reunião onde muitos participantes compartilham suas câmeras e telas. Em suas perguntas frequentes, o BigBlueButton fornece exemplos de taxas de bits para webcams por resolução e uma maneira de estimar a entrada e saída de dados do servidor a partir do número de webcams e espectadores. Use esse modelo para criar uma estimativa inicial de largura de banda, mas inclua áudio, sinalização, compartilhamento de tela, retransmissões e sobrecarga de protocolo. Não multiplique 500 por uma taxa de bits estimada e considere o resultado como um plano de capacidade.

Rede, salas e gravações a serem incluídas no projeto.

Dê ao tráfego de mídia um caminho direto.

Utilize um design de rede que permita que os clientes do navegador acessem cada nó de mídia atribuído através das portas TCP e UDP necessárias. A documentação do cluster-proxy do BigBlueButton explica que os fluxos de mídia e as conexões WebSocket são trocados diretamente com o servidor que hospeda a conferência; o proxy comum retransmite principalmente a interface do cliente e os recursos web relacionados. Um proxy reverso que, acidentalmente, direcione toda a mídia através de um único gateway pequeno pode se tornar o gargalo. Confirme as regras de firewall, o endereçamento público, o DNS, os certificados e a largura de banda em ambas as direções antes do teste de carga.

O tamanho do armazenamento de gravações se baseia na retenção, não na contagem de participantes.

Para o exemplo da faculdade, estime o número e a duração das aulas gravadas por dia e, em seguida, meça o tamanho das gravações representativas da versão e das configurações reais. Multiplique a produção diária esperada pelos dias de retenção e adicione uma margem operacional. A recomendação de 500 GB de espaço livre no guia de instalação é um mínimo inicial, não uma garantia de que uma política de retenção específica seja adequada. Monitore o espaço livre e as filas de processamento de gravações e mova os arquivos arquivados somente por meio de um fluxo de trabalho testado.

Como validar a estimativa antes do lançamento

1. Descreva a carga de trabalho. Registre o número esperado de usuários simultâneos, reuniões, usuários por reunião, editores e visualizadores de webcam, compartilhamentos de tela, uso de áudio, política de gravação, duração da sessão e picos de entrada. Use o exemplo de cinco classes somente se ele se assemelhar ao seu padrão real.
2. Escolha nós equivalentes aos de produção. Certifique-se de que a geração da CPU e o comportamento do clock, a memória, o sistema operacional, o caminho de rede, o armazenamento e a versão do BigBlueButton sejam compatíveis. Instâncias compartilhadas ou com limitação de CPU podem se comportar de maneira diferente de instâncias dedicadas.
3. Teste com cargas escalonadas. Comece com um pequeno grupo e, em seguida, aumente a participação simultânea em etapas, utilizando câmeras, áudio, slides, compartilhamento de tela e gravações realistas. Inclua um período de entrada sincronizada, em vez de apenas uma reunião contínua.
4. Monitore simultaneamente sinais visíveis ao usuário e métricas do servidor. Acompanhe a saturação da CPU e a fila de execução, a pressão da memória e o swap, a taxa de transferência da rede e a perda de pacotes, o espaço em disco e as operações de E/S, as reinicializações de serviços e os sintomas de reuniões, como áudio atrasado ou interrompido, vídeo congelado, compartilhamentos com falha ou loops de reconexão.
5. Repita os testes de pico e recuperação. Mantenha o pico esperado por tempo suficiente para expor a pressão térmica ou de memória e, em seguida, teste o que acontece quando um nó fica indisponível. Verifique se as novas reuniões são encaminhadas para nós íntegros e documente como os usuários afetados se reconectam.
6. Defina um limite operacional seguro. Baseie o limite de usuários simultâneos publicado em testes repetíveis com capacidade ociosa, e não na primeira execução bem-sucedida. Realize novos testes após atualizações de software, alterações na política da webcam, na configuração de gravação ou no hardware de hospedagem.

Em resumo, para uma implementação com 500 usuários, este é o ponto crucial.

Para 500 participantes simultâneos em diversas reuniões comuns, inicie a avaliação com quatro nós de mídia BigBlueButton dedicados, cada um atendendo aos requisitos mínimos oficiais de produção, e um arranjo de cluster robusto e otimizado para reuniões. Reserve uma quantidade generosa de recursos de rede, planeje o armazenamento de gravações com base nas necessidades de retenção estimadas e teste a combinação exata de salas e mídias. Este projeto é uma hipótese de dimensionamento, não uma prova de que qualquer instância em nuvem possa suportar 500 usuários. Uma única sala com 500 pessoas representa uma carga de trabalho diferente e não deve ser inferida a partir do total do cluster.

Referências oficiais

• Requisitos de instalação do BigBlueButton
• Perguntas frequentes sobre o BigBlueButton 2.5: orientações sobre concorrência e variáveis ​​de carga de trabalho
• Perguntas frequentes sobre o BigBlueButton 4.0: orientações sobre largura de banda e exemplos de largura de banda da webcam (a versão 4.0 está marcada como em desenvolvimento na documentação)
• Configuração de proxy de cluster BigBlueButton