Cómo elegir un servidor para IPTV

Antes de elegir un chasis hay que separar tres cargas que se confunden todo el tiempo porque conviven en el mismo rack. La transcodificación convierte una señal de entrada en varias salidas y escala con canales multiplicados por perfiles, no con suscriptores. El empaquetado o transmuxing reordena esa salida en segmentos HLS o DASH sin recomprimir, y su cuello de botella es entrada y salida de disco y de red. La entrega u origin sirve esos segmentos a los clientes y sí escala con la concurrencia. Un servidor que hace las tres cosas tiene tres perfiles de hardware distintos peleando por el mismo presupuesto.

El dato que hay que tener antes de cotizar nada es la matriz de canales: cuántas señales entran, en qué resolución y a qué tasa de cuadros, cuántos perfiles adaptativos genera cada una, y si alguna se distribuye tal cual sin tocar. Un catálogo de sesenta canales con una escalera de cuatro perfiles produce doscientas cuarenta salidas simultáneas; el mismo catálogo con passthrough de treinta señales y transcodificación de las otras treinta produce ciento cincuenta. Esa diferencia decide si el proyecto necesita un servidor o tres.

La segunda variable es el modo de entrega. En IPTV administrada sobre multicast, el ancho de banda de salida del origen es canales por bitrate y no depende de cuántos abonados vean cada señal: doscientos canales a seis megabits son mil doscientos megabits fijos. En OTT unicast, en cambio, la salida es concurrencia pico por bitrate medio, y ahí cinco mil espectadores simultáneos a cuatro megabits son veinte gigabits. Dimensionar una plataforma unicast con la aritmética del multicast es el fallo más caro de esta categoría.

HEVC entrega calidad comparable a H.264 con una reducción de tasa de bits que en contenido real se mueve entre el treinta y el cincuenta por ciento según el material: una película con planos largos gana mucho, un partido de fútbol a cincuenta cuadros por segundo gana bastante menos. Ese ahorro es dinero directo cuando el transporte cuesta, y por eso todo operador quiere HEVC. El problema aparece del otro lado: codificar en HEVC con calidad equivalente cuesta varias veces más ciclos de CPU que H.264 en presets comparables, así que el mismo servidor rinde una fracción de los canales.

Las cifras de trabajo con las que conviene arrancar el cálculo son conocidas: una señal 1080p en H.264 se distribuye habitualmente entre cinco y ocho megabits, la misma en HEVC entre tres y cuatro, y un perfil 720p en H.264 entre dos y medio y tres y medio. No son valores sagrados —dependen del encoder, del preset y del contenido—, pero sirven para dimensionar red y almacenamiento antes de tener el equipo en el laboratorio. Lo que no sirve es tomar el bitrate de la señal de contribución de entrada como si fuera el de distribución.

La restricción que casi nunca se revisa a tiempo es el parque de decodificadores. Si el operador tiene decodificadores desplegados que solo entienden H.264, HEVC no es una decisión de servidor sino de reemplazo de terminales, y mientras dure la transición hay que emitir en los dos códecs. Ese simulcast duplica la carga de transcodificación, duplica el almacenamiento de catch-up y duplica el ancho de banda del multiplex. Conviene decidirlo antes de comprar, porque un servidor dimensionado para HEVC puro se queda corto el día que hay que emitir en paralelo.

La transcodificación por software con x264 o x265 entrega la mejor calidad por bit disponible y es completamente flexible: cualquier códec, cualquier filtro, cualquier preset. El precio es densidad. Cuando el objetivo es exprimir cada megabit —porque el tránsito internacional se paga caro o porque el multiplex ya está lleno— un preset lento en CPU sigue ganando la comparación de calidad frente a la codificación por hardware. Ese es el caso típico del operador que tiene que meter doce canales adicionales en la capacidad que ya tiene contratada.

La codificación acelerada por GPU invierte la ecuación: multiplica el número de salidas simultáneas por chasis y baja la latencia, a cambio de una calidad por bit algo inferior a la de un preset lento en software y de un límite duro en el número de sesiones concurrentes que el chip acepta. Para escaleras adaptativas de OTT, donde hay muchos perfiles derivados de la misma fuente y el bitrate no es el recurso escaso, la aceleración por hardware suele ser la decisión correcta y la diferencia de calidad es difícil de defender frente a la diferencia de coste por canal.

Hay un detalle que se pasa por alto al comprar plataformas de generación anterior y que cambia el diseño: los Xeon E5-2600 v3 y v4 que llevan los PowerEdge de decimotercera generación y los ProLiant Gen9 no integran gráficos, así que no existe Quick Sync en esos servidores. Toda la aceleración tiene que venir de una GPU discreta, y eso obliga a revisar antes tres cosas: que el chasis tenga un slot PCIe de ancho suficiente, que la fuente cubra el consumo adicional y que el flujo de aire del formato admita la tarjeta. Un 2U resuelve esas tres cosas con mucho más margen que un 1U.

El cálculo de salida es aritmética simple, pero hay que hacerla con el escenario correcto. En multicast administrado se suman los bitrates de todos los canales activos: doscientos canales entre cuatro y ocho megabits dan del orden de uno a dos gigabits, que un enlace de diez gigabits absorbe sin discusión. En unicast, se multiplica la concurrencia pico por el bitrate medio del perfil que realmente consume la mayoría de los clientes, que no es el perfil más alto de la escalera. Diez mil sesiones a tres megabits son treinta gigabits, y eso ya no cabe en un par de puertos de diez.

A ese número hay que aplicarle dos correcciones. La primera es no diseñar la interfaz al cien por ciento: por encima del setenta por ciento de utilización sostenida, las ráfagas de arranque de sesiones adaptativas empiezan a producir descartes que el cliente percibe como rebuffering aunque el promedio se vea sano en la gráfica. La segunda es la redundancia: si dos puertos en agregación llevan la carga y uno de ellos cae, el que queda tiene que poder sostenerla, lo que en la práctica significa dimensionar cada rama al cincuenta por ciento en operación normal.

Del lado del servidor hay que confirmar que el chasis puede alojar la tarjeta. Una NIC de dos puertos de diez gigabits necesita un slot PCIe 3.0 x8 para no quedar limitada, y en formatos de una unidad de rack el riser disponible a veces no ofrece ese ancho en todas las posiciones. A partir de decenas de miles de sesiones concurrentes el cuello deja de ser el disco y pasa a ser el procesamiento de interrupciones, así que conviene una tarjeta con múltiples colas y reparto de interrupciones entre núcleos, y verificar la afinidad de esas colas con el socket que ejecuta el proceso de entrega.

El cálculo base es directo y conviene hacerlo antes de mirar bahías. Un canal a seis megabits grabado durante veinticuatro horas ocupa unos sesenta y cinco gigabytes por día. Cien canales con siete días de ventana de catch-up son alrededor de cuarenta y cinco terabytes útiles, y eso grabando un solo perfil. Si el requisito es grabar la escalera adaptativa completa para que el catch-up también sea adaptativo, hay que multiplicar por el número de perfiles, y el proyecto pasa de una máquina con doce bahías a un subsistema de almacenamiento con criterio propio.

El nDVR añade una variable jurídica que cambia el hardware. Si la implementación admite copia única compartida entre suscriptores, el almacenamiento crece con el catálogo. Si el marco aplicable exige copia individual por abonado, crece con el catálogo multiplicado por los abonados que graban, y ningún dimensionamiento de servidor único sobrevive a eso. Es una definición que hay que cerrar con el área legal y comercial antes de comprar discos, no después.

El patrón de acceso también decide la tecnología. Grabar es escritura secuencial y lo resuelve cualquier disco mecánico nearline; reproducir catch-up es lectura de segmentos pequeños dispersos, y ahí los discos mecánicos sufren. La combinación que funciona es capacidad en discos nearline de gran tamaño para la ventana completa, más SSD o NVMe para los índices, los manifiestos y las últimas horas, que son las que concentran la mayoría de las reproducciones. Sobre volúmenes grandes use RAID 6 o RAID 60: con discos de ocho a doce terabytes, el tiempo de reconstrucción de un RAID 5 deja el arreglo expuesto demasiadas horas.

No todo se duplica, y pretenderlo es la forma más rápida de gastar el doble sin ganar disponibilidad. La regla práctica es duplicar en función del impacto: las señales premium y los canales que sostienen el producto van en configuración uno más uno con conmutación automática; el resto del catálogo se cubre con un esquema N más uno, donde un motor de transcodificación de reserva puede asumir el canal que falle. A partir de ocho canales, el esquema N más uno cuesta mucho menos y ofrece casi la misma protección estadística.

El origin siempre va en pareja, porque es el punto donde una caída se convierte en pantalla negra para todos a la vez, y los nodos de empaquetado y entrega se escalan horizontalmente detrás de un balanceador, no se hacen más grandes. El almacenamiento frío de catch-up normalmente no se replica: se protege con RAID y se acepta que la pérdida de una ventana histórica es un incidente menor comparado con la caída del directo.

La parte física es donde se pierde la redundancia que se creía tener. Dos fuentes de alimentación conectadas a la misma regleta no son redundantes; tienen que ir a dos unidades de distribución alimentadas por ramas distintas. Dos puertos en agregación hacia el mismo switch protegen contra una óptica rota, no contra la caída del switch: hay que llevarlos a dos equipos con agregación multichasis. Y el conmutado real del flujo depende de que el receptor sepa cambiar de origen, algo que se prueba en laboratorio antes de dar el servicio por redundante.

Para un headend de tamaño medio que recibe, desmultiplexa y empaqueta sin transcodificación pesada, el perfil que funciona es un chasis de una unidad de rack con doble socket, memoria moderada y buena red. Un PowerEdge R630 o un ProLiant DL160 Gen9 con dos procesadores de ocho a diez núcleos, entre sesenta y cuatro y ciento veintiocho gigabytes de memoria, un par de SSD en espejo para el sistema y una tarjeta de dos puertos de diez gigabits cubre la carga con holgura. Aquí lo que importa es la estabilidad de la entrada y salida, no la potencia bruta de cálculo.

Cuando hay transcodificación por software, la métrica de compra cambia a núcleos físicos y ancho de banda de memoria. Un R630 o un DL160 Gen9 con dos procesadores de catorce núcleos y de ciento veintiocho a doscientos cincuenta y seis gigabytes de memoria es el punto donde la mayoría de los operadores regionales encuentran la mejor relación entre canales por chasis y coste. La forma correcta de fijar cuántos canales entran no es un cálculo teórico: es una prueba de veinticuatro horas con el contenido más exigente del catálogo, normalmente deporte a cincuenta cuadros por segundo, midiendo cuadros descartados y no promedio de uso de CPU.

Para origin, empaquetado y nDVR el criterio se invierte y manda el formato de dos unidades de rack. Un PowerEdge R730 o un ProLiant DL180 Gen9 aportan las bahías que el catch-up necesita —el R730 admite ocho discos de tres pulgadas y media o dieciséis de dos y media, y el DL180 Gen9 llega a doce discos de tres pulgadas y media— además del espacio y la alimentación para una GPU si más adelante hace falta. En estos nodos la memoria no es un lujo: el sistema la usa como caché de segmentos calientes, y ciento veintiocho gigabytes o más reducen la lectura a disco mucho más de lo que cualquier mejora de procesador aportaría.

El error más repetido es dimensionar por suscriptores una plataforma cuya carga dominante es de transcodificación. Un operador con quinientos abonados y cien canales necesita más capacidad de cómputo que uno con cinco mil abonados y treinta canales, porque la transcodificación no sabe cuántos clientes hay del otro lado. La cifra de abonados solo manda en la capa de entrega unicast, y aun así lo que manda es la concurrencia pico, no el total facturado.

El segundo error clásico es comprar el procesador equivocado para la tarea. Un origin agradece frecuencia y memoria; un transcodificador agradece núcleos. Comprar una máquina de pocos núcleos muy rápidos para transcodificar deja canales sobre la mesa, y comprar una de muchos núcleos lentos para servir segmentos no mejora nada. El tercero es olvidar que un catálogo crece: la ventana de catch-up que hoy es de siete días será de catorce en cuanto el área comercial lo pida, y ese cambio duplica el almacenamiento sin tocar una sola línea del diseño.

Por último, medir mal. Un benchmark de sesenta segundos con un clip de demostración no dice nada útil sobre una plataforma que va a operar sin parar. Las decisiones se toman con pruebas largas, con el contenido más difícil que se vaya a emitir y con las métricas correctas: cuadros descartados, latencia de empaquetado, ocupación de buffer y tiempo de respuesta del origin bajo concurrencia, no el porcentaje medio de uso de procesador.