Resource allocation method and device, computer equipment and storage medium

Abstract

The invention relates to the technical field of clusters, and discloses a resource allocation method and device, computer equipment and a storage medium, and the method comprises the steps: adding a new target virtual machine for a target cluster under the condition that resources of the target cluster are insufficient, and allocating corresponding resources for the new target virtual machine based on public resources; under the condition that the resource of the target cluster is idle, recycling the resource corresponding to the idle target virtual machine in the target cluster as a public resource; wherein the target cluster is a block chain cluster or a data cluster. According to the method, the block chain virtual machine is allocated for the block chain cluster through the host, the data virtual machine is allocated for the data cluster, the public resources can be reserved in the host, and the public resources are utilized to realize newly adding and recycling of resources among different clusters; the nodes of each cluster are realized by different virtual machines, so that isolation among the clusters can be realized, and dynamic resource scheduling among different clusters can be realized.

Description

Technical Field

[0001] This invention relates to the field of cluster technology, and specifically to methods, apparatus, computer equipment, and storage media for resource allocation. Background Technology

[0002] In certain fields with high data security requirements, secure data storage is necessary. For example, blockchain technology can be used to achieve encrypted data storage. To ensure the security of nodes within a specific field, these nodes are typically deployed on different physical machines than other ordinary data nodes.

[0003] While this method can achieve complete physical isolation, it lacks flexibility in configuration, and the resources of the two types of nodes cannot be dynamically allocated. Summary of the Invention

[0004] In view of this, the present invention provides a method, apparatus, computer equipment and storage medium for resource allocation, so as to solve the problem of the inability to dynamically allocate resources between different clusters.

[0005] In a first aspect, the present invention provides a resource allocation method applied to a host cluster; the hosts in the host cluster are used to provide blockchain virtual machines for a blockchain cluster and data virtual machines for a data cluster; and at least some hosts reserve public resources; the method includes:

[0006] If the target cluster resources are insufficient, add a new target virtual machine to the target cluster and allocate corresponding resources to the new target virtual machine based on the public resources;

[0007] When the target cluster resources are idle, the resources corresponding to the idle target virtual machines in the target cluster will be reclaimed as public resources;

[0008] Wherein, the target cluster is the blockchain cluster or the data cluster; if the target cluster is the blockchain cluster, the target virtual machine is the blockchain virtual machine; if the target cluster is the data cluster, the target virtual machine is the data virtual machine.

[0009] In some optional implementations, when the target cluster is the blockchain cluster, adding a new target virtual machine to the target cluster and allocating corresponding resources to the new target virtual machine based on the public resources includes:

[0010] Allocate corresponding resources to the new blockchain virtual machine based on the aforementioned public resources;

[0011] Set corresponding encryption factors for the new blockchain virtual machine; the encryption factors are used for encryption and decryption processing of the data of the new blockchain virtual machine;

[0012] Add the new blockchain virtual machine to the blockchain cluster.

[0013] In some optional implementations, setting the corresponding encryption factors for the new blockchain virtual machine includes:

[0014] Determine global parameters used to represent the global characteristics of the host cluster;

[0015] The encryption factor of the new blockchain virtual machine is determined based on the attribute information of the new blockchain virtual machine and the global parameters.

[0016] In some optional implementations, determining the global parameters used to represent the global characteristics of the host cluster includes:

[0017] Obtain the first hardware parameters of each host in the host cluster;

[0018] The global parameters of the host cluster are determined based on the first hardware parameters of each host.

[0019] In some optional implementations, the attribute information of the new blockchain virtual machine includes: the second hardware parameters of the target host corresponding to the new blockchain virtual machine, and the virtual machine parameters of the new blockchain virtual machine; the target host is a host in the host cluster.

[0020] In some alternative implementations, the new blockchain virtual machine is equipped with a virtual disk volume;

[0021] The header data of the virtual disk volume is obtained by encrypting it according to the encryption factor.

[0022] In some optional implementations, the method further includes:

[0023] When the blockchain virtual machine is started, the encryption factor of the blockchain virtual machine is obtained;

[0024] Determine whether the encryption factor of the blockchain virtual machine is correct;

[0025] If the encryption factor of the blockchain virtual machine is correct, the blockchain virtual machine is allowed to start.

[0026] In some optional implementations, the step of reclaiming the resources corresponding to idle target virtual machines in the target cluster as public resources includes:

[0027] If the target cluster is the blockchain cluster, determine the first idle blockchain virtual machine in the blockchain cluster;

[0028] The data of the first blockchain virtual machine is decrypted according to the encryption factor of the first blockchain virtual machine to obtain the original data of the first blockchain virtual machine; wherein, the data of the blockchain virtual machine includes the header data corresponding to the blockchain virtual machine.

[0029] The original data is encrypted according to the encryption factor of the second blockchain virtual machine in the blockchain cluster, and the encrypted data is stored in the storage area allocated to the second blockchain virtual machine.

[0030] Delete the first blockchain virtual machine and reclaim the resources corresponding to the first blockchain virtual machine as public resources.

[0031] Secondly, the present invention provides a resource allocation device applied to a host cluster; the hosts in the host cluster are used to provide blockchain virtual machines for a blockchain cluster and data virtual machines for a data cluster; and at least some hosts reserve public resources; the device includes:

[0032] A new module is added to the target cluster when the target cluster resources are insufficient, and to allocate corresponding resources to the new target virtual machine based on the public resources.

[0033] The recycling module is used to reclaim the resources corresponding to the idle target virtual machines in the target cluster as public resources when the target cluster resources are idle.

[0034] Wherein, the target cluster is the blockchain cluster or the data cluster; if the target cluster is the blockchain cluster, the target virtual machine is the blockchain virtual machine; if the target cluster is the data cluster, the target virtual machine is the data virtual machine.

[0035] Thirdly, the present invention provides a computer device, comprising: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the resource allocation method of the first aspect or any corresponding embodiment described above.

[0036] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to perform the resource allocation method of the first aspect or any corresponding embodiment thereof.

[0037] Fifthly, the present invention provides a computer program product, including computer instructions for causing a computer to execute the resource allocation method of the first aspect or any corresponding embodiment thereof.

[0038] The host cluster provided by this invention allows a host to allocate blockchain virtual machines to both blockchain clusters and data virtual machines to data clusters, and the host can reserve public resources. When any cluster resource is idle, the resources corresponding to its idle virtual machines can be reclaimed as public resources. Conversely, when another cluster's resources are insufficient, new virtual machines can be added to it based on public resources. This method uses different virtual machines to implement nodes in each cluster, achieving isolation between clusters. Furthermore, by reclaiming or adding resources to each blockchain cluster and data cluster based on public resources, dynamic resource scheduling between different clusters can be achieved, flexibly meeting business needs. Attached Figure Description

[0039] To more clearly illustrate the technical solutions in the specific embodiments or related technologies of the present invention, the drawings used in the description of the specific embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0040] Figure 1 This is a schematic diagram of a cluster deployment structure;

[0041] Figure 2 This is a schematic diagram of a host cluster according to an embodiment of the present invention;

[0042] Figure 3 This is a flowchart illustrating a resource allocation method according to an embodiment of the present invention;

[0043] Figure 4 This is a schematic diagram illustrating the addition of resources to a blockchain cluster according to an embodiment of the present invention;

[0044] Figure 5 This is a schematic diagram illustrating resource recovery for a blockchain cluster according to an embodiment of the present invention;

[0045] Figure 6 This is a flowchart illustrating another resource allocation method according to an embodiment of the present invention;

[0046] Figure 7 This is a structural block diagram of a resource allocation device according to an embodiment of the present invention;

[0047] Figure 8 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0048] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention 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, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0049] Before providing a detailed description of the embodiments of this application, some terms used in these embodiments will be explained. These explanations are intended to make the embodiments of this application easier to understand and should not be construed as limiting the scope of protection claimed in this application.

[0050] (1) Blockchain: Blockchain is a data structure that combines valid data blocks in a chain in chronological order. It is also a decentralized shared ledger that is cryptographically guaranteed to be immutable and non-repudiable. In a broad sense, blockchain technology is a new decentralized infrastructure and distributed computing paradigm that uses a cryptographic chain block structure to verify and store data, uses distributed node consensus algorithms to generate and update data, and uses automated script code (smart contracts) to program and manipulate data.

[0051] (2) Hyperconverged infrastructure: Hyperconverged infrastructure is a technical architecture based on a standard general-purpose hardware platform. It achieves the convergence of computing, storage, and networking through software definition, and can build a software-defined data center centered on virtualization. The hyperconverged architecture integrates the basic elements of the data center, such as computing, storage, networking, and management tools, and uses general-purpose server hardware to replace the expensive dedicated hardware in traditional architectures, which can solve problems such as complex management and difficulty in expansion.

[0052] In fields with high data security requirements, relevant nodes can be deployed in hyperconverged infrastructures (HCIs) to provide network services, computing services, storage services, and security services. For example, in fields such as healthcare and finance, HCIs can be used as the digital infrastructure to support blockchain. Deploying blockchain nodes in HCIs can provide network services, computing services, storage services, and security services to the decentralized nodes of the blockchain.

[0053] Figure 1 A schematic diagram of a cluster deployment structure is shown. For example... Figure 1 As shown, each blockchain node in the blockchain cluster is deployed on a corresponding physical machine; similarly, each data node in the data cluster is also deployed on its own physical machine, completely isolated physically. Data nodes can upload data to the blockchain using identifiers. Blockchain nodes store the data blocks corresponding to each identifier and can retrieve and transfer data based on the identifier.

[0054] One issue is that the deployment of blockchain nodes and data nodes on different physical machines results in insufficient configuration flexibility. For example, if the blockchain cluster has surplus resources but the data cluster has limited resources, the data cluster cannot utilize the physical resources of the nodes in the blockchain cluster, making dynamic allocation of node resources difficult.

[0055] This invention provides a resource allocation method in which a single host provides virtual machines to different clusters, forming corresponding cluster nodes; and the host reserves common resources, which are used to add or reclaim resources for virtual machines in different clusters, thereby realizing resource allocation between different clusters.

[0056] According to an embodiment of the present invention, a method embodiment for resource allocation is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0057] This embodiment provides a resource allocation method applied to a host cluster, which can provide the required nodes for multiple clusters; specifically, the hosts in the host cluster are used to provide blockchain virtual machines for the blockchain cluster and data virtual machines for the data cluster; and at least some hosts reserve public resources.

[0058] Figure 2 A schematic diagram of the host cluster is shown, such as Figure 2 As shown, the host cluster consists of multiple hosts. Figure 2 The example shown below contains three hosts: host 1, host 2, and host 3. Any host in the host cluster can provide corresponding nodes for different clusters.

[0059] like Figure 2 As shown, host 1 provides one or more blockchain virtual machines (VM11) for the blockchain cluster, which can serve as blockchain nodes. Similarly, host 2 provides one or more blockchain virtual machines (VM12) as blockchain nodes, and host 3 provides one or more blockchain virtual machines (VM13) as blockchain nodes. The blockchain nodes of multiple hosts in the host cluster can constitute the corresponding cluster, i.e., the blockchain cluster.

[0060] Similarly, host 1 provides one or more data virtual machines (VM21) for the data cluster, which can serve as data nodes. Likewise, host 2 provides one or more data virtual machines (VM22) as data nodes, and host 3 provides one or more data virtual machines (VM23) as data nodes. The data nodes of multiple hosts in the host cluster constitute the data cluster.

[0061] Furthermore, at least some hosts in the host cluster have reserved public resources. For example... Figure 2 As shown, all three hosts have reserved common resources. These common resources can form a common resource pool. By using the common resource pool, resources can be added to or reclaimed for virtual machines in different clusters, thereby realizing resource allocation between different clusters.

[0062] Specifically, the resource allocation method provided in this embodiment can be applied to the resource management module of a host cluster, such as... Figure 2 As shown, the resource management module can be a global management module for the host cluster, used to manage all hosts; or, each host can also have its own corresponding resource management module to manage the resources of each host separately. This embodiment does not limit this. Figure 3 This is a flowchart of a resource allocation method according to an embodiment of the present invention, such as... Figure 3 As shown, the process includes the following steps.

[0063] Step S301: If the target cluster resources are insufficient, add a new target virtual machine to the target cluster and allocate corresponding resources to the new target virtual machine based on public resources.

[0064] In this embodiment, for the sake of consistent description, the term "target cluster" refers to either the blockchain cluster or the data cluster. In other words, either the blockchain cluster or the data cluster can be used as the target cluster, and steps S301 and S302 are executed.

[0065] If the target cluster resources are insufficient, it means that new nodes need to be added to the target cluster. In this embodiment, the target virtual machine refers to the virtual machine corresponding to the target cluster. Accordingly, when the target cluster resources are insufficient, new target virtual machines can be added to the target cluster. Furthermore, since there are common resources in the host cluster, corresponding resources, such as processing resources and storage resources, can be allocated to the new target virtual machine based on these common resources.

[0066] It is understandable that when the target cluster is a blockchain cluster, the target virtual machine is a blockchain virtual machine; when the target cluster is a data cluster, the target virtual machine is a data virtual machine.

[0067] Taking a blockchain cluster as an example, during its operation, the cluster can monitor its own status in real time to determine resource usage. If its own resources are insufficient, it can notify the resource management module to indicate that system resources are inadequate. Upon determining that the blockchain cluster's resources are insufficient, the resource management module can then determine the need to add resources to the blockchain cluster.

[0068] Specifically, a new blockchain virtual machine (i.e., a new target virtual machine) can be added to the blockchain cluster. Resources can be requested from a reserved public resource pool, and corresponding resources can be allocated to the new blockchain virtual machine based on the public resources in the pool. These resources may include, for example, processing resources, memory resources, and storage resources. For instance, virtual CPUs, memory, and virtual disk volumes can be configured for the new blockchain virtual machine based on public resources.

[0069] In this embodiment, each host in the host cluster can pre-configure its own resources to configure the resources of the blockchain cluster, the data cluster, and public resources. Taking a specific host in the host cluster as an example... Figure 4 This diagram illustrates one way to add resources to a blockchain cluster. For example... Figure 4 As shown, host 1 of the host cluster sets up three blockchain virtual machines (i.e., blockchain virtual machines VM1-1, VM1-2, and VM1-3) and five data virtual machines (i.e., data virtual machines VM2-1, VM2-2, VM2-3, VM2-4, and VM2-5) for the blockchain cluster. In addition, the reserved public resources can be configured with three reserved virtual machines, i.e., virtual machines VM3-1, VM3-2, and VM3-3.

[0070] Each virtual machine in the host requires certain CPU and memory resources. For example, each virtual machine can be allocated a 4-core virtual CPU and 32GB of memory. In addition, each virtual machine also needs certain storage resources. For example, initially, the host can pre-configure 5TB of storage resources for the blockchain cluster, pre-configure 10TB of storage resources for the data cluster, and reserve 5TB of storage resources as public resources.

[0071] If the blockchain cluster lacks resources, the resource management module can add new blockchain virtual machines to the cluster. For example... Figure 4 As shown, virtual machine VM3-2, which belongs to public resources, can be used as a new blockchain virtual machine; that is, the resources corresponding to virtual machine VM3-2 are allocated to the blockchain cluster. A diagram illustrating the addition of resources to the blockchain cluster is shown below. Figure 4 As shown, after adding resources, the blockchain virtual machine in host 1 added virtual machine VM3-2.

[0072] Similarly, if the data cluster resources are insufficient, new data virtual machines can be added to the resource-deficient data cluster, and corresponding resources can be allocated to the new data virtual machines based on public resources. For example, [the following can be done:] Figure 4 The virtual machine VM3-1, which is a public resource in the middle, is used as a new data virtual machine, etc., which will not be described in detail in this embodiment.

[0073] It is understood that the virtual machines reserved in the public resources can be virtual machines that have already been created, or virtual machines can be created based on the public resources when it is necessary to add virtual machines for other clusters in the future. This embodiment does not limit this.

[0074] Step S302: When the target cluster resources are idle, reclaim the resources corresponding to the idle target virtual machines in the target cluster as public resources.

[0075] In this embodiment, if the target cluster resources are idle, it means that some resources in the target cluster can be released, and the release will not affect the normal operation of the target cluster. Therefore, at this time, the idle target virtual machines in the target cluster can be identified, and the resources corresponding to the idle target virtual machines can be recycled and recycled into public resources.

[0076] Continuing with the example of a blockchain cluster as the target cluster, if the blockchain cluster currently has idle resources, that is, if there are idle resources in the blockchain cluster, then resource reclamation can be carried out, that is, the resources corresponding to the idle blockchain virtual machines in the blockchain cluster can be reclaimed as public resources.

[0077] Specifically, when blockchain cluster resources are idle, the resource management module can select blockchain virtual machines to be reclaimed (i.e., idle blockchain virtual machines), migrate the data in the blockchain virtual machine to be reclaimed to other blockchain virtual machines in the blockchain cluster, and then reclaim the resources (such as CPU resources, storage resources, etc.) corresponding to the blockchain virtual machine and reclaim them as public resources.

[0078] Figure 5 This diagram illustrates one method for reclaiming resources for a blockchain cluster. For example... Figure 5 As shown, if the blockchain virtual machine VM1-3 in the blockchain cluster is idle, its data can be migrated to other virtual machines, such as blockchain virtual machine VM1-1 or blockchain virtual machines on other hosts, and the resources corresponding to blockchain virtual machine VM1-3 can be reclaimed to public resources. Figure 5 As shown, after resource reclamation, the blockchain virtual machines in host 1 only include VM1-1 and VM1-2, while the public resources include the resources corresponding to virtual machine VM1-3.

[0079] Similarly, if a data cluster requires resource reclamation, the data virtual machines within the cluster can be reclaimed as public resources, for example, by... Figure 5 The recycling of the data virtual machine VM2-5 into public resources, etc., will not be elaborated on in this embodiment.

[0080] It is understandable that both pre-set public resources and public resources recovered from other clusters can provide the necessary resources for virtual machines in any other cluster, no longer restricted by the cluster. That is, resources recovered from the blockchain cluster can also be provided to the data cluster, and resources recovered from the data cluster can also be provided to the blockchain cluster.

[0081] by Figure 5 As shown in the example, after reclaiming the resources of the blockchain virtual machine VM1-3, if additional resources are needed due to insufficient resources in the data cluster, the resources originally allocated to the blockchain virtual machine VM1-3 (which are public resources at this time) can be reallocated to the data virtual machines newly added to the data cluster, thereby realizing the dynamic allocation of resources among multiple clusters.

[0082] Furthermore, steps S302 and S301 can be performed simultaneously or sequentially. This embodiment does not limit the execution order of the two.

[0083] The resource allocation method provided in this embodiment allows a host in a host cluster to allocate blockchain virtual machines to both blockchain clusters and data virtual machines to data clusters, while also reserving public resources. When resources in any cluster are idle, the resources corresponding to its idle virtual machines can be reclaimed as public resources. Conversely, when resources in another cluster are insufficient, new virtual machines can be added based on public resources. This method uses different virtual machines to implement nodes in each cluster, achieving isolation between clusters. Furthermore, by reclaiming or adding resources for each blockchain cluster and data cluster based on public resources, dynamic resource scheduling between different clusters can be achieved, flexibly meeting business needs.

[0084] This embodiment provides another resource allocation method that can be applied to the aforementioned host cluster, such as the resource management module of the host cluster. Figure 6 This is a flowchart of a resource allocation method according to an embodiment of the present invention, such as... Figure 6 As shown, the process includes the following steps.

[0085] Step S601: When the blockchain cluster resources are insufficient, add a new blockchain virtual machine to the blockchain cluster with insufficient resources, and allocate corresponding resources to the new blockchain virtual machine based on public resources.

[0086] Please see details Figure 3 The relevant description of step S301 in the illustrated embodiment will not be repeated here.

[0087] In some optional implementations, the method further includes determining that the target cluster has insufficient resources when the resource utilization of the target cluster exceeds a first preset value.

[0088] For blockchain clusters, a first preset value can be set in advance. If the resource utilization rate of the blockchain cluster exceeds the first preset value, it is determined that the blockchain cluster resources are insufficient.

[0089] In this embodiment, the blockchain cluster can collect relevant resource utilization data, such as CPU utilization and memory utilization. If the resource utilization of the blockchain cluster exceeds a first preset value (e.g., 80%), the resource management module can be notified that the blockchain cluster has insufficient resources. After receiving the command indicating insufficient blockchain cluster resources, the resource management module can apply for resources from the reserved public resource pool. If the public resources of a certain host can meet the resource application requirements, a new blockchain virtual machine can be added based on the public resources of that host, and the newly added blockchain virtual machine can be configured with CPU, memory, and corresponding virtual storage volumes and other resources.

[0090] It should be noted that this resource utilization rate can be the overall utilization rate of the blockchain cluster, based on which resource scheduling is performed for the entire blockchain cluster. Alternatively, this resource utilization rate can also be the resource utilization rate of all blockchain virtual machines on a certain host. If the resource utilization rate exceeds a first preset value, it indicates that the host has not allocated enough resources to the blockchain cluster. In this case, blockchain virtual machines can be added using the public resources of the host or the public resources of other hosts to reduce the corresponding resource utilization rate.

[0091] Step S602: Set the corresponding encryption factor for the new blockchain virtual machine. This encryption factor is used to encrypt the data of the new blockchain virtual machine.

[0092] In this embodiment, the blockchain cluster is a cluster with high security requirements. To ensure data security, corresponding encryption factors are set for each blockchain virtual machine in the blockchain cluster. Similarly, when a new blockchain virtual machine is set up due to insufficient resources, a corresponding encryption factor also needs to be set for the new blockchain virtual machine. The encryption factor of the blockchain virtual machine is used to encrypt the data of that blockchain virtual machine to ensure data security.

[0093] For data related to a blockchain virtual machine, the data can be encrypted according to the encryption factor of that blockchain virtual machine and then stored. For example, the encrypted data can be saved to a virtual storage volume allocated to that blockchain virtual machine. When needed, the data can be decrypted according to the encryption factor of the blockchain virtual machine to recover the original plaintext.

[0094] It is understandable that each blockchain virtual machine in a blockchain cluster has a corresponding encryption factor set. That is, when creating a blockchain cluster, and when adding a new blockchain virtual machine to the cluster, it is necessary to set the corresponding encryption factor for each blockchain virtual machine.

[0095] In some optional implementations, the encryption factors corresponding to each blockchain virtual machine are different. Specifically, when adding a new blockchain virtual machine (e.g., when adding a blockchain virtual machine due to insufficient resources, or when adding a blockchain virtual machine when creating a blockchain cluster), the process of setting the encryption factor for the new blockchain virtual machine includes the following steps A1 to A2.

[0096] Step A1: Determine the global parameters used to represent the global characteristics of the host cluster.

[0097] In this embodiment, features that can globally represent the host cluster can be obtained, namely global features, wherein global parameters represent the global features of the host cluster.

[0098] A host cluster consists of multiple hosts, and global parameters that can represent the global characteristics of the host cluster can be generated by combining the relevant parameters of each host.

[0099] Optionally, step A1, "determining global parameters for representing global characteristics of the host cluster," may include steps A11 to A12.

[0100] Step A11: Obtain the first hardware parameters of each host in the host cluster.

[0101] Step A12: Determine the global parameters of the host cluster based on the first hardware parameters of each host.

[0102] In this embodiment, for each host in the host cluster, hardware-related parameters, namely the first hardware parameter, can be determined for each host. For example, the first hardware parameter can be the host's CPU serial number, or it can be the network card MAC address, etc. For example, the host's CPU serial number can be obtained based on the following command: #cat / sys / devices / virtual / dmi / id / product_serial.

[0103] After obtaining the initial hardware parameters of each host, the global parameters of the host cluster can be determined based on these initial hardware parameters.

[0104] by Figure 2Taking the host cluster shown as an example, it includes three hosts (i.e., host 1, host 2, and host 3). If the first hardware parameters of the three hosts are key1, key2, and key3 respectively, then the global parameter Globalkey of the host cluster can be: Globalkey = Rule_1(key1, key2, key3). Here, Rule_1 is a preset calculation rule. For example, Rule_1 can be a concatenation of all the first hardware parameters, or a weighted summation of all the first hardware parameters, etc. This embodiment does not limit the specific method of Rule_1.

[0105] Optionally, step A1, "determining global parameters for representing global characteristics of the host cluster," may also include step A13.

[0106] Step A13: When adding, deleting, or changing the hardware configuration of hosts in the host cluster, the first hardware parameters of each host in the host cluster are redefined to redetermine the global parameters of the host cluster.

[0107] In this embodiment, if host 'a' is added to the host cluster, the first hardware parameters of host 'a' can be determined, and the global parameters of the host cluster can be re-determined based on this. If... Figure 2 Taking the host cluster shown as an example, if a fourth host 'a' is added, the first hardware parameter 'keyan' of host 'a' can be determined, and the global parameter 'Globalkeynew' of the host cluster can be reconstructed, which can be expressed as: Globalkeynew = Rule_1(key1,key2,key3,keyan).

[0108] Similarly, if a host in the host cluster is removed, it is no longer necessary to use that removed host to calculate global parameters. Continuing with... Figure 2 Taking the host cluster shown as an example, if host 1 is removed, the first hardware parameter key1 of host 1 is no longer needed. Therefore, the new global parameter Globalkeynew of the host cluster can be expressed as: Globalkeynew = Rule_1(key2,key3).

[0109] Furthermore, if the hardware configuration of a host in the host cluster changes, the primary hardware parameters may also change. Therefore, it is necessary to redetermine the primary hardware parameters of each host in the host cluster in order to redetermine the global parameters of the host cluster. For example, if Figure 2 In the host cluster shown, the hardware configuration of host 1 changes, and its first hardware parameter after the change is key1n. Then the new global parameter Globalkeynew of the host cluster can be expressed as: Globalkeynew = Rule(key1n,key2,key3).

[0110] Step A2: Determine the encryption factor of the new blockchain virtual machine based on its attribute information and global parameters.

[0111] In this embodiment, when adding a new blockchain virtual machine, its attribute information can be determined for each blockchain virtual machine. This attribute information represents the characteristics of the blockchain virtual machine itself. Then, based on this global parameter and the attribute information of the blockchain virtual machine, characteristic parameters that can represent the blockchain virtual machine are comprehensively determined and used as the encryption factor of the blockchain virtual machine.

[0112] Optionally, the attribute information of the blockchain virtual machine includes the second hardware parameters of the target host corresponding to the blockchain virtual machine, as well as the virtual machine parameters of the blockchain virtual machine itself. Accordingly, step A2, "determine the encryption factor of the new blockchain virtual machine based on the attribute information and global parameters of the new blockchain virtual machine", may include steps A21 to A22.

[0113] Step A21: Determine the second hardware parameters of the target host corresponding to the new blockchain virtual machine, and determine the virtual machine parameters of the new blockchain virtual machine; the second hardware parameters and virtual machine parameters are included in the attribute information; the target host is a host in the host cluster.

[0114] Step A22: Determine the encryption factor of the new blockchain virtual machine based on the global parameters, the second hardware parameters, and the virtual machine parameters of the new blockchain virtual machine.

[0115] In this embodiment, when adding blockchain virtual machines to a blockchain cluster, for each new blockchain virtual machine, its corresponding target host can be determined. This target host is a host within the host cluster, and the new blockchain virtual machine is built by the target host. Figure 2 As shown in the example, the blockchain virtual machine VM12 is located in host 2, so host 2 is the target host corresponding to the blockchain virtual machine VM12.

[0116] When determining the attribute information of a new blockchain virtual machine, the hardware parameters of its corresponding target host, i.e., the second hardware parameters, can be determined. These second hardware parameters can be parameters with higher security than the first hardware parameters. For example, the second hardware parameter can be a random number related to the target host hardware determined based on the TPM (Trusted Platform Module).

[0117] Furthermore, the relevant parameters of the new blockchain virtual machine itself can be determined, namely the virtual machine parameters of the new blockchain virtual machine. For example, the virtual machine parameters of the new blockchain virtual machine may include configuration parameters (such as the number of CPUs, memory size, etc.) and / or virtual machine ID, etc. Based on these virtual machine parameters and global parameters, the encryption factor of the new blockchain virtual machine is determined.

[0118] Specifically, when creating a blockchain virtual machine (e.g., when initially deploying a blockchain cluster based on a host cluster, or when creating a new blockchain virtual machine due to insufficient blockchain cluster resources), the global key of the host cluster and the target host where the blockchain virtual machine resides can be determined. This allows for the determination of the target host's hardware tpmkey random number (i.e., the second hardware parameter), as well as the blockchain virtual machine's configuration parameters (number of CPUs, memory size), virtual machine ID, etc., based on which the encryption factor of the blockchain virtual machine is constructed. For example, the encryption factor VM_key1 of the blockchain virtual machine can be represented as: VM_key1 = Rule_2(tpmkey, Globalkey, virtual machine configuration parameters, virtual machine ID). Rule_2 is a preset rule, and rule_2 can be the same as or different from the aforementioned rule_1.

[0119] The encryption factors for each blockchain virtual machine can be stored in the header of the corresponding virtual storage volume. Specifically, for the blockchain virtual machines on the target host, virtual disk volumes are configured as storage resources for each blockchain virtual machine, and the encryption factors of each blockchain virtual machine can be stored in the header of the virtual storage volume of each blockchain virtual machine on the target host to ensure the security of the encryption factors. For example, as a blockchain node, the blockchain virtual machine can ensure the reliability of the encryption factors of each blockchain virtual machine.

[0120] For example, such as Figure 4 As shown, if host 1 includes three blockchain virtual machines, namely VM1-1, VM1-2, and VM1-3, corresponding virtual storage volumes vol1-1, vol1-2, and vol1-3 can be configured for the three blockchain virtual machines respectively. For the encryption factor of blockchain virtual machine VM1-1, it can be stored in the volume header of virtual storage volumes vol1-1, vol1-2, and vol1-3 and associated with the blockchain virtual machine VM1-1 for subsequent use.

[0121] Alternatively, as shown above, if the global parameters of the host cluster change, a new global parameter Globalkeynew can be determined, and each blockchain virtual machine in the blockchain cluster can be notified to update its encryption factor to: Rule_2(tpmkey,Globalkeynew,virtual machine configuration parameters,virtual machine ID).

[0122] Similarly, if the configuration of the blockchain virtual machine itself changes, its encryption factor also needs to be updated. The updated encryption factor is: Rule_2(tpmkey, Globalkey, virtual machine configuration parameter new, virtual machine ID). At this time, the corresponding blockchain virtual machine in the blockchain cluster is notified, and the updated encryption factor is rewritten to the virtual disk volume attributes of that blockchain virtual machine.

[0123] In this embodiment, by comprehensively considering the global parameters of the host cluster and the attribute information of each blockchain virtual machine, the encryption factor of the blockchain virtual machine is determined. This ensures that the encryption factor has comprehensive characteristics and that the encryption factors of each blockchain virtual machine are different. This not only guarantees security but also enables secure encryption of each blockchain virtual machine.

[0124] In some alternative implementations, the method further includes steps B1 to B3.

[0125] Step B1: When starting the blockchain virtual machine, obtain the encryption factor of the blockchain virtual machine.

[0126] Step B2: Determine whether the encryption factor of the blockchain virtual machine is correct.

[0127] Step B3: If the encryption factor of the blockchain virtual machine is correct, allow the blockchain virtual machine to start.

[0128] In this embodiment, when starting the blockchain virtual machine, the encryption factor of the blockchain virtual machine needs to be determined to ensure that the blockchain virtual machine is functioning correctly. Specifically, the resource management module can obtain global parameters of the host cluster, virtual machine configuration parameters of each blockchain virtual machine, virtual machine ID, etc. When starting the blockchain virtual machine, the resource management module can read the virtual disk volume attributes (e.g., volume header) of the blockchain virtual machine to obtain the encryption factor VM_key. Based on the encryption factor VM_key, global parameters, virtual machine configuration parameters, virtual machine ID, etc., can be extracted. The extracted information is compared with the actual value. If they match, it means that the encryption factor of the blockchain virtual machine is correct, and the blockchain virtual machine is allowed to start. If they do not match, the blockchain virtual machine is not allowed to start.

[0129] Optionally, as shown above, the blockchain virtual machine is equipped with a virtual disk volume; and the encryption factor is used to encrypt the metadata of the virtual disk volume, etc., and the encrypted data is used as the volume header data, that is, the volume header data of the virtual disk volume is obtained after being encrypted according to the encryption factor.

[0130] In this embodiment, the virtual disk volume of the blockchain virtual machine includes a volume header and a volume body. The volume header is used to store metadata, i.e., volume header data, and the volume body is used to store actual business data, i.e., volume body data. Different keys are used to encrypt these two parts of data.

[0131] Specifically, for the header of a virtual disk volume, a suitable encryption key is determined using the encryption factor of the blockchain virtual machine. Then, based on this encryption key and a certain ciphertext algorithm, the data to be stored in the header (such as metadata, which does not include the encryption factor stored in the header) is encrypted to obtain the header data, which is then saved.

[0132] In addition, at least some of the virtual machine parameters of the blockchain virtual machine can also be used to encrypt the data (such as business data) of the volume body that needs to be stored in the virtual disk volume, and use the encrypted data as the volume body data. That is, the volume body data of the virtual disk volume is obtained after encryption based on at least some of the virtual machine parameters of the blockchain virtual machine.

[0133] For the volume body of a virtual disk volume, encryption is performed using the blockchain virtual machine's own virtual machine parameters (e.g., virtual machine ID) as a factor, based on a specific encryption algorithm, and then stored in ciphertext. If a blockchain virtual machine is migrated to another location within the blockchain cluster (e.g., from host 1 to host 2, not deleted), since the volume body data of that blockchain virtual machine is encrypted based on its own virtual machine parameters (e.g., virtual machine ID), no processing of the volume body data is required. Only the encryption factor of the blockchain virtual machine needs to be updated, and the volume header data updated based on the new encryption factor.

[0134] When it is necessary to decrypt data in a virtual disk volume, the encrypted volume header data can be decrypted based on the encryption factor to recover the normal virtual disk volume header, ensuring that the system can start normally; the volume body data can also be decrypted in a similar way.

[0135] If the virtual disk volume of the blockchain virtual machine is migrated to a location other than the blockchain cluster, the volume header cannot be correctly recovered because it is encrypted, making it impossible for the blockchain virtual machine to start normally. Furthermore, the volume body data is stored in encrypted form and is invalid, rendering the blockchain virtual machine unusable. This ensures the security of the blockchain virtual machine and prevents it from being migrated to an unauthorized host, which could lead to data leakage.

[0136] In some optional implementations, if the target cluster is a blockchain cluster, then step S605, "reclaiming the resources corresponding to the idle target virtual machines in the target cluster as public resources", specifically means: reclaiming the resources corresponding to the idle blockchain virtual machines in the blockchain cluster as public resources, and this process specifically includes the following steps C1 to C4.

[0137] Step C1: If the target cluster is a blockchain cluster, determine the first idle blockchain virtual machine in the blockchain cluster.

[0138] Step C2 involves decrypting the data of the first blockchain virtual machine according to its encryption factor to obtain the original data of the first blockchain virtual machine. This data includes the header data corresponding to the blockchain virtual machine.

[0139] Step C3: Encrypt the original data according to the encryption factor of the second blockchain virtual machine in the blockchain cluster, and store the encrypted data in the storage area allocated to the second blockchain virtual machine.

[0140] Step C4: Delete the first blockchain virtual machine and reclaim the resources corresponding to the first blockchain virtual machine as public resources.

[0141] In this embodiment, each blockchain virtual machine in the blockchain cluster has an encryption factor. If the blockchain cluster resources are idle, the idle blockchain virtual machine in the blockchain cluster can be identified; for ease of description, it is referred to as the first blockchain virtual machine.

[0142] When reclaiming resources corresponding to the first blockchain virtual machine, the data of the first blockchain virtual machine needs to be migrated to other blockchain virtual machines, which are referred to here as second blockchain virtual machines. The number of second blockchain virtual machines can be one or more, depending on actual needs.

[0143] When reclaiming resources corresponding to the first blockchain virtual machine, since the data of the first blockchain virtual machine is encrypted using an encryption factor, it is first necessary to decrypt the data based on the encryption factor of the first blockchain virtual machine to restore the unencrypted data of the first blockchain virtual machine, i.e., the original data. As shown above, a virtual disk volume can be configured for the blockchain virtual machine. Correspondingly, the data of the blockchain virtual machine includes volume header data, which can then be decrypted based on the encryption factor of the first blockchain virtual machine.

[0144] If data needs to be migrated from the first blockchain virtual machine to the second blockchain virtual machine, the original data needs to be encrypted again according to the encryption factor of the second blockchain virtual machine in the blockchain cluster. The encrypted data is then stored in the storage area allocated to the second blockchain virtual machine, such as the virtual storage volume of the second blockchain virtual machine. This completes the data migration process.

[0145] Since all the data of the first blockchain virtual machine has been migrated to the second blockchain virtual machine, the first blockchain virtual machine can now be deleted, and the resources corresponding to the first blockchain virtual machine can be reclaimed as public resources for use by other virtual machines.

[0146] It is understandable that if the encryption factor is only used to encrypt the header data of the virtual disk volume, while the body data of the virtual disk volume is encrypted based on at least some virtual machine parameters (e.g., virtual machine ID) of the blockchain virtual machine, then when migrating the data corresponding to the first blockchain virtual machine (including the header data and body data), the header data is decrypted based on the encryption factor of the first blockchain virtual machine, and the body data is decrypted based on the virtual machine parameters (e.g., virtual machine ID) of the first blockchain virtual machine. Then, the decrypted header data is re-encrypted based on the encryption factor of the second blockchain virtual machine, and the decrypted body data is re-encrypted based on the virtual machine parameters (e.g., virtual machine ID) of the second blockchain virtual machine, and stored in the virtual storage volume of the second blockchain virtual machine, completing the data migration process.

[0147] Step S603: Add the new blockchain virtual machine to the blockchain cluster.

[0148] In this embodiment, after configuring the blockchain virtual machine, such as setting an encryption factor and allocating corresponding resources, it can be added to the blockchain cluster to perform corresponding tasks.

[0149] Step S604: In the case of insufficient data cluster resources, add new data virtual machines to the data cluster with insufficient resources; allocate corresponding resources to the new data virtual machines based on public resources.

[0150] In this embodiment, if the data cluster resources are insufficient, new data virtual machines can be added. For example, if the resource utilization rate of the data cluster exceeds a first preset value (e.g., 80%), then it is determined that the data cluster resources are insufficient. For details, please refer to [link to relevant documentation]. Figure 3 Step S301 of the illustrated embodiment will not be described again here.

[0151] Among them, the data cluster has low security requirements. It can be a regular data cluster that can be deployed with conventional configuration. There is no secure encryption factor mechanism. That is, there is no need to configure secure encryption factors for the data virtual machine, and the corresponding virtual disk volume does not need to store encryption factors.

[0152] It is understood that the above-mentioned process of adding a data virtual machine (i.e., step S604) and the process of adding a blockchain virtual machine (i.e., steps S601 to S603) can be performed simultaneously or sequentially. This embodiment does not limit the execution order of the two.

[0153] Step S605: When the target cluster resources are idle, reclaim the resources corresponding to the idle target virtual machines in the target cluster as public resources.

[0154] Specifically, if at least one of the blockchain cluster and the data cluster has idle resources, the resources corresponding to the idle virtual machines in the idle cluster will be reclaimed as public resources. For details, please refer to [link to relevant documentation]. Figure 3 Step S302 of the illustrated embodiment will not be described again here.

[0155] In this embodiment, the method may further include: when the resource utilization rate of the target cluster is lower than a second preset value, determining that the target cluster resources are idle, and designating the virtual machine with the lowest resource utilization rate in the target cluster as the idle virtual machine.

[0156] Specifically, when the resource utilization rate of the blockchain cluster is lower than a second preset value, the blockchain cluster resources are determined to be idle, and the blockchain virtual machine with the lowest resource utilization rate is designated as the idle blockchain virtual machine. It can be understood that the second preset value is less than the first preset value.

[0157] In this embodiment, the resource utilization rate of the blockchain cluster, such as CPU utilization and memory utilization, is collected periodically. When the resource utilization rate of the blockchain cluster is lower than a second preset value (e.g., 50%), the blockchain cluster can notify the resource management module to inform it of its system resource usage.

[0158] The resource management module receives the resource usage information of the blockchain cluster and can determine which blockchain virtual machines (i.e., idle blockchain virtual machines) need to be reclaimed. Generally, the blockchain virtual machine with the lowest resource utilization rate is designated as an idle blockchain virtual machine. Then, the module instructs the blockchain cluster to migrate the data of the idle blockchain virtual machines, and then the resource reclamation can be achieved.

[0159] Since multiple blockchain virtual machines can be configured within the host, the number of blockchain virtual machines to be recycled can be determined based on the resource utilization rate of the blockchain cluster. For example, if the resource utilization rate of the blockchain cluster is less than 50%, one blockchain virtual machine is recycled; if the resource utilization rate of the blockchain cluster is less than 30%, two blockchain virtual machines are recycled.

[0160] For example, see Figure 5As shown, if the resource utilization of blockchain virtual machine VM1-3 is the lowest, then VM1-3 can be selected, and its business data can be dynamically migrated to other blockchain virtual machines in the blockchain cluster, such as to a specific blockchain virtual machine or evenly distributed across multiple blockchain virtual machines. After the migration is complete, the contents of the virtual storage volume of blockchain virtual machine VM1-3 are erased, then the virtual storage volume of blockchain virtual machine VM1-3 is deleted, and the CPU resources, memory resources, etc., allocated to blockchain virtual machine VM1-3 are reclaimed. At this point, the resource utilization of the cluster can be updated, and the quantity of public resources can be updated.

[0161] Similarly, if the resource utilization of the data cluster is lower than a second preset value (e.g., 50%), the data cluster resources are determined to be idle, and the data virtual machine with the lowest resource utilization is designated as the idle data virtual machine.

[0162] It is understood that for blockchain clusters and data clusters, a first preset value of the same size can be set for both, or a first preset value of different sizes can be set for both; similarly, a second preset value of the same size can be set for both, or a second preset value of different sizes can be set for both, and this embodiment does not limit this.

[0163] In this embodiment, since multiple data virtual machines can be configured within the host, the number of data virtual machines to be reclaimed can be determined based on the resource utilization rate of the data cluster. For example, if the resource utilization rate of the data cluster is less than 50%, two data virtual machines are reclaimed; if the resource utilization rate of the data cluster is less than 30%, three data virtual machines are reclaimed, and so on.

[0164] Continue with Figure 5 For example, if the data virtual machines VM2-4 and VM2-5 are in the data cluster, the business data of VM2-4 and VM2-5 will be dynamically migrated to other data virtual machines in the data cluster. After the migration is complete, the virtual storage volume content of data virtual machine VM2-4 is erased, then the virtual storage volume of data virtual machine VM2-4 is deleted, and then the virtual storage volume content of data virtual machine VM2-5 is erased and deleted. Furthermore, the CPU resources, memory resources, etc., allocated to data virtual machines VM2-4 and VM2-5 are reclaimed. At this point, the data cluster resource utilization rate and the quantity of shared resources can be updated.

[0165] The resource allocation method provided in this embodiment enables dynamic scheduling of system resources by configuring different virtual machines for different clusters. For example, configuring blockchain virtual machines for blockchain clusters and data virtual machines for ordinary data clusters. This allows for more flexible fulfillment of business needs. During dynamic resource allocation, blockchain virtual machines and data virtual machines are isolated from each other. Furthermore, if the data volume of a blockchain virtual machine is moved to a location outside its cluster, it will not be able to start, ensuring security in blockchain and other similar scenarios. The encryption factor is determined comprehensively based on global parameters and the virtual machine's own parameters, and is linked to the virtual disk volume to improve security isolation.

[0166] This embodiment also provides a resource allocation apparatus for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0167] This embodiment provides a resource allocation device applied to a host cluster; the hosts in the host cluster are used to provide blockchain virtual machines for a blockchain cluster and data virtual machines for a data cluster; and at least some hosts reserve public resources; such as Figure 7 As shown, the device includes:

[0168] A new module 701 is added, which is used to add a new target virtual machine to the target cluster when the target cluster resources are insufficient, and to allocate corresponding resources to the new target virtual machine based on the public resources;

[0169] The recycling module 702 is used to reclaim the resources corresponding to the idle target virtual machines in the target cluster as public resources when the target cluster resources are idle.

[0170] Wherein, the target cluster is the blockchain cluster or the data cluster; if the target cluster is the blockchain cluster, the target virtual machine is the blockchain virtual machine; if the target cluster is the data cluster, the target virtual machine is the data virtual machine.

[0171] In some optional implementations, when the target cluster is the blockchain cluster, adding a new target virtual machine to the target cluster and allocating corresponding resources to the new target virtual machine based on the public resources includes:

[0172] Allocate corresponding resources to the new blockchain virtual machine based on the aforementioned public resources;

[0173] Set corresponding encryption factors for the new blockchain virtual machine; the encryption factors are used for encryption and decryption processing of the data of the new blockchain virtual machine;

[0174] Add the new blockchain virtual machine to the blockchain cluster.

[0175] In some optional implementations, setting the corresponding encryption factors for the new blockchain virtual machine includes:

[0176] Determine global parameters used to represent the global characteristics of the host cluster;

[0177] The encryption factor of the new blockchain virtual machine is determined based on the attribute information of the new blockchain virtual machine and the global parameters.

[0178] In some optional implementations, determining the global parameters used to represent the global characteristics of the host cluster includes:

[0179] Obtain the first hardware parameters of each host in the host cluster;

[0180] The global parameters of the host cluster are determined based on the first hardware parameters of each host.

[0181] In some optional implementations, the attribute information of the new blockchain virtual machine includes: the second hardware parameters of the target host corresponding to the new blockchain virtual machine, and the virtual machine parameters of the new blockchain virtual machine; the target host is a host in the host cluster.

[0182] In some alternative implementations, the new blockchain virtual machine is equipped with a virtual disk volume;

[0183] The header data of the virtual disk volume is obtained by encrypting it according to the encryption factor.

[0184] In some alternative embodiments, the apparatus further includes a processing module for:

[0185] When the blockchain virtual machine is started, the encryption factor of the blockchain virtual machine is obtained;

[0186] Determine whether the encryption factor of the blockchain virtual machine is correct;

[0187] If the encryption factor of the blockchain virtual machine is correct, the blockchain virtual machine is allowed to start.

[0188] In some optional implementations, the recycling module 702 reclaims the resources corresponding to idle target virtual machines in the target cluster as public resources, including:

[0189] If the target cluster is the blockchain cluster, determine the first idle blockchain virtual machine in the blockchain cluster;

[0190] The data of the first blockchain virtual machine is decrypted according to the encryption factor of the first blockchain virtual machine to obtain the original data of the first blockchain virtual machine; wherein, the data of the blockchain virtual machine includes the header data corresponding to the blockchain virtual machine.

[0191] The original data is encrypted according to the encryption factor of the second blockchain virtual machine in the blockchain cluster, and the encrypted data is stored in the storage area allocated to the second blockchain virtual machine.

[0192] Delete the first blockchain virtual machine and reclaim the resources corresponding to the first blockchain virtual machine as public resources.

[0193] In this embodiment, the resource allocation device is presented in the form of a functional unit. Here, a unit refers to an ASIC (Application Specific Integrated Circuit) circuit, including a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0194] This invention also provides a computer device having the above-described features. Figure 7 The device shown is for resource allocation.

[0195] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of the present invention, such as... Figure 8 As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 8 Take a processor 10 as an example.

[0196] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GPA), or any combination thereof.

[0197] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0198] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0199] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0200] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0201] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0202] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0203] Although embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations should all be covered within the protection scope of the present invention.

Claims

1. A method for resource allocation, characterized in that, The method is applied to a host cluster; the hosts in the host cluster are used to provide blockchain virtual machines for the blockchain cluster and data virtual machines for the data cluster; and at least some hosts reserve public resources; the method includes: If the target cluster resources are insufficient, add a new target virtual machine to the target cluster and allocate corresponding resources to the new target virtual machine based on the public resources; When the target cluster resources are idle, the resources corresponding to the idle target virtual machines in the target cluster will be reclaimed as public resources; Wherein, the target cluster is the blockchain cluster or the data cluster; if the target cluster is the blockchain cluster, the target virtual machine is the blockchain virtual machine; if the target cluster is the data cluster, the target virtual machine is the data virtual machine.

2. The method according to claim 1, characterized in that, When the target cluster is the blockchain cluster, the step of adding a new target virtual machine to the target cluster and allocating corresponding resources to the new target virtual machine based on the public resources includes: Allocate corresponding resources to the new blockchain virtual machine based on the aforementioned public resources; Set corresponding encryption factors for the new blockchain virtual machine; the encryption factors are used for encryption and decryption processing of the data of the new blockchain virtual machine; Add the new blockchain virtual machine to the blockchain cluster.

3. The method according to claim 2, characterized in that, Setting the corresponding encryption factors for the new blockchain virtual machine includes: Determine global parameters used to represent the global characteristics of the host cluster; The encryption factor of the new blockchain virtual machine is determined based on the attribute information of the new blockchain virtual machine and the global parameters.

4. The method according to claim 3, characterized in that, The determination of global parameters used to represent the global characteristics of the host cluster includes: Obtain the first hardware parameters of each host in the host cluster; The global parameters of the host cluster are determined based on the first hardware parameters of each host.

5. The method according to claim 3, characterized in that, The attribute information of the new blockchain virtual machine includes: The second hardware parameters of the target host corresponding to the new blockchain virtual machine, and the virtual machine parameters of the new blockchain virtual machine; the target host is a host in the host cluster.

6. The method according to claim 5, characterized in that, The new blockchain virtual machine is equipped with virtual disk volumes; The header data of the virtual disk volume is obtained by encrypting it according to the encryption factor.

7. The method according to claim 2, characterized in that, The method further includes: When the blockchain virtual machine is started, the encryption factor of the blockchain virtual machine is obtained; Determine whether the encryption factor of the blockchain virtual machine is correct; If the encryption factor of the blockchain virtual machine is correct, the blockchain virtual machine is allowed to start.

8. The method according to claim 2, characterized in that, The step of reclaiming the resources corresponding to idle target virtual machines in the target cluster as public resources includes: If the target cluster is the blockchain cluster, determine the first idle blockchain virtual machine in the blockchain cluster; The data of the first blockchain virtual machine is decrypted according to the encryption factor of the first blockchain virtual machine to obtain the original data of the first blockchain virtual machine; wherein, the data of the blockchain virtual machine includes the header data corresponding to the blockchain virtual machine. The original data is encrypted according to the encryption factor of the second blockchain virtual machine in the blockchain cluster, and the encrypted data is stored in the storage area allocated to the second blockchain virtual machine. Delete the first blockchain virtual machine and reclaim the resources corresponding to the first blockchain virtual machine as public resources.

9. A resource allocation device, characterized in that, Applied to a host cluster; the hosts in the host cluster are used to provide blockchain virtual machines for the blockchain cluster and data virtual machines for the data cluster; and at least some hosts reserve public resources; the device includes: A new module is added to the target cluster when the target cluster resources are insufficient, and to allocate corresponding resources to the new target virtual machine based on the public resources. The recycling module is used to reclaim the resources corresponding to the idle target virtual machines in the target cluster as public resources when the target cluster resources are idle. Wherein, the target cluster is the blockchain cluster or the data cluster; if the target cluster is the blockchain cluster, the target virtual machine is the blockchain virtual machine; if the target cluster is the data cluster, the target virtual machine is the data virtual machine.

10. A computer device, characterized in that, include: A memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, the processor executing the computer instructions to perform the resource allocation method of any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the resource allocation method according to any one of claims 1 to 8.

Images