La mayoría de los que contratan servicios de streaming invierten demasiado en la CPU y no lo suficiente en capacidad de red. En esta guía te explicamos cómo dimensionar un servidor dedicado para streaming basándote en los datos que realmente determinan la calidad del vídeo: núcleos por reproducción, velocidad del puerto en función del número de espectadores simultáneos, aumento del almacenamiento debido a las grabaciones y el momento en el que una CDN debería hacerse cargo de la distribución.
¿Qué es lo primero que debes dimensionar en un servidor de streaming?
La velocidad del puerto. Todo lo demás es negociable.
Un servidor de streaming ejecuta tres tareas con perfiles de recursos totalmente diferentes. La ingesta acepta la señal codificada de tu software de emisión y no cuesta casi nada. La transcodificación recrea esa señal en varios niveles de calidad y consume CPU. La distribución envía los segmentos a los espectadores y consume capacidad de red, que es donde los presupuestos se agotan primero.
Puedes compensar una CPU lenta codificando menos versiones. Puedes compensar los discos de poca capacidad archivando los archivos en un almacenamiento de objetos. No puedes compensar un puerto de red saturado. Una vez que el puerto está lleno, todos los usuarios se quedan en el búfer al mismo tiempo, y la única solución es cambiar de hardware o de plan.
Ese orden marca la estructura del resto de esta guía: primero la red, luego la CPU, después la RAM y, por último, el almacenamiento.
¿Cómo se calcula el ancho de banda para los espectadores simultáneos?
Multiplica el número de espectadores simultáneos por su velocidad de transmisión media y, a continuación, añade un margen de seguridad. Una transmisión en 1080p a 5 Mbps y otra en 720p a 3 Mbps son cifras razonables a la hora de planificar una transmisión adaptativa, en la que la mayoría de los espectadores se sitúan en la parte media de la escala.
| Espectadores simultáneos | Transmisión con una velocidad media de 5 Mbps | Se necesita un puerto realista |
|---|---|---|
| 250 | 1,25 Gbps | 3 Gbps |
| 500 | 2,5 Gbps | 3 Gbps |
| 1,000 | 5 Gbps | De 8 a 10 Gbps |
| 2,500 | 12,5 Gbps | Se necesita una CDN |
| 10,000 | 50 Gbps | Se necesita una CDN |
Hay dos factores que te ayudan a ser realista. La velocidad del puerto es la capacidad nominal de la conexión, no el rendimiento real que vas a medir. La sobrecarga del protocolo, las retransmisiones y las condiciones de la red se llevan una parte, así que calcula que el rendimiento sostenido será de entre el 60 % y el 70 % de la cifra nominal. En segundo lugar, la concurrencia no es lo mismo que el tamaño de la audiencia. Una retransmisión con 4.000 registros y una tasa de asistencia en directo del 35 % alcanza un máximo de unos 1.400 espectadores, no 4.000.
Los servidores de alta capacidad de InMotion vienen con un puerto básico de 3 Gbps y transferencia ilimitada, con capacidad adicional disponible en incrementos de 1 Gbps a 60 $ al mes hasta un máximo de 10 Gbps. El modelo CC-4000 incluye los 10 Gbps completos sin coste adicional. La transferencia ilimitada es tan importante como la velocidad del puerto en este caso, ya que los planes con límite de transferencia convierten una transmisión que sale bien en una factura por exceso de consumo.
¿Cuánta potencia de CPU necesitas para la transcodificación en directo?
Presupuesta por versión, no por canal.
Codificación de software con x264 en el veryfast Este preajuste consume más o menos entre 2 y 4 núcleos por cada renderización a 1080p a 30 fps, dependiendo de la complejidad de la escena. Una escalera de tres niveles (1080p, 720p, 480p) generada a partir de una única fuente de 1080p suele consumir entre 6 y 10 núcleos, una vez que se tienen en cuenta los recursos necesarios para la ingesta y el empaquetado. Si hay dos canales simultáneos, esa cifra se duplica más o menos.
La elección del preset influye más en el resultado que el hardware. La guía de codificación H.264 de FFmpeg explica la disyuntiva: los presets más lentos ofrecen una mayor eficiencia de compresión a costa de un elevado consumo de CPU, lo cual está bien para la codificación bajo demanda, pero es inviable para la retransmisión en directo. La transcodificación en directo tiene un plazo estricto. Si la codificación se retrasa respecto al tiempo real, se pierden fotogramas, y por mucha CPU que añadas después, la grabación ya no se podrá arreglar.
Tres formas de reducir el gasto en CPU antes de comprar más:
- Pasa por el nivel superior. Envía la señal original de 1080p sin modificar y transcodifica solo los niveles inferiores. Con esto ya eliminas la versión más costosa de la carga de trabajo.
- Recorta la escalera. Lo habitual son cuatro peldaños. Tres suelen ser suficientes para un público empresarial que utiliza banda ancha y ordenadores de sobremesa.
- Codifica a 30 fps en lugar de a 60 fps para los vídeos en los que solo se ve a la persona hablando. Los deportes, las partidas y las secuencias con mucho movimiento necesitan una frecuencia de fotogramas más alta. Los seminarios web y las demostraciones de productos no la necesitan.
InMotion no ofrece servidores con GPU, así que la codificación acelerada por hardware no forma parte de esta infraestructura. La codificación por software en los núcleos modernos gestiona sin problemas trabajos de un solo canal y de pocos canales; las secuencias muy largas que abarcan muchos canales simultáneos deben realizarse en un nivel de codificación dedicado o mediante un servicio de transcodificación externo.
¿Cuánta RAM usa realmente un servidor de streaming?
Es menos de lo que la mayoría de los compradores esperan por un solo canal, y mucho más cuando tienes varios en marcha.
La pila de streaming en sí es bastante modesta. NGINX el módulo RTMP, un proceso de FFmpeg por versión y el sistema operativo rara vez superan los 8 a 16 GB por canal. Esto sorprende a muchos que compran por primera vez y dan por hecho que el vídeo consume tanta memoria como las bases de datos.
La RAM empieza a ser importante cuando el servidor actúa como origen. Los segmentos que se sirven desde la caché de páginas nunca llegan al disco, lo que mantiene la latencia estable bajo carga. Una sola transmisión de 5 Mbps con una ventana de DVR de 60 segundos ocupa unos 37 MB en la caché. Multiplica eso por una escalera de cuatro niveles y veinte canales, y estarás almacenando en caché varios gigabytes de segmentos en directo de forma continua, además de los procesos de codificación.
Las configuraciones de 64 GB de los servidores dedicados gestionados de InMotion ofrecen suficiente margen para un origen multicanal sin que las lecturas de segmentos tengan que volver al disco.
¿Qué configuración de almacenamiento es la más adecuada para una infraestructura de distribución de vídeo?
NVMe los segmentos activos, capacidad más económica o almacenamiento de objetos para el archivo.
Los segmentos en directo son archivos pequeños que se escriben y se borran constantemente. Ese patrón de escritura favorece a NVMe perjudica a los discos giratorios. Las grabaciones son otro tema: no hacen más que crecer.
Los cálculos son bastante predecibles. Una grabación en 1080p a 6 Mbps consume unos 2,7 GB por hora. A 12 Mbps, se acercan más a los 5,4 GB por hora.
- Ocho horas al día a 6 Mbps: unos 22 GB al día, o 650 GB al mes
- Dos unidades NVMe de 1,92 TB NVMe RAID-1 ofrecen una capacidad útil cercana a los 1,92 TB, así que con ese ritmo se llenará la matriz en unos tres meses
- RAID-1 utiliza duplicación para garantizar la redundancia, así que una matriz de dos discos no duplica el espacio útil
Planifica la ruta de archivo antes de la primera transmisión, no después de que salte la alerta del disco. Premier Care incluye 500 GB de almacenamiento para copias de seguridad en servidores dedicados y 2 TB en servidores de alta capacidad, lo que te permite guardar una copia fuera del servidor de las grabaciones importantes. Para los archivos a largo plazo, sincroniza las grabaciones completadas con un almacenamiento de objetos compatible con S3 según un calendario y deja el disco local para los archivos en uso.
¿En qué protocolo deberías enviarlo?
La latencia y la escalabilidad tiran en direcciones opuestas, y la respuesta correcta depende de cuál de las dos es lo que realmente necesita tu público.
| Protocolo | Latencia típica | Se adapta a | Lo mejor para |
|---|---|---|---|
| HLS estándar | De 15 a 30 segundos | Audiencias muy amplias a través de la CDN | Seminarios web, vídeo bajo demanda, canales lineales |
| HLS de baja latencia | De 2 a 5 segundos | Gran número de espectadores a través de la CDN | Eventos en directo, deportes, lanzamientos de productos |
| WebRTC | Menos de 1 segundo | Cientos por servidor | Subastas, telesalud, interacción bidireccional |
La documentación de Apple sobre HTTP Live Streaming (HLS) habla de la extensión HLS de baja latencia, que usa segmentos parciales para reducir el retraso sin dejar de lado el modelo de distribución HTTP que hace posible el almacenamiento en caché de la CDN. Esa capacidad de almacenamiento en caché es precisamente la razón por la que HLS se escala de forma económica: un segmento es un archivo estático, así que un solo servidor puede alimentar a una CDN que, a su vez, alimenta a todos los demás.
WebRTC mantiene una conexión con estado por espectador. Como consecuencia, el coste del servidor por espectador se dispara, por lo que las plataformas interactivas suelen usar WebRTC para el puñado de participantes que hablan y HLS para el público que mira.
¿Cuándo debería encargarse una CDN de la distribución en lugar de tu servidor?
Cuando el volumen de envíos se acerque a la mitad de tu capacidad de puerto útil, o cuando tu público se extienda por más de un continente.
Las cifras hablan por sí solas. Sin una CDN, 2.000 espectadores simultáneos a 5 Mbps consumen 10 Gbps directamente de tu servidor. Con una CDN por delante, el servidor de origen envía cada segmento una sola vez a cada punto de borde y solo tiene que gestionar unas pocas docenas de conexiones en lugar de 2.000. La carga de tu servidor deja de aumentar a medida que crece la audiencia.
La geografía te obliga a tomar la misma decisión cuando hay menos espectadores. Un espectador de Sídney que recurre a segmentos procedentes de Virginia tiene que esperar cada ida y vuelta. InMotion tiene centros de datos en Virginia, California y Ámsterdam, lo que acorta bastante el primer salto para el público norteamericano y europeo, pero el público global sigue necesitando almacenamiento en caché en el borde.
Configura bien el origen antes de apuntar una CDN hacia él. Los archivos de segmentos deben tener un tiempo de vida en caché largo, ya que nunca cambian una vez grabados. Los manifiestos de las listas de reproducción deben tener uno muy corto, porque cambian cada pocos segundos. Si lo haces al revés, o bien tendrás transmisiones obsoletas o una CDN que no almacena nada en caché.
¿El vídeo bajo demanda cambia los requisitos?
En gran medida. El VOD elimina la restricción de tiempo real que condiciona las decisiones sobre el hardware de los servidores de streaming.
Al codificar una biblioteca de un día para otro, puedes usar ajustes predefinidos lentos pero eficientes que generan archivos más pequeños sin perder calidad visual. Unos archivos más pequeños significan que se necesita menos ancho de banda para cada reproducción futura, así que el esfuerzo que le dedicas a la CPU una vez te compensa continuamente. La codificación en directo nunca tiene esa opción.
Lo que aporta el VOD, en cambio, es capacidad de almacenamiento. Una biblioteca de 500 horas a 1080p en una estructura de tres niveles ocupa varios terabytes, y las bibliotecas no hacen más que crecer. Si tu carga de trabajo es principalmente bajo demanda, destina mayor parte del presupuesto a la capacidad y a la descarga de la CDN, en lugar de a los núcleos.
¿Qué servidor de InMotion se adapta mejor a tu carga de trabajo de streaming?
| Carga de trabajo | Perfil | Plan recomendado |
|---|---|---|
| Un solo canal, menos de 500 espectadores simultáneos, con una CDN delante | Escalera de tres peldaños, grabación esporádica | Essential, desde 99,99 $ al mes (64 GB de RAM, doble NVMe de 1,92 TB) |
| De dos a tres canales, de 500 a 2.000 espectadores | Varias escalas, registro diario | Plan Advanced desde 149,99 $ al mes o Plan Elite desde 199,99 $ al mes |
| Contenido de múltiples canales, amplia biblioteca de VOD, más de 2.000 usuarios simultáneos | Origen detrás de una CDN, alto rendimiento constante | Servidores de alta capacidad con una velocidad base de 3 Gbps, ampliables hasta 10 Gbps |
| Configuración personalizada, sin panel de control, solo con acceso de root | Nodo de codificación o de origen diseñado específicamente para este fin | Servidores Bare Metal |
| Desarrollo y pruebas de codificadores | No hay espectadores de producción | Un servidor dedicado básico o un VPS |
Todos los servidores dedicados gestionados incluyen el servicio de asistencia técnica avanzada, y en todos los niveles superiores al básico puedes añadir el servicio Premier Care para protección contra malware, almacenamiento de copias de seguridad y horas de consultoría.
¿Cuánto cuesta al mes un servidor de streaming?
La partida de servicio casi nunca es el importe total de la factura. Calcula el presupuesto teniendo en cuenta cuatro conceptos:
- El servidor en sí, desde 99,99 $ al mes por una configuración que admite un único canal bien optimizado
- Velocidad de puerto superior a la básica, a 60 dólares al mes por cada gigabit adicional en los planes en los que se aplica ese complemento
- Distribución a través de una CDN, que tu proveedor te factura por terabyte y que suele ser el mayor coste variable cuando se opera a gran escala
- Almacenamiento de archivo, ya sea con capacidad de copia de seguridad incluida o almacenamiento de objetos con precio por terabyte
La licencia del panel de control, si la necesitas, se factura por separado de los paquetes de atención gestionada. Comprueba los precios actuales en el carrito antes de confirmar la compra, ya que las tarifas promocionales y de renovación son diferentes.
¿A qué se debe que se cuelgue el servidor después de haberlo comprado?
El hardware casi nunca es el culpable. Estos cinco problemas de configuración son los que más quejas generan después de la compra:
- Los intervalos entre fotogramas clave que no coinciden con la duración del segmento. Los reproductores no pueden cambiar de versión de forma fluida, por lo que los espectadores ven retrasos durante los cambios de calidad. Ajusta el intervalo entre fotogramas clave al doble de la frecuencia de fotogramas y haz que coincida en todos los niveles.
- Un preset que va demasiado lento para tocar en directo. La codificación va por detrás del tiempo real y se pierden fotogramas. Prueba con
veryfasty ya irás ajustándolo sobre la marcha. - El RTMP está abierto a Internet. Cualquiera que encuentre el puerto puede enviar una transmisión a través de tu ancho de banda. Limita la captación a direcciones de emisoras conocidas.
- Las grabaciones se guardan en el mismo volumen que los segmentos en directo. La congestión del disco se nota en forma de cortes durante las sesiones largas. Separa las rutas.
- No hay ninguna CDN delante de un servidor de origen que dé servicio a una audiencia global. La distancia no es un problema de hardware, y ninguna actualización del servidor lo soluciona.
¿Dónde deberías pedir una segunda opinión sobre el montaje?
Las cargas de trabajo de streaming varían más que casi cualquier otro caso de uso de alojamiento. Un simple canal de webinar a 720p y una fuente de retransmisión deportiva de cuatro canales a 1080p60 se sitúan en extremos opuestos de la misma línea de productos, y la diferencia entre una configuración bien dimensionada y un error costoso suele reducirse a dos cifras: el número máximo de espectadores simultáneos y cuántas versiones necesitas realmente.
Si esas cifras aún son estimaciones, coméntalas con ellos antes de hacer el pedido. El equipo de InMotion trabaja con cargas de trabajo de streaming y medios en configuraciones de origen compartido, entornos multicanal y arquitecturas con CDN, y las conversaciones sobre el dimensionamiento se llevan a cabo con ingenieros, no siguiendo un guion. Ponte en contacto con el equipo con tu estimación de concurrencia y tu escalera de codificación, o echa un vistazo a los planes actuales de servidores dedicados para comparar las configuraciones directamente.