WO2016064303A1 - Method for distributing load among servers of a content delivery network (cdn) - Google Patents

Method for distributing load among servers of a content delivery network (cdn) Download PDF

Info

Publication number
WO2016064303A1
WO2016064303A1 PCT/RU2015/000693 RU2015000693W WO2016064303A1 WO 2016064303 A1 WO2016064303 A1 WO 2016064303A1 RU 2015000693 W RU2015000693 W RU 2015000693W WO 2016064303 A1 WO2016064303 A1 WO 2016064303A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
cdn
route
address
servers
Prior art date
Application number
PCT/RU2015/000693
Other languages
French (fr)
Russian (ru)
Inventor
Ярослав Игоревич ГОРОДЕЦКИЙ
Сергей Владимирович ИВЛЕНКОВ
Original Assignee
Общество с ограниченной ответственностью "СДН-видео"
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Общество с ограниченной ответственностью "СДН-видео" filed Critical Общество с ограниченной ответственностью "СДН-видео"
Publication of WO2016064303A1 publication Critical patent/WO2016064303A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions

Definitions

  • the claimed invention relates to the field of CDN networks (content delivery networks), in particular, to a method of load balancing between servers in such networks.
  • An analogue of the claimed invention is a method of load balancing between CDN servers (WO 0184356 A2, 11/08/2001, G06F 17/00), in which a service request is received from a user on a central server, the user's location is determined by his address, and the user’s location is adjusted the CDN server address selected from the set of CDN server addresses, and a route is established for communication between the user and the corresponding CDN server, while the CDN server address is selected based on the route metric selected from the group: the unified delay of data transmission on the route, the average processing time of information on the CDN server, the bandwidth of the route, the load of the CDN server.
  • the disadvantages of this method is the insufficient assessment of the network situation when choosing a candidate route.
  • this method does not provide mechanisms for flexible route changes in case of failure of a previously selected CDN server.
  • the central server is a system vulnerability during a critical increase in load.
  • the prototype of the claimed invention is "METHOD FOR LOAD DISTRIBUTION BETWEEN CONTENT DELIVERY NETWORK SERVERS (CDN)", in which they accept a service request from the terminal of the user on the server, the user address is determined, the CDN server address selected from the plurality of CDN server addresses is brought into correspondence with the user address, and a route is selected for the user to communicate with the corresponding CDN server, and matching is carried out using the candidate route database on the server, and the route is selected based on the route metric selected from the group: delay, delay variation, load, percentage (or number) of packet loss, number of hopes, number of
  • the autonomy systems, the Q-criterion additionally provide an interval of permissible values for each route metric and, if the route metric is not included in the specified interval, exclude the corresponding route from the corresponding database of candidate routes and, in addition, monitor activity of all CDN servers in real time using the fault detection tool connected to the server, and in case of detection of a failure condition of the
  • each “edge” node - a server in the topology of the CDN network needs to allocate "public" addresses for each published resource (in fact, each client (not the user). This is necessary for balancing and processing requests
  • version 4 IP addresses have come to an end and are issued by the RIPE Institute with restrictions, which leads to a shortage of IP addresses (ipv4) and limits the development of the CDN network infrastructure, ie the prototype is dependent on the availability of free IP addresses (which are about our to) does not notice the change in the structure rcuit
  • the technical result of the claimed invention is the aggregation of user queries at the level of data centers and their distribution in a CDN cluster via an SDN controller. That is, the addition of each new network node does not lead to the need to allocate new "public" addresses, thus increasing the scalability of CDN network performance.
  • the technical result achieved is that; that in the method of load balancing between the servers of the content delivery network (cdn), in which a service request is received from at least one user terminal on at least one server, the user address is determined, the CDN address is mapped to the user address a server selected from a plurality of CDN server addresses. Next, a route is selected for user communication with the corresponding CDN server.
  • the alignment is carried out by means of at least one database of candidate routes formed on at least one server.
  • the route is selected based on at least one route metric selected from the group: delay, delay variation, load, percentage (or number) of packet loss, number of hopes, number of autonomous systems, Q-criterion.
  • an interval of acceptable values is provided for each route metric, and if the route metric is not included in the specified interval, the corresponding route is excluded from the corresponding database of candidate routes.
  • they monitor the activity of all CDN servers in real time using a fault detection tool connected to at least one server. In this case, if a condition is found failure of the CDN server, information about the status and address of such a CDN server is entered into the corresponding database of at least one server and is then not taken into account when choosing a route.
  • the network node ceases to be, on the one hand, only a caching server, it becomes a structural unit with its own intelligence at the node level, and on the other hand, no changes have occurred for the common CDN. No need to allocate "public" IP addresses for each published stream or data, which allows not to limit the development of the network in conditions of a shortage of IP addresses.
  • scheme 1 shows the distribution of load between the servers of the content delivery network.
  • a service request is received from at least one user terminal on at least one server
  • a CDN server address is mapped to a user address selected from a plurality of CDN server addresses.
  • a route is selected for user communication with the corresponding CDN server.
  • the alignment is carried out by means of at least one database of candidate routes formed on at least one server.
  • the route is selected based on at least one route metric selected from the group: delay, delay variation, load, percentage (or number) of packet loss, number of hopes, number of autonomous systems, Q-criterion.
  • an interval of acceptable values is provided for each route metric, and if the route metric is not included in the specified interval,ayne M is the corresponding route from the corresponding database of candidate routes.
  • the activity of all CDN servers is monitored in real time using a failure detection tool connected to at least one server.
  • information about the status and address of such a CDN server is entered into the corresponding database of at least one server and is then not taken into account when choosing a route.
  • the network node ceases to be, on the one hand, only a caching server, it becomes a structural unit with its own intelligence at the node level, and on the other hand, no changes have occurred for the common CDN.
  • at least one server is provided in the CDN system, on which, using the means of collecting and storing information, a candidate route database (routing table) is formed for each of the system’s CDN servers, consisting of IP prefixes.
  • Such a server may be, in particular, one or more CDN servers or one or more specialized central servers (backup servers). Further in the description, the term “server” means either a CDN or a specified central server. If several such servers are used in the system, their functionality is duplicated on each of these servers.
  • the specified database is formed, in particular, on the basis of data from open sources (GeoIP database, RIPE database, robtex.com website, lists of regional IP servers, etc.); route information __
  • each of the CDN servers can regularly, after a specified period of time (for example, 1 time per day), trace the route to a randomly selected IP address inside its IP prefix. At the same time, at least one of the following is collected: delay, variation of delay, load, percentage (or number) of packet loss, number of hopes, number of autonomous systems, Q-criterion (sum of the number of hopes and the number of autonomous systems).
  • metrics are entered in the table of candidate routes of this server for further processing with the recording of this information in the database. Metrics can also be transferred to one or more CDN servers for processing and writing to the appropriate database.
  • the collected parameters can be checked for compliance with predetermined value ranges (thresholds). If this or that route is recognized as inappropriate according to the specified parameters, it is excluded from the database (s).
  • a blacklist of prefixes can be generated for each of the CDN servers, to which the server does not have the right to direct traffic.
  • the list is formed on the basis of at least one of: analysis of log files (a large percentage of errors during file transfer, frequent cases of video buffering), based on information received from users or as a result of analysis carried out by system administrators of the CDN system.
  • analysis of log files a large percentage of errors during file transfer, frequent cases of video buffering
  • a check is made to see if the prefixes of candidate routes are blacklisted; if they do, such routes are eliminated.
  • the presence of information on the average connection speed for one or another IP prefix can be checked in the log files of the CDN server. If such information is statistically reliable, it is entered into the database of candidate routes.
  • CDN system servers can be continuously monitored in the system to determine their activity through the fault detection tool.
  • a CDN server is deprived of active status if this CDN server satisfies the failure condition: it is unavailable, or is overloaded, or too many percent of users receive refusals to display content, or too often the video is buffered.
  • the specified information is sent to the server in the form of information about the status of the CDN server and its address, is entered into the database and then taken into account when choosing routes from the list of candidate routes.
  • real-time monitoring of the status of CDN servers allows you to build a route taking into account the characteristics of the content of the service, which is not provided by the current level of technology.
  • the present invention provides for taking into account the quality of video display (including the buffering frequency) when determining the optimal route. Also, such monitoring allows to increase the fault tolerance of the CDN system (indicating the status of the CDN server), and increase its flexibility in general.
  • the present invention provides for taking into account the boundaries of the networks of Internet providers when determining the optimal route using the Q-criterion, which is the sum of the number of routers and autonomous systems on the route.
  • the use of the Q-criterion reflects the fact that a deterioration in the quality of communication on the intranet routers of Internet providers occurs There are tv routers installed on the borders of the networks of Internet providers, due to the greater load of the latter.
  • the communication lines indicated in this application can be either wired or wireless communication lines, such as WiFi, CDMA, LTE, and the like.
  • the corresponding at least one database is hosted on the corresponding at least one server. It is obvious that the databases can duplicate each other, and each of the aforementioned CDN server and / or servers can be configured to exchange data with each other via respective communication lines.
  • the network node ceases to be, on the one hand, only a caching server, it becomes a structural unit with its own intelligence at the node level, and on the other hand, no changes have occurred for the common CDN. No need to allocate "public" IP addresses for each published stream or data, which allows not to limit the development of the network in conditions of a shortage of IP addresses.
  • Ec1 e (caching) servers are combined into nodes or clusters representing one high-performance node that requires only one "public" IP address.
  • the main or upper-level balancing is carried out between aggregated nodes, which include several "edge” servers. This group begins to possess uniform balancing metrics and in the presentation of the balancing algorithm is one node.
  • balancing is done by the SDN controller, which performs two functions. The first, carries out internal load balancing according to the built-in algorithms, and the second, accumulates system parameters to represent aggregate system metrics for working with the CDN balancer.
  • the delivered technical result is achieved: aggregation of user queries at the data center level and their distribution in the CDN cluster by means of the SDN controller. That is, the addition of each new network node does not lead to the need to allocate new "public” addresses, thus increasing the performance of the CDN network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

The invention relates to the field of content delivery networks (CDN networks), and more particularly to a method for distributing the load among servers in such networks. In the present method: a request for a service is received from a user terminal by a server, the user address is identified, a CDN server address selected from a plurality of CDN server addresses is matched to the user address, and a path is selected for connecting the user to the relevant CDN server. The path is selected on the basis of at least one route metric selected from the group: delay, delay variation, load, percentage (or number) of packets lost, hop count, autonomous system count and Q-criterion, and a range of permissible values is provided for each route metric. The activity of all of the CDN servers is monitored in real time using a failure detection means connected to a server; in the event that a CDN server failure is detected, information about the status and address of the CDN server in question is entered into the relevant database of a server and is no longer taken into consideration during selection of a route.

Description

СПОСОБ РАСПРЕДЕЛЕНИЯ НАГРУЗКИ МЕЖДУ СЕРВЕРАМИ СЕТИ ДОСТАВКИ КОНТЕНТА (CDN).  METHOD FOR LOAD DISTRIBUTION BETWEEN CONTENT DELIVERY NETWORK SERVERS (CDN).
Заявленное изобретение относится к области сетей CDN (сетей доставки контента), в частности, к способу распределения нагрузки между серверами в таких сетях. The claimed invention relates to the field of CDN networks (content delivery networks), in particular, to a method of load balancing between servers in such networks.
Аналогом заявленного изобретения является способ распределения нагрузки между CDN-серверами (WO 0184356 А2, 08.11.2001 , G06F 17/00), при котором принимают запрос на услугу от пользователя на центральном сервере, определяют местоположение пользователя по его адресу, приводят в соответствие местоположению пользователя адрес CDN-сервера, выбранный из множества адресов CDN-серверов, и устанавливают маршрут для связи пользователя и соответствующего CDN-сервера, при этом выбор адреса CDN-сервера осуществляют на основании метрики маршрута, выбранной из группы: усредненной задержки передачи данных на маршруте, усредненного времени обработки информации на CDN-сервере, полосы пропускания маршрута, нагрузки CDN-сервера. Недостатками указанного способа является недостаточная оценка сетевой ситуации, при выборе маршрута-кандидата. Кроме того, указанный способ не предоставляет механизмов гибкого изменения маршрута в случае выхода из строя ранее выбранного CDN-сервера. Кроме того, в указанном способе центральный сервер является уязвимым местом системы при критическом возрастании нагрузки. An analogue of the claimed invention is a method of load balancing between CDN servers (WO 0184356 A2, 11/08/2001, G06F 17/00), in which a service request is received from a user on a central server, the user's location is determined by his address, and the user’s location is adjusted the CDN server address selected from the set of CDN server addresses, and a route is established for communication between the user and the corresponding CDN server, while the CDN server address is selected based on the route metric selected from the group: the unified delay of data transmission on the route, the average processing time of information on the CDN server, the bandwidth of the route, the load of the CDN server. The disadvantages of this method is the insufficient assessment of the network situation when choosing a candidate route. In addition, this method does not provide mechanisms for flexible route changes in case of failure of a previously selected CDN server. In addition, in this method, the central server is a system vulnerability during a critical increase in load.
Прототипом заявленного изобретения является «СПОСОБ РАСПРЕДЕЛЕНИЯ НАГРУЗКИ МЕЖДУ СЕРВЕРАМИ СЕТИ ДОСТАВКИ КОНТЕНТА (CDN)», при котором принимают запрос на услугу от терминала пользователя на сервере, определяют адрес пользователя, приводят в соответствие адресу пользователя адрес CDN-сервера, выбранный из множества адресов CDN-серверов и выбирают маршрут для связи пользователя с соответствующим CDN-сервером, причем приведение в соответствие осуществляют посредством базы данных маршрутов- кандидатов, сформированной на сервере, при этом выбор маршрута осуществляют на основании метрики маршрута, выбранной из группы: задержки, вариации задержки, нагрузки, процента (или числа) потери пакетов, количества хопов, количества автономных систем, Q-критерия, при этом дополнительно предусматривают интервал допустимых значений для каждой метрики маршрута и, в случае, если метрика маршрута не входит в указанный интервал, исключают соответствующий маршрут из соответствующей базы данных маршрутов-кандидатов и, кроме того, производят мониторинг активности всех CDN-серверов в режиме реального времени при помощи средства обнаружения отказов, соединенного с сервером, при этом в случае обнаружения условия отказа CDN-сервера, информацию о статусе и адресе такого CDN-сервера заносят в соответствующую базу данных сервера и далее не учитывают при выборе маршрута. The prototype of the claimed invention is "METHOD FOR LOAD DISTRIBUTION BETWEEN CONTENT DELIVERY NETWORK SERVERS (CDN)", in which they accept a service request from the terminal of the user on the server, the user address is determined, the CDN server address selected from the plurality of CDN server addresses is brought into correspondence with the user address, and a route is selected for the user to communicate with the corresponding CDN server, and matching is carried out using the candidate route database on the server, and the route is selected based on the route metric selected from the group: delay, delay variation, load, percentage (or number) of packet loss, number of hopes, number of In this case, the autonomy systems, the Q-criterion, additionally provide an interval of permissible values for each route metric and, if the route metric is not included in the specified interval, exclude the corresponding route from the corresponding database of candidate routes and, in addition, monitor activity of all CDN servers in real time using the fault detection tool connected to the server, and in case of detection of a failure condition of the CDN server, information about the status and address of such a CDN server faith is entered into the appropriate server database and is then not taken into account when choosing a route.
В силу своей архитектуры каждому пограничному узлу "edge''-серверу в топологии CDN-сети (кэширующему серверу) необходимо выделение "публичных" адресов для каждого опубликованного ресурса (по сути каждому клиенту (не пользователю). Это необходимо для осуществления балансировки и обработки запросов пользователей. На сегодня IP-адреса версии 4 подошли к концу и выдаются институтом "RIPE" с ограничениями, что приводит к нехватке IP-адресов (ipv4) и ограничивает развитие инфраструктуры CDN-сети, т.е. прототип зависим от наличия свободный ip адресов (которые ограничены) не замечает изменения структуры г „ Due to its architecture, each “edge” node - a server in the topology of the CDN network (caching server) needs to allocate "public" addresses for each published resource (in fact, each client (not the user). This is necessary for balancing and processing requests Today, version 4 IP addresses have come to an end and are issued by the RIPE Institute with restrictions, which leads to a shortage of IP addresses (ipv4) and limits the development of the CDN network infrastructure, ie the prototype is dependent on the availability of free IP addresses (which are about ourselves to) does not notice the change in the structure r „
к ши ую их серверов и работает с новой архитектурой оез изменении, что является недостатком данного прототипа. their servers and works with the new architecture to change, which is a disadvantage of this prototype.
Техническим результатом заявленного изобретения является агрегация пользовательских запросов на уровне дата центров и распределение их в кластере CDN посредством SDN-контроллера. То есть добавление каждого нового узла сети не ведет к необходимости выделения новых "публичных" адресов, таким образом, увеличивает масштабируемость производительность CDN-сети. Достигаемый технический результат заключается в том; что в способе распределения нагрузки между серверами сети доставки контента (cdn), при котором принимают запрос на услугу от, по меньшей мере, одного терминала пользователя на, по меньшей мере, одном сервере, определяют адрес пользователя, приводят в соответствие адресу пользователя адрес CDN- сервера, выбранный из множества адресов CDN-серверов. Далее выбирают маршрут для связи пользователя с соответствующим CDN-сервером. Приведение в соответствие осуществляют посредством, по меньшей мере, одной базы данных маршрутов-кандидатов, сформированной на, по меньшей мере, одном сервере. Выбор маршрута осуществляют на основании, по меньшей мере, одной метрики маршрута, выбранной из группы: задержки, вариации задержки, нагрузки, процента (или числа) потери пакетов, количества хопов, количества автономных систем, Q-критерия. При этом дополнительно предусматривают интервал допустимых значений для каждой метрики маршрута и, в случае, если метрика маршрута не входит в указанный интервал, исключают соответствующий маршрут из соответствующей базы данных маршрутов-кандидатов. Кроме того, производят мониторинг активности всех CDN-серверов в режиме реального времени при помощи средства обнаружения отказов, соединенного с, по меньшей мере, одним сервером. При этом в случае обнаружения условия отказа CDN-сервера, информацию о статусе и адресе такого CDN-сервера заносят в соответствующую базу данных, по меньшей мере, одного сервера и далее не учитывают при выборе маршрута. The technical result of the claimed invention is the aggregation of user queries at the level of data centers and their distribution in a CDN cluster via an SDN controller. That is, the addition of each new network node does not lead to the need to allocate new "public" addresses, thus increasing the scalability of CDN network performance. The technical result achieved is that; that in the method of load balancing between the servers of the content delivery network (cdn), in which a service request is received from at least one user terminal on at least one server, the user address is determined, the CDN address is mapped to the user address a server selected from a plurality of CDN server addresses. Next, a route is selected for user communication with the corresponding CDN server. The alignment is carried out by means of at least one database of candidate routes formed on at least one server. The route is selected based on at least one route metric selected from the group: delay, delay variation, load, percentage (or number) of packet loss, number of hopes, number of autonomous systems, Q-criterion. In addition, an interval of acceptable values is provided for each route metric, and if the route metric is not included in the specified interval, the corresponding route is excluded from the corresponding database of candidate routes. In addition, they monitor the activity of all CDN servers in real time using a fault detection tool connected to at least one server. In this case, if a condition is found failure of the CDN server, information about the status and address of such a CDN server is entered into the corresponding database of at least one server and is then not taken into account when choosing a route.
При этом узел сети (кеширующий сервер) перестает быть с одной стороны только кэширующим сервером, он становится структурной единицей со своим интеллектом на уровне узла, а с другой стороны для общей сети CDN никаких изменений не произошло. Отсутствие необходимости в выделении "публичных" IP-адресов под каждый публикуемый поток или данные, что позволяет не ограничивать развитие сети в условиях дефицита IP-адресов. In this case, the network node (caching server) ceases to be, on the one hand, only a caching server, it becomes a structural unit with its own intelligence at the node level, and on the other hand, no changes have occurred for the common CDN. No need to allocate "public" IP addresses for each published stream or data, which allows not to limit the development of the network in conditions of a shortage of IP addresses.
Сущность заявленного изобретения поясняется схемой 1, на котором изображено распределение нагрузки между серверами сети доставки контента. The essence of the claimed invention is illustrated by scheme 1, which shows the distribution of load between the servers of the content delivery network.
В способе распределения нагрузки между серверами сети доставки контента (cdn), при котором принимают запрос на услугу от, по меньшей мере, одного терминала пользователя на, по меньшей мере, одном сервере, определяют адрес пользователя, приводят в соответствие адресу пользователя адрес CDN-сервера, выбранный из множества адресов CDN- серверов. Далее выбирают маршрут для связи пользователя с соответствующим CDN-сервером. Приведение в соответствие осуществляют посредством, по меньшей мере, одной базы данных маршрутов-кандидатов, сформированной на, по меньшей мере, одном сервере. Выбор маршрута осуществляют на основании, по меньшей мере, одной метрики маршрута, выбранной из группы: задержки, вариации задержки, нагрузки, процента (или числа) потери пакетов, количества хопов, количества автономных систем, Q-критерия. При этом дополнительно предусматривают интервал допустимых значений для каждой метрики маршрута и, в случае, если метрика маршрута не входит в указанный интервал, исключают „ м - соответствующий маршрут из соответствующей базы данных маршрутов- кандидатов. Кроме того, производят мониторинг активности всех CDN- серверов в режиме реального времени при помощи средства обнаружения отказов, соединенного с, по меньшей мере, одним сервером. При этом в случае обнаружения условия отказа CDN-сервера, информацию о статусе и адресе такого CDN-сервера заносят в соответствующую базу данных, по меньшей мере, одного сервера и далее не учитывают при выборе маршрута. In the method of load balancing between servers of a content delivery network (cdn), in which a service request is received from at least one user terminal on at least one server, a user address is determined, a CDN server address is mapped to a user address selected from a plurality of CDN server addresses. Next, a route is selected for user communication with the corresponding CDN server. The alignment is carried out by means of at least one database of candidate routes formed on at least one server. The route is selected based on at least one route metric selected from the group: delay, delay variation, load, percentage (or number) of packet loss, number of hopes, number of autonomous systems, Q-criterion. Moreover, an interval of acceptable values is provided for each route metric, and if the route metric is not included in the specified interval, „ M is the corresponding route from the corresponding database of candidate routes. In addition, the activity of all CDN servers is monitored in real time using a failure detection tool connected to at least one server. Moreover, in case of detection of the failure condition of the CDN server, information about the status and address of such a CDN server is entered into the corresponding database of at least one server and is then not taken into account when choosing a route.
При этом узел сети (дотирующий сервер) перестает быть с одной стороны только кэширующим сервером, он становится структурной единицей со своим интеллектом на уровне узла, а с другой стороны для общей сети CDN никаких изменений не произошло. Отсутствие необходимости в выделении "публичных" IP-адресов под каждый публикуемый поток или данные, что позволяет не ограничивать развитие сети в условиях дефицита IP-адресов. В соответствии с предпочтительным вариантом осуществления изобретения в системе CDN предусматривают, по меньшей мере, один сервер, на котором при помощи средств сбора и хранения информации формируют базу данных маршрутов-кандидатов (таблицу маршрутизации) для каждого из CDN-серверов системы, состоящую из IP-префиксов. Таким сервером может быть, в частности, один или несколько CDN-серверов или один или несколько специализированных центральных серверов (резервирующих серверов). Далее в описании под понятием «сервер» понимается либо CDN, либо указанный центральный сервер. В случае применения нескольких таких серверов в системе их функционал дублируется на каждом их указанных серверов. At the same time, the network node (subsidizing server) ceases to be, on the one hand, only a caching server, it becomes a structural unit with its own intelligence at the node level, and on the other hand, no changes have occurred for the common CDN. No need to allocate "public" IP addresses for each published stream or data, which allows not to limit the development of the network in conditions of a shortage of IP addresses. According to a preferred embodiment of the invention, at least one server is provided in the CDN system, on which, using the means of collecting and storing information, a candidate route database (routing table) is formed for each of the system’s CDN servers, consisting of IP prefixes. Such a server may be, in particular, one or more CDN servers or one or more specialized central servers (backup servers). Further in the description, the term “server” means either a CDN or a specified central server. If several such servers are used in the system, their functionality is duplicated on each of these servers.
Указанная база данных формируется, в частности, на основании данных из открытых источников (база GeoIP, база RIPE, сайт robtex.com, списки региональных IP-серверов и пр.); информации о маршрутах, __ The specified database is formed, in particular, on the basis of data from open sources (GeoIP database, RIPE database, robtex.com website, lists of regional IP servers, etc.); route information __
получаемых от операторов, где установлены сервера CDN (как в статическом виде, так и в режиме онлайн по протоколу BGP). received from the operators where the CDN server is installed (both in static form and online using the BGP protocol).
Кроме того, каждый из CDN-серверов может регулярно, через заданный промежуток времени (например, 1 раз в сутки), производить трассировку маршрута до случайно выбранного IP-адреса внутри своего IP- префикса. При этом производят сбор, по меньшей мере, одного из: задержки, вариации задержки, нагрузки, процента (или числа) потери пакетов, количества хопов, количества автономных систем, Q-критерия (суммы числа хопов и числа автономных систем). Эти данные (метрики) заносятся в таблицу маршрутов-кандидатов данного сервера для дальнейшей обработки с записью этой информации в базу данных. Метрики также могут быть переданы на один или несколько CDN-серверов для обработки и записи в соответствующие базы данных. In addition, each of the CDN servers can regularly, after a specified period of time (for example, 1 time per day), trace the route to a randomly selected IP address inside its IP prefix. At the same time, at least one of the following is collected: delay, variation of delay, load, percentage (or number) of packet loss, number of hopes, number of autonomous systems, Q-criterion (sum of the number of hopes and the number of autonomous systems). These data (metrics) are entered in the table of candidate routes of this server for further processing with the recording of this information in the database. Metrics can also be transferred to one or more CDN servers for processing and writing to the appropriate database.
Кроме того, для всех CDN-серверов и для каждого из маршрутов- кандидатов может производиться проверка соответствия собранных параметров заранее определенным интервалам значений (порогам). Если тот или иной маршрут признается несоответствующим по указанным параметрам, он исключается из базы (баз) данных. In addition, for all CDN servers and for each of the candidate routes, the collected parameters can be checked for compliance with predetermined value ranges (thresholds). If this or that route is recognized as inappropriate according to the specified parameters, it is excluded from the database (s).
Кроме того, для каждого из CDN-серверов может формироваться "черный список" префиксов, на который сервер не имеет права направлять трафик. Список формируется на основании, по меньшей мере, одного из: анализа лог-файлов (большой процент ошибок при передаче файлов, частые случаи буферизации видео), на основании поступающей от пользователей информации или в результате анализа, проводимого системными администраторами системы CDN. Кроме того, для всех CDN-серверов производится проверка, не попадают ли префиксы маршрутов-кандидатов в "черный список", если попадают - такие маршруты отсеиваются. т In addition, a blacklist of prefixes can be generated for each of the CDN servers, to which the server does not have the right to direct traffic. The list is formed on the basis of at least one of: analysis of log files (a large percentage of errors during file transfer, frequent cases of video buffering), based on information received from users or as a result of analysis carried out by system administrators of the CDN system. In addition, for all CDN servers, a check is made to see if the prefixes of candidate routes are blacklisted; if they do, such routes are eliminated. t
оме того, для всех CDN-серверов и для каждого из маршрутов- кандидатов может производиться проверка наличия в лог-файлах CDN- сервера информации о средней скорости подключения на тот или иной IP- префикс. В случае, если такая информация является статистически достоверной, она заносится в базу данных маршрутов-кандидатов.  In addition, for all CDN servers and for each of the candidate routes, the presence of information on the average connection speed for one or another IP prefix can be checked in the log files of the CDN server. If such information is statistically reliable, it is entered into the database of candidate routes.
Кроме того, в системе может производиться постоянный мониторинг всех серверов системы CDN для определения их активности посредством средства обнаружения отказов. CDN-сервер лишается статуса активного, если этот CDN-сервер удовлетворяет условию отказа: недоступен, или же перегружен, или же слишком большой процент пользователей получает отказы в показе контента, или же слишком часто видео буферизируется. Указанная информация поступает на сервер в виде информации о статусе CDN-сервера и его адресе, вносится в базу данных и далее учитывается при выборе маршрутов из списка маршрутов-кандидатов. Кроме того, мониторинг состояния CDN-серверов в режиме реального времени позволяет производить построение маршрута с учетом характеристик контента услуги, что не предусмотрено текущим уровнем техники. В частности, настоящее изобретение предусматривает учет качества показа видео (в том числе частоты буферизации) при определении оптимального маршрута. Также такой мониторинг позволяет повысить отказоустойчивость системы CDN (указание статуса CDN-сервера), и повысить ее гибкость в целом. In addition, all CDN system servers can be continuously monitored in the system to determine their activity through the fault detection tool. A CDN server is deprived of active status if this CDN server satisfies the failure condition: it is unavailable, or is overloaded, or too many percent of users receive refusals to display content, or too often the video is buffered. The specified information is sent to the server in the form of information about the status of the CDN server and its address, is entered into the database and then taken into account when choosing routes from the list of candidate routes. In addition, real-time monitoring of the status of CDN servers allows you to build a route taking into account the characteristics of the content of the service, which is not provided by the current level of technology. In particular, the present invention provides for taking into account the quality of video display (including the buffering frequency) when determining the optimal route. Also, such monitoring allows to increase the fault tolerance of the CDN system (indicating the status of the CDN server), and increase its flexibility in general.
Кроме того, настоящее изобретение предусматривает учет границ сетей Интернет-провайдеров при определении оптимального маршрута посредством Q-критерия, представляющего собой сумму числа маршрутизаторов и автономных систем, находящихся на маршруте. In addition, the present invention provides for taking into account the boundaries of the networks of Internet providers when determining the optimal route using the Q-criterion, which is the sum of the number of routers and autonomous systems on the route.
Использование Q-критерия отражает тот факт, что ухудшение качества связи на внутрисетевых маршрутизаторах интернет-провайдеров происходит , еств т евых маршрутизаторах, установленных на границах сетях интернет-провайдеров, из-за большей загрузки последних. The use of the Q-criterion reflects the fact that a deterioration in the quality of communication on the intranet routers of Internet providers occurs There are tv routers installed on the borders of the networks of Internet providers, due to the greater load of the latter.
Специалисту будет понятно, что указанные в настоящей заявке линии связи могут представлять собой проводные либо беспроводные линии связи, такие как WiFi, CDMA, LTE и т.п. One skilled in the art will understand that the communication lines indicated in this application can be either wired or wireless communication lines, such as WiFi, CDMA, LTE, and the like.
В соответствии с предпочтительным вариантом осуществления предусмотрен способ распределения нагрузки между серверами сети доставки контента (CDN), при котором принимают запрос на услугу от, по меньшей мере, одного терминала пользователя на, по меньшей мере, одном сервере, определяют адрес пользователя, приводят в соответствие адресу пользователя адрес CDN-сервера, выбранный из множества адресов CDN- серверов, и выбирают маршрут для связи пользователя с соответствующим CDN-сервером, приведение в соответствие осуществляют посредством, по меньшей мере, одной базы данных маршрутов-кандидатов, сформированной на, по меньшей мере, одном сервере, при этом выбор маршрута осуществляют на основании, по меньшей мере, одной метрики маршрута, выбранной из группы: задержки, вариации задержки, нагрузки, процента (или числа) потери пакетов, количества хопов, количества автономных систем, Q-критерия, при этом дополнительно предусматривают интервал допустимых значений для каждой метрики маршрута и, в случае, если метрика маршрута не входит в указанный интервал, исключают соответствующий маршрут из соответствующей базы данных маршрутов- кандидатов и, кроме того, производят мониторинг активности всех CDN- серверов в режиме реального времени при помощи средства обнаружения отказов, соединенного с, по меньшей мере, одним сервером, при этом в случае обнаружения условия отказа CDN-сервера, информацию о статусе и адресе такого CDN-сервера заносят в соответствующую базу данных, по меньшей мере, одного сервера и далее не учитывают при выборе маршрута. τ r ~ In accordance with a preferred embodiment, a method is provided for load balancing between servers of a content delivery network (CDN), in which a service request is received from at least one user terminal on at least one server, a user address is determined, brought into correspondence the user address is the address of the CDN server selected from the plurality of addresses of the CDN servers, and a route is selected for the user to communicate with the corresponding CDN server, matching is carried out by at least at least one database of candidate routes formed on at least one server, and the route is selected based on at least one route metric selected from the group: delay, delay variation, load, percentage (or numbers) packet loss, the number of hopes, the number of autonomous systems, the Q-criterion, while additionally providing an interval of acceptable values for each route metric and, if the route metric is not included in the specified interval, exclude the corresponding route from the corresponding database of candidate routes and, in addition, they monitor the activity of all CDN servers in real time using a failure detection tool connected to at least one server, in case of detection of a failure condition of the CDN server, information about the status and address of such a CDN server is entered into the corresponding database of at least one server and is then not taken into account when choosing a route. τ r ~
При awM соответствующая, по меньшей мере, одна база данных размещена на соответствующем ей, по меньшей мере, одном сервере. При этом очевидно, что базы данных могут дублировать друг друга, а каждый из упомянутых CDN-сервером и/или серверов могут быть выполнены с возможностью обмена данными друг с другом по соответствующим линиям связи.  With awM, the corresponding at least one database is hosted on the corresponding at least one server. It is obvious that the databases can duplicate each other, and each of the aforementioned CDN server and / or servers can be configured to exchange data with each other via respective communication lines.
При этом узел сети (кеширующий сервер) перестает быть с одной стороны только кэширующим сервером, он становится структурной единицей со своим интеллектом на уровне узла, а с другой стороны для общей сети CDN никаких изменений не произошло. Отсутствие необходимости в выделении "публичных" IP-адресов под каждый публикуемый поток или данные, что позволяет не ограничивать развитие сети в условиях дефицита IP-адресов. In this case, the network node (caching server) ceases to be, on the one hand, only a caching server, it becomes a structural unit with its own intelligence at the node level, and on the other hand, no changes have occurred for the common CDN. No need to allocate "public" IP addresses for each published stream or data, which allows not to limit the development of the network in conditions of a shortage of IP addresses.
Агрегация пользовательских запросов на уровне дата центров и распределение их в кластере CDN посредством SDN-контроллера. То есть добавление каждого нового узла сети не ведет к необходимости выделения новых "публичных" адресов, но решает главную задачу, увеличивает производительность CDN-сети.  Aggregation of user queries at the data center level and their distribution in a CDN cluster by means of an SDN controller. That is, the addition of each new network node does not lead to the need to allocate new "public" addresses, but it solves the main problem and increases the performance of the CDN network.
"Ес1 е"(кэширующие) сервера объединяются в узлы или кластеры представляющие собой один высокопроизводительный узел, которому требуется всего один "публичный" IP адрес. Основная или верхнеуровневая балансировка осуществляется между агригированными узлами, в состав которых входит несколько "edge" серверов. Это группа начинает обладать едиными метриками балансировки и в представлении алгоритма балансировки является одним узлом. На уровне узла балансировкой занимается SDN-контроллер, который выполняет две функции. Первая, осуществляет внутреннюю балансировку нагрузки согласно встроенным алгоритмам и второе, аккумулирует параметры системы для представления совокупных метрик системы для работы с балансировщиком CDN. „ "Ec1 e" (caching) servers are combined into nodes or clusters representing one high-performance node that requires only one "public" IP address. The main or upper-level balancing is carried out between aggregated nodes, which include several "edge" servers. This group begins to possess uniform balancing metrics and in the presentation of the balancing algorithm is one node. At the node level, balancing is done by the SDN controller, which performs two functions. The first, carries out internal load balancing according to the built-in algorithms, and the second, accumulates system parameters to represent aggregate system metrics for working with the CDN balancer. „
l аким образом, достигается поставленный технический результат: агрегация пользовательских запросов на уровне дата центров и распределение их в кластере CDN посредством SDN-контроллера. То есть добавление каждого нового узла сети не ведет к необходимости выделения новых "публичных" адресов, таким образом, увеличивает производительность CDN-сети.  l Thus, the delivered technical result is achieved: aggregation of user queries at the data center level and their distribution in the CDN cluster by means of the SDN controller. That is, the addition of each new network node does not lead to the need to allocate new "public" addresses, thus increasing the performance of the CDN network.
Анализ совокупности всех существенных признаков предложенного изобретения доказывает, что исключение хотя бы одного из них приводит к невозможности полного обеспечения достигаемого технического результата.  Analysis of the totality of all the essential features of the proposed invention proves that the exclusion of at least one of them leads to the inability to fully ensure the achieved technical result.
Анализ уровня техники показывает, что неизвестен способ распределения нагрузки между серверами сети доставки контента (cdn), которому присущи признаки, идентичные всем существенным признакам данного технического решения, что свидетельствует о его неизвестности и, следовательно, новизне.  The analysis of the prior art shows that there is no known method of load distribution between the servers of the content delivery network (cdn), which has features identical to all the essential features of this technical solution, which indicates its unknownness and, therefore, novelty.
Вышеперечисленное доказывает соответствие заявленного способа критериям изобретательского уровня.  The above proves the conformity of the claimed method to the criteria of an inventive step.
При осуществлении изобретения действительно реализуется наличие предложенного объекта, что свидетельствует о промышленной применимости.  When implementing the invention, the presence of the proposed object is really realized, which indicates industrial applicability.

Claims

Формула изобретения Claim
Способ распределения нагрузки между серверами сети доставки контента (CDN), при котором принимают запрос на услугу от, по меньшей мере, одного терминала пользователя на, по меньшей мере, одном сервере, определяют адрес пользователя, приводят в соответствие адресу пользователя адрес CDN-сервера, выбранный из множества адресов CDN-серверов и выбирают маршрут для связи пользователя с соответствующим CDN- сервером, приведение в соответствие осуществляют посредством, по меньшей мере, одной базы данных маршрутов-кандидатов, сформированной на, по меньшей мере, одном сервере, при этом выбор маршрута осуществляют на основании, по меньшей мере, одной метрики маршрута, выбранной из группы: задержки, вариации задержки, нагрузки, процента (или числа) потери пакетов, количества хопов, количества автономных систем, Q-критерия, при этом дополнительно предусматривают интервал допустимых значений для каждой метрики маршрута и, в случае, если метрика маршрута не входит в указанный интервал, исключают соответствующий маршрут из соответствующей базы данных маршрутов- кандидатов и, кроме того, производят мониторинг активности всех CDN- серверов в режиме реального времени при помощи средства обнаружения отказов, соединенного с, по меньшей мере, одним сервером, при этом в случае обнаружения условия отказа CDN-сервера, информацию о статусе и адресе такого CDN-сервера заносят в соответствующую базу данных, по меньшей мере, одного сервера и далее не учитывают при выборе маршрута, отличающийся тем, что узел сети (кеширующий сервер) перестает быть с одной стороны только кэширующим сервером, он становится структурной единицей со своим интеллектом на уровне узла, а с другой стороны для общей сети CDN никаких изменений не произошло, отсутствие необходимости в выделении "публичных" IP-адресов под каждый публикуемый поток или данные позволяет не ограничивать развитие сети в условиях дефицита IP-адресов.  A method of load balancing between servers of a content delivery network (CDN), in which a service request is received from at least one user terminal on at least one server, a user address is determined, a CDN server address is brought into correspondence with the user address, selected from a plurality of CDN server addresses and a route is selected for user communication with the corresponding CDN server, matching is carried out by means of at least one database of candidate routes generated by at least one server, and the route is selected based on at least one route metric selected from the group: delay, delay variation, load, percentage (or number) of packet loss, number of hopes, number of autonomous systems, Q- criteria, in addition, provide an interval of acceptable values for each route metric and, if the route metric is not included in the specified interval, exclude the corresponding route from the corresponding database of candidate routes and, in addition, monitoring the activity of all CDN servers in real time using a failure detection tool connected to at least one server, and in case of detection of a failure condition of the CDN server, information about the status and address of such a CDN server is entered into the corresponding the database of at least one server is not taken into account further when choosing a route, characterized in that the network node (caching server) ceases to be only a caching server on one side, it becomes a structural unit with its own intelligence a site level, and on the other hand to the overall CDN network no change, no need to allocate a "public" IP-addresses for each stream or published data allows you to not restrict the development of the network under the IP-address the deficit.
PCT/RU2015/000693 2014-10-21 2015-10-20 Method for distributing load among servers of a content delivery network (cdn) WO2016064303A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
RU2014142341 2014-10-21
RU2014142341A RU2014142341A (en) 2014-10-21 2014-10-21 METHOD FOR LOAD DISTRIBUTION BETWEEN CONTENT DELIVERY NETWORK SERVERS (CDN)

Publications (1)

Publication Number Publication Date
WO2016064303A1 true WO2016064303A1 (en) 2016-04-28

Family

ID=55761218

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/RU2015/000693 WO2016064303A1 (en) 2014-10-21 2015-10-20 Method for distributing load among servers of a content delivery network (cdn)

Country Status (2)

Country Link
RU (1) RU2014142341A (en)
WO (1) WO2016064303A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108696444A (en) * 2018-05-07 2018-10-23 广州大学华软软件学院 One-to-many stream compression forwarding method based on SDN network
CN109586969A (en) * 2018-12-13 2019-04-05 平安科技（深圳）有限公司 Content distributing network disaster recovery method, device, computer equipment and storage medium

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030101253A1 (en) * 2001-11-29 2003-05-29 Takayuki Saito Method and system for distributing data in a network
EP2434758A1 (en) * 2009-06-19 2012-03-28 ZTE Corporation Distributed node video monitoring system and management method thereof
RU2454711C1 (en) * 2011-04-04 2012-06-27 Общество с ограниченной ответственностью "СДН-видео" Method of distributing load between content delivery network (cdn) servers

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030101253A1 (en) * 2001-11-29 2003-05-29 Takayuki Saito Method and system for distributing data in a network
EP2434758A1 (en) * 2009-06-19 2012-03-28 ZTE Corporation Distributed node video monitoring system and management method thereof
RU2454711C1 (en) * 2011-04-04 2012-06-27 Общество с ограниченной ответственностью "СДН-видео" Method of distributing load between content delivery network (cdn) servers

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108696444A (en) * 2018-05-07 2018-10-23 广州大学华软软件学院 One-to-many stream compression forwarding method based on SDN network
CN109586969A (en) * 2018-12-13 2019-04-05 平安科技（深圳）有限公司 Content distributing network disaster recovery method, device, computer equipment and storage medium
CN109586969B (en) * 2018-12-13 2022-02-11 平安科技（深圳）有限公司 Content distribution network disaster tolerance method and device, computer equipment and storage medium

Also Published As

Publication number Publication date
RU2014142341A (en) 2016-05-20

Similar Documents

Publication Publication Date Title
US10200402B2 (en) Mitigating network attacks
US9794281B1 (en) Identifying sources of network attacks
US9742795B1 (en) Mitigating network attacks
US10447648B2 (en) Assignment of a POP to a DNS resolver based on volume of communications over a link between client devices and the POP
US9929961B2 (en) Flow-based load balancing
CN106998263B (en) System and method for maintaining network service level
JP6059336B2 (en) Method, system and computer readable medium for performing Diameter overload control
US9240949B2 (en) Methods, systems and computer readable media for predicting overload conditions using load information
US10979387B2 (en) Systems and methods for utilization of anycast techniques in a DNS architecture
US20060203739A1 (en) Profiling wide-area networks using peer cooperation
JP7313480B2 (en) Congestion Avoidance in Slice-Based Networks
Alzoubi et al. A practical architecture for an anycast CDN
JP2013168139A (en) Load balancing device, load balancing method and hierarchized data center system
Alzoubi et al. Anycast cdns revisited
US20150288597A1 (en) Traffic distribution for an edge device
JP2015535669A (en) Monitoring encrypted sessions
WO2016077801A4 (en) Circuit-aware load balancing with dynamic quality of service
CN110771122A (en) Method and network node for enabling a content delivery network to handle unexpected traffic surges
CN103401799A (en) Method and device for realizing load balance
RU2454711C1 (en) Method of distributing load between content delivery network (cdn) servers
JP5871908B2 (en) Method and system for controlling data communication within a network
JP5154313B2 (en) SIP message distribution method and SIP message distribution apparatus
Bhattacharyya et al. Geographical and temporal characteristics of inter‐POP flows: View from a single pop
WO2016064303A1 (en) Method for distributing load among servers of a content delivery network (cdn)
Saifullah et al. Open flow-based server load balancing using improved server health reports

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15851747

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15851747

Country of ref document: EP

Kind code of ref document: A1