Equipment change arrangement method and device, electronic equipment and storage medium

Abstract

The invention discloses an equipment change arrangement method and device, electronic equipment and a storage medium. The method comprises the steps that risk factors corresponding to all equipment clusters with configuration to be changed are obtained, and the risk factors comprise equipment attributes which trigger errors in the historical change process of the equipment clusters and the number of users associated with the equipment clusters; target change constraint conditions and preset arrangement parameters are obtained, the target change constraint conditions are used for constraining conditions required to be met by the equipment clusters in the same change group, and the preset arrangement parameters are used for representing demand information for carrying out equipment change arrangement on the equipment clusters; and based on the risk factor, a target change constraint condition and a preset arrangement parameter, generating a change schedule of the to-be-changed device cluster, the change schedule including device clusters included in the change group in each change wave. According to the embodiment of the invention, the technical problems of long change time and low efficiency of equipment change arrangement in related technologies can be solved.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, specifically to a device change orchestration method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the continuous development of cloud computing technology, cloud providers are constantly changing the software and hardware configurations of cloud network devices such as switches and routers to meet users' needs for new cloud network features. Due to the large scale and wide impact of cloud network devices, a single change typically requires multiple cycles to complete in order to ensure network stability. Related technologies often employ manual analysis for change orchestration planning; however, this method not only wastes significant manpower, is time-consuming and inefficient, but also often fails to consider the risks inherent in historical change data, making the risks in change orchestration planning uncontrollable. Summary of the Invention

[0003] In view of the above problems, this application provides a device change arrangement method, apparatus, electronic device and storage medium to at least solve the technical problems of long change time and low efficiency in the related art.

[0004] According to a first aspect of the embodiments of this application, a device change orchestration method is provided. The method includes: obtaining risk factors corresponding to each device cluster whose configuration is to be changed, the risk factors including device attributes that have triggered errors in the historical change process of the device cluster and the number of users associated with the device cluster; obtaining target change constraints and preset orchestration parameters, the target change constraints being used to constrain the conditions that device clusters in the same change group need to meet, and the preset orchestration parameters being used to characterize the demand information for device change orchestration of each device cluster; and generating a change schedule for each device cluster whose configuration is to be changed based on the risk factors, target change constraints, and preset orchestration parameters, the change schedule including the device clusters included in the change group in each change wave.

[0005] According to a second aspect of the embodiments of this application, a device change orchestration apparatus is provided. The apparatus includes: a first acquisition unit, configured to acquire risk factors corresponding to each device cluster whose configuration is to be changed, the risk factors including device attributes that have triggered errors during historical changes and the number of users associated with the device cluster; a second acquisition unit, configured to acquire target change constraints and preset orchestration parameters, the target change constraints constraining the conditions that device clusters in the same change group need to meet, the preset orchestration parameters characterizing the requirement information for device change orchestration of each device cluster; and a generation unit, configured to generate a change schedule for each device cluster whose configuration is to be changed based on the risk factors, target change constraints, and preset orchestration parameters, the change schedule including the device clusters included in the change group of each change wave.

[0006] According to a third aspect of the embodiments of this application, an electronic device is also provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the device change arrangement method of the first aspect described above.

[0007] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer program, and the computer program is configured to execute the device change orchestration method of the first aspect described above when running.

[0008] According to a fifth aspect of the embodiments of this application, a computer program product includes a computer program that is executed by a processor to perform the device change arrangement method of the first aspect described above.

[0009] In this embodiment, the method involves obtaining risk factors corresponding to each device cluster whose configuration needs to be changed. These risk factors include device attributes that have triggered errors during historical changes and the number of tenants associated with each device cluster. The method also involves obtaining target change constraints and preset orchestration parameters. The target change constraints are used to constrain the conditions that device clusters in the same change group must meet, and the preset orchestration parameters are used to characterize the demand information for device change orchestration for each device cluster. Based on the risk factors, target change constraints, and preset orchestration parameters, a change schedule for the device clusters to be changed is generated. This change schedule includes the device clusters included in each change wave's change group. This application can automatically generate change schedules for device clusters to be changed based on the obtained risk factors, target change constraints, and preset orchestration parameters. Compared to manually obtaining change schedules based on change orchestration experience, this method not only accurately identifies change risks in historical change data and covers a higher proportion of risk factors, but also effectively reduces risks in change orchestration planning while generating change schedules quickly and efficiently, and saves labor costs. Attached Figure Description

[0010] Various other advantages and benefits will become apparent to those skilled in the art upon reading the detailed description of the preferred embodiments below. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0011] Figure 1 This is a schematic diagram of the application environment of an optional device change arrangement method according to an embodiment of this application;

[0012] Figure 2 This is a flowchart illustrating an optional device change arrangement method according to an embodiment of this application;

[0013] Figure 3 This is a schematic diagram illustrating an optional device change arrangement method according to an embodiment of this application;

[0014] Figure 4 This is a flowchart illustrating another optional device change arrangement method according to an embodiment of this application;

[0015] Figure 5 This is a flowchart illustrating another optional device change arrangement method according to an embodiment of this application;

[0016] Figure 6 This is a schematic diagram of an optional equipment change arrangement evaluation index according to an embodiment of this application;

[0017] Figure 7This is a schematic diagram of evaluation metrics for another optional equipment change arrangement according to an embodiment of this application;

[0018] Figure 8 This is a schematic diagram of evaluation indicators for another optional equipment change arrangement according to an embodiment of this application;

[0019] Figure 9 This is a schematic diagram of the structure of an equipment change and arrangement device provided in an embodiment of this application;

[0020] Figure 10 This is a schematic diagram of the structure of another electronic device provided in an embodiment of this application. Detailed Implementation

[0021] To enable those skilled in the art to better understand the present invention, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0022] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0023] The following is an explanation of the technical terms that may be involved in this application:

[0024] Changes: Changes to devices or the clusters in which they reside, including software upgrades, hardware replacements, and modifications to configuration information.

[0025] Schedule: Plan a change schedule for a large number of network devices in the cloud network.

[0026] Change risks: The impact of incorrect changes on cloud network tenants.

[0027] As an optional implementation method, the equipment change arrangement method described above in this application can be applied to... Figure 1 The application environment shown. For example... Figure 1 As shown, user 102 can interact with electronic device 104. Electronic device 104 includes memory 106 and processor 108; memory 106 stores risk factors, target change constraints, and preset orchestration parameters corresponding to each device cluster whose configuration is to be changed; processor 108 obtains the risk factors corresponding to each device cluster whose configuration is to be changed, including device attributes that have triggered errors during historical changes and the number of tenants associated with the device cluster; obtains target change constraints and preset orchestration parameters, the target change constraints constraining the conditions that device clusters in the same change group need to meet, and the preset orchestration parameters characterizing the demand information for device change orchestration of each device cluster; and generates a change schedule for the device clusters to be changed based on the risk factors, target change constraints, and preset orchestration parameters, the change schedule including the device clusters included in the change groups of each change wave.

[0028] Optionally, the aforementioned electronic device 104 includes, but is not limited to, mobile phones, laptops, tablets, PDAs, MIDs (Mobile Internet Devices), desktop computers, smart TVs, etc. The aforementioned electronic device 104 can also be a server, which can be a single server, a server cluster composed of multiple servers, or a cloud server. The aforementioned cloud server includes, but is not limited to, private cloud servers or public cloud servers. The above is merely an example, and no limitation is made in this embodiment.

[0029] As an alternative implementation method, such as Figure 2 As shown in the figure, this application provides a method for arranging equipment changes, including the following steps:

[0030] S202, obtain the risk factors corresponding to each device cluster whose configuration is to be changed. The risk factors include the device attributes of the device cluster that have triggered errors during historical changes and the number of users associated with the device cluster.

[0031] Specifically, the risk factors in this application embodiment mainly include device attributes that have triggered errors during historical changes in the configuration of each device cluster to be modified. For example, the network card version, network card driver version, or operating system version of the device may have experienced failures during version updates. These risk factors can also be obtained through expert knowledge. The risk factors also include the number of users (tenants) associated with each device in the device cluster. Assuming the current device cluster contains four devices: device 1, device 2, device 3, and device 4, with 10 tenants associated with device 1, 20 with device 2, 15 with device 3, and 10 with device 4, then the current device cluster is associated with 55 users.

[0032] S204, obtain the target change constraints and preset orchestration parameters. The target change preset conditions are used to constrain the conditions that the equipment clusters in the same change group need to meet. The preset orchestration parameters are used to characterize the equipment change orchestration requirements for each equipment cluster.

[0033] Specifically, in this application embodiment, the target change constraint is one or more change constraints selected from the set of change constraints. For example, mutually backing network devices cannot be assigned to the same change group, or the maximum number of device clusters assigned to each change group. The requirement information here includes the steps, sequence, required resources, and expected execution time of the change operation. The requirement information may also include the change objective: such as improving performance, fixing defects, updating software versions, etc. Figure 3 As shown, the preset orchestration parameters here include, but are not limited to, change waves and the number of change groups contained in each change wave. Change groups can be further divided into test groups and batch groups. Each device cluster whose configuration needs to be changed can be divided into one or more change waves for change. The purpose of the test group is to test the device clusters that may trigger errors as early as possible under various constraints (constraints such as limiting the number of associated tenants, or not assigning two backup devices to the same group, etc.), and to fix or optimize the triggered errors. The change order of the batch group is set after the test group, mainly used for rapid deployment of changes to the device cluster.

[0034] S206, Based on the risk factors, target change constraints and preset orchestration parameters, generate a change schedule for each device cluster whose configuration is to be changed, wherein the change schedule includes the device clusters included in the change group in each change wave.

[0035] In this application embodiment, including but not limited to using a heuristic algorithm (CloudPlanner-Fast algorithm) or branch and bound method as the change schedule solver, and then generating the change schedule of the device cluster to be changed based on the risk factors, target change constraints, and preset orchestration parameters. Related technologies typically orchestrate change schedules at the device level, which is inefficient. To improve the efficiency of large-scale network device change orchestration, this application accelerates the solution of the change orchestration model by setting coarse-grained decision variables, i.e., orchestrating change schedules at the cluster level. The resulting change schedule includes the device clusters contained in the change groups of each change wave.

[0036] In this embodiment, the method involves obtaining risk factors corresponding to each device cluster whose configuration needs to be changed. These risk factors include device attributes that have triggered errors during historical changes and the number of tenants associated with each device cluster. The method also involves obtaining target change constraints and preset orchestration parameters. The target change constraints are used to constrain the conditions that device clusters in the same change group must meet, and the preset orchestration parameters are used to characterize the demand information for device change orchestration for each device cluster. Based on the risk factors, target change constraints, and preset orchestration parameters, a change schedule for the device clusters to be changed is generated. This change schedule includes the device clusters included in each change wave's change group. This application can automatically generate change schedules for device clusters to be changed based on the obtained risk factors, target change constraints, and preset orchestration parameters. Compared to manually obtaining change schedules based on change orchestration experience, this method not only accurately identifies change risks in historical change data and covers a higher proportion of risk factors, but also effectively reduces risks in change orchestration planning while generating change schedules quickly and efficiently, and saves labor costs.

[0037] In one or more embodiments, such as Figure 4 As shown in the embodiments of this application, a method for arranging equipment changes is also provided, including the following steps:

[0038] S402, Obtain the device attribute table corresponding to each device in the device cluster whose configuration is to be changed, wherein the device attribute table includes multiple attributes of the device;

[0039] S404, Based on the device attribute table corresponding to each device in the device cluster, obtain the potential error factor of the device cluster and the number of tenants associated with the device cluster to obtain the risk factor corresponding to the device cluster; the potential error factor is used to characterize the device attributes of the device cluster that have triggered errors during historical changes.

[0040] Specifically, firstly, the device cluster whose configuration needs to be changed is determined, and the device attribute table of each device in the device cluster whose configuration needs to be changed is obtained from the device attribute database as shown in Table (1). Then, expert knowledge and historical fault-triggered device attribute information data can be used to extract the risk factors corresponding to the device cluster whose configuration needs to be changed from the device attribute table. In this embodiment, the potential error factors are the values ​​or combinations of values ​​of the device attributes that have historically triggered errors. A device may have many potential error factors. Similarly, since a device cluster usually contains multiple devices, a cluster may also include multiple potential error factors. In order to aggregate the potential error factors at the cluster level, it is necessary to extract the potential error factors at the device level. After obtaining the risk factors of each device in the device cluster, the risk factors of each device are aggregated to obtain the risk factors corresponding to the device cluster.

[0041] Table (1)

[0042]

[0043] S406, Obtain the target change constraint conditions and preset orchestration parameters. The target change constraint conditions are used to constrain the conditions that the equipment clusters in the same change group need to meet. The preset orchestration parameters are used to characterize the requirement information for orchestrating equipment changes for each equipment cluster.

[0044] S408, based on the risk factors, target change constraints and preset orchestration parameters, generate a change schedule for the equipment cluster to be changed, the change schedule including the equipment clusters included in the change groups of each change wave.

[0045] Steps S406-S408 in the embodiments of this application have been clearly explained above and will not be repeated here.

[0046] In one or more embodiments, obtaining the potential error factors of the device cluster based on the device attribute table of each device in the device cluster includes:

[0047] From the device attribute table corresponding to each device, obtain the error-related attributes of each device that have triggered errors during the historical change process, and the attribute values ​​corresponding to each error-related attribute;

[0048] The error-related attributes of each device and the attribute values ​​corresponding to the error-related attributes are used to form key-value pairs, and the potential error factors of each device are determined based on the key-value pairs.

[0049] The potential error factors corresponding to each device belonging to the same device cluster are aggregated to obtain the potential error factors corresponding to each device cluster.

[0050] Specifically, the process of extracting potential error factors includes: Symbol definition: Define n as the total number of devices in the device attribute table, where n is a natural number, and denote the device with device number i in the device attribute table, such as Table (1), as d. i Where 1 ≤ i ≤ n. Define the attributes of each device that has historically triggered errors as a set P = {p1, p2, ..., pn}. J}, where p j This represents the device attribute (hereinafter referred to as error-related attribute) that triggered the j-th historical error. There are a total of J error-related attributes. For each device d... i Define device d i The set of values ​​for each error-related attribute is as follows: in Indicates device d i The value of the j-th error-related attribute. To determine the value of each device d... i Each error-related attribute p j and the corresponding error-related attribute values Connect them together to define attribute-value pairs Where × is the Cartesian product, and the function of × is to multiply attribute p j and value These are concatenated together as an ordered pair (key-value pair). Then, each device d can be obtained. i Attribute-value pair collection in Indicates device d i The attribute-value pairs (key-value pairs) of the j-th error-related attribute are obtained, and then the risk factors of each device belonging to the same device cluster are aggregated to obtain the risk factors corresponding to each device cluster.

[0051] In a specific example, as shown in Table (1), it is assumed that there are two device attributes that have triggered errors in the above-mentioned cluster configuration to be changed, namely the network card version (NIC) and the operating system version (OS). In the current three clusters, the devices in cluster C1 include two parts of devices with device serial numbers 1 and 2. For example, these two parts of devices are named clusters C11 and C12.

[0052] The network interface card (NIC) versions and operating system versions of the four device clusters are as follows: Cluster C11 (v1, Linux), Cluster C12 (v1, CentOS), Cluster C2 (v2, Linux), and Cluster C3 (v2, CentOS). Taking Cluster C2 as an example, the error-related attributes of Cluster C2 include: NIC version (value V2), operating system version (value Linux), and the potential error factor for Cluster C2 can be {NIC version: V2, operating system version: Linux}.

[0053] In one or more embodiments, determining the potential error factor of each device based on the number of combinations and the key-value pairs corresponding to each device includes:

[0054] Get the number of combinations of device attributes that caused the device change error;

[0055] Based on the number of combinations, the key-value pairs corresponding to the current device are combined to obtain the potential error factor corresponding to the current device.

[0056] In this embodiment, change errors can be triggered not only by a single attribute value but also by the combined effects of multiple attribute values. Therefore, expert knowledge is needed to define the number of attribute combinations (combination number) C that leads to change errors. After obtaining the value of the combination number C, a device-level potential error factor is extracted for a given attribute combination number C. Each device d is defined. i The set of potential error factors consisting of C combinations of attributes is S(d) i C) = {{Y1,Y2,…,Y} C}}|, 1≤a≤C, and Y u ≠Y v for u≠v, 1≤u, v≤C}. That is, this set S(d i C) includes device d i Attribute-value pairs All C-scale subsets, these subsets represent those formed by... All possible combinations of the C attribute-value pairs in the dataset.

[0057] Then, based on the potential error factor set S(d) at the device granularity i C) is used to perform cluster-level aggregation. First, the cluster set is defined as S. cluster (C)={cluster1,cluster2,…,cluster N}, where N is the total number of clusters, and a cluster is defined. j Let j be the j-th cluster. Then, perform an aggregation operation to define the cluster. j The set of potential error factors is That is, belonging to the same cluster j Each device d i The union of the sets of potential error factors.

[0058] Next, construct the potential error factor for all clusters given a parameter C (the number of combinations of device attributes that cause device change errors) in dictionary format, denoted as S. cluster(C)={cluster1:S(cluster1,C), cluster2:S(cluster2,C),…,cluster N :S(cluster N ,C)}.

[0059] For example, the error-related attributes of device 1 include: attribute A (value a1), attribute B (value b1), and attribute C (value c1); when C = 1, the potential error factor of device 1 is {A:a1, B:b1, C:c1}; when C = 2, the potential error factor of device 1 is {{A:a1, B:b1}, {B:b1, C:c1}, {A:a1, C:c1}}.

[0060] The error-related attributes of device 2 include: attribute A (value a2), attribute B (value b2), and attribute C (value c2). When C = 1, the potential error factors of device 2 are {A: a2, B: b2, C: c2}. When C = 2, the potential error factors of device 2 are {{A: a2, B: b2}, {B: b2, C: c2}, {A: a2, C: c2}}.

[0061] In a specific example, as shown in Table (1), it is assumed that there are three device attributes that have been historically triggered errors in the cluster to be modified, namely the network card version (NIC), the network card driver version (NIC Driver), and the operating system version (OS). In the current three clusters, the devices in cluster C1 include two parts of devices with device serial numbers 1 and 2. It is assumed that these two parts of devices are named clusters C11 and C12.

[0062] Taking cluster C2 as an example, the error-related attributes of cluster C2 include: network interface card (NIC) version (value V2), NIC driver version (value V2), and operating system version (value Linux). When C=1, the potential error factors of cluster C2 are {NIC version: V2, NIC driver version: V2, operating system version: Linux}. When C=2, the potential error factors of cluster C2 are {{NIC version: V2, NIC driver version: V2}, {NIC version: V2, operating system version: Linux}, {NIC driver version: V2, operating system version: Linux}}.

[0063] In one or more embodiments, obtaining the number of users associated with the device cluster based on the device attribute table of each device in the device cluster includes:

[0064] From the device attribute table of each device in the device cluster, obtain the number of users associated with devices deployed in the same availability zone;

[0065] The total number of users associated with devices deployed in the same availability zone is calculated to obtain the total number of users associated with the availability zone of the device cluster.

[0066] Specifically, in this embodiment, to reduce the impact of potential change errors on tenants, the number of tenants affected by the test group needs to be considered. Therefore, the number of tenants associated with each cluster can be used as the change impact factor. Based on the device attribute table, the change impact factor for each cluster is extracted, and the following change impact factor dictionary is constructed: {cluster1:{region-az:Aa, tenant:43}, cluster2:{region-az:Aa, tenant:1}, ..., cluster N :{region-az:Ba,tenant:6}};where region-az is the availability zone. As shown in Table (1) above, for example, the device cluster located in availability zone Aa is C1 and the number of associated users is 43.

[0067] In one or more embodiments, such as Figure 5 As shown in the embodiments of this application, a method for arranging equipment changes is also provided, including the following steps:

[0068] S502, obtain the risk factors corresponding to each device cluster whose configuration is to be changed. The risk factors include the device attributes of the device cluster that have triggered errors during historical changes and the number of tenants associated with the device cluster.

[0069] S504, obtain the target change constraints and preset orchestration parameters. The target change preset conditions are used to constrain the conditions that the equipment clusters in the same change group need to meet. The preset orchestration parameters are used to characterize the requirement information for orchestrating equipment changes for each equipment cluster.

[0070] S506, Based on the change wave and the number of change groups in each change wave, determine the change groups of the device clusters to be allocated included in each change wave;

[0071] S508, determine the target equipment cluster that meets the change constraints corresponding to the current change group, and assign the target equipment cluster to the current change group; the change constraints include constraints obtained based on the risk factor;

[0072] S510, when all device clusters whose configurations are to be changed are assigned to a change group, the change schedule is determined.

[0073] Specifically, in this embodiment of the application, the solver Cloudplanner-Fast, which is based on a heuristic algorithm, can also be used, along with the solver Cloudplanner-Opt, which is based on an optimization algorithm, to obtain the corresponding change schedule for each device cluster whose configuration needs to be changed. The set of change constraints is denoted as φ.

[0074] Each change group must meet the following two conditions when allocating clusters: (1) Loading clusters group by group: Clusters are only selected for allocation in the current change group when the previous change group is full. A change group is full because it cannot select more clusters to load into this change group due to certain constraints in set φ. (2) Iterative cluster loading: i. Load clusters into the current change group one by one. ii. The loaded clusters must satisfy all constraints in set φ.

[0075] In one or more embodiments, the aforementioned change groups include test groups and batch groups. Specifically, each change wave is divided into two phases: a test phase and a batch phase. All test groups can constitute the test phase, and all batch groups can constitute the batch phase. These two phases have different objectives. The test phase aims to identify clusters that may trigger errors as early as possible under various change constraints, while the batch phase emphasizes rapid change deployment. Here, the test phase is primarily used to test device clusters that may trigger errors. For example, some devices with specific hardware and software configurations may be incompatible with the software or hardware changes, leading to device malfunctions after the changes. Therefore, during the test phase, a portion of the clusters whose configurations are to be changed can be modified to identify potential incompatibility issues arising from the hardware and software changes. For example, if a cloud network includes 50 device clusters, 20% of these clusters can be allocated to the test phase for change orchestration, i.e., 10 device clusters can be selected as the test group clusters, and the remaining 40 device clusters can be selected as the batch group clusters.

[0076] Specifically, a cluster in a cloud network typically consists of 10-1000 network devices that are logically or geographically close to each other. Let the decision variable be defined as x. ik (x ik The value of can be 0 or 1, indicating whether cluster i is assigned to the k-th test group. For example, when x ik =0 means that cluster i was not assigned to the k-th test group, x ik =1 means that cluster i is assigned to the kth test group.

[0077] The change constraints corresponding to the test group include: 1. Unique allocation constraint: each device cluster can be assigned to at most one change group. This application can use formula (1) to determine whether the device change orchestration meets the change constraint.

[0078]

[0079] Where, x ik It indicates whether device cluster i is assigned to the k-th test group, x ik The value can be 0 or 1, N is the total number of device clusters, and K is the maximum value of the change group.

[0080] 2. Group-level tenant number constraint: the number of tenants in each change group shall not exceed the first preset number; this application can use formula (2) to determine whether the equipment change arrangement meets the change constraint condition.

[0081]

[0082] Among them, u i It is the number of tenants associated with each cluster, e k It is the maximum number of tenants that the k-th group can contain.

[0083] 3. Group-level capacity constraints: the number of equipment clusters contained in each change group shall not exceed the second preset number; this application can use formula (3) to determine whether the equipment change arrangement meets the change constraint conditions.

[0084]

[0085] Among them, h k It is the upper limit of the number of clusters that the k-th group can contain.

[0086] 4. Regional mutual exclusion constraint: the number of device clusters in the test group does not exceed a third preset number, which is the product of the total number of device clusters in the current change wave and a preset percentage. This application can use formula (4) to determine whether the device change arrangement meets the change constraint condition.

[0087]

[0088] Where α is the preset percentage and N is the total number of devices in the cluster.

[0089] 5. Regional mutual exclusion constraint: The number of device clusters within a preset region included in each change group shall not exceed the fourth preset number.

[0090] This application can use formula (5) to determine whether the equipment change arrangement meets the change constraint conditions.

[0091]

[0092] Where R is the number of critical clusters, o jk It is a 0-1 matrix, o jk=1 indicates that a cluster in the j-th critical region has been assigned to the k-th group, q ij =1 indicates that cluster i belongs to the j-th critical region.

[0093] 6. Availability zone mutual exclusion constraint: the device clusters in each change group are not mutually backup clusters. This application can use formula (6) to determine whether the device change orchestration meets this change constraint condition.

[0094]

[0095] Among them, L r This represents the total number of available zones in the r-th region. This indicates that a cluster belonging to the r-th region and the j-th availability zone has been assigned to the k-th group. This indicates that cluster i belongs to the j-th availability zone of the r-th region.

[0096] The change constraints corresponding to the change group include: all clusters are assigned constraints, and the device clusters assigned to the batch group and the device clusters assigned to the test group cover each device cluster of the configuration to be changed. This application can use formula (7) to determine whether the device change orchestration meets the change constraints.

[0097]

[0098] Where N′ represents the number of clusters not assigned to the test phase, and K′ represents the number of batch groups. Depending on the actual needs of the operations personnel, constraints 2, 3, 5, and 6 of the test phase can also be selectively added to the orchestration model of the batch phase. It is important to note that when adding the constraints of the test phase to the batch phase, the parameters N and K of the test phase need to be replaced with N′ and K′ of the batch phase.

[0099] Steps S502-S504 in the embodiments of this application have been clearly explained above and will not be repeated here.

[0100] In one or more embodiments, the change group includes a test group; when the current change group is a test group, determining the target device cluster that satisfies the change constraints corresponding to the current change group and assigning the target device cluster to the current change group includes:

[0101] Identify candidate device clusters that meet the change constraints corresponding to the current change group;

[0102] Based on the allocation limit value corresponding to the current change group, the combination of candidate device clusters with the most potential error factors is allocated to the current change group.

[0103] In this embodiment, clusters with larger potential error factor coverage increments are preferentially selected to maximize the optimization objective of the change orchestration. Therefore, during the testing phase, it is also necessary to satisfy the following condition: if a cluster satisfies all constraints in set φ and brings the largest potential error factor coverage increment, then that cluster is loaded into the current group. Specifically, during the testing phase, the pseudocode for the solver based on heuristic algorithms to obtain the corresponding change schedule for each device cluster whose configuration needs to be changed includes, for example:

[0104] Input parameters: matrix F = (f ij ), number of potential error factors M, number of device clusters N, number of change groups K, change constraints φ.

[0105]

[0106] Output parameters: Matrix X = (x ik The corresponding change schedule for each device cluster can be determined based on matrix X.

[0107] The pseudocode for the batch stage differs from that for the testing stage in the following ways: 1. The pseudocode for the batch stage does not include the input variable matrix F, the number of potential error factors M, and the coverage vector Q related to potential error factors; 2. Code replacement in steps 9-11: Select any cluster i from the candidate cluster set S and assign cluster i to the current group j, x ij =1.

[0108] In a specific example, suppose the number of attribute combinations that caused the change error is C = 1. There are two device attributes that have historically triggered the error: network interface card (NIC) version and operating system version. There are currently four device clusters (A, B, C, D), of which two clusters (A, B) have already been assigned to the current change group, leaving device clusters C and D pending assignment.

[0109] The network interface card (NIC) versions and operating system versions of each device cluster are as follows: Cluster A (v1, Ubuntu), Cluster B (v2, CentOS), Cluster C (v1, Fedora), and Cluster D (v3, Fedora). Since device cluster D has an overlay increment of 2, and device cluster C has an overlay increment of 1, and device cluster D corresponds to the largest number of potential error factors added to the current change group, when the maximum number of clusters allocated to the current change group is 3, cluster D is selected to be assigned to the current change group.

[0110] Assuming the number of attribute combinations leading to a change error is C = 2, the network interface card (NIC) version and operating system version will both cause the change error. Device cluster A has only one potential error factor: {NIC:v1, OS:Ubuntu} (a combination of these two attribute values). Cluster B also has only one potential error factor: {NIC:v2, OS:CentOS}. Similarly, device clusters C and D also have only one potential error factor. In this case, the coverage increment brought by either device cluster C or D is 1, so either one can be added to the current group.

[0111] In one or more application embodiments, this application also provides a device change orchestration method, applied to cloud servers in a cloud network, the cloud network including multiple server clusters, the method comprising:

[0112] Obtain the risk factors corresponding to each server cluster whose configuration is to be changed. The risk factors include the device attributes of the server cluster that have triggered errors during historical changes and the number of users associated with the server cluster.

[0113] Obtain target change constraints and preset orchestration parameters. The target change constraints are used to constrain the conditions that server clusters in the same change group need to meet. The preset orchestration parameters are used to characterize the requirement information for orchestrating device changes for each server cluster.

[0114] Based on the risk factors, target change constraints, and preset orchestration parameters, a change schedule for each server cluster whose configuration is to be changed is generated. The change schedule includes the server clusters included in the change groups of each change wave.

[0115] The cloud server in this application can automatically generate a change schedule for the server clusters whose configurations are to be changed by obtaining the corresponding risk factors, target change constraints, and preset orchestration parameters of each server cluster in the cloud network. Compared with obtaining the change schedule manually based on change orchestration experience, it can not only accurately obtain the change risks existing in the historical change data of the server clusters in the cloud network and cover a higher proportion of risk factors, but also effectively reduce the risks in change orchestration planning while generating the change schedule quickly and efficiently, and save labor costs.

[0116] In one or more embodiments, the preset orchestration parameters include change waves and the number of change groups in each change wave. The step of generating a change schedule for each server cluster with the configuration to be changed based on the risk factor, target change constraints, and preset orchestration parameters includes:

[0117] Based on the change wave and the number of change groups in each change wave, determine the change groups of the server clusters to be allocated included in each change wave, and the change constraints corresponding to each change group; the change constraints include constraints based on the risk factors.

[0118] Identify the target server cluster that meets the change constraints corresponding to the current change group, and assign the target server cluster to the current change group;

[0119] The change schedule is determined when all server clusters whose configurations are to be changed are assigned to a change group.

[0120] To verify the effectiveness of the algorithm proposed in this application, the present invention uses a real virtual switch change dataset for verification. This dataset contains virtual switch device attributes of six availability regions (region-az) and four real change test schedules generated manually in relation to the dataset. Each test schedule has only one change wave. The manually generated test schedules can be used to compare with the test schedules generated by the algorithm.

[0121] In terms of evaluation metrics, three metrics can be evaluated for each test schedule: the percentage of potential error factors covered by the test schedule (Cover Rate), the test schedule generation time (Planning Time), and the percentage of tenants affected by the test schedule (Impacted Tenant Rate), as shown in formulas (7), (8), and (9).

[0122]

[0123] Planning Time = Records the time required for each algorithm to generate a test schedule (8)

[0124]

[0125] like Figure 6 As shown, considering the number of attribute combinations C=2, the Cover Rate of each test schedule orchestrated by each algorithm covers the potential risk factors. The horizontal axis represents the four test schedules. The modified orchestration method used in this application (CloudPlanner-Fast or CloudPlanner-Opt) can cover a higher proportion of potential risk factors compared to manual orchestration methods. Figure 7 As shown, the proportion of tenants affected by the test schedule generated by the modified orchestration method in this embodiment is lower than that of the manually orchestrated test schedule. Figure 8As shown, the embodiments of this application also have high scheduling efficiency, and can generate a test schedule in one minute, which is more efficient than the manual scheduling method that may take several days to schedule.

[0126] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0127] According to another aspect of the embodiments of this application, an equipment change arrangement for implementing the above-described equipment change arrangement method is also provided, such as... Figure 9 As shown, the equipment change scheduling device includes:

[0128] The first acquisition unit 902 acquires the risk factors corresponding to each device cluster whose configuration is to be changed. The risk factors include the device attributes of the device cluster that have triggered errors during historical changes and the number of tenants associated with the device cluster.

[0129] The second acquisition unit 904 is used to acquire target change constraints and preset orchestration parameters. The target change preset conditions are used to constrain the conditions that the equipment clusters in the same change group need to meet, and the preset orchestration parameters are used to characterize the equipment change orchestration requirements for each equipment cluster.

[0130] The generation unit 906 is used to generate a change schedule for the equipment cluster to be changed based on the risk factor, target change constraints and preset orchestration parameters. The change schedule includes the equipment clusters contained in the change groups in each change wave.

[0131] In this embodiment, a method is employed to obtain risk factors corresponding to each device cluster whose configuration needs to be changed. These risk factors include device attributes that have triggered errors during historical changes and the number of tenants associated with each device cluster. Target change constraints and preset orchestration parameters are also obtained. The target change constraints constrain the conditions that device clusters in the same change group must meet, and the preset orchestration parameters characterize the need information for orchestrating device changes for each device cluster. Based on the risk factors, target change constraints, and preset orchestration parameters, a change schedule for the device clusters to be changed is generated. This change schedule includes the device clusters included in each change wave's change group. Compared to the prior art's method of manually orchestrating and obtaining change schedules, this method not only saves labor costs but also obtains change schedules quickly and efficiently, and effectively reduces the risks in change orchestration planning.

[0132] In one or more embodiments, the first acquisition unit 902 includes:

[0133] The first acquisition module is used to acquire the device attribute table corresponding to each device in the device cluster whose configuration is to be changed. The device attribute table includes multiple attributes of the device.

[0134] The second acquisition module is used to obtain the potential error factors of the device cluster and the number of tenants associated with the device cluster based on the device attribute table corresponding to each device in the device cluster, and obtain the risk factor corresponding to the device cluster; the potential error factors are used to characterize the device attributes of the device cluster that have triggered errors during historical changes.

[0135] In one or more embodiments, the second acquisition module includes:

[0136] The first acquisition subunit is used to acquire, from the device attribute table, the error-related attributes of each device that have triggered errors during the historical change process, and the attribute values ​​corresponding to each error-related attribute;

[0137] A subunit is constructed to form key-value pairs between the error-related attributes of each device and the attribute values ​​corresponding to the error-related attributes, and to determine the potential error factors of each device based on the key-value pairs.

[0138] The aggregation subunit is used to aggregate the potential error factors corresponding to each device belonging to the same device cluster to obtain the potential error factors corresponding to each device cluster.

[0139] In one or more embodiments, the building subunit includes:

[0140] The `get` submodule is used to obtain the number of combinations of device attributes that caused the device change error.

[0141] The combination submodule is used to combine the key-value pairs corresponding to the current device according to the combination number to obtain the potential error factor corresponding to the current device.

[0142] In one or more embodiments, the second acquisition module includes:

[0143] The second acquisition subunit is used to obtain the number of users associated with devices deployed in the same availability zone from the device attribute table of each device in the device cluster.

[0144] The calculation subunit is used to calculate the sum of the number of users associated with devices deployed in the same availability zone, so as to obtain the number of users associated with the device cluster.

[0145] In one or more embodiments, the preset orchestration parameters include the number of change waves and the number of change groups in each change wave, and the generation unit 906 includes:

[0146] The determination module is used to determine the change groups of the device clusters to be allocated in each change wave based on the change wave and the number of change groups in each change wave;

[0147] The allocation module is used to determine the target device cluster that meets the change constraints corresponding to the current change group, and allocate the target device cluster to the current change group; the change constraints include constraints based on the risk factor.

[0148] The determination module is used to determine the change schedule when all device clusters whose configurations are to be changed are assigned to change groups.

[0149] In one or more embodiments, the change group includes a test group;

[0150] When the current change group is the test group, the assignment determination module includes:

[0151] The sub-unit is used to determine the candidate device clusters that meet the change constraints corresponding to the current change group;

[0152] The allocation subunit is used to allocate the combination of candidate device clusters with the most potential error factors to the current change group based on the allocation upper limit value corresponding to the current change group.

[0153] According to another aspect of the embodiments of this application, an electronic device for implementing the above-described device change arrangement method is also provided. This electronic device may be... Figure 1 The electronic device shown. For example... Figure 10As shown, the electronic device includes a memory 1002 and a processor 1004. The memory 1002 stores a computer program, and the processor 1004 is configured to execute the steps of any of the above method embodiments via the computer program.

[0154] Optionally, in this embodiment, the aforementioned electronic device may be at least one of a plurality of network devices in a computer network.

[0155] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:

[0156] S1, obtain the risk factors corresponding to each device cluster whose configuration is to be changed. The risk factors include the device attributes of the device cluster that have triggered errors during historical changes and the number of users associated with the device cluster.

[0157] S2, obtain the target change constraints and preset orchestration parameters. The target change constraints are used to constrain the conditions that the equipment clusters in the same change group need to meet. The preset orchestration parameters are used to characterize the equipment change orchestration requirements for each equipment cluster.

[0158] S3. Based on the risk factors, target change constraints and preset orchestration parameters, generate a change schedule for each device cluster whose configuration is to be changed. The change schedule includes the device clusters included in the change group of each change wave.

[0159] The memory 1002 can be used to store software programs and modules, such as the program instructions / modules corresponding to the device change orchestration method and apparatus in this embodiment. The processor 1004 executes various functional applications and data processing by running the software programs and modules stored in the memory 1002, thereby realizing the aforementioned device change orchestration method. The memory 1002 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 1002 may further include memory remotely located relative to the processor 1004, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. Specifically, the memory 1002 may be used, but is not limited to, to store device attribute information and risk factors.

[0160] As an example, such as Figure 10As shown, the memory 1002 may include, but is not limited to, the first acquisition unit 902, the second acquisition unit 904, and the generation unit 906 in the device change orchestration device. Furthermore, it may include, but is not limited to, other module units in the virtual machine, which will not be elaborated upon in this example.

[0161] Optionally, the transmission device 1006 described above is used to receive or send data via a network. Specific examples of the network described above may include wired networks and wireless networks. In one example, the transmission device 1006 includes a Network Interface Controller (NIC), which can be connected to other network devices and routers via a network cable to communicate with the Internet or a local area network. In another example, the transmission device 1006 is a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0162] In addition, the aforementioned electronic device also includes a connection bus 1008 for connecting various module components in the aforementioned electronic device.

[0163] In other embodiments, the aforementioned electronic device can be a node in a distributed system, which can be a blockchain system. This blockchain system is formed by connecting multiple nodes through network communication. The nodes can form a peer-to-peer (P2P) network, and any type of computing device, such as a server or terminal, can become a node in the blockchain system by joining this peer-to-peer network.

[0164] In one or more embodiments, this application also provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the device change orchestration method described above. The computer program is configured to execute the steps in any of the method embodiments described above when running.

[0165] Optionally, in this embodiment, the computer-readable storage medium described above may be configured to store a computer program for performing the following steps:

[0166] S1, obtain the risk factors corresponding to each device cluster whose configuration is to be changed. The risk factors include the device attributes of the device cluster that have triggered errors during historical changes and the number of users associated with the device cluster.

[0167] S2, obtain the target change constraints and preset orchestration parameters. The target change constraints are used to constrain the conditions that the equipment clusters in the same change group need to meet. The preset orchestration parameters are used to characterize the equipment change orchestration requirements for each equipment cluster.

[0168] S3. Based on the risk factors, target change constraints and preset orchestration parameters, generate a change schedule for each device cluster whose configuration is to be changed. The change schedule includes the device clusters included in the change group of each change wave.

[0169] Optionally, in this embodiment, those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0170] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0171] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods of the various embodiments of the present invention.

[0172] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0173] In the several embodiments provided in this application, it should be understood that the disclosed client can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or the indirect coupling or communication connection of units or modules may be electrical or other forms.

[0174] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0175] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0176] The above are merely preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

[0177] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

Claims

1. A method for scheduling equipment changes, characterized in that, The method includes: Obtain the risk factors corresponding to each device cluster whose configuration is to be changed. The risk factors include the device attributes of the device cluster that have triggered errors during historical changes and the number of users associated with the device cluster. Obtain target change constraints and preset orchestration parameters. The target change constraints are used to constrain the conditions that the equipment clusters in the same change group need to meet. The preset orchestration parameters are used to characterize the equipment change orchestration requirements for each equipment cluster. Based on the risk factors, target change constraints, and preset orchestration parameters, a change schedule for each device cluster whose configuration is to be changed is generated. The change schedule includes the device clusters included in the change group of each change wave.

2. The method according to claim 1, characterized in that, The process of obtaining the risk factors corresponding to each device cluster whose configuration needs to be changed includes: Obtain the device attribute table corresponding to each device in the device cluster whose configuration is to be changed. The device attribute table includes multiple attributes of the device. Based on the device attribute table corresponding to each device in the device cluster, the potential error factors of the device cluster and the number of users associated with the device cluster are obtained to obtain the risk factor corresponding to the device cluster; the potential error factors are used to characterize the device attributes of the device cluster that have triggered errors during historical changes.

3. The method according to claim 2, characterized in that, The step of obtaining potential error factors of the device cluster based on the device attribute table of each device in the device cluster includes: From the device attribute table, obtain the error-related attributes of each device that have triggered errors during the historical change process, and the attribute values ​​corresponding to each error-related attribute; The error-related attributes of each device and the attribute values ​​corresponding to the error-related attributes are used to form key-value pairs, and the potential error factors of each device are determined based on the key-value pairs. The potential error factors corresponding to each device belonging to the same device cluster are aggregated to obtain the potential error factors corresponding to each device cluster.

4. The method according to claim 3, characterized in that, The determination of potential error factors for each device based on the key-value pairs includes: Get the number of combinations of device attributes that caused the device change error; Based on the number of combinations, the key-value pairs corresponding to the current device are combined to obtain the potential error factor corresponding to the current device.

5. The method according to claim 2, characterized in that, The step of obtaining the number of users associated with the device cluster based on the device attribute table of each device in the device cluster includes: From the device attribute table of each device in the device cluster, obtain the number of users associated with devices deployed in the same availability zone; The total number of users associated with devices deployed in the same availability zone is calculated to obtain the total number of users associated with the device cluster.

6. The method according to any one of claims 1 to 5, characterized in that, The preset orchestration parameters include the change wave number and the number of change groups in each change wave. The step of generating a change schedule for the equipment cluster to be changed based on the risk factor, target change constraints, and preset orchestration parameters includes: Based on the change wave and the number of change groups in each change wave, determine the change groups of the device clusters to be allocated included in each change wave; Identify the target device cluster that meets the change constraints corresponding to the current change group, and assign the target device cluster to the current change group; the change constraints include constraints based on the risk factor. The change schedule is determined when all device clusters whose configurations are to be changed are assigned to a change group.

7. The method according to claim 6, characterized in that, The change group includes the test group; When the current change group is a test group, determining the target device cluster that meets the change constraints corresponding to the current change group and assigning the target device cluster to the current change group includes: Identify candidate device clusters that meet the change constraints corresponding to the current change group; Based on the allocation limit value corresponding to the current change group, the combination of candidate device clusters with the most potential error factors is allocated to the current change group.

8. A method for scheduling equipment changes, characterized in that, The method, applied to cloud servers in a cloud network comprising multiple server clusters, includes: Obtain the risk factors corresponding to each server cluster whose configuration is to be changed. The risk factors include the device attributes of the server cluster that have triggered errors during historical changes and the number of users associated with the server cluster. Obtain target change constraints and preset orchestration parameters. The target change constraints are used to constrain the conditions that server clusters in the same change group need to meet. The preset orchestration parameters are used to characterize the requirement information for orchestrating device changes for each server cluster. Based on the risk factors, target change constraints, and preset orchestration parameters, a change schedule for each server cluster whose configuration is to be changed is generated. The change schedule includes the server clusters included in the change groups of each change wave.

9. The method according to claim 8, characterized in that, The preset orchestration parameters include change waves and the number of change groups in each change wave. The step of generating a change schedule for each server cluster whose configuration needs to be changed, based on the risk factor, target change constraints, and preset orchestration parameters, includes: Based on the change wave and the number of change groups in each change wave, determine the change groups of the server clusters to be allocated included in each change wave, and the change constraints corresponding to each change group; the change constraints include constraints based on the risk factors. Identify the target server cluster that meets the change constraints corresponding to the current change group, and assign the target server cluster to the current change group; The change schedule is determined when all server clusters whose configurations are to be changed are assigned to a change group.

10. An equipment change and arrangement device, characterized in that, The device includes: The first acquisition unit acquires the risk factors corresponding to each device cluster whose configuration is to be changed. The risk factors include the device attributes of the device cluster that have triggered errors during historical changes and the number of users associated with the device cluster. The second acquisition unit is used to acquire target change constraints and preset orchestration parameters. The target change constraints are used to constrain the conditions that the equipment clusters in the same change group need to meet, and the preset orchestration parameters are used to characterize the equipment change orchestration requirements for each equipment cluster. The generation unit is used to generate a change schedule for each device cluster whose configuration is to be changed based on the risk factors, target change constraints and preset orchestration parameters. The change schedule includes the device clusters included in the change group in each change wave.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes the computer program to implement the method as described in any one of claims 1 to 7.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by a processor to implement the method as described in any one of claims 1 to 9.

13. A computer program product, comprising a computer program, characterized in that, The computer program is executed by a processor to implement the method according to any one of claims 1 to 9.

Images