EP4298766A1 - Procédé de contrôle d'une grappe de noeuds esclave par une grappe de noeuds maître, dispositifs et programmes d'ordinateurs correspondants - Google Patents

Procédé de contrôle d'une grappe de noeuds esclave par une grappe de noeuds maître, dispositifs et programmes d'ordinateurs correspondants

Info

Publication number
EP4298766A1
EP4298766A1 EP22711083.0A EP22711083A EP4298766A1 EP 4298766 A1 EP4298766 A1 EP 4298766A1 EP 22711083 A EP22711083 A EP 22711083A EP 4298766 A1 EP4298766 A1 EP 4298766A1
Authority
EP
European Patent Office
Prior art keywords
cluster
slave
task
master
nodes
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
EP22711083.0A
Other languages
German (de)
English (en)
Inventor
Romuald CORBEL
Emile Stephan
Gaël FROMENTOUX
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
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 Orange SA filed Critical Orange SA
Publication of EP4298766A1 publication Critical patent/EP4298766A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/04—Network management architectures or arrangements
    • H04L41/044—Network management architectures or arrangements comprising hierarchical management structures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0893—Assignment of logical groups to network elements

Definitions

  • the field of the invention is that of cloud computing or “cloud computing”.
  • the invention relates to a solution allowing the orchestration of a plurality of clusters of nodes having to perform identical tasks in an identical manner although these different clusters of nodes are not co-located.
  • telecommunications networks have been using virtualized functions hosted in servers, or nodes, grouped together in clusters, or “clusters”, giving rise to cloud computing.
  • the [Fig. 1] presents in a simplified manner the architecture of a cluster of nodes 1 conforming to the Kubernetes solution.
  • the cluster of nodes 1 comprises a first node 10 called the management node, or "Kubernetes master", and N computing nodes, or "Kubernetes node", 11 ,, i e ⁇ 1, ..., N), N being a natural number.
  • the management node 10 comprises a controller 101, an API module (Application Programming interface or application programming interface) 102 and a so-called ETCD database 103 which consists of a dynamic register for configuring the calculation nodes 11 ,.
  • API module Application Programming interface or application programming interface
  • ETCD database 103 which consists of a dynamic register for configuring the calculation nodes 11 ,.
  • a calculation node 11 comprises M containers or "pods" 110 j , i ⁇ 1, ... , M), M being a natural integer.
  • Each container 110 j is endowed with resources allowing the execution of one or more tasks.
  • a task when executed contributes to the implementation of a network service or function, such as a Dynamic Host Configuration Protocol (DHCP) function for example.
  • DHCP Dynamic Host Configuration Protocol
  • cloud computing architectures are most often multi-site architectures in which the constituent nodes of clusters of nodes can be non-co-located.
  • a management node 10 and two calculation nodes II1, II2 of a cluster of nodes 1 are located on a site A while three other calculation nodes II3, II4, They are located on a remote site B .
  • a first solution consists in deploying a first cluster of nodes on the ground and a second cluster of nodes in one or more satellites in orbit.
  • the satellites being in continuous movement around the Earth, the cluster of nodes on board the satellites modifies its configuration in order to adapt to all the needs and constraints formulated by the different operators managing the telecommunication networks of the different countries flown over. .
  • These reconfiguration operations such as deploying another operating system, installing dependencies, deploying and then updating management and compute nodes, are time-consuming. Indeed, it takes approximately ten minutes for a complete deployment of this type, which occupies a very large part of the coverage period of a country by the satellite.
  • a second solution consists in deploying several management nodes 10 for the same cluster of nodes 1 on the ground and in one or more satellites.
  • such an architecture induces a latency time for the synchronization of the databases 103 embedded in each of the management nodes 10.
  • these databases 103 work together by means of a consensus algorithm, called RAFT.
  • This algorithm is based on the use of time delays which are sensitive to the latency introduced between each replication operation of the content of a database 103.
  • the databases 103 are very regularly updated in order to keep the database up to date. operating state of a cluster of nodes 1.
  • the distribution of the management nodes 10 between the ground and the satellites results in a lengthening of the reactivity of the management nodes of the cluster of nodes 1 which introduces service interruptions.
  • the invention meets this need by proposing a method for controlling a first cluster of nodes, called slave cluster, by a second cluster of nodes, called master cluster, a cluster of nodes comprising at least one computing node executing at least a task, said control method being implemented by said master cluster and comprising the following steps:
  • the two clusters of nodes are independent clusters of nodes, they behave from a functional point of view like a single and same cluster of nodes.
  • the master cluster and the slave cluster are linked and have identical behavior allowing proper execution of the required services or network functions.
  • the conditions of execution of the tasks by the master cluster and the slave cluster are identical because these two clusters being part of the same cloud computing architecture, it is important to ensure a coherent execution of the network functions between the different components. of the cloud computing architecture knowing that, for a given service or a given network function, certain tasks related to the provision of this service or this function will be carried out partly in the master cluster and partly in the slave cluster .
  • an execution condition can be a minimum memory capacity required for the execution of the task.
  • the effective memory capacity of the master cluster and the slave cluster can be different.
  • first cluster of nodes located for example on the ground
  • second cluster of nodes for example located in one or more satellites, or in any other vehicle in a fleet.
  • the first cluster can communicate with the second cluster, it takes control of it and transfers a configuration file to it allowing the second cluster to perform the required tasks.
  • the tasks executed by the master cluster being divided into a plurality of task groups, a task group comprising at least one task, the configuration file comprises an identifier of at least one group of tasks and the relative expected execution conditions of said group of tasks.
  • groups can for example include all the tasks to be executed to deliver a service or execute a network function.
  • Other groups can include tasks of the same nature, the tasks can also be grouped according to the types of resources they require for their execution.
  • Each group is then provided with an identifier and one or more sets of execution conditions.
  • control method also comprises the following steps:
  • each update of the configuration of the master cluster is dynamically deployed on the slave cluster thus ensuring that the master cluster and the slave cluster always have identical behavior.
  • the method further comprises a step of receiving a message indicating the failure of the update of the configuration by the slave cluster.
  • the master cluster can seek to take control of another slave cluster in order to be able to provide the services or the network functions required.
  • the control method further comprises, in a particular implementation, a step of receiving a message comprising information relating to the implementation, by the slave cluster, updating the configuration of at least one other slave cluster to which the slave cluster has transmitted a configuration file comprising the expected execution conditions of said task by said at least one computing node of said other slave cluster, said expected execution conditions of said task being identical to the current execution conditions of said task by at least one computing node of said master cluster.
  • the first slave cluster being unable to implement the configuration requested by the master cluster, it takes control of a second slave cluster. For this, the slave cluster behaves like the master cluster by transmitting a configuration file comprising a takeover request intended for the second slave cluster.
  • the master cluster is informed of this situation.
  • an intermediate device serves as a relay.
  • the method comprises a step of receiving a message transmitted by the intermediate equipment indicating the impossibility of transmitting a configuration file to said slave cluster.
  • the master cluster can seek to take control of another slave cluster in order to be able to provide the services or the network functions required via the intermediate equipment or not.
  • the latter comprises:
  • the master cluster When the master cluster is informed of the occurrence of an error at the level of the slave cluster, it tries to carry out a repair in order to ensure continuity of service.
  • control method may also comprise in certain embodiments:
  • the slave cluster regains its independence and can be used autonomously, that is to say without a master, or under the control of a new master, etc.
  • the invention also relates to a method for configuring a first cluster of nodes, called slave cluster, by a second cluster of nodes, called master cluster, a cluster of nodes comprising at least one computing node executing at least one task , said configuration method being implemented by said slave cluster and comprising the following steps:
  • the slave cluster informs the latter which can then seek to take control of a new slave cluster.
  • the configuration method also comprises the following steps:
  • the configuration of the slave cluster is dynamically updated and always operates identically to the master cluster.
  • the configuration method further comprises a step of sending a message indicating the failure of the update of the configuration intended for the master cluster.
  • the master cluster can seek to take control of another slave cluster in order to be able to provide the services or the network functions required.
  • the configuration method further comprises when the required resources are not available:
  • the first slave cluster being unable to implement the configuration requested by the master cluster, it takes control of a second slave cluster.
  • the slave cluster behaves like the master cluster by transmitting a configuration file comprising a takeover request intended for the second slave cluster.
  • the master cluster is informed of this situation.
  • the invention also relates to a node for managing a first cluster of nodes, called master cluster, capable of controlling a second cluster of nodes, called slave cluster, a cluster of nodes also comprising at least one computing node executing at least one task, said master cluster management node comprising means for: - receiving a request to take control of said slave cluster identifying at least one task intended to be executed by at least one computing node of said slave cluster,
  • the invention also relates to a node for managing a first cluster of nodes, called a slave cluster, capable of configuring said slave cluster, a cluster of nodes also comprising at least one computing node executing at least one task, said management node of the slave cluster comprising means for:
  • - receive, from a second cluster of nodes, called master cluster, a configuration file of said slave cluster comprising takeover parameters and expected execution conditions of said task by said at least one computing node of said cluster slave, said expected execution conditions of said task being identical to current execution conditions of said task by at least one computing node of said master cluster,
  • the invention relates to computer program products comprising program code instructions for implementing the methods as described above, when they are executed by a processor.
  • the invention also relates to a recording medium readable by a computer on which are recorded computer programs comprising program code instructions for the execution of the steps of the methods according to the invention as described above.
  • Such recording medium can be any entity or device capable of storing the programs.
  • the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or even a magnetic recording means, for example a USB key or a hard disk.
  • such a recording medium can be a transmissible medium such as an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means, so that the programs computers it contains are executable remotely.
  • the programs according to the invention can in particular be downloaded from a network, for example the Internet network.
  • the recording medium may be an integrated circuit in which the programs are incorporated, the circuit being suitable for executing or for being used in the execution of the aforementioned methods which are the subject of the invention.
  • FIG. 1 this figure represents in a simplified manner the architecture of a cluster of nodes in accordance with the prior art
  • FIG. 2 this figure represents in a simplified manner the architecture of a cluster of nodes in accordance with the solution which is the subject of the present invention
  • FIG. 3 this figure represents the steps of the control and configuration processes when they are implemented by the various components of a master cluster and a slave cluster,
  • FIG. 4 this figure represents the steps of an orchestration loop of a cluster of nodes
  • FIG. 5 this figure represents the steps of the control and configuration methods when they are implemented by the various constituents of a master cluster and of a first slave cluster in the case where, the first slave cluster being already controlled by the master cluster, the configuration of the master cluster is updated,
  • FIG. 6 this figure represents the steps of the control and configuration methods when they are implemented by the various constituents of a master cluster and of a first slave cluster in the case where, the first slave cluster being already controlled by the master cluster, the slave cluster detects an error
  • FIG. 7 this figure represents the steps of the control and configuration methods when they are implemented by the various constituents of a master cluster and of a first slave cluster in the case where the messages exchanged between the master cluster and the first slave cluster are relayed by an intermediate device,
  • FIG. 8 this figure represents a management node capable of implementing the various methods which are the subject of the present invention.
  • the general principle of the invention is based on the establishment of a master-slave relationship between two clusters of nodes which may or may not be co-located.
  • the establishment of this master-slave relationship makes it possible, particularly when a first cluster of nodes is located on the ground and a second cluster of nodes is located in a satellite in orbit around the Earth, to overcome the problems of synchronization of the databases present in the nodes for managing clusters of nodes between them while ensuring that the two clusters of nodes have an identical behavior thus allowing the proper provision of a required service or a required network function.
  • the cluster of nodes 1 comprises a first node 10 called the management node, or "Kubernetes master", and N computing nodes, or “Kubernetes node", 11,, i e ⁇ 1, ..., N), N being a whole natural.
  • the management node 10 includes a controller 101, an API (Application Programming Interface) module 102, a database 103 called DCE which consists of a dynamic register for configuring the calculation nodes 11, and at least one synchronization module 104.
  • a synchronization module 104 can be a master synchronization module 104M or a slave synchronization module 104E depending on whether the management node 10 in which it is located belongs to a cluster of master nodes or a cluster of slave nodes.
  • a single management node 10 can comprise both a master synchronization module 104M and a slave synchronization module 104E because the cluster of nodes to which it belongs can both be the slave of a first cluster of nodes and the master of a second cluster of nodes as will be detailed later.
  • a calculation node 11 comprises M containers or "pods" 110 j , i ⁇ 1, ... , M), M being a natural integer.
  • Each container 110 j is endowed with resources allowing the execution of one or more tasks.
  • a task when executed contributes to the implementation of a network service or function, such as a Dynamic Host Configuration Protocol (DHCP) function for example.
  • DHCP Dynamic Host Configuration Protocol
  • the [fig. 3] represents the steps of the control and configuration methods when they are implemented by the various constituents of a master cluster and of a slave cluster.
  • the API module 102M of the management node 10M of the master cluster receives a takeover request DI from a first slave cluster.
  • a takeover request DI comprises an identifier IdT of at least one task intended to be executed by at least one computing node II,E of the first slave cluster.
  • the takeover request can be sent by equipment of a telecommunications network managed by the same telecommunications operator managing the master cluster.
  • this DI takeover request is transmitted to the database 103M which updates its registers with the information included in the DI takeover request such as, in addition, an IdT identifier of at least at least one task to be executed by at least one calculation module II,E of the first slave cluster, an identifier of the first slave cluster and information relating to the conditions of execution of the task by the calculation node IIIE.
  • an orchestration loop is implemented by the master cluster.
  • Such an orchestration loop is described with reference to [fig. 4],
  • An orchestration loop is a process implemented in a cluster of nodes during which the execution conditions of the tasks executed by the calculation nodes 11 are updated according to: information included in the database data 103 and information on the current execution conditions of the tasks by the calculation nodes 11 ,.
  • the information on the current execution conditions of the tasks is fed back by the calculation nodes 11, to the controller 101 or to the API module 102.
  • the update of the content of the database 103 is independent of the execution of a orchestration loop.
  • the takeover request DI being able to indicate which tasks executed by the computation nodes lli of the cluster of master nodes are intended to be executed by the computation nodes 11, of the first cluster of slave nodes, the implementation of such an orchestration loop makes it possible to update the operation of the cluster of master nodes.
  • the execution of an orchestration loop makes it possible to pass from a so-called current operating state of a cluster of nodes, the current state being defined in particular by the current execution conditions of the tasks by the nodes of calculation 11, and the current content of the registers of the database 103, to an operating state called the expected state which is defined among other things by the execution conditions of the tasks specified in the takeover request D1.
  • the expected state of the cluster of nodes becomes the new current state.
  • Such an orchestration loop although described as implemented within a management node 10M belonging to a master cluster, is implemented identically within a management node 10E belonging to a first slave cluster.
  • a step G1 the controller 101 or the synchronization module 104 transmits a first request for information DU intended for the API module 102.
  • the API module 102 transmits the information request DU to the database 103 and to at least one calculation node 11 i .
  • the database 103 and the calculation node 11 transmit the required information to the API module 102.
  • the API module 102 then transmits this information to the controller 101 or to the synchronization module 104 during a step G4.
  • a step G5 the controller 101 or the synchronization module 104 transmits a request RQT in application of a configuration determined by means of the information received during the step G4.
  • the master synchronization module 104M creates a configuration file FC and transmits the latter to the API module 102M in a step E4.
  • the API module 102M then transmits, in a step E5, the FC configuration file of the first slave cluster comprising takeover parameters and expected execution conditions of said task by the computing node II, E, the conditions expected execution conditions of the task being identical to the current execution conditions of the same task by the lliM computation node.
  • the execution conditions included in the configuration file can be constraints for the tasks to execute correctly such the physical resources such as CPU, GPU, radio antennas required, but also the maximum resources authorized for a given task: maximum number of CPUs, minimum RAM resources required, etc.
  • the tasks executed by the master cluster can be divided into a plurality of task groups, a task group comprising at least one task.
  • the FC configuration file includes an identifier of at least one group of tasks and the expected execution conditions relating to said group of tasks.
  • Such groups can for example include all the tasks to be executed to deliver a service or execute a network function.
  • Other groups can include tasks of the same nature, the tasks can also be grouped according to the type of resources they require for their execution.
  • Each group is then provided with an identifier and one or more sets of execution conditions.
  • Only certain groups of tasks can be executed by the calculation nodes of the first slave cluster while others are executed only by the calculation nodes of the master cluster. The same group of tasks can be executed both by the calculation nodes of the master cluster and the calculation nodes of the first slave cluster.
  • the API module 102E of the management node 10E of the first slave cluster receives the configuration file FC during a step E6 and transmits it to the slave synchronization module 104E.
  • the slave synchronization module 104E checks, with at least one calculation node II,E, the availability of the resources required for the execution of the task identified in the configuration file FC.
  • the slave synchronization module 104E transmits the result of this check to the API module 102E in a step E8.
  • API module 102E in turn transmits this information to the database 103E which updates its registers in a step E9.
  • the slave synchronization module 104E If, in a first case, the slave synchronization module 104E has determined that the required resources are available, it transmits a message MC, called a confirmation message, comprising information relating to the implementation, by the slave cluster, of the configuration required and therefore indicating the takeover of the first slave cluster by the master cluster to the API module 102E which in turn transmits it to the API module 102M of the management node 10M of the master cluster during a step E10. Steps E8 and E10 can be executed simultaneously.
  • a message MC comprising information relating to the implementation, by the slave cluster, of the configuration required and therefore indicating the takeover of the first slave cluster by the master cluster
  • the API module 102E which in turn transmits it to the API module 102M of the management node 10M of the master cluster during a step E10. Steps E8 and E10 can be executed simultaneously.
  • the first slave cluster implements, in a step Eli, an orchestration loop as described with reference to FIG. 4 in order to configure all of the calculation nodes II, E of the first slave cluster with the execution conditions included in the configuration file issued by the master cluster.
  • the first slave cluster is controlled by the master cluster and has an operation identical to that of the master cluster.
  • the tasks executed by the computing nodes II,E of the first slave cluster are executed in the same way, under the same conditions and with the same constraints as when they are executed by the computing nodes II,M of the master cluster.
  • the API module 102M of the management node 10M of the master cluster transmits the confirmation message MC to the master synchronization module 104M.
  • the first slave cluster transmits to the API module 102 of the master cluster in a recurring manner data relating to the execution of the tasks executed by its calculation nodes II, E.
  • step E7 the slave synchronization module 104E has determined that the required resources are not available
  • the slave synchronization module 104E transmits the result of this verification to the API module 102E in step E8.
  • the API module 102E transmits this information to the database 103E which updates its registers in step E9.
  • the slave synchronization module 104E When the slave synchronization module 104E has determined that the required resources are not available, it then transmits a message of failure EC of the takeover of the first slave cluster by the master cluster to the API module 102E which transmits it to its turn to the API module 102M of the management node 10M of the master cluster during step E10.
  • step E7 when during step E7, the slave synchronization module 104E has determined that the required resources are not available, the slave synchronization module 104E transmits the result of this verification to the database 103E in step E8'.
  • This second embodiment can only be implemented if the master cluster explicitly authorizes the takeover of a second slave cluster by the first slave cluster. Such authorization is included in the configuration file FC transmitted during step E5.
  • a step E9′ the database 103E updates its registers with the verification results.
  • an orchestration loop is implemented by the first slave cluster in order to instantiate a master synchronization module 104M in the management node 10E of the first slave cluster
  • the master synchronization module 104M of the management node 10E of the first slave cluster is instantiated and transmits a takeover request D3 of a second slave cluster to the API module 102E in a step E1.
  • the takeover request D3 includes a configuration file FC2 of a second slave cluster created by the master synchronization module 104M.
  • the master synchronization module 104M of the management node 10E transmits, directly after step E7, a request to take control D3 of the second slave cluster intended for the API module 102E in a step E1.
  • the API module 102E then transmits, in a step E12′, the configuration file FC2 of the second slave cluster comprising takeover parameters and expected execution conditions of said task by a computing node II, E of the second slave cluster, the expected execution conditions of the task being identical to the current execution conditions of the same task by the calculation node II, M of the master cluster.
  • the FC2 configuration file is created during the execution of step E1.
  • An API module 102E of a management node 10E of the second slave cluster receives the configuration file FC2 and transmits it to a slave synchronization module 104E of the second slave cluster.
  • the slave synchronization module 104E of the second slave cluster checks, with at least one computing node II,E of the second slave cluster, the availability of the resources required for the execution of the task identified in the configuration file FC2.
  • the slave synchronization module 104E of the second slave cluster transmits the result of this verification to the API module 102E of the second slave cluster.
  • the API module 102E of the second slave cluster in turn transmits this information to the database 103E of the second slave cluster which updates its registers.
  • the slave synchronization module 104E of the second slave cluster When the slave synchronization module 104E of the second slave cluster has determined that the required resources are available, it transmits a confirmation message MC2 of the takeover of the second slave cluster by the first slave cluster to the API module 102E of the second slave cluster which in turn transmits it to the API module 102E of the management node 10E of the first slave cluster during a step E13'.
  • the second slave cluster implements an orchestration loop as described with reference to FIG. 4 in order to configure all of the calculation nodes II, E of the second slave cluster with the execution conditions included in the FC2 config file.
  • the second slave cluster is controlled by the first slave cluster, itself controlled by the master cluster, and has an operation identical to that of the master cluster.
  • the API module 102E of the management node 10E of the first slave cluster transmits the confirmation message MC2 to the API module 102M of the management node 10M of the master cluster which in turn transmits it to the synchronization module master 104M.
  • the first slave cluster recurrently transmits data relating to the execution of the tasks executed by the computing nodes II, E of the second slave cluster to the master cluster. .
  • the first slave cluster can be freed and thus regain its independence in order to be used autonomously or under the control of a new master cluster.
  • the API module 102M of the master cluster receives a franking request DA from the first slave cluster.
  • this franking request DA is transmitted to the database 103M which updates its registers with the information included in the franking request DA.
  • an orchestration loop is implemented by the master cluster.
  • the master synchronization module 104M transmits a franking request DA2 from the first slave cluster to the API module 102M in a step E16.
  • the API module 102M then transmits, in a step E17, a configuration file FC3 of the first slave cluster comprising franking parameters of said first slave cluster.
  • the API module 102E of the management node 10E of the first slave cluster receives the configuration file FC3 during a step E18 and transmits it to the slave synchronization module 104E.
  • the slave synchronization module 104E processes the configuration file FC3 and transmits the processing result to the API module 102E in a step E20.
  • the API module 102E in turn transmits this information to the database 103E which updates its registers.
  • the slave synchronization module 104E When the slave synchronization module 104E has processed the FC3 configuration file, it transmits a first slave cluster freeing message to the master to the API module 102E which in turn transmits it to the API module 102M of the management node 10M of the master cluster during a step E21.
  • the first slave cluster implements, in a step E22, an orchestration loop as described with reference to FIG. 4 in order to configure all of the calculation nodes II, E of the first slave cluster.
  • the first slave cluster is no longer controlled by the master cluster and operates autonomously.
  • the [fig. 5] represents the steps of the control and configuration methods when they are implemented by the various constituents of a master cluster and of a first slave cluster in the case where, the first slave cluster being already controlled by the cluster master, the configuration of the master cluster is updated.
  • the sequence of steps described with reference to Figure 5 is located between steps E12 and E13 described with reference to Figure 3.
  • the API module 102M of the management node 10M of the master cluster receives an update request Update of the configuration of the master cluster.
  • Such an update request MàJl comprises an identifier IdT of at least one task intended to be executed by at least one computing node II,M of the master cluster.
  • the MàJ1 update request can be sent by equipment of a telecommunications network managed by the same telecommunications operator managing the master cluster.
  • Such an update request MàJl similar to a takeover request such as that described with reference to Figure 3.
  • apiVersion apps/vx kind: DeploymentSlave metadata: name: DeploymentName labels: app: DeploymentLabel spec: replicas: ReplicaNumber selector: matchLabels: app: DeploymentLabel template :metadata:labels:app:LabelDeployment spec:slave:IDESCLAVE/IPESCLAVE containers:
  • this update request MàJl is transmitted to the database 103M which updates its registers with the information included in the update request MàJl such as, in addition, an IdT identifier of at at least one task to be executed by at least one calculation module II,M of the master cluster and information relating to the conditions for execution of the task by the calculation node II,M.
  • an orchestration loop is implemented by the master cluster.
  • the cluster master configuration is updated. Following this update of the master cluster configuration, some tasks execution conditions may have changed, new tasks may be running, and some tasks may be completed.
  • the master synchronization module 104M then creates and transmits a MàJFC configuration update file of the first slave cluster to the API module 102M in a step F4.
  • the API module 102M then transmits, in a step F5, the configuration update file MàJFC of the first slave cluster comprising the expected execution conditions of said task per computing node II, E, the expected execution conditions of the task being identical to the current execution conditions of the same task by the lliM computing node, i.e. the conditions under which the tasks are executed by the lliM computing node following the implementation of the orchestration loop in step F3.
  • the API module 102E of the management node 10E of the first slave cluster receives the MàJFC configuration update file during a step F6 and transmits it to the slave synchronization module 104E.
  • the slave synchronization module 104E checks, for example with at least one calculation node II,E, the availability of the resources required for the execution of the task identified in the update file configuration Update JFC.
  • the slave synchronization module 104E transmits the result of this check to the API module 102E in a step F8.
  • the API module 102E in turn transmits this information to the database 103E which updates its registers in a step F9.
  • the slave synchronization module 104E If, in a first case, the slave synchronization module 104E has determined that the required resources are available, it transmits a message comprising information relating to the implementation of the required update, called the update confirmation message MC. updated, from the first slave cluster to the API module 102E which in turn transmits it to the API module 102M of the management node 10M of the master cluster during a step F10.
  • the first slave cluster implements, in a Fil step, an orchestration loop as described with reference to FIG. 4 in order to configure all of the calculation nodes II, E of the first slave cluster with the execution conditions included in the configuration update file issued by the master cluster.
  • the first slave cluster is updated and has an operation identical to that of the master cluster.
  • the API module 102M of the management node 10M of the master cluster transmits the update confirmation message MC to the master synchronization module 104M of the master cluster.
  • the first slave cluster recurrently transmits data relating to the execution of the tasks executed by its calculation nodes II, E.
  • step F7 the slave synchronization module 104E transmits the result of this check to the API module 102E in step F8.
  • the API module 102E transmits this information to the database 103E which updates its registers in step F9.
  • the slave synchronization module 104E transmits an EC update failure message from the first slave cluster to the API module 102E which in turn transmits it to the API module.
  • 102M of the management node 10M of the master cluster during step F10.
  • the database 103E updates its registers with the results verification during a step F9'.
  • an orchestration loop is implemented by the first slave cluster in order to instantiate a master synchronization module 104M in the management node 10E of the first slave cluster.
  • the master synchronization module 104M of the management node 10E of the first slave cluster is instantiated and transmits an update request from the second slave cluster to the API module 102E in a step FU'.
  • the update request of the second slave cluster D3 includes a configuration update file MàJFC2 of the second slave cluster created by the master synchronization module 104M.
  • the master synchronization module 104M of the management node 10E transmits, directly after step F7, an update request. update of the second slave cluster to the API module 102E in a Fil' step.
  • the API module 102E then transmits, in a step F12′, the configuration update file MàJFC2 of the second slave cluster comprising the expected execution conditions of said task by a computing node II, E of the second slave cluster , the expected execution conditions of the task being identical to the current execution conditions of the same task by the computing node II,M of the master cluster.
  • the MàJFC2 configuration file is created during step FU'.
  • An API module 102E of a management node 10E of the second slave cluster receives the configuration update file MàJFC2 and transmits it to a slave synchronization module 104E of the second slave cluster.
  • the slave synchronization module 104E of the second slave cluster checks, with at least one computing node II,E of the second slave cluster, the availability of the resources required for the execution of the task identified in the update file configuration Update JFC2.
  • the slave synchronization module 104E of the second slave cluster transmits the result of this verification to the API module 102E of the second slave cluster.
  • the API module 102E of the second slave cluster in turn transmits this information to the database 103E of the second slave cluster which updates its registers.
  • the slave synchronization module 104E of the second slave cluster When the slave synchronization module 104E of the second slave cluster has determined that the required resources are available, it transmits a confirmation message MC2 of the update of the second slave cluster to the API module 102E of the second slave cluster which transmits it in turn to the API module 102E of the management node 10E of the first slave cluster during a step F13'.
  • the second slave cluster implements an orchestration loop as described with reference to FIG. 4 in order to configure all of the calculation nodes II, E of the second slave cluster with the execution conditions included in the configuration update file MàJFC2.
  • the second slave cluster is updated and has an operation identical to that of the master cluster.
  • the API module 102E of the management node 10E of the first slave cluster transmits the confirmation message MC2 to the API module 102M of the management node 10M of the master cluster which in turn transmits it to the synchronization module master 104M.
  • the first slave cluster recurrently transmits data relating to the execution of the tasks executed by the calculation nodes II, E of the second slave cluster to the master cluster .
  • the [fig. 6] represents the steps of the control and configuration methods when they are implemented by the various constituents of a master cluster and of a first slave cluster in the case where, the first slave cluster being already controlled by the cluster master, the slave cluster detects an error.
  • the sequence of steps described with reference to Figure 6 is located between steps E12 and E13 described with reference to Figure 3.
  • the API module 102E of the management node 10E of the first slave cluster receives an error message Pb transmitted for example by a radio antenna of an access node of a communication network, the node d the access being controlled by the first slave cluster which executes network functions for it such as coding functions for example.
  • the API module 102E of the management node 10E transmits the error message Pb to the slave synchronization module 104E of the first slave cluster.
  • the slave synchronization module 104E verifies the capacity of the first slave cluster to resolve the error itself.
  • the first slave cluster If the first slave cluster is able to resolve the error itself, it does so during a step H4.
  • the slave synchronization module 104E transmits this information to the API module 102E in a step H5.
  • the API module 102E in turn transmits this information to the API module 102M of the master cluster in a step H6.
  • the API module 102M of the master cluster in turn transmits this information to the master synchronization module 104M in a step H7.
  • the master synchronization module 104M determines a solution to resolve the error and generates a correction file.
  • the master synchronization module 104M transmits the correction file to the API module 102M in a step H9.
  • the API module 102M transmits the correction file to the API module 102E during a step H10.
  • the slave synchronization module 104E receives, in a step H11, the correction file transmitted to it by the API module 102E.
  • a step H12 an orchestration loop is implemented by the master cluster in order to take account of the information from the correction file during the execution of the tasks by the calculation nodes II, M.
  • an orchestration loop is implemented by the first master cluster in order to take into account the information of the correction file during the execution of the tasks by the calculation nodes II, E and thus fix the error.
  • the [fig. 7] represents the steps of the control and configuration methods when they are implemented by the various constituents of a master cluster and of a first slave cluster in the case where the messages exchanged between the master cluster and the first cluster slave are relayed by an intermediate device.
  • the API 102M module wishes to transmit a first slave cluster FC configuration file during step E5 or a MàJFC configuration update file during step F5
  • the message comprising this configuration file or configuration update is transmitted to an intermediate device which then serves as a relay.
  • the intermediate equipment R receives the message comprising this configuration or configuration update file intended to be relayed to the first slave cluster.
  • the intermediate equipment R applies security and filtering rules to the message received. Such rules are for example set by the telecommunications operator managing the master cluster and wishing to take control or update the first slave cluster. The intermediate equipment R also checks that it is able to communicate with the first slave cluster.
  • the intermediate equipment R determines that the message to be transmitted to the first slave cluster cannot be relayed, it informs the master cluster thereof during a step J3 and indicates the reasons for this refusal.
  • the intermediate equipment R determines that the message to be transmitted to the first slave cluster can be relayed, it transmits the message to the first slave cluster during a step J4.
  • the master cluster is informed of the correct transmission of the message to the first slave cluster when the intermediate equipment transmits to it during a step J5 a message confirming the takeover of the first slave cluster or a message confirming the update of the first slave cluster.
  • the [fig. 8] represents management node 10 capable of implementing the various methods which are the subject of the present invention.
  • a management node 10 can comprise at least one hardware processor 801, one storage unit 802, one interface 803, and at least one network interface 804 which are connected together through a bus 805 in addition to the API module 102 , of the controller 101, of the database 103 and of the synchronization module(s) 104.
  • the constituent elements of the management node 10 can be connected by means of a connection other than a bus.
  • the processor 801 controls the operations of the management node 10.
  • the storage unit 802 stores at least one program for the implementation of the various methods which are objects of the invention to be executed by the processor 801, and various data, such as parameters used for calculations carried out by the processor 801, intermediate data of calculations carried out by the 801 processor, etc.
  • Processor 801 may be formed by any known and suitable hardware or software, or by a combination of hardware and software.
  • the processor 801 can be formed by dedicated hardware such as a processing circuit, or by a programmable processing unit such as a Central Processing Unit which executes a program stored in a memory of this one.
  • Storage unit 802 may be formed by any suitable means capable of storing the program or programs and data in a computer readable manner. Examples of storage unit 802 include non-transitory computer-readable storage media such as semiconductor memory devices, and magnetic, optical, or magneto-optical recording media loaded into a read-and-write unit. 'writing.
  • Interface 803 provides an interface between management node 10 and at least one computing node 11, belonging to the same cluster of nodes as management node 10.
  • the network interface 804 in turn provides a connection between the management node 10 and another management node of another cluster of nodes.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Hardware Redundancy (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne une solution d'orchestration d'une pluralité de grappes de nœuds devant exécuter des tâches identiques de manière identique en n'étant pas co‐localisées. Il est difficile de déployer une architecture dans laquelle des grappes de nœuds sont réparties à la fois au sol et dans un ou plusieurs satellites. La présente solution permet un tel déploiement en établissant une relation maître‐esclave entre une première et une deuxième grappe de nœuds. Il est alors possible de s'affranchir des problèmes liés à la synchronisation des bases de données des grappes de nœuds puisque seule la synchronisation de la base de données de la grappe de nœuds maître importe. En effet, une fois que les grappes de nœuds esclaves ont été configurées, les bases de données des grappes de nœuds esclaves n'ont pas besoin d'être synchronisées avec la base de données du nœud de gestion de la grappe de nœuds maître.

Description

DESCRIPTION
PROCÉDÉ DE CONTRÔLE D'UNE GRAPPE DE NOEUDS ESCLAVE PAR UNE GRAPPE DE NOEUDS MAÎTRE,
DISPOSITIFS ET PROGRAMMES D'ORDINATEURS CORRESPONDANTS
Domaine de l'invention
Le domaine de l'invention est celui de l'informatique en nuage ou « cloud computing ».
Plus précisément, l’invention concerne une solution permettant l'orchestration d'une pluralité de grappes de noeuds devant exécuter des tâches identiques de manière identique bien que ces différentes grappes de noeuds ne soient pas co-localisées.
Art antérieur et ses inconvénients
Depuis plusieurs années, les réseaux de télécommunication utilisent des fonctions virtualisées hébergées dans des serveurs, ou noeuds, regroupés en grappes, ou « clusters », donnant naissance à l'informatique en nuage.
Une solution d'orchestration de ces grappes de noeuds est connue sous l'appellation Kubernetes. La [Fig. 1] présente de manière simplifiée l'architecture d'une grappe de noeuds 1 conforme à la solution Kubernetes. La grappe de noeuds 1 comprend un premier nœud 10 dit nœud de gestion, ou « Kubernetes master », et N nœuds de calcul, ou « Kubernetes node », 11·,, i e {1, ... , N), N étant un entier naturel.
Le nœud de gestion 10 comprend un contrôleur 101, un module API (Application Progra ing interface ou interface de programmation d'applications) 102 et une base de données 103 dite ETCD qui consiste en un registre dynamique de configuration des nœuds de calculs 11,.
Un nœud de calcul 11, comprend M conteneurs ou « pods » 110j, j e {1, ... , M), M étant un entier naturel. Chaque conteneur 110j est doté de ressources permettant l'exécution d'une ou de plusieurs tâches. Une tâche lorsqu'elle est exécutée contribue à la mise en œuvre d'un service ou d'une fonction réseau, telle qu'une fonction DHCP (Dynamic Host Configuration Protocol ou protocole de configuration dynamique des hôtes) par exemple.
Dans un souci de réduction des coûts et d'amélioration de la flexibilité des infrastructures réseaux, les architectures d'informatique en nuage sont le plus souvent des architectures multi- sites dans lesquelles les nœuds constitutifs des grappes de nœuds peuvent être non co-localisés. Par exemple un nœud de gestion 10 et deux nœuds de calcul lli, II2 d'une grappe de nœuds 1 sont situés sur un site A alors que trois autres nœuds de calculs II3, II4, Ils sont quant à eux situés sur un site B distant.
Dans un tel cas de figure, il est nécessaire de synchroniser les états de fonctionnements des différentes tâches exécutées par les nœuds de calculs 11, d'une même grappe de nœuds 1 pour s'assurer de la bonne fourniture du service requis ou de la bonne exécution de la fonction réseau.
Ceci est particulièrement important dans le cas où un partie d'une grappe de nœuds 1 est déployée à la fois dans des sites au sol et dans des satellites en orbite autour de la Terre. En effet, l'ensemble des conteneurs 110j de la grappe de nœuds 1 déployés doit être supervisé et orchestré en permanence.
Or, il est difficile de déployer un unique nœud de gestion 10 réparti à la fois dans la partie terrestre et dans la partie satellitaire de la grappe de nœuds 1 car une latence trop importante ne permet pas un niveau de synchronisation satisfaisant entre la partie de la base de données 103 située au sol et la partie de la base de données 103 située dans le satellite.
Il est également difficile d'orchestrer les conteneurs 110j embarqués dans un satellite via un nœud de gestion 10 situé au sol car le satellite n'est pas en permanence à portée du nœud de gestion 10.
Afin de résoudre cette problématique, une première solution consiste à déployer une première grappe de nœuds au sol et une deuxième grappe de nœuds dans un ou plusieurs satellites en orbite. Les satellites étant en déplacement continu autour de la Terre, la grappe de nœuds embarquée dans les satellites modifie sa configuration afin de s'adapter à l'ensemble des besoins et des contraintes formulées par les différents opérateurs gérant des réseaux de télécommunication des différents pays survolés. Ces opérations de reconfiguration, comme le déploiement d'un autre système d'exploitation, l'installation de dépendances, le déploiement puis la mise à jour des nœuds de gestion et de calcul, sont chronophages. En effet, il faut compter environ une dizaine de minutes pour un déploiement complet de ce type, ce qui occupe une très grande partie de la période de couverture d'un pays par le satellite.
Une deuxième solution consiste à déployer plusieurs nœuds de gestion 10 pour une même grappe de nœuds 1 au sol et dans un ou plusieurs satellites. Cependant une telle architecture induit un temps de latence pour la synchronisation des bases de données 103 embarquées dans chacun des nœuds de gestion 10. En effet, ces bases de données 103 fonctionnent entre elles au moyen d'un algorithme de consensus, nommé RAFT. Cet algorithme repose sur l'utilisation de temporisations qui sont sensibles à la latence introduite entre chaque opération de réplication du contenu d'une base de données 103. Or, les base de données 103 sont très régulièrement mises à jour afin de maintenir à jour l'état de fonctionnement d'une grappe de nœuds 1.
Ainsi, la répartition des nœuds de gestion 10 entre le sol et les satellites a pour conséquence un allongement de la réactivité des nœuds de gestions de la grappe de nœuds 1 ce qui introduit des ruptures de services.
Il existe donc un besoin d’une solution de déploiement de grappes de nœuds ne présentant pas tout ou partie des inconvénients précités.
Exposé de l’invention
L’invention répond à ce besoin en proposant un procédé de contrôle d'une première grappe de nœuds, dite grappe esclave, par une deuxième grappe de nœuds, dite grappe maître, une grappe de nœuds comprenant au moins un nœud de calcul exécutant au moins une tâche, ledit procédé de contrôle étant mis en œuvre par ladite grappe maître et comprenant les étapes suivantes :
- réception d'une demande de prise de contrôle de ladite grappe esclave identifiant au moins une tâche destinée à être exécutée par au moins un nœud de calcul de ladite grappe esclave,
- création d'un fichier de configuration de ladite grappe esclave comprenant des paramètres de prise de contrôle et des conditions d'exécution attendues de ladite tâche par ledit au moins un nœud de calcul de ladite grappe esclave, lesdites conditions d'exécution attendues de ladite tâche étant identiques aux conditions d'exécution courantes de ladite tâche par au moins un nœud de calcul de ladite grappe maître,
- transmission dudit fichier de configuration à destination de ladite grappe esclave,
- réception d'un message comprenant des informations relatives à la mise en œuvre, par la grappe esclave, de la configuration requise. Une telle solution permet de déployer une solution d'informatique en nuage dans laquelle les grappes de noeuds constitutives de l'architecture déployée ne sont pas co-localisées mais ne présentant pas les inconvénients de l'état de l'art précédemment cités.
Ceci est rendu possible en établissant une relation maître-esclave entre une première grappe de noeuds et une deuxième grappe de noeuds.
Une telle solution permet de s'affranchir des problèmes liés à la synchronisation des bases de données des noeuds de gestion des grappes de noeuds puisque dans une telle solution, seule la synchronisation de la base de données du nœud de gestion de la grappe de nœuds maître importe. En effet, dans la présente solution, une fois que la grappe de nœuds esclave a été configurée au moyen du ficher de configuration, les bases de données des nœuds de gestion des grappes de nœuds esclaves n'ont pas besoin d'être synchronisées avec la base de données du nœud de gestion de la grappe de nœuds maître. Cela est possible car les conditions d'exécutions spécifiées dans le fichier de configuration correspondent aux conditions d'exécution courantes appliquées par les nœuds de la grappe maître.
Ainsi, bien que d'un point de vue matériel les deux grappes de nœuds, maître et esclave, soient des grappes de nœuds indépendantes, elles se comportent d'un point de vue fonctionnel comme une seule et même grappe de nœuds. La grappe maître et la grappe esclave sont liées et possèdent un comportement identique permettant une bonne exécution des services requis ou des fonctions réseaux.
Les conditions d'exécution des tâches par la grappe maître et la grappe esclave sont identiques car ces deux grappes faisant partie d'une même architecture d'informatique en nuage, il est important d'assurer une exécution cohérente des fonctions réseau entre les différents composant de l'architecture d'informatique en nuage sachant que, pour un service donné ou une fonction réseau donnée, certaines tâches liées à la fourniture de ce service ou de cette fonction seront exécutées en partie dans la grappe maître et en partie dans la grappe esclave.
Ainsi, une condition d'exécution peut être un minimum de capacité mémoire requise pour l'exécution de la tâche. Tant que la condition d'exécution est respectée par la grappe maître et la grappe esclave, la capacité mémoire effective de la grappe maître et de la grappe esclave peuvent être différentes. Ainsi, si la condition d'exécution est minimum de capacité mémoire requise = 2Goctets de mémoire et que la grappe maître affiche une capacité mémoire de 6Go et que la grappe esclave affiche une capacité mémoire de 4Go alors la condition d'exécution est respectée puisque de manière identique les deux grappes maître et esclave respecte une condition d'exécution identique à savoir afficher un minimum de capacité mémoire de 2Go.
Dans la solution objet de l'invention, il suffit de configurer une première grappe de nœuds, située par exemple au sol, et lui demander de prendre le contrôle d'une deuxième grappe de nœuds, par exemple située dans un ou plusieurs satellites, ou dans tout autre véhicule d’une flotte. Lorsque la première grappe peut communiquer avec la deuxième grappe, elle en prend le contrôle et lui transfère un fichier de configuration permettant à la deuxième grappe d'exécuter les tâches requises.
Selon une première implémentation du procédé de contrôle d'une grappe de nœuds esclave, les tâches exécutées par la grappe maître étant réparties en une pluralité de groupes de tâches, un groupe de tâches comprenant au moins une tâche, le fichier de configuration comprend un identifiant d'au moins un groupe de tâches et les conditions d'exécution attendues relatives dudit groupe de tâches.
Il est intéressant de répartir les différentes tâches à exécuter en groupes. De tels groupes peuvent par exemple comprendre l'ensemble des tâches à exécuter pour livrer un service ou exécuter une fonction réseau. D'autres groupes peuvent comprendre des tâches de même nature, les tâches peuvent être également regrouper en fonction du types de ressources qu'elles requièrent pour leur exécution.
Chaque groupe est ensuite doté d'un identifiant et d'un ou plusieurs jeux de conditions d'exécution.
Ainsi, seuls certains groupes de tâches peuvent être exécutés par les noeuds de calculs de la grappe esclave tandis que d'autres sont exécutés uniquement par les noeuds de calculs de la grappe maître. Un même groupe de tâches peut être exécuté à la fois par les noeuds de calculs de la grappe maître et les noeuds de calculs de la grappe esclave.
Dans un mode de réalisation particulier du procédé de contrôle, celui-ci comprend en outre les étapes suivantes :
- réception d'une demande de modification de la configuration de ladite grappe maître comprenant des conditions d'exécution attendues de ladite tâche par ledit au moins un nœud de calcul de ladite grappe maître,
- configuration de ladite grappe maître au moyen desdites conditions d'exécution attendues, lesdites conditions d'exécution attendues devenant, à l'issue de ladite étape de configuration, les nouvelles conditions d'exécution courantes de ladite tâche,
- création d'un fichier de mise à jour de la configuration de ladite grappe esclave comprenant les conditions d'exécution attendues de ladite tâche par ledit au moins un nœud de calcul de ladite grappe esclave, lesdites conditions d'exécution attendues de ladite tâche étant identiques aux nouvelles conditions d'exécution courantes de ladite tâche par au moins un nœud de calcul de ladite grappe maître,
- transmission dudit fichier de mise à jour de la configuration à destination de ladite grappe esclave.
Ainsi, chaque mise à jour de la configuration de la grappe maître est dynamiquement déployée sur la grappe esclave assurant ainsi que la grappe maître et la grappe esclave ont toujours un comportement identique.
Lorsque la mise à jour de la configuration de la grappe esclave échoue, le procédé comprend en outre une étape de réception d'un message indiquant l'échec de la mise à jour de la configuration par la grappe esclave.
Ainsi la grappe maître peut chercher à prendre le contrôle d'une autre grappe esclave afin de pouvoir fournir les services ou les fonctions réseaux requis.
Lorsque la mise à jour de la configuration de la grappe esclave échoue, le procédé de contrôle comprend en outre, dans une implémentation particulière, une étape de réception d'un message comprenant des informations relatives à la mise en œuvre, par la grappe esclave, de la mise à jour de la configuration d'au moins une autre grappe esclave à destination de laquelle la grappe esclave a transmis un fichier de configuration comprenant des conditions d'exécution attendues de ladite tâche par ledit au moins un nœud de calcul de ladite autre grappe esclave, lesdites conditions d'exécution attendues de ladite tâche étant identiques aux conditions d'exécution courantes de ladite tâche par au moins un nœud de calcul de ladite grappe maître. Dans cette implémentation particulière, la première grappe esclave étant dans l'incapacité de mettre en œuvre la configuration demandée par la grappe maître, elle prend le contrôle d'une deuxième grappe esclave. Pour cela la grappe esclave se comporte comme la grappe maître en transmettant un fichier de configuration comprenant une demande de prise de contrôle à destination de la deuxième grappe esclave.
La grappe maître est informée de cette situation.
Lorsque les grappes maître et esclave ne peuvent communiquer directement, un équipement intermédiaire sert de relai. Dans un tel cas de figure, le procédé comprend une étape de réception d'un message émis par l'équipement intermédiaire indiquant l'impossibilité de transmettre un fichier de configuration à ladite grappe esclave.
Ainsi la grappe maître peut chercher à prendre le contrôle d'une autre grappe esclave afin de pouvoir fournir les services ou les fonctions réseaux requis via l'équipement intermédiaire ou non.
Dans une autre implémentation du procédé de contrôle, ce dernier comprend :
- une étape de réception d'un message d'erreur émis par la grappe esclave,
- une étape de création d'un fichier de réparation de ladite grappe esclave comprenant des paramètres de réparation de ladite grappe esclave,
- transmission dudit fichier de réparation à destination de ladite grappe esclave.
Lorsque la grappe maître est informée de la survenue d'une erreur au niveau de la grappe esclave, elle tente de procéder à une réparation afin d'assurer une continuité de service.
Enfin, le procédé de contrôle peut également comprendre dans certains modes de réalisation :
- une étape de réception d'une demande d'affranchissement de ladite grappe esclave,
- une étape de création d'un fichier de configuration de ladite grappe esclave comprenant des paramètres d'affranchissement de ladite grappe esclave,
- une étape de transmission dudit fichier de configuration à destination de ladite grappe esclave.
Ainsi lorsque les circonstances l'exigent, la grappe esclave retrouve son indépendance et peut être utilisée de manière autonome, c'est-à-dire sans maître, ou bien sous le contrôle d'un nouveau maître, etc.
L'invention a également pour objet un procédé de configuration d'une première grappe de nœuds, dite grappe esclave, par une deuxième grappe de nœuds, dite grappe maître, une grappe de nœuds comprenant au moins un nœud de calcul exécutant au moins une tâche, ledit procédé de configuration étant mis en œuvre par ladite grappe esclave et comprenant les étapes suivantes :
- réception d'un fichier de configuration de ladite grappe esclave comprenant des paramètres de prise de contrôle et des conditions d'exécution attendues de ladite tâche par ledit au moins un nœud de calcul de ladite grappe esclave, lesdites conditions d'exécution attendues de ladite tâche étant identiques à des conditions d'exécution courantes de ladite tâche par au moins un nœud de calcul de ladite grappe maître,
- vérification d'une disponibilité des ressources requises pour l'exécution de ladite tâche,
- lorsque les ressources requises sont disponibles, configuration de ladite grappe esclave au moyen dudit fichier de configuration,
- transmission, à destination de la grappe maître, d'un message comprenant des informations relatives à la mise en œuvre, par la grappe esclave, de la configuration requise. Si elle n'est pas capable de fournir les ressources requises par la grappe maître, la grappe esclave en informe cette dernière qui peut alors chercher à prendre le contrôle d'une nouvelle grappe esclave.
Selon une implémentation particulière, le procédé de configuration comprend en outre les étapes suivantes :
- réception d'un fichier de mise à jour de la configuration de ladite grappe esclave comprenant des conditions d'exécution attendues de ladite tâche par ledit au moins un nœud de calcul de ladite grappe esclave, lesdites conditions d'exécution attendues de ladite tâche étant identiques à des nouvelles conditions d'exécution courantes de ladite tâche par au moins un nœud de calcul de ladite grappe maître,
- vérification d'une disponibilité des ressources requises pour l'exécution de ladite tâche,
- lorsque les ressources requises sont disponibles, mise à jour de la configuration de ladite grappe esclave au moyen dudit fichier de mise à jour de la configuration,
- transmission, à destination de la grappe maître, d'un message comprenant des informations relatives à la mise en œuvre, par la grappe esclave, de la configuration requise.
Ainsi lorsque les ressources requises sont disponibles, la configuration de la grappe esclave est mise à jour dynamiquement et fonctionne toujours de manière identique à la grappe maître.
Lorsque les ressources requises ne sont pas disponibles, le procédé de configuration comprend en outre une étape d'émission d'un message indiquant l'échec de la mise à jour de la configuration à destination de la grappe maître.
Ainsi la grappe maître peut chercher à prendre le contrôle d'une autre grappe esclave afin de pouvoir fournir les services ou les fonctions réseaux requis.
Le procédé de configuration comprend en outre lorsque les ressources requise ne sont pas disponibles :
- une étape de transmission d'un fichier de configuration comprenant des conditions d'exécution attendues de ladite tâche par au moins un nœud de calcul d'une autre grappe esclave, lesdites conditions d'exécution attendues de ladite tâche étant identiques aux conditions d'exécution courantes de ladite tâche par au moins un nœud de calcul de ladite grappe maître,
- une étape de réception d'un message comprenant des informations relatives à la mise en œuvre, par ladite autre grappe esclave, de la configuration requise,
- une étape de transmission, à destination de la grappe maître, d'un message comprenant des informations relatives à la mise en œuvre, par ladite autre grappe esclave, de la configuration requise.
Dans cette implémentation particulière, la première grappe esclave étant dans l'incapacité de mettre en œuvre la configuration demandée par la grappe maître, elle prend le contrôle d'une deuxième grappe esclave. Pour cela la grappe esclave se comporte comme la grappe maître en transmettant un fichier de configuration comprenant une demande de prise de contrôle à destination de la deuxième grappe esclave.
La grappe maître est informée de cette situation.
L'invention à également pour objet un nœud de gestion d'une première grappe de nœuds, dite grappe maître, capable de contrôler une deuxième grappe de nœuds, dite grappe esclave, une grappe de nœuds comprenant également au moins un nœud de calcul exécutant au moins une tâche, ledit nœud de gestion de la grappe maître comprenant des moyens pour : - recevoir une demande de prise de contrôle de ladite grappe esclave identifiant au moins une tâche destinée à être exécutée par au moins un nœud de calcul de ladite grappe esclave,
- créer un fichier de configuration de ladite grappe esclave comprenant des paramètres de prise de contrôle et des conditions d'exécution attendues de ladite tâche par ledit au moins un nœud de calcul de ladite grappe esclave, lesdites conditions d'exécution attendues de ladite tâche étant identiques aux conditions d'exécution courantes de ladite tâche par au moins un nœud de calcul de ladite grappe maître,
- transmettre le fichier de configuration à destination de ladite grappe esclave,
- recevoir un message comprenant des informations relatives à la mise en œuvre, par la grappe esclave, de la configuration requise.
L'invention concerne encore un nœud de gestion d'une première grappe de nœuds, dite grappe esclave, capable de configurer ladite grappe esclave, une grappe de nœuds comprenant également au moins un nœud de calcul exécutant au moins une tâche, ledit nœud de gestion de la grappe esclave comprenant des moyens pour :
- recevoir, depuis une deuxième grappe de nœuds, dite grappe maître, un fichier de configuration de ladite grappe esclave comprenant des paramètres de prise de contrôle et des conditions d'exécution attendues de ladite tâche par ledit au moins un nœud de calcul de ladite grappe esclave, lesdites conditions d'exécution attendues de ladite tâche étant identiques à des conditions d'exécution courantes de ladite tâche par au moins un nœud de calcul de ladite grappe maître,
- vérifier une disponibilité des ressources requises pour l'exécution de ladite tâche,
- lorsque les ressources requises sont disponibles, configurer ladite grappe esclave au moyen dudit fichier de configuration,
- transmettre, à destination de la grappe maître, un message comprenant des informations relatives à la mise en œuvre, par la grappe esclave, de la configuration requise.
L'invention a enfin pour objets des produits programme d’ordinateur comprenant des instructions de code de programme pour la mise en œuvre des procédés tels que décrits précédemment, lorsqu'ils sont exécutés par un processeur.
L'invention vise également un support d'enregistrement lisible par un ordinateur sur lequel sont enregistrés des programmes d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes des procédés selon l'invention tels que décrits ci-dessus.
Un tel support d’enregistrement peut être n’importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, le support peut comporter un moyen de stockage, tel qu’une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d’enregistrement magnétique, par exemple une clé USB ou un disque dur.
D’autre part, un tel support d’enregistrement peut être un support transmissible tel qu’un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d’autres moyens, de sorte que les programmes d'ordinateur qu'il contient sont exécutables à distance. Les programmes selon l’invention peuvent être en particulier téléchargés sur un réseau par exemple le réseau Internet.
Alternativement, le support d’enregistrement peut être un circuit intégré dans lequel les programmes sont incorporés, le circuit étant adapté pour exécuter ou pour être utilisé dans l’exécution des procédés objets de l'invention précités.
Liste des figures D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles :
[fig. 1] : cette figure représente de manière simplifiée l'architecture d'une grappe de noeuds conforme à l'art antérieur,
[fig. 2] : cette figure représente de manière simplifiée l'architecture d'une grappe de noeuds conforme à la solution objet de la présente invention,
[fig. 3] : cette figure représente les étapes des procédés de contrôle et de configuration lorsqu'elles sont mises en oeuvre par les différents constituants d'une grappe maître et d'une grappe esclave,
[fig. 4] : cette figure représente les étapes d'une boucle d'orchestration d'une grappe de noeuds,
[fig. 5] : cette figure représente les étapes des procédés de contrôle et de configuration lorsqu'elles sont mises en oeuvre par les différents constituants d'une grappe maître et d'une première grappe esclave dans le cas où, la première grappe esclave étant déjà contrôlée par la grappe maître, la configuration de la grappe maître est mise à jour,
[fig. 6] : cette figure représente les étapes des procédés de contrôle et de configuration lorsqu'elles sont mises en oeuvre par les différents constituants d'une grappe maître et d'une première grappe esclave dans le cas où, la première grappe esclave étant déjà contrôlée par la grappe maître, la grappe esclave détecte une erreur,
[fig. 7] : cette figure représente les étapes des procédés de contrôle et de configuration lorsqu'elles sont mises en oeuvre par les différents constituants d'une grappe maître et d'une première grappe esclave dans le cas où, les messages échangés entre la grappe maître et la première grappe esclave sont relayés par un équipement intermédiaire,
[fig. 8] : cette figure représente nœud de gestion apte à mettre en œuvre les différents procédés objets de la présente invention.
Description détaillée de modes de réalisation de l'invention
Le principe général de l'invention repose sur l'établissement d'une relation maître-esclave entre deux grappes de nœuds pouvant ou non être co-localisées. L'établissement de cette relation maître-esclave permet, particulièrement lorsqu'une première grappe de nœuds est localisée au sol et une deuxième grappe de nœuds est localisée dans un satellite en orbite autour de la Terre, de s'affranchir des problèmes de synchronisation des bases de données présentes dans les nœuds de gestion des grappes de nœuds entre elles tout en s'assurant que les deux grappes de nœuds ont un comportement identique permettant ainsi la bonne fourniture d'un service requis ou d'une fonction réseau requise.
La [fig. 2] présente de manière simplifiée l'architecture d'une grappe de nœuds 1 conforme à la solution objet de la présente invention. Les éléments déjà décrits en référence à la figure 1 conservent les mêmes signes de référence.
La grappe de nœuds 1 comprend un premier nœud 10 dit nœud de gestion, ou « Kubernetes master », et N nœuds de calcul, ou « Kubernetes node », 11,, i e {1, ... , N), N étant un entier naturel.
Le nœud de gestion 10 comprend un contrôleur 101, un module API (Application Programming interface ou interface de programmation d'applications) 102, une base de données 103 dite ETCD qui consiste en un registre dynamique de configuration des noeuds de calculs 11, et au moins un module de synchronisation 104. Un tel module de synchronisation 104 peut être un module de synchronisation maître 104M ou un module de synchronisation esclave 104E selon que le nœud de gestion 10 dans lequel il se situe appartient à une grappe de nœuds maître ou une grappe de nœuds esclave. Un même nœud de gestion 10 peut comprendre à la fois un module de synchronisation maître 104M et un module de synchronisation esclave 104E car la grappe de nœuds à laquelle il appartient peut à la fois être l'esclave d'une première grappe de nœuds et le maître d'une deuxième grappe de nœuds comme cela sera détaillé plus loin.
Un nœud de calcul 11, comprend M conteneurs ou « pods » 110j, j e {1, ... , M), M étant un entier naturel. Chaque conteneur 110j est doté de ressources permettant l'exécution d'une ou de plusieurs tâches. Une tâche lorsqu'elle est exécutée contribue à la mise en œuvre d'un service ou d'une fonction réseau, telle qu'une fonction DHCP (Dynamic Host Configuration Protocol ou protocole de configuration dynamique des hôtes) par exemple.
La [fig. 3] représente les étapes des procédés de contrôle et de configuration lorsqu'elles sont mises en œuvre par les différents constituants d'une grappe maître et d'une grappe esclave.
Dans une étape El, le module API 102M du nœud de gestion 10M de la grappe maître reçoit une demande de prise de contrôle DI d'une première grappe esclave. Une telle demande comprend un identifiant IdT d'au moins une tâche destinée à être exécutée par au moins un nœud de calcul II,E de la première grappe esclave. La demande de prise de contrôle peut être émise par un équipement d'un réseau de télécommunication géré par le même opérateur en télécommunication gérant la grappe maître.
Un exemple d'une telle demande de prise de contrôle DI est le suivant : apiVersion: apps/vx kind: CreateEsclave spec: esclave:
- name: IDESCLAVE ipEsclave: x.x.x.x deploymentEsclave: IFNOTEXISTCREATE apiVersion: apps/vx kind: DeploymentEsclave metadata: name: NameDeployement labels: app: LabelDeployement spec: replicas: NombreDeReplicat selector: matchLabels: app: LabelDeployement template: metadata: labels: app: LabelDeployement spec: esclave: IDESCLAVE/IPESCLAVE containers:
- nantie: NOMAPPLICATION image: NONCONTENEUR ports:
- containerPort: port resources: limits:
RESSOURCELIMITE requests:
RESSOURCEDEMANDE
Dans une étape E2, cette demande de prise de contrôle DI est transmise à la base de données 103M qui met à jour ses registres avec les informations comprises dans la demande de prise de contrôle DI telle que, en autre, un identifiant IdT d'au moins une tâche à exécuter par au moins un module de calcul II,E de la première grappe esclave, un identifiant de la première grappe esclave et des informations relatives à des conditions d'exécution de la tâche par le nœud de calcul lliE.
Au cours d'une étape E3, une boucle d'orchestration est mise en œuvre par la grappe maître. Une telle boucle d'orchestration est décrite en référence à la [fig. 4],
Une boucle d'orchestration est un processus mis en œuvre dans une grappe de nœuds au cours de laquelle les conditions d'exécution des tâches exécutées par les nœuds de calcul 11, sont mises à jour en fonction : d'informations comprises dans la base de données 103 et d'informations sur les conditions d'exécution courantes des tâches par les nœuds de calcul 11,.
Les informations sur les conditions d'exécution courantes des tâches sont remontées par les nœuds de calcul 11, au contrôleur 101 ou au module API 102. La mise à jour du contenu de la base de données 103 est indépendante de l'exécution d'une boucle d'orchestration.
La demande de prise de contrôle DI pouvant indiquer quelles tâches exécutées par les nœuds de calcul lli de la grappe de nœuds maître sont destinées à être exécutées par les nœuds de calcul 11, de la première grappe de nœuds esclave, la mise en œuvre d'une telle boucle d'orchestration permet de mettre à jour le fonctionnement de la grappe de nœuds maître.
Ainsi, l'exécution d'une boucle d'orchestration permet de passer d'un état de fonctionnement dit courant d'une grappe de nœuds, l'état courant étant défini notamment par les conditions d'exécution courantes des tâches par les nœuds de calcul 11, et le contenu courant des registres de la base de données 103, à un état de fonctionnement dit état attendu qui est défini entre autre par les conditions d'exécutions des tâches précisées dans la demande de prise de contrôle Dl. A l'issue de l'exécution de la boucle d'orchestration, l'état attendu de la grappe de nœuds devient le nouvel état courant.
Une telle boucle d'orchestration bien que décrite comme mise en œuvre au sein d'un nœud de gestion 10M appartenant à une grappe maître est mise en œuvre de manière identique au sein d'un nœud de gestion 10E appartenant à une première grappe esclave.
Ainsi, dans une étape G1 le contrôleur 101 ou le module de synchronisation 104 transmet une première demande d'informations DU à destination du module API 102. Dans une étape G2, le module API 102 transmet la demande d'informations DU à destination de la base de données 103 et à au moins un nœud de calcul 11,.
Au cours d'une étape G3, la base de données 103 et le nœud de calcul 11, transmettent les informations requises au module API 102. Le module API 102 transmet alors ces informations au contrôleur 101 ou au module de synchronisation 104 au cours d'une étape G4.
Dans une étape G5, le contrôleur 101 ou le module de synchronisation 104 transmet une requête RQT en application d'une configuration déterminée au moyen des informations reçues au cours de l'étape G4.
Une fois la boucle d'orchestration mise en œuvre, le module de synchronisation maître 104M crée un fichier de configuration FC et transmet ce dernier à destination du module API 102M dans une étape E4.
Le module API 102M transmet alors, dans une étape E5, le fichier de configuration FC de la première grappe esclave comprenant des paramètres de prise de contrôle et des conditions d'exécution attendues de ladite tâche par le nœud de calcul II,E, les conditions d'exécution attendues de la tâche étant identiques aux conditions d'exécution courantes de la même tâche par le nœud de calcul lliM.les conditions d'exécution comprises dans le fichier de configuration peuvent être des contraintes pour que les tâche s'exécutent correctement telles de que les ressources physiques comme CPU, GPU, antennes radio requises, mais aussi les ressources maximales autorisées pour une tâche donnée : nombre de CPU maximum, minimum de ressources en mémoire vive requises, etc.
Les tâches exécutées par la grappe maître peuvent être réparties en une pluralité de groupes de tâches, un groupe de tâches comprenant au moins une tâche. Dans une telle situation, le fichier de configuration FC comprend un identifiant d'au moins un groupe de tâches et les conditions d'exécution attendues relatives dudit groupe de tâches.
De tels groupes peuvent par exemple comprendre l'ensemble des tâches à exécuter pour livrer un service ou exécuter une fonction réseau. D'autres groupes peuvent comprendre des tâches de même nature, les tâches peuvent être également regroupées en fonction du type de ressources qu'elles requièrent pour leur exécution.
Chaque groupe est ensuite doté d'un identifiant et d'un ou plusieurs jeux de conditions d'exécution.
Seuls certains groupes de tâches peuvent être exécutés par les nœuds de calculs de la première grappe esclave tandis que d'autres sont exécutés uniquement par les nœuds de calculs de la grappe maître. Un même groupe de tâches peut être exécuté à la fois par les nœuds de calculs de la grappe maître et les nœuds de calculs de la première grappe esclave.
Le module API 102E du nœud de gestion 10E de la première grappe esclave reçoit le fichier de configuration FC au cours d'une étape E6 et le transmet à destination du module de synchronisation esclave 104E.
Au cours d'une étape E7, le module de synchronisation esclave 104E vérifie, auprès d'au moins un nœud de calcul II,E la disponibilité des ressources requises pour l'exécution de la tâche identifiées dans le fichier de configuration FC. Le module de synchronisation esclave 104E transmet le résultat de cette vérification à destination du module API 102E dans une étape E8. Le module API 102E transmet à son tour cette information à la base de données 103Equi met à jour ses registres dans une étape E9.
Si, dans un premier cas, le module de synchronisation esclave 104E a déterminé que les ressources requises sont disponibles, il transmet un message MC, dit message de confirmation, comprenant des informations relatives à la mise en oeuvre, par la grappe esclave, de la configuration requise et donc indiquant la prise de contrôle de la première grappe esclave par la grappe maître au module API 102E qui le transmet à son tour au module API 102M du nœud de gestion 10M de la grappe maître au cours d'une étape E10. Les étapes E8 et E10 peuvent être exécutées simultanément.
Parallèlement à l'exécution de l'étape E10, la première grappe esclave met en œuvre, dans une étape Eli, une boucle d'orchestration telle que décrite en référence à la figure 4 afin de configurer l'ensemble des nœuds de calculs II,E de la première grappe esclave aves les conditions d'exécution comprises dans le fichier de configuration émis par la grappe maître.
A l'issue de cette étape Eli, la première grappe esclave est contrôlée par la grappe maître et présente un fonctionnement identique à celui de la grappe maître. En d'autres mots, à l'issue de l'étape Eli les tâches exécutées par les nœuds de calcul II,E de la première grappe esclave sont exécutées de la même manière, dans les mêmes conditions et avec les mêmes contraintes que lorsqu'elles sont exécutées par les nœuds de calcul II,M de la grappe maître.
Enfin dans une étape E12, le module API 102M du nœud de gestion 10M de la grappe maître transmet le message de confirmation MC au module de synchronisation maître 104M.
Une fois la prise de contrôle de la première grappe esclave effectué, la première grappe esclave transmet à destination du module API 102 de la grappe maître de manière récurrente des données relatives à l'exécution des tâches exécutées par ses nœuds de calcul II,E.
Si, dans un deuxième cas, au cours de l'étape E7, le module de synchronisation esclave 104E a déterminé que les ressources requises ne sont pas disponibles, le module de synchronisation esclave 104E transmet le résultat de cette vérification à destination du module API 102E dans l'étape E8. Le module API 102E transmet à son tour cette information à la base de données 103E qui met à jour ses registres dans l'étape E9.
Lorsque le module de synchronisation esclave 104E a déterminé que les ressources requises ne sont pas disponibles, il transmet alors un message d'échec EC de la prise de contrôle de la première grappe esclave par la grappe maître au module API 102E qui le transmet à son tour au module API 102M du nœud de gestion 10M de la grappe maître au cours de l'étape E10.
Dans un deuxième mode de réalisation lorsqu'au cours de l'étape E7, le module de synchronisation esclave 104E a déterminé que les ressources requises ne sont pas disponibles, le module de synchronisation esclave 104E transmet le résultat de cette vérification à la base de données 103E dans l'étape E8'.
Ce deuxième mode de réalisation ne peut être mis en œuvre que si la grappe maître autorise explicitement la prise de contrôle d'une deuxième grappe esclave par la première grappe esclave. Une telle autorisation est comprise dans le fichier de configuration FC transmis au cours de l'étape E5.
Dans une étape E9', la base de données 103E met à jour ses registres avec les résultats de la vérification. Au cours d'une étape E10', une boucle d'orchestration est mise en oeuvre par la première grappe esclave afin d'instancier un module de synchronisation maître 104M dans le nœud de gestion 10E de la première grappe esclave
Une fois la boucle d'orchestration mise en œuvre, le module de synchronisation maître 104M du nœud de gestion 10E de la première grappe esclave est instancié et transmet une demande de prise de contrôle D3 d'une deuxième grappe esclave à destination du module API 102E dans une étape E1 . La demande de prise de contrôle D3 comprend un fichier de configuration FC2 d'une deuxième grappe esclave créé par le module de synchronisation maître 104M.
Dans une autre implémentation dans laquelle le nœud de gestion 10E de la première grappe esclave comprend déjà un module de synchronisation maître 104M, le module de synchronisation maître 104M du nœud de gestion 10E transmet, directement après l'étape E7, une demande de prise de contrôle D3 de la deuxième grappe esclave à destination du module API 102E dans une étape E1 .
Le module API 102E transmet alors, dans une étape E12', le fichier de configuration FC2 de la deuxième grappe esclave comprenant des paramètres de prise de contrôle et des conditions d'exécution attendues de ladite tâche par un nœud de calcul II,E de la deuxième grappe esclave, les conditions d'exécution attendues de la tâche étant identiques aux conditions d'exécution courantes de la même tâche par le nœud de calcul II,M de la grappe maître. Le fichier de configuration FC2 est créé au cours de l'exécution de l'étape E1 .
Un module API 102E d'un nœud de gestion 10E de la deuxième grappe esclave reçoit le fichier de configuration FC2 et le transmet à destination d'un module de synchronisation esclave 104E de la deuxième grappe esclave.
Le module de synchronisation esclave 104E de la deuxième grappe esclave vérifie, auprès d'au moins un nœud de calcul II,E de la deuxième grappe esclave la disponibilité des ressources requises pour l'exécution de la tâche identifiées dans le fichier de configuration FC2. Le module de synchronisation esclave 104E de la deuxième grappe esclave transmet le résultat de cette vérification à destination du module API 102E de la deuxième grappe esclave. Le module API 102E de la deuxième grappe esclave transmet à son tour cette information à la base de données 103Ede la deuxième grappe esclave qui met à jour ses registres.
Lorsque le module de synchronisation esclave 104E de la deuxième grappe esclave a déterminé que les ressources requises sont disponibles, il transmet un message de confirmation MC2 de la prise de contrôle de la deuxième grappe esclave par la première grappe esclave au module API 102E de la deuxième grappe esclave qui le transmet à son tour au module API 102E du nœud de gestion 10E de la première grappe esclave au cours d'une étape E13'.
Parallèlement, la deuxième grappe esclave met en œuvre une boucle d'orchestration telle que décrite en référence à la figure 4 afin de configurer l'ensemble des nœuds de calculs II,E de la deuxième grappe esclave aves les conditions d'exécution comprises dans le fichier de configuration FC2.
A l'issue de cette étape E13', la deuxième grappe esclave est contrôlée par la première grappe esclave, elle-même contrôlée par la grappe maître, et présente un fonctionnement identique à celui de la grappe maître. Enfin dans une étape E14', le module API 102E du nœud de gestion 10E de la première grappe esclave transmet le message de confirmation MC2 au module API 102M du nœud de gestion 10M de la grappe maître qui le transmet à son tour au module de synchronisation maître 104M.
Une fois la prise de contrôle de la deuxième grappe esclave effectué, la première grappe esclave transmet de manière récurrente des données relatives à l'exécution des tâches exécutées par les nœuds de calcul II,E de la deuxième grappe esclave à destination de la grappe maître.
Lorsque les circonstances l'exigent, par exemple lorsque le satellite embarquant la première grappe esclave ne survole plus le territoire dans lequel se situe la grappe maître, la première grappe esclave peut être affranchie et ainsi retrouver son indépendance afin d'être utilisée de manière autonome ou sous le contrôle d'une nouvelle grappe maître.
Dans une étape E13, le module API 102M de la grappe maître reçoit une demande d'affranchissement DA de première grappe esclave.
Dans une étape E14, cette demande d'affranchissement DA est transmise à la base de données 103M qui met à jour ses registres avec les informations comprises dans la demande d'affranchissement DA.
Au cours d'une étape E15, une boucle d'orchestration est mise en œuvre par la grappe maître.
Une fois la boucle d'orchestration mise en œuvre, le module de synchronisation maître 104M transmet une demande d'affranchissement DA2 de la première grappe esclave à destination du module API 102M dans une étape E16.
Le module API 102M transmet alors, dans une étape E17, un fichier de configuration FC3 de la première grappe esclave comprenant des paramètres d'affranchissement de ladite première grappe esclave.
Le module API 102E du nœud de gestion 10E de la première grappe esclave reçoit le fichier de configuration FC3 au cours d'une étape E18 et le transmet à destination du module de synchronisation esclave 104E.
Au cours d'une étape E19, le module de synchronisation esclave 104E traite le fichier de configuration FC3 et transmet le résultat de traitement à destination du module API 102E dans une étape E20. Le module API 102E transmet à son tour cette information à la base de données 103E qui met à jour ses registres.
Lorsque le module de synchronisation esclave 104E a traité le fichier de configuration FC3, il transmet un message d'affranchissement de la première grappe esclave au maître au module API 102E qui le transmet à son tour au module API 102M du nœud de gestion 10M de la grappe maître au cours d'une étape E21.
Parallèlement à l'exécution de l'étape E21, la première grappe esclave met en œuvre, dans une étape E22, une boucle d'orchestration telle que décrite en référence à la figure 4 afin de configurer l'ensemble des nœuds de calculs II,E de la première grappe esclave.
A l'issue de cette étape E21, la première grappe esclave n'est plus contrôlée par la grappe maître et fonctionne de manière autonome.
Une procédure identique peut être mise en œuvre entre la première grappe esclave et la deuxième grappe esclave afin de mettre fin au contrôle de la deuxième grappe esclave par la première grappe esclave. La [fig. 5] représente les étapes des procédés de contrôle et de configuration lorsqu'elles sont mises en oeuvre par les différents constituants d'une grappe maître et d'une première grappe esclave dans le cas où, la première grappe esclave étant déjà contrôlée par la grappe maître, la configuration de la grappe maître est mise à jour. Typiquement l'enchaînement d'étapes décrit en référence à la figure 5 se situe entre les étapes E12 et E13 décrites en référence à la figure 3.
Dans une étape Fl, le module API 102M du nœud de gestion 10M de la grappe maître reçoit une demande de mise à jour MàJl de la configuration de la grappe maître. Une telle demande de mise à jour MàJl comprend un identifiant IdT d'au moins une tâche destinée à être exécutée par au moins un nœud de calcul II,M de la grappe maître. La demande de mise à jour MàJl peut être émise par un équipement d'un réseau de télécommunication géré par le même opérateur en télécommunication gérant la grappe maître. Une telle demande de mise à jour MàJl semblable à une demande de prise de contrôle telle que celle décrite en référence à la figure 3.
Un exemple d'une telle demande de mise à jour MàJl de la configuration est le suivant : apiVersion: apps/vx kind: DeploymentEsclave metadata: name: NameDeployement labels: app: LabelDeployement spec: replicas: NombreDeReplicat selector: matchLabels: app: LabelDeployement template: metadata: labels: app: LabelDeployement spec: esclave: IDESCLAVE/IPESCLAVE containers:
- name: NOMAPPLICATION image: NONCONTENEUR ports:
- containerPort: port resources: limits:
RESSOURCELIMITE requests:
RESSOURCEDEMANDE
Dans une étape F2, cette demande de mise à jour MàJl est transmise à la base de données 103M qui met à jour ses registres avec les informations comprises dans la demande de mise à jour MàJl telle que, en autre, un identifiant IdT d'au moins une tâche à exécuter par au moins un module de calcul II,M de la grappe maître et des informations relatives à des conditions d'exécution de la tâche par le nœud de calcul II,M.
Au cours d'une étape F3, une boucle d'orchestration est mise en œuvre par la grappe maître.
Une fois la boucle d'orchestration mise en œuvre, la configuration de la grappe maître est mise à jour. Suite à cette mise à jour de la configuration de la grappe maître, certaines tâches peuvent avoir changé de conditions d'exécution, de nouvelles tâches peuvent être exécutées et certaines tâches peuvent être terminées.
Le module de synchronisation maître 104M crée et transmet alors un fichier de mise à jour de configuration MàJFC de la première grappe esclave à destination du module API 102M dans une étape F4.
Le module API 102M transmet alors, dans une étape F5, le fichier de mise à jour de configuration MàJFC de la première grappe esclave comprenant des conditions d'exécution attendues de ladite tâche par nœud de calcul II,E, les conditions d'exécution attendues de la tâche étant identiques aux conditions d'exécution courantes de la même tâche par le nœud de calcul lliM, c'est-à-dire les conditions dans lesquelles les tâches sont exécutées par le nœud de calcul lliM suite à la mise en œuvre de la boucle d'orchestration à l'étape F3.
Le module API 102E du nœud de gestion 10E de la première grappe esclave reçoit le fichier de mise à jour de configuration MàJFC au cours d'une étape F6 et le transmet à destination du module de synchronisation esclave 104E.
Au cours d'une étape F7, le module de synchronisation esclave 104E vérifie, par exemple auprès d'au moins un nœud de calcul II,E la disponibilité des ressources requises pour l'exécution de la tâche identifiées dans le fichier de mise à jour de configuration MàJFC. Le module de synchronisation esclave 104E transmet le résultat de cette vérification à destination du module API 102E dans une étape F8. Le module API 102E transmet à son tour cette information à la base de données 103E qui met à jour ses registres dans une étape F9.
Si, dans un premier cas, le module de synchronisation esclave 104E a déterminé que les ressources requises sont disponibles, il transmet un message comprenant des informations relatives à la mise en œuvre de la mise à jour requise, dit message de confirmation MC de la mise à jour, de la première grappe esclave au module API 102E qui le transmet à son tour au module API 102M du nœud de gestion 10M de la grappe maître au cours d'une étape F10.
Parallèlement à l'exécution de l'étape F10, la première grappe esclave met en œuvre, dans une étape Fil, une boucle d'orchestration telle que décrite en référence à la figure 4 afin de configurer l'ensemble des nœuds de calculs II,E de la première grappe esclave aves les conditions d'exécution comprises dans le fichier de mise à jour de configuration émis par la grappe maître.
A l'issue de cette étape Fil, la première grappe esclave est mise à jour et présente un fonctionnement identique à celui de la grappe maître.
Enfin dans une étape F12, le module API 102M du nœud de gestion 10M de la grappe maître transmet le message de confirmation MC de la mise à jour au module de synchronisation maître 104M de la grappe maître.
Une fois la mise à jour de la première grappe esclave effectuée, la première grappe esclave transmet de manière récurrente des données relatives à l'exécution des tâches exécutées par ses nœuds de calcul II,E.
Si, dans un deuxième cas, au cours de l'étape F7, le module de synchronisation esclave 104E a déterminé que les ressources requises ne sont pas disponibles, le module de synchronisation esclave 104E transmet le résultat de cette vérification à destination du module API 102E dans l'étape F8. Le module API 102E transmet à son tour cette information à la base de données 103E qui met à jour ses registres dans l'étape F9. Lorsque le module de synchronisation esclave 104E a déterminé que les ressources requises ne sont pas disponibles, il transmet alors un message d'échec EC de la mise à jour de la première grappe esclave au module API 102E qui le transmet à son tour au module API 102M du nœud de gestion 10M de la grappe maître au cours de l'étape F10.
Dans un deuxième mode de réalisation dans lequel le nœud de gestion 10E de la première grappe esclave a été autorisé explicitement à prendre le contrôle de la deuxième grappe esclave par la première grappe esclave, la base de données 103E met à jour ses registres avec les résultats de la vérification au cours d'une étape F9'.
Au cours d'une étape F10', une boucle d'orchestration est mise en œuvre par la première grappe esclave afin d'instancier un module de synchronisation maître 104M dans le nœud de gestion 10E de la première grappe esclave.
Une fois la boucle d'orchestration mise en œuvre, le module de synchronisation maître 104M du nœud de gestion 10E de la première grappe esclave est instancié et transmet une demande de mise à jour de la deuxième grappe esclave à destination du module API 102E dans une étape FU'. La demande de mise à jour de la deuxième grappe esclave D3 comprend un fichier de mise à jour de configuration MàJFC2 de la deuxième grappe esclave créé par le module de synchronisation maître 104M.
Dans une autre implémentation dans laquelle le nœud de gestion 10E de la première grappe esclave comprend déjà un module de synchronisation maître 104M, le module de synchronisation maître 104M du nœud de gestion 10E transmet, directement après l'étape F7, une demande de mise à jour de la deuxième grappe esclave à destination du module API 102E dans une étape Fil'.
Le module API 102E transmet alors, dans une étape F12', le fichier de mise à jour de configuration MàJFC2 de la deuxième grappe esclave comprenant des conditions d'exécution attendues de ladite tâche par un nœud de calcul II,E de la deuxième grappe esclave, les conditions d'exécution attendues de la tâche étant identiques aux conditions d'exécution courantes de la même tâche par le nœud de calcul II,M de la grappe maître. Le fichier de configuration MàJFC2 est créé au cours de l'étape FU'.
Un module API 102E d'un nœud de gestion 10E de la deuxième grappe esclave reçoit le fichier de mise à jour de configuration MàJFC2 et le transmet à destination d'un module de synchronisation esclave 104E de la deuxième grappe esclave.
Le module de synchronisation esclave 104E de la deuxième grappe esclave vérifie, auprès d'au moins un nœud de calcul II,E de la deuxième grappe esclave la disponibilité des ressources requises pour l'exécution de la tâche identifiées dans le fichier de mise à jour de configuration MàJFC2. Le module de synchronisation esclave 104E de la deuxième grappe esclave transmet le résultat de cette vérification à destination du module API 102E de la deuxième grappe esclave. Le module API 102E de la deuxième grappe esclave transmet à son tour cette information à la base de données 103E de la deuxième grappe esclave qui met à jour ses registres.
Lorsque le module de synchronisation esclave 104E de la deuxième grappe esclave a déterminé que les ressources requises sont disponibles, il transmet un message de confirmation MC2 de la mise à jour de la deuxième grappe esclave au module API 102E de la deuxième grappe esclave qui le transmet à son tour au module API 102E du nœud de gestion 10E de la première grappe esclave au cours d'une étape F13'. Parallèlement, la deuxième grappe esclave met en œuvre une boucle d'orchestration telle que décrite en référence à la figure 4 afin de configurer l'ensemble des nœuds de calculs II,E de la deuxième grappe esclave aves les conditions d'exécution comprises dans le fichier de mise à jour de configuration MàJFC2.
A l'issue de cette étape F13', la deuxième grappe esclave est mise à jour et présente un fonctionnement identique à celui de la grappe maître.
Enfin dans une étape F14', le module API 102E du nœud de gestion 10E de la première grappe esclave transmet le message de confirmation MC2 au module API 102M du nœud de gestion 10M de la grappe maître qui le transmet à son tour au module de synchronisation maître 104M.
Une fois la mise à jour de la deuxième grappe esclave effectué, la première grappe esclave transmet de manière récurrente des données relatives à l'exécution des tâches exécutées par les nœuds de calcul II,E de la deuxième grappe esclave à destination de la grappe maître.
La [fig. 6] représente les étapes des procédés de contrôle et de configuration lorsqu'elles sont mises en œuvre par les différents constituants d'une grappe maître et d'une première grappe esclave dans le cas où, la première grappe esclave étant déjà contrôlée par la grappe maître, la grappe esclave détecte une erreur. Typiquement l'enchaînement d'étapes décrit en référence la figure 6 se situe entre les étapes E12 et E13 décrites en référence à la figure 3.
Dans une étape Hl, le module API 102E du nœud de gestion 10E de la première grappe esclave reçoit un message d'erreur Pb transmis par exemple par une antenne radio d'un nœud d'accès d'un réseau de communication, le nœud d'accès étant contrôlé par la première grappe esclave qui exécute pour lui des fonctions réseau telles que des fonctions de codage par exemple.
Dans une étape H2, le module API 102E du nœud de gestion 10E transmet le message d'erreur Pb à destination du module de synchronisation esclave 104E de la première grappe esclave.
Au cours d'une étape H3, le module de synchronisation esclave 104E vérifie la capacité de la première grappe esclave à résoudre l'erreur elle-même.
Si la première grappe esclave est capable de résoudre l'erreur elle-même, elle le fait au cours d'une étape H4.
Si la première grappe esclave n'est pas capable de résoudre l'erreur elle-même, le module de synchronisation esclave 104E transmet cette information à destination du module API 102E dans une étape H5.
Le module API 102E transmet à son tour cette information au module API 102M de la grappe maître dans une étape H6. Le module API 102M de la grappe maître transmet à son tour cette information au module de synchronisation maître 104M dans une étape H7.
Au cours d'une étape H8, le module de synchronisation maître 104M détermine une solution pour résoudre l'erreur et génère un fichier de correction.
Le module de synchronisation maître 104M transmet le fichier de correction au module API 102M dans une étape H9.
Le module API 102M transmet le fichier de correction à destination du module API 102E au cours d'une étape H10.
Le module de synchronisation esclave 104E reçoit, dans une étape Hll, le fichier de correction qui lui est transmis par le module API 102E. Au cours d'une étape H12, une boucle d'orchestration est mise en oeuvre par la grappe maître afin de prendre en compte les informations du fichier de correction lors de l'exécution des tâches par les noeuds de calcul II,M.
Au cours d'une étape H13, une boucle d'orchestration est mise en oeuvre par la première grappe maître afin de prendre en compte les informations du fichier de correction lors de l'exécution des tâches par les noeuds de calcul II,E et ainsi réparer l'erreur.
La [fig. 7] représente les étapes des procédés de contrôle et de configuration lorsqu'elles sont mises en oeuvre par les différents constituants d'une grappe maître et d'une première grappe esclave dans le cas où les messages échangés entre la grappe maître et la première grappe esclave sont relayés par un équipement intermédiaire.
Ainsi, lorsque le module API 102M souhaite transmette un fichier de configuration FC de première grappe esclave au cours de l'étape E5 ou un fichier de mise à jour de configuration MàJFC au cours de l'étape F5, le message comprenant ce fichier de configuration ou de mise à jour de configuration est transmis à destination d'un équipement intermédiaire qui sert alors de relai.
Dans une étape Jl, l'équipement intermédiaire R reçoit le message comprenant ce fichier de configuration ou de mise à jour de configuration destiné à être relayé à la première grappe esclave.
Au cours d'une étape J2, l'équipement intermédiaire R applique des règles de sécurité et de filtrage au message reçu. De telles règles sont par exemple fixées par l'opérateur de télécommunication gestionnaire de la grappe maître et souhaitant prendre le contrôle ou mettre à jour la première grappe esclave. L'équipement intermédiaire R vérifie également qu'il est en capacité de communiquer avec la première grappe esclave.
Si l'équipement intermédiaire R détermine que le message à transmettre à la première grappe esclave ne peut être relayé, il en informe la grappe maître au cours d'une étape J3 et indique les raisons de ce refus.
Si l'équipement intermédiaire R détermine que le message à transmettre à la première grappe esclave peut être relayé, il transmet le message à la première grappe esclave au cours d'une étape J4.
La grappe maître est informée de la bonne transmission du message à la première grappe esclave lorsque l'équipement intermédiaire lui transmet au cours d'une étape J5 un message de confirmation de la prise de contrôle de la première grappe esclave ou un message de confirmation de mise à jour de la première grappe esclave.
La [fig. 8] représente nœud de gestion 10 apte à mettre en œuvre les différents procédés objets de la présente invention.
Un nœud de gestion 10 peut comprendre au moins un processeur matériel 801, une unité de stockage 802, une interface 803, et au moins une interface de réseau 804 qui sont connectés entre eux au travers d'un bus 805 en plus du module API 102, du contrôleur 101, de la base données 103 et du/des modules de synchronisation 104. Bien entendu, les éléments constitutifs du nœud de gestion 10 peuvent être connectés au moyen d'une connexion autre qu'un bus.
Le processeur 801 commande les opérations du nœud de gestion 10. L’unité de stockage 802 stocke au moins un programme pour la mise en œuvre des différents procédés objets de l'invention à exécuter par le processeur 801, et diverses données, telles que des paramètres utilisés pour des calculs effectués par le processeur 801, des données intermédiaires de calculs effectués par le processeur 801, etc. Le processeur 801 peut être formé par tout matériel ou logiciel connu et approprié, ou par une combinaison de matériel et de logiciel. Par exemple, le processeur 801 peut être formé par un matériel dédié tel qu'un circuit de traitement, ou par une unité de traitement programmable telle qu'une unité centrale de traitement (Central Processing Unit) qui exécute un programme stocké dans une mémoire de celui-ci.
L'unité de stockage 802 peut être formée par n'importe quel moyen approprié capable de stocker le programme ou les programmes et des données d'une manière lisible par un ordinateur. Des exemples d'unité de stockage 802 comprennent des supports de stockage non transitoires lisibles par ordinateur tels que des dispositifs de mémoire à semi-conducteurs, et des supports d'enregistrement magnétiques, optiques ou magnéto-optiques chargés dans une unité de lecture et d'écriture.
L'interface 803 fournit une interface entre le nœud de gestion 10 et au moins un nœud de calcul 11, appartenant à la même grappe de nœuds que le nœud de gestion 10.
L'interface réseau 804 fournit quant à elle une connexion entre le nœud de gestion 10 et un autre nœud de gestion d'une autre grappe de nœuds.

Claims

REVENDICATIONS
1. Procédé de contrôle d'une première grappe de noeuds, dite grappe esclave, par une deuxième grappe de noeuds, dite grappe maître, une grappe de noeuds comprenant au moins un nœud de calcul exécutant au moins une tâche, ledit procédé de contrôle étant mis en œuvre par ladite grappe maître et comprenant les étapes suivantes :
- réception d'une demande de prise de contrôle de ladite grappe esclave identifiant au moins une tâche destinée à être exécutée par au moins un nœud de calcul de ladite grappe esclave,
- création d'un fichier de configuration de ladite grappe esclave comprenant des paramètres de prise de contrôle et des conditions d'exécution attendues de ladite tâche par ledit au moins un nœud de calcul de ladite grappe esclave, lesdites conditions d'exécution attendues de ladite tâche étant identiques aux conditions d'exécution courantes de ladite tâche par au moins un nœud de calcul de ladite grappe maître,
- transmission dudit fichier de configuration à destination de ladite grappe esclave,
- réception d'un message comprenant des informations relatives à la mise en œuvre, par la grappe esclave, de la configuration requise.
2. Procédé de contrôle d'une grappe de nœuds esclave selon la revendication 1 dans lequel les tâches exécutées par la grappe maître étant réparties en une pluralité de groupes de tâches, un groupe de tâches comprenant au moins une tâche, le fichier de configuration comprend un identifiant d'au moins un groupe de tâches et les conditions d'exécution attendues relatives dudit groupe de tâches.
3. Procédé de contrôle d'une grappe de nœuds esclave selon la revendication 1 comprenant en outre les étapes suivantes :
- réception d'une demande de modification de la configuration de ladite grappe maître comprenant des conditions d'exécution attendues de ladite tâche par ledit au moins un nœud de calcul de ladite grappe maître,
- configuration de ladite grappe maître au moyen desdites conditions d'exécution attendues, lesdites conditions d'exécution attendues devenant, à l'issue de ladite étape de configuration, les nouvelles conditions d'exécution courantes de ladite tâche,
- création d'un fichier de mise à jour de la configuration de ladite grappe esclave comprenant les conditions d'exécution attendues de ladite tâche par ledit au moins un nœud de calcul de ladite grappe esclave, lesdites conditions d'exécution attendues de ladite tâche étant identiques aux nouvelles conditions d'exécution courantes de ladite tâche par au moins un nœud de calcul de ladite grappe maître,
- transmission dudit fichier de mise à jour de la configuration à destination de ladite grappe esclave.
4. Procédé de contrôle d'une grappe de nœuds esclave selon la revendication 3 dans lequel lorsque la mise à jour de la configuration de la grappe esclave échoue, le procédé comprend en outre une étape de réception d'un message indiquant l'échec de la mise à jour de la configuration par la grappe esclave.
5. Procédé de contrôle d'une grappe de nœuds esclave selon la revendication 4 comprenant en outre une étape de réception d'un message comprenant des informations relatives à la mise en œuvre, par la grappe esclave, de la mise à jour de la configuration d'au moins une autre grappe esclave à destination de laquelle la grappe esclave a transmis un fichier de configuration comprenant des conditions d'exécution attendues de ladite tâche par ledit au moins un nœud de calcul de ladite autre grappe esclave, lesdites conditions d'exécution attendues de ladite tâche étant identiques aux conditions d'exécution courantes de ladite tâche par au moins un nœud de calcul de ladite grappe maître.
6. Procédé de contrôle d'une grappe de nœuds esclave selon l'une quelconque des revendications précédentes, le procédé comprenant une étape de réception d'un message émis par un équipement intermédiaire indiquant l'impossibilité de transmettre un fichier de configuration à ladite grappe esclave.
7. Procédé de contrôle d'une grappe de nœuds esclave selon l'une quelconque des revendications précédentes comprenant :
- une étape de réception d'un message d'erreur émis par la grappe esclave,
- une étape de création d'un fichier de réparation de ladite grappe esclave comprenant des paramètres de réparation de ladite grappe esclave,
- transmission dudit fichier de réparation à destination de ladite grappe esclave.
8. Procédé de contrôle d'une grappe de nœuds esclave selon l'une quelconque des revendications précédentes comprenant :
- une étape de réception d'une demande d'affranchissement de ladite grappe esclave,
- une étape de création d'un fichier de configuration de ladite grappe esclave comprenant des paramètres d'affranchissement de ladite grappe esclave,
- une étape de transmission dudit fichier de configuration à destination de ladite grappe esclave.
9. Procédé de configuration d'une première grappe de nœuds, dite grappe esclave, par une deuxième grappe de nœuds, dite grappe maître, une grappe de nœuds comprenant au moins un nœud de calcul exécutant au moins une tâche, ledit procédé de configuration étant mis en œuvre par ladite grappe esclave et comprenant les étapes suivantes :
- réception d'un fichier de configuration de ladite grappe esclave comprenant des paramètres de prise de contrôle et des conditions d'exécution attendues de ladite tâche par ledit au moins un nœud de calcul de ladite grappe esclave, lesdites conditions d'exécution attendues de ladite tâche étant identiques à des conditions d'exécution courantes de ladite tâche par au moins un nœud de calcul de ladite grappe maître,
- vérification d'une disponibilité des ressources requises pour l'exécution de ladite tâche,
- lorsque les ressources requises sont disponibles, configuration de ladite grappe esclave au moyen dudit fichier de configuration,
- transmission, à destination de la grappe maître, d'un message comprenant des informations relatives à la mise en œuvre, par la grappe esclave, de la configuration requise.
10. Procédé de configuration d'une grappe de nœuds esclave selon la revendication 9 comprenant en outre les étapes suivantes :
- réception d'un fichier de mise à jour de la configuration de ladite grappe esclave comprenant des conditions d'exécution attendues de ladite tâche par ledit au moins un nœud de calcul de ladite grappe esclave, lesdites conditions d'exécution attendues de ladite tâche étant identiques à des nouvelles conditions d'exécution courantes de ladite tâche par au moins un nœud de calcul de ladite grappe maître,
- vérification d'une disponibilité des ressources requises pour l'exécution de ladite tâche,
- lorsque les ressources requises sont disponibles, mise à jour de la configuration de ladite grappe esclave au moyen dudit fichier de mise à jour de la configuration,
- transmission, à destination de la grappe maître, d'un message comprenant des informations relatives à la mise en oeuvre, par la grappe esclave, de la configuration requise.
11. Procédé de configuration d'une grappe de noeuds esclave selon la revendication 10 dans lequel lorsque les ressources requises ne sont pas disponibles, le procédé comprend en outre une étape d'émission d'un message indiquant l'échec de la mise à jour de la configuration à destination de la grappe maître.
12. Procédé de configuration d'une grappe de noeuds esclave selon la revendication 11 comprenant en outre lorsque les ressources requise ne sont pas disponibles :
- une étape de transmission d'un fichier de configuration comprenant des conditions d'exécution attendues de ladite tâche par au moins un nœud de calcul d'une autre grappe esclave, lesdites conditions d'exécution attendues de ladite tâche étant identiques aux conditions d'exécution courantes de ladite tâche par au moins un nœud de calcul de ladite grappe maître,
- une étape de réception d'un message comprenant des informations relatives à la mise en œuvre, par ladite autre grappe esclave, de la configuration requise,
- une étape de transmission, à destination de la grappe maître, d'un message comprenant des informations relatives à la mise en œuvre, par ladite autre grappe esclave, de la configuration requise.
13. Nœud de gestion d'une première grappe de nœuds, dite grappe maître, capable de contrôler une deuxième grappe de nœuds, dite grappe esclave, une grappe de nœuds comprenant également au moins un nœud de calcul exécutant au moins une tâche, ledit nœud de gestion de la grappe maître comprenant des moyens pour :
- recevoir une demande de prise de contrôle de ladite grappe esclave identifiant au moins une tâche destinée à être exécutée par au moins un nœud de calcul de ladite grappe esclave,
- créer un fichier de configuration de ladite grappe esclave comprenant des paramètres de prise de contrôle et des conditions d'exécution attendues de ladite tâche par ledit au moins un nœud de calcul de ladite grappe esclave, lesdites conditions d'exécution attendues de ladite tâche étant identiques aux conditions d'exécution courantes de ladite tâche par au moins un nœud de calcul de ladite grappe maître,
- transmettre le fichier de configuration à destination de ladite grappe esclave,
- recevoir un message comprenant des informations relatives à la mise en œuvre, par la grappe esclave, de la configuration requise.
14. Nœud de gestion d'une première grappe de nœuds, dite grappe esclave, capable de configurer ladite grappe esclave, une grappe de nœuds comprenant également au moins un nœud de calcul exécutant au moins une tâche, ledit nœud de gestion de la grappe esclave comprenant des moyens pour :
- recevoir, depuis une deuxième grappe de nœuds, dite grappe maître, un fichier de configuration de ladite grappe esclave comprenant des paramètres de prise de contrôle et des conditions d'exécution attendues de ladite tâche par ledit au moins un nœud de calcul de ladite grappe esclave, lesdites conditions d'exécution attendues de ladite tâche étant identiques à des conditions d'exécution courantes de ladite tâche par au moins un nœud de calcul de ladite grappe maître,
- vérifier une disponibilité des ressources requises pour l'exécution de ladite tâche,
- lorsque les ressources requises sont disponibles, configurer ladite grappe esclave au moyen dudit fichier de configuration, - transmettre, à destination de la grappe maître, un message comprenant des informations relatives à la mise en oeuvre, par la grappe esclave, de la configuration requise.
15. Produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en oeuvre d'un procédé selon l’une des revendications 1 à 12, lorsqu'il est exécuté par un processeur
EP22711083.0A 2021-02-25 2022-02-16 Procédé de contrôle d'une grappe de noeuds esclave par une grappe de noeuds maître, dispositifs et programmes d'ordinateurs correspondants Pending EP4298766A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2101850A FR3120172A1 (fr) 2021-02-25 2021-02-25 Procédé de contrôle d’une grappe de nœuds esclave par une grappe de nœuds maître, dispositifs et programmes d’ordinateurs correspondants
PCT/FR2022/050279 WO2022180323A1 (fr) 2021-02-25 2022-02-16 Procédé de contrôle d'une grappe de noeuds esclave par une grappe de noeuds maître, dispositifs et programmes d'ordinateurs correspondants

Publications (1)

Publication Number Publication Date
EP4298766A1 true EP4298766A1 (fr) 2024-01-03

Family

ID=75746845

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22711083.0A Pending EP4298766A1 (fr) 2021-02-25 2022-02-16 Procédé de contrôle d'une grappe de noeuds esclave par une grappe de noeuds maître, dispositifs et programmes d'ordinateurs correspondants

Country Status (5)

Country Link
US (1) US20240146605A1 (fr)
EP (1) EP4298766A1 (fr)
CN (1) CN116888934A (fr)
FR (1) FR3120172A1 (fr)
WO (1) WO2022180323A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117370468A (zh) * 2023-11-09 2024-01-09 浙江智臾科技有限公司 数据同步方法以及集群系统
CN118377836B (zh) * 2024-06-25 2024-11-01 天津南大通用数据技术股份有限公司 一种数据库管理方法、装置、终端及存储介质

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8280944B2 (en) * 2005-10-20 2012-10-02 The Trustees Of Columbia University In The City Of New York Methods, media and systems for managing a distributed application running in a plurality of digital processing devices
US20080098113A1 (en) * 2006-10-19 2008-04-24 Gert Hansen Stateful firewall clustering for processing-intensive network applications
US20080172679A1 (en) * 2007-01-11 2008-07-17 Jinmei Shen Managing Client-Server Requests/Responses for Failover Memory Managment in High-Availability Systems
US7631214B2 (en) * 2007-05-31 2009-12-08 International Business Machines Corporation Failover processing in multi-tier distributed data-handling systems
US20090157766A1 (en) * 2007-12-18 2009-06-18 Jinmei Shen Method, System, and Computer Program Product for Ensuring Data Consistency of Asynchronously Replicated Data Following a Master Transaction Server Failover Event
CN102479099B (zh) * 2010-11-22 2015-06-10 中兴通讯股份有限公司 虚拟机管理系统及其使用方法
US9154577B2 (en) * 2011-06-06 2015-10-06 A10 Networks, Inc. Sychronization of configuration file of virtual application distribution chassis
EP2901312B1 (fr) * 2012-09-28 2019-01-02 Cycle Computing LLC Optimisation en temps réel d'une infrastructure de calcul dans un environnement virtualisé
US10693955B2 (en) * 2013-12-14 2020-06-23 Netapp, Inc. Techniques for SAN storage cluster synchronous disaster recovery
US9619243B2 (en) * 2013-12-19 2017-04-11 American Megatrends, Inc. Synchronous BMC configuration and operation within cluster of BMC
US20150229715A1 (en) * 2014-02-13 2015-08-13 Linkedin Corporation Cluster management
US20170308446A1 (en) * 2014-10-23 2017-10-26 Telefonaktiebolaget Lm Ericsson (Publ) System and method for disaster recovery of cloud applications
US10083057B1 (en) * 2016-03-29 2018-09-25 EMC IP Holding Company LLC Migration of active virtual machines across multiple data centers
US10609130B2 (en) * 2017-04-28 2020-03-31 Microsoft Technology Licensing, Llc Cluster resource management in distributed computing systems
US10762234B2 (en) * 2018-03-08 2020-09-01 International Business Machines Corporation Data processing in a hybrid cluster environment
US11194620B2 (en) * 2018-10-31 2021-12-07 Nutanix, Inc. Virtual machine migration task management
US10977028B1 (en) * 2020-01-22 2021-04-13 Capital One Services, Llc Computer-based systems configured to generate and/or maintain resilient versions of application data usable by operationally distinct clusters and methods of use thereof
WO2021254592A1 (fr) * 2020-06-15 2021-12-23 Telefonaktiebolaget Lm Ericsson (Publ) Procédés et dispositifs de prévention de mésinformation lors d'un apprentissage automatique
US11321461B2 (en) * 2020-06-25 2022-05-03 EMC IP Holding Company LLC Malware scan task processing in a data storage system

Also Published As

Publication number Publication date
CN116888934A (zh) 2023-10-13
WO2022180323A1 (fr) 2022-09-01
FR3120172A1 (fr) 2022-08-26
US20240146605A1 (en) 2024-05-02

Similar Documents

Publication Publication Date Title
US10824416B2 (en) Method and system for a client to server deployment via an online distribution platform
EP3392761B1 (fr) Mise à jour incrémentielle distribuée de plateaux au moyen d'un système de commande de source
US20100306337A1 (en) Systems and methods for cloning target machines in a software provisioning environment
US20160044046A1 (en) Secure, non-disruptive firmware updating
EP3474583B1 (fr) Procédés de chargement d'un profil dans un élément sécurisé, gestionnaire et élément sécurisé personnalisable
EP3123387B1 (fr) Sécurisation du chargement de données dans une mémoire non-volatile d'un élément sécurisé
US10360010B1 (en) Method and system for implementing an ATM management and software policy tool
FR3059194B1 (fr) Installation d'un profil dans un module d'identite de souscripteur embarque
US10409582B1 (en) Method and system for implementing a retail event management tool
US10579362B1 (en) Method and system for implementing an ATM phone home and scrapper mapping tool
EP4298766A1 (fr) Procédé de contrôle d'une grappe de noeuds esclave par une grappe de noeuds maître, dispositifs et programmes d'ordinateurs correspondants
US20240012632A1 (en) Coordinating updates to an agent platform appliance in which agents of cloud services are deployed
EP4309032B1 (fr) Mise à jour automatique d'ensembles de vm
US20230185627A1 (en) Managing lifecycle of agents of cloud services according to desired state
EP4606084A1 (fr) Procédé de traitement d'une requête d'exécution d'un service dans un réseau de communication, procédé de validation de la requête, entité intermédiaire, entité de validation, système et programme d'ordinateur correspondants
WO2015092307A1 (fr) Procédé de test et de mise à jour du système d'un terminal par un module d'identité de souscripteur et dispositifs associés
FR3090156A1 (fr) Registre distribué
FR3125187A1 (fr) Procédé et dispositif de configuration d’une unité d’accès dans un environnement virtualisé
CN113691820A (zh) 直播间礼物更新方法、装置、终端设备及可读存储介质
EP4049409A1 (fr) Technique de communication entre une application mettant en oeuvre un service et un serveur
EP2791794B1 (fr) Procede de gestion d'une application referencee par un dispositif
WO2016156714A1 (fr) Système et procédé d'exécution d'une application dans un terminal muni d'une carte a puce
WO2025114164A1 (fr) Procédé de déploiement d'un service dans un environnement distribué
FR3067149A1 (fr) Mise a jour hierarchisee de logiciels d'equipements d'un reseau de distribution electrique
WO2023227386A1 (fr) Procédé de gestion de profils de service d'un élément sécurisé

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20230822

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20251223

GRAJ Information related to disapproval of communication of intention to grant by the applicant or resumption of examination proceedings by the epo deleted

Free format text: ORIGINAL CODE: EPIDOSDIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE