Zonas de entrega¶
Una zona es la sede desde la que mira el espectador. En una red corporativa una sede suele coincidir con una oficina: la oficina de Moscú tiene sus servidores, la de San Petersburgo los suyos, y un empleado no tiene por qué traer la transmisión desde el otro extremo del país cuando la imagen está disponible en su propia sala de servidores.
Las zonas responden a una sola pregunta: a qué servidor enviar al espectador que acaba de abrir una transmisión.
Cómo cae un espectador en una zona¶
Una zona se describe con una lista de subredes en notación CIDR — 10.10.0.0/16, 2a02:6b8::/32. IPv4 e IPv6 conviven en la misma lista.
Cuando un espectador abre una transmisión, su dirección se compara con las subredes de todas las zonas. Gana el prefijo coincidente más largo, es decir, la descripción más precisa. Esto permite describir la red por capas: una zona amplia para toda la empresa y zonas estrechas para cada oficina dentro de ella; el empleado de una oficina cae en su propia zona, mientras que un invitado desde una subred que nadie describió aparte cae en la general.
Los servidores se asignan a una zona en sus propios ajustes: una zona no es una lista de máquinas, sino un atributo de la máquina.
La zona de reserva¶
Una zona puede nombrar una zona de reserva: adónde llevar al espectador cuando en la suya no queda ningún servidor vivo. Esto es lo que convierte la caída de la sala de servidores de una oficina de «la transmisión se fue» en «la transmisión va más lenta».
La reserva es una referencia, no una copia: una cadena de zonas puede seguir más allá, y se admite una referencia a una zona que todavía no existe — la cadena simplemente termina ahí.
Por qué esto le interesa a un difusor corporativo¶
El sentido de las zonas no es ahorrar tráfico en sí, sino dónde está el cuello de botella. Una reunión general la miran todas las oficinas a la vez, y el enlace entre sedes es el único lugar donde mil espectadores se convierten en mil flujos. Las zonas mantienen ese tráfico dentro de la sede: entre oficinas viaja un flujo, no mil.
Por eso las zonas se configuran antes de la primera reunión grande, no después de ella.
Rutas explícitas y rechazo¶
Una sola zona activa el enrutamiento CDN. Central selecciona únicamente nodos de la zona del cliente y de su cadena explícita fallback_zone. Se excluyen nodos sin zona y zonas ajenas. none (null en la API), una zona inexistente o una repetida terminan la cadena. Sin destinos aptos, central devuelve 503 con Retry-After; un stream desconocido devuelve 404.
Sin CIDR coincidente o sin IP del cliente también se rechaza. Configure explícitamente 0.0.0.0/0 para IPv4 y ::/0 para IPv6 si necesita una ruta general. Incluso una zona sin rutas activa este modo. Eliminar la última zona restaura la selección sin restricciones: primero edge y después ingest.
El origen no es una reserva universal. Los espectadores de una oficina que falla pueden sobrecargarlo y afectar otras oficinas. Para permitirlo, asigne el nodo de origen a origin-pool, cree esa zona (puede dejar sus rutas vacías) y úsela como reserva de la oficina. El nombre no tiene significado especial. Un origen en la zona del cliente también está permitido explícitamente.
| Configuración | Cuando fallan todos los nodos de office-2 |
|---|---|
office-2 → none |
Rechazo; office-1 y el origen quedan excluidos |
office-2 → office-1 → none |
Solo office-1; después rechazo |
office-2 → origin-pool → none |
Solo origin-pool; después rechazo |
Carga y límites¶
Dentro de una zona, edge e ingest son iguales: se elige el nodo con menos sesiones Play activas y los empates se reparten uniformemente. El origen no tiene prioridad especial. JSON ordena las zonas según la cadena y los nodos por carga creciente; excluye direcciones privadas. GET normal admite proxy y entrega local.
La sección CDN del nodo ofrece dos campos independientes:
playback_session_limit: límite de sesiones Play activas, sin Publish.playback_bandwidth_kbit: tráfico saliente de todo el host en kbit/s, incluido el tráfico entre nodos. Es independiente denetwork_bandwidth_kbit, el presupuesto RX+TX de colocación.
Vacío elimina el límite; 0 impide nuevas selecciones. Un valor igual o superior al límite excluye el nodo. Si todos quedan excluidos, se intenta la siguiente zona explícita. Sin métricas necesarias se excluye el nodo; el último informe sirve mientras esté online. Los límites explícitos también se aplican sin zonas.
Estos límites afectan a nuevas decisiones de central. El retraso de informes y las URL ya emitidas permiten superar el límite. No limitan el ancho de banda ni terminan sesiones. El reproductor recibe cambios al volver a solicitar rutas; las URL existentes no se revocan.
Para VOD, primero se filtran las ubicaciones disponibles por zonas permitidas; después se elige la revisión máxima disponible, la zona y la carga. Una réplica reciente prohibida no excluye una antigua permitida; una reserva permitida más reciente puede prevalecer sobre la copia local antigua.
Un proxy de confianza¶
Introduzca CIDR en Proxies de confianza del clúster, en la configuración compartida de central, un prefijo por línea. La lista se aplica a todo el clúster, incluidas todas las instancias de central y los streamers, sin excepciones locales. Por ejemplo:
192.0.2.10/32
2001:db8::10/128
Solo de un par de confianza se acepta la última IP de X-Forwarded-For. El proxy debe añadir la dirección real del cliente. Si falta o es inválida, se usa la IP de la conexión; se ignora X-Real-IP. Una lista vacía no confía en cabeceras. No se admite una cadena de varios proxies de confianza.
Los cambios y el vaciado de la lista se aplican automáticamente al actualizar la configuración, sin reiniciar. Un CIDR inválido se rechaza y el campo muestra el error. La API expone trusted_proxies mediante PATCH /central/api-v4/config; un array vacío o null elimina la confianza en todos los proxies. El listener determina el esquema de la URL pública.