Patent Application
20140325577
The present invention generally relates, in a first aspect, to a method to perform a distributed content acquisition process for a Content Delivery Network, said CDN comprising a plurality of server nodes, said content acquisition process being performed when an end-user requests uploading content, and more particularly to a method that comprises selecting at least one of said plurality of server nodes, directing said uploading request from said end-user to said at least one of said plurality of server nodes and uploading said content to said at least one of said plurality of server nodes upon acceptance of said uploading request by said at least one of said plurality of server nodes.
A second aspect of the invention relates to a system arranged to implement the method of the first aspect.
A CDN (Content Distribution Network) is a full geographically distributed system with objective to replicate contents to servers that are close to the end-users. All CDN system designs are based on the assumption that most contents in Internet are accessed multiple times once it produced. The implication of this assumption is that bandwidth requirement for content acquisition is considered be negligible compared to the one for the distribution. As consequence, all the current CDN systems [1] [2] [3] are optimized for content distribution rather than content acquisition.
With evolution of Web 2.0, the content consumption pattern has been traumatically changed. Current Internet users are no longer consumers of the content; they are actively participating in the entire chair of the content, from production and addiction to distribution and consume. Online UGC (user generated content) portals such as YouTube [1], allow users to upload the own videos, or modifications of previously downloaded videos, to share with other online users. Other web sites such as Megaupload [6] or RapidShare [7] are even more radicals. With these one-click hosting services [20], end-users can upload any content they want, from videos to DVD ISO files. According to report [2], 24 hours of raw video is being uploaded to YouTube per minute. In term of bandwidth, users around the world can be pushing content to YouTube servers with a rate of 1.4 Gbps.
Other characteristic of Web 2.0 is the speedup of information propagation process. The OSNs, such as Facebook [8] or Twitter [9] allows users to send notifications (tweets) to their direct-connected online friends (or follower in Twitter). The received information is then propagated to another thousand friends of the friend. In an OSN, information or tweets can quickly be propagated to end-users as a cascade [21] [22]. The pandemic nature of OSNs incentives group of users to start simultaneously pushing information to the network, producing well-known phenomenon called flash-crowd.
The content production democratization and fast information propagation brings new challenges for current and next generation online services where the backend system has often to handle flash-crowds, driven by unpredictable end-user social interactions. There have been several measurement studies 00 to analyze online services, such as YouTube. In [3] authors even discussed the potential of P2P system to improve the video distribution, but the uploading process is still not considered.
CDNs typically operate as single global entities; have multiple points of presence and in locations that are geographically far apart. CDN used to have multiple replicas of each piece of content that is hosted for a CDN customer. The first copy (master copy) of the content, however, is only hosted in a single point, called the origin server. The origin server allows the CDN customers to upload the content that they are interested to distribute to the end-users. For this proposes, CDN providers normally define a standard API that facilitates the content publication. Some CDN providers [10] allocate a FTP space for each customer. Other CDN vendors deploy remote sync functionalities that allow CDN customers to mirror a server folder to the origin server. Typical CDN providers also implement the pull-based mechanisms. With pull-based mechanisms, the CDN customers do not publish the content to the CDN. The CDN is on charge to bring all contents from predefined servers when are being requested by the end-users.
A part of the content publication mechanism, CDN can only differentiate by a set of other characteristics, such as node selection or node allocation strategy. For example, in [11] it is used a hierarchy of DNS [12] servers together with geo-location information to find the content server that is closest to a requesting end-user to serve content. Other solutions [13] use HTTP redirection mechanism to implement node selection. Solutions like [14] rely on a small number of large datacenters rather than a large number of small datacenters connected by a well-provisioned private network [11]. Further, [16] relies on extensive storage and caching infrastructure at the major peering points to reduce the bandwidth cost. Amazon [15] provides CDN service using Amazon CloudFront [17] together with its simple storage service allowing end-users to get data from various edge locations of the Internet that Amazon peers with.
Regardless of the content publication mechanism and other architecture characteristics, the current CDN designs are all based on a centralized origin server to handle the master copy of the customer content.
A centralized architecture can only handle a limited number of parallel acquisition processes and it is constrained by different system resources, including network bandwidth, memory size, CPU capacity and disk read/write throughput.
Scaling Constrains
The common practice to scale the data acquisition service is replicating server nodes inside the datacenter. This technique, however, is not always possible due to the space limitations and power constrains. For instance, some rack vendors offer a limited number of slots for CPU/storage elements. Scaling inside the datacenter is neither cost-effective because the non-linearity of the cost of the cooling system. For large datacenters, the cooling system has to provide lower temperature to overcome the recirculation effects of the higher temporal equipment exhaust air [18]. Furthermore, up to 30% of extra cooling power can be required to supply a constant humidity level to all the IT elements.
Low-Level Resource Utilization
In current CDN systems, data acquisition and data delivery are isolated services and are allocated in independent machines, resulting in substantial system resource inefficiency related with node inactivity. Depending on workload characteristics, the current server nodes may only need 10-20% of CPU resource to full saturate the network link. The 80-90% of remaining resources is just wasted and could be utilized by CPU intensive operations such as video post-processing for user uploaded contents.
Determined by human behavior of different time zones, CDN nodes experience high demands during only a certain period of day. In order to manage the diurnal network demand, CDN nodes are normally over-provisioning and, as consequence, suffer low-level utilization across time.
Low Uploading Performance
Uploading content to a single centralized point can suffer from high latency and low throughput.
High Network Cost
Having a centralized acquisition point involves longer transmission paths and consumes more network resources.
It is necessary to offer an alternative to the state of the art which cover the gaps found therein, particularly related to the lack of proposals which really offer a distributed architecture with a scalable content acquisition mechanism and which really allow reducing the replication cost of uploaded contents to other delivery nodes.
To that end, the present invention provides, in a first aspect, a method to to perform a distributed content acquisition process for a Content Delivery Network, said Content Delivery Network, or CDN, comprising a plurality of server nodes, said content acquisition process being performed when an end-user requests uploading content.
On contrary to the known proposals, the method of the invention, in a characteristic manner it further comprises:
Other embodiments of the method of the first aspect of the invention are described according to appended claims 2 to 8, and in a subsequent section related to the detailed description of several embodiments.
A second aspect of the present invention concerns to a system to perform a distributed content acquisition process for a Content Delivery Network, said Content Delivery Network, or CDN, comprising a plurality of server nodes, said content acquisition process being performed when an end-user requests uploading content.
In the system of the second aspect of the invention, on contrary to the known systems mentioned in the prior state of the art section, and in a characteristic manner it comprises a central controller in charge of:
The system of the second aspect of the invention is adapted to implement the method of the first aspect.
Other embodiments of the system of the second aspect of the invention are described according to appended claims 10 to 21, and in a subsequent section related to the detailed description of several embodiments.
The previous and other advantages and features will be more fully understood from the following detailed description of embodiments, with reference to the attached drawings (some of which have already been described in the Prior State of the Art section), which must be considered in an illustrative and non-limiting manner, in which:
The invention is about a distributed content acquisition system for CDN. In this system, all delivery nodes of a CDN are coordinated to allow any particular end-user (home user as well as CDN customers) to upload content to the node storage. The uploaded content is then post-processed and propagated to other delivery nodes.
All delivery nodes report load state to a centralized controller. According to the state of delivery nodes, geolocation of the uploader and CPU requirement for post-processing, the controller selects the best delivery node for the acquisition process.
A replication process follows the acquisition process, where the delivery node sends the acquired content to a centralized repository. The centralized repository guarantees the availability of content and performs all the control policy, such as access right control or content available period.
The distributed acquisition system is composed by 2 main elements: Acquisition Nodes and Central Controller.
Acquisition Node
An acquisition node (AN) is composed by a set of software elements that can run both in same physical delivery nodes as well as in independent machines. The seamless integration of acquisition with delivery nodes provides deployment advantages and high resource utilization.
In
(1) System load monitor (SLM): this component constantly tracks resource consumption level of the node by using different monitors that calculate the load level of CPU, disk, network and memory. Using real-time load levels, the SLM calculates the current and near future load level. The system load is then, periodically, reported to the central controller (2).
(3) Task admission Manager (TAM): the central controller communicates with this component whenever a new acquisition process is requested. The admission manager interprets a set of predefined requests and discomposes each request in tasks. Each of these tasks requires a set of resources (CPU, disk, memory, network) and all of them are linked to form the task graph (4).
(4) Task graph: is defined by a DAG (Directed Acyclic Graph) that defines dependences and result flow between tasks. A typical acquisition process is composed by 7 tasks: 1) access control, 2) disk allocation, 3) network resource allocation, 4) uploading process, 5) CPU resource allocation 6) post-processing, and 7) content replication to central repository. With DAG, different tasks can be specified to be run in parallel. For instance, task 1), 2) and 3) can be forked in same time in this case.
(5) Resource Manager: each task is associated with resource requirements.
This module is on charge to verify that all tasks can be performed correctly taking into account the current system load. If resource requirement is satisfied, this module will send the acceptance answer (6) back to task admission manager.
(7) Task Pool: once the acquisition request is accepted, the task admission manager sends the set of tasks to this module.
(8) Task scheduler: taking the list of tasks in the task pool, this module performs the scheduling according to the task dependences (specified in DAG) and timestamps associated with tasks. The scheduler is on charge to interact with network, memory and CPU to execute all tasks from the task pool.
(9) Task repository: all possible tasks are pre-defined in this module. Only tasks in this repository are allowed. The task repository performs periodical update processes (10) that download new set of predefined tasks from a central task repository, 11.
Central Controller
The central controller (CC) is the key component that coordinates all the acquisition process. This component is structured in 6 sub elements, as shown in
(1) Content manager API (CM-API): the end-users interact with CC through this element. It provides a set of API functions to manager the content of all users, including creation of a new content and delete of a exist content.
(2) Content Manager (CM): this is the core element of CC and manages the meta infomation related with all contents. When an end-user requests an acquisition process, the CM-API (1) starts a new task in CM. The CM is on charge to validate the access right of the end-user and request available acquisition nodes (ANs) from acquisition node controller (3). Once AN is selected, CM interact with the AN to start the acquisition process.
(3) Acquisition Node Controller (ANC): all acquisition nodes (AN) report to this element. For each AN, ANC knows the current state, the near future load prediction, the ongoing acquisition processes and acquired contents. ANC also provides node selection policy. Bases on geolocation of the end-user and load state of ANs, the policy select the closest node with lowest load.
(4) Access Controller (AC): all access right of CDN users are controlled by this element. For each end-user, this element defines the access right, the maximum storage capacity and the maximum number of parallel upload processes. All the meta information is stored in the user database (5).
(6) Central Repository Controller (CRC): this element tracks all acquired content in the central repository (7). Given an end-user, this element knows the list of uploaded content. It also provides interface for ANC to replicate the content in the central repository. When an AN decides to replicate the content, it interacts with ANC which notifies the CRC to start a new replication process. Once the CNC allocates the storage space, the replication can be started.
The invention has been implemented in the top of the Telefonica CDN solution. The Telefonica CDN solution is a P2P solution where delivery nodes (endpoints) are organized in logical sites. All nodes in the same site can exchange content by P2P communications.
Nodes report load statistics to a centralized element called tracker. The tracker contains information of nodes in real time and guides the DNS to select the correct endpoint, given an end-user request.
The DNS system in Telefonica CDN is structured in concept of business units (BU). Each business unit has own DNS and the DNSs of all BUs are interconnected by a top-level DNS (TLD). Based on geolocation of end-user, the TLD forward the DNS resolution request to a local BU's DNS. Each BU's DNS talks with a tracker that has load statistics of all nodes that the tracker is on charge of.
The central repository for all contents of the CDN is called the Origin Server. All uploaded content is allocated in this central repository. All endpoints contact with this central repository to get first copy of the requested content.
Acquisition node runs together with CDN endpoints and share all the resources for delivery and acquisition process. An independent directory is managed by the acquisition node, however, the storage space is shared. A file is uploaded, first, to the independent space, and then it is post-processed. The result file of post-processing is then moved to the delivery node space and a replication process is started to replica the file to the origin server. Once the file is replicated, it will be removed by the acquisition node.
Other implementation details are the following:
1. Each of endpoints in the Telefonica CDN runs an instance of acquisition node. The acquisition node (AN) calls a REST API of the endpoint software to get statistics of the node and build the resource availability metrics. The REST API is defines as:
Each AN calls the API every 30 seconds and calculate the system load by a moving average. The calculated load level is sent back to the Central Control every 5 minutes.
2. Task admission manager of the AN export a REST API that define all operations that an AN can performs. The most important API call is /anapi/v1/newacquisition that activates an acquisition process. Different parameters are passed one the call:
3. Task repository: this module is implemented on the top of the Telefonica CDN software repository. Each 30 minutes, a cron job is activated to download a text file that contains all RPM packets that has to be downloaded. Each task is associated with a unique ID that can be used to define the post-process operations.
4. Resource manager: current implementation is hard threshold based. For each task, CPU, disk, memory and network requirement is defined. The requirement can be a constant or a function call. For instance, the disk requirement for a video is calculated as VideoSize*(1+1/R), where R is the estimated compression factor for a given encoder. If the resource requirement of any task is not satisfied, the acquisition process will be rejected.
5. Task scheduler: current implementation is just a timestamp-based scheduler based one soft real-time schedulers, specifically it is an Earliest Deadline First (EDF) algorithm.
Central controller runs inside the Origin Server and share all resources in same way as the acquisition nodes do with the endpoints. The central controller has following implementation details:
1. Node Selection: the mechanism following 3 steps to select an acquisition node:
The virtual distance is provided by the Telefonica CDN and defines a number given any pair of IP address. The distance is calculated taking into account the network topology, network saturation and operational cost. For instance a transoceanic link will have higher cost than a link inside the country, even the capacity of transoceanic link is much higher.
2. Access control: the user access right control is implemented in the top of existing infrastructure. Files in Telefonica CDN are divided in buckets. An end-user may have access right to multiple buckets and a bucket can contain multiple files.
3. Acquisition node controller: this module is implemented as a service in the Origin Server and provides a REST API for node state reports. It has been implemented by using django framework [19].
The distributed acquisition system proposed in this invention has several advantages, including high upload throughput, high resource utilization, fault tolerance and low network cost.
The central controller is able to direct the end-user request to a server node geographically close-by with low latency. The lower latency can potentially increase the TCP throughput and improve the overall QoS.
In the proposed architecture, the acquisition coexists with delivery service in the same physical nodes, enabling resource sharing and improving the node utilization.
The current Telefonica CDN nodes are based on 8 cores CPUs with load level less than 20% in 90% of time. Taking into account these numbers and the transcoding CPU requirement, it is possible to predict that each delivery node has wasted resource to transcode one video per 3.8 Minutes. With 20 nodes around the world, the distributed acquisition system can potential post-process one video every 12 seconds.
Other advantage of the proposal is fault tolerance capability of the acquisition service. The central controller has a global view of all acquisition nodes. Once a failure is detected, new incoming upload request can be redirected to other nodes, although the selected node may not be the optimal in term of network cost. The central controller is the unique component that cannot be replaced without resource replication. The current replication mechanism of Telefonica CDN for origin is leveraged to implement fault tolerance of the central controller. Specifically, the central controller is replicated in two existent servers with a synchronized backend. The two servers are dynamically selected by a balancer that hides the complexity of the controller.
A person skilled in the art could introduce changes and modifications in the embodiments described without departing from the scope of the invention as it is defined in the attached claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| P201131644 | Oct 2011 | ES | national |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/EP2012/070106 | 10/11/2012 | WO | 00 | 5/8/2014 |
