Streaming con Real Video (III)
Todos sus secretos
En esta tercera entrega se va a proceder a explicar todo el proceso de configuración de la técnica del splitting, multicasting o caching así como las opciones de seguridad, desvelando los secretos y trucos para establecer el perfecto funcionamiento de su Real Server.
Continuando con el apartado de configuración (Configure) vamos a centrarnos en técnicas y procesos que precisan de parámetros específicos.
Splitting (Figura 20) La técnica del splitting permite configurar los servidores de Real como transmisores o espejos de los contenidos en directo, de forma que los usuarios se conecten a dichos contenidos a su servidor más cercano. Con ello se logra que los usuarios se conecten con más garantías a los contenidos yse descarga el ancho de banda necesario en el servidor central y en cada uno de los incluidos en la infraestructura.
En la figura 20 puede ver como sería una arquitectura ejemplo en la que desde un servidor principal (contra el que se está realizando una retransmisión en directo), reparte la señal a un segundo Splitter que, a su vez, la reparte a otros tres y, al mismo tiempo, a otros tres más individuales. De esta forma tendríamos 6 servidores de borde (edge servers) a los que se conectarán los usuarios directamente usando Internet. Evidentemente, este acceso no se produce de forma automática. En las páginas de acceso a este contenido habrá que indicar a qué servidor se tiene que acceder. Una forma, la más obvia, es que existan páginas diferentes dependiendo de la región donde se acceda. Pero otra solución posible y fácil es programar un filtrado de la IP del usuario para así encaminarlo a su servidor más cercano.
Esta técnica es válida sólo para retransmisiones en directo. Para los contenidos bajo demanda es necesario programar o contratar algún servicio de caching que reparta dichos contenidos por nuestra infraestructura. Esto no lo hace Real Server por sí mismo.
Para interconectar mediante splitting los servidores se pueden usar tres tipos distintos de protocolos: UDP Unicast, UDP Multicast y TCP. UDP Multicast es la más eficaz, pero debe conocer su arquitectura de red para saber cuál de ellas puede utilizar.
Real Server está preparado para poder interconectar los servidores usando cualquier red IP. Así que podrá usar Internet para este propósito. Es posible que esto suene a inseguro, pero si contamos con buenas comunicaciones esta configuración funciona. Otro tema peliagudo es de las licencias. Si vamos a usar los servidores de cabecera (head servers) sólo como servidores principales de splitting, éstos sólo consumirán las licencias de los servidores de borde que les conectemos. Será en los servidores de borde (donde se conectan los usuarios) donde deberemos tener las licencias instaladas.
Los usuarios que conozcan el Real Server 7 o G2 habrán visto que en la configuración de los splitters existen dos métodos de splitting: Pull y Push. Esto ha desaparecido en la versión 8 debido a que Real ha decidido automatizar las comunicaciones entre servidores haciendo principal al trasmisor (Transmitter) y dejando que el/los receptores (Receiver) funcionen como secundarios, configurando todo en un único sitio. Por consiguiente y debido a todos estos cambios tanto el transmisor como el receptor deben ser Real Server v.8, perdiendo así la compatibilidad con las versiones anteriores. Entremos ahora a ver cómo son las pantallas de configuración de los dos tipos de configuración de los splitters.
Transmiter (figura 21) En esta pantalla se aprecian tres partes diferentes de esta configuración. En la primera sólo debe darle nombre al transmisor (lo normal es darle el mismo nombre que tiene como máquina en sí).
En la segunda, se debe proceder a configurar cada uno de los receptores que estarán conectados a su transmisor. Debe comenzar por ponerle nombre al receptor. Indique qué punto de montaje del mismo será el origen de las retransmisiones. Se incluye la IP del receptor y el método de transmisión de datos, por defecto es UDP Unicast, pero se puede cambiar (por UDP Multicast o TCP dependiendo de sus necesidades). Las comunicaciones UDP son mucho más estables y seguras por su propia arquitectura. Esto es importante para los administradores de los FireWalls. Tendrá que indicarles el puerto o rango de puertos que vamos a utilizar para las retransmisiones de forma que nos dejen abiertas las reglas de entrada/salida de datos entre los servidores. Real recomienda no usar TCP a no ser que sea estrictamente necesario o disponga de una red de absoluta confianza.
Si utiliza Multicast debe rellenar el valor TTL (Time To Live) del Multicasting. TTL significa que cada vez que un paquete de datos es enviado a través del router multicast, el valor se decrementa en 1 hasta llegar a cero. En ese momento el router descarga el paquete. 16 es el valor por defecto y es válido para la mayoría de configuraciones. Puede guiarse por la siguiente tabla:
Valor TTL Rango de Paquetes
0 Local host
1 Red Local (subnet)
32 Site
64 Región
128 Continente
255 Mundo
Los siguientes parámetros opcionales indican lo siguiente: Error Correction Rate es el porcentaje de correcciones en los paquetes enviados. Un valor alto da más garantía de transmisión a cambio de un consumo mayor de ancho de banda. En una red local podría ajustarse a cero e ir subiendo hasta ver cuanta corrección de errores es necesaria. Metadata Transmit Rate es la frecuencia en segundos en la que los paquetes especiales son transmitidos al receptor. Estos paquetes especiales describen el stream que está siendo r
Continuando con el apartado de configuración (Configure) vamos a centrarnos en técnicas y procesos que precisan de parámetros específicos.
Splitting (Figura 20) La técnica del splitting permite configurar los servidores de Real como transmisores o espejos de los contenidos en directo, de forma que los usuarios se conecten a dichos contenidos a su servidor más cercano. Con ello se logra que los usuarios se conecten con más garantías a los contenidos yse descarga el ancho de banda necesario en el servidor central y en cada uno de los incluidos en la infraestructura.
En la figura 20 puede ver como sería una arquitectura ejemplo en la que desde un servidor principal (contra el que se está realizando una retransmisión en directo), reparte la señal a un segundo Splitter que, a su vez, la reparte a otros tres y, al mismo tiempo, a otros tres más individuales. De esta forma tendríamos 6 servidores de borde (edge servers) a los que se conectarán los usuarios directamente usando Internet. Evidentemente, este acceso no se produce de forma automática. En las páginas de acceso a este contenido habrá que indicar a qué servidor se tiene que acceder. Una forma, la más obvia, es que existan páginas diferentes dependiendo de la región donde se acceda. Pero otra solución posible y fácil es programar un filtrado de la IP del usuario para así encaminarlo a su servidor más cercano.
Esta técnica es válida sólo para retransmisiones en directo. Para los contenidos bajo demanda es necesario programar o contratar algún servicio de caching que reparta dichos contenidos por nuestra infraestructura. Esto no lo hace Real Server por sí mismo.
Para interconectar mediante splitting los servidores se pueden usar tres tipos distintos de protocolos: UDP Unicast, UDP Multicast y TCP. UDP Multicast es la más eficaz, pero debe conocer su arquitectura de red para saber cuál de ellas puede utilizar.
Real Server está preparado para poder interconectar los servidores usando cualquier red IP. Así que podrá usar Internet para este propósito. Es posible que esto suene a inseguro, pero si contamos con buenas comunicaciones esta configuración funciona. Otro tema peliagudo es de las licencias. Si vamos a usar los servidores de cabecera (head servers) sólo como servidores principales de splitting, éstos sólo consumirán las licencias de los servidores de borde que les conectemos. Será en los servidores de borde (donde se conectan los usuarios) donde deberemos tener las licencias instaladas.
Los usuarios que conozcan el Real Server 7 o G2 habrán visto que en la configuración de los splitters existen dos métodos de splitting: Pull y Push. Esto ha desaparecido en la versión 8 debido a que Real ha decidido automatizar las comunicaciones entre servidores haciendo principal al trasmisor (Transmitter) y dejando que el/los receptores (Receiver) funcionen como secundarios, configurando todo en un único sitio. Por consiguiente y debido a todos estos cambios tanto el transmisor como el receptor deben ser Real Server v.8, perdiendo así la compatibilidad con las versiones anteriores. Entremos ahora a ver cómo son las pantallas de configuración de los dos tipos de configuración de los splitters.
Transmiter (figura 21) En esta pantalla se aprecian tres partes diferentes de esta configuración. En la primera sólo debe darle nombre al transmisor (lo normal es darle el mismo nombre que tiene como máquina en sí).
En la segunda, se debe proceder a configurar cada uno de los receptores que estarán conectados a su transmisor. Debe comenzar por ponerle nombre al receptor. Indique qué punto de montaje del mismo será el origen de las retransmisiones. Se incluye la IP del receptor y el método de transmisión de datos, por defecto es UDP Unicast, pero se puede cambiar (por UDP Multicast o TCP dependiendo de sus necesidades). Las comunicaciones UDP son mucho más estables y seguras por su propia arquitectura. Esto es importante para los administradores de los FireWalls. Tendrá que indicarles el puerto o rango de puertos que vamos a utilizar para las retransmisiones de forma que nos dejen abiertas las reglas de entrada/salida de datos entre los servidores. Real recomienda no usar TCP a no ser que sea estrictamente necesario o disponga de una red de absoluta confianza.
Si utiliza Multicast debe rellenar el valor TTL (Time To Live) del Multicasting. TTL significa que cada vez que un paquete de datos es enviado a través del router multicast, el valor se decrementa en 1 hasta llegar a cero. En ese momento el router descarga el paquete. 16 es el valor por defecto y es válido para la mayoría de configuraciones. Puede guiarse por la siguiente tabla:
Valor TTL Rango de Paquetes
0 Local host
1 Red Local (subnet)
32 Site
64 Región
128 Continente
255 Mundo
Los siguientes parámetros opcionales indican lo siguiente: Error Correction Rate es el porcentaje de correcciones en los paquetes enviados. Un valor alto da más garantía de transmisión a cambio de un consumo mayor de ancho de banda. En una red local podría ajustarse a cero e ir subiendo hasta ver cuanta corrección de errores es necesaria. Metadata Transmit Rate es la frecuencia en segundos en la que los paquetes especiales son transmitidos al receptor. Estos paquetes especiales describen el stream que está siendo r
