WO2013050682A1 - Procédé de routage adaptatif pseudo-dynamique dans un cluster comprenant des liens de communication statiques et programme d'ordinateur mettant en oeuvre ce procédé - Google Patents

Procédé de routage adaptatif pseudo-dynamique dans un cluster comprenant des liens de communication statiques et programme d'ordinateur mettant en oeuvre ce procédé Download PDF

Info

Publication number
WO2013050682A1
WO2013050682A1 PCT/FR2012/052090 FR2012052090W WO2013050682A1 WO 2013050682 A1 WO2013050682 A1 WO 2013050682A1 FR 2012052090 W FR2012052090 W FR 2012052090W WO 2013050682 A1 WO2013050682 A1 WO 2013050682A1
Authority
WO
WIPO (PCT)
Prior art keywords
nodes
application
execution
routing
route
Prior art date
Application number
PCT/FR2012/052090
Other languages
English (en)
Inventor
Jean-Vincent Ficet
Sébastien DUGUE
Yann Kalemkarian
Original Assignee
Bull Sas
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 Bull Sas filed Critical Bull Sas
Publication of WO2013050682A1 publication Critical patent/WO2013050682A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H04L45/306—Route determination based on the nature of the carried application
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/12—Shortest path evaluation
    • H04L45/123—Evaluation of link metrics
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/12—Shortest path evaluation
    • H04L45/125—Shortest path evaluation based on throughput or bandwidth
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2475—Traffic characterised by specific attributes, e.g. priority or QoS for supporting traffic characterised by the type of applications

Definitions

  • the present invention relates to the routing in a cluster, that is to say the determination of communication routes between a computer and a computer. a set of nodes of the cluster, and more particularly a pseudodynamic adaptive routing method in a cluster comprising static communication links and a computer program implementing this method.
  • HPC High Performance Computing
  • Performance Computing in Anglo-Saxon terminology is developing for both academic research and industry, particularly in technical fields such as aeronautics, energy, climatology and life sciences.
  • modeling and simulation make it possible to reduce development costs and speed up the launch of innovative, more reliable and less energy-consuming products.
  • high performance computing has become an indispensable means of investigation.
  • a cluster typically includes a set of interconnected nodes. Some nodes are used to perform compute tasks (compute nodes), others to store data (storage nodes), and one or more others manage the cluster (administration nodes). Each node is for example a server implementing an operating system such as Linux (Linux is a brand). The connection between the nodes is, for example, carried out using Ethernet or Infiniband communication links (Ethernet and Infiniband are trademarks).
  • Figure 1 schematically illustrates an example of a topology 100 of a cluster, type fat-tree.
  • the latter comprises a set of generically referenced nodes 105.
  • the nodes belonging to the set 110 are here calculation nodes while the nodes of the set 1 15 are service nodes (storage nodes and administration nodes). .
  • Nodes The calculation units may be grouped into subsets 120 called calculation islands, the set 1 being called the service island.
  • the nodes are connected to each other by switches
  • nodes are connected to first level switches 125 which are themselves connected to second level switches 130 which are in turn connected to third level switches 135.
  • each node generally comprises one or more microprocessors, local memories as well as a communication interface. More specifically, the node 200 here comprises a communication bus 202 to which are connected:
  • central processing units or microprocessors 204 or
  • CPU Central Processing Unit
  • RAM Random Access Memory
  • Random Access Memory in English terminology having registers adapted to record variables and parameters created and modified during the execution of programs (as illustrated, each memory component can be associated with a microprocessor); and,
  • communication interfaces 208 adapted to transmit and receive data.
  • the node 200 furthermore has internal storage means
  • the communication bus allows the communication and interoperability between the different elements included in the node 200 or connected to it.
  • the microprocessors 204 control and direct the execution of the instructions or portions of software code or programs. When powering up, the program or programs that are stored in a non-volatile memory, for example a hard disk, are transferred into the RAM 206.
  • the performances of a cluster are directly related to the quality of the roads allowing the transfer of data between the nodes, established via communication links.
  • physical communication links are established between the nodes and the switches during the hardware configuration of a cluster, the communication routes being themselves determined in an initialization phase from a definition of the connections. to be established between the nodes.
  • the configuration of the routes can be static or dynamic.
  • Infiniband technology enables a static configuration of roads in a cluster.
  • This configuration uses static routing tables (or LFT, acronym for Linear Forwarding Table in English terminology) in each switch.
  • LFT Linear Forwarding Table
  • a routing algorithm such as the algorithms known as FTree, MINHOP, UPDN and LASH can be used.
  • the FTree algorithm determines routes so that they are distributed as much as possible through the existing communication links. For these purposes, when routing a fully connected communication network according to a fat-tree architecture, each node of the network is considered to have the same importance. Thus, when a route is established between two nodes of the same link, the number of routes using this link, called the link load, is increased by one. When the routing algorithm tries to establish a new route and there are several possibilities, it compares the load levels associated with the links on which these possibilities are based and chooses the one with the links with the lowest load level.
  • the routing quality can be expressed in terms of the number of routes per link.
  • FIG. 3 comprising FIGS. 3a to 3e, illustrates this routing principle in a switch 300 during an initialization phase of a cluster comprising this switch.
  • the switch 300 here has four input communication links, denoted 310-1 to 310-4, connecting the switch 300 to inputs 305-1 to 305-4 and two output communication links, denoted 320-1 and 320. -2, connecting the switch 300 to outputs 315-1 and 315-2.
  • none of the links 310-1 through 310-4, 320-1, and 320-2 comprise a route.
  • the load levels associated with these links are therefore zero as shown in Figure 3a next to each link.
  • the link 310-1 (the only one that can be used) is selected along with the link 320-1 (the associated load levels).
  • links 320-1 and 320-2 being equal, here at zero, the first link is selected).
  • the load levels associated with the links 310-1 and 320-1 are then incremented by one to indicate that these links implement an additional route, as illustrated in FIG. 3b.
  • link 310-2 (the only one that can be used) is selected along with link 320-2 (load level). associated with the link 320-1 being equal to one and the load level associated with the link 320-2 being equal to zero, this last link is selected).
  • the load levels associated with the links 310-2 and 320-2 are then incremented by one to indicate that these links implement an additional route, as illustrated in FIG. 3c.
  • the link 310-3 (the only one that can be used) is selected as well as the link 320-1 (the levels of load associated with links 320-1 and 320-2 being equal, the first link is selected).
  • the load levels associated with the links 310-3 and 320-1 are then incremented by one to indicate that these links implement an additional route, as illustrated in FIG. 3d.
  • the link 310-4 (the only one that can be used) is selected as well as the link 320-2 (the associated load level). at link 320-1 being equal to two and the load level associated with link 320-2 being equal to one, this last link is selected).
  • the load levels associated with links 310-4 and 320-2 are then incremented by one to indicate that these links implement an additional route, as shown in FIG. 3e.
  • the invention solves at least one of the problems discussed above.
  • the subject of the invention is thus a pseudo-dynamic adaptive routing computer method for executing an application in a cluster comprising a plurality of nodes, static communication links connecting nodes of said plurality of nodes, said routing. being based on load levels associated with said communication links, the method comprising the following steps,
  • the method according to the invention thus makes it possible to improve the routing of a cluster for the execution of an application by taking into account information relating to a previous execution of the application.
  • the method further includes, advantageously, a step of determining said at least one performance indication of an earlier execution of said application.
  • said step of determining said at least one performance indication comprises a step of obtaining initial and final values of at least one performance counter, said performance indication being based on a variation in value said at least one performance counter.
  • the method according to the invention is thus particularly simple to implement in that it uses information generally available in a cluster targeting application execution characteristics.
  • the method furthermore preferably comprises a step of obtaining the routing scheme linked to the execution of said application in order to allow the establishment of a link between an application and the hardware resources implemented for the execution. of this application.
  • the method further comprises a step of determining an execution priority level of said application, said step of estimating a weight value associated with said selected route according to at least one performance indication of an earlier execution of said application being performed in response to said step of determining a priority level of said application.
  • routing optimization of a cluster is based in particular on the execution priority of the applications to be executed.
  • the method further comprises a preliminary step to determine whether a new routing related to the execution of said application must be performed.
  • a new routing can thus be performed selectively so that it is performed under certain conditions, especially if this new routing is of real interest.
  • the method further comprises a step of updating at least one static routing table, said at least one static routing table being associated with at least one switch of said cluster, said at least one switch connecting at least two nodes of said cluster.
  • the method according to the invention can thus be implemented in clusters using technologies such as infinfinand.
  • the method further comprises a step of launching the execution of said application.
  • the invention also relates to a computer program comprising instructions adapted to the implementation of each of the steps of the method described above when said program is executed on a computer and a means of storing information, removable or no, partially or completely readable by a computer or a microprocessor having code instructions of a computer program for performing each of the steps of the method previously.
  • FIG. 1 illustrates an exemplary topology of a cluster
  • FIG. 2 illustrates an exemplary architecture of a node of a cluster
  • FIG. 3 comprising FIGS. 3a to 3e, illustrates the routing principle, according to a FTree type algorithm, in a switch during an initialization phase of a cluster comprising this switch;
  • FIG. 4 represents a simplified block diagram illustrating the role of software modules involved in the implementation of the invention
  • FIG. 5 comprising FIGS. 5a to 5d, illustrates an example of the principle of routing with weights, in a switch, during an initialization phase of a cluster comprising this switch;
  • FIG. 6, comprising FIGS. 6a and 6b, illustrates certain steps of an exemplary algorithm for routing or re-routing a cluster comprising static communication links. It has been observed that if the routes of a communication network in a cluster are of the same nature, the nature of the nodes connected by these routes plays a role vis-à-vis the volume of data exchanged and therefore the bandwidth used . Thus, for example, a route connecting two compute nodes generally uses less bandwidth than a route connecting a compute node to a storage node.
  • the routes used to connect compute nodes used to perform the same task generally require a higher bandwidth than those used to connect compute nodes used to perform different tasks.
  • a task or a process also called a job in English terminology, is an application defined, in particular, in a time and place. It is usually executed by a set of nodes after being launched by a task manager, also called batch manager, resource manager or job manager in English terminology.
  • the purpose of the task manager is, in particular, to determine the number of nodes required to execute a task, to check that there are a sufficient number of available nodes to execute the task, taking into account, where appropriate, special constraints, including constraints determined by a user, to allocate nodes to the execution of the task and start its execution.
  • Some applications are run periodically, for example every day.
  • priorities can be assigned to applications to promote their execution relative to the execution of other applications.
  • a high priority may be associated with a weather forecasting application to obtain results at a given time.
  • the invention therefore aims to obtain precise topology and performance information related to an application implemented by nodes of a cluster according to an allocation made by a routing module to enable the if necessary, an improvement of this allocation during a subsequent implementation of this same application.
  • This information may in particular be obtained from statistical data from the interconnection devices used, for example Infiniband type switches. The processing of this data makes it possible to establish an application profile that can be used to improve a routing operation according to real measurements.
  • the object of the invention is in particular to improve the routing linked to an application when the application is rerun, re-routing an application before its execution requires time and therefore represents a cost. It is therefore advantageous to perform a routing operation only if the targeted application has a high priority level.
  • FIG. 4 represents a simplified block diagram illustrating the role of software modules involved in the implementation of the invention.
  • the software modules implemented here are the task manager 410 (JobManager), the optimization module 415 according to the invention here called RAKI (Routing acronym Advanced Knowledge for Interconnect technlogies in English terminology) and the administration and network manager 420 (for example the module known as openSM).
  • the task manager 410 JobManager
  • the optimization module 415 according to the invention here called RAKI (Routing acronym Advanced Knowledge for Interconnect technlogies in English terminology)
  • the administration and network manager 420 for example the module known as openSM.
  • the purpose of the task manager is to manage priorities, queues, and loads in the cluster.
  • This is, for example, one of the software modules known as PBS Professional (PBS is a trademark), LSF (abbreviation of Load Sharing FacHity in English terminology) and Slurn (acronym for Simple Linux Utility for Resource Management in Anglo-Saxon terminology).
  • the optimization module according to the invention is intended in particular to identify the applications to be considered as privileged, to build performance profiles for the applications considered. as privileged and apply learning enhancement techniques to help improve a cluster's return on investment, ie here to improve cluster performance for running applications given in optimizing routing.
  • the optimization module is used to store application features, such as their name, size, and run history. It also makes it possible to associate routing characteristics of the components of the cluster, necessary for the execution of the application, according to the characteristics of the targeted application.
  • the adjustment module also makes it possible to memorize a performance profile created during the execution of an application and making it possible to improve the routing of the cluster components necessary for the execution of the application. Such information may, for example, be stored in a database.
  • the optimization module decides whether or not it is advantageous to reroute the cluster components needed to run an application, including adjusting link weights.
  • the administration and network manager determines the routing schemes to be used and deploys them via, for example, routing tables. To determine routing schemes, weights of connections are used as described below.
  • a first step shown in FIG. 4 consists in starting or activating the optimization module according to the invention (RAKI). This step is initiated here (step 425) by the administration and network manager 420 using a command here called startRAKIQ.
  • a query is issued by the task manager 410 to determine whether the RAKI optimization module is operational. This query is performed here using a command called RAKI? (). According to a particular embodiment, the absence of response within a predetermined time means that the RAKI optimization module is not operational.
  • a command typically called scheduleQ
  • scheduleQ is sent to the task manager so that the latter reserves resources for the execution of this application.
  • a scheduleQ command is addressed to the task manager 410 (step 435).
  • the task manager will schedule the execution of this application.
  • the task manager determines whether the application 1 is privileged within the meaning of the invention, that is to say if it is to be the subject of a particular analysis and, if the case where appropriate, new routing. For these purposes, the task manager sends a command, here called privileged? (), To the RAKI optimization module (step 440).
  • a negative response is received from the RAKI optimization module (step 445) or no response is received in response to the privileged? ) (according to a particular embodiment, the absence of response within a predetermined time means that the application should not be considered as privileged). In this case, its execution is handled in a standard way by the task manager.
  • a scheduleQ command is addressed to the task manager 410 (step 450).
  • the task manager queries the RAKI optimization module using a privileged? () Command (step 455) to determine whether this application should be considered privileged within the meaning of the invention.
  • the application 2 being considered as such, a response to this effect is sent to the task manager (step 460).
  • a command here called CountersPicQ is then addressed by the RAKI optimization module to the task manager (step 465) in order to determine the state of indicators of interconnection devices used, that is to say to take a photograph of the state of these devices before running the application 2.
  • the indicators used are traffic volume counters between each pair of device ports and data block counters between these port pairs.
  • These states are preferably transmitted to the RAKI optimization module (step 470) where they are stored.
  • the RAKI optimization module determines if there is a profile for the application to be executed, here the application 2, and, if so, determines whether to re-route the application. cluster, that is, reconfigure cluster switches.
  • routePrivileged a command, here called routePrivileged () is transmitted to the administration and network manager 420 (step 475) so that the latter re-routes the application and transmits the results to the routing tables implemented. If it is not necessary to re-route the application, the application is executed according to the previously defined configuration.
  • the task manager reruns the function previously called by the CountersPicQ command to determine the state of indicators of interconnection devices used, that is to say to take a photograph the state of these devices after the execution of the application 2.
  • these states are preferably transmitted to the RAKI optimization module (step 485) where they are stored.
  • an application when invoked by a user to be executed, it is firstly determined whether this application is to be considered as privileged (within the meaning of the invention) or not. If the application should not be considered privileged, it is treated in a standard way, without rerouting the cluster. Determining whether an application should be considered privileged can be based on heuristics such as the type of application, the number of nodes used, the traffic generated in the cluster, and the available resources of the cluster.
  • an application is to be considered privileged, actions are invoked when it is launched.
  • the performance counter values of the switches involved in the execution of this application are stored.
  • a profile of this application is obtained from a database.
  • Such a profile represents here a diagram of routing and associated traffic determined during the previous run of the application. This profile makes it possible to fine-tune the routing of the application by assigning and adapting weights to roads connecting certain nodes of a cluster in order to bias the routing algorithm used with respect to certain routes and, by therefore, optimize the bandwidth allocation to each route in the communication links implemented.
  • an application profile is determined from the routing scheme and information from performance counters. Such a profile is constructed and then adjusted in two stages, one being performed before the execution of the application and the other after.
  • the pseudo-code given in the appendix illustrates a particularly simple example of instructions for evaluating such a profile.
  • the routing scheme is determined and the values of the performance counters of the switches involved are stored using a function called populate.
  • a tree of nodes (tree) is established from a list of nodes (elected nodes) accessible via the task manager. Knowing the topology of the physical connections, it is possible to associate with the tree of nodes built the used ports (port_tree).
  • port_tree By using a wide analysis approach (called a large parsing approach in English terminology) targeting all the interfering ports of the switches implemented for the execution of the application, it is possible to take into account the associated tasks, also called alien jobs, in order to isolate the traffic resulting from these interfering tasks.
  • the volume of data that has passed (port volume) and the volume of data blocked (port blocked) are then stored for each identified port in the determined node tree.
  • a function called profile
  • Its purpose is notably to determine the volume of data that has passed through (port volume) and the volume of data blocked (port blocked) for each port identified in the determined tree of nodes, during the execution of the application. This estimate is obtained by subtracting the stored volume of data having passed (port_tree [i]. volume) and the stored volume of blocked data (port_tree [i] .blocked) to the volume of data having passed (volume port) and the volume of data blocked ( port blocked), measured at the end of the execution of the application, for each port identified in the node tree.
  • the values obtained are then adjusted (port_tree statistic adj.) To take into account the traffic generated by the execution of ancillary tasks. Such an adjustment can be made statistically according to the traffic measured on the interfering ports of the switches implemented for the execution of the application.
  • the weights to be used to route the cluster to execute the application are then adjusted according to the values obtained. Such an adjustment is for example to increase the weight values associated with links corresponding to important traffic values and to decrease the weight values associated with links corresponding to low traffic values. For these purposes, thresholds can be used.
  • the information for adjusting the weights to be used to route the cluster to run the application is then stored, preferably after being compressed, for later use, typically when the application is run again.
  • Assigning and, if necessary, adjusting a given weight to certain types of roads or routes can bias routing towards certain routes that have specific bandwidth requirements.
  • a high value weight for a route connecting two nodes it is possible to allocate a higher bandwidth to the data communication between these nodes.
  • the assignment of weight to roads during a routing phase can be performed through an API (acronym for Application Program Interface in English terminology).
  • the weight assignment during the routing phase can in particular be determined according to the type of the nodes, the group or groups to which they belong or according to the tasks executed by these nodes, so separate. As previously described, these weights can be modified to account for performance information.
  • weight_fHe a weight file
  • GUIDs port Globally Unique IDentifiers in English terminology
  • Such a file is analyzed before the routing phase. It contains a list of communicating elements of the communication network, typically nodes, grouped by type, and a list of weights for couples formed between these groups. During their analysis, these weights can be used to fill a matrix that describes the increment of load level to be used for each communication link during the routing phase. By default, when the value of a weight for a route connecting two types of nodes is not defined, its value is equal to one.
  • the values obtained from the weights can then be modified according to adjustment information associated with applications and determined during the execution of these applications.
  • the load level associated with each of these links is incremented by the weight value related to the types of nodes between which the route is established.
  • FIG. 5 comprising FIGS. 5a to 5d, illustrates the principle of routing as a function of the type of the nodes or group or groups to which they belong, in a switch 500, during a phase of initialization of a cluster comprising this switch.
  • the switch 500 here has four input communication links, denoted 510-1 to 510-4, connecting the switch 500 to inputs 505-1 to 505-4 and two links of output communication, denoted 520-1 and 520-2, connecting the switch 500 to outputs 515-1 and 515-2.
  • the inputs are, for example, outputs of network nodes or outputs of other switches.
  • none of the links 510-1 through 510-4, 520-1, and 520-2 include a route.
  • the charge level associated with each of these links is therefore zero as illustrated in Figure 5a next to each link.
  • the 510-1 link (the only one that can be used) is selected along with the 520-1 link (the same load level). no one is associated with the links 520-1 and 520-2, the first link is selected). It is assumed here that the route using the links 510-1 and 520-1 that has just been established is for connecting a compute node to a storage node. Therefore, if the weight value of a route connecting storage and compute type nodes is 200, this value is used to increment the load level of links 510-1 and 520-1, as shown in FIG. 5b.
  • the link 510-2 (the only one that can be used) is selected along with the link 520-2 (a load level 200 being associated with the link 520-1 and a level of zero load being associated with the link 520-2, the latter, whose load level has the lowest value, is selected).
  • the link 510-3 (the only one that can be used) is selected as well as the link 520-2 (a load level equal to 200 being associated with the link 520-1 and a level of load equal to 99 being associated with link 520-2, the latter, whose load level has the lowest value, is selected). If it is accepted that the route using the links 510-3 and 520-2 which has just been established is intended to link two compute nodes and that the weight value of a route connecting computation type nodes is 1, this value is used to increment the load level of links 510-3 and 520-2, as shown in Figure 5d.
  • the nodes having as GUIDs port the values 0x100901, 0x101201, 0x100903, 0x1 101203, 0x101207, 0x100909 and 0x101209 are "storage" type nodes, that is to say storage nodes.
  • the definition of a type of nodes is done here using the indication DEF followed by the name of the group itself followed by the list of corresponding GUIDs port, placed in braces.
  • the nodes having for GUIDs port the values 0x100905, 0x101205 and 0x00907 are nodes of the "admin" type, that is to say management nodes.
  • the nodes having for GUIDs port the values 0x10090b, 0x010120b, 0x10090d, 0x10120d, 0x10090f, 0x10120f, 0x10091 1, 0x101211, 0x100913, 0x101213, 0x100915, 0x100917, 0x101217 and 0x100919 are nodes of "compute” type, c i.e. computing nodes.
  • a type of node called “service” includes all the nodes of types "storage” and "admin”.
  • the weights are given here at the end of the file.
  • ID1 is the GUID port or the group of the original node
  • ID2 is the GUID port or the node group of destination
  • weight is the value to be used when calculating the load of a link.
  • the roads are considered to be directional, the load level associated with a road may be the same as that associated with the reverse road as if the roads were bidirectional.
  • Such routing can be performed during the initialization of the cluster or be performed together with a re-routing related to the execution of an application.
  • a list of the identifiers of the nodes allocated to the execution of this application is transmitted to an intra-task weight management software module during a step called prologue of the task (or prologue job). in Anglo-Saxon terminology). This list is established by the task manager before launching the application.
  • the intra-task weight management module then associates a task identifier with the identifiers of nodes belonging to the received list and preferably establishes a correspondence between these node identifiers and information stored in a database, in particular identifiers. port, or GUIDs port, to map a task ID to a GUID port.
  • a weight having a particular value is then assigned to each port pair GUIDs associated with the same identifier.
  • the load level of a communication link used to establish a route between two nodes not being allocated to the execution of the same application can be equal to one
  • the load level of a similar communication link used to establish a route between two nodes allocated to the execution of the same application can be equal to ten.
  • the charge level of each of these communication links is incremented by ten.
  • the value of these weights can be adjusted according to previously computed performance information.
  • the value of the initial weight assigned to a pair of port GUIDs can be incremented by ten if the ratio between the data volumes having passed through and blocked data associated with this pair is less than a first predetermined and decremented threshold. by ten if this ratio is greater than a second predetermined threshold. It is thus possible to adjust the weight of each port pair GUIDs.
  • an application is identified on nodes whose mapping of all the ports is known since they are referenced in the administration system of the cluster.
  • a port of a first-level switch is a small number of processes (or jobs) typically one, sometimes two or three.
  • the process manager can, from the port references, determine the name of an application, for example by using its characteristics, including its symbols. At this application name is associated a profile.
  • a message can then be sent to a network manager, called a subnet manager in English terminology, to re-route the cluster according to the application to be executed.
  • a network manager called a subnet manager in English terminology
  • the task After re-routing, the task is started. Then, after its execution, the weight values of the pairs of nodes (or port GUIDs) allocated to the execution of this task are reset to their initial value, for example to the value one. This step is called an epilogue.
  • the routes are preferably determined in an orderly manner so that a road associated with a weight whose value is greater than that of a weight of another road is determined before this other route to optimize routing.
  • This order can be determined from the weight matrix and node groups to identify them according to their type and from a table of weight determined when launching a task.
  • FIG. 6, comprising FIGS. 6a and 6b, illustrates certain steps of an exemplary algorithm for routing or re-routing a cluster comprising static communication links.
  • FIG. 6a schematically illustrates an exemplary algorithm implemented to determine and select a route connecting two nodes as well as to determine the charge level of a communication link after the selection of a route.
  • a first step (step 600) here concerns the initialization of a weight matrix making it possible to associate a weight with a pair of nodes formed of two nodes (same weight whatever the direction of the road) or a original node and a destination node (road-related weight) as shown in the appendix (table 1).
  • This matrix can in particular be established from a weight file such as that presented in the appendix (extract 1).
  • This step also makes it possible to memorize the correspondences between an identifier of a node with its type and / or one or more groups to which it belongs.
  • the weight matrix can directly establish the weights associated with each pair of nodes as shown in the appendix (table 2).
  • Table 1 shows the weight to be assigned to a route connecting a source node type to a destination node type while Table 2 indicates the weight to be assigned to a route connecting a source node to a destination node.
  • a pair of nodes between which a route is to be established is identified.
  • the node pair here includes a source node and a destination node.
  • This step is a basic step in routing algorithms to help define the routes to be established. Nodes are, for example, identified by GUIDs.
  • step 610 The steps of determining the possible routes for connecting these identified nodes and selection of the best route are then performed (step 610) according to a standard algorithm, for example according to the FTree algorithm.
  • step 615 the type of the identified nodes or the group or groups to which they belong are obtained according to the information obtained during the initialization step. As suggested by the use of dashed lines, this step is optional because if, in particular, the weight matrix determined during the initialization phase directly associates weights with the identifiers of the nodes, it is not necessary at this stage , to determine the type and / or to determine the group or groups to which they belong.
  • the weight of the road connecting these two nodes is then estimated (step 620). This estimate is based on the types of nodes, the group (s) to which they belong and / or their identifier, for example their GUID port, or on calculation results previously performed if the two nodes identified are calculation nodes allocated to the node. execution of the same task.
  • the weight is related to the type of the identified nodes or to one or more groups to which they belong, it is preferably directly given by a reading of the previously determined weight matrix.
  • a weight can be estimated according to a reference stored in the weight matrix according to a predetermined function or table.
  • the weights from the weight matrix can also be increased or decreased according to particular circumstances related, for example, to the topology of the cluster and the position of the links implemented by the road in question.
  • the value of the weight of a road is not equal to a default value, it is equal to a value determined according to a type of nodes or groups of membership or according to an allocation according to a task but it is preferably not equal to a value determined according to a type of nodes or membership groups and according to an allocation according to a task. Therefore, if this value is determined at from the weight matrix used, it is not always necessary to check whether the weight must be modified according to the allocation of the identified nodes.
  • Table 3 here comprises three columns corresponding respectively to a source GUID port, a destination GUID port and a weight value. Each line corresponds to a route between the node comprising the source GUID port and the node comprising the destination GUID port.
  • the estimated weight is then, if necessary, adjusted according to previously determined performance information. For these purposes, the performance information related to the intended application is obtained. The estimated weight is then adjusted according to this information and predetermined rules.
  • the estimated weight and possibly adjusted for the selected route is then used to update the load level associated with the communication links implemented by the route considered (step 625). As previously described, the value of the estimated weight can be added to the load level of the communication links implemented by the considered route.
  • steps 605 to 625 can be repeated to establish new routes.
  • steps 605 to 625 are repeated for all routes to be established in the cluster in which the algorithm illustrated in Figure 6a is implemented.
  • Figure 6b illustrates some steps of an example of a road weight calculation algorithm connecting two nodes when these nodes are allocated to the execution of the same application.
  • the task manager determines whether the new application can be run and, if so, lists the nodes allocated to run it.
  • the intra-task weight management module receives the list of nodes allocated to its execution (step 635).
  • a task identifier is associated with these node identifiers.
  • step 640 A test is then performed (step 640) to determine whether the application to be performed is, within the meaning of the invention, an application to be considered as preferred. As previously described, this test can be based on heuristics such as the type of the application, the number of nodes used, the traffic generated in the cluster and the available resources of the cluster.
  • step 645 If the application to be executed should not be considered privileged, an instruction is transmitted to the task manager to allow execution of the application considered (step 645). The algorithm then returns to step 630 pending a new application to execute.
  • the routing scheme is obtained (step 650) as well as the performance values (step 655).
  • the performance values are, for example, the counter values implemented in the switches to be used by the application in question.
  • a test is then performed (step 660) to determine whether to re-route the cluster to optimize, in particular, the execution of the application to be executed.
  • Such a test can consist in comparing the number of nodes allocated to the application to be executed with the number of nodes used in the cluster and / or in comparing the estimated execution time of the application with and without re-routing.
  • step 665 If it is not necessary to perform a re-routing, an instruction is transmitted to the task manager to allow the execution of the application concerned (step 665). The algorithm then returns to step 630 while waiting for a new task to be performed. However, as previously described, the performance values are obtained (step 670) at the end of the execution of the application and the profile of the application is estimated and stored (step 675).
  • the estimation of the application profile, to adapt connection weights in a cluster can simply consist of creating a set of performance values.
  • the profile is estimated from these values according to a standard datamining algorithm allowing incremental learning of the profile so that the latter converges towards an optimal solution.
  • a next step is to establish a link between node identifiers and routing information such as GUIDs.
  • This step is typically performed from the list of node identifiers received from the task manager and configuration data generally stored in a database. This step notably makes it possible to identify source addresses and node destinations allocated to the execution of the same task and between which routes must be established.
  • a weight is assigned and adjusted (step 685) to each route connecting an output address of a node allocated to the task to be executed to an input address of a node allocated to that same task.
  • Such addresses are preferably GUIDs.
  • This step makes it possible to establish a weight table such as that illustrated in the appendix (Table 3).
  • the cluster is then re-routed according to an algorithm such as that described with reference to FIG. 6a (reference A).
  • the new routing scheme is obtained as well as the corresponding performance values (steps not shown).
  • the performance values are, for example, the counter values implemented in the switches to be used by the application in question.
  • An instruction is then transmitted to the task manager to enable execution of the application concerned (step 665).
  • the algorithm then returns to step 630 while waiting for a new task to be performed.
  • the performance values are obtained (step 670) at the end of the execution of the application and the profile of the application is estimated and stored (step 675).
  • the obtained performance information may be displayed, graphically or textually, to enable a user to analyze the routing of an application.
  • IBs :: RAKI :: populate (context information):
  • port_tree parse tree, list up and down ports (tree);
  • IBs :: RAKI :: profile (context information):
  • Pseudo-code 1 evaluation of a performance profile

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne le routage adaptatif pseudo-dynamique, pour l'exécution d'une application, dans un cluster comprenant des nœuds et des liens de communication statiques entre ces nœuds. Le routage est basé sur des niveaux de charge des liens de communication. Après avoir identifié (605) des nœuds devant être utilisés pour exécuter l'application, une connexion devant être établie entre ces nœuds, au moins une route connectant ces nœuds est déterminée (610), ladite au moins une route étant déterminée selon ces nœuds, les liens de communication et un niveau de charge associé à chaque lien de communication. Une route déterminée est alors sélectionnée. Une valeur de poids associé à chaque lien de communication de la route sélectionnée est ensuite estimée (685), notamment selon une indication de performance d'une exécution antérieure de l'application. Un niveau de charge associé à chaque lien de communication comprenant la route sélectionnée est incrémenté (625) selon ledit poids estimé.

Description

Procédé de routage adaptatif pseudo-dynamique dans un cluster comprenant des liens de communication statiques et programme d'ordinateur mettant en uyre ce procédé La présente invention concerne le routage dans un cluster, c'est-à- dire la détermination de routes de communication entre un ensemble de nœuds du cluster, et plus particulièrement un procédé de routage adaptatif pseudodynamique dans un cluster comprenant des liens de communication statiques et un programme d'ordinateur mettant en œuvre ce procédé.
Le calcul haute performance, aussi appelé HPC (sigle de High
Performance Computing en terminologie anglo-saxonne) se développe pour la recherche universitaire comme pour l'industrie, notamment dans des domaines techniques tels que l'aéronautique, l'énergie, la climatologie et les sciences de la vie. La modélisation et la simulation permettent en particulier de réduire les coûts de développement, d'accélérer la mise sur le marché de produits innovants, plus fiables et moins consommateurs d'énergie. Pour les chercheurs, le calcul haute performance est devenu un moyen d'investigation indispensable.
Ces calculs sont généralement mis en œuvre sur des systèmes de traitement de données appelés clusters. Un cluster comprend typiquement un ensemble de nœuds interconnectés. Certains nœuds sont utilisés pour effectuer des tâches de calcul (nœuds de calcul), d'autres pour stocker des données (nœuds de stockage) et un ou plusieurs autres gèrent le cluster (nœuds d'administration). Chaque nœud est par exemple un serveur mettant en œuvre un système d'exploitation tel que Linux (Linux est une marque). La connexion entre les nœuds est, par exemple, réalisée à l'aide de liens de communication Ethernet ou Infiniband (Ethernet et Infiniband sont des marques).
La figure 1 illustre schématiquement un exemple d'une topologie 100 d'un cluster, de type fat-tree. Ce dernier comprend un ensemble de nœuds génériquement référencés 105. Les nœuds appartenant à l'ensemble 110 sont ici des nœuds de calcul tandis que les nœuds de l'ensemble 1 15 sont des nœuds de service (nœuds de stockage et nœuds d'administration). Les nœuds de calcul peuvent être regroupés en sous-ensembles 120 appelés îlots de calcul, l'ensemble 1 15 étant appelé îlot de service.
Les nœuds sont reliés les uns aux autres par des commutateurs
(appelés switch en terminologie anglo-saxonne), par exemple de façon hiérarchique. Dans l'exemple illustré sur la figure 1 , les nœuds sont connectés à des commutateurs 125 de premier niveau qui sont eux-mêmes reliés à des commutateurs 130 de deuxième niveau qui sont à leur tour reliés à des commutateurs 135 de troisième niveau.
Comme illustré sur la figure 2, chaque nœud comprend généralement un ou plusieurs microprocesseurs, des mémoires locales ainsi qu'une interface de communication. Plus précisément, le nœud 200 comporte ici un bus de communication 202 auquel sont reliés :
- des unités centrales de traitement ou microprocesseurs 204 (ou
CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ;
- des composants de mémoire vive 206 (RAM, acronyme de
Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution de programmes (comme illustré, chaque composant de mémoire vive peut être associé à un microprocesseur) ; et,
- des interfaces de communication 208 adaptées à transmettre et à recevoir des données.
Le nœud 200 dispose en outre ici de moyens de stockage interne
212, tels que des disques durs, pouvant notamment comporter le code exécutable de programmes.
Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le nœud 200 ou reliés à lui. Les microprocesseurs 204 commandent et dirigent l'exécution des instructions ou portions de code logiciel du ou des programmes. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple un disque dur, sont transférés dans la mémoire vive 206.
Il est observé ici que les performances d'un cluster sont directement liées à la qualité des routes permettant le transfert de données entre les nœuds, établies via des liens de communication. De façon générale, des liens de communication physiques sont établis entre les nœuds et les commutateurs lors de la configuration matérielle d'un cluster, les routes de communication étant elles-mêmes déterminées dans une phase d'initialisation à partir d'une définition des connexions devant êtres établies entre les nœuds. Selon la technologie de communication mise en œuvre, la configuration des routes peut être statique ou dynamique.
A titre d'illustration, la technologie Infiniband permet, dans un cluster, une configuration statique des routes. Cette configuration utilise des tables statiques de routage (ou LFT, sigle de Linear Forwarding Table en terminologie anglo-saxonne) dans chaque commutateur. Lorsque cette technologie est mise en œuvre, un algorithme de routage tel que les algorithmes connus sous les noms de FTree, MINHOP, UPDN et LASH peut être utilisé.
De façon simplifiée, l'algorithme FTree détermine des routes de telle sorte que celles-ci soient réparties autant que possible à travers les liens de communication existants. A ces fins, lors du routage d'un réseau de communication entièrement connecté selon une architecture de type fat-tree, chaque nœud du réseau est considéré comme ayant une même importance. Ainsi, lorsqu'une route est établie entre deux nœuds d'un même lien, le nombre de routes utilisant ce lien, appelé la charge du lien, est augmenté de un. Lorsque l'algorithme de routage cherche à établir une nouvelle route et que plusieurs possibilités se présentent, il compare les niveaux de charge associés aux liens sur lesquels sont basées ces possibilités et choisit celle dont les liens ont le niveau de charge le plus faible.
La qualité de routage peut être exprimée en termes de nombre de routes par lien.
La figure 3, comprenant les figures 3a à 3e, illustre ce principe de routage dans un commutateur 300 lors d'une phase d'initialisation d'un cluster comprenant ce commutateur.
Le commutateur 300 a ici quatre liens de communication d'entrée, notés 310-1 à 310-4, reliant le commutateur 300 à des entrées 305-1 à 305-4 et deux liens de communication de sortie, notés 320-1 et 320-2, reliant le commutateur 300 à des sorties 315-1 et 315-2. Avant l'initialisation, aucun des liens 310-1 à 310-4, 320-1 et 320-2 ne comprend de route. Les niveaux de charge associés à ces liens sont donc nuls comme illustré sur la figure 3a à côté de chaque lien. Puis, lorsqu'une route doit être établie entre l'entrée 305-1 et une sortie du commutateur 300, le lien 310-1 (le seul pouvant être utilisé) est sélectionné ainsi que le lien 320-1 (les niveaux de charge associés aux liens 320-1 et 320-2 étant égaux, ici à zéro, le premier lien est sélectionné). Les niveaux de charge associés aux liens 310-1 et 320-1 sont alors incrémentés de un pour indiquer que ces liens mettent en œuvre une route supplémentaire, comme illustré sur la figure 3b.
De même, lorsqu'une route doit être établie entre l'entrée 305-2 et une sortie du commutateur 300, le lien 310-2 (le seul pouvant être utilisé) est sélectionné ainsi que le lien 320-2 (le niveau de charge associé au lien 320-1 étant égal à un et le niveau de charge associé au lien 320-2 étant égal à zéro, ce dernier lien est sélectionné). Les niveaux de charge associés aux liens 310-2 et 320-2 sont alors incrémentés de un pour indiquer que ces liens mettent en œuvre une route supplémentaire, comme illustré sur la figure 3c. De façon similaire, lorsqu'une route doit être établie entre l'entrée 305-3 et une sortie du commutateur 300, le lien 310-3 (le seul pouvant être utilisé) est sélectionné ainsi que le lien 320-1 (les niveaux de charge associés aux liens 320-1 et 320-2 étant égaux, le premier lien est sélectionné). Les niveaux de charge associés aux liens 310-3 et 320-1 sont alors incrémentés de un pour indiquer que ces liens mettent en œuvre une route supplémentaire, comme illustré sur la figure 3d.
Enfin, lorsqu'une route doit être établie entre l'entrée 305-4 et une sortie du commutateur 300, le lien 310-4 (le seul pouvant être utilisé) est sélectionné ainsi que le lien 320-2 (le niveau de charge associé au lien 320-1 étant égal à deux et le niveau de charge associé au lien 320-2 étant égal à un, ce dernier lien est sélectionné). Les niveaux de charge associés aux liens 310-4 et 320-2 sont alors incrémentés de un pour indiquer que ces liens mettent en œuvre une route supplémentaire, comme illustré sur la figure 3e. Lorsque toutes les routes entre les nœuds ont été établies, les tables statiques de routage des commutateurs sont mises à jour.
Cependant, alors que ces algorithmes de routage donnent de bons résultats, ces derniers ne sont pas optimaux.
L'invention permet de résoudre au moins un des problèmes exposés précédemment.
L'invention a ainsi pour objet un procédé pour ordinateur de routage adaptatif pseudo-dynamique pour l'exécution d'une application dans un cluster comprenant une pluralité de noeuds, des liens de communication statiques reliant des nœuds de ladite pluralité de nœuds, ledit routage étant basé sur des niveaux de charge associés auxdits liens de communication, ce procédé comprenant les étapes suivantes,
- identification d'au moins deux nœuds dudit cluster devant être utilisés pour exécuter ladite application, une connexion devant être établie entre lesdits au moins deux nœuds identifiés ;
- détermination d'au moins une route connectant lesdits au moins deux nœuds identifiés selon lesdits liens de communication, ladite au moins une route étant déterminée selon lesdits au moins deux nœuds identifiés, une pluralité de liens de communication desdits liens de communication et au moins un niveau de charge associé à chaque lien de communication de ladite pluralité de liens de communication, et sélection d'une route déterminée ;
- estimation d'une valeur de poids associé à chaque lien de communication de ladite route sélectionnée, ladite valeur de poids étant au moins partiellement estimée selon au moins une indication de performance d'une exécution antérieure de ladite application ; et,
- incrémentation d'un niveau de charge associé à chaque lien de communication comprenant ladite route sélectionnée selon ledit poids estimé.
Le procédé selon l'invention permet ainsi d'améliorer le routage d'un cluster pour l'exécution d'une application en prenant en compte des informations relatives à une exécution antérieure de l'application. Le procédé comprend en outre, avantageusement, une étape de détermination de ladite au moins une indication de performance d'une exécution antérieure de ladite application.
Selon un mode de réalisation particulier, ladite étape de détermination de ladite au moins une indication de performance comprend une étape d'obtention de valeurs initiale et finale d'au moins un compteur de performance, ladite indication de performance étant basée sur une variation de valeur dudit au moins un compteur de performance.
Le procédé selon l'invention est ainsi particulièrement simple à mettre en oeuvre en ce qu'il utilise des informations généralement disponibles dans un cluster visant des caractéristiques d'exécution d'applications.
Le procédé comprend en outre, de préférence, une étape d'obtention du schéma de routage lié à l'exécution de ladite application afin de permettre l'établissement d'un lien entre une application et des ressources matérielles mises en œuvre pour l'exécution de cette application.
Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de détermination d'un niveau de priorité d'exécution de ladite application, ladite étape d'estimation d'une valeur de poids associé à ladite route sélectionnée selon au moins une indication de performance d'une exécution antérieure de ladite application étant effectuée en réponse à ladite étape de détermination d'un niveau de priorité de ladite application. Ainsi, l'optimisation du routage d'un cluster est notamment basée sur la priorité d'exécution des applications devant être exécutées.
De façon avantageuse, le procédé comprend en outre une étape préalable visant à déterminer si un nouveau routage lié à l'exécution de ladite application doit être effectué. Un nouveau routage peut ainsi être effectué de façon sélective afin qu'il ne soit effectué que sous certaines conditions, en particulier que si ce nouveau routage présente un intérêt réel.
Selon un mode de réalisation particulier, le procédé comprend en outre une étape de mise à jour d'au moins une table de routage statique, ladite au moins une table de routage statique étant associée à au moins un commutateur dudit cluster, ledit au moins un commutateur reliant au moins deux nœuds dudit cluster. Le procédé selon l'invention peut ainsi être mis en uvre dans des clusters utilisant des technologies telles qu'lnfiniband.
Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de lancement de l'exécution de ladite application.
L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en œuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur ainsi qu'un moyen de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé précédemment.
Les avantages procurés par ce programme d'ordinateur et ce moyen de stockage d'informations sont similaires à ceux évoqués précédemment.
D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels :
- la figure 1 illustre un exemple de topologie d'un cluster ;
- la figure 2 illustre un exemple d'architecture d'un nœud d'un cluster ;
- la figure 3, comprenant les figures 3a à 3e, illustre le principe de routage, selon un algorithme de type FTree, dans un commutateur lors d'une phase d'initialisation d'un cluster comprenant ce commutateur ;
- la figure 4 représente un diagramme de séquence simplifié illustrant le rôle de modules logiciels intervenant dans la mise en œuvre de l'invention ;
- la figure 5, comprenant les figures 5a à 5d, illustre un exemple du principe de routage avec des poids, dans un commutateur, lors d'une phase d'initialisation d'un cluster comprenant ce commutateur ; et,
- la figure 6, comprenant les figures 6a et 6b, illustre certaines étapes d'un exemple d'algorithme pour router ou re-router un cluster comprenant des liens de communication statiques. Il a été observé que si les routes d'un réseau de communication dans un cluster sont de même nature, la nature des nœuds reliés par ces routes joue un rôle vis-à-vis du volume de données échangé et donc de la bande passante utilisée. Ainsi, par exemple, une route connectant deux nœuds de calcul utilise généralement moins de bande passante qu'une route connectant un nœud de calcul à un nœud de stockage.
De même, les routes utilisées pour connecter des nœuds de calcul utilisés pour effectuer une même tâche ont généralement besoin d'une bande passante plus élevée que celles utilisées pour connecter des nœuds de calcul utilisés pour effectuer des tâches différentes.
Il est rappelé ici qu'une tâche ou un processus, aussi appelée job en terminologie anglo-saxonne, est une application définie, en particulier, dans un temps et un lieu. Elle est généralement exécutée par un ensemble de nœuds après avoir été lancée par un gestionnaire de tâches, aussi appelé batch manager, resource manager ou job manager en terminologie anglo-saxonne. Le gestionnaire de tâches a notamment pour objet de déterminer le nombre de nœuds nécessaires à l'exécution d'une tâche, de vérifier qu'il existe un nombre de nœuds disponibles suffisant pour exécuter la tâche, en tenant compte, le cas échéant, de contraintes particulières, notamment de contraintes déterminées par un utilisateur, d'allouer des nœuds à l'exécution de la tâche et de lancer son exécution.
Certaines applications sont exécutées périodiquement, par exemple tous les jours. En outre, des priorités peuvent être assignées à des applications pour favoriser leur exécution par rapport à l'exécution d'autres applications. Ainsi, par exemple, une priorité élevée peut être associée à une application de prévision météorologique afin d'obtenir des résultats à une heure donnée.
Cependant, s'il est possible de déterminer des règles générales d'assignation de poids à des routes pour améliorer le routage d'un cluster, l'efficacité d'un routage est aussi liée aux applications mises en œuvre.
L'invention vise donc l'obtention d'informations précises de topologie et de performances liées à une application mise en œuvre par des nœuds d'un cluster selon une attribution effectuée par un module routage pour permettre, le cas échéant, une amélioration de cette attribution lors d'une mise en œuvre ultérieure de cette même application. Ces informations peuvent notamment être obtenues à partir de données statistiques issues des dispositifs d'interconnexion utilisés, par exemple de commutateurs de type Infiniband. Le traitement de ces données permet d'établir un profil d'application pouvant être utilisé pour améliorer une opération de routage selon des mesures réelles.
Il est observé ici que si l'invention a notamment pour objet d'améliorer le routage lié à une application lorsque cette dernière est réexécutée, re-router une application avant son exécution nécessite du temps et représente donc un coût. Il est donc avantageux de n'effectuer une opération de routage que si l'application visée a un niveau de priorité élevé.
La figure 4 représente un diagramme de séquence simplifié illustrant le rôle de modules logiciels intervenant dans la mise en œuvre de l'invention.
Outre des modules logiciels liés à une première et une seconde applications 400 et 405, les modules logiciels mis en œuvre sont ici le gestionnaire de tâches 410 (JobManager), le module d'optimisation 415 selon l'invention appelé ici RAKI (sigle de Routing Advanced Knowledge for Interconnect technlogies en terminologie anglo-saxonne) et le gestionnaire d'administration et de réseau 420 (par exemple le module connu sous le nom d'openSM).
Il est supposé ici que la première application (application 1) n'a pas un niveau de priorité élevé tandis que la seconde application [application 2) a un niveau de priorité élevé (application privilégiée au sens de l'invention).
Le gestionnaire de tâches a notamment pour objet de gérer les priorités, les queues et les charges dans le cluster. Il s'agit, par exemple, de l'un des modules logiciels connus sous les noms de PBS Professional (PBS est une marque), LSF (sigle de Load Sharing FacHity en terminologie anglo-saxonne) et Slurn (acronyme de Simple Linux Utility for Resource Management en terminologie anglo-saxonne).
Le module d'optimisation selon l'invention a notamment pour objet d'identifier les applications devant être considérées comme privilégiées, de construire des profils de performances pour les applications considérées comme privilégiées et d'appliquer des techniques de renforcement d'apprentissage pour aider à améliorer le retour sur investissement d'un cluster, c'est-à-dire ici d'améliorer les performances du cluster pour l'exécution d'applications données en optimisant le routage.
Le module d'optimisation permet de mémoriser des caractéristiques d'applications, par exemple leur nom, leur taille et l'historique de leurs exécutions. Il permet également d'associer des caractéristiques de routage des composants du cluster, nécessaires à l'exécution de l'application, selon les caractéristiques de l'application visée. Le module d'ajustement permet en outre de mémoriser un profil de performance créé durant l'exécution d'une application et permettant d'améliorer le routage des composants du cluster nécessaires à l'exécution de l'application. De telles informations peuvent, par exemple, être mémorisées dans une base de données.
Le module d'optimisation décide s'il est avantageux ou non de rerouter les composants du cluster nécessaires à l'exécution d'une application, notamment en ajustant des poids de liens.
Le gestionnaire d'administration et de réseau détermine les schémas de routage devant être utilisés et les déploie via, par exemple, des tables de routage. Pour déterminer des schémas de routage, des poids de connexions sont utilisés comme décrit ci-après.
Une première étape représentée sur la figure 4 consiste au démarrage ou à l'activation du module d'optimisation selon l'invention (RAKI). Cette étape est ici initiée (étape 425) par le gestionnaire d'administration et de réseau 420 à l'aide d'une commande appelée ici startRAKIQ. Dans une étape suivante (étape 430), une interrogation est émise par le gestionnaire de tâches 410 pour déterminer si le module d'optimisation RAKI est opérationnel. Cette interrogation est ici réalisée à l'aide d'une commande appelée RAKI?(). Selon un mode de réalisation particulier, l'absence de réponse dans un délai prédéterminé signifie que le module d'optimisation RAKI n'est pas opérationnel.
Lorsqu'une application doit être exécutée, une commande, typiquement appelée scheduleQ, est adressée au gestionnaire de tâches afin que ce dernier réserve des ressources pour l'exécution de cette application. Ainsi, par exemple, lorsque l'application 1 (400) doit être exécutée, une commande scheduleQ est adressée au gestionnaire de tâches 410 (étape 435). En fonction des ressources disponibles et de la priorité associée à l'application 1 , le gestionnaire de tâches va planifier l'exécution de cette application.
Cependant, conformément à l'invention, le gestionnaire de tâches détermine si l'application 1 est privilégiée au sens de l'invention, c'est-à-dire si elle doit faire l'objet d'une analyse particulière et, le cas échéant, d'un nouveau routage. A ces fins, le gestionnaire de tâches adresse une commande, appelée ici privileged?(), au module d'optimisation RAKI (étape 440).
L'application 1 ne devant pas être considérée comme une application privilégiée au sens de l'invention, une réponse négative est reçue du module d'optimisation RAKI (étape 445) ou aucune réponse n'est reçue en réponse à la commande privileged?() (selon un mode de réalisation particulier, l'absence de réponse dans un délai prédéterminé signifie que l'application ne doit pas être considérée comme privilégiée). Dans ce cas, son exécution est gérée de façon standard par le gestionnaire de tâches.
De façon similaire, lorsque l'application 2 (405) doit être exécutée, une commande scheduleQ est adressée au gestionnaire de tâches 410 (étape 450). A nouveau, le gestionnaire de tâches interroge le module d'optimisation RAKI à l'aide d'une commande privileged?() (étape 455) pour déterminer si cette application doit être considérée comme privilégiée au sens de l'invention. L'application 2 étant considérée comme telle, une réponse en ce sens est adressée au gestionnaire de tâches (étape 460).
Une commande appelée ici CountersPicQ est alors adressée par le module d'optimisation RAKI au gestionnaire de tâches (étape 465) afin de déterminer l'état d'indicateurs de dispositifs d'interconnexions utilisés, c'est-à- dire de prendre une photographie de l'état de ces dispositifs avant l'exécution de l'application 2. Typiquement, les indicateurs utilisés sont des compteurs de volume du trafic entre chaque paire de ports des dispositifs et des compteurs de blocage de données entre ces paires de ports. Ces états sont, de préférence, transmis au module d'optimisation RAKI (étape 470) où ils sont mémorisés. Parallèlement, avant ou après, le module d'optimisation RAKI détermine s'il existe un profil pour l'application devant être exécutée, ici l'application 2, et, dans l'affirmative, détermine s'il convient de re-router le cluster, c'est-à-dire reconfigurer des commutateurs du cluster. Dans ce cas, une commande, appelée ici routePrivilegedQ est transmise au gestionnaire d'administration et de réseau 420 (étape 475) afin que ce dernier re-route l'application et transmette les résultats aux tables de routage mises en œuvre. S'il n'est pas nécessaire de re-router l'application, cette dernière est exécutée selon la configuration précédemment définie.
L'application 2 est alors exécutée.
A la fin de son exécution (étape 480), le gestionnaire de tâches réexécute la fonction précédemment appelée par la commande CountersPicQ pour déterminer l'état d'indicateurs de dispositifs d'interconnexions utilisés, c'est-à-dire de prendre une photographie de l'état de ces dispositifs après l'exécution de l'application 2. A nouveau, ces états sont, de préférence, transmis au module d'optimisation RAKI (étape 485) où ils sont mémorisés. Ainsi, en comparant les états de ces indicateurs avant et après l'exécution de l'application 2, il est possible de caractériser les performances de son exécution.
Ainsi, lorsqu'une application est invoquée par un utilisateur pour être exécutée, il est tout d'abord déterminé si cette application doit être considérée comme privilégiée (au sens de l'invention) ou non. Si l'application ne doit pas être considérée comme privilégiée, elle est traitée de façon standard, sans rerouter le cluster. Déterminer si une application doit être considérée comme privilégiée peut être basé sur des heuristiques telles que le type de l'application, le nombre de nœuds utilisés, le trafic généré dans le cluster et les ressources disponibles du cluster.
Si une application doit être considérée comme privilégiée, des actions sont invoquées lorsqu'elle est lancée. Tout d'abord, les valeurs de compteurs de performance des commutateurs impliquées dans l'exécution de cette application sont mémorisées. Par ailleurs, un profil de cette application est obtenu d'une base de données. Un tel profil représente ici un schéma de routage et le trafic associé déterminé lors de l'exécution précédente de l'application. Ce profil permet notamment d'affiner le routage de l'application en assignant et en adaptant des poids à des routes connectant certains nœuds d'un cluster afin de biaiser l'algorithme de routage utilisé vis-à-vis de certaines routes et, par conséquent, d'optimiser l'allocation de bande passante à chaque route dans les liens de communication mis en œuvre.
Comme indiqué précédemment, un profil d'application est déterminé à partir du schéma de routage et d'informations issues de compteurs de performance. Un tel profil est construit, puis ajusté, en deux temps, l'un étant effectué avant l'exécution de l'application et l'autre après. Le pseudo-code donné en annexe (pseudo-code 1) illustre un exemple particulièrement simple d'instructions pour évaluer un tel profil.
Dans une première phase mise en œuvre avant l'exécution de l'application, le schéma de routage est déterminé et les valeurs des compteurs de performance des commutateurs impliqués sont mémorisées à l'aide d'une fonction appelée populate. A ces fins, un arbre de nœuds (tree) est établi à partir d'une liste de nœuds (elected nodes) accessible via le gestionnaire de tâches. Connaissant la topologie des connexions physiques, il est possible d'associer à l'arbre de nœuds construits les ports utilisés (port_tree). En utilisant une approche d'analyse large (appelée large parsing approach en terminologie anglo-saxonne) visant tous les ports interférants des commutateurs mis en œuvre pour l'exécution de l'application, il est possible de tenir compte des tâches annexes, aussi appelées alien jobs, afin d'isoler le trafic issu de ces tâches interférantes.
Le volume de données ayant transité {port volume) et le volume de données bloquées (port blocked) sont alors mémorisés pour chaque port identifié dans l'arbre de nœuds déterminé.
Dans une seconde phase, après l'exécution de l'application, une fonction, appelée profile, est appelée. Elle a notamment pour objet de déterminer le volume de données ayant transité (port volume) et le volume de données bloquées (port blocked) pour chaque port identifié dans l'arbre de nœuds déterminé, durant l'exécution de l'application. Cette estimation est obtenue en retranchant le volume mémorisé de données ayant transité (port_tree[i]. volume) et le volume mémorisé de données bloquées (port_tree[i].blocked) au volume de données ayant transité (port volume) et au volume de données bloquées (port blocked), mesurés à la fin de l'exécution de l'application, pour chaque port identifié dans l'arbre de nœuds.
Les valeurs obtenues sont alors ajustées (port_tree statistic adj.) pour tenir compte du trafic généré par l'exécution de tâches annexes. Un tel ajustement peut être réalisé de façon statistique selon le trafic mesuré sur les ports interférants des commutateurs mis en œuvre pour l'exécution de l'application. Les poids devant être utilisés pour router le cluster afin d'exécuter l'application sont alors ajustés selon les valeurs obtenues. Un tel ajustement consiste par exemple à augmenter les valeurs des poids associés à des liens correspondant à des valeurs de trafic importantes et à diminuer les valeurs des poids associés à des liens correspondant à des valeurs de trafic faibles. A ces fin, des seuils peuvent être utilisés.
Les informations permettant d'ajuster les poids devant être utilisés pour router le cluster afin d'exécuter l'application sont alors stockées, de préférence après avoir été compressées, pour pouvoir être utilisées ultérieurement, typiquement lorsque l'application sera exécutée à nouveau.
L'assignation et, le cas échéant, l'ajustement d'un poids donné à certains types de routes ou à certaines routes permet de biaiser le routage en faveur de certaines routes qui ont des besoins spécifiques en termes de bande passante. Ainsi, en utilisant un poids dont la valeur est élevée pour une route connectant deux nœuds, il est possible d'allouer une bande passante plus élevée à la communication de données entre ces nœuds.
L'assignation de poids à des routes durant une phase de routage peut être réalisée à travers une API (sigle d'Application Program Interface en terminologie anglo-saxonne).
L'assignation de poids lors de la phase de routage peut notamment être déterminée en fonction du type des nœuds, du ou des groupes auxquels ils appartiennent ou en fonction des tâches exécutées par ces nœuds, de façon distincte. Comme décrit précédemment, ces poids peuvent être modifiés pour tenir compte d'informations de performance.
Pour assigner un poids en fonction du type des n uds ou du ou des groupes auxquels ils appartiennent, un fichier de poids, appelé weight_fHe, peut être utilisé. Il permet ici d'assigner des poids à des routes définies par des identifiants de port, appelés port GUIDs (sigle de Globally Unique IDentifiers en terminologie anglo-saxonne) dans un réseau de communication de type Infiniband.
Un tel fichier est analysé avant la phase de routage. Il contient une liste des éléments communicants du réseau de communication, typiquement des nœuds, regroupés par type, et une liste de poids pour des couples formés entre ces groupes. Lors de leur analyse, ces poids peuvent être utilisés pour remplir une matrice qui décrit l'incrément de niveau de charge devant être utilisé pour chaque lien de communication lors de la phase de routage. Par défaut, lorsque la valeur d'un poids pour une route connectant deux types de nœuds n'est pas définie, sa valeur est égale à un.
Les valeurs obtenues des poids peuvent alors être modifiées selon des informations d'ajustement associée à des applications et déterminées lors de l'exécution de ces applications.
Lorsqu'une route est établie à travers un ensemble de liens durant la phase de routage, le niveau de charge associé à chacun de ces liens est incrémenté de la valeur du poids lié aux types de nœuds entre lesquels la route est établie.
La figure 5, comprenant les figures 5a à 5d, illustre le principe de routage en fonction du type des nœuds ou du ou des groupes auxquels ils appartiennent, dans un commutateur 500, lors d'une phase d'initialisation d'un cluster comprenant ce commutateur.
Comme le commutateur 300 illustré sur la figure 3, le commutateur 500 a ici quatre liens de communication d'entrée, notés 510-1 à 510-4, reliant le commutateur 500 à des entrées 505-1 à 505-4 et deux liens de communication de sortie, notés 520-1 et 520-2, reliant le commutateur 500 à des sorties 515-1 et 515-2. Les entrées sont, par exemple, des sorties de n uds du réseau ou des sorties d'autres commutateurs.
Avant l'initialisation, aucun des liens 510-1 à 510-4, 520-1 et 520-2 ne comprend de route. Le niveau de charge associé à chacun de ces liens est donc nul comme illustré sur la figure 5a à côté de chaque lien. Puis, lorsqu'une route doit être établie entre l'entrée 505-1 et une sortie du commutateur 500, le lien 510-1 (le seul pouvant être utilisé) est sélectionné ainsi que le lien 520-1 (le même niveau de charge nul étant associé aux liens 520-1 et 520-2, le premier lien est sélectionné). Il est supposé ici que la route utilisant les liens 510-1 et 520-1 qui vient d'être établie a pour objet de connecter un nœud de calcul à un nœud de stockage. Par conséquent, si la valeur du poids d'une route connectant des nœuds de type calcul et stockage est 200, cette valeur est utilisée pour incrémenter le niveau de charge des liens 510-1 et 520-1 , comme illustré sur la figure 5b.
De même, lorsqu'une route doit être établie entre l'entrée 505-2 et une sortie du commutateur 500, le lien 510-2 (le seul pouvant être utilisé) est sélectionné ainsi que le lien 520-2 (un niveau de charge égal à 200 étant associé au lien 520-1 et un niveau de charge nul étant associé au lien 520-2, ce dernier, dont le niveau de charge a la valeur la plus faible, est sélectionné).
A nouveau, s'il est admis que la route utilisant les liens 510-2 et 520-
2 qui vient d'être établie a pour objet de connecter un nœud de service à un nœud de calcul et que la valeur du poids d'une route connectant des nœuds de type service et calcul est 99, cette valeur est utilisée pour incrémenter le niveau de charge des liens 510-2 et 520-2, comme illustré sur la figure 5c.
De façon similaire, lorsqu'une route doit être établie entre l'entrée
505-3 et une sortie du commutateur 500, le lien 510-3 (le seul pouvant être utilisé) est sélectionné ainsi que le lien 520-2 (un niveau de charge égal à 200 étant associé au lien 520-1 et un niveau de charge égal à 99 étant associé au lien 520-2, ce dernier, dont le niveau de charge a la valeur la plus faible, est sélectionné). S'il est admis que la route utilisant les liens 510-3 et 520-2 qui vient d'être établie a pour objet de lier deux nœuds de calcul et que la valeur du poids d'une route connectant des nœuds de type calcul est 1 , cette valeur est utilisée pour incrémenter le niveau de charge des liens 510-3 et 520-2, comme illustré sur la figure 5d.
Un extrait de fichier de poids est présenté en annexe (extrait 1 ). Il illustre un exemple de groupage de nœuds d'un réseau de communication, chaque groupe représentant ici des types distincts de nœuds, ainsi que l'affectation initiale de poids à des couples de type de nœuds.
Selon cet exemple, les nœuds ayant pour port GUIDs les valeurs 0x100901 , 0x101201 , 0x100903, 0x1 101203, 0x101207, 0x100909 et 0x101209 sont des nœuds de type « storage », c'est-à-dire des nœuds de stockage. La définition d'un type de nœuds est ici réalisée à l'aide de l'indication DEF suivie du nom du groupe lui-même suivi de la liste des port GUIDs correspondants, placée entre accolades. De même, les nœuds ayant pour port GUIDs les valeurs 0x100905, 0x101205 et 0x 00907 sont des nœuds de type « admin », c'est-à-dire des nœuds d'administration. De façon similaire, les nœuds ayant pour port GUIDs les valeurs 0x10090b, 0x010120b, 0x10090d, 0x10120d, 0x10090f, 0x10120f, 0x10091 1 , 0x101211 , 0x100913, 0x101213, 0x100915, 0x100917, 0x101217 et 0x100919 sont des nœuds de type « compute », c'est-à-dire des nœuds de calcul. Par ailleurs, un type de nœuds appelé « service » regroupe tous les nœuds de types « storage » et « admin ».
Les poids sont ici donnés en fin de fichier. La syntaxe pour définir le poids d'une route connectant deux nœuds utilise ici la formulation « ID1 => ID2 poids » où ID1 est le port GUID ou le groupe du nœud d'origine, ID2 est le port GUID ou le groupe du nœud de destination et poids est la valeur devant être utilisée lors du calcul de la charge d'un lien. Selon cet exemple, une valeur de poids égale à 200 est ajoutée à toutes les routes allant d'un nœud de calcul, nœud de type « compute », vers un nœud de stockage, noeud de type « storage » (« compute => storage 200 »). De façon similaire, une valeur de poids égale à 99 est ajoutée à toutes les routes allant d'un nœud de service, nœud de type « service », vers un nœud de calcul, nœud de type « compute » (« service => compute 99 »). De même, une valeur de poids égale à 200 est ajoutée à toutes les routes allant d'un nœud d'administration (nœud de type « admin ») vers un nœud de stockage, noeud de type « storage » (« admin => storage 200 »).
Naturellement, d'autres poids initiaux peuvent être définis. De même, une syntaxe différente peut être utilisée. Par ailleurs, si, selon les exemples donnés précédemment, les routes sont considérées comme étant directionnelles, le niveau de charge associé à une route peut être le même que celui associé à la route inverse comme si les routes étaient bidirectionnelles.
Un tel routage peut être effectué lors de l'initialisation du cluster ou être effectué conjointement à un re-routage lié à l'exécution d'une application.
Avant de lancer l'exécution d'une application, une liste des identifiants des nœuds alloués à l'exécution de cette application est transmise à un module logiciel de gestion de poids intra-tâche durant une étape appelée prologue de la tâche (ou job prologue en terminologie anglo-saxonne). Cette liste est établie par le gestionnaire de tâches avant de lancer l'application.
Le module de gestion de poids intra-tâche associe alors un identifiant de tâche aux identifiants de nœuds appartenant à la liste reçue et établit, de préférence, une correspondance entre ces identifiants de nœuds et des informations mémorisées dans une base de données, notamment des identifiants de port, ou port GUIDs, afin d'établir une correspondance entre un identifiant de tâche et des port GUIDs. Un poids ayant une valeur particulière est alors assigné à chaque couple de port GUIDs associés à un même identifiant. Ainsi, lors du routage, lorsqu'une route est créée via un ensemble de liens de communication, le niveau de charge de ces liens est incrémenté d'une valeur égale à ces poids.
A titre d'illustration, si le niveau de charge d'un lien de communication utilisé pour établir une route entre deux nœuds n'étant pas alloués à l'exécution d'une même application est égale à un, le niveau de charge d'un lien de communication similaire utilisé pour établir une route entre deux nœuds alloués à l'exécution d'une même application peut être égale à dix. Ainsi, selon cet exemple, lorsqu'une route connectant des port GUIDs associés à un même identifiant de tâche est créée via un ensemble de liens de communication, le niveau de charge de chacun de ces liens de communication est incrémenté de dix.
Après avoir assigné des poids initiaux à des couples de nœuds, ou plus précisément, ici, à des couples de port GUIDs, la valeur de ces poids peut être ajustée selon des informations de performance préalablement calculées.
A titre d'illustration, la valeur du poids initial assigné à un couple de port GUIDs peut être incrémentée de dix si le ratio entre les volumes de données ayant transité et de données bloquées associés à ce couple est inférieur à un premier seuil prédéterminé et décrémentée de dix si ce ratio est supérieur à un second seuil prédéterminé. Il est ainsi possible d'ajuster le poids de chaque couple de port GUIDs.
Il est observé ici qu'une application est identifiée sur des nœuds dont la cartographie de tous les ports est connue puisqu'ils sont référencés dans le système d'administration du cluster. En outre, à un port d'un commutateur de premier niveau correspond un faible nombre de processus (ou jobs) typiquement un seul, parfois deux ou trois. Ainsi, le gestionnaire de processus peut, à partir des références de ports, déterminer le nom d'une application, par exemple en utilisant ses caractéristiques, notamment ses symboles. A ce nom d'application est associé un profile.
Un message peut alors être transmis à un gestionnaire réseau, appelé subnet manager en terminologie anglo-saxonne, pour re-router le cluster en fonction de l'application à exécuter.
Après le re-routage, la tâche est lancée. Puis, après son exécution, les valeurs des poids des couples de nœuds (ou de port GUIDs) alloués à l'exécution de cette tâche sont réinitialisés à leur valeur initiale, par exemple à la valeur une. Cette étape est appelée épilogue.
Lors de la phase de routage, les routes sont, de préférence, déterminées de façon ordonnée de telle sorte qu'une route associée à un poids dont la valeur est supérieure à celle d'un poids d'une autre route soit déterminée avant cette autre route afin d'optimiser le routage. Cet ordre peut être déterminé à partir de la matrice de poids et des groupes de nœuds permettant de les identifier en fonction de leur type et à partir d'une table de poids déterminée lors du lancement d'une tâche.
La figure 6, comprenant les figures 6a et 6b, illustre certaines étapes d'un exemple d'algorithme pour router ou re-router un cluster comprenant des liens de communication statiques.
La figure 6a illustre schématiquement un exemple d'algorithme mis en œuvre pour déterminer et sélectionner une route connectant deux nœuds ainsi que pour déterminer le niveau de charge d'un lien de communication après la sélection d'une route.
Une première étape (étape 600) a ici pour objet l'initialisation d'une matrice de poids permettant d'associer un poids à un couple de nœuds formé de deux nœuds (même poids quelque soit le sens de la route) ou d'un nœud d'origine et d'un nœud de destination (poids lié au sens d'une route) comme illustré en annexe (table 1). Cette matrice peut notamment être établie à partir d'un fichier de poids tel que celui présenté en annexe (extrait 1). Cette étape permet également de mémoriser les correspondances entre un identifiant d'un nœud avec son type et/ou un ou plusieurs groupes auxquels il appartient. Alternativement, la matrice de poids peut établir directement les poids associés à chaque couple de nœuds comme illustré partiellement en annexe (table 2).
La table 1 indique le poids devant être affecté à une route connectant un type de nœud source à un type de nœud destination tandis que la table 2 indique le poids devant être affecté à une route connectant un nœud source à un nœud destination.
Dans une étape suivante (étape 605), une paire de nœuds entre lesquels une route doit être établie est identifiée. La paire de nœuds comprend ici un nœud source et un nœud destination. Cette étape est une étape de base des algorithmes de routage pour permettre de définir les routes devant être établies. Les nœuds sont, par exemple, identifiés selon des port GUIDs.
Les étapes de détermination des routes possibles pour connecter ces nœuds identifiés et de sélection de la meilleure route sont alors réalisées (étape 610) selon un algorithme standard, par exemple selon l'algorithme FTree. Dans une étape suivante (étape 615), le type des nœuds identifiés ou le ou les groupes auxquels ils appartiennent sont obtenus selon les informations obtenues durant l'étape d'initialisation. Comme suggéré par l'utilisation de traits pointillés, cette étape est optionnelle car si, en particulier, la matrice de poids déterminée durant la phase d'initialisation associe directement des poids aux identifiants des nœuds, il n'est pas nécessaire, à ce stade, d'en déterminer le type et/ou de déterminer le ou les groupes auxquels ils appartiennent.
Le poids de la route connectant ces deux nœuds est alors estimé (étape 620). Cette estimation est basée sur les types des nœuds, le ou les groupes auxquels ils appartiennent et/ou leur identifiant, par exemple leur port GUID, ou sur des résultats de calcul précédemment effectués si les deux nœuds identifiés sont des nœuds de calcul alloués à l'exécution d'une même tâche.
Lorsque le poids est lié au type des nœuds identifiés ou à un ou plusieurs groupes auxquels ils appartiennent, il est, de préférence, directement donné par une lecture de la matrice de poids préalablement déterminée. Alternativement, un poids peut être estimé selon une référence mémorisée dans la matrice de poids selon une fonction ou une table prédéterminée. Les poids issus de la matrice de poids peuvent également être majorés ou minorés selon des circonstances particulières liées, par exemple, à la topologie du cluster et à la position des liens mis en œuvre par la route considérée.
Lorsque le poids est lié à la tâche effectuée par les nœuds identifiés, il est obtenu via une table de poids telle que celle présentée en annexe (Table 3).
Si la valeur du poids d'une route n'est pas égale à une valeur par défaut, elle est égale à une valeur déterminée en fonction d'un type de nœuds ou de groupes d'appartenance ou en fonction d'une allocation selon une tâche mais elle n'est, de préférence, pas égale à une valeur déterminée en fonction d'un type de nœuds ou de groupes d'appartenance et en fonction d'une allocation selon une tâche. Par conséquent, si cette valeur est déterminée à partir de la matrice de poids utilisée, il n'est pas toujours nécessaire de vérifier si le poids doit être modifié en fonction de l'allocation des nœuds identifiés.
La table 3 comprend ici trois colonnes correspondant respectivement à un port GUID source, un port GUID destination et une valeur de poids. Chaque ligne correspond à une route entre le nœud comprenant le port GUID source et le nœud comprenant le port GUID destination.
Le poids estimé est alors, le cas échéant, ajusté selon des informations de performance préalablement déterminées. A ces fins, les informations de performance liées à l'application visée sont obtenues. Le poids estimé est alors ajusté selon ces informations et des règles prédéterminées.
Le poids estimé et, éventuellement, ajusté pour la route sélectionnée est alors utilisé pour mettre à jour le niveau de charge associé aux liens de communication mis en œuvre par la route considérée (étape 625). Comme décrit précédemment, la valeur du poids estimé peut être ajoutée au niveau de charge des liens de communication mis en œuvre par la route considérée.
Comme suggéré par la flèche en trait pointillé, les étapes 605 à 625 peuvent être répétées pour établir de nouvelles routes. Typiquement, les étapes 605 à 625 sont répétées pour toutes les routes devant être établies dans le cluster dans lequel l'algorithme illustré sur la figure 6a est mis en œuvre.
La figure 6b illustre certaines étapes d'un exemple d'algorithme de calcul de poids de routes connectant deux nœuds lorsque ces nœuds sont alloués à l'exécution d'une même application.
Comme indiqué précédemment, lorsqu'une nouvelle application doit être lancée, le gestionnaire de tâches détermine si celle-ci peut être exécutée et, dans l'affirmative, établit la liste des nœuds alloués à l'exécution de celle-ci. Ainsi, lorsqu'une nouvelle application doit être exécutée (étape 630), le module de gestion de poids intra-tâche reçoit la liste des nœuds alloués à son exécution (étape 635). Un identifiant de tâche est associé à ces identifiants de nœuds.
Si aucune nouvelle application ne doit être exécutée, l'algorithme boucle sur lui-même jusqu'à ce qu'il soit stoppé. Un test est alors effectué (étape 640) pour déterminer si l'application devant être exécutée est, au sens de l'invention, une application devant être considérée comme privilégiée. Comme décrit précédemment, ce test peut être basé sur des heuristiques telles que le type de l'application, le nombre de n uds utilisés, le trafic généré dans le cluster et les ressources disponibles du cluster.
Si l'application devant être exécutée ne doit pas être considérée comme privilégiée, une instruction est transmise au gestionnaire de tâches pour permettre l'exécution de l'application considérée (étape 645). L'algorithme retourne alors à l'étape 630 dans l'attente d'une nouvelle application à exécuter.
Au contraire, si l'application devant être exécutée doit être considérée comme privilégiée, le schéma de routage est obtenu (étape 650) ainsi que les valeurs de performance (étape 655). Comme décrit précédemment, les valeurs de performance sont, par exemple, les valeurs de compteurs mis en œuvre dans les commutateurs devant être utilisés par l'application considérée.
Un test est alors effectué (étape 660) pour déterminer s'il convient d'effectuer un re-routage du cluster pour optimiser, en particulier, l'exécution de l'application devant être exécutée.
Un tel test peut notamment consister à comparer le nombre de nœuds alloués à l'application à exécuter avec le nombre de nœuds utilisés du cluster et/ou à comparer le temps estimé d'exécution de l'application avec et sans re-routage.
S'il n'est pas nécessaire d'effectuer un re-routage, une instruction est transmise au gestionnaire de tâches pour permettre l'exécution de l'application considérée (étape 665). L'algorithme retourne alors à l'étape 630 dans l'attente d'une nouvelle tâche à effectuer. Cependant, comme décrit précédemment, les valeurs de performance sont obtenues (étape 670) à la fin de l'exécution de l'application et le profil de l'application est estimé et mémorisé (étape 675).
L'estimation du profil de l'application, pour adapter des poids de connexions dans un cluster, peut simplement consister en la création d'un ensemble de valeurs de performance. Cependant, de façon avantageuse, le profile est estimé à partir de ces valeurs selon un algorithme standard de datamining permettant un apprentissage incrémental du profil de telle sorte que ce dernier converge vers une solution optimale.
Au contraire, si un re-routage doit être effectué, une étape suivante (étape 680) vise à établir un lien entre des identifiants de nœuds et des informations de routage telles que des port GUIDs. Cette étape est typiquement réalisée à partir de la liste d'identifiants de nœuds reçue du gestionnaire de tâches et de données de configuration généralement mémorisées dans une base de données. Cette étape permet notamment d'identifier des adresses sources et destinations de nœuds alloués à l'exécution d'une même tâche et entre lesquels des routes doivent être établies.
Enfin, un poids est attribué et ajusté (étape 685) à chaque route connectant une adresse de sortie d'un nœud alloué à la tâche devant être exécutée à une adresse d'entrée d'un nœud alloué à cette même tâche. De telles adresses sont, de préférence, des port GUIDs. Cette étape permet d'établir une table de poids telle que celle illustrée en annexe (Table 3).
Le cluster est alors re-routé selon un algorithme tel que celui décrit en référence à la figure 6a (référence A). Le nouveau schéma de routage est obtenu ainsi que les valeurs de performance correspondantes (étapes non représentées). Comme décrit précédemment, les valeurs de performance sont, par exemple, les valeurs de compteurs mis en œuvre dans les commutateurs devant être utilisés par l'application considérée.
Une instruction est ensuite transmise au gestionnaire de tâches pour permettre l'exécution de l'application considérée (étape 665). L'algorithme retourne alors à l'étape 630 dans l'attente d'une nouvelle tâche à effectuer. A nouveau, comme décrit précédemment, les valeurs de performance sont obtenues (étape 670) à la fin de l'exécution de l'application et le profil de l'application est estimé et mémorisé (étape 675).
Il est observé que l'algorithme décrit en référence à la figure 6 peut, par exemple, être mis en œuvre dans un dispositif dont l'architecture est similaire à celle décrite en référence à la figure 2. Cet algorithme est typiquement mis en œuvre au niveau du gestionnaire de réseau s'exécutant sur un nœud d'administration.
Par ailleurs, il est observé que l'utilisation de poids dans un algorithme de routage est compatible avec un algorithme de gestion de qualité de service (appelé QoS, sigle de Quality of Service en terminologie anglo- saxonne). Il est rappelé ici que la gestion de qualité de service, typiquement basée sur des niveaux de service et des crédits associés à chaque route selon un concept de lien virtuel, permet de favoriser certaines routes en cas de contention du réseau. Cette gestion est donc indépendante du routage en lui- même. Ces deux approches sont donc complémentaires pour améliorer la transmission de données dans un cluster et ainsi améliorer les performances de ce dernier.
En outre, les informations de performance obtenues peuvent être affichées, sous forme graphique ou textuelle, pour permettre à un utilisateur d'analyser le routage d'une application.
Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente.
ANNEXE
IBs::RAKI::populate(context information):
tree - convert node in tree (elected_nodes);
port_tree - parse tree, list up and down ports (tree);
foreach port of port_tree:
port_tree[i]. olume <- get the port counter volume (port volume); port_tree[i].blocked <- get the port retry/blocked counter volume (port blocked);
IBs::RAKI::profile(context information):
foreach port of port_tree:
port_tree[i]. volume - port volume - port_tree[i]. volume; port_tree[i]. blocked - port blocked - port_tree[i]. blocked; port_tree statistic adj. with job's external ports (port_tree);
apply heuristic algorithm for weight adjustement (port_tree);
compress and store adjustement information (context information);
Pseudo-code 1 : évaluation d'un profil de performance
DEF storage {
0x100901
0x101201
0x100903
0x1 01203
0x101207
0x100909
0x101209
DEF admin {
0x100905
0x101205
0x100907 DEF service {
storage
admin
}
DEF compute {
0x10090b
0x10120b
0x10090d
0x10120d
0x10090f
0x10120f
0x1009 1
0x10121 1
0x100913
0x101213
0x100915
0x100917
0x101217
0x100919
}
compute => storage 200
service => compute 99
admin => storage 200
Extrait 1
Figure imgf000029_0001
Table 1
source/dest. 0x100901 0x101201 0x100903 ... 0x100919
0x100901 - 200 200 1
0x101201 200 - 1
0x100903 200 200 - 1
... - 100919 200 200 200 -
Table 2
Figure imgf000030_0001
Table 3

Claims

REVENDICATIONS
1. Procédé pour ordinateur de routage adaptatif pseudo-dynamique pour l'exécution d'une application dans un cluster comprenant une pluralité de nœuds, des liens de communication statiques reliant des nœuds de ladite pluralité de nœuds, ledit routage étant basé sur des niveaux de charge associés auxdits liens de communication, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes,
- identification (605) d'au moins deux nœuds dudit cluster devant être utilisés pour exécuter ladite application, une connexion devant être établie entre lesdits au moins deux nœuds identifiés ;
- détermination (610) d'au moins une route connectant lesdits au moins deux nœuds identifiés selon lesdits liens de communication, ladite au moins une route étant déterminée selon lesdits au moins deux nœuds identifiés, une pluralité de liens de communication desdits liens de communication et au moins un niveau de charge associé à chaque lien de communication de ladite pluralité de liens de communication, et sélection d'une route déterminée ;
- estimation (685) d'une valeur de poids associé à chaque lien de communication de ladite route sélectionnée, ladite valeur de poids étant au moins partiellement estimée selon au moins une indication de performance d'une exécution antérieure de ladite application ; et,
- incrémentation (625) d'un niveau de charge associé à chaque lien de communication comprenant ladite route sélectionnée selon ledit poids estimé.
2. Procédé selon la revendication 1 comprenant en outre une étape de détermination (675) de ladite au moins une indication de performance d'une exécution antérieure de ladite application.
3. Procédé selon la revendication 2 selon lequel ladite étape de détermination de ladite au moins une indication de performance comprend une étape d'obtention de valeurs initiale (655) et finale (670) d'au moins un compteur de performance, ladite indication de performance étant basée sur une variation de valeur dudit au moins un compteur de performance.
4. Procédé selon la revendication 2 ou la revendication 3 comprenant en outre une étape d'obtention (650) du schéma de routage lié à l'exécution de ladite application.
5. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de détermination (640) d'un niveau de priorité d'exécution de ladite application, ladite étape d'estimation d'une valeur de poids associé à ladite route sélectionnée selon au moins une indication de performance d'une exécution antérieure de ladite application étant effectuée en réponse à ladite étape de détermination d'un niveau de priorité de ladite application.
6. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape préalable visant à déterminer (660) si un nouveau routage lié à l'exécution de ladite application doit être effectué.
7. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de mise à jour d'au moins une table de routage statique, ladite au moins une table de routage statique étant associée à au moins un commutateur dudit cluster, ledit au moins un commutateur reliant au moins deux nœuds dudit cluster.
8. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de lancement de l'exécution de ladite application.
9. Programme d'ordinateur comprenant des instructions adaptées à la mise en œuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédentes lorsque ledit programme est exécuté sur un ordinateur.
10. Moyen de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 8.
PCT/FR2012/052090 2011-10-06 2012-09-19 Procédé de routage adaptatif pseudo-dynamique dans un cluster comprenant des liens de communication statiques et programme d'ordinateur mettant en oeuvre ce procédé WO2013050682A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1159019A FR2981236B1 (fr) 2011-10-06 2011-10-06 Procede de routage adaptatif pseudo-dynamique dans un cluster comprenant des liens de communication statiques et programme d'ordinateur mettant en oeuvre ce procede
FR1159019 2011-10-06

Publications (1)

Publication Number Publication Date
WO2013050682A1 true WO2013050682A1 (fr) 2013-04-11

Family

ID=47022994

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2012/052090 WO2013050682A1 (fr) 2011-10-06 2012-09-19 Procédé de routage adaptatif pseudo-dynamique dans un cluster comprenant des liens de communication statiques et programme d'ordinateur mettant en oeuvre ce procédé

Country Status (2)

Country Link
FR (1) FR2981236B1 (fr)
WO (1) WO2013050682A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3191950A1 (fr) * 2014-09-12 2017-07-19 Bull SAS Allocation de ressources
CN112929408A (zh) * 2021-01-19 2021-06-08 郑州阿帕斯数云信息科技有限公司 动态负载均衡方法及装置

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
DIEGO LUGONES, DANIEL FRANCO, EMILIO LUQUE: "Dynamic Routing Balancing On Infiniband Networks", JOURNAL OF COMPUTER SCIENCE & TECHNOLOGY, vol. 8, no. 2, July 2008 (2008-07-01), pages 104 - 110, XP002672839, Retrieved from the Internet <URL:http://journal.info.unlp.edu.ar/journal/journal23/papers/jcst-jul08-8.pdf> [retrieved on 20120402] *
GERMAN RODRÍGUEZ, RAMÓN BEIVIDE, CYRIEL MINKENBERG, JESÚS LABARTA, MATEO VALERO: "Exploring Pattern-aware Routing in Generalized Fat Tree Networks", INTERNATIONAL CONFERENCE ON SUPERCOMPUTING, 8 June 2009 (2009-06-08), Yorktown Heights, New York, pages 276 - 285, XP002673393, Retrieved from the Internet <URL:http://delivery.acm.org/10.1145/1550000/1542316/p276-rodriguez.pdf?ip=145.64.134.245&acc=ACTIVE%20SERVICE&CFID=75411749&CFTOKEN=33467343&__acm__=1333527934_e3dc4de0d39afc1fdb8687e0eef31ec6> [retrieved on 20120403] *
IZMAILOV R ET AL: "Administrative weight allocation for PNNI routing algorithms", HIGH PERFORMANCE SWITCHING AND ROUTING, 2001 IEEE WORKSHOP ON 29-31 MAY 2001, PISCATAWAY, NJ, USA,IEEE, 29 May 2001 (2001-05-29), pages 347 - 352, XP010542826, ISBN: 978-0-7803-6711-1 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3191950A1 (fr) * 2014-09-12 2017-07-19 Bull SAS Allocation de ressources
CN112929408A (zh) * 2021-01-19 2021-06-08 郑州阿帕斯数云信息科技有限公司 动态负载均衡方法及装置

Also Published As

Publication number Publication date
FR2981236A1 (fr) 2013-04-12
FR2981236B1 (fr) 2013-11-08

Similar Documents

Publication Publication Date Title
US10657106B2 (en) Method, computing device, and distributed file system for placement of file blocks within a distributed file system
US10853116B2 (en) Machine learning prediction of virtual computing instance transfer performance
CN106027643B (zh) 一种基于Kubernetes容器集群管理系统的资源调度方法
US20190312772A1 (en) Topology-aware provisioning of hardware accelerator resources in a distributed environment
Kim et al. CometCloud: An autonomic cloud engine
EP0715257B1 (fr) Outil d&#39;aide à la répartition de la charge d&#39;une application répartie
Feng et al. Topology-aware virtual network embedding based on multiple characteristics
CN110798517B (zh) 去中心化集群负载均衡方法、系统、移动终端及存储介质
US20140149493A1 (en) Method for joint service placement and service routing in a distributed cloud
EP2572478B1 (fr) Procede d&#39;optimisation de routage dans un cluster comprenant des liens de communication statiques et programme d&#39;ordinateur mettant en oeuvre ce procede
CN101873224A (zh) 一种云计算负载均衡方法和设备
US9184982B2 (en) Balancing the allocation of virtual machines in cloud systems
US20230053575A1 (en) Partitioning and placement of models
Liao et al. Live: learning and inference for virtual network embedding
EP2577920B1 (fr) Procédé de routage pseudo-dynamique dans un cluster comprenant des liens de communication statiques et programme d&#39;ordinateur mettant en oeuvre ce procédé
WO2013050682A1 (fr) Procédé de routage adaptatif pseudo-dynamique dans un cluster comprenant des liens de communication statiques et programme d&#39;ordinateur mettant en oeuvre ce procédé
US11102256B2 (en) System and method for dynamic cloud formations for stream computing
US8521747B2 (en) System and method for selectively consolidating applications to a machine using resource utilization data
He et al. Hidden Markov Model-based Load Balancing in Data Center Networks
Maia et al. Dataflasks: epidemic store for massive scale systems
Ayoubi et al. Multicast virtual network embedding in cloud data centers with delay constraints
WO2013088019A1 (fr) Procédé et programme d&#39;ordinateur de gestion de pannes multiples dans une infrastructure informatique comprenant des équipements à haute disponibilité
EP3572929B1 (fr) Procédé d`envoi de données, programme d`ordinateur et système associés
US11962467B2 (en) Managing heterogeneous cluster environment
Teyeb Integrated optimization in cloud environment

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

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

Country of ref document: EP

Kind code of ref document: A1