ES2402037B1

ES2402037B1 - Método y sistema para realizar un proceso de adquisición de contenido distribuido para una red de distribución de contenido

Info

Publication number: ES2402037B1
Application number: ES201131644A
Authority: ES
Inventors: Armando Antonio GARCIA MENDOZA; Pablo RODRÍGUEZ RODRÍGUEZ; Yang XIAOYUAN
Original assignee: Telefonica SA
Current assignee: Telefonica SA
Priority date: 2011-10-13
Filing date: 2011-10-13
Publication date: 2014-04-30
Anticipated expiration: 2031-10-13
Also published as: WO2013053785A1; EP2767072B1; US20140325577A1; ES2402037R1; ES2402037A2; EP2767072A1; ES2554910T3

Abstract

Un método y un sistema para realizar un proceso de adquisición de contenido distribuido para una red de distribución de contenido.#En el método de la invención, dicha CDN comprende una pluralidad de nodos de servidor, dicho proceso de adquisición de contenido se realiza cuando un usuario final solicita cargar contenido y dicho método se caracteriza porque comprende:#- seleccionar, una entidad central que recibe una petición de carga realizada por dicho usuario final, al menos uno de dicha pluralidad de nodos de servidor según la ubicación de dicho usuario final, el estado actual de dicha pluralidad de nodos de servidor, los requisitos de CPU de dicha pluralidad de nodos de servidor y/o cualquier otro parámetro de monitorización de dicha CDN;#- dirigir, dicha entidad central, dicha petición de carga realizada por dicho usuario final a dicho al menos uno de dicha pluralidad de nodos de servidor; y#- cargar, dicho usuario final, dicho contenido a dicho al menos uno de dicha pluralidad de nodos de servidor tras la aceptación de dicha petición de carga por dicho al menos uno de dicha pluralidad de nodos de servidor.#El sistema de la invención está dispuesto para implementar el método de la invención.

Description

Método y sistema para realizar un proceso de adquisición de contenido distribuido para una red de distribución de contenido

Campo de la técnica

La presente invención se refiere, en general, en un primer aspecto, a un método para realizar un proceso de adquisición de contenido distribuido para una red de distribución de contenido, comprendiendo dicha CDN una pluralidad de nodos de servidor, realizándose dicho proceso de adquisición de contenido cuando un usuario final solicita cargar contenido, y más particularmente a un método que comprende seleccionar al menos uno de dicha pluralidad de nodos de servidor, dirigir dicha petición de carga realizada por dicho usuario final a dicho al menos uno de dicha pluralidad de nodos de servidor y cargar dicho contenido a dicho al menos uno de dicha pluralidad de nodos de servidor tras la aceptación de dicha petición de carga por dicho al menos uno de dicha pluralidad de nodos de servidor.

Un segundo aspecto de la invención se refiere a un sistema dispuesto para implementar el método del primer aspecto.

Estado de la técnica anterior

Una CDN (red de distribución de contenido) es un sistema distribuido geográficamente completo con el objetivo de replicar contenido a servidores que están cerca de los usuarios finales. Todos los diseños de sistemas CDN se basan en la suposición de que se accede múltiples veces a la mayoría del contenido en Internet, una vez producido. La implicación de esta suposición es que el requisito de ancho de banda para la adquisición de contenido se considera despreciable en comparación con el que se requiere para la distribución. Como consecuencia, todos los sistemas de CDN actuales [1] [2] [3] se optimizan para la distribución de contenido en vez de para la adquisición de contenido.

Con la evolución de la Web 2.0 ha cambiado de manera drástica el patrón de consumo de contenido. Los usuarios de Internet actuales ya no son consumidores del contenido; están participando activamente en toda la cadena del contenido, desde la producción y adicción hasta la distribución y consumo. Los portales de UGC (contenido generado por usuarios) en línea, tales como YouTube [1], permiten que los usuarios carguen sus propios vídeos, o modificaciones de vídeos previamente descargas, para compartirlos con otros usuarios en línea. Otros sitios web tales como Megaupload [6] o RapidShare [7] son incluso más radicales. Con estos servicios de alojamiento a un clic [20], los usuarios finales pueden cargar cualquier contenido que deseen, desde vídeos hasta archivos ISO de DVD. Según el informe [2], se están cargando 24 horas de vídeo sin procesar en YouTube por minuto. En términos de ancho de banda, los usuarios alrededor del mundo pueden estar poniendo contenido en los servidores de YouTube a un ritmo de 1,4 Gbps.

Otra característica de la Web 2.0 es la aceleración del proceso de propagación de información. Las OSN, tales como Facebook [8] o Twitter [9], permiten a los usuarios enviar notificaciones (tweets) a sus amigos en línea directamente conectados (o rastreadores en Twitter). Entonces la información recibida se propaga a otros miles de amigos del amigo. En una OSN, la información o tweets pueden propagarse rápidamente a usuarios finales como una cascada [21] [22]. La naturaleza pandémica de las OSN incentiva que grupos de usuarios empiecen a poner simultáneamente información en la red, produciendo un fenómeno ampliamente conocido denominado avalancha (flashcrowd).

La democratización de la producción de contenido y la rápida propagación de la información conlleva nuevos retos para los servicios en línea de la actual y la próxima generación en los que el sistema backend a menudo tiene que manipular avalanchas, impulsadas por interacciones sociales impredecibles de los usuarios finales. Ha habido varios estudios de medición 00 para analizar los servicios en línea, tales como YouTube. En [3] los autores incluso comentaron el potencial del sistema P2P para mejorar la distribución de vídeo, pero sigue sin considerarse el proceso de carga.

Las CDN normalmente funcionan como entidades globales únicas; tienen múltiples puntos de presencia y en ubicaciones que están geográficamente alejadas. La CDN suele tener múltiples réplicas de cada contenido que se aloja para un cliente de la CDN. La primera copia (copia maestra) del contenido, sin embargo, sólo se aloja en un único punto, llamado servidor original. El servidor original permite que los clientes de la CDN carguen el contenido que están interesados en distribuir a los usuarios finales. Con este propósito, los proveedores de CDN normalmente definen una API (application programming interface; interfaz de programación de aplicaciones) convencional que facilita la publicación de contenido. Algunos proveedores de CDN [10] asignan un espacio FTP (file transfer protocol; protocolo de transferencia de archivos) para cada cliente. Otros operadores de CDN implementan funcionalidades de sincronización remota que permiten a los clientes de la CDN realizar una copia espejo de una carpeta de servidor en el servidor original. Los proveedores de CDN normales también implementan los mecanismos basados en extracción (pull). Con los mecanismos basados en extracción, los clientes de la CDN no publican el contenido en la CDN. La CDN se encarga de traer todo el contenido desde servidores predefinidos cuando los usuarios finales lo solicitan.

Aparte del mecanismo de publicación de contenido, una CDN sólo puede diferenciarse por un conjunto de otras características, tales como selección de nodos o estrategia de asignación de nodos. Por ejemplo, en [11] se usa una jerarquía de servidores DNS (domain name Server; servidor de nombres de dominio) [12] conjuntamente con información de ubicación geográfica para encontrar el servidor de contenido que está más cerca de un usuario final solicitante para entregar contenido. Otras soluciones [13] usan un mecanismo de redirección HTTP para implementar selección de nodo. Soluciones tales como [14] se basan en un pequeño número de grandes centros de datos en vez de en un gran número de pequeños centros de datos conectados por una red privada debidamente aprovisionada [11]. Además, [16] se basa en una infraestructura de almacenamiento extenso y almacenamiento en caché en los puntos de interconexión principales para reducir el coste de ancho de banda. Amazon [15] proporciona un servicio de CDN que usa Amazon CloudFront [17] conjuntamente con su servicio de almacenamiento sencillo que permite a los usuarios finales obtener datos desde diversas ubicaciones marginales de Internet con las que Amazon se interconecta.

Independientemente del mecanismo de publicación de contenido y otras características de arquitectura, todos los diseños de CDN actuales se basan en un servidor original centralizado para manejar la copia maestra del contenido del cliente.

Una arquitectura centralizada sólo puede manejar un número limitado de procesos de adquisición paralelos y está restringida por diferentes recursos de sistema, incluyendo ancho de banda de red, tamaño de memoria, capacidad de CPU (central processing unit; unidad de procesamiento central)y rendimiento global de lectura/escritura de disco.

-: Restricciones del ajuste a escala

La práctica común de ajustar a escala el servicio de adquisición de datos es replicar nodos de servidor dentro del centro de datos. Esta técnica, sin embargo, no siempre es posible debido a las limitaciones de espacio y restricciones de potencia. Por ejemplo, algunos proveedores de bastidores ofrecen un número limitado de ranuras para los elementos de CPU/almacenamiento. El ajuste a escala dentro del centro de datos tampoco es económico debido a la no linealidad del coste del sistema de refrigeración. Para centros de datos grandes, el sistema de refrigeración tiene que proporcionar una temperatura inferior para superar los efectos de recirculación del aire de escape del equipo temporal superior [18]. Además, puede requerirse hasta un 30% de potencia de refrigeración adicional para proporcionar un nivel de humedad constante para todos los elementos de IT (information technology; tecnología de la información).

-: Utilización de recursos de nivel bajo

En los sistemas de CDN actuales, la adquisición de datos y la entrega de datos son servicios aislados y se asignan en máquinas independientes, dando como resultado una ineficacia de recursos de sistema sustancial relacionada con la inactividad de nodos. Dependiendo de las características de carga de trabajo, los nodos de servidor actuales pueden necesitar sólo el 10-20% del recurso de CPU para saturar completamente el enlace de red. El 80-90% de los recursos restantes simplemente se desperdicia y podrían utilizarse por operaciones intensivas de CPU tales como procesamiento posterior de vídeo para contenido cargado por el usuario.

Determinado por el comportamiento humano en diferentes zonas horarias, los nodos de CDN experimentan altas demandas durante sólo un determinado periodo del día. Para gestionar la demanda de red diurna, los nodos de CDN normalmente se aprovisionan en exceso y, como consecuencia, experimentan una utilización de bajo nivel a lo largo del tiempo.

-: Bajo rendimiento de carga

Cargar contenido a un único punto centralizado puede conllevar una alta latencia y un bajo rendimiento global. La figura 1 muestra el resultado de un estudio de rendimiento con 40 servidores distribuidos en 12 ciudades alrededor del mundo. En el estudio, cada servidor carga imágenes a un servidor centralizado en Madrid en un periodo de 48 horas. Se mide tanto la latencia como la velocidad de carga. Tal como se observó, la velocidad de carga es inversamente proporcional a la latencia de red. Es posible identificar claramente 3 zonas: 1) ciudades europeas con el rendimiento más alto, 2) ciudades norteamericanas y 3) ciudades en Sudamérica con el rendimiento más bajo. En comparación con las ciudades europeas, la velocidad de carga de los nodos en Sudamérica es un 60% menor.

-: Alto coste de red

Tener un punto de adquisición centralizado implica trayectos de transmisión más largos y consume más recursos de redes. La figura 2 muestra el número de saltos de red entre servidores en diferentes ciudades hasta Madrid. El trayecto más largo está entre Buenos Aires y Madrid, que requiere hasta 8 saltos. La transmisión en trayectos largos no es eficaz y también es poco atractiva para los proveedores de red (ISP) que están pagando anchos de banda de carga/descarga a/de proveedores de red de tránsito. Cargar nodos de servidor locales, en el mismo POP que el usuario final o el cliente de la CDN, es mucho más eficaz y reduce el tráfico de red en muchos enlaces.

Descripción de la invención

Es necesario ofrecer una alternativa al estado de la técnica que cubra las lagunas que se encuentran en la misma, particularmente en relación con la falta de propuestas que realmente ofrezcan una arquitectura distribuida con un mecanismo de adquisición de contenido ajustable a escala y que realmente permitan reducir el coste de replicación del contenido cargado a otros nodos del servicio de distribución.

Para ello, la presente invención proporciona, en un primer aspecto, un método para realizar un proceso de adquisición de contenido distribuido para una red de distribución de contenido, comprendiendo dicha red de distribución de contenido, o CDN, una pluralidad de nodos de servicio, realizándose dicho proceso de adquisición de contenido cuando un usuario final solicita cargar contenido.

A diferencia de las propuestas conocidas, el método de la invención, de una manera característica, comprende además:

-: seleccionar, una entidad central que recibe una petición de carga realizada por dicho usuario final, al menos uno de dicha pluralidad de nodos de servicio según la ubicación de dicho usuario final, el estado actual de dicha pluralidad de nodos de servicio, los requisitos de CPU de dicha pluralidad de nodos de servicio y/o cualquier otro parámetro de monitorización de dicha CDN;

-: dirigir, dicha entidad central, dicha petición de carga realizada por dicho usuario final a dicho al menos uno de dicha pluralidad de nodos de servicio; y

-: cargar, dicho usuario final, dicho contenido a dicho al menos uno de dicha pluralidad de nodos de servidor tras la aceptación de dicha petición de carga por dicho al menos uno de dicha pluralidad de nodos de servicio.

Otras realizaciones del método del primer aspecto de la invención se describen según las reivindicaciones adjuntas 2 a 8, y en una sección posterior relativa a la descripción detallada de varias realizaciones.

Un segundo aspecto de la presente invención se refiere a un sistema para realizar un proceso de adquisición de contenido distribuido para una red de distribución de contenido, comprendiendo dicha red de distribución de contenido, o CDN, una pluralidad de nodos de servicio, realizándose dicho proceso de adquisición de contenido cuando un usuario final solicita cargar contenido.

En el sistema del segundo aspecto de la invención, a diferencia de los sistemas conocidos mencionados en la sección del estado de la técnica anterior, y de una manera característica, comprende un controlador central que se encarga de:

-: seleccionar, cuando se recibe una petición de carga realizada por dicho usuario final, al menos uno de dicha pluralidad de nodos de servicio según la ubicación de dicho usuario final, el estado actual de dicha pluralidad de nodos de servicio, los requisitos de CPU de dicha pluralidad de nodos de servicio y/o cualquier otro parámetro de monitorización de dicha CDN; y

-: dirigir, dicha entidad central, dicha petición de carga de dicho usuario final a dicho al menos uno de dicha pluralidad de nodos de servicio;

en el que dicho usuario final carga dicho contenido a dicho al menos uno de dicha pluralidad de nodos de servicio tras la aceptación de dicha petición de carga por dicho al menos uno de dicha pluralidad de nodos de servicio.

El sistema del segundo aspecto de la invención está adaptado para implementar el método del primer aspecto.

Otras realizaciones del sistema del segundo aspecto de la invención se describen según las reivindicaciones adjuntas 10 a 21, y en una sección posterior relativa a la descripción detallada de varias realizaciones.

Breve descripción de los dibujos

Las anteriores y otras ventajas y características se entenderán más completamente a partir de la siguiente descripción detallada de realizaciones, con referencia a los dibujos adjuntos (algunos de los cuales ya se han descrito en la sección del estado de la técnica anterior), que deben considerarse de una manera ilustrativa y no limitativa, en los que:

La figura 1 muestra el resultado de latencia y velocidad de carga de un estudio de rendimiento con 40 servidores distribuidos en 12 ciudades alrededor del mundo.

La figura 2 muestra el número de saltos entre servidores hasta alcanzar el servidor situado en Madrid, según el estudio de rendimiento.

La figura 3 muestra el nodo de adquisición, según una realización de la presente invención.

La figura 4 muestra el controlador central, según una realización de la presente invención.

La figura 5 muestra gráficamente el rendimiento global de carga de países europeos frente al rendimiento global de carga de todo el mundo, según una implementación de la presente invención.

La figura 6 muestra la carga de CPU para un procesamiento posterior de vídeo, según una implementación de la presente invención.

Descripción detallada de varias realizaciones

La invención trata de un sistema de adquisición de contenido distribuido para una CDN. En este sistema, todos los nodos de distribución de una CDN están coordinados para permitir a cualquier usuario final particular (usuario doméstico así como clientes de CDN) cargar contenido al almacenamiento del nodo. El contenido cargado luego se procesa posteriormente y se propaga hacia otros nodos de distribución.

Todos los nodos de distribución informan del estado de carga a un controlador centralizado. Según el estado de los nodos de distribución, la ubicación geográfica del cargador y los requisitos de CPU para el procesamiento posterior, el controlador selecciona el mejor nodo de entrega para el proceso de adquisición.

Un proceso de replicación sigue al proceso de adquisición, en el que el nodo de distribución envía el contenido adquirido a un repositorio centralizado. El repositorio centralizado garantiza la disponibilidad del contenido y realiza toda la política de control, tal como el control de derechos de acceso o el periodo de disponibilidad del contenido.

El sistema de adquisición distribuido está compuesto por 2 elementos principales: nodos de adquisición y controlador central.

-: Nodo de adquisición

Un nodo de adquisición (AN) está compuesto por un conjunto de elementos de software que pueden funcionar tanto en los propios nodos de distribución físicos como en máquinas independientes. La integración sin discontinuidades de la adquisición con los nodos de entrega proporciona ventajas de implementación y una alta utilización de recursos.

En la figura 3 se muestran todos los componentes de un nodo de adquisición:

(1): Monitor de carga de sistema (SLM; system load monitor): este componente hace un seguimiento constante del nivel de consumo de recursos del nodo usando diferentes monitores que calculan el nivel de carga de CPU, disco, red y memoria. Al usar niveles de carga en tiempo real, el SLM calcula el nivel de carga actual y en un futuro próximo. La carga de sistema se notifica entonces, periódicamente, al controlador central (2).

(3): Gestor de admisión de tareas (TAM; task admission manager): el controlador central se comunica con este componente siempre que se solicita un nuevo proceso de adquisición. El gestor de admisión interpreta un conjunto de peticiones predefinidas y descompone cada petición en tareas. Cada una de estas tareas requiere un conjunto de recursos (CPU, disco, memoria, red) y todos ellos se enlazan para formar el gráfico de tareas (4).

(4): Gráfico de tareas: se define por un DAG (gráfico acíclico dirigido) que define dependencias y flujo resultante entre tareas. Un proceso de adquisición típico está compuesto por 7 tareas: 1) control de acceso, 2) asignación de disco, 3) asignación de recursos de red, 4) proceso de carga, 5) asignación de recursos de CPU 6) procesamiento posterior y 7) replicación del contenido al repositorio central. Con el DAG, pueden especificarse diferentes tareas que deben ejecutarse en paralelo. Por ejemplo, en este caso la tarea 1), 2) y 3) pueden bifurcarse al mismo tiempo.

(5): Gestor de recursos: cada tarea está asociada con requisitos de recursos. Este módulo se encarga de verificar que pueden realizarse todas las tareas de manera correcta teniendo en cuenta la carga de sistema actual. Si se satisface el requisito de recursos, este módulo enviará la respuesta de aceptación (6) de vuelta al gestor de admisión de tareas.

(7): Grupo de tareas: una vez que se acepta la petición de adquisición, el gestor de admisión de tareas envía el conjunto de tareas a este módulo.

(8) Planificador de tareas: tomando la lista de tareas en el grupo de tareas, este módulo realiza la planificación según las dependencias entre tareas (especificadas en el DAG) y los sellos de fecha y hora asociados con las tareas. El planificador se encarga de interactuar con la red, memoria y CPU para ejecutar todas las tareas del grupo de tareas.

(9) Repositorio de tareas: todas las posibles tareas están predefinidas en este módulo. Sólo se permiten tareas incluidas en este repositorio. El repositorio de tareas realiza procesos de actualización periódica (10) que descargan un nuevo conjunto de tareas predefinidas desde un repositorio 11 de tareas central.

-: Controlador central

El controlador central (CC) es el componente clave que coordina todo el proceso de adquisición. Este componente está estructurado en 6 subelementos, tal como se muestra en la figura 4:

(1): API del gestor de contenido (CM-API): los usuarios finales interactúan con el CC a través de este elemento. Proporciona un conjunto de funciones API para gestionar el contenido de todos los usuarios, incluyendo la creación de nuevo contenido y la eliminación de contenido existente.

(2): Gestor de contenido (CM): éste es el elemento central del CC y gestiona la metainformación relacionada con todos los contenidos. Cuando un usuario final solicita un proceso de adquisición, la CM-API (1) inicia una nueva tarea en el CM. El CM se encarga de validar el derecho de acceso del usuario final y solicita nodos de adquisición (AN) disponibles al controlador de nodo de adquisición (3). Una vez seleccionado el AN, el CM interactúa con el AN para iniciar el proceso de adquisición.

(3): Controlador de nodo de adquisición (ANC; acquisition node controller): todos los nodos de adquisición (AN) informan a este elemento. Para cada AN, el ANC conoce el estado actual, la predicción de carga en un futuro próximo, los procesos de adquisición en curso y el contenido adquirido. El ANC también proporciona una política de selección de nodo. Basándose en la ubicación geográfica del usuario final y el estado de carga de los AN, la política selecciona el nodo más cercano con la carga más baja.

(4): Controlador de acceso (AC; access controller): todos los derechos de acceso de los usuarios de la CDN se controlan por este elemento. Para cada usuario final, este elemento define el derecho de acceso, la capacidad de almacenamiento máxima y el número máximo de procesos de carga paralelos. Toda la metainformación se almacena en la base de datos de usuarios (5).

(6): Controlador de repositorio central (CRC; central repository controller): este elemento hace un seguimiento de todo el contenido adquirido en el repositorio central (7). Dado un usuario final, este elemento conoce la lista de contenido cargado. También proporciona la interfaz para que el ANC replique el contenido en el repositorio central. Cuando un AN decide replicar el contenido, interactúa con el ANC que notifica al CRC que inicie un nuevo proceso de replicación. Una vez que el CNC asigna el espacio de almacenamiento, la replicación puede iniciarse.

La invención se ha implementado sobre la solución de CDN de Telefónica. La solución de CDN de Telefónica es una solución P2P en la que los nodos de entrega (nodos de extremo) están organizados en sitios lógicos. Todos los nodos en el mismo sitio pueden intercambiar contenido mediante comunicaciones P2P.

Los nodos notifican las estadísticas de carga a un elemento centralizado denominado rastreador. El rastreador contiene información de los nodos en tiempo real y guía al DNS para seleccionar el nodo de extremo correcto, dada una petición realizada por un usuario final.

El sistema DNS en la CDN de Telefónica está estructurado según el concepto de unidades de negocio (BU, business unit). Cada unidad de negocio tiene su propio DNS y los DNS de todas las BU están interconectados por un DNS de nivel superior (TLD; top-level DNS). Basándose en la ubicación geográfica del usuario final, el TLD envía la petición de resolución de DNS a un DNS del BU local. Cada DNS del BU habla con un rastreador que tiene estadísticas de carga de todos los nodos de los que se encarga el rastreador.

El repositorio central para todos los contenidos de la CDN se denomina servidor original. Todo el contenido cargado se asigna a este repositorio central. Todos los nodos de extremo se ponen en contacto con este repositorio central para obtener la primera copia del contenido solicitado.

El nodo de adquisición se instala junto con los nodos de extremo de la CDN y comparten todos los recursos para el proceso de adquisición y entrega. El nodo de adquisición gestiona un directorio independiente, aunque se comparte el espacio de almacenamiento. En primer lugar, se carga un archivo al espacio independiente, y luego se procesa posteriormente. El archivo resultante del procesamiento posterior se mueve después al espacio del nodo de distribución y se inicia un proceso de replicación para replicar el archivo en el servidor original. Una vez replicado el archivo, se retirará por el nodo de adquisición.

Otros detalles de implementación son los siguientes:

1. Cada uno de lo nodos de extremo en la CDN de Telefónica ejecuta una instancia de nodo de adquisición.

El nodo de adquisición (AN) llama a una API de REST del software del nodo de extremo para obtener las estadísticas del nodo y construir las métricas de disponibilidad de recursos. La API de REST se define como: Sintaxis: GET /anapi/v1/nodestats Resultado: 200 OK: { cpu: 50, totalnetworkcapacityMBPS: 50, availnetworkcapacityMBPS: 50, totaldiskcapacityMB: 100000 availcapacityMB: 40000 } Cada AN llama a la API cada 30 segundos y calcula la carga de sistema mediante un promedio móvil. El nivel de carga calculado se envía de vuelta al control central cada 5 minutos.

2. El gestor de admisión de tareas del AN exporta una API de REST que define todas las operaciones que un AN puede realizar. La llamada a API más importante es /anapi/v1/newacquisition que activa un proceso de adquisición. Se pasan diferentes parámetros una vez llamada:

-: Testigo de control: sólo usuarios finales con un testigo válido pueden cargar el contenido a este nodo. El testigo está asociado con un sello de fecha y hora y es válido durante sólo 10 minutos. El testigo también se usa para formar el URL para la operación de adquisición. Un usuario final puede realizar HTTP POST contra http://NODE_IP:PORT/token para cargar el contenido.

-: Id. de contenedor: en la CDN de Telefónica, todos los archivos están organizados en contenedores lógicos.

- Nombre de archivo: el nombre de archivo de salida.

-Tamaño de archivo: el tamaño de archivo esperado.

-: DAG de operación de proceso posterior: todas las operaciones de procesos posteriores están asociadas con Id. únicos y se enlazan en el DAG.

-: El resultado de la llamada puede ser 200, de modo que el nodo acepta el proceso de adquisición. O, de lo contrario, devuelve el código 400.

3.: Repositorio de tareas: este módulo está implementado sobre el repositorio de software de CDN de Telefónica. Cada 30 minutos, se activa una tarea cron para descargar un archivo de texto que contiene todos los paquetes RPM que tienen que descargarse. Cada tarea está asociada con un ID único que puede usarse para definir las operaciones de procesos posteriores.

4.: Gestor de recursos: la implementación actual se basa en umbral rígido. Para cada tarea, se define el requisito de CPU, disco, memoria y red. El requisito puede ser una constante o una llamada de función. Por ejemplo, el requisito de disco para un vídeo se calcula como VideoSize * (1+1/R), donde R es el factor de compresión estimado para un codificador dado. Si no se satisface el requisito de recursos de cualquier tarea, el proceso de adquisición se rechazará.

5.: Planificador de tareas: la implementación actual es simplemente un planificador basado en sellos de fecha de hora, basado en planificadores en tiempo real blandos, específicamente es un algoritmo de prioridad a la tarea más urgente (EDF; Earliest Deadline First).

El controlador central se ejecuta dentro del servidor original y comparte todos los recursos de la misma manera que los nodos de adquisición lo hacen con los nodos de extremo. El controlador central tiene los siguientes detalles de implementación:

1. Selección de nodo: el mecanismo sigue 3 etapas para selección un nodo de adquisición:

-: Seleccionar todos los nodos con nivel de carga menor que un umbral (el 60%, actualmente).

-: Ordenar los nodos según la distancia virtual entre el usuario final y el nodo.

-: Seleccionar los N primeros nodos como candidatos (N=3, actualmente).

-: Ponerse en contacto, en paralelo, con los N nodos para iniciar el proceso de adquisición.

-: El primer nodo que acepte la petición será el nodo seleccionado. Los otros N-1 nodos se descartarán cancelando la petición.

La distancia virtual la proporciona la CDN de Telefónica y define un número dado cualquier par de direcciones IP. La distancia se calcula teniendo en cuenta la topología de red, saturación de red y coste operacional. Por ejemplo, un enlace transoceánico tendrá mayor coste que un enlace dentro del país, incluso la capacidad del enlace transoceánico es mucho mayor.

2.: Control de acceso: el control de derechos de acceso de los usuarios se implementa sobre la infraestructura existente. Los archivos en la CDN de Telefónica se dividen en contenedores. Un usuario final puede tener derecho de acceso a múltiples contenedores y un contenedor puede contener múltiples archivos.

3.: Controlador de nodo de adquisición: este módulo se implementa como un servicio en el servidor original y proporciona una API de REST para los informes de estado de nodo. Se ha implementado usando el entorno de django [19].

Ventajas de la invención

El sistema de adquisición distribuido propuesto en esta invención tiene varias ventajas, incluyendo alto rendimiento global de carga, alta utilización de recursos, tolerancia a fallos y bajo coste de red.

El controlador central puede dirigir la petición realizada por un usuario final a un nodo de servidor geográficamente cercano con baja latencia. La latencia inferior puede aumentar de manera potencial el rendimiento global de TCP (transmission control protocoll; protocolo de control de transmisión) y mejorar la QoS total. La figura 5 muestra la distribución CDF de la velocidad de carga de usuarios finales europeos y de todos los usuarios finales alrededor del mundo a un nodo en Madrid. Los resultados sugieren que el rendimiento global de carga promedio puede mejorarse potencialmente en un 281% con el sistema de adquisición distribuido.

En la arquitectura propuesta, la adquisición coexiste con el servicio de entrega en los mismos nodos físicos, posibilitando la compartición de recursos y mejorando la utilización del nodo. La figura 6 muestra el requisito de CPU del proceso de procesamiento posterior de un vídeo cargado en un servidor de doble núcleo. En este caso, el vídeo cargado original se codifica mediante el códec XVID con una tasa promedio de 1106,5 kbps. La duración del vídeo es de 98 minutos. El flujo de audio se codifica con mp3 con una tasa promedio de 128 kbps. El vídeo cargado se codifica a 3 tasas de transmisión de bits: 1000 kbps, 750 kbps y 500 kbps. El códec de vídeo es H264 mientras que el audio siempre se codifica como mp3 con tasa de transmisión de bits objetivo de 96 kbps, usando el códec mp3lame. El proceso de procesamiento posterior se inicia en 4:35 y finaliza en 5:40; el tiempo total es de 65 minutos. El transcodificador satura por completo 1 CPU y consume el 50% de los recursos. Sorprendentemente, el códec puede producir la misma tasa de transmisión de tramas en cada calidad y requiere un tiempo constante (21 minutos) para producir un vídeo.

Los nodos de la CDN de Telefónica actuales están basados en CPU de 8 núcleos con nivel de carga inferior al 20% en el 90% del tiempo. Teniendo en cuenta estos números y el requisito de CPU de transcodificación, es posible predecir que cada nodo de entrega ha desperdiciado recursos para transcodificar un vídeo por 3,8 minutos. Con 20 nodos alrededor del mundo, el sistema de adquisición distribuido puede procesar posteriormente un vídeo cada 12 segundos.

Otra ventaja de la propuesta es la capacidad de tolerancia a fallos del servicio de adquisición. El controlador central tiene una visión global de todos los nodos de adquisición. Una vez que se detecta un fallo, puede redirigirse una nueva petición de carga entrante a otros nodos, aunque el nodo seleccionado pueda no ser el óptimo en términos de coste de red. El controlador central es el único componente que no puede reemplazarse sin replicación de recursos. El mecanismo de replicación actual de la CDN de Telefónica se aprovecha para implementar la tolerancia a fallos del controlador central. Específicamente, el controlador central se replica en dos servidores existentes con un backend sincronizado. Los dos servidores se seleccionan de manera dinámica mediante un equilibrador que oculta la complejidad del controlador.

Un experto en la técnica puede introducir cambios y modificaciones en las realizaciones descritas sin apartarse del alcance de la invención según se define en las reivindicaciones adjuntas.

SIGLAS

AN: Acquisition Node; Nodo de adquisición

CC: Central controller; Controlador central

CDN: Content Distribution Network; Red de distribución de contenido

5: CDF Cumulative Distribution Function; Función de distribución acumulativa

DAG: Directed Acyclic Graph; Gráfico acíclico dirigido

ISP: Internet Service Provider; Proveedor de servicios de Internet

OSN: Online Social Network; Red social en línea

POP: Point of Presence; Punto de presencia

10: QoS Quality of Service; Calidad de servicio

UGC: User Generated Content; Contenido generado por usuarios

BIBLIOGRAFÍA

[1] YouTube: http://www.youtube.com

[2] YouTube traffic: http://www.website-monitoring.com/blog/2010/05/17/YouTube-facts-and-figures-historystatistics/

[3] Alan Mislove, Massimiliano Marcon, Krishna P. Gummadi, Peter Druschel y Bobby Bhattacharjee. Measurement and analysis of online social networks. In Proceedings of the 7th ACM SIGCOMM conference on Internet measurement (IMC '07). ACM, Nueva York, NY, EE.UU., 29-42.

[4] Phillipa Gill, Martin Arlitt, Zongpeng Li y Anirban Mahanti. 2007. YouTube traffic characterization: a view from the edge. In Proceedings of the 7th ACM SIGCOMM conference on Internet measurement (IMC '07). ACM, Nueva York, NY, EE.UU., 15-28.

[5] M. Cha, H. Kwak, P. Rodriguez, Yong-Yeol Ahn y S. Moon, I tube, you tube, everybody tubes: analyzing the world's largest user generated content video system. In Proceedings of the 7th ACM SIGCOMM conference on Internet measurement (IMC '07). ACM, Nueva York, NY, EE.UU., 1-14.

[6] Megaupload: http://www.megaupload.com/

[7] RapidShare: https://www.rapidshare.com/

[8] Facebook: http://www.facebook.com/

[9] Twitter: http://twitter.com/

[10] Telefonica CDN: http://test.cdn.telefonica.com/demo.html

[11] Akamai: http://akamai.com/

[12] RFC 1035, Domain Names - Implementation and Specification, P. Mockapetris, The Internet Society (Noviembre de 1987)

[13] ALU CDN: http://www.velocix.com/

[14] Limelight CDN: www.limelightnetworks.com/

[15] Amazon: www.amazon.com

[16] YouTube system architecture: http://video.google.com/videoplay?docid=-6304964351441328559#

[17] Amazon CloudFront: http://aws.amazon.com/cloudfront/

[18] Cooling System for Data centers: http://www.lamdahellix.com/%5CUserFiles%5CFile%5Cdownloads%5C25_whitepaper.pdf

[19] Django Project: https://www.djangoproject.com/

[20] Demetris Antoniades, Evangelos P. Markatos y Constantine Dovrolis. 2009. One-click hosting services: a file-sharing hideout. In Proceedings of the 9th ACM SIGCOMM conference on Internet measurement conference (IMC '09). ACM, Nueva York, NY, EE.UU., 223-234.

[21] Fabricio Benevenuto, Tiago Rodrigues, Meeyoung Cha y Virgilio Almeida, Characterizing User Behavior in Online Social Networks. In Proc. of Usenix/ACM SIGCOMM Internet Measurement Conference (IMC), Noviembre de

[22] Haewoon Kwak, Changhyun Lee, Hosung Park y Sue Moon, What is Twitter, a Social Network or a News Media? The 19th international conference on World wide web (WWW), 2010.

Claims

REIVINDICACIONES

1. Método para realizar un proceso de adquisición de contenido distribuido para una red de distribución de contenido, comprendiendo dicha red de distribución de contenido, o CDN, una pluralidad de nodos de servicio, realizándose dicho proceso de adquisición de contenido cuando un usuario final solicita cargar contenido, caracterizado porque comprende:

-

seleccionar, una entidad central que recibe una petición de carga realizada por dicho usuario final, al menos uno de dicha pluralidad de nodos de servicio según la ubicación de dicho usuario final, el estado actual de dicha pluralidad de nodos de servicio, requisitos de CPU de dicha pluralidad de nodos de servicio y/o cualquier otro parámetro de monitorización de dicha CDN;

-

dirigir, dicha entidad central, dicha petición de carga realizada por dicho usuario final a dicho al menos uno de dicha pluralidad de nodos de servicio; y

-

cargar, dicho usuario final, dicho contenido a dicho al menos uno de dicha pluralidad de nodos de servicio tras la aceptación de dicha petición de carga por dicho al menos uno de dicha pluralidad de nodos de servicio.
2.

Método según la reivindicación 1, que comprende procesar posteriormente, dicho al menos uno de dicha pluralidad de nodos de servicio, dicho contenido y propagar dicho contenido, una vez carga, a otro u otros de dicha pluralidad de nodos de servicio.
3.

Método según la reivindicación 1 ó 2, que comprende enviar dicho contenido, una vez carga, desde dicho al menos uno de dicha pluralidad de nodos de servicio a un repositorio central de dicha entidad central.
4.

Método según la reivindicación 1, 2 ó 3, que comprende realizar, dicha entidad central, una política de control de dicho contenido y/o comprobar los derechos de acceso, la capacidad de almacenamiento máxima y el número máximo de procesos de adquisición de contenido distribuido paralelos de dicho usuario final.
5.

Método según cualquiera de las reivindicaciones anteriores, que comprende calcular el consumo de recursos actual y futuro, el nivel de carga de CPU, el nivel de carga de disco, el nivel de carga de red y el nivel de carga de memoria de al menos parte de dicha pluralidad de nodos de servidor mediante medios de monitorización situados en cada nodo de servicio correspondiente y enviar dichos cálculos a dicha entidad central.
6.

Método según la reivindicación 5 cuando depende de la reivindicación 3, que comprende descomponer, dicho al menos uno de dicha pluralidad de nodos de servicio, dicha petición de carga recibida desde dicha entidad central en un conjunto de tareas, siendo dicho conjunto de tareas al menos una de la siguiente lista no cerrada: control de acceso, asignación de disco, asignación de recursos de red, proceso de carga, asignación de recursos de CPU, procesamiento posterior y replicación de contenido a dicho repositorio central.
7.

Método según la reivindicación 6, que comprende definir dicho conjunto de tareas según a gráfico acíclico dirigido.
8.

Método según la reivindicación 7, que comprende aceptar, dicho al menos uno de dichos nodos de servicio, dicha petición de carga recibida desde dicha entidad central si pueden satisfacerse los requisitos de recursos asociadas a dicho conjunto de tareas mediante recursos disponibles actuales en dicho al menos uno de dichos nodos de servicio.
9.

Sistema para realizar un proceso de adquisición de contenido distribuido para una red de distribución de contenido, comprendiendo dicha red de distribución de contenido, o CDN, una pluralidad de nodos de servicio, realizándose dicho proceso de adquisición de contenido cuando un usuario final solicita cargar contenido, caracterizado porque comprende un controlador central que se encarga de:

-

seleccionar, cuando se recibe una petición de carga realizada por dicho usuario final, al menos uno de dicha pluralidad de nodos de servicio según la ubicación de dicho usuario final, el estado actual de dicha pluralidad de nodos de servicio, los requisitos de CPU de dicha pluralidad de nodos de servicio y/o cualquier otro parámetro de monitorización de dicha CDN; y

-

dirigir, dicha entidad central, dicha petición de carga de dicho usuario final a dicho al menos uno de dicha pluralidad de nodos de servicio;

en el que dicho usuario final carga dicho contenido a dicho al menos uno de dicha pluralidad de nodos de servicio tras la aceptación de dicha petición de carga por dicho al menos uno de dicha pluralidad de nodos de servicio.
10.

Sistema según la reivindicación 9, en el que cada uno de dicha pluralidad de nodos de servicio comprende un monitor de carga de sistema que calcula el nivel de carga actual y futuro de recursos relacionados con el nodo de servicio correspondiente, y envía dichos cálculos a dicho controlador central, siendo dichos recursos al menos uno de la siguiente lista no cerrada: CPU, disco, red y memoria.
11.

Sistema según la reivindicación 10, en el que cada uno de dicha pluralidad de nodos de servicio comprende un gestor de admisión de tareas encarga de recibir dicha petición de carga desde dicho controlador central y descomponer dicha petición de carga en un conjunto de tareas, comprendiendo dicho conjunto de tareas el uso de recursos relacionados con el nodo de servicio correspondiente y siendo dichas tareas al menos una de la siguiente lista no cerrada: control de acceso, asignación de disco, asignación de recursos de red, proceso de carga, asignación de recursos de CPU, procesamiento posterior y replicación de contenido a dicho controlador central.
12.

Sistema según la reivindicación 11, en el que cada uno de dicha pluralidad de nodos de servicio comprende un gestor de recursos encarga de verificar que dicho conjunto de tareas puede llevarse a cabo según los recursos disponibles actuales en dicho al menos uno de dichos nodos de servicio y aceptar dicha petición de carga después de dicha verificación.
13.

Sistema según la reivindicación 12, en el que cada uno de dicha pluralidad de nodos de servicio comprende un grupo de tareas en el que dicho gestor de admisión de tareas envía dicho conjunto de tareas tras dicha aceptación de dicha petición de carga.
14.

Sistema según la reivindicación 13, en el que cada uno de dicha pluralidad de nodos de servicio comprende un planificador de tareas encarga de ejecutar dicho conjunto de tareas a partir de dicho grupo de tareas según un gráfico acíclico dirigido y sellos de fecha y hora asociados a dicho conjunto de tareas.
15.

Sistema según la reivindicación 14, en el que cada uno de dicha pluralidad de nodos de servicio comprende un repositorio de tareas en el que se definen todas las posibles tareas, cargándose dichas todas las posibles tareas desde un repositorio de tareas central en dicho controlador central.
16.

Sistema según cualquiera de las reivindicaciones anteriores 9 a 15, en el que dicho controlador central comprende una interfaz de programación de aplicaciones de gestor de contenido que permite que dicho usuario final interactúe con dicho controlador central proporcionando un conjunto de funciones.
17.

Sistema según la reivindicación 16, en el que dicho controlador central comprende un controlador de nodo de adquisición al que dicha pluralidad de nodos de servicio envían dichos cálculos, teniendo dicho nodo de adquisición al menos parte de la siguiente información de cada uno de dicha pluralidad de nodos de servicio: estado actual, predicción de carga futura, procesos de adquisición en curso y contenido adquirido.
18.

Sistema según la reivindicación 17, en el que dicho controlador central comprende un gestor de contenido encarga de validar los derechos de acceso de dicho usuario final y realizar dicha selección de dicho al menos uno de dicha pluralidad de nodos de servicio según información proporcionada por dicho controlador de nodo de adquisición.
19.

Sistema según la reivindicación 18, en el que dicho controlador central comprende un controlador de acceso en el que se definen dichos derechos de acceso, la capacidad de almacenamiento máxima y el número máximo de procesos de carga paralelos para dicho usuario final y se almacenan en una base de datos de usuarios.
20.

Sistema según la reivindicación 19, en el que dicho controlador central comprende un controlador de repositorio central en el que se almacena el contenido carga en cada uno de dicha pluralidad de nodos de servicio.
21. Sistema según cualquiera de las reivindicaciones anteriores, en el que dicho proceso de adquisición de contenido distribuido coexiste con un proceso de entrega de contenido distribuido en dicha pluralidad de nodos de servicio.

Figura 1

Figura 2 Figura 3

Figura 4 Figura 5

Figura 6

OFICINA ESPAÑOLA DE PATENTES Y MARCAS

N.º solicitud: 201131644

ESPAÑA

Fecha de presentación de la solicitud: 13.10.2011

Fecha de prioridad:

INFORME SOBRE EL ESTADO DE LA TECNICA

51 Int. Cl. : H04L29/08 (2006.01)

DOCUMENTOS RELEVANTES

Categoría

56 Documentos citados Reivindicaciones afectadas

X X

US 2002143798 A1 (LISIECKI PHILIP A et al.) 03.10.2002, resumen; párrafos [0013-0014],[0016],[0019],[0038-0039],[0047-0048],[0050]. US 2002078174 A1 (SIM SIEW YONG et al.) 20.06.2002, resumen; párrafos [0075-0076],[0080-0082],[0108],[0186-0189],[0226]. 1-21 1-21

Categoría de los documentos citados X: de particular relevancia Y: de particular relevancia combinado con otro/s de la misma categoría A: refleja el estado de la técnica O: referido a divulgación no escrita P: publicado entre la fecha de prioridad y la de presentación de la solicitud E: documento anterior, pero publicado después de la fecha de presentación de la solicitud

El presente informe ha sido realizado • para todas las reivindicaciones • para las reivindicaciones nº:

Fecha de realización del informe 24.09.2013

Examinador M. L. Álvarez Moreno Página 1/4

INFORME DEL ESTADO DE LA TÉCNICA

Nº de solicitud: 201131644

Documentación mínima buscada (sistema de clasificación seguido de los símbolos de clasificación) H04L Bases de datos electrónicas consultadas durante la búsqueda (nombre de la base de datos y, si es posible, términos de

búsqueda utilizados) INVENES, EPODOC, WPI, Inspec

Informe del Estado de la Técnica Página 2/4

OPINIÓN ESCRITA

Nº de solicitud: 201131644

Fecha de Realización de la Opinión Escrita: 24.09.2013

Declaración

Novedad (Art. 6.1 LP 11/1986)

Reivindicaciones Reivindicaciones 1-21 SI NO

Actividad inventiva (Art. 8.1 LP11/1986)

Reivindicaciones Reivindicaciones 1-21 SI NO

Se considera que la solicitud cumple con el requisito de aplicación industrial. Este requisito fue evaluado durante la fase de examen formal y técnico de la solicitud (Artículo 31.2 Ley 11/1986).

Base de la Opinión.-

La presente opinión se ha realizado sobre la base de la solicitud de patente tal y como se publica.

Informe del Estado de la Técnica Página 3/4

OPINIÓN ESCRITA

Nº de solicitud: 201131644

1. Documentos considerados.-

A continuación se relacionan los documentos pertenecientes al estado de la técnica tomados en consideración para la realización de esta opinión.

Documento

Número Publicación o Identificación Fecha Publicación

D01

US 2002143798 A1 (LISIECKI PHILIP A et al.) 03.10.2002
2. Declaración motivada según los artículos 29.6 y 29.7 del Reglamento de ejecución de la Ley 11/1986, de 20 de marzo, de Patentes sobre la novedad y la actividad inventiva; citas y explicaciones en apoyo de esta declaración

Reivindicación independiente 1

El documento D01 muestra una red de distribución de contenido (resumen, párrafos [0013-0014; 0016; 0038-0039; 0050]) en el que cuando la entidad central (Traffic Management System) recibe una petición de carga se redirige al usuario hacia un destino específico seleccionado de entre una pluralidad. Posteriormente el usuario (Content Provider) realiza la carga en dicho destino. La selección del destino se realiza pudiendo tener en cuenta diversos parámetros de monitorización de la red (p.ej., carga del servidor, condiciones del tráfico de red, latencia). Las etapas definidas en la reivindicación 1 (selección de un nodo de destino en función de cualquier parámetro de monitorización de la red; dirigir la petición de carga hacia dicho nodo seleccionado y realizar la carga del contenido) se encuentran anticipadas en el documento D01. La reivindicación 1 carece de novedad según el artículo 6 de la Ley de Patentes.

Reivindicaciones dependientes 2 y 3

El documento D01 muestra que una vez recibido el contenido en el nodo seleccionado (Resumen; párrafos [0014, 0019]) se realiza una propagación del mismo. Las reivindicaciones 2 y 3 carecen de novedad según el artículo 6 de la Ley de Patentes.

Reivindicación dependiente 4

El documento D01 [párrafo 0047] muestra que se realiza una política de control de contenido, derechos de acceso y que la entidad central realiza un control de los procesos paralelos. La reivindicación 4 carece de novedad según el artículo 6 de la Ley de Patentes.

Reivindicaciones dependientes 5 a 8

El documento D01 [párrafos 0013-0014; 0038-0039; 0048; 0050] ya muestra que se dispone de los medios de monitorización apropiados para realizar las diversas tareas previstas en los distintos nodos: carga, propagación y descarga. Realizándose una comprobación de los distintos nodos y su capacidad para llevar a cabo la acciones requeridas (p.ej. estado de carga del servidor, condiciones de tráfico de la red). La descomposición de una actividad en tareas y la comprobación de la disponibilidad de los recursos necesarios para su realización es evidente para un experto en la materia. Las reivindicaciones 5 a 8 carecen de novedad según el artículo 6 de la Ley de Patentes.

Reivindicaciones independiente 9

El sistema definido en la reivindicación 9 viene caracterizado por disponer de un controlador central encargado de realizar las etapas definidas en la reivindicación 1. Cómo ya se ha indicado anteriormente, el documento D01 dispone de un controlador central (Traffic Management System) encargado de realizar dichas tareas (resumen, párrafos [0013-0014; 0016; 0038-0039; 0050]). La reivindicación 1 carece de novedad según el artículo 6 de la Ley de Patentes.

Reivindicaciones dependientes 10 a 21

El sistema definido en las reivindicaciones 10 a 21 viene definido por disponer de los medios funcionales apropiados (monitor de carga, gestor/planificador de tareas, controlador de acceso, gestor de contenido...) para realizar las acciones previamente indicadas en las reivindicaciones de procedimiento. Ya se ha indicado anteriormente que el documento D01 realiza dicho conjunto de tareas (resumen, párrafos [0013-0014; 0016; 0038-0039; 0048; 0050]) por lo que dispone de los medios funcionales apropiados. Las reivindicaciones dependientes 10 a 21 carecen de novedad según el artículo 6 de la Ley de Patentes.

Informe del Estado de la Técnica Página 4/4