A diskless client allocation method, device, apparatus and storage medium

Abstract

This application discloses a diskless client allocation method, apparatus, device, and storage medium, relating to the field of resource scheduling technology and applied to a preset allocation platform. The method includes: receiving a diskless client allocation request including a source identifier, a data center identifier, and a virtual private cloud identifier; querying whether a target client corresponding to the diskless client allocation request exists based on the source identifier; if no target client exists, acquiring a local lock based on the data center identifier and the virtual private cloud identifier to restrict client allocation operations of the same instance within the same virtual private cloud; querying again based on the source identifier to obtain a query result; determining the target client based on the query result; and executing the client allocation operation of the diskless client allocation request to complete the client allocation. This can effectively improve the success rate of diskless client address allocation and reduce the probability of conflicts.

Description

Technical Field

[0001] This invention relates to the field of resource scheduling technology, and in particular to a diskless client allocation method, apparatus, device, and storage medium. Background Technology

[0002] In scenarios such as bare metal boot, hardware detection, and BIOS (Basic Input Output System) refresh, the platform needs to first create a corresponding client for the target device in the diskless system and assign an available IP address (Internet Protocol address) to the client so that the device can boot from the diskless environment.

[0003] With the increasing number of business entry points, different entry points such as bare metal boot, hardware detection, and basic input / output system refresh independently maintain their own processing logic for querying available addresses and creating clients. This lack of a unified allocation and control chain results in logical redundancy and difficulty in uniformly managing conflicts between concurrent allocation requests across different entry points. Furthermore, to ensure high service availability, allocation platforms typically employ a multi-instance deployment architecture. Therefore, in concurrent scenarios with multiple entry points and multiple instances, multiple requests may simultaneously query the same available IP address within the current VPC (Virtual Private Cloud) and initiate creation, leading to issues such as duplicate address contention, client creation failures, and resource waste, resulting in a low overall allocation success rate. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a diskless client address allocation method, apparatus, device, and storage medium, which can effectively improve the success rate of diskless client address allocation and reduce the probability of conflicts. The specific solution is as follows: Firstly, this application provides a diskless client allocation method, applied to a preset allocation platform, comprising: Receive diskless client allocation request; the diskless client allocation request includes source identifier, data center identifier and virtual private cloud identifier; the source identifier is the unique idempotent anchor point of the diskless client allocation request, used to uniquely identify the service source corresponding to the diskless client allocation request; The system queries whether a target client corresponding to the diskless client allocation request exists based on the source identifier. If no target client corresponding to the diskless client allocation request exists, the system acquires a local lock based on the data center identifier and the virtual private cloud identifier, and queries again based on the source identifier to determine whether a target client corresponding to the diskless client allocation request exists, thus obtaining the query result. The local lock is used to serially process client allocation operations for multiple diskless client allocation requests received by the same instance of the preset allocation platform within the same virtual private cloud. Based on the query results, the target client in the diskless system is determined, and the client allocation operation corresponding to the diskless client allocation request is executed to complete the client allocation of the diskless client allocation request.

[0005] Optionally, after querying whether a target client corresponding to the diskless client allocation request exists based on the source identifier, the method further includes: When a client corresponding to the diskless client allocation request is found based on the source identifier, the found client is directly identified as the target client.

[0006] Optionally, determining the target client in the diskless system based on the query result includes: When the query result indicates that there is a client in the diskless system corresponding to the diskless client allocation request, the queried client is determined as the target client; Accordingly, when the query result indicates that there is no client corresponding to the diskless client allocation request, candidate addresses in the virtual private cloud are determined, and the target address corresponding to the diskless client allocation request is determined from among the candidate addresses. A client is created in the diskless system based on the target address, and the actual address of the currently created client is queried based on the source identifier; When the actual address matches the target address, the currently created client is identified as the target client.

[0007] Optionally, determining the target address corresponding to the diskless client allocation request from the candidate addresses includes: Query the occupied addresses within the virtual private cloud, and determine the address range of the virtual private cloud based on the subnet mask of the virtual private cloud; Remove the gateway address and the occupied address from the address range to obtain the candidate address of the virtual private cloud; The address value of each address in the candidate addresses is determined, and the address with the smallest address value in the candidate addresses is determined as the target address.

[0008] Optionally, the process of querying the actual address of the currently created client based on the source identifier further includes: If the actual address of the currently created client is not found based on the source identifier, the actual address of the currently created client is queried again based on the source identifier according to the incremental backoff time interval, until the actual address of the currently created client is found, or the number of queries reaches a preset number threshold.

[0009] Optionally, the process of querying the actual address of the currently created client based on the source identifier further includes: When the preset query conditions are met, the candidate addresses in the virtual private cloud are queried again, and a new target address different from the target address is determined from the queried candidate addresses. The client is recreated based on the new target address, and the process jumps to the step of querying the actual address of the currently created client according to the source identifier, until the actual address of the recreated client is consistent with the corresponding target address. The preset query conditions are: the actual address of the currently created client is found based on the source identifier, and the actual address is inconsistent with the target address; or, the actual address of the currently created client is not found even when the number of queries reaches the preset number threshold.

[0010] Optionally, obtaining the corresponding local lock based on the data center identifier and the virtual private cloud identifier includes: A lock identifier is generated based on the data center identifier and the virtual private cloud identifier; The corresponding local lock is determined based on the lock identifier, so that several first allocation requests can be processed serially and several second allocation requests can be processed in parallel within the same virtual private cloud based on the local lock. The local lock is a mutex lock within a single instance process of the preset allocation platform. The first allocation request is an allocation request for the diskless client carrying the same data center identifier and the same virtual private cloud identifier. The second allocation request is an allocation request for the diskless client carrying different data center identifiers and / or different virtual private cloud identifiers.

[0011] Secondly, this application provides a diskless client allocation device, applied to a preset allocation platform, comprising: The request receiving module is used to receive diskless client allocation requests; the diskless client allocation request includes a source identifier, a data center identifier, and a virtual private cloud identifier; the source identifier is the unique idempotent anchor point of the diskless client allocation request, used to uniquely identify the service source corresponding to the diskless client allocation request; The client query module is used to query whether there is a target client corresponding to the diskless client allocation request based on the source identifier. If there is no target client corresponding to the diskless client allocation request, it acquires the corresponding local lock based on the data center identifier and the virtual private cloud identifier, and queries again based on the source identifier to determine whether there is a target client corresponding to the diskless client allocation request, thus obtaining the query result. The local lock is used to serially process the client allocation operations of multiple diskless client allocation requests received by the same instance of the preset allocation platform within the same virtual private cloud. The client allocation module is used to determine the target client in the diskless system based on the query result, and execute the client allocation operation corresponding to the diskless client allocation request to complete the client allocation of the diskless client allocation request.

[0012] Thirdly, this application provides an electronic device including a processor and a memory; wherein the memory is used to store a computer program, which is loaded and executed by the processor to implement the aforementioned diskless client allocation method.

[0013] Fourthly, this application provides a computer-readable storage medium for storing a computer program that, when executed by a processor, implements the aforementioned diskless client allocation method.

[0014] This application can receive diskless client allocation requests including a source identifier, a data center identifier, and a virtual private cloud identifier. It queries whether a target client corresponding to the diskless client allocation request exists based on the source identifier. If no target client exists, it acquires the corresponding local lock based on the data center identifier and the virtual private cloud identifier, and queries again based on the source identifier to obtain the query result. Then, based on the query result, it determines the target client in the diskless system and executes the client allocation operation corresponding to the diskless client allocation request to complete the client allocation for the diskless client allocation request.

[0015] Based on the above technical solution, this application can use a local lock with a granularity of combining data center identifier and virtual private cloud identifier for concurrency control. This constrains client allocation operations within the same data center and virtual private cloud, ensuring that allocation operations across different virtual private clouds do not interfere with each other. This effectively reduces the probability of conflicts caused by multiple concurrent requests and duplicate creations within the same virtual private cloud on a single instance, while avoiding overall performance degradation caused by global locks. This improves both concurrency control and system operating efficiency. Furthermore, after acquiring the local lock, it checks the client's existence again based on the source identifier, effectively identifying clients created by other threads during the lock waiting period. This avoids duplicate allocation and creation operations caused by lock waiting time differences, further improving the accuracy and efficiency of the allocation process. Simultaneously, since this application can reduce the probability of concurrency conflicts based on the service instance's own local lock, it eliminates the need for additional components such as distributed locks and independent resource scheduling services, resulting in low modification costs and effectively reducing deployment and maintenance complexity. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0017] Figure 1 A flowchart of a diskless client allocation method provided in this application; Figure 2 A schematic diagram of an IP allocation process based on local lock control provided for this application; Figure 3 A flowchart of a diskless client creation method provided in this application; Figure 4 This application provides a flowchart of a diskless client machine backtesting verification process; Figure 5 This application provides a flowchart for IP conflict identification and reallocation. Figure 6 This application provides a schematic diagram of a diskless client IP allocation structure. Figure 7 A schematic diagram of a diskless client machine allocation device provided in this application; Figure 8 This application provides a structural diagram of an electronic device. Detailed Implementation

[0018] 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, 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 are within the scope of protection of the present invention.

[0019] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0020] With the increasing number of business entry points, multiple business links such as bare metal boot and hardware detection can independently trigger diskless client allocation requests. At the same time, allocation platforms generally adopt a multi-instance deployment architecture, and the address allocation process is prone to concurrent conflicts, which can lead to client creation failures and resource waste. This application can use local locks for concurrency control to constrain client allocation operations. It unifies the diskless client allocation requests from multiple business entry points such as bare metal boot, hardware detection, and basic input / output system refresh to a preset allocation platform. Through a unified allocation process, it achieves single-instance concurrency suppression and multi-instance conflict self-healing, effectively reducing the probability of multiple requests for concurrent preemption and duplicate creation conflicts within the same virtual private cloud in a single instance. Furthermore, through mechanisms such as post-creation verification, backoff retries, and IP conflict reassignment, it effectively improves the diskless client address allocation success rate in multi-instance scenarios.

[0021] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0022] See Figure 1 As shown, this embodiment of the invention discloses a diskless client allocation method, applied to a preset allocation platform, including: Step S11: Receive diskless client allocation request; the diskless client allocation request includes source identifier, data center identifier and virtual private cloud identifier; the source identifier is the unique idempotent anchor point of the diskless client allocation request, used to uniquely identify the service source corresponding to the diskless client allocation request.

[0023] It should be noted that the preset allocation platform receiving diskless client allocation requests in this embodiment can serve as a unified endpoint for multiple service entry points such as bare-metal boot, hardware detection, and BIOS flashing. When these multiple service entry points need to create diskless clients for the target device, they all do so through the preset allocation platform, eliminating the need for each to maintain independent processing logic for querying available addresses and creating clients. This avoids the address duplication and contention issues caused by each service link maintaining its own independent client creation logic, thus facilitating unified concurrency control and conflict self-healing of the address allocation process by the preset allocation platform. Accordingly, the preset allocation platform in this embodiment provides a unified allocation service for multiple service entry points.

[0024] Specifically, this embodiment can receive diskless client allocation requests, and the diskless client allocation request includes at least a source identifier, a data center identifier, and a virtual private cloud identifier. The source identifier (sourceId) is the unique idempotent anchor point of the diskless client allocation request, used to uniquely identify the service source corresponding to this allocation request, and serves as the unified basis for subsequent queries to determine whether the client already exists and for retrospective verification after client creation. The same source identifier corresponds to the same diskless client instance. The data center identifier identifies the data center to which the target device belongs, specifically the data center identifier (regionId). The virtual private cloud identifier identifies the virtual private cloud to which the target device belongs, specifically the virtual private cloud identifier (vpcId).

[0025] In one specific implementation, the diskless client allocation request may include, in addition to the source identifier, data center identifier, and virtual private cloud identifier, the diskless server identifier, the boot scheme identifier, and the MAC (Media Access Control) address of the bare metal device, so that the target device can boot through the diskless environment after completing the client allocation.

[0026] Step S12: Query whether there is a target client corresponding to the diskless client allocation request based on the source identifier. If there is no target client corresponding to the diskless client allocation request, obtain the corresponding local lock based on the data center identifier and the virtual private cloud identifier, and query again based on the source identifier whether there is a target client corresponding to the diskless client allocation request to obtain the query result. The local lock is used to serially process the client allocation operation of multiple diskless client allocation requests received by the same instance of the preset allocation platform within the same virtual private cloud.

[0027] It should be noted that in this embodiment, the source identifier (i.e., sourceId) is first used as a unified idempotent anchor to query whether a client corresponding to the diskless client allocation request already exists. When a client corresponding to the diskless client allocation request is found based on the source identifier, the found client is directly identified as the target client and allocated to the diskless client allocation request. In other words, if the client already exists, the already created client is reused and returned, instead of re-allocating the address and creating the client for each request. This avoids repeatedly creating clients corresponding to the same service source, reducing address waste and duplicate calls.

[0028] Further, see Figure 2 As shown, in this embodiment, when there is no target client corresponding to the diskless client allocation request, a global serialization lock is not used. Instead, a lock identifier is generated based on the data center identifier and the virtual private cloud identifier, for example, a lock key is generated in the form of regionId:vpcId. The corresponding local lock is obtained based on this lock identifier, and concurrency suppression is performed only within the same data center and the same virtual private cloud. It can be understood that the local lock is a mutex lock within the single instance process of the preset allocation platform, used to constrain client allocation operations of the same instance within the same virtual private cloud, so that allocation requests carrying the same data center identifier and the same virtual private cloud identifier are executed serially within the single instance. The local lock acts within the single instance process, and only suppresses concurrency of allocation requests within the same data center and the same virtual private cloud. Allocation requests from different virtual private clouds can be processed in parallel, reducing address preemption conflicts within a single instance while avoiding the overall performance loss caused by global locks. Concurrency conflicts between multiple instances are self-healed through subsequent back-checking and reallocation mechanisms. In other words, after acquiring a local lock, multiple diskless client allocation requests carrying the same data center identifier and the same virtual private cloud identifier can be processed serially within the same virtual private cloud, and multiple diskless client allocation requests carrying different data center identifiers and / or different virtual private cloud identifiers can be processed in parallel. This reduces the problem of multiple requests simultaneously preempting the same target address within a single instance of the same virtual private cloud, and avoids mutual blocking between unrelated virtual private clouds, thereby improving both concurrency control and system operating efficiency.

[0029] Furthermore, in this embodiment, after acquiring the local lock, it can again query the source identifier to see if a target client corresponding to the diskless client allocation request exists. This is used to identify whether other threads have already completed client creation during the lock waiting period. If the corresponding client has already been created by another thread during the lock waiting period, the client is directly reused, avoiding repeated address allocation and creation actions, thereby improving idempotency and processing efficiency in concurrent scenarios. Moreover, this embodiment can acquire the local lock after the initial query to determine if the client exists, and then perform a second query within the lock. This double-checked lock control mechanism prevents other threads from completing creation during the lock waiting period, effectively avoiding duplicate allocation and creation caused by lock waiting time differences.

[0030] In this way, after confirming that there is no target client corresponding to the source identifier, the pre-configured allocation platform connects the data center identifier (regionId) and the virtual private cloud identifier (vpcId) to form a lock key "regionId:vpcId", and uses the lock key to obtain the corresponding local lock. This ensures that address allocation operations within the same data center and the same virtual private cloud are subject to serial constraints, avoiding the problem of multiple concurrent requests under the same virtual private cloud simultaneously reading the same available IP and initiating duplicate creation. At the same time, allocation operations between different virtual private clouds are independent and unblocked, avoiding the overall performance degradation caused by global locks.

[0031] Step S13: Determine the target client in the diskless system based on the query result, and execute the client allocation operation corresponding to the diskless client allocation request to complete the client allocation of the diskless client allocation request.

[0032] In this embodiment, it should be noted that determining the target client based on the query results specifically includes the following client allocation operations. In one client allocation operation, if the query results indicate that a client corresponding to the diskless client allocation request already exists in the diskless system, the queried client is directly determined as the target client. In another client allocation operation, if the query results indicate that no corresponding client exists, then candidate addresses and corresponding target addresses in the virtual private cloud are first determined, and then a client is created in the diskless system based on the target address. The creation result is then confirmed through a back-check, and the created client is determined as the target client.

[0033] The candidate addresses mentioned above are the set of available IPs (Internet Protocol) within the current Virtual Private Cloud (VPN). Available IPs are unoccupied IP addresses within the VPN that can be allocated to clients. The target address is the target IP selected from the available IP set in this round. The actual address is the client's actual assigned IP obtained after client creation. In other words, this embodiment does not use the return result of the creation interface as the final success criterion. Instead, it checks the client's actual address based on the source identifier and verifies whether it matches the target address. Only when they match is the currently created client identified as the target client.

[0034] In this way, this embodiment can use local locks with a combined granularity of data center identifier and virtual private cloud identifier for concurrency control. This constrains client allocation operations within the same data center and virtual private cloud, ensuring that allocation operations across different virtual private clouds do not interfere with each other. This effectively reduces the probability of conflicts such as multiple requests for concurrent preemption and duplicate creation within the same virtual private cloud on a single instance, while avoiding the overall performance degradation caused by global locks. It improves both concurrency control and system operating efficiency. Furthermore, after acquiring the local lock, it checks the existence of the client again based on the source identifier, effectively identifying clients created by other threads during the lock waiting period. This avoids duplicate allocation and creation operations caused by lock waiting time differences, further improving the accuracy and efficiency of the allocation process. Simultaneously, the probability of concurrency conflicts can be reduced based on the service instance's own local lock, eliminating the need for additional components such as distributed locks and independent resource scheduling services. This results in low modification costs and effectively reduces deployment and maintenance complexity.

[0035] As described in the previous embodiment, this application can, after acquiring the local lock, query again whether a target client corresponding to the diskless client allocation request exists. If not, the target client is created in the diskless system. Next, this embodiment will describe the target client creation process in detail. See [link to documentation]. Figure 3 As shown in the figure, this application discloses a method for creating a diskless client machine, including: Step S21: Determine the candidate addresses in the virtual private cloud, and determine the target address among the candidate addresses that corresponds to the diskless client allocation request.

[0036] In this embodiment, after acquiring the local lock, it queries again whether a target client corresponding to the diskless client allocation request exists. If not, it determines candidate addresses in the virtual private cloud and identifies the target address corresponding to the diskless client allocation request from among the candidate addresses. Specifically, it queries the currently occupied addresses within the virtual private cloud in real time, determines the address range of the virtual private cloud based on the subnet mask of the virtual private cloud, removes the gateway address and occupied address from the above address range to obtain the candidate addresses of the virtual private cloud, determines the address value of each address in the candidate addresses, and identifies the address with the smallest address value in the candidate addresses as the target address.

[0037] It should be noted that in this embodiment, when determining candidate addresses, the occupied addresses within the Virtual Private Cloud (VPN) can be queried in real time. The address range of the VPN is determined based on its subnet mask, and then gateway addresses and occupied addresses are removed from this range to obtain candidate addresses for the VPN, which is the set of available IPs updated in real time within the current VPN. Furthermore, the address values ​​of each candidate address can be determined, and the address with the smallest address value is selected as the target address in ascending order. This means selecting the smallest available IP as the target IP used for creating the client in this round, ensuring a consistent address selection order across multiple diskless client allocation requests. This facilitates the identification and handling of address conflicts in multi-instance concurrent scenarios. It should also be pointed out that if the queried candidate address is empty, meaning there are no available IPs within the current VPN, the address allocation failure result is returned directly.

[0038] Step S22: Create a client machine in the diskless system based on the target address, and query the actual address of the currently created client machine according to the source identifier. When the actual address matches the target address, determine the currently created client machine as the target client machine.

[0039] In this embodiment, a client machine needs to be created in the diskless system. The actual address of the currently created client machine is queried based on the source identifier. If the actual address matches the target address, the currently created client machine is identified as the target client machine. It should be noted that after initiating a client machine creation request to the diskless system based on the target address, this embodiment does not directly use the synchronous return result of the creation interface as the final success criterion. Instead, it again checks the actual status of the client machine in the diskless system based on the source identifier (i.e., sourceId) and verifies whether the actual address obtained from the check matches the target address in this round. Therefore, the judgment flag for successful client machine creation is changed from "request sent" to "creation completed and address matches." Furthermore, the creation process is only considered successful and the currently created client machine is identified as the target client machine when the actual address matches the target address.

[0040] Furthermore, during the process of querying the actual address of the currently created client based on the source identifier, if the actual address of the currently created client is not found based on the source identifier, the query is repeated based on the source identifier at an incrementing backoff time interval until the actual address of the currently created client is found, or the number of queries reaches a preset threshold. It is understandable that, due to the asynchronous visibility delay in creating diskless clients, a successful creation interface return does not necessarily mean that the platform can immediately query the client. If the synchronous return value is used as the final criterion, it is easy to misjudge success or failure. Therefore, if... Figure 4 As shown, when the actual address of the currently created client cannot be found based on the source identifier, the preset allocation platform does not immediately determine failure. Instead, it re-queries the actual address of the currently created client based on the source identifier at an incrementing backoff time interval, repeating the above query operation until the actual address of the currently created client is found, or the number of queries reaches a preset threshold. In this way, through the backoff and query mechanism, the scenarios of the client not yet being visible on the diskless side and the client creation actually failing can be effectively distinguished, significantly reducing the probability of false failure due to asynchronous latency.

[0041] In other words, during the backtracking process, if the actual address of the currently created client is not found based on the source identifier, the creation is not immediately determined to have failed. Instead, based on an increasing backtracking time interval, for example, a limited number of backtracking attempts are made until the actual address is found or the number of attempts reaches a preset threshold. This achieves compatibility with asynchronous data storage or delayed visibility scenarios in diskless systems, distinguishes between "not yet visible" and "truly failed" scenarios, and reduces misjudgments.

[0042] Furthermore, a preset query condition is established: either the actual address of the currently created client is found based on the source identifier, and the actual address does not match the target address, or the actual address of the currently created client is not found even after a preset query count threshold. Then, if the preset query condition is met, a new query is performed on candidate addresses in the virtual private cloud. A new target address, different from the target address, is determined from the queried candidate addresses. The client is then recreated based on the new target address, and the process returns to the step of querying the actual address of the currently created client based on the source identifier, until the actual address of the recreated client matches the corresponding target address.

[0043] In other words, during the lookup process, when the actual address of the currently created client is found based on the source identifier, but the actual address is inconsistent with the target address of this round, it can be determined that there is a multi-instance contention conflict. Since continuing to wait cannot change the fact that the target address has already been preempted by another instance, this embodiment directly abandons the current target address, re-queries for candidate addresses in the virtual private cloud, determines a new target address different from the target address from the queried candidate addresses, and recreates the client based on the new target address before jumping to the lookup verification step, until the actual address of the recreated client is consistent with the corresponding target address. This prevents concurrent conflicts from being directly exposed as business failures, but transforms them into a self-recoverable control process within the platform. In this way, through the above-mentioned post-creation lookup verification, asynchronous visibility delay compatibility, and reassignment retry after IP conflict, best-effort consistency control for diskless client address allocation in multi-instance scenarios can be achieved without introducing distributed locks and independent address placeholder tables. When the number of retry rounds exceeds the preset retry limit or there are no available IPs, an allocation failure result is returned. See also Figure 5 As shown, when the actual IP is found to be inconsistent with the expected IP during the retrospective check, it is determined that there is a multi-instance contention conflict. A new target address different from the current target address can be determined, and the client is recreated and verified based on the new target address until the actual address of the recreated client is consistent with the corresponding target address. In this way, the self-healing capability in multi-instance concurrent scenarios is improved through the explicit conflict identification and reallocation retry mechanism for IP inconsistency.

[0044] Based on the above technical solutions, such as Figure 6 As shown, this embodiment addresses multiple service entry points such as bare metal boot, hardware detection, and BIOS flashing. It unifies the allocation requirements for diskless clients from each entry point into a single allocation method within a pre-defined allocation platform. Using the source ID as an idempotent anchor, it combines local lock concurrency suppression, post-creation backcheck verification, and reassignment retries after conflicts to form a complete best-effort consistency control. This embodiment solves the problems of duplicate address preemption and distorted creation results for diskless clients in multi-entry, multi-instance scenarios. Using sourceId as an idempotent anchor, combined with local concurrency suppression at the regionId:vpcId granularity, post-creation backcheck verification, asynchronous visibility latency compatibility, and reassignment retries after IP conflicts, it forms a closed-loop consistency control system. This reduces the probability of duplicate IP preemption for diskless clients without introducing distributed locks or independent address placeholder tables, thereby reducing the risk of service failures due to conflicts and improving the success rate of diskless client address allocation.

[0045] See Figure 7As shown in the embodiments, this application also discloses a diskless client allocation device, applied to a preset allocation platform, comprising: The request receiving module 11 is used to receive diskless client allocation requests; the diskless client allocation request includes a source identifier, a data center identifier, and a virtual private cloud identifier; the source identifier is the unique idempotent anchor point of the diskless client allocation request, used to uniquely identify the service source corresponding to the diskless client allocation request. The client query module 12 is used to query whether there is a target client corresponding to the diskless client allocation request based on the source identifier. If there is no target client corresponding to the diskless client allocation request, it acquires the corresponding local lock based on the data center identifier and the virtual private cloud identifier, and queries again based on the source identifier whether there is a target client corresponding to the diskless client allocation request to obtain the query result. The local lock is used to serially process the client allocation operations of multiple diskless client allocation requests received by the same instance of the preset allocation platform within the same virtual private cloud. The client allocation module 13 is used to determine the target client in the diskless system based on the query result, and to execute the client allocation operation corresponding to the diskless client allocation request, so as to complete the client allocation of the diskless client allocation request.

[0046] This embodiment uses local locks with a combined granularity of data center identifier and virtual private cloud identifier for concurrency control. This constrains client allocation operations within the same data center and virtual private cloud, effectively reducing the probability of conflicts such as multiple requests preempting and duplicate creation within a single instance and the same virtual private cloud. It also avoids the overall performance degradation caused by global locks, improving system efficiency while enhancing concurrency control. After acquiring the local lock, it checks the client's existence again based on the source identifier, identifying clients created by other threads during lock waiting, avoiding duplicate allocation and creation operations due to lock waiting time differences, further improving the accuracy and efficiency of the allocation process. Furthermore, it can reduce the probability of concurrency conflicts based on the service instance's own local lock, eliminating the need for additional components such as distributed locks and independent resource scheduling services, resulting in low modification costs.

[0047] In some specific embodiments, the diskless client allocation device further includes: The client determination module is used to directly determine the queried client as the target client when a client corresponding to the diskless client allocation request is found based on the source identifier.

[0048] In some specific embodiments, the client allocation module 13 specifically includes: The first client determination submodule is used to determine the queried client as the target client when the query result indicates that there is a client in the diskless system corresponding to the diskless client allocation request; The first address determination submodule is used to determine candidate addresses in the virtual private cloud when the query result indicates that there is no client corresponding to the diskless client allocation request, and to determine the target address among the candidate addresses that corresponds to the diskless client allocation request; The first address query submodule is used to create a client in the diskless system based on the target address, and query the actual address of the currently created client according to the source identifier; The second client determination submodule is used to determine the currently created client as the target client when the actual address matches the target address.

[0049] In some specific embodiments, the first address determination submodule specifically includes: The address query unit is used to query the occupied addresses within the virtual private cloud and determine the address range of the virtual private cloud based on the subnet mask of the virtual private cloud. The address filtering unit is used to remove the gateway address and the occupied address from the address range to obtain the candidate address of the virtual private cloud; The address determination unit is used to determine the address value of each address in the candidate addresses, and to determine the address with the smallest address value in the candidate addresses as the target address.

[0050] In some specific embodiments, the client allocation module 13 further includes: The second address query submodule is used to query the actual address of the currently created client again based on the source identifier when the actual address of the currently created client is not found according to the source identifier, based on an increasing backoff time interval, until the actual address of the currently created client is found, or the number of queries reaches a preset number threshold.

[0051] In some specific embodiments, the client allocation module 13 further includes: The second address determination submodule is used to re-query the candidate addresses in the virtual private cloud when the preset query conditions are met, and determine a new target address that is different from the target address from the queried candidate addresses. Based on the new target address, the client is recreated, and the process jumps to the step of querying the actual address of the currently created client according to the source identifier until the actual address of the recreated client is consistent with the corresponding target address. The preset query conditions are: the actual address of the currently created client is found based on the source identifier, and the actual address is inconsistent with the target address; or, the actual address of the currently created client is not found even when the number of queries reaches the preset number threshold.

[0052] In some specific embodiments, the client query module 12 specifically includes: A lock identifier generation unit is used to generate a lock identifier based on the data center identifier and the virtual private cloud identifier; A local lock determination unit is used to determine the corresponding local lock based on the lock identifier, so as to process a number of first allocation requests serially and a number of second allocation requests in parallel within the same virtual private cloud based on the local lock. The local lock is a mutex lock within a single instance process of the preset allocation platform. The first allocation request is an allocation request for the diskless client carrying the same data center identifier and the same virtual private cloud identifier. The second allocation request is an allocation request for the diskless client carrying different data center identifiers and / or different virtual private cloud identifiers.

[0053] Furthermore, embodiments of this application also disclose an electronic device, Figure 8 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0054] Figure 8 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the diskless client allocation method disclosed in any of the foregoing embodiments. Furthermore, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0055] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0056] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0057] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the diskless client allocation method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include a computer program capable of performing other specific tasks.

[0058] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned diskless client allocation method. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0059] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0060] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0061] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0062] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0063] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A diskless client allocation method, characterized in that, Applied to the preset allocation platform, including: Receive diskless client allocation request; the diskless client allocation request includes source identifier, data center identifier and virtual private cloud identifier; the source identifier is the unique idempotent anchor point of the diskless client allocation request, used to uniquely identify the service source corresponding to the diskless client allocation request; The system queries whether a target client corresponding to the diskless client allocation request exists based on the source identifier. If no target client corresponding to the diskless client allocation request exists, the system acquires a local lock based on the data center identifier and the virtual private cloud identifier, and queries again based on the source identifier to determine whether a target client corresponding to the diskless client allocation request exists, thus obtaining the query result. The local lock is used to serially process client allocation operations for multiple diskless client allocation requests received by the same instance of the preset allocation platform within the same virtual private cloud. Based on the query results, the target client in the diskless system is determined, and the client allocation operation corresponding to the diskless client allocation request is executed to complete the client allocation of the diskless client allocation request.

2. The diskless client allocation method according to claim 1, characterized in that, After querying whether a target client corresponding to the diskless client allocation request exists based on the source identifier, the method further includes: When a client corresponding to the diskless client allocation request is found based on the source identifier, the found client is directly identified as the target client.

3. The diskless client allocation method according to claim 1, characterized in that, The step of determining the target client in the diskless system based on the query results includes: When the query result indicates that there is a client in the diskless system corresponding to the diskless client allocation request, the queried client is determined as the target client; Accordingly, when the query result indicates that there is no client corresponding to the diskless client allocation request, candidate addresses in the virtual private cloud are determined, and the target address corresponding to the diskless client allocation request is determined from among the candidate addresses. A client is created in the diskless system based on the target address, and the actual address of the currently created client is queried based on the source identifier; When the actual address matches the target address, the currently created client is identified as the target client.

4. The diskless client allocation method according to claim 3, characterized in that, Determining the target address from the candidate addresses that corresponds to the diskless client allocation request includes: Query the occupied addresses within the virtual private cloud, and determine the address range of the virtual private cloud based on the subnet mask of the virtual private cloud; Remove the gateway address and the occupied address from the address range to obtain the candidate address of the virtual private cloud; The address value of each address in the candidate addresses is determined, and the address with the smallest address value in the candidate addresses is determined as the target address.

5. The diskless client allocation method according to claim 3, characterized in that, The process of querying the actual address of the currently created client based on the source identifier also includes: If the actual address of the currently created client is not found based on the source identifier, the actual address of the currently created client is queried again based on the source identifier according to the incremental backoff time interval, until the actual address of the currently created client is found, or the number of queries reaches a preset number threshold.

6. The diskless client allocation method according to claim 5, characterized in that, The process of querying the actual address of the currently created client based on the source identifier also includes: When the preset query conditions are met, the candidate addresses in the virtual private cloud are queried again, and a new target address different from the target address is determined from the queried candidate addresses. The client is recreated based on the new target address, and the process jumps to the step of querying the actual address of the currently created client according to the source identifier, until the actual address of the recreated client is consistent with the corresponding target address. The preset query conditions are: the actual address of the currently created client is found based on the source identifier, and the actual address is inconsistent with the target address; or, the actual address of the currently created client is not found even when the number of queries reaches the preset number threshold.

7. The diskless client allocation method according to any one of claims 1 to 6, characterized in that, The step of obtaining the corresponding local lock based on the data center identifier and the virtual private cloud identifier includes: A lock identifier is generated based on the data center identifier and the virtual private cloud identifier; The corresponding local lock is determined based on the lock identifier, so that several first allocation requests can be processed serially and several second allocation requests can be processed in parallel within the same virtual private cloud based on the local lock. The local lock is a mutex lock within a single instance process of the preset allocation platform. The first allocation request is an allocation request for the diskless client carrying the same data center identifier and the same virtual private cloud identifier. The second allocation request is an allocation request for the diskless client carrying different data center identifiers and / or different virtual private cloud identifiers.

8. A diskless client machine allocation device, characterized in that, Applied to the preset allocation platform, including: The request receiving module is used to receive diskless client allocation requests; the diskless client allocation request includes a source identifier, a data center identifier, and a virtual private cloud identifier; the source identifier is the unique idempotent anchor point of the diskless client allocation request, used to uniquely identify the service source corresponding to the diskless client allocation request; The client query module is used to query whether there is a target client corresponding to the diskless client allocation request based on the source identifier. If there is no target client corresponding to the diskless client allocation request, it acquires the corresponding local lock based on the data center identifier and the virtual private cloud identifier, and queries again based on the source identifier to determine whether there is a target client corresponding to the diskless client allocation request, thus obtaining the query result. The local lock is used to serially process the client allocation operations of multiple diskless client allocation requests received by the same instance of the preset allocation platform within the same virtual private cloud. The client allocation module is used to determine the target client in the diskless system based on the query result, and execute the client allocation operation corresponding to the diskless client allocation request to complete the client allocation of the diskless client allocation request.

9. An electronic device, characterized in that, The electronic device includes a processor and a memory; wherein the memory is used to store a computer program, which is loaded and executed by the processor to implement the diskless client allocation method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store computer programs, which, when executed by a processor, implement the diskless client allocation method as described in any one of claims 1 to 7.

Images