WO2015025066A1 - Method and system for balancing content requests in a server provider network - Google Patents

Method and system for balancing content requests in a server provider network Download PDF

Info

Publication number
WO2015025066A1
WO2015025066A1 PCT/ES2013/070605 ES2013070605W WO2015025066A1 WO 2015025066 A1 WO2015025066 A1 WO 2015025066A1 ES 2013070605 W ES2013070605 W ES 2013070605W WO 2015025066 A1 WO2015025066 A1 WO 2015025066A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
entity
information
load balancer
request
Prior art date
Application number
PCT/ES2013/070605
Other languages
Spanish (es)
French (fr)
Inventor
Manuel NÚÑEZ SANZ
Ignacio CONDE SÁNCHEZ
Original Assignee
Telefonica, S.A.
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 Telefonica, S.A. filed Critical Telefonica, S.A.
Priority to PCT/ES2013/070605 priority Critical patent/WO2015025066A1/en
Publication of WO2015025066A1 publication Critical patent/WO2015025066A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload

Definitions

  • the present invention has its application within the telecommunication sector and, especially, refers to a system and method for providing balance (or balance) of loads in a communication network with multiple content servers.
  • a server farm -server farm, in English-, or a cluster of servers -server cluster, in English-, is a collection of computer servers, usually maintained by a Service Network Provider, to meet server needs far beyond of the capacity of a machine.
  • Server campuses often consist of thousands of computers that require a lot of power to operate.
  • Server campuses are usually coded with network switches and / or routers, which allow communication between the different parts of the cluster and the users of the cluster.
  • Server sites achieve high scalability and high availability through server load balancing.
  • Load balancers load balancers, in English) are responsible for ensuring that the workload on each server is within a small environment (or balance criteria) of the workload present on each of the other servers in the system.
  • Figure 1 shows a typical server campus system comprising multiple servers (5, 6, 7, 8, 9, 10) in a network (100) server provider.
  • the balance or load balance hides the server pool (5, 6, 7, 8, 9, 10) to the clients (1), which seem to connect to a single server.
  • the Load Balancers (2, 3, 4) distribute the workload among multiple servers (5, 6, 7, 8, 9, 10).
  • the load balancer (2, 3, 4) connected to the customer (1) through a transport network (101), and to which a content request is dispatched by the customer (1), select one of the servers (5, 6, 7, 8, 9, 10) Final or Back-end server, in English, between the network server servers (100) providing servers, to process the content request.
  • a server - from Trastienda - is the entity where the contents (e.g., files, streams, ...) distributed to end users and the software that distributes them are hosted.
  • Centralized algorithms In this class of algorithms, there is a central element that collects information from the servers and makes the appropriate decision.
  • each load balancer has information about all servers.
  • Level 4 load balancers this class of load balancers does not take into account the content or application that the user is requesting. These load balancers work in Layer 4 in the OSI (IP-based) model.
  • Level 7 load balancers These load balancers are called content-sensitive load balancers, and are capable of performing a complete inspection of layer 7.
  • the layer 7 load balancing works using three main techniques: Syntactic analysis of the URLs, HTTP Header Interception and Decoy Interception. - Dynamic / static
  • Static algorithms Their behavior is predetermined. They assign the tasks of a program parallel to a Backroom Server, based on the load at the time when tasks are assigned to the nodes, or based on an average load of the Backroom Server.
  • Dynamic algorithms This class of algorithms makes decisions according to the state of the systems, makes changes in the distribution of work among the Disorder Servers at runtime; use current or recent load information when making distribution decisions.
  • Liabilities analyze flows between clients and servers passively, using a router or other network element.
  • An example of passive measurement could be the Round Trip Time (RTT), calculated with the network delay and the server processing delay of each SOIDIDITY! The origin of the reference is not found.
  • RTT Round Trip Time
  • the most advanced load balancers use "dynamic + passive + active" algorithms / procedures and use level 7 inspection techniques. Thus, they take the new request to the idle server at all times.
  • the idle server is usually determined or estimated using only the network response time of a server.
  • EP1 1 16082 An example of a dynamic load balancer for multiple network servers is disclosed in EP1 1 16082.
  • This load balancer examines the loads on the servers and adjusts their queues using an algorithm decentralized, but the load balancing algorithm only takes into account the CPU value to update the information for each load balancer, in order to obtain the CPU balance between all servers.
  • Another example of a load balancing algorithm is described in WO 2009/004734, in which a plurality of real servers, which form a virtual server system, transmit their respective states to a single Server Load Balancer (SLB) loading, along with communication information used for the distribution of requests.
  • SLB stores the communication information received as new information about distribution destinations if this new communication information is not stored in a service management database (DB).
  • DB service management database
  • the SLB balances the loads of the various requests to the plurality of real servers.
  • This architecture is aimed at facilitating management, allowing changes in real servers, but does not take into account the characterization of the request from the client.
  • the addition of new servers to the system topology, or a change by one of the servers in your service offering also requires a change, manually by the service provider, in Load balancer configuration policy.
  • the existing Load Balancing does not take into account the characterization of the request from the client, for example, the case in which a request needs more CPU than Memory resources to be executed optimally.
  • V2, V3, D2, D3, M2, M3 are grouped by the type of services they provide, e.g. eg, video, database, mathematical calculations, etc., which respectively form a campus (100 v ) of video servers, a campus (100 D ) of database servers and a campus (100 M ) of mathematical servers
  • the architecture of the load balancing system is very rigid.
  • Customer requests (1) are always balanced for an idle server by the corresponding Load Balancer (V1, D1, M1), which manages the traffic of the specific service: flow of video (f1), data flow (f2) or mathematical flow (f3).
  • Each Load Balancer (V1, D1, M1) is connected to a grouped logical server, that is, with each campus (100 v , 100 D , 100 M ) of thematic servers, such as a dedicated balancer. Therefore, this conventional architecture does not allow load balancing in real time, since it is not possible to change services without changing the configuration policy in load balancers.
  • the present invention solves the aforementioned problems by revealing a procedure and a system that is constantly learning from the information about servers in a cluster (server staff), its services and requests from customers, in order to adjust in time Real decision on the balance of requests for servers, based on the following parameters:
  • each resource can be dynamically weighted (and individually, instead of weighing the total energy resource of the serving machine, as in the prior art ) for its importance for each type of client request.
  • the status of the server is in standardized form and, in a preferred embodiment of the invention, the status of each server resource can be referred to: delay, current CPU, RAM ...
  • Client calculation or program that requests data or information from a Server.
  • Server Machine where one or more Services are running.
  • Service Software program that provides information, content or Customer assistance in a computer network.
  • Service Request request issued by Customers to try to access certain content (application / service) (e.g., segments in IPTV systems or file blocks in file download systems) that can be supplied by one or more Servers associated with A kind of service.
  • content application / service
  • servers associated with A kind of service.
  • Load Balancing central network entity responsible for distributing incoming traffic among Servers that host the same application content, balancing content requests between multiple servers to improve server utilization and maximize availability.
  • a load balancer is capable of making traffic decisions based on traditional information from layers 2 and 3 of the OSI model, and more advanced load balancers can make intelligent traffic management decisions based also on specific information from layers 4 to 7, contained within the request issued by the client.
  • Load balancers also routinely incorporate network address translation (NAT) to blind the IP address of the backroom application server, and are able to determine the physical or virtual server to send the client's request.
  • the load balancer manages all bidirectional traffic between the client and the server.
  • the server sends its response to the client through the load balancer, which correlates each response of the application with the correct connection of the client, ensuring that each user receives the appropriate response.
  • the present invention is based on a single simple load balancing system architecture, comprising the following three network entities of a server provider network: the Load Balancing Server (LBSEF) Reinforcement Function assigned to a Server the server provider network, the Load Balancer Policy Reinforcement Function (LBPEF) assigned to a Load Balancer of the server provider network, and the Load Balancer Policy Rule Function (LBPRF), in communication with each LBSEF and LBPEF of the server provider network.
  • LBSEF Load Balancing Server
  • LBSEF Load Balancer Policy Reinforcement Function
  • LBPEF Load Balancer Policy Rule Function
  • Load Balancer Server Booster Function This entity collects information about the server to which it is assigned and sends the collected information to the LBPRF. In addition, it executes some basic instructions ordered by the LBPRF (stop / start services, server status monitoring / checking ).
  • the LBSEF can be defined as an element of the Data Plane.
  • the Load Balancing Policy Rules Function An entity without dependency that decides in real time which is the optimal server for each request. In a possible embodiment of the invention, only one instance of this element is required, but several are recommended for reasons of redundancy and scalability.
  • the LBPRF can be defined as an element of the Control Plane.
  • LBPEF Load Balancer Policy Reinforcement Function
  • This entity analyzes each incoming request from the client, to extract information regarding the request, sends this summary information and asks the LBPRF for instructions on the optimal server where to resolve it. broadcast it.
  • the LBPEF can be an integrated part of a load-balancing node.
  • the LBPEF can also be defined as an element of the Data Plane.
  • a method for balancing content requests in a server provider network comprising the following steps:
  • a server that is optimal for the content request among the network servers server provider, based on a load balancing algorithm that takes into account all the information received in the previous two stages.
  • all the information is received in an entity of the Load Balancing Policy Rules Function, which chooses the optimal server for the content request received, based on the load balancing algorithm, and where:
  • the summary of information contained in the content request is received from an entity of the Load Balancer Policy Reinforcement Function, associated with the load balancer that receives the content request from the client;
  • each server is received from an entity of the Load Balancing Server Reinforcement Function, associated respectively with each server in the server provider network.
  • the procedure for balancing content requests which can be implemented in an entity of the Load Balancer Policy Rules Function, chooses the optimal server for each request, taking into account the resources that the request needs and using, in a possible embodiment of the invention, a weighted algorithm.
  • the weighted algorithm manages and processes information about the kind of service the group is hosting, and about what are the main features that the service needs.
  • this procedure learns in real time about changes in the topology of the campus / server pool, learns in real time about the "ready and in action" services on each server, and can learn about aggregates, modifications or deletions for the services offered by the server pool.
  • a historical database, integrated into the LBPRF, or accessible by the Load Balancer Policy Rules Function entity can be used to store the teachings, or information, so that heuristic algorithms can be introduced to in order to further improve the optimal server allocation at all times.
  • a second aspect of the present invention relates to a system that is integrated into a server provider network comprising a plurality of Content servers, to balance content requests from users of the server provider network.
  • the system comprises one or more entities of the Load Balancing Policy Rules Function, to balance content requests in a server provider network, which provides multiple content servers associated with at least one
  • the Load Balancer Policy Rules Function implements the procedure described above.
  • the system additionally comprises one or more entities of the Load Balancer Policy Reinforcement Function (LBPEF), associated with at least one Load Balancer, in charge of sending to the LBPRF a summary of the information contained in a request for content from the client of the server provider network.
  • LBPEF analyzes each new customer request, sends this summary information and asks the LBPRF for instructions.
  • the system comprises one or more entities of the Load Balancer Server Reinforcement Function, each entity collecting the Load Balancer Server Reinforcement Function (LBSEF) associated with one of the servers, information referred to the associated server , and sending real-time information about the server to the LBPRF.
  • LBSEF Load Balancer Server Reinforcement Function
  • the LBPRF is an independent entity that provides means to decide in real time which is the optimal server for each client request, based on the information received about services, servers and client requests.
  • the present invention takes into account the characteristics of the request issued by the client, the characteristics of the server, including its status information (which allows server administrators to determine how well their server is currently performing) and characteristics of the service, for each class of service, unlike the approach revealed in EP1 1 16082, which considers only the CPU resource of the servers. In this way, the present invention assigns, in real time, the client request for a server or service to the optimal server, making better use of the total resources. Also patent WO 2009/004734 is based on servers that execute various processes in a similar manner and that do not take into account the characteristics of the request
  • the present invention allows the use of a mixture of machines with different hardware characteristics in a data center, and without any configuration in each load balancer, since a new machine is simply added as an element to "connect and use” and only one point (its associated LBSEF) needs to be configured.
  • the present invention uses a single architecture to serve everyone, with the corresponding hardware savings.
  • Figure 1 shows a block diagram of the conventional architecture of a system for balancing content requests, as known in the prior art.
  • Figure 2 shows a network scenario of a system for balancing content requests, as known in the prior art, comprising different server groupings distinguished by the content class.
  • Figure 3 shows a block diagram of the system architecture, for balancing content requests in a server provider network, according to a preferred embodiment of the invention.
  • Figure 4 shows a message flow diagram in the system of Figure 3 for balancing content requests, according to a possible embodiment of the invention.
  • Figure 5 shows a message flow diagram in the system of Figure 3 to collect the status of the servers, according to a possible application of the invention.
  • Figure 3 presents a system for balancing content requests on a server provider network (100) comprising the following network entities:
  • LBSEF Load Balancer Server Reinforcement Function
  • Figure 4 shows a flow chart of the communication messages exchanged in the system described above, illustrating the flow of information between the entity (2 ', 3', 4 ') of the Booster Function of the Balancer Policy of Loads and the entity (1 1) of the Load Balancing Policy Rules Function, when a client (1) extracts a Service from one of the servers (5, 6, 7, 8, 9, 10) of the campus Dynamic server, for example, the server (5) in Figure 3, and all the network entities involved in this process, comprising the following stages:
  • the client (1) sends a Service Request (401) to request service content from a network (100) server provider.
  • a Load Balancer (2) receives this request and forwards it (402) to its linked LBPEF (2 ').
  • the LBPEF (2 ') can be implemented in a node connected to the Load Balancer (2), or integrated into the same Load Balancer node (2).
  • the LBPEF (2 ') summarizes the request to obtain the main data, usually the header data with the name of the service, the ports involved, etc., and, in general, any data that is useful to identify the service, and send this information that identifies the service and the request (403) to the LBPRF (1 1).
  • the LBPRF (1 1) makes a decision, based on the information received from the LBPEF (2 '), and applying a load balancing algorithm described below, also based on the information from the available servers (5, 6, 7, 8, 9, 10) of dynamic campus of servers, in order to select an optimal server, which is notified (404) to the LBPEF (2 ') in response to the information sent before.
  • the LBPEF (1 1) sends (405) the notification of the optimal server to the linked load balancer (2).
  • Load Balancer (2) requests the service (406) from the server selected by the LBPRF (1 1), p. eg, the server (5).
  • Figure 5 shows a flow chart of the protocol between the LBPRF (1 1) and any of the entities (5 ', 6', 7 ', 8', 9 ', 10') of the Balancer Server Booster Function Loads, only as an exemplary LBSEF (5 '), to obtain the status details of each associated server (5, 6, 7, 8, 9, 10), prior to notification (404) of the optimal server to the LBPEF (2').
  • the state provides the LBPRF (1 1) with real-time information about the operability of a server, to decide if this server could be a candidate for the optimal selection.
  • the status of a server at a Network headquarters can indicate whether it is online or offline
  • the maintenance status means that a server is undergoing maintenance
  • the alert status means a notification of a service outage ...
  • FIG. 5 shows three different main implementation options for the LBPRF (1 1) to obtain information about the status of a server (5) through its assigned LBSEF (5 '):
  • the LBPRF (1 1) requests status information (a1) from the server (5) to the LBSEF (5 ') assigned to said server (5) and defines a periodicity of sending updated status information by said LBSEF (5) '). 2.
  • the LBSEF (5 ') replies with the information response (a2) comprising at least one indication of the status of the server (5); additionally, other available parameters about server resources (5) and their service can be included in the response, e.g. eg, the characteristics of the CPU, the amount of memory, the weight of each CPU or memory resource for the service running on the server (5), etc.
  • the LBPRF (1 1) stores (50) this information in its own database for future use.
  • LBSEF starts the periodic sending of server status information
  • the LBSEF (5 ') initiates (b1) the sending of status information, and additional server parameters, as described above, to the LBPRF (1 1), when there are significant changes in the server parameters, or periodically , using a period of time predefined by the server provider.
  • the LBPRF (1 1) stores (50) this information in its own database, for future use.
  • the LBPRF determines whether the status of a server is "down" or not
  • the LBPRF (1 1) may decide that a server (5) is down, if after several attempts (c1, c2, c3) it does not obtain a response from the LBSEF (5 ') assigned to the server (5), that is, a Failure to request status information is detected by the LBPRF (1 1) upon discovering that the LBSEF (5 ') is unable to respond properly.
  • the LBPRF (1 1) stores (50) this information in its own database for future use. Usually, the LBPRF (1 1) marks the server (5) assigned as "dropped” in its database and no longer sends requests to that server (5). Optionally, additional attempts may be included within an interval with more time, to send again 'ping' messages to the LBSEF (5 ') of the server (5) marked, in order to detect if the server (5) is "active".
  • the LBSEF (5 ') can obtain the status information of the server through multiple active or passive procedures (execute the Operating System APIs to obtain the hardware status, monitor the network interface, run low intrusion pilot test programs, etc. .). This main information is shown below, but any other relevant information can be added.
  • Calculation Power CPU: total number of cores, power of each (operations per second), percentage of idleness (average since the last state).
  • MEM Total amount of memory and amount of free memory.
  • BW Total Bandwidth and Free Bandwidth (average since the last state).
  • Identification parameters in a request to assign that "request” to that "service”. For example, the service URL, the port where the service is listening, the protocol that is accepting the service, etc.
  • the objective of the LBPRF (1 1) is to assign the optimal server to each client request at any time.
  • the LBPRF (1 1) builds a real-time map of the server's topology, and with the "ready and in action" status of each server and service, based on the information obtained from the LBSEF ( 5 ', 6', 7 ', 8', 9 ', 10').
  • the main functions performed by the Entity (1 1) of the LBPRF comprises:
  • a high-level algorithm for implementing these main functions of the entity (1 1) of the LBPRF may comprise the following steps:
  • the LBPRF (1 1) receives a new request from an LBPEF (2 ', 3, 4'), activated by a content request issued by a customer (1)
  • the Type of Protocol (HTTP, FTP, TCP, SIP, SMTP, VolP, LDAP ).
  • the LBPRF (1 1) determines the kind of service requested, p. eg, a mathematical calculation. 4.
  • the LBPRF (1 1) extracts from the LBPRF Server Database which is the most suitable server for this request at this time, based on the following factors, for example: a. Amount of free resources from each server required for the content request. In a preferred embodiment, each individual resource of a server (5, 6, 7, 8, 9, 10) is weighted according to its importance for each type of request, e.g. For example, the free CPU could be the most weighted resource.
  • a possible implementation option comprises manually configuring a single default server, or a collection of them, in the entity (1 1) of the LBPRF, so that, in case the LBPRF (1 1) cannot connect with your LBPRF Server Database, or if no data is returned for the query in this Database, the server, or servers, can be used by default to process the request .
  • the LBPRF (1 1) answers the LBPEF (2 ⁇ 3, 4 ') question with the most appropriate server.
  • the response from the LBPRF (1 1) to the LBPEF (2 ⁇ 3, 4 ') may contain a period of validity, also called Life Time or TTL, which indicates that this response with the optimal server identification can be stored and used by the LBPEF (2 ', 3, 4') in similar subsequent requests. In this way, an increase in system performance is achieved if that period of validity is well tuned. In general, the smaller the TTL, the less resources available, and on the contrary, the larger.
  • the invention can be applied in traditional data centers or cloud data centers, since the management of each request for the most suitable server is automatic and transparent for the client's request or for the server, and therefore it is possible to use any type of hardware machine to function as servers. Even when a "virtual server” is implemented within a mixture of “virtual hardware servers,” the invention can apply this concept instead of the "hardware server” concept.
  • This invention is capable of assigning the most appropriate server to each request at any time, even if any service can start / stop on any machine, or in the event that a new machine is introduced into the system without stopping any architecture element .
  • a request for the Mathematical server reaches the Load Balancer.
  • the LPBEF element requests information from the LPBRF.
  • the LPBRF module selects the optimal server using the high level algorithm described above, taking into account that a mathematical request needs more CPU resources than memory. This factor is weighted in the algorithm.
  • the least loaded server is assigned, with 4 CPUs.
  • the LPBRF considers that this request needs more resources of Memory than of CPU.
  • the LPBRF responds with the most idle server, taking into account that the use of Memory is the main feature of this request.

Abstract

The invention relates to a method and system for balancing content requests in a server provider network (100) comprising a plurality of servers (5,6, 7, 8, 9, 10) and at least one load balancer (2, 3, 4), also comprising: at least one entity (11) responsible for the load balancer policy rules function, which is an independent entity that decides in real time which is the optimum server for each request; an entity (5', 6', 7', 8', 9', 10') responsible for the load balancer server enforcement function, associated with one of the servers (5, 6, 7, 8, 9, 10), which transmits information in real time from each server (5, 6, 7, 8, 9, 10) to the entity (11) responsible for the load balancer policy rules function; and an entity (2', 3, 4') responsible for the load balancer policy enforcement function, associated with a load balancer (2, 3, 4), which transmits information concerning a content request from a client (1) to the entity (11) responsible for the load balancer policy rules function.

Description

PROCEDIMIENTO Y SISTEMA PARA EQUILIBRAR SOLICITUDES DE CONTENIDO EN UNA RED PROVEEDORA DE SERVIDORES  PROCEDURE AND SYSTEM FOR BALANCING REQUESTS FOR CONTENTS IN A SERVER SUPPLIER NETWORK
Campo de la invención Field of the Invention
La presente invención tiene su aplicación dentro del sector de la telecomunicación y, especialmente, se refiere a un sistema y procedimiento para proporcionar equilibrio (o balance) de cargas en una red de comunicación con múltiples servidores de contenido. Antecedentes de la invención The present invention has its application within the telecommunication sector and, especially, refers to a system and method for providing balance (or balance) of loads in a communication network with multiple content servers. Background of the invention
En el modelo actual de Internet, la alta demanda de servicios requiere una arquitectura eficaz del plantel de servidores para satisfacer ese alto número de solicitudes de servicio. In the current Internet model, the high demand for services requires an effective architecture of the server campus to meet that high number of service requests.
Un plantel de servidores -server farm, en inglés-, o una agrupación de servidores -server cluster, en inglés-, es una colección de servidores informáticos, usualmente mantenidos por un Proveedor en Red de Servicios, para satisfacer necesidades de servidores mucho más allá de la capacidad de una máquina. Los planteles de servidores a menudo consisten en miles de ordenadores que requieren una gran cantidad de energía para funcionar. Los planteles de servidores están habitualmente cosituados con los conmutadores de red y / o los encaminadores, que permiten la comunicación entre las distintas partes de la agrupación y los usuarios de la agrupación. Los planteles de servidores logran alta escalabilidad y alta disponibilidad a través del equilibrio de cargas de los servidores. Los balanceadores o equilibradores de cargas -load balancers, en inglés- están encargados de asegurar que la carga de trabajo en cada servidor esté dentro de un pequeño entorno (o criterio de equilibrio) de la carga de trabajo presente en cada uno de los demás servidores en el sistema. A server farm -server farm, in English-, or a cluster of servers -server cluster, in English-, is a collection of computer servers, usually maintained by a Service Network Provider, to meet server needs far beyond of the capacity of a machine. Server campuses often consist of thousands of computers that require a lot of power to operate. Server campuses are usually coded with network switches and / or routers, which allow communication between the different parts of the cluster and the users of the cluster. Server sites achieve high scalability and high availability through server load balancing. Load balancers (load balancers, in English) are responsible for ensuring that the workload on each server is within a small environment (or balance criteria) of the workload present on each of the other servers in the system.
La Figura 1 muestra un típico sistema de plantel de servidores que comprende múltiples servidores (5, 6, 7, 8, 9, 10) en una red (100) proveedora de servidores. El equilibrio o balance de las cargas oculta el plantel de servidores (5, 6, 7, 8, 9, 10) a los clientes (1 ), que parecen conectarse con un único servidor. Los Equilibradores (2, 3, 4) de Cargas distribuyen la carga de trabajo entre los múltiples servidores (5, 6, 7, 8, 9, 10). El equilibrador (2, 3, 4) de cargas conectado con el cliente (1 ) a través de una red (101 ) de transporte, y al cual se despacha una solicitud de contenido por parte del cliente (1 ), selecciona uno de los servidores (5, 6, 7, 8, 9, 10) Final o de Trastienda - Back-end server, en inglés- entre el plantel de servidores de la red (100) proveedora de servidores, para procesar la solicitud de contenido. Un servidor - de Trastienda - es la entidad donde se alojan los contenidos (p. ej., ficheros, flujos, ...) distribuidos a los usuarios finales y el software que los distribuye. Figure 1 shows a typical server campus system comprising multiple servers (5, 6, 7, 8, 9, 10) in a network (100) server provider. The balance or load balance hides the server pool (5, 6, 7, 8, 9, 10) to the clients (1), which seem to connect to a single server. The Load Balancers (2, 3, 4) distribute the workload among multiple servers (5, 6, 7, 8, 9, 10). The load balancer (2, 3, 4) connected to the customer (1) through a transport network (101), and to which a content request is dispatched by the customer (1), select one of the servers (5, 6, 7, 8, 9, 10) Final or Back-end server, in English, between the network server servers (100) providing servers, to process the content request. A server - from Trastienda - is the entity where the contents (e.g., files, streams, ...) distributed to end users and the software that distributes them are hosted.
Hay distintos procedimientos para obtener mediciones acerca de servidores de trastienda y varios tipos de algoritmos / mecanismos de planificación para determinar, en base a esas mediciones, a cuál servidor de trastienda ha de enviarse la solicitud. Estos algoritmos / mecanismos para la selección de servidores de trastienda pueden ser categorizados como:  There are different procedures for obtaining measurements about backroom servers and various types of algorithms / planning mechanisms to determine, based on those measurements, to which backroom server the request should be sent. These algorithms / mechanisms for the selection of backroom servers can be categorized as:
- Centralizados / descentralizados:  - Centralized / decentralized:
• Algoritmos centralizados: En esta clase de algoritmos, hay un elemento central que recoge información desde los servidores y toma la decisión adecuada.  • Centralized algorithms: In this class of algorithms, there is a central element that collects information from the servers and makes the appropriate decision.
• Algoritmos descentralizados: En esta clase de algoritmos, cada equilibrador de cargas tiene información acerca de todos los servidores.  • Decentralized algorithms: In this class of algorithms, each load balancer has information about all servers.
- Nivel 4 / Nivel 7:  - Level 4 / Level 7:
• Equilibradores de cargas de nivel 4: esta clase de equilibradores de cargas no tiene en cuenta el contenido o aplicación que el usuario está solicitando. Estos equilibradores de cargas funcionan en la Capa 4 en el modelo OSI (basado en IP).  • Level 4 load balancers: this class of load balancers does not take into account the content or application that the user is requesting. These load balancers work in Layer 4 in the OSI (IP-based) model.
• Equilibradores de cargas de Nivel 7: estos equilibradores de cargas se llaman equilibradores de cargas sensibles al contenido, y son capaces de realizar una inspección completa de la capa 7. El equilibrio de cargas de la Capa 7 funciona usando tres técnicas principales: Análisis sintáctico de los URL, Intercepción de Cabeceras del HTTP e Intercepción de Señuelos. - Dinámicos / estáticos • Level 7 load balancers: These load balancers are called content-sensitive load balancers, and are capable of performing a complete inspection of layer 7. The layer 7 load balancing works using three main techniques: Syntactic analysis of the URLs, HTTP Header Interception and Decoy Interception. - Dynamic / static
• Algoritmos estáticos: Su comportamiento está predeterminado. Adjudican las tareas de un programa paralelo a un Servidor de Trastienda, en base a la carga en el momento en que se adjudican tareas a los nodos, o bien en base a una carga media del Servidor de Trastienda. • Static algorithms: Their behavior is predetermined. They assign the tasks of a program parallel to a Backroom Server, based on the load at the time when tasks are assigned to the nodes, or based on an average load of the Backroom Server.
• Algoritmos dinámicos: Esta clase de algoritmos toma decisiones según el estado de los sistemas, hace cambios en la distribución del trabajo entre los Servidores de Trastienda en tiempo de ejecución; usan información de carga actual o reciente al tomar decisiones de distribución.• Dynamic algorithms: This class of algorithms makes decisions according to the state of the systems, makes changes in the distribution of work among the Disorder Servers at runtime; use current or recent load information when making distribution decisions.
Desde el punto de vista de la recogida de mediciones, hay dos procedimientos para obtener información acerca de los servidores (de trastienda): From the point of view of the collection of measurements, there are two procedures to obtain information about the servers (backroom):
• Pasivos: analizan flujos entre clientes y servidores pasivamente, usando un encaminador u otro elemento de red. Un ejemplo de medición pasiva podría ser el Tiempo de Ida y Vuelta (RTT), calculado con el retardo de red y el retardo de procesamiento del servidor de cada SOlicitudíError! No se encuentra el origen de la referencia..  • Liabilities: analyze flows between clients and servers passively, using a router or other network element. An example of passive measurement could be the Round Trip Time (RTT), calculated with the network delay and the server processing delay of each SOIDIDITY! The origin of the reference is not found.
• Activos: solicitan distintas mediciones directamente a los servidores.  • Assets: request different measurements directly from the servers.
En esta clasificación, los equilibradores de cargas más avanzados usan algoritmos / procedimientos "dinámicos + pasivos + activos" y usan las técnicas de inspección del nivel 7. De tal modo, llevan la nueva solicitud al servidor ocioso en cada momento. El servidor ocioso está usualmente determinado o estimado usando solamente el tiempo de respuesta de red de un servidor.  In this classification, the most advanced load balancers use "dynamic + passive + active" algorithms / procedures and use level 7 inspection techniques. Thus, they take the new request to the idle server at all times. The idle server is usually determined or estimated using only the network response time of a server.
Convencionalmente, muchos sistemas equilibradores de cargas están configurados estáticamente para asignar a cada solicitud de usuario el servidor adecuado. Algunos enfoques existentes que permiten el equilibrio dinámico de cargas se describen a continuación. Conventionally, many load balancing systems are statically configured to assign the appropriate server to each user request. Some existing approaches that allow dynamic load balancing are described below.
Un ejemplo de un equilibrador dinámico de cargas para múltiples servidores de red se revela en el documento EP1 1 16082. Este equilibrador de cargas examina las cargas en los servidores y ajusta sus colas usando un algoritmo descentralizado, pero el algoritmo de equilibrio de cargas solamente tiene en cuenta el valor de CPU para actualizar la información para cada equilibrador de cargas, con el objeto de obtener el equilibrio de CPU entre todos los servidores. Otro ejemplo de un algoritmo de equilibrio de cargas está descrito en el documento WO 2009 / 004734, en el cual una pluralidad de servidores reales, que forman un sistema servidor virtual, transmiten a un único Equilibrador de Cargas de Servidor (SLB) sus respectivos estados de carga, junto con información de comunicación usada para la distribución de las solicitudes. El SLB almacena la información de comunicación recibida como información nueva acerca de destinos de distribuciones si esta nueva información de comunicación no es almacenada en una base de datos (DB) de gestión de servicios. En base a los estados de carga transmitidos por los servidores reales, la información almacenada en la DB de gestión de servicios y la nueva información acerca de los destinos de las distribuciones, el SLB realiza el equilibrio de cargas de las diversas solicitudes a la pluralidad de servidores reales. Esta arquitectura está orientada a facilitar la gestión, permitiendo cambios en los servidores reales, pero no tiene en cuenta la caracterización de la solicitud proveniente del cliente. En los sistemas existentes de equilibrio de cargas, el agregado de nuevos servidores a la topología del sistema, o un cambio por parte de uno de los servidores en su oferta de servicios, también requieren un cambio, manualmente por parte del proveedor de servicios, en la política de configuración del equilibrador de cargas. Además, los Equilibradores de Cargas existentes no tienen en cuenta la caracterización de la solicitud proveniente del cliente, por ejemplo, el caso en que una solicitud necesite más CPU que recursos de Memoria para ser ejecutada de manera óptima. An example of a dynamic load balancer for multiple network servers is disclosed in EP1 1 16082. This load balancer examines the loads on the servers and adjusts their queues using an algorithm decentralized, but the load balancing algorithm only takes into account the CPU value to update the information for each load balancer, in order to obtain the CPU balance between all servers. Another example of a load balancing algorithm is described in WO 2009/004734, in which a plurality of real servers, which form a virtual server system, transmit their respective states to a single Server Load Balancer (SLB) loading, along with communication information used for the distribution of requests. The SLB stores the communication information received as new information about distribution destinations if this new communication information is not stored in a service management database (DB). Based on the load states transmitted by the real servers, the information stored in the service management DB and the new information about the destinations of the distributions, the SLB balances the loads of the various requests to the plurality of real servers. This architecture is aimed at facilitating management, allowing changes in real servers, but does not take into account the characterization of the request from the client. In existing load balancing systems, the addition of new servers to the system topology, or a change by one of the servers in your service offering, also requires a change, manually by the service provider, in Load balancer configuration policy. In addition, the existing Load Balancing does not take into account the characterization of the request from the client, for example, the case in which a request needs more CPU than Memory resources to be executed optimally.
Por ejemplo, en un escenario de red como el mostrado en la Figura 2, bajo la hipótesis de que los servidores de trastienda (V2, V3, D2, D3, M2, M3) están agrupados por el tipo de servicios que proporcionan, p. ej., vídeo, base de datos, cálculos matemáticos, etc., que forman respectivamente, un plantel (100v) de servidores de vídeo, un plantel (100D) de servidores de bases de datos y un plantel (100M) de servidores matemáticos, la arquitectura del sistema de equilibrio de cargas es muy rígida. Las solicitudes de clientes (1 ) son siempre equilibradas para un servidor ocioso por el correspondiente Equilibrador de Cargas (V1 , D1 , M1 ), que gestiona el tráfico del servicio específico: flujo de vídeo (f1 ), flujo de datos (f2) o flujo matemático (f3). Cada Equilibrador de Cargas (V1 , D1 , M1 ) está conectado a un servidor lógico agrupado, es decir, con cada plantel (100v, 100D, 100M) de servidores temáticos, como un equilibrador dedicado. Por lo tanto, esta arquitectura convencional no permite el equilibrio de cargas en tiempo real, dado que no es posible cambiar los servicios sin cambiar la política de configuración en los equilibradores de cargas. Siguiendo el ejemplo en la Figura 2, si el proveedor de servidores decide detener un "Servicio matemático" en un servidor (M3) del plantel (100M) de servidores matemáticos, a fin de iniciar en el mismo servidor (M3) un nuevo servicio de vídeo, los respectivos equilibradores de cargas, (M1 ) y (V1 ), del plantel (100M) de servidores matemáticos y el plantel (100v) de servidores de vídeo requieren que se cambie su configuración según la nueva topología de red. Además, el problema aumenta cuando estos servidores temáticos no están cosituados en un mismo plantel de servidores y dependen de distintos equilibradores de cargas. En este tipo de arquitectura tradicional, el equilibrio de cargas siempre se realiza de acuerdo al servicio solicitado, con las máquinas a las cuales se solicita el servicio y con la estimación de la máquina ociosa. No obstante, no es posible decidir en tiempo real cuál servidor es el óptimo considerando una función de todas sus características propias (CPU, memoria, ancho de banda, retardo...) y sus características principales requeridas por la clase de servicio solicitado. Más específicamente, por ejemplo, si un servicio específico necesita un montón de ancho de banda (p. ej., un servicio de vídeo), mientras que otro servicio necesita un montón de potencia de CPU (p. ej., calculadores matemáticos), no es posible decidir en tiempo real cuál es el servidor óptimo para la siguiente solicitud del cliente. Normalmente, los centros de datos contienen máquinas servidoras con características de hardware muy similares entre sí, pero si no es así, surge otra cuestión y entonces el equilibrador de cargas necesita estar configurado con distintos pesos en función de la estimación de potencia de cada máquina, donde la potencia es una medida rígida que refleja la capacidad de hardware conjunta. Nuevamente, en este escenario, no es posible introducir dinámicamente cambios en la red proveedora de servidores. For example, in a network scenario like the one shown in Figure 2, under the hypothesis that backroom servers (V2, V3, D2, D3, M2, M3) are grouped by the type of services they provide, e.g. eg, video, database, mathematical calculations, etc., which respectively form a campus (100 v ) of video servers, a campus (100 D ) of database servers and a campus (100 M ) of mathematical servers, the architecture of the load balancing system is very rigid. Customer requests (1) are always balanced for an idle server by the corresponding Load Balancer (V1, D1, M1), which manages the traffic of the specific service: flow of video (f1), data flow (f2) or mathematical flow (f3). Each Load Balancer (V1, D1, M1) is connected to a grouped logical server, that is, with each campus (100 v , 100 D , 100 M ) of thematic servers, such as a dedicated balancer. Therefore, this conventional architecture does not allow load balancing in real time, since it is not possible to change services without changing the configuration policy in load balancers. Following the example in Figure 2, if the server provider decides to stop a "Mathematical Service" on a server (M3) of the campus (100 M ) of mathematical servers, in order to start a new service on the same server (M3) of video, the respective load balancers, (M1) and (V1), of the campus (100 M ) of mathematical servers and the campus (100 v ) of video servers require that their configuration be changed according to the new network topology. In addition, the problem increases when these thematic servers are not cosituted in the same campus and depend on different load balancers. In this type of traditional architecture, load balancing is always performed according to the requested service, with the machines to which the service is requested and with the idle machine estimate. However, it is not possible to decide in real time which server is the optimum considering a function of all its own characteristics (CPU, memory, bandwidth, delay ...) and its main characteristics required by the kind of service requested. More specifically, for example, if a specific service needs a lot of bandwidth (e.g., a video service), while another service needs a lot of CPU power (e.g., mathematical calculators), It is not possible to decide in real time which is the optimal server for the client's next request. Normally, data centers contain server machines with very similar hardware characteristics to each other, but if not, another issue arises and then the load balancer needs to be configured with different weights depending on the power estimate of each machine, where power is a rigid measure that reflects the ability of joint hardware. Again, in this scenario, it is not possible to dynamically introduce changes in the server provider network.
Por lo tanto, existe la necesidad, en el estado de la técnica, de un sistema y procedimiento de equilibrio de cargas que asegure una decisión en tiempo real en la cual esté el servidor óptimo para la solicitud del cliente, estando la decisión en función de cada característica de cada servidor, y de la caracterización del servicio, así como de las características de la solicitud, teniendo en cuenta también el estado actual del servidor. Therefore, there is a need, in the state of the art, for a load balancing system and procedure that ensures a real-time decision in which the optimal server is for the client's request, the decision being depending on each feature of each server, and the characterization of the service, as well as the characteristics of the request, also taking into account the current status of the server.
Resumen de la invención Summary of the Invention
La presente invención resuelve los problemas precitados revelando un procedimiento y un sistema que está aprendiendo constantemente de la información sobre servidores en una agrupación (plantel de servidores), de sus servicios y de las solicitudes por parte de los clientes, a fin de ajustar en tiempo real la decisión sobre el equilibrio de las solicitudes para los servidores, en base a los siguientes parámetros:  The present invention solves the aforementioned problems by revealing a procedure and a system that is constantly learning from the information about servers in a cluster (server staff), its services and requests from customers, in order to adjust in time Real decision on the balance of requests for servers, based on the following parameters:
• Características de los recursos requeridos por la clase determinada de servicio solicitada por el cliente, p. ej., retardo, CPU actual, memoria RAM, ... En una realización de la invención, cada recurso puede ser ponderado dinámicamente (e individualmente, en lugar de ponderar el recurso de energía total de la máquina servidora, como en la técnica anterior) por su importancia para cada tipo de solicitud del cliente. • Characteristics of the resources required by the specific kind of service requested by the client, p. eg, delay, current CPU, RAM, ... In one embodiment of the invention, each resource can be dynamically weighted (and individually, instead of weighing the total energy resource of the serving machine, as in the prior art ) for its importance for each type of client request.
• Características y cambios en la topología de red de la(s) agrupación(es) de servidores de la red proveedora de servidores.• Characteristics and changes in the network topology of the server group (s) of the server provider network.
• Características de todos los servicios que disponen de soporte, y se ejecutan, en cada servidor de la agrupación de servidores.• Characteristics of all services that have support, and are running, on each server in the server pool.
• Cambios en el estado de cada servidor a fin de conocer la capacidad o incapacidad de proporcionar un servicio específico en el momento actual, es decir, determinar si el servidor es capaz o no de gestionar el tráfico entrante actual. El estado del servidor está en forma normalizada y, en una realización preferida de la invención, puede remitirse al estado de cada recurso del servidor: retardo, CPU actual, Memoria RAM... • Changes in the status of each server in order to know the ability or inability to provide a specific service at the current time, that is, determine whether or not the server is capable of managing current incoming traffic. The status of the server is in standardized form and, in a preferred embodiment of the invention, the status of each server resource can be referred to: delay, current CPU, RAM ...
En el contexto de la invención, se usan los siguientes conceptos:  In the context of the invention, the following concepts are used:
Cliente: cálculo o programa que solicita datos o información a un Servidor.  Client: calculation or program that requests data or information from a Server.
Servidor (de Trastienda): Máquina donde están ejecutándose uno o varios Servicios.  Server (Backroom): Machine where one or more Services are running.
Servicio: Programa de software que proporciona información, contenido o asistencia a un Cliente en una red de ordenadores. Service: Software program that provides information, content or Customer assistance in a computer network.
Solicitud de Servicio: solicitud emitida por Clientes para intentar acceder a cierto contenido (de aplicación / servicio) (p. ej., segmentos en sistemas de IPTV o bloques de ficheros en sistemas de descarga de ficheros) suministrable por uno o más Servidores asociados a una clase de servicio.  Service Request: request issued by Customers to try to access certain content (application / service) (e.g., segments in IPTV systems or file blocks in file download systems) that can be supplied by one or more Servers associated with A kind of service.
Equilibrador de Cargas: entidad de red central responsable de distribuir el tráfico entrante entre los Servidores que alojan el mismo contenido de aplicación, equilibrar las solicitudes de contenido entre múltiples servidores para mejorar la utilización de los servidores y maximizar la disponibilidad. Un equilibrador de cargas es capaz de tomar decisiones de tráfico en base a información tradicional de la capa 2 y 3 del modelo OSI, y los equilibradores de cargas más avanzados pueden tomar decisiones inteligentes de gestión de tráfico basándose también en información específica de las capas 4 a 7, contenida dentro de la solicitud emitida por el cliente. Los equilibradores de cargas también incorporan habitualmente la traducción de direcciones de red (NAT) para cegar la dirección de IP del servidor de aplicaciones de trastienda, y son capaces de determinar el servidor físico o virtual para enviar la solicitud del cliente. El equilibrador de cargas gestiona todo el tráfico bidireccional entre el cliente y el servidor. Una vez que la solicitud es recibida y procesada, el servidor envía su respuesta al cliente mediante el equilibrador de cargas, que correlaciona cada respuesta de la aplicación con la conexión correcta del cliente, asegurando que cada usuario reciba la respuesta adecuada. La presente invención se basa en una única arquitectura sencilla de sistema de equilibrio de cargas, que comprende las siguientes tres entidades de red de una red proveedora de servidores: la Función de Refuerzo del Servidor del Equilibrador de Cargas (LBSEF) asignada a un Servidor de la red proveedora de servidores, la Función de Refuerzo de la Política del Equilibrador de Cargas (LBPEF) asignada a un Equilibrador de Cargas de la red proveedora de servidores, y la Función de Reglas de la Política del Equilibrador de Cargas (LBPRF), en comunicación con cada LBSEF y LBPEF de la red proveedora de servidores. Más específicamente,  Load Balancing: central network entity responsible for distributing incoming traffic among Servers that host the same application content, balancing content requests between multiple servers to improve server utilization and maximize availability. A load balancer is capable of making traffic decisions based on traditional information from layers 2 and 3 of the OSI model, and more advanced load balancers can make intelligent traffic management decisions based also on specific information from layers 4 to 7, contained within the request issued by the client. Load balancers also routinely incorporate network address translation (NAT) to blind the IP address of the backroom application server, and are able to determine the physical or virtual server to send the client's request. The load balancer manages all bidirectional traffic between the client and the server. Once the request is received and processed, the server sends its response to the client through the load balancer, which correlates each response of the application with the correct connection of the client, ensuring that each user receives the appropriate response. The present invention is based on a single simple load balancing system architecture, comprising the following three network entities of a server provider network: the Load Balancing Server (LBSEF) Reinforcement Function assigned to a Server the server provider network, the Load Balancer Policy Reinforcement Function (LBPEF) assigned to a Load Balancer of the server provider network, and the Load Balancer Policy Rule Function (LBPRF), in communication with each LBSEF and LBPEF of the server provider network. More specifically,
• Función de Refuerzo del Servidor del Equilibrador de Cargas (LBSEF): Esta entidad recoge información acerca del servidor al que está asignada y envía la información recogida a la LBPRF. Además, ejecuta algunas instrucciones básicas ordenadas por la LBPRF (servicios de parada / arranque, monitorización / comprobación de estado de servidores...). La LBSEF puede ser definida como un elemento del Plano de Datos. • Load Balancer Server Booster Function (LBSEF): This entity collects information about the server to which it is assigned and sends the collected information to the LBPRF. In addition, it executes some basic instructions ordered by the LBPRF (stop / start services, server status monitoring / checking ...). The LBSEF can be defined as an element of the Data Plane.
• La Función de Reglas de la Política del Equilibrador de Cargas (LBPRF): Una entidad sin dependencia que decide en tiempo real cuál es el servidor óptimo para cada petición. En una posible realización de la invención, solamente se requiere una instancia de este elemento, pero se recomiendan varios por razones de redundancia y de ajustabilidad a escala. La LBPRF puede ser definida como un elemento del Plano de Control. • The Load Balancing Policy Rules Function (LBPRF): An entity without dependency that decides in real time which is the optimal server for each request. In a possible embodiment of the invention, only one instance of this element is required, but several are recommended for reasons of redundancy and scalability. The LBPRF can be defined as an element of the Control Plane.
• Función de Refuerzo de la Política del Equilibrador de Cargas (LBPEF): Esta entidad analiza cada solicitud entrante proveniente del cliente, para extraer información referida a la solicitud, envía esta información resumida y pide instrucciones a la LBPRF acerca del servidor óptimo donde resolverla / retransmitirla. En una realización preferida de la invención, la LBPEF puede ser una parte integrada de un nodo equilibrador de cargas. La LBPEF puede ser definida también como un elemento del Plano de Datos. • Load Balancer Policy Reinforcement Function (LBPEF): This entity analyzes each incoming request from the client, to extract information regarding the request, sends this summary information and asks the LBPRF for instructions on the optimal server where to resolve it. broadcast it. In a preferred embodiment of the invention, the LBPEF can be an integrated part of a load-balancing node. The LBPEF can also be defined as an element of the Data Plane.
Según un primer aspecto de la presente invención, se revela un procedimiento para equilibrar solicitudes de contenido en una red proveedora de servidores, y que comprende las siguientes etapas:  According to a first aspect of the present invention, a method for balancing content requests in a server provider network is revealed, and comprising the following steps:
- recibir un resumen de información contenida en una solicitud de contenido desde un cliente de la red proveedora de servidores; - receive a summary of information contained in a content request from a client of the server provider network;
- recibir información de tiempo real referida a cada servidor de la red proveedora de servidores, incluyendo la información al menos información de estado de cada servidor, información de servicio de cada servicio ejecutándose en cada servidor y la topología actual de la red proveedora de servidores; - receive real-time information referring to each server in the server provider network, including information at least status information of each server, service information of each service running on each server and the current topology of the server provider network;
- para la solicitud de contenido recibida, escoger un servidor que sea el óptimo para la solicitud de contenido, entre los servidores de la red proveedora de servidores, en base a un algoritmo de equilibrio de cargas que tiene en cuenta toda la información recibida en las dos etapas anteriores. - for the content request received, choose a server that is optimal for the content request, among the network servers server provider, based on a load balancing algorithm that takes into account all the information received in the previous two stages.
En una realización de la invención, toda la información es recibida en una entidad de la Función de Reglas de la Política del Equilibrador de Cargas, que escoge el servidor óptimo para la solicitud de contenido recibida, en base al algoritmo de equilibrio de cargas, y en donde:  In one embodiment of the invention, all the information is received in an entity of the Load Balancing Policy Rules Function, which chooses the optimal server for the content request received, based on the load balancing algorithm, and where:
- el resumen de información contenido en la solicitud de contenido es recibido desde una entidad de la Función de Refuerzo de la Política del Equilibrador de Cargas, asociada al equilibrador de cargas que recibe la solicitud de contenido desde el cliente;  - the summary of information contained in the content request is received from an entity of the Load Balancer Policy Reinforcement Function, associated with the load balancer that receives the content request from the client;
- la información referida a cada servidor es recibida desde una entidad de la Función de Refuerzo del Servidor del Equilibrador de Cargas, asociada respectivamente a cada servidor de la red proveedora de servidores.  - the information referred to each server is received from an entity of the Load Balancing Server Reinforcement Function, associated respectively with each server in the server provider network.
Por lo tanto, el procedimiento para equilibrar solicitudes de contenido, que puede ser implementado en una entidad de la Función de Reglas de la Política del Equilibrador de Cargas, escoge el servidor óptimo para cada solicitud, teniendo en cuenta los recursos que la solicitud necesita y usando, en una posible realización de la invención, un algoritmo ponderado. El algoritmo ponderado gestiona y procesa información acerca de la clase de servicio que la agrupación está alojando, y acerca de cuáles son las características principales que necesita el servicio. Además, este procedimiento aprende en tiempo real acerca de los cambios en la topología del plantel / agrupación de servidores, aprende en tiempo real acerca de los servicios "listos y en acción" en cada servidor, y puede aprender acerca de agregados, modificaciones o eliminaciones para los servicios ofrecidos por la agrupación de servidores. Una base de datos históricos, integrada en la LBPRF, o accesible por la entidad de la Función de Reglas de la Política del Equilibrador de Cargas, puede ser usada para almacenar las enseñanzas, o la información, de modo que puedan ser introducidos algoritmos heurísticos a fin de mejorar aún más la asignación del servidor óptimo en cada momento.  Therefore, the procedure for balancing content requests, which can be implemented in an entity of the Load Balancer Policy Rules Function, chooses the optimal server for each request, taking into account the resources that the request needs and using, in a possible embodiment of the invention, a weighted algorithm. The weighted algorithm manages and processes information about the kind of service the group is hosting, and about what are the main features that the service needs. In addition, this procedure learns in real time about changes in the topology of the campus / server pool, learns in real time about the "ready and in action" services on each server, and can learn about aggregates, modifications or deletions for the services offered by the server pool. A historical database, integrated into the LBPRF, or accessible by the Load Balancer Policy Rules Function entity, can be used to store the teachings, or information, so that heuristic algorithms can be introduced to in order to further improve the optimal server allocation at all times.
Un segundo aspecto de la presente invención se refiere a un sistema que está integrado en una red proveedora de servidores que comprende una pluralidad de servidores de contenidos, para equilibrar solicitudes de contenido provenientes de usuarios de la red proveedora de servidores. El sistema comprende una o más entidades de la Función de Reglas de la Política del Equilibrador de Cargas, para equilibrar las solicitudes de contenido en una red proveedora de servidores, que proporciona múltiples servidores de contenido asociados a al menos unA second aspect of the present invention relates to a system that is integrated into a server provider network comprising a plurality of Content servers, to balance content requests from users of the server provider network. The system comprises one or more entities of the Load Balancing Policy Rules Function, to balance content requests in a server provider network, which provides multiple content servers associated with at least one
Equilibrador de Cargas. La Función de Reglas de la Política del Equilibrador de Cargas (LBPRF) implementa el procedimiento anteriormente descrito. El sistema comprende adicionalmente una o más entidades de la Función de Refuerzo de la Política del Equilibrador de Cargas (LBPEF), asociadas a al menos un Equilibrador de Cargas, a cargo de enviar a la LBPRF un resumen de la información contenida en una solicitud de contenido proveniente del cliente de la red proveedora de servidores. La LBPEF analiza cada nueva solicitud de cliente, envía esta información resumida y pide instrucciones a la LBPRF. Además, el sistema comprende una o más entidades de la Función de Refuerzo del Servidor del Equilibrador de Cargas, recogiendo cada entidad de la Función de Refuerzo del Servidor del Equilibrador de Cargas (LBSEF) asociada a uno de los servidores, información referida al servidor asociado, y enviando información en tiempo real acerca del servidor a la LBPRF. La LBPRF es una entidad independiente que proporciona medios para decidir en tiempo real cuál es el servidor óptimo para cada solicitud de cliente, en base a la información recibida sobre servicios, servidores y solicitudes de clientes. Load balancer. The Load Balancer Policy Rules Function (LBPRF) implements the procedure described above. The system additionally comprises one or more entities of the Load Balancer Policy Reinforcement Function (LBPEF), associated with at least one Load Balancer, in charge of sending to the LBPRF a summary of the information contained in a request for content from the client of the server provider network. The LBPEF analyzes each new customer request, sends this summary information and asks the LBPRF for instructions. In addition, the system comprises one or more entities of the Load Balancer Server Reinforcement Function, each entity collecting the Load Balancer Server Reinforcement Function (LBSEF) associated with one of the servers, information referred to the associated server , and sending real-time information about the server to the LBPRF. The LBPRF is an independent entity that provides means to decide in real time which is the optimal server for each client request, based on the information received about services, servers and client requests.
El procedimiento y sistema de acuerdo a los aspectos anteriormente descritos de la invención tienen un cierto número de ventajas con respecto a la técnica anterior, resumidas de la siguiente manera:  The method and system according to the previously described aspects of the invention have a number of advantages over the prior art, summarized as follows:
- La presente invención tiene en cuenta las características de la solicitud emitida por el cliente, las características del servidor, incluso su información de estado (que permite a los administradores de servidores determinar cuán bien se está desempeñando actualmente su servidor) y características del servicio, para cada clase de servicio, a diferencia del enfoque revelado en el documento EP1 1 16082, que considera solamente el recurso de CPU de los servidores. De este modo, la presente invención asigna, en tiempo real, la solicitud de los clientes para un servidor o servicio al servidor óptimo, haciendo mejor uso de los recursos totales. También la patente WO 2009 / 004734 se basa en servidores que ejecutan diversos procesos de manera similar y que no tienen en cuenta las características de la solicitud. - The present invention takes into account the characteristics of the request issued by the client, the characteristics of the server, including its status information (which allows server administrators to determine how well their server is currently performing) and characteristics of the service, for each class of service, unlike the approach revealed in EP1 1 16082, which considers only the CPU resource of the servers. In this way, the present invention assigns, in real time, the client request for a server or service to the optimal server, making better use of the total resources. Also patent WO 2009/004734 is based on servers that execute various processes in a similar manner and that do not take into account the characteristics of the request
- La presente invención permite el uso de una mezcla de máquinas con distintas características de hardware en un centro de datos, y sin ninguna configuración en cada equilibrador de cargas, ya que una nueva máquina es simplemente añadida como un elemento para "conectar y usar" y solamente es necesario que esté configurado un punto (su LBSEF asociado).  - The present invention allows the use of a mixture of machines with different hardware characteristics in a data center, and without any configuration in each load balancer, since a new machine is simply added as an element to "connect and use" and only one point (its associated LBSEF) needs to be configured.
- Dado que la presente invención usa una base de datos históricos de solicitudes / respuestas anteriores desde clientes / servidores, podrían introducirse nuevos algoritmos heurísticos a fin de mejorar aún más la asignación del servidor óptimo en cada momento.  - Since the present invention uses a historical database of previous requests / responses from clients / servers, new heuristic algorithms could be introduced in order to further improve the optimal server allocation at all times.
- A diferencia de las soluciones de la técnica anterior, donde se necesitan arquitecturas individuales de equilibrio de cargas para cada clase de servicios que deban ser atendidos por un servidor o un plantel de servidores, lo que conduce al despilfarro de recursos, la presente invención usa una única arquitectura para servir a todos, con el correspondiente ahorro en hardware. - Unlike the prior art solutions, where individual load balancing architectures are needed for each class of services that must be serviced by a server or a server campus, which leads to waste of resources, the present invention uses a single architecture to serve everyone, with the corresponding hardware savings.
Estas y otras ventajas serán evidentes a la luz de la descripción detallada de la invención. These and other advantages will be apparent in light of the detailed description of the invention.
Descripción de los dibujos  Description of the drawings
Con el fin de asistir a la comprensión de las características de la invención, según una realización práctica preferida de la misma, y a fin de complementar esta descripción, se añaden las siguientes figuras como parte integral de la misma, teniendo un carácter ilustrativo y no limitador.  In order to assist in the understanding of the features of the invention, according to a preferred practical embodiment thereof, and in order to complement this description, the following figures are added as an integral part thereof, having an illustrative and non-limiting character .
La Figura 1 muestra un diagrama de bloques de la arquitectura convencional de un sistema para equilibrar solicitudes de contenido, según lo conocido en la técnica anterior.  Figure 1 shows a block diagram of the conventional architecture of a system for balancing content requests, as known in the prior art.
La Figura 2 muestra un escenario de red de un sistema para equilibrar solicitudes de contenido, según lo conocido en la técnica anterior, que comprende distintas agrupaciones de servidores distinguidas por la clase de contenido.  Figure 2 shows a network scenario of a system for balancing content requests, as known in the prior art, comprising different server groupings distinguished by the content class.
La Figura 3 muestra un diagrama de bloques de la arquitectura de sistema, para equilibrar solicitudes de contenido en una red proveedora de servidores, según una realización preferida de la invención. Figure 3 shows a block diagram of the system architecture, for balancing content requests in a server provider network, according to a preferred embodiment of the invention.
La Figura 4 muestra un diagrama de flujo de mensajes en el sistema de la Figura 3 para equilibrar solicitudes de contenido, de acuerdo a una posible realización de la invención. Figure 4 shows a message flow diagram in the system of Figure 3 for balancing content requests, according to a possible embodiment of the invention.
La Figura 5 muestra un diagrama de flujo de mensajes en el sistema de la Figura 3 para recoger el estado de los servidores, de acuerdo a una posible aplicación de la invención.  Figure 5 shows a message flow diagram in the system of Figure 3 to collect the status of the servers, according to a possible application of the invention.
Realización preferida de la invención Preferred Embodiment of the Invention
Los asuntos definidos en esta descripción detallada se proporcionan para asistir en la comprensión exhaustiva de la invención. En consecuencia, los medianamente expertos en la técnica reconocerán que pueden hacerse variaciones, cambios y modificaciones de las realizaciones descritas en la presente memoria sin apartarse del alcance y el espíritu de la invención. The issues defined in this detailed description are provided to assist in the thorough understanding of the invention. Consequently, those of ordinary skill in the art will recognize that variations, changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention.
Además, la descripción de funciones y elementos bien conocidos se omite para mayor claridad y concisión. In addition, the description of well-known functions and elements is omitted for clarity and conciseness.
Por supuesto, las realizaciones de la invención pueden ser implementadas en una gran variedad de plataformas arquitectónicas, sistemas operativos y servidores, dispositivos, sistemas o aplicaciones. Cualquier diseño o implementación arquitectónica específica presentada en la presente memoria se proporciona solamente con fines de ilustración y comprensión, y ninguno está concebido para limitar aspectos de la invención.  Of course, the embodiments of the invention can be implemented in a wide variety of architectural platforms, operating systems and servers, devices, systems or applications. Any specific architectural design or implementation presented herein is provided for purposes of illustration and understanding only, and none is intended to limit aspects of the invention.
Es dentro de este contexto que se presentan ahora diversas realizaciones de la invención, con referencia a las FIGs. 3 a 5.  It is within this context that various embodiments of the invention are now presented, with reference to FIGs. 3 to 5
La Figura 3 presenta un sistema para equilibrar solicitudes de contenidos en una red (100) proveedora de servidores que comprende las siguientes entidades de red:  Figure 3 presents a system for balancing content requests on a server provider network (100) comprising the following network entities:
• al menos una entidad (1 1 ) de la Función de Reglas de la Política del Equilibrador de Cargas, LBPRF, a cargo de seleccionar en tiempo real cuál es el servidor óptimo para cada solicitud de contenido, siendo el servidor óptimo uno seleccionado entre una pluralidad de servidores (5, 6, 7, 8, 9, 10) que forman un plantel dinámico de servidores asociado a al menos un Equilibrador de Cargas (2, 3, 4);  • at least one entity (1 1) of the Load Balancing Policy Rules Function, LBPRF, in charge of selecting in real time which is the optimal server for each content request, the optimal server being one selected from a plurality of servers (5, 6, 7, 8, 9, 10) that form a dynamic campus of servers associated with at least one Load Balancer (2, 3, 4);
• una pluralidad de entidades (5', 6', 7', 8', 9', 10') de la Función de Refuerzo del Servidor del Equilibrador de Cargas, LBSEF, estando cada entidad de la LBSEF a cargo de recoger información acerca del servidor con el cual está comunicada, y de enviarla a la entidad (1 1 ) de la Función de Reglas de la Política del Equilibrador de Cargas; y • a plurality of entities (5 ', 6', 7 ', 8', 9 ', 10') of the Load Balancer Server Reinforcement Function, LBSEF, each LBSEF entity being in charge of collecting information about of the server with which it is communicated, and of send it to the entity (1 1) of the Rules Function of the Load Balancer Policy; Y
• al menos una entidad (2', 3', 4') de la Función de Refuerzo de la Política del Equilibrador de Cargas, LBPEF, a cargo de analizar cada solicitud de contenido entrante enviada por un cliente (1 ), y de enviar un resumen de la información analizada, así como una solicitud de instrucciones, a la entidad (1 1 ) de la Función de Reglas de la Política del Equilibrador de Cargas.  • at least one entity (2 ', 3', 4 ') of the Load Balancing Policy Reinforcement Function, LBPEF, in charge of analyzing each incoming content request sent by a customer (1), and sending a summary of the information analyzed, as well as a request for instructions, to the entity (1 1) of the Rules Function of the Load Balancer Policy.
La Figura 4 muestra un diagrama de flujo de los mensajes de comunicación intercambiados en el sistema descrito anteriormente, que ilustra el flujo de información entre la entidad (2', 3', 4') de la Función de Refuerzo de la Política del Equilibrador de Cargas y la entidad (1 1 ) de la Función de Reglas de la Política del Equilibrador de Cargas, cuando un cliente (1 ) extrae un Servicio desde uno de los servidores (5, 6, 7, 8, 9, 10) del plantel dinámico de servidores, por ejemplo, el servidor (5) en la Figura 3, y todas las entidades de red implicadas en este proceso, que comprende las siguientes etapas:  Figure 4 shows a flow chart of the communication messages exchanged in the system described above, illustrating the flow of information between the entity (2 ', 3', 4 ') of the Booster Function of the Balancer Policy of Loads and the entity (1 1) of the Load Balancing Policy Rules Function, when a client (1) extracts a Service from one of the servers (5, 6, 7, 8, 9, 10) of the campus Dynamic server, for example, the server (5) in Figure 3, and all the network entities involved in this process, comprising the following stages:
• El cliente (1 ) envía una Solicitud de Servicio (401 ) para solicitar contenido de servicios de una red (100) proveedora de servidores.  • The client (1) sends a Service Request (401) to request service content from a network (100) server provider.
• Un Equilibrador de Cargas (2) recibe esta solicitud y la reenvía (402) a su LBPEF (2') enlazada. La LBPEF (2') puede ser implementada en un nodo conectado con el Equilibrador de Cargas (2), o integrada en el mismo nodo del Equilibrador de Cargas (2).  • A Load Balancer (2) receives this request and forwards it (402) to its linked LBPEF (2 '). The LBPEF (2 ') can be implemented in a node connected to the Load Balancer (2), or integrated into the same Load Balancer node (2).
• La LBPEF (2') resume la solicitud para obtener los datos principales, normalmente los datos de cabecera con el nombre del servicio, los puertos implicados, etc., y, en general, cualquier dato que sea útil para identificar el servicio, y envía esta información que identifica el servicio y la solicitud (403) a la LBPRF (1 1 ).  • The LBPEF (2 ') summarizes the request to obtain the main data, usually the header data with the name of the service, the ports involved, etc., and, in general, any data that is useful to identify the service, and send this information that identifies the service and the request (403) to the LBPRF (1 1).
• La LBPRF (1 1 ) toma una decisión, en función de la información recibida de la LBPEF (2'), y aplicando un algoritmo de equilibrio de cargas descrito más adelante, también en base a la información desde los servidores disponibles (5, 6, 7, 8, 9, 10) del plantel dinámico de servidores, a fin de seleccionar un servidor óptimo, que es notificado (404) a la LBPEF (2') en respuesta a la información enviada antes. • The LBPRF (1 1) makes a decision, based on the information received from the LBPEF (2 '), and applying a load balancing algorithm described below, also based on the information from the available servers (5, 6, 7, 8, 9, 10) of dynamic campus of servers, in order to select an optimal server, which is notified (404) to the LBPEF (2 ') in response to the information sent before.
• La LBPEF (1 1 ) remite (405) la notificación del servidor óptimo al equilibrador (2) de cargas enlazado.  • The LBPEF (1 1) sends (405) the notification of the optimal server to the linked load balancer (2).
• El Equilibrador de Cargas (2) solicita el servicio (406) al servidor seleccionado por la LBPRF (1 1 ), p. ej., el servidor (5).  • Load Balancer (2) requests the service (406) from the server selected by the LBPRF (1 1), p. eg, the server (5).
• El Servidor (5) procesa la solicitud y le da servicio normalmente • Server (5) processes the request and serves it normally
(407) . (407).
• El Equilibrador de Cargas (2) retransmite el servicio o contenido • Load Balancer (2) retransmits the service or content
(408) . (408).
En la Figura 4, alguna entidad específica instanciada se muestra solo como un ejemplo, p. ej., el servidor (5) como el óptimo, pero el diagrama de flujo es completamente equivalente a cualquier otro.  In Figure 4, some specific instantiated entity is shown only as an example, e.g. eg, the server (5) as the optimum, but the flowchart is completely equivalent to any other.
La Figura 5 muestra un diagrama de flujo del protocolo entre la LBPRF (1 1 ) y cualquiera de las entidades (5', 6', 7', 8', 9', 10') de la Función de Refuerzo del Servidor del Equilibrador de Cargas, solo como una LBSEF (5') ejemplar, para obtener los detalles de estado de cada servidor asociado (5, 6, 7, 8, 9, 10), anteriormente a la notificación (404) del servidor óptimo a la LBPEF (2'). El estado proporciona a la LBPRF (1 1 ) información en tiempo real sobre la operabilidad de un servidor, para decidir si este servidor podría ser un candidato a la selección óptima. Por ejemplo, el estado de un servidor de una sede de la Red puede indicar si está en línea o fuera de línea, el estado de mantenimiento significa que un servidor está sometido a mantenimiento, el estado de alerta significa una notificación de una caída del servicio...  Figure 5 shows a flow chart of the protocol between the LBPRF (1 1) and any of the entities (5 ', 6', 7 ', 8', 9 ', 10') of the Balancer Server Booster Function Loads, only as an exemplary LBSEF (5 '), to obtain the status details of each associated server (5, 6, 7, 8, 9, 10), prior to notification (404) of the optimal server to the LBPEF (2'). The state provides the LBPRF (1 1) with real-time information about the operability of a server, to decide if this server could be a candidate for the optimal selection. For example, the status of a server at a Network headquarters can indicate whether it is online or offline, the maintenance status means that a server is undergoing maintenance, the alert status means a notification of a service outage ...
La Figura 5 muestra tres opciones principales distintas de implementación para que la LBPRF (1 1 ) obtenga la información acerca del estado de un servidor (5) mediante su LBSEF (5') asignada:  Figure 5 shows three different main implementation options for the LBPRF (1 1) to obtain information about the status of a server (5) through its assigned LBSEF (5 '):
a) La información es directamente solicitada por la LBPRF (1 1 )  a) The information is directly requested by the LBPRF (1 1)
1 . La LBPRF (1 1 ) solicita información (a1 ) de estado del servidor (5) a la LBSEF (5') asignada a dicho servidor (5) y define una periodicidad del envío de información de estado actualizada por parte de dicha LBSEF (5'). 2. La LBSEF (5') contesta con la respuesta (a2) de información que comprende al menos una indicación del estado del servidor (5); adicionalmente, otros parámetros disponibles acerca de los recursos del servidor (5) y de su servicio pueden ser incluidos en la respuesta, p. ej., las características de la CPU, la cantidad de memoria, el peso de cada CPU o recurso de memoria para el servicio que se ejecuta en el servidor (5), etc. one . The LBPRF (1 1) requests status information (a1) from the server (5) to the LBSEF (5 ') assigned to said server (5) and defines a periodicity of sending updated status information by said LBSEF (5) '). 2. The LBSEF (5 ') replies with the information response (a2) comprising at least one indication of the status of the server (5); additionally, other available parameters about server resources (5) and their service can be included in the response, e.g. eg, the characteristics of the CPU, the amount of memory, the weight of each CPU or memory resource for the service running on the server (5), etc.
3. La LBPRF (1 1 ) almacena (50) esta información en su propia base de datos para usarla en el futuro.  3. The LBPRF (1 1) stores (50) this information in its own database for future use.
la LBSEF inicia el envío periódico de información de estado de servidor LBSEF starts the periodic sending of server status information
1 . La LBSEF (5') inicia (b1 ) el envío de información de estado, y parámetros adicionales del servidor, según lo descrito anteriormente, a la LBPRF (1 1 ), cuando hay cambios significativos en los parámetros del servidor, o de manera periódica, usando una duración de periodo predefinida por el proveedor de servidores.  one . The LBSEF (5 ') initiates (b1) the sending of status information, and additional server parameters, as described above, to the LBPRF (1 1), when there are significant changes in the server parameters, or periodically , using a period of time predefined by the server provider.
2. La LBPRF (1 1 ) almacena (50) esta información en su propia base de datos, para usarla en el futuro.  2. The LBPRF (1 1) stores (50) this information in its own database, for future use.
la LBPRF determina si el estado de un servidor es o no "caído"the LBPRF determines whether the status of a server is "down" or not
1 . La LBPRF (1 1 ) puede decidir que un servidor (5) está caído, si después de varios intentos (c1 , c2, c3) no obtiene respuesta de la LBSEF (5') asignada al servidor (5), es decir, un fallo de la solicitud de información de estado es detectado por la LBPRF (1 1 ) al descubrir que la LBSEF (5') es incapaz de responder debidamente. one . The LBPRF (1 1) may decide that a server (5) is down, if after several attempts (c1, c2, c3) it does not obtain a response from the LBSEF (5 ') assigned to the server (5), that is, a Failure to request status information is detected by the LBPRF (1 1) upon discovering that the LBSEF (5 ') is unable to respond properly.
2. La LBPRF (1 1 ) almacena (50) esta información en su propia base de datos para usarla en el futuro. Habitualmente, la LBPRF (1 1 ) marca al servidor (5) asignado como "caído" en su base de datos y ya no envía solicitudes a ese servidor (5). Optativamente, pueden ser incluidos intentos adicionales dentro de un intervalo con más tiempo, para enviar nuevamente mensajes 'ping' a la LBSEF (5') del servidor (5) marcado, a fin de detectar si el servidor (5) está "activo". 2. The LBPRF (1 1) stores (50) this information in its own database for future use. Usually, the LBPRF (1 1) marks the server (5) assigned as "dropped" in its database and no longer sends requests to that server (5). Optionally, additional attempts may be included within an interval with more time, to send again 'ping' messages to the LBSEF (5 ') of the server (5) marked, in order to detect if the server (5) is "active".
La LBSEF (5') puede obtener la información de estado del servidor mediante múltiples procedimientos activos o pasivos (ejecutar las API del Sistema Operativo para obtener el estado del Hardware, monitorizar la interfaz de red, ejecutar programas de pruebas piloto de baja intrusión, etc.). A continuación se muestra esta información principal, pero puede añadirse cualquier otra información relevante. The LBSEF (5 ') can obtain the status information of the server through multiple active or passive procedures (execute the Operating System APIs to obtain the hardware status, monitor the network interface, run low intrusion pilot test programs, etc. .). This main information is shown below, but any other relevant information can be added.
• Información del servidor:  • Server information:
1 . Potencia de Cálculo (CPU): número total de núcleos, potencia de cada uno (operaciones por segundo), porcentaje de ociosidad (promedio desde el último estado).  one . Calculation Power (CPU): total number of cores, power of each (operations per second), percentage of idleness (average since the last state).
2. MEM: Cantidad total de memoria y cantidad de memoria libre.  2. MEM: Total amount of memory and amount of free memory.
3. BW: Ancho de Banda total y ancho de banda libre (promedio desde el último estado).  3. BW: Total Bandwidth and Free Bandwidth (average since the last state).
4. Retardo: Retardo mínimo, medio y máximo.  4. Delay: Minimum, medium and maximum delay.
• Información de servicio (para cada servicio):  • Service information (for each service):
1 . Identificación del Servicio  one . Service Identification
2. Peso de cada característica (CPU, MEM...) para cada servicio en ejecución.  2. Weight of each characteristic (CPU, MEM ...) for each running service.
3. Estado de cada Servicio: por ejemplo: activo o detenido, 3. Status of each Service: for example: active or stopped,
4. Parámetros de identificación en una solicitud, para asignar esa "solicitud" a ese "servicio". Por ejemplo, el URL del servicio, el puerto donde el servicio está a la escucha, el protocolo que está aceptando el servicio, etc. 4. Identification parameters in a request, to assign that "request" to that "service". For example, the service URL, the port where the service is listening, the protocol that is accepting the service, etc.
Aunque está fuera del alcance de esta patente, se recomiendo gestionar toda esta información como datos de XML.  Although it is beyond the scope of this patent, it is recommended to manage all this information as XML data.
El objetivo de la LBPRF (1 1 ) es asignar el servidor óptimo a cada solicitud de cliente en cualquier momento. Con este fin, la LBPRF (1 1 ) construye un mapa en tiempo real de la topología del plantel de servidores, y con el estado "listo y en acción" de cada servidor y servicio, en base a la información obtenida de las LBSEF (5', 6', 7', 8', 9', 10'). Así, las funciones principales realizadas por la entidad (1 1 ) de la LBPRF comprenden: The objective of the LBPRF (1 1) is to assign the optimal server to each client request at any time. To this end, the LBPRF (1 1) builds a real-time map of the server's topology, and with the "ready and in action" status of each server and service, based on the information obtained from the LBSEF ( 5 ', 6', 7 ', 8', 9 ', 10'). Thus, the main functions performed by the Entity (1 1) of the LBPRF comprises:
• Obtener la información de estado desde cada servidor distinto (5, 6, 7, 8, 9, 10) mediante las respectivas LBSEF (5', 6', 7', 8', 9', 10')  • Obtain status information from each different server (5, 6, 7, 8, 9, 10) through the respective LBSEF (5 ', 6', 7 ', 8', 9 ', 10')
• Almacenar esta información en una base de datos, la Base de Datos del Servidor de la LBPRF, con un sello temporal para determinar durante cuánto tiempo pueden ser usados los datos de estado de servidor almacenados en la Base de Datos del Servidor de la LBPRF como valores de referencia. • Store this information in a database, the LBPRF Server Database, with a temporary stamp to determine how long the server status data stored in the LBPRF Server Database can be used as reference values.
• Contestar solicitudes de la LBPEF (2', 3, 4') en tiempo real, respondiendo con una identificación del servidor óptimo asociado a la solicitud de cliente dada, recibida en la correspondiente LBPEF (2\ 3, 4'). • Answer LBPEF requests (2 ', 3, 4') in real time, responding with an optimal server identification associated with the given client request, received in the corresponding LBPEF (2 \ 3, 4 ').
En una posible realización, un algoritmo de alto nivel para implementar estas funciones principales de la entidad (1 1 ) de la LBPRF puede comprender las siguientes etapas:  In a possible embodiment, a high-level algorithm for implementing these main functions of the entity (1 1) of the LBPRF may comprise the following steps:
1 . La LBPRF (1 1 ) recibe una nueva solicitud desde una LBPEF (2', 3, 4'), activada por una solicitud de contenido emitida por un cliente (1 )  one . The LBPRF (1 1) receives a new request from an LBPEF (2 ', 3, 4'), activated by a content request issued by a customer (1)
2. Analiza los datos más relevantes de esta solicitud, por cualquier mecanismo de clasificación de tráfico, p. ej., en base a la carga útil (inspección de bolsillos profundos, o uso del acceso a L3 / L4), por un análisis avanzado si la solicitud del cliente es más compleja - debido a la priorización, por ejemplo - o simplemente mediante un análisis básico de la solicitud del paquete de cabecera, para obtener:  2. Analyze the most relevant data of this application, by any traffic classification mechanism, p. For example, based on the payload (inspection of deep pockets, or use of access to L3 / L4), by an advanced analysis if the client's request is more complex - due to prioritization, for example - or simply by means of a Basic analysis of the header package request, to obtain:
el Tipo de Protocolo (HTTP, FTP, TCP, SIP, SMTP, VolP, LDAP...)  The Type of Protocol (HTTP, FTP, TCP, SIP, SMTP, VolP, LDAP ...)
• Puertos de Origen y Destino  • Ports of Origin and Destination
• Direcciones de IP de Origen y Destino  • Source and Destination IP Addresses
•  •
3. En base a los datos analizados, la LBPRF (1 1 ) determina la clase de servicio que se solicita, p. ej., un cálculo matemático. 4. La LBPRF (1 1 ) extrae de la Base de Datos del Servidor de la LBPRF cuál es el servidor más adecuado para esta solicitud en este momento, en base a los siguientes factores, por ejemplo: a. Cantidad de recursos libres de cada servidor necesarios para la solicitud de contenido. En una realización preferida, cada recurso individual de un servidor (5, 6, 7, 8, 9, 10) es ponderado según su importancia para cada tipo de solicitud, p. ej., la CPU libre podría ser el recurso más ponderado. b. Constantes predefinidas de la solicitud de contenido, p. ej.: solamente es posible asignar una cantidad reducida de servidores, o solamente es posible asignar servidores con un recurso libre disponible en una magnitud que supere un umbral predefinido. 3. Based on the analyzed data, the LBPRF (1 1) determines the kind of service requested, p. eg, a mathematical calculation. 4. The LBPRF (1 1) extracts from the LBPRF Server Database which is the most suitable server for this request at this time, based on the following factors, for example: a. Amount of free resources from each server required for the content request. In a preferred embodiment, each individual resource of a server (5, 6, 7, 8, 9, 10) is weighted according to its importance for each type of request, e.g. For example, the free CPU could be the most weighted resource. b. Predefined constants of the content request, p. Eg: it is only possible to assign a reduced number of servers, or it is only possible to assign servers with a free resource available in a magnitude that exceeds a predefined threshold.
c. Formulación heurística de cuál es el servidor óptimo para estos tipos de solicitudes, como una función de la carga, la hora del día, etc., usando la base de datos históricos.  C. Heuristic formulation of what is the optimal server for these types of requests, as a function of load, time of day, etc., using the historical database.
d. Cualquier otra información relevante: por ejemplo, el servicio requiere procesamiento de mono-hebra y, por lo tanto, solamente es relevante una CPU central en este contexto.  d. Any other relevant information: for example, the service requires single-strand processing and, therefore, only one central CPU is relevant in this context.
Además, una posible opción de implementación comprende configurar manualmente un servidor único por omisión, o una colección de ellos, en la entidad (1 1 ) de la LBPRF, de modo que, en caso de que la LBPRF (1 1 ) no pueda conectarse con su Base de Datos del Servidor de la LBPRF, o si no se devuelve ningún dato para la consulta en esta Base de Datos, pueda(n) ser usado(s) el servidor, o los servidores, por omisión, para tratar la solicitud.  In addition, a possible implementation option comprises manually configuring a single default server, or a collection of them, in the entity (1 1) of the LBPRF, so that, in case the LBPRF (1 1) cannot connect with your LBPRF Server Database, or if no data is returned for the query in this Database, the server, or servers, can be used by default to process the request .
5. La LBPRF (1 1 ) contesta a la LBPEF (2\ 3, 4') interrogante con el servidor más adecuado. En una realización de la invención, la respuesta desde la LBPRF (1 1 ) a la LBPEF (2\ 3, 4') puede contener un periodo de tiempo agotado de validez, también llamado Tiempo de Vida o TTL, que indica que esta respuesta con la identificación del servidor óptimo puede ser almacenada y usada por la LBPEF (2', 3, 4') en similares solicitudes posteriores. De esta manera, se logra un aumento de las prestaciones del sistema si ese periodo de validez está bien afinado. En general, cuanto más pequeño es el TTL, menos recursos disponibles hay, y al contrario, cuanto más grande sea. 5. The LBPRF (1 1) answers the LBPEF (2 \ 3, 4 ') question with the most appropriate server. In one embodiment of the invention, the response from the LBPRF (1 1) to the LBPEF (2 \ 3, 4 ') may contain a period of validity, also called Life Time or TTL, which indicates that this response with the optimal server identification can be stored and used by the LBPEF (2 ', 3, 4') in similar subsequent requests. In this way, an increase in system performance is achieved if that period of validity is well tuned. In general, the smaller the TTL, the less resources available, and on the contrary, the larger.
La invención puede ser aplicada en centros de datos tradicionales o centros de datos en nube, dado que la gestión de cada solicitud para el servidor más adecuado es automática y transparente para la solicitud del cliente o para el servidor, y por tanto es posible usar cualquier tipo de máquina de hardware para que funcionen como servidores. Incluso cuando un "servidor virtual" es implementado dentro de una mezcla de "servidores de hardware - virtuales", la invención puede aplicar este concepto en lugar del concepto del "servidor de hardware". The invention can be applied in traditional data centers or cloud data centers, since the management of each request for the most suitable server is automatic and transparent for the client's request or for the server, and therefore it is possible to use any type of hardware machine to function as servers. Even when a "virtual server" is implemented within a mixture of "virtual hardware servers," the invention can apply this concept instead of the "hardware server" concept.
Esta invención es capaz de asignar el servidor más adecuado a cada solicitud en cada momento, incluso si cualquier servicio puede arrancar / detenerse en cualquier máquina, o en el caso de que una nueva máquina sea introducida en el sistema sin detener ningún elemento de la arquitectura.  This invention is capable of assigning the most appropriate server to each request at any time, even if any service can start / stop on any machine, or in the event that a new machine is introduced into the system without stopping any architecture element .
Como un ejemplo práctico de aplicación, imagínese una agrupación de servidores con los siguientes elementos:  As a practical application example, imagine a cluster of servers with the following elements:
• Dos máquinas con 1 CPU y 4 Gigaoctetos de memoria. • Two machines with 1 CPU and 4 Gigabytes of memory.
• Dos máquinas con 4 CPU y 1 Gigaocteto de memoria.• Two machines with 4 CPUs and 1 Gigabyte of memory.
• Un servicio de cálculos matemáticos: con altos requisitos de CPU. • A mathematical calculation service: with high CPU requirements.
• Un servicio de Base de Datos: con altos requisitos de Memoria. Entonces, una solicitud para esta agrupación de servidores con Equilibradores de Cargas seguirá estas etapas:  • A Database service: with high Memory requirements. Then, a request for this server pool with Load Balancing will follow these stages:
1 . Una solicitud para el servidor Matemático llega al Equilibrador de Cargas.  one . A request for the Mathematical server reaches the Load Balancer.
2. El elemento de LPBEF pide información a la LPBRF. 2. The LPBEF element requests information from the LPBRF.
3. El módulo de LPBRF selecciona el servidor óptimo usando el algoritmo de alto nivel descrito anteriormente, teniendo en cuenta que una solicitud matemática necesita más recursos de CPU que de memoria. Este factor es ponderado en el algoritmo. 3. The LPBRF module selects the optimal server using the high level algorithm described above, taking into account that a mathematical request needs more CPU resources than memory. This factor is weighted in the algorithm.
4. Es asignado el servidor menos cargado, con 4 CPU. 4. The least loaded server is assigned, with 4 CPUs.
5. Luego, se recibe una solicitud posterior para la Base de Datos. 5. Then, a subsequent request for the Database is received.
Entonces, la LPBRF considera que esta solicitud necesita más recursos de Memoria que de CPU.  Then, the LPBRF considers that this request needs more resources of Memory than of CPU.
6. La LPBRF responde con el servidor más ocioso, teniendo en cuenta que el uso de Memoria es la característica principal de esta solicitud.  6. The LPBRF responds with the most idle server, taking into account that the use of Memory is the main feature of this request.
Obsérvese que, en este texto, el término "comprende" y sus derivaciones (tales como "comprendiendo", etc.) no debería ser entendido en un sentido excluyente, es decir, estos términos no deberían ser interpretados como excluyentes de la posibilidad de que lo que se describe y define pueda incluir elementos, etapas, etc., adicionales.  Note that, in this text, the term "understand" and its derivations (such as "understanding", etc.) should not be understood in an exclusive sense, that is, these terms should not be construed as excluding the possibility that what is described and defined may include additional elements, stages, etc.

Claims

REIVINDICACIONES
1 . Un procedimiento para equilibrar solicitudes de contenido en una red (100) proveedora de servidores, caracterizado por comprender: one . A procedure for balancing content requests on a server provider network (100), characterized by comprising:
- recibir un resumen de información contenida en una solicitud de contenido desde un cliente (1 ) de la red (100) proveedora de servidores,  - receive a summary of information contained in a content request from a client (1) of the network (100) provider of servers,
- recibir información en tiempo real referida a cada servidor (5, 6, 7, 8, 9, 10) de la red (100) proveedora de servidores, que comprende información de estado de cada servidor (5, 6, 7, 8, 9, 10), información de servicio de cada servicio ejecutándose en cada servidor (5, 6, 7, 8, 9, 10) y la topología actual de la red (100) proveedora de servidores; - receive real-time information regarding each server (5, 6, 7, 8, 9, 10) of the server provider network (100), which includes status information for each server (5, 6, 7, 8, 9, 10), service information of each service running on each server (5, 6, 7, 8, 9, 10) and the current topology of the network (100) server provider;
- para la solicitud de contenido recibida, escoger un servidor (5, 6, 7, 8, 9, 10) de la red (100) proveedora de servidores, en base a un algoritmo de equilibrio de cargas que tiene en cuenta toda la información recibida. - for the request for content received, choose a server (5, 6, 7, 8, 9, 10) from the network (100) server provider, based on a load balancing algorithm that takes into account all the information received
2. El procedimiento según la reivindicación 1 , en el cual toda la información es recibida en una entidad (1 1 ) de Función de Reglas de la Política del Equilibrador de Cargas, que escoge el servidor (5, 6, 7, 8, 9, 10) para la solicitud de contenido recibida, en base al algoritmo de equilibrio de cargas, y en el cual:  2. The method according to claim 1, wherein all the information is received in a Load Function Balancer Policy Rule (1 1) entity, which chooses the server (5, 6, 7, 8, 9 , 10) for the request for content received, based on the load balancing algorithm, and in which:
- el resumen de información contenida en la solicitud de contenido es recibido desde una entidad (2', 3, 4') de la Función de Refuerzo de la Política del Equilibrador de Cargas, asociada a un equilibrador (2, 3, 4) de cargas que recibe la solicitud de contenido desde el cliente (1 ); - the summary of information contained in the content request is received from an entity (2 ', 3, 4') of the Load Balancing Policy Reinforcement Function, associated with a balancer (2, 3, 4) of loads that the content request receives from the client (1);
- la información referida a cada servidor (5, 6, 7, 8, 9, 10) es recibida desde una entidad (5', 6', 7', 8', 9', 10') de la Función de Refuerzo del Servidor del Equilibrador de Cargas, asociada respectivamente con cada servidor (5, 6, 7, 8, 9, 10). - the information referred to each server (5, 6, 7, 8, 9, 10) is received from an entity (5 ', 6', 7 ', 8', 9 ', 10') of the Booster Function of the Load Balancer Server, associated respectively with each server (5, 6, 7, 8, 9, 10).
3. El procedimiento según la reivindicación 2, que comprende adicionalmente enviar una identidad del servidor escogido (5, 6, 7, 8, 9, 10) desde la entidad (1 1 ) de la Función de Reglas de la Política del Equilibrador de Cargas a la entidad (2', 3, 4') de la Función de Refuerzo de la Política del Equilibrador de Cargas, asociada al equilibrador (2, 3, 4) de cargas que recibe la solicitud de contenido desde el cliente (1 ). 3. The method according to claim 2, further comprising sending an identity of the chosen server (5, 6, 7, 8, 9, 10) from the entity (1 1) of the Load Balancer Policy Rules Function to the entity (2 ', 3, 4') of the Load Balancing Policy Reinforcement Function, associated with the load balancer (2, 3, 4) that Receive the content request from the client (1).
4. El procedimiento según cualquiera de las reivindicaciones 2 a 3, que comprende adicionalmente enviar un periodo de tiempo agotado de validez desde la entidad (1 1 ) de la Función de Reglas de la Política del Equilibrador de Cargas a la entidad (2', 3, 4') de la Función de Refuerzo de la Política del Equilibrador de Cargas, que indica que, para las posteriores solicitudes de contenido desde el cliente (1 ), el servidor escogido (5, 6, 7, 8, 9, 10) es válido durante el periodo de tiempo agotado de validez.  4. The method according to any one of claims 2 to 3, further comprising sending a period of time of validity from the entity (1 1) of the Rules Function of the Load Balancer Policy to the entity (2 ', 3, 4 ') of the Load Balancing Policy Reinforcement Function, which indicates that, for subsequent content requests from the client (1), the chosen server (5, 6, 7, 8, 9, 10 ) is valid during the validity period of time.
5. El procedimiento según cualquiera de las reivindicaciones 2 a 4, en el cual la recepción de un resumen de información contenida en la solicitud del cliente comprende un análisis del tráfico de la solicitud de contenido, para determinar qué servicio es solicitado por el cliente (1 ).  5. The method according to any of claims 2 to 4, wherein the reception of a summary of information contained in the client's request comprises an analysis of the traffic of the content request, to determine which service is requested by the client ( one ).
6. El procedimiento según cualquiera de las reivindicaciones 2 a 5, en el cual la recepción de información en tiempo real referida a cada servidor (5, 6, 7, 8, 9, 10) comprende ponderar la información referida a cada servidor (5, 6, 7, 8, 9, 10), de acuerdo a la información resumida recibida desde la solicitud de contenido.  6. The method according to any of claims 2 to 5, wherein the reception of real-time information referred to each server (5, 6, 7, 8, 9, 10) comprises weighing the information referred to each server (5 , 6, 7, 8, 9, 10), according to the summary information received from the content request.
7. El procedimiento según cualquiera de las reivindicaciones 2 a 6, en el cual la recepción de información de estado de cada servidor (5, 6, 7, 8, 9, 10) se inicia en respuesta a una solicitud desde la entidad (1 1 ) de la Función de Reglas de la Política del Equilibrador de Cargas.  7. The method according to any of claims 2 to 6, wherein the reception of status information from each server (5, 6, 7, 8, 9, 10) is initiated in response to a request from the entity (1 1) of the Rules Function of the Load Balancer Policy.
8. El procedimiento según cualquiera de las reivindicaciones 2 a 6, en el cual la recepción de información de estado de cada servidor (5, 6, 7, 8, 9, 10) se inicia cuando una entidad (5', 6', 7', 8', 9', 10') de la Función de Refuerzo del Servidor del Equilibrador de Cargas detecta un cambio en su servidor asociado (5, 6, 7, 8, 9, 10).  8. The method according to any of claims 2 to 6, wherein the reception of status information from each server (5, 6, 7, 8, 9, 10) is initiated when an entity (5 ', 6', 7 ', 8', 9 ', 10') of the Load Balancer Server Reinforcement Function detects a change in its associated server (5, 6, 7, 8, 9, 10).
9. El procedimiento según cualquier reivindicación precedente, que comprende adicionalmente almacenar toda la información recibida en una base de datos con un sello temporal que determina un periodo temporal para el cual es válida la información almacenada, para su uso por el algoritmo de equilibrio de cargas.  9. The method according to any preceding claim, further comprising storing all the information received in a database with a time stamp that determines a time period for which the stored information is valid, for use by the load balancing algorithm .
10. Un sistema para equilibrar solicitudes de contenido en una red (100) proveedora de servidores, asociada a al menos un Equilibrador de Cargas (2, 3, 4), y comprendiendo la red (100) proveedora de servidores una pluralidad de servidores (5, 6, 7, 8, 9, 10), caracterizado porque el sistema comprende adicionalmente: 10. A system for balancing content requests on a server provider network (100), associated with at least one Balancer of Loads (2, 3, 4), and the server provider network (100) comprising a plurality of servers (5, 6, 7, 8, 9, 10), characterized in that the system additionally comprises:
- al menos una entidad (1 1 ) de la Función de Reglas de la Política del Equilibrador de Cargas, que comprende medios para implementar el procedimiento definido según la reivindicación 1 ;  - at least one entity (1 1) of the Load Balancer Policy Rules Function, which comprises means for implementing the procedure defined according to claim 1;
- una pluralidad de entidades (5', 6', 7', 8', 9', 10') de la Función de Refuerzo del Servidor del Equilibrador de Cargas, estando cada entidad (5', 6', 7', 8', 9', 10') de la Función de Refuerzo del Servidor del Equilibrador de Cargas asociada a uno de los servidores (5, 6, 7, 8, 9, 10), y comprendiendo medios de envío para enviar información en tiempo real referida a cada servidor (5, 6, 7, 8, 9, 10) a la entidad (1 1 ) de la Función de Reglas de la Política del Equilibrador de Cargas; y - a plurality of entities (5 ', 6', 7 ', 8', 9 ', 10') of the Load Balancing Server Reinforcement Function, each entity being (5 ', 6', 7 ', 8 ', 9', 10 ') of the Load Balancing Server Reinforcement Function associated with one of the servers (5, 6, 7, 8, 9, 10), and comprising sending means to send information in real time referred to each server (5, 6, 7, 8, 9, 10) to the entity (1 1) of the Load Balancer Policy Rules Function; Y
- al menos una entidad (2', 3, 4') de la Función de Refuerzo de la Política del Equilibrador de Cargas, asociada a al menos un Equilibrador de Cargas (2, 3, 4) que comprende medios de envío para enviar a la entidad (1 1 ) de la Función de Reglas de la Política del Equilibrador de Cargas un resumen de la información contenida en una solicitud de contenido proveniente de un cliente (1 ) de la red (100) proveedora de servidores. - at least one entity (2 ', 3, 4') of the Load Balancing Policy Reinforcement Function, associated with at least one Load Balancer (2, 3, 4) comprising shipping means to be sent to the entity (1 1) of the Load Balancing Policy Rules Function a summary of the information contained in a content request from a client (1) of the server provider network (100).
1 1 . El sistema según la reivindicación 10, en el cual la entidad (2', 3, 4') de la eleven . The system according to claim 10, wherein the entity (2 ', 3, 4') of the
Función de Refuerzo de la Política del Equilibrador de Cargas está integrada en un Equilibrador de Cargas (2, 3, 4). Function of Reinforcement of the Load Balancer Policy is integrated into a Load Balancer (2, 3, 4).
12. El sistema según cualquiera de las reivindicaciones 10 a 1 1 , en el cual la entidad (5', 6', 7', 8', 9', 10') de la Función de Refuerzo del Servidor del Equilibrador de Cargas está integrada en un servidor (5, 6, 7, 8, 9, 10). 12. The system according to any of claims 10 to 1 1, wherein the entity (5 ', 6', 7 ', 8', 9 ', 10') of the Load Balancer Server Reinforcement Function is integrated into a server (5, 6, 7, 8, 9, 10).
13. El sistema según cualquiera de las reivindicaciones 10 a 12, en el cual la entidad (1 1 ) de la Función de Reglas de la Política del Equilibrador de Cargas comprende una base de datos para almacenar toda la información recibida desde cada entidad (2', 3, 4') de la Función de Refuerzo de la Política del Equilibrador de Cargas, y cada entidad (5', 6', 7', 8', 9', 10') de la Función de Refuerzo del Servidor del Equilibrador de Cargas, con un sello temporal que determina un periodo temporal para el cual la información almacenada es válida para su uso por la entidad (1 1 ) de la Función de Reglas de la Política del Equilibrador de Cargas. 13. The system according to any of claims 10 to 12, wherein the entity (1 1) of the Load Balancer Policy Rules Function comprises a database for storing all information received from each entity (2 ', 3, 4') of the Load Balancer Policy Reinforcement Function, and each entity (5 ', 6', 7 ', 8', 9 ', 10') of the Server Reinforcement Function of the Load balancer, with a temporary stamp that determines a temporary period for which the information stored is valid for use by the entity (1 1) of the Rules Function of the Load Balancer Policy.
14. El sistema según cualquiera de las reivindicaciones 10 a 13, en el cual la entidad (1 1 ) de la Función de Reglas de la Política del Equilibrador de Cargas comprende medios analizadores de tráfico para analizar la solicitud de contenido, a fin de determinar cuál servicio es solicitado por el cliente (1 ) en la solicitud de contenido.  14. The system according to any of claims 10 to 13, wherein the entity (1 1) of the Load Balancer Policy Rules Function comprises traffic analyzer means for analyzing the content request, in order to determine which service is requested by the client (1) in the content request.
15. El sistema según cualquiera de las reivindicaciones 10 a 13, en el cual la entidad (2', 3, 4') de la Función de Refuerzo de la Política del Equilibrador de Cargas comprende medios analizadores de tráfico para analizar la solicitud de contenido, a fin de determinar cuál servicio es solicitado por el cliente (1 ) en la solicitud de contenido.  15. The system according to any of claims 10 to 13, wherein the entity (2 ', 3, 4') of the Load Balancing Policy Reinforcement Function comprises traffic analyzer means for analyzing the content request , in order to determine which service is requested by the customer (1) in the content request.
PCT/ES2013/070605 2013-08-21 2013-08-21 Method and system for balancing content requests in a server provider network WO2015025066A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/ES2013/070605 WO2015025066A1 (en) 2013-08-21 2013-08-21 Method and system for balancing content requests in a server provider network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/ES2013/070605 WO2015025066A1 (en) 2013-08-21 2013-08-21 Method and system for balancing content requests in a server provider network

Publications (1)

Publication Number Publication Date
WO2015025066A1 true WO2015025066A1 (en) 2015-02-26

Family

ID=52483106

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/ES2013/070605 WO2015025066A1 (en) 2013-08-21 2013-08-21 Method and system for balancing content requests in a server provider network

Country Status (1)

Country Link
WO (1) WO2015025066A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3437273A4 (en) * 2016-03-29 2019-12-04 Alibaba Group Holding Limited Time-based adjustable load balancing

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030172163A1 (en) * 2002-03-05 2003-09-11 Nec Corporation Server load balancing system, server load balancing device, and content management device
US20060106938A1 (en) * 2003-11-14 2006-05-18 Cisco Systems, Inc. Load balancing mechanism using resource availability profiles

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030172163A1 (en) * 2002-03-05 2003-09-11 Nec Corporation Server load balancing system, server load balancing device, and content management device
US20060106938A1 (en) * 2003-11-14 2006-05-18 Cisco Systems, Inc. Load balancing mechanism using resource availability profiles

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3437273A4 (en) * 2016-03-29 2019-12-04 Alibaba Group Holding Limited Time-based adjustable load balancing

Similar Documents

Publication Publication Date Title
Son et al. Priority-aware VM allocation and network bandwidth provisioning in software-defined networking (SDN)-enabled clouds
US9444763B1 (en) Optimizing communication among collections of computing resources
US10715479B2 (en) Connection redistribution in load-balanced systems
US9948600B2 (en) Client-driven load balancing of dynamic IP address allocation
US9628556B2 (en) Decentralized request routing
US20180121221A1 (en) Systems and methods for deploying microservices in a networked microservices system
EP2996310A1 (en) Systems and methods for directly responding to distributed network traffic
US10439901B2 (en) Messaging queue spinning engine
US9819626B1 (en) Placement-dependent communication channels in distributed systems
US10320680B1 (en) Load balancer that avoids short circuits
US11032358B2 (en) Monitoring web applications including microservices
US11888745B2 (en) Load balancer metadata forwarding on secure connections
US11178217B2 (en) DNS-based in-packet service version tagging
Nakai et al. On the use of resource reservation for web services load balancing
US10305789B2 (en) Packet forwarding for quality of service delivery
US11822946B2 (en) Systems and methods for secure network management of virtual network functions
WO2015025066A1 (en) Method and system for balancing content requests in a server provider network
Kontogiannis et al. ALBL: an adaptive load balancing algorithm for distributed web systems
US20200106681A1 (en) Connection management based on server feedback using recent connection request service times
US10860347B1 (en) Virtual machine with multiple content processes
US9537748B1 (en) Finding shortest path in multi-access nodes in cloud service
US11533362B1 (en) Network interface controller aware placement of virtualized workloads
US11579915B2 (en) Computing node identifier-based request allocation
US20230031963A1 (en) System and method for estimation of performance impact upon a hypervisor in a cloud environment
Romanov et al. Enhancing Resource Availability: Indicators and Strategies for Optimizing the Kubernetes Network

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: 13891857

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: 13891857

Country of ref document: EP

Kind code of ref document: A1