WO2017028930A1 - Procédés et appareil pour exécuter une fonction d'analyse - Google Patents

Procédés et appareil pour exécuter une fonction d'analyse Download PDF

Info

Publication number
WO2017028930A1
WO2017028930A1 PCT/EP2015/069173 EP2015069173W WO2017028930A1 WO 2017028930 A1 WO2017028930 A1 WO 2017028930A1 EP 2015069173 W EP2015069173 W EP 2015069173W WO 2017028930 A1 WO2017028930 A1 WO 2017028930A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
analytics function
network
nodes
cost
Prior art date
Application number
PCT/EP2015/069173
Other languages
English (en)
Inventor
Tony Larsson
Nicolas Seyvet
Ignacio MULAS VIELA
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
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 Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to PCT/EP2015/069173 priority Critical patent/WO2017028930A1/fr
Publication of WO2017028930A1 publication Critical patent/WO2017028930A1/fr

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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/502—Proximity

Definitions

  • This disclosure relates to a method and apparatus for running an analytics function.
  • it relates to determining an optimal node in a distributed network on which to run an analytics function.
  • frameworks such as HadoopTM and SparkTM. Alternatively they may be statistically provisioned/deployed in specific nodes.
  • frameworks can increase network overheads as data has to be copied from one or more storage nodes and moved through the network to a central node for processing.
  • a method in a distributed network for determining an optimal node on which to run an analytics function.
  • the method comprises determining a candidate list of potential nodes on which to run the analytics function.
  • the method further comprises, for each node in the candidate list, calculating at least one parameter for the node relating to the cost of running the analytics function, and determining the optimal node based on the at least one calculated parameter.
  • the step of determining a candidate list of potential nodes comprises determining a preliminary list of potential nodes based on the location of one or more data sources used in the analytics function.
  • the candidate list is determined from the preliminary list using graph analysis methods.
  • the graph analysis method may comprise, for example, shortest path calculations.
  • the analytics function requires data stored on at least a first node and a second node, and wherein the shortest path calculations determine the shortest path between the first node and the second node.
  • the candidate list of potential nodes contains nodes along the shortest path between the first node and the second node.
  • the analytics function further requires data stored on a third node, and wherein the shortest path calculations further determine the shortest path between the first node and the third node and the shortest path between the second node and the third node.
  • the candidate list of potential nodes also contains nodes along the shortest path between the third node and the first node and/or the third node and the second node.
  • the shortest path calculations are weighted according to one or more negotiated link costs between nodes in the network.
  • the method further comprises calculating a total cost of computing the analytics function on each of the nodes in the candidate list, wherein the total cost is a combination of the values of one or more
  • the total cost is a weighted combination of the values of the one or more parameters, and the step of determining the optimal node is based on the weighted combination.
  • the weighting may reflect the frequency that data will need to be accessed on the one or more neighbouring nodes in order to compute the analytics function.
  • the total cost is an average combination of the values of the one or more parameters calculated for the node and/or one or more neighbouring nodes, and the step of determining the optimal node is based on the average combination.
  • the step of determining an optimal node comprises determining a prioritized list of nodes by ranking each candidate node according to its total cost and selecting an optimal node from the prioritized list.
  • the at least one parameter can relate to at least one of:
  • the network node comprises an analytics function location module for determining an optimal node in the distributed network on which to run an analytics function.
  • the analytics function location module is configured to determine a candidate list of potential nodes on which to run the analytics function.
  • the analytics function location module is further configured, for each node in the candidate list, to obtain at least one parameter relating to the cost of running the analytics function and to determine the optimal node based on the at least one parameter.
  • the analytics function location module is configured to store and maintain a list of the locations of data sources in the network.
  • the analytics function location module may be configured to receive one or more updates on the location of data sources in the network and update the list of locations of data sources accordingly.
  • the analytics function location module is further configured to receive one or more parameters relating to the cost of running the analytics function. In some embodiments, the analytics function location module is configured to receive the one or more parameters through gossip communication.
  • a network node in a distributed network comprising a processor and a memory, said memory containing instructions executable by said processor.
  • the network node is operative to determine a candidate list of potential nodes on which to run the analytics function.
  • the network node is further operative to calculate, for each node in the candidate list, at least one parameter for the node relating to the cost of running the analytics function and determine the optimal node based on the at least one calculated parameter.
  • a network node in a distributed network comprising a first module for determining a candidate list of potential nodes on which to run the analytics function; a second module for calculating, for each node in the candidate list, at least one parameter for the node relating to the cost of running the analytics function; and a third module for determining the optimal node based on the at least one calculated parameter.
  • a computer program which, when run on a computer, causes the computer to carry out a method according to any of the embodiments listed above.
  • a computer program product comprising computer readable storage medium and a computer program according to the fifth aspect, stored on the computer readable storage medium.
  • Figure 1 illustrates an example of a method of determining an optimal node on which to run an analytics function, according to an embodiment
  • Figure 2 shows an example distributed network
  • Figure 3 shows an example network node according to an embodiment
  • Figure 4 shows an example network node according to another embodiment.
  • Figure 5 shows an example network node according to a further embodiment. Detailed Description
  • FIG. 1 shows a method according to an embodiment, for determining an optimal node on which to run an analytics function. The method comprises determining a candidate list of potential nodes on which to run the analytics function, step 102.
  • the method further comprises, for each node in the candidate list, calculating at least one parameter for the node relating to the cost of running the analytics function, step 104.
  • an optimal node is determined based on the at least one calculated parameter. In this way, instead of running an analytics function on a centrally located node, the method provides a mechanism for dynamically choosing which node to run the analytics function on. Executing an analytics function at the
  • a distributed network consists of a number of nodes connected in various ways with a number of links.
  • Such a distributed network can be illustrated as a graph, as shown in Figure 2.
  • the circle labelled AC in Figure 2 represents an analytics client (AC).
  • the other circles in Figure 2 represent nodes (or computational resources) that can potentially also run analytics clients or analytics functions.
  • Each straight line represents a network link (or connection) between two nodes.
  • Each node is labelled with a letter (a-y), according to the data stored on it, or streamed though it (e.g. the node labelled a, has data source 'a' on it, or streamed through it).
  • Each node and each link is also labelled with a number representing the cost of using the respective nodes and links when running the analytics function.
  • an Internet of Things (loT) type scenario such as the one in Figure 2, resources can be limited in some parts of the distributed network and this is reflected in the costs.
  • the costs of each node and link are dynamically allocated and can be calculated based on utilization of bandwidth, cpu, ram etc.
  • the costs are dynamically updated to reflect the current status of the nodes and the network.
  • the 'cost' in this sense can be a dimensionless number based on a scale agreed between the nodes in the network.
  • the cost can be the actual monetary cost (e.g. in euros or dollars) of using the node, or another dimensional number, such as the CPU utilisation.
  • Nodes All nodes run an internal process that, based on resource utilization (cpu, ram, i/o), calculates a cost for the node. This cost indicates how utilized the node is at the moment. A low cost means low utilization and a high cost means high utilization. The cost can be a relative, for example, the utilization can be ranked according to an agreed scale such as e.g. 1 to 10. The node and link costs are dynamically updated at each node. This can be done periodically, or based on threshold values for certain metrics (for example cpu, io, ram, nw etc).
  • gossip communication protocols are used in the point-to-point (P2P) networks, which makes them a perfect fit for distributed scenarios.
  • Gossip communication protocols are a way that computers share information across a network using a form of random "peer selection". At specified time intervals, each node in the network picks another node at random and shares any new data or updates e.g. in this case, any updates on calculated node costs. The fact that the chosen nodes are random means that some nodes will receive the data more than once from two or more different nodes.
  • gossip communication protocols are an efficient way of sharing data quickly and efficiently around a distributed network.
  • Link costs Nodes that are directly connected and share a link continuously calculate and agree on a cost for that particular link.
  • the link cost is directional such that there are separate link costs for the uplink and downlink. This is done based on the network metrics available such as bandwidth or latency. If the nodes are the vertices of the graph shown in Figure 2, then the link is the value attached to the edge formed between these two vertices.
  • Link costs can be calculated using a Gather Apply Scatter model: o Gather: Receive information about adjacent vertexes. o Apply: Take computation from gather phase, o Scatter: Update data on adjacent edges.
  • the method 100 as illustrated in Figure 1 can run in the network as follows.
  • the method 100 may run on a node in the network that is configured to run an Analytics Function Location Service (AFLS).
  • AFLS Analytics Function Location Service
  • the AFLS has access to one or more data sources, for example, the AFLS may have access to one or more of (i) a list of nodes in the network (ii) the costs of running the analytics function on each node (ii) a list of link costs for transferring data between each pair of nodes (iii) a list of databases and/or the data sources on each node.
  • the AFLS may keep track of the data sources listed above and may update the data sources (for example, what data is stored on each node) based on updates from the network received, for example, through the gossip
  • the step of determining a candidate list of potential nodes on which to run the analytics function 102 comprises determining a preliminary list of potential nodes based on the location of one or more data sources used in the analytics function. For example, for the analytics function f(a,b,c) the AFLS may generate a preliminary list of nodes based on the location of the data sources a, b and c.
  • the preliminary list of nodes may contain nodes that have a, b or c stored on them, or the candidate list may contain nodes that can accommodate the function "f and have access to a, b and/or c.
  • data source 'a' can be obtained from node a
  • data source 'b' can be obtained from node b
  • data source 'c' can be obtained from node c.
  • the data can be obtained from the respective nodes because, for example, the data is stored on the node, or because the data is being generated and streamed from the node. Therefore, in this example, the preliminary list contains nodes a, b and c.
  • the AFLS will then determine a candidate list from the preliminary list using graph analysis methods.
  • the graph analysis method may comprise shortest path (SP) calculations for all combinations of dependent sources, e.g. calculating all of the shortest paths between the different locations of the data sources a, b and c (a-b, a-c, b-c).
  • SP shortest path
  • the analytics function requires data stored on a first node, a second node and a third node
  • the shortest path calculations determine the shortest path between the first node and the second node, the shortest path between the first node and the third node and the shortest path between the second node and the third node.
  • this may also involve calculating the shortest paths for each repeated data source, for example if there were a second source of data a, a' then the shortest path calculations may determine the shortest paths between (a-b, a-c, b-c, a'-b, a'-c').
  • the shortest path calculations are calculated by the nodes of the network. For example, shortest path calculations can be initiated by the AFLS by sending ComputeSP multicast messages to the first nodes in each unique combination: i. message to a: get shortest path between a-b and a-c
  • a node Once a node receives a ComputeSP message, it will return an OK message and store the AFLS return address, and start a shortest path calculation.
  • the AFLS may calculate the shortest paths itself, based on information available to it about the network and network costs.
  • all information is sent to one node that collects a global view of the network. The information might be received at the node through a dedicated protocol that sends all updates to the central node, or alternatively, through the gossip protocol described above.
  • Shortest path computations can be performed using any already existing algorithm, for example such as Dijkstra's algorithm or the A * (A-star) search algorithm.
  • the shortest path calculations calculate the shortest physical network path between the two nodes, for example, the path(s) that contains the fewest intermediary nodes.
  • the basic shortest path calculations can be modified such that the algorithm is effectively weighted according to the negotiated link costs between the nodes. For example, whilst the path (x->d- >e) in Figure 2, may physically be the same length as the path (x->y->e), the link cost between nodes d and e is higher than the link cost between nodes y and e.
  • link costs may be used as weightings in the shortest path calculations, such that the shortest path calculation would consider (x->y->e) to be 'shorter' than, or preferential to, the path (x->d->e).
  • the results of the shortest path calculation are collected in a format that shows the entire path, including node and link costs. Referring again to Figure 2, the shortest paths for the combinations (a-b, a-c, b-c) are:
  • the results of the shortest path calculations are then sent to the AFLS using a message such as a ResultSP message.
  • the ResultSP message contains a list of all of the nodes along the shortest path between the two nodes (including the end nodes themselves).
  • the AFLS collects all of the nodes along all of the shortest paths and this forms the candidate list of potential nodes on which to run the analytics function.
  • the candidate list 102 may therefore comprise a list of nodes that appear along a shortest path between two nodes that store data needed for the analytics function.
  • the candidate list is sorted so that each node only appears once. According to Figure 2, (a, x, y, b, c) are the unique nodes from the shortest paths between the nodes (a, b, c).
  • the candidate list above is then sorted, using one or more parameters. This may comprise calculating a total cost of computing the analytics function on each of the nodes in the candidate list, wherein the total cost is a combination of the values of one or more parameters calculated for the node and/or one or more neighbouring nodes.
  • the two parameters 'link cost' and 'node cost' can be used to put the candidates in a prioritized order.
  • the end result can then be used to sort the candidates according their total cost: x (5/3), a (6/3), y (6/3), b (7/3), c (7/3).
  • the sorted list above ranks the nodes in order of their link costs (the node with the lowest link cost being ranked the highest).
  • the available resources on each node i.e. the node cost
  • the analytics client can then execute the analytics function according to the prioritised list of nodes.
  • the total cost can also be a weighted combination of the values of the one or more parameters.
  • the link and node costs can be weighted according to how important they are for a particular network or analytics function. The formula to calculate the total cost of running the analytics function on a node a, Cost To tai,a , would then be:
  • COSt T otal,a Weight no de * COStnode, a + Weight
  • in k are the weightings to be applied to the node and link costs respectively. This enables a higher cost to be put on nodes that already are overutilized, by making weight n0 de > weight
  • the examples given above take node costs and link costs into consideration when ranking each node and determining an optimal node on which to calculate the analytics function. More generally, other parameters may also be used, for example, parameters relating to utilisation, such as a node cost or link cost or a measure of network utilization. Alternatively, the one or more parameters may relate to latency, for example, the availability of computing resources, the latency of one or more databases on a node or the speed at which data can be written to and/or read from one or more databases on a node. Costs for the links may be directional (i.e. different costs in different directions depending on load) and thus there may be different parameters describing uplink link cost and downlink link cost for each pair of nodes.
  • the cost in read might depend on the delay of a stream (network capacity) while the cost in write might depend on the disk type of the machine (SSD disk).
  • the choice of which parameters to use may depend on a number of factors, for example, the parameters may be chosen on a network level, such that the AFLS uses the same parameters and cost calculations to determine the optimal nodes for all analytics functions running on the network. For example, if the nodes in a network are generally over-utilised, the equations and calculations above might be modified so as to reduce node utilisation. For instance, the AFLS may calculate the optimal node for each analytics function based solely on the node cost.
  • the parameters may be determined on a network level (i.e. the same parameters may be used for all analytics functions as above) but the parameters chosen may be changed over time, for example, if the AFLS has been calculating the optimal node for each analytics function based solely on the node cost and, over time, node utilisation drops, it may then be preferable for the AFLS to stop calculating the optimal node based on node cost and to use another parameter instead, for example, link utilisation.
  • the parameter(s) may be chosen on a case by case basis for each analytics function.
  • the method may further comprise choosing one or more parameters for the analytics function to use to determine the optimal node on which to run the analytics function. For instance, if a first analytics function requires a node to frequently write to its database, it may be important to choose a node with a low database latency and thus database latency may be used to determine the optimal node.
  • a second analytics function requires particularly resource intensive calculations, it may be more important to choose a node with sufficient memory, and thus a parameter based on CPU may be used to determine the optimal node.
  • different types of costs may be used, depending on the needs of the applications and agreed service level agreements (SLAs). For example, one application might have requirements on maximum latency and therefore a cost model that captures this aspect is needed. At the same time there might be another application that mainly cares about high availability, or a third application that mainly cares about the cost (in dollars) to run the application. All these requirements can be aggregated into different cost values at each node. It is then a matter of selecting the right cost value when executing the method.
  • SLAs agreed service level agreements
  • the chosen parameters relate to potential bottlenecks resulting from the specific tasks that need to be performed in the analytics function. This might include the number of times a particular data source has to be accessed to run the analytics function.
  • the algorithm is also applicable to write access, where the results need to be written in different storage parts. For example, a node might need to frequently update (write) its data and thus the optimal node will reduce the time it takes to write the data to file.
  • Frequency of data access can also be incorporated into the algorithm by putting different weights for different data sources (small weight on high- frequency data sources, and higher weight on low-frequency data sources). This can then be used when doing the link cost calculations, in the sense that all link costs to a certain data source get an additional weight.
  • the effect of this is that the analytics location protocol will try to give high-frequency data sources higher priority, and the optimal node to run the analytics function will be closer to those data sources.
  • FIG. 3 shows a network node 300 in a distributed network, according to another embodiment.
  • the network node 300 comprises an analytics function location module 302 for determining an optimal node in the distributed network on which to run an analytics function.
  • the analytics function location module is configured to determine a candidate list of potential nodes on which to run the analytics function; for each node in the candidate list, obtain at least one parameter relating to the cost of running the analytics function; and determine the optimal node based on the at least one parameter.
  • the analytics function location module 302 is configured to store and maintain a list of locations of data sources in the network.
  • the analytics function location module may then be configured to receive one or more updates of the location of data sources in the network, for instance via the gossip communication protocol referred to above.
  • the analytics function location module may then be configured to update its list of locations of data sources according to the received updates.
  • the analytics function location module may also receive one or more parameters, from a second node in the network relating to the cost of running the analytics function on that node.
  • FIG. 4 shows a network node 400 in a distributed network, according to another embodiment.
  • the network node comprises a processor 402 and a memory 404, said memory containing instructions executable by said
  • the network node is operative to determine a candidate list of potential nodes on which to run the analytics function.
  • the network node is further operative to calculate, for each node in the candidate list, at least one parameter for the node relating to the cost of running the analytics function, and determine the optimal node based on the at least one calculated parameter.
  • the network node may be further operative to carry out any optional steps of method 100.
  • Figure 5 illustrates functional units in another embodiment of a network node in a distributed network which may execute the method 100 of the present invention, for example according to computer readable instructions received from a computer program. It will be understood that the units illustrated in Figure 5 are software implemented functional units, and may be realised in any appropriate combination of software modules.
  • the network node comprises a first module 502 for determining a candidate list of potential nodes on which to run the analytics function.
  • the network node further comprises a second module 504 for calculating, for each node in the candidate list, at least one parameter for the node relating to the cost of running the analytics function, and a third module 506 for determining the optimal node based on the at least one calculated parameter.
  • the network node 500 may comprise a fourth module for storing and maintaining a list of the locations of data sources in the network.
  • the network node 500 may further comprise a fifth module for receiving one or more updates on the location of data sources in the network and updating the list of locations of data sources accordingly.
  • the network node 500 may further comprise a sixth module for receiving one or more parameters relating to the cost of running the analytics function. Furthermore, the network node 500 may comprise a seventh module for receiving the one or more parameters through gossip communication.
  • a computer program which, when run on a computer, causes the computer to carry out a method according to any of the embodiments listed above.
  • a computer program product comprising computer readable storage medium and a computer program according to the above, stored on the computer readable storage medium.

Abstract

L'invention concerne un procédé dans un réseau distribué pour déterminer un nœud optimal sur lequel exécuter une fonction d'analyse. Le procédé consiste à déterminer une liste candidate de nœuds potentiels sur lesquels exécuter la fonction d'analyse. Le procédé consiste en outre, pour chaque nœud dans la liste candidate, à calculer au moins un paramètre pour le nœud concernant le coût d'exécution de la fonction d'analyse et à déterminer le nœud optimal sur la base du ou des paramètres calculés.
PCT/EP2015/069173 2015-08-20 2015-08-20 Procédés et appareil pour exécuter une fonction d'analyse WO2017028930A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2015/069173 WO2017028930A1 (fr) 2015-08-20 2015-08-20 Procédés et appareil pour exécuter une fonction d'analyse

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2015/069173 WO2017028930A1 (fr) 2015-08-20 2015-08-20 Procédés et appareil pour exécuter une fonction d'analyse

Publications (1)

Publication Number Publication Date
WO2017028930A1 true WO2017028930A1 (fr) 2017-02-23

Family

ID=54105766

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2015/069173 WO2017028930A1 (fr) 2015-08-20 2015-08-20 Procédés et appareil pour exécuter une fonction d'analyse

Country Status (1)

Country Link
WO (1) WO2017028930A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107528904A (zh) * 2017-09-01 2017-12-29 星环信息科技（上海）有限公司 用于数据分布式异常检测的方法与设备

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140372611A1 (en) * 2013-06-14 2014-12-18 Fujitsu Limited Assigning method, apparatus, and system
WO2015032430A1 (fr) * 2013-09-04 2015-03-12 Telefonaktiebolaget L M Ericsson (Publ) Ordonnancement de machines virtuelles

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140372611A1 (en) * 2013-06-14 2014-12-18 Fujitsu Limited Assigning method, apparatus, and system
WO2015032430A1 (fr) * 2013-09-04 2015-03-12 Telefonaktiebolaget L M Ericsson (Publ) Ordonnancement de machines virtuelles

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
ARSLAN ENGIN ET AL: "Locality and Network-Aware Reduce Task Scheduling for Data-Intensive Applications", 2014 5TH INTERNATIONAL WORKSHOP ON DATA-INTENSIVE COMPUTING IN THE CLOUDS, IEEE, 21 November 2014 (2014-11-21), pages 17 - 24, XP032726756, DOI: 10.1109/DATACLOUD.2014.10 *
BALAJI PALANISAMY ET AL: "Purlieus: Locality-aware resource allocation for MapReduce in a cloud", HIGH PERFORMANCE COMPUTING, NETWORKING, STORAGE AND ANALYSIS (SC), 2011 INTERNATIONAL CONFERENCE FOR, IEEE, 12 November 2011 (2011-11-12), pages 1 - 11, XP032081479, ISBN: 978-1-4503-0771-0 *
MANFU MA ET AL: "A Grid-distance Based Scheduling for Grid Resource Management", HIGH-PERFORMANCE COMPUTING IN ASIA-PACIFIC REGION, 2005. PROCEEDINGS. EIGHTH INTERNATIONAL CONFERENCE ON BEIJING, CHINA 30-03 NOV. 2005, PISCATAWAY, NJ, USA,IEEE, 30 November 2005 (2005-11-30), pages 1 - 6, XP010895507, ISBN: 978-0-7695-2486-3, DOI: 10.1109/HPCASIA.2005.4 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107528904A (zh) * 2017-09-01 2017-12-29 星环信息科技（上海）有限公司 用于数据分布式异常检测的方法与设备
CN107528904B (zh) * 2017-09-01 2020-02-18 星环信息科技（上海）有限公司 用于数据分布式异常检测的方法与设备

Similar Documents

Publication Publication Date Title
US10904319B2 (en) Dynamic deployment of an application based on micro-services
US11018979B2 (en) System and method for network slicing for service-oriented networks
JP7061693B2 (ja) グラフデータに基づくタスクスケジューリング方法、装置、プログラム及び機器
JP4421637B2 (ja) サブタスク・プロセッサの分散スケジューリング
US8924392B2 (en) Clustering-based resource aggregation within a data center
US9420513B1 (en) Clustering approach to estimating a network metric for nodes
Tos et al. Dynamic replication strategies in data grid systems: a survey
Kang et al. Virtual network function allocation to maximize continuous available time of service function chains with availability schedule
CN112148492A (zh) 一种考虑多用户移动性的服务部署和资源分配方法
Wang et al. Network-aware QoS prediction for service composition using geolocation
Abreu et al. A rank scheduling mechanism for fog environments
JP4265377B2 (ja) 負荷分散方法及び装置とシステム並びにプログラム
Lu et al. Cost-efficient resource provisioning in delay-sensitive cooperative fog computing
US9124508B2 (en) Communication control device communication control system, communication control method and program
Shefu et al. Fruit fly optimization algorithm for network-aware web service composition in the cloud
WO2017028930A1 (fr) Procédés et appareil pour exécuter une fonction d'analyse
CN115361332A (zh) 容错路由的处理方法及装置、处理器和电子设备
Qiao et al. Load balancing in peer-to-peer systems using a diffusive approach
Di et al. Decentralized proactive resource allocation for maximizing throughput of P2P grid
Rahmanian et al. RAVAS: Interference-Aware Model Selection and Resource Allocation for Live Edge Video Analytics
Zhao et al. Distance-aware virtual cluster performance optimization: A hadoop case study
CN115587222B (zh) 分布式图计算方法、***及设备
Archana et al. Fog Offloading and Scheduling in Traffic Monitoring System by Deep Reinforcement
Celaya et al. Scalable architecture for allocation of idle CPUs in a P2P network
Cavallo et al. Multi-job Hadoop scheduling to process geo-distributed big data

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

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

Country of ref document: EP

Kind code of ref document: A1