A resource management method, device, equipment and readable storage medium

Abstract

The application discloses a resource management method, device and equipment and a readable storage medium, and belongs to the technical field of cloud computing. The method comprises the following steps: in response to a switching request, acquiring an unfinished computing power order and a physical resource identifier thereof in a first computing power scheduling platform; after locking the resource in a second computing power scheduling platform, appending and writing a locking record in a first lock file; periodically querying an order state, and when the order ends, traversing reversely from the end of the first lock file, if there is an update locking record with the same resource identifier and later writing, only deleting the current record and maintaining the locking, otherwise, releasing the resource and deleting the record. Through the order state driven resource mutual exclusion pre-occupation and the same resource relay unlocking, the application avoids the repeated allocation of resources during platform switching, solves the locking coverage problem under continuous switching, and realizes the automatic closed-loop management of the whole life cycle of resource locking.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a resource management method, apparatus, device, and readable storage medium. Background Technology

[0002] During the upgrade or replacement of cloud computing power scheduling platforms, the coexistence of different versions of scheduling systems (computing power scheduling platforms) is a common transitional phase, where the same physical resource is visible and operable by two scheduling systems simultaneously. For example, during a scheduling version switch, after the scheduling is switched to the target platform, the other platform may still have unfinished computing power orders occupying some physical nodes. If the target platform immediately initiates new computing power requests for these nodes, the same physical node may be allocated to different tenants by both systems simultaneously, leading to resource overselling and business conflicts.

[0003] Currently, resources are typically locked manually after the order status is checked, which is time-consuming and prone to omissions. In addition, resource locking is disconnected from the order lifecycle. The end time of an order is dynamic. If a one-time static lock is used, resources may remain locked even after the order has ended, resulting in resource waste. If the lock is released too early, the resources corresponding to orders that are still in progress may be reallocated.

[0004] In summary, how to effectively manage resources during the switching process of computing power scheduling platforms is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] The purpose of this application is to provide a resource management method, apparatus, device, and readable storage medium to effectively manage resources during the switching process of computing power scheduling platforms, and to avoid conflicts in which the same physical resource is simultaneously visible and operable by two computing power scheduling platforms.

[0006] To solve the above-mentioned technical problems, this application provides the following technical solution: A resource management method, comprising: In response to the switching request, obtain the unfinished computing power orders and their physical resource identifiers in the first computing power scheduling platform; Within the second computing power scheduling platform, after locking the computing power resources identified by the physical resource identifier, a lock record is appended to the first lock file. Periodically read the lock records of the first lock file and query the order status of the computing power orders corresponding to the lock records; If the order status is closed, then traverse backwards from the end of the first lock file to determine if there is an update lock record with the same resource identifier that was written later than the lock record. If it exists, delete the lock record in the first lock file and maintain the second computing power scheduling platform's lock on the computing power resource; otherwise, release the second computing power scheduling platform's lock on the computing power resource and delete the lock record in the first lock file.

[0007] Preferably, the correspondence between the order identifier of the computing power order and the physical resource identifier is appended to the first lock file, including: Construct key-value pairs using the order identifier and the physical resource identifier; The key-value pairs are appended one by one to the first lock file.

[0008] Preferably, it further includes: When the second computing power scheduling platform malfunctions, a switchback request is received to switch the scheduling from the second computing power scheduling platform back to the first computing power scheduling platform. Query the computing power orders that are in an unfinished state and their physical resource identifiers in the second computing power scheduling platform; Within the first computing power scheduling platform, after locking the computing power resource identified by the physical resource identifier, a lock record is appended to the second lock file.

[0009] Preferably, the first lock file and the second lock file are managed independently by their respective periodic tasks.

[0010] Preferably, the locking records of the first lock file are periodically read, and the order status of the computing power order corresponding to the locking record is queried, including: Read all locked records in the first lock file at preset intervals, and query the order status of the corresponding computing power order from the first computing power scheduling platform for each record; If the first lock file reading fails or the computing power order status query fails, the current locked record is skipped and the next record is processed.

[0011] Preferably, the first computing power scheduling platform is a host scheduling platform or a bare metal orchestration platform; the lock file of the host scheduling platform is a host lock file; and the lock file of the bare metal orchestration platform is a bare metal lock file.

[0012] Preferably, the process involves traversing backwards from the end of the first lock file to determine if there exists an update lock record with the same resource identifier that was written later than the lock record, including: Search backwards from the end to the beginning of the first lock file to filter out all lock records that have the same physical resource identifier as the current lock record; If a lock record for the same resource is found after the current lock record, it is determined that the updated lock record exists.

[0013] A resource management device, comprising: The request and response module is used to respond to switching requests and obtain unfinished computing power orders and their physical resource identifiers in the first computing power scheduling platform; The resource locking module is used to lock the computing resources identified by the physical resource identifier in the second computing power scheduling platform and then append a locking record to the first lock file. The periodic query module is used to periodically read the lock records of the first lock file and query the order status of the computing power orders corresponding to the lock records; The resource unlocking module is used to, if the order status is closed, traverse backwards from the end of the first lock file to determine if there is an updated lock record with the same resource identifier that was written later than the lock record; if there is, delete the lock record in the first lock file and maintain the second computing power scheduling platform's lock on the computing power resource; otherwise, release the second computing power scheduling platform's lock on the computing power resource and delete the lock record in the first lock file.

[0014] An electronic device, comprising: Memory, used to store computer programs; A processor is used to implement the steps of the resource management method described above when executing the computer program.

[0015] A readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the resource management method described above.

[0016] The method provided in this application includes: in response to a switching request, obtaining unfinished computing power orders and their physical resource identifiers in a first computing power scheduling platform; in a second computing power scheduling platform, locking the computing power resources with the physical resource identifiers and appending a locking record to a first lock file; periodically reading the locking records in the first lock file and querying the order status of the computing power orders corresponding to the locking records; if the order status is finished, traversing backwards from the end of the first lock file to determine if there is an updated locking record with the same resource identifier that was written later than the locking record; if so, deleting the locking record in the first lock file and maintaining the second computing power scheduling platform's locking of the computing power resources; otherwise, releasing the second computing power scheduling platform's locking of the computing power resources and deleting the locking record in the first lock file.

[0017] During the corresponding switchover request process, the system first retrieves unfinished computing power orders and their physical resource identifiers from the first computing power scheduling platform. Then, it performs a locking operation on the resource in the second computing power scheduling platform and writes the locking record to the first lock file. Based on the computing power orders from the first computing power scheduling platform, the corresponding resources are locked in the second computing power scheduling platform. This ensures that the same physical resource is pre-marked as unallocable in the second computing power scheduling platform, avoiding the problem of the same physical resource being repeatedly allocated by the two computing power scheduling platforms during the switchover. By periodically reading the locking records in the first lock file and querying the order status from the first computing power scheduling platform, the system only initiates the unlocking process when the order ends. This achieves dynamic binding between the lock lifecycle and the order execution progress, avoiding the problems of premature resource release or long-term idleness caused by static locking. By performing a resource relay check by traversing backwards from the end of the first lock file, if a subsequent lock record (i.e., an updated lock record) exists, only the current record is cleared without releasing the resource. Only when the subsequent lock record does not exist is the resource actually unlocked on the second computing power scheduling platform. This achieves resource-level relay protection where the subsequent lock takes over the preceding lock in a continuous switching scenario, avoiding the situation where the resource is incorrectly released due to the end of the preceding order but is still locked by the resources required by the subsequent order.

[0018] Therefore, this application can manage resources in an orderly, dynamic and reliable manner when switching computing power scheduling platforms.

[0019] Accordingly, embodiments of this application also provide resource management devices, equipment, and readable storage media corresponding to the above-described resource management methods, which have the aforementioned technical effects, and will not be elaborated further here. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart illustrating the implementation of a resource management method in an embodiment of this application. Figure 2 This is a schematic diagram of the structure of a resource management device according to an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application; Figure 4 This is a schematic diagram of the specific structure of an electronic device in an embodiment of this application. Detailed Implementation

[0022] 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. Obviously, the described embodiments are merely some embodiments of the present application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] Please refer to Figure 1 , Figure 1 This is a flowchart of a resource management method according to an embodiment of this application, which includes the following steps.

[0024] S101. In response to the switching request, obtain the unfinished computing power orders and their physical resource identifiers in the first computing power scheduling platform.

[0025] In this embodiment, both the first and second computing power scheduling platforms are computing power scheduling platforms that manage physical computing nodes. They can be different computing power scheduling platforms or different versions of the same computing power scheduling platform. The first computing power scheduling platform can be a host scheduling platform, and the second computing power scheduling platform can be a bare metal orchestration platform; alternatively, the first computing power scheduling platform can be a bare metal orchestration platform, and the second computing power scheduling platform can be a host scheduling platform. The host scheduling platform is a platform that manages physical computing nodes through a traditional host scheduling system, and the bare metal orchestration platform is a platform that manages physical computing nodes through a bare metal orchestration system.

[0026] After receiving a switch request to switch scheduling from the first computing power scheduling platform to the second computing power scheduling platform, the system queries the first computing power scheduling platform for computing power orders that are currently in an unfinished state and extracts the physical resource identifier associated with each computing power order. Here, "unfinished state" refers to a computing power order that has not yet been completed and is still occupying physical resources. If there are multiple unfinished computing power orders in the first computing power scheduling platform, each order and its associated physical resource identifier are extracted one by one.

[0027] In practical applications, to avoid two computing power scheduling platforms simultaneously receiving scheduling requests, the system can switch to the second computing power scheduling platform only after the first platform stops receiving scheduling requests but continues processing existing orders (service shutdown). Specifically, upon receiving a scheduling version switch request, the system first queries the currently active scheduling version. If the current version is not in a service shutdown state (version number not 0), the direct switch request from a non-service shutdown state is rejected. This verification forces all scheduling version switches to first pass through a service shutdown intermediate state, thus preventing order routing errors caused by direct switching between the old and new platforms in an active state. The management page only exposes three options: service shutdown, old platform, and new platform. Users must select service shutdown before selecting the target platform version, ensuring the rigor of the control logic from an operational flow perspective.

[0028] S102. In the second computing power scheduling platform, after locking the computing power resources identified by the physical resource identifier, a lock record is appended to the first lock file.

[0029] On the second computing power scheduling platform side, the system marks the resource corresponding to the physical resource identifier as locked. When the second computing power scheduling platform is a host scheduling platform, the resource status field of the corresponding host is updated to occupied, causing the scheduler of the host scheduling platform to skip locked hosts when allocating hosts. When the second computing power scheduling platform is a bare metal orchestration platform, the reserved status field of the corresponding bare metal resource is updated to reserved, causing the scheduler of the bare metal orchestration platform to skip reserved resources when allocating bare metal.

[0030] Then, a lock record is appended to the first lock file. In this embodiment, the first lock file and the second lock file correspond to the lock files of the computing power scheduling platform, respectively. The lock file is automatically created upon first access, ensuring that the locking process is not interrupted after a new deployment or accidental deletion of the lock file. The reading, deduplication, and write-back operations of the lock file are all performed under the protection of the synchronization method, ensuring the safety of concurrent writes.

[0031] Appending to a file means that after opening the file, neither the original content is deleted nor overwritten; the new record is written directly to the end of the file, while the old records are completely preserved at the beginning. In this way, based on the order of the locked records in the lock file, the chronological relationship of different locked records can be determined without relying on timestamps.

[0032] In one specific embodiment of this application, the correspondence between the order identifier and the physical resource identifier of a computing power order is appended to the first lock file, including: constructing key-value pairs using the order identifier and the physical resource identifier; and appending the key-value pairs one by one to the first lock file. The key-value pair format is: order identifier = physical resource identifier. The same physical resource identifier can correspond to multiple lock records from different time-switching operations, and the first lock file retains a complete historical lock chain. The first lock file is automatically created upon first access, ensuring that the locking process is not interrupted after a new deployment or accidental deletion of the lock file. Reading, record removal, and write-back operations of the first lock file are all performed under the protection of a synchronization method, ensuring safe concurrent writes.

[0033] S103. Periodically read the lock records of the first lock file and query the order status of the computing power order corresponding to the lock record.

[0034] The system deploys a periodic task that reads all locked records in the first lock file at preset intervals and queries the first computing power scheduling platform for the order status of the corresponding computing power order for each record. In this embodiment, the periodic task can be configured to execute once per minute. Of course, in practical applications, it can also be set to other time periods, which can be determined according to the statistical values ​​of the execution duration of the actual computing power orders (such as mean, mode, median, or minimum value).

[0035] After the periodic task reads the locked record, it parses the order identifier and queries the first computing power scheduling platform for the current usage status of the computing power order corresponding to that order identifier. The unlocking process only begins when the computing power order status is "end"; otherwise, the lock remains and the process waits for the next cycle.

[0036] In one specific embodiment of this application, the locking records of the first lock file are periodically read, and the order status of the corresponding computing power orders is queried. This includes: periodically reading all locking records in the first lock file at a preset period, and querying the order status of the corresponding computing power orders from the first computing power scheduling platform for each record; if the first lock file reading is abnormal or the computing power order status query is abnormal, the current locking record is skipped and the next record is processed. Specifically, when skipping the current record in an abnormal situation, no resource status changes are performed on the second computing power scheduling platform side to avoid incorrect unlocking due to abnormalities and to ensure the security of the locking status.

[0037] In one specific embodiment of this application, the first computing power scheduling platform is a host scheduling platform or a bare metal orchestration platform; the lock file of the host scheduling platform is a host lock file; and the lock file of the bare metal orchestration platform is a bare metal lock file. The host lock file and the bare metal lock file each correspond to their respective periodic tasks, which are deployed independently and executed independently according to their respective configured periods, without interfering with each other.

[0038] S104. If the order status is "completed", then traverse backwards from the end of the first lock file to determine if there is an update lock record with the same resource identifier that was written later than the lock record.

[0039] When the current status of a computing power order is found to be "completed", the system does not immediately release the resources, but instead performs a relay check on the same resources.

[0040] As mentioned earlier, lock records are written in an append-only manner. Therefore, the order of lock records in the first lock file indicates the order in which they were locked. Thus, we can directly traverse backwards from the end of the first lock file to find update lock records that are written later than the lock records for the same resource identifier. We may or may not find them.

[0041] In one specific embodiment of this application, the process of traversing backwards from the end of the first lock file to determine whether there is an updated lock record with the same resource identifier that was written later than the current lock record includes: searching backwards from the end of the first lock file to the beginning, filtering out all lock records with the same physical resource identifier as the current lock record; if a lock record with the same resource identifier is found after the current lock record, it is determined that an updated lock record exists. Traversing backwards from the end of the lock file prioritizes checking the most recently written records, improving the efficiency of relay checks. Multiple records with the same resource identifier may exist in the lock file, and these records originate from switch operations at different times.

[0042] S105. If it exists, delete the lock record in the first lock file and maintain the lock on the computing resources by the second computing power scheduling platform; otherwise, release the lock on the computing resources by the second computing power scheduling platform and delete the lock record in the first lock file.

[0043] If, after a resource relay check, it is determined that there is an updated lock record, it means that the lock responsibility for the resource has been taken over by the lock record generated by the subsequent switch operation. The current record is only cleared from the first lock file, and no actual resource unlocking is performed. The lock status of the computing resource on the second computing power scheduling platform remains unchanged.

[0044] If, after a resource relay check, it is determined that there are no updated lock records, it means that the resource no longer has any subsequent lock records to take over the protection responsibility in the first lock file. In this case, the actual resource release is performed: the resource is restored to an available state on the second computing power scheduling platform side, and the current lock record is removed from the first lock file.

[0045] When the second computing power scheduling platform is a host scheduling platform, the actual resource release involves restoring the resource status field of the corresponding host to an available state. When the second computing power scheduling platform is a bare metal orchestration platform, the actual resource release involves restoring the reserved status field of the corresponding bare metal resource to an unreserved state.

[0046] In one specific embodiment of this application, the method further includes: when the second computing power scheduling platform malfunctions, receiving a switchback request to switch the scheduling from the second computing power scheduling platform back to the first computing power scheduling platform; querying the computing power orders and their physical resource identifiers that are not yet completed in the second computing power scheduling platform; and, within the first computing power scheduling platform, locking the computing power resources associated with the physical resource identifiers and appending a lock record to the second lock file. The first lock file and the second lock file are managed independently by their respective periodic tasks. The two periodic tasks execute independently according to their respective configured periods, without interfering with each other.

[0047] In one specific embodiment of this application, in a continuous switching scenario, the same physical resource identifier exists simultaneously in both the first lock file and the second lock file, each managed independently by its respective periodic task. From the perspective of the scheduler of the first computing power scheduling platform, the resource is in a locked state and will not be allocated; from the perspective of the scheduler of the second computing power scheduling platform, the resource is also in a locked state and will not be allocated. The same physical node is in an unallocable state in the schedulers of both platforms.

[0048] The method provided in this application includes: in response to a switching request, obtaining unfinished computing power orders and their physical resource identifiers in a first computing power scheduling platform; in a second computing power scheduling platform, locking the computing power resources with the physical resource identifiers and appending a locking record to a first lock file; periodically reading the locking records in the first lock file and querying the order status of the computing power orders corresponding to the locking records; if the order status is finished, traversing backwards from the end of the first lock file to determine if there is an updated locking record with the same resource identifier that was written later than the locking record; if so, deleting the locking record in the first lock file and maintaining the second computing power scheduling platform's locking of the computing power resources; otherwise, releasing the second computing power scheduling platform's locking of the computing power resources and deleting the locking record in the first lock file.

[0049] During the corresponding switchover request process, the system first retrieves unfinished computing power orders and their physical resource identifiers from the first computing power scheduling platform. Then, it performs a locking operation on the resource in the second computing power scheduling platform and writes the locking record to the first lock file. Based on the computing power orders from the first computing power scheduling platform, the corresponding resources are locked in the second computing power scheduling platform. This ensures that the same physical resource is pre-marked as unallocable in the second computing power scheduling platform, avoiding the problem of the same physical resource being repeatedly allocated by the two computing power scheduling platforms during the switchover. By periodically reading the locking records in the first lock file and querying the order status from the first computing power scheduling platform, the system only initiates the unlocking process when the order ends. This achieves dynamic binding between the lock lifecycle and the order execution progress, avoiding the problems of premature resource release or long-term idleness caused by static locking. By performing a resource relay check by traversing backwards from the end of the first lock file, if a subsequent lock record (i.e., an updated lock record) exists, only the current record is cleared without releasing the resource. Only when the subsequent lock record does not exist is the resource actually unlocked on the second computing power scheduling platform. This achieves resource-level relay protection where the subsequent lock takes over the preceding lock in a continuous switching scenario, avoiding the situation where the resource is incorrectly released due to the end of the preceding order but is still locked by the resources required by the subsequent order.

[0050] Therefore, this application can manage resources in an orderly, dynamic and reliable manner when switching computing power scheduling platforms.

[0051] To help those skilled in the art better understand and implement the resource management method provided in the embodiments of this application, the resource management method will be illustrated below with specific examples.

[0052] During the upgrade or replacement of cloud computing platforms, the coexistence of two scheduling systems is a common transitional phase. The new platform manages physical resources through a bare-metal orchestration system, while the old platform manages the same batch of physical computing nodes through a traditional host scheduling system. Switching scheduling versions—that is, the console switching the internet cafe's scheduling routes from the new platform to the old platform, or vice versa—is the core operation during the migration transition period.

[0053] However, during the transition between the old and new platforms, the same physical resource is visible and operable by two scheduling systems simultaneously, which presents the following technical problems: The issue of redundant allocation of physical resources before and after the switchover arises because after the scheduling version switches to the target platform, some physical nodes are still occupied by unfinished computing power orders on the other platform. If the target platform immediately initiates new computing power requests for these physical nodes after the switchover, the same physical node may be allocated to different tenants by both systems simultaneously, leading to resource overselling and tenant business conflicts. Existing solutions typically rely on manual verification of order status and manual locking of resources, which is time-consuming and prone to omissions.

[0054] The disconnect between resource locking and order lifecycle is a significant issue. Even if resources can be locked once during switchover, the order's end time is dynamic—it might end in minutes or continue for hours. If the locking is static (one-time lock), resources might remain locked even after the order has ended and the resources have been released, resulting in wasted resources. If the lock is released too early, resources still in the order process might be reallocated by the new scheduling system. Existing solutions lack a means to dynamically control the resource locking lifecycle based on order status.

[0055] Continuous switching and resource lock overwriting issues can arise in actual operations and maintenance, potentially leading to scenarios where switching to a new platform → migration failure and switching back to the old platform → repair and then switching back to the new platform. Each switch generates a new batch of lock records, which may apply to the same physical resource. Simply overwriting previous locks in chronological order could result in the incorrect clearing of locks for orders that are not yet completed. Existing solutions lack hierarchical management and security overwriting mechanisms for multiple lock records on the same resource.

[0056] The persistence and disaster recovery of resource lock states are crucial. Switching operations occur within a single interface call to a regional service, but locking and unlocking operations can span hours or even days. If only a memory cache is used to store the lock state, all locking information will be lost after a service restart, potentially leading to the accidental release of locked resources or the inability to unlock completed resources. Existing solutions lack a disaster recovery mechanism that persists the lock state to the file system and integrates it with periodic tasks for continuous flow.

[0057] To address the aforementioned issues, this application proposes a resource management method: an order-state-driven resource mutual exclusion pre-allocation and continuous unlocking method for scheduling and switching between new and old platforms. This method involves: blocking direct switching by verifying the version before switching; pre-allocating resources on the target side by querying unfinished orders on the other side; persisting the lock relationship in files and continuously unlocking based on order status in periodic tasks; and ensuring that subsequent locks are not disrupted by previous unlocks in continuous switching scenarios through resource relay checks.

[0058] As can be seen from the above method embodiments, in this application, version status verification before switching and direct mutual switching blocking are implemented. After receiving a scheduling version switching request, the system first queries the currently effective scheduling version. If the current version is not in a service-stopped state (version number not 0), the direct switching request in a non-service-stopped state is rejected. This verification forces all scheduling version switching to first go through a service-stopped intermediate state, thereby avoiding order routing errors caused by direct mutual switching between the new and old platform scheduling routes in an active state. The management page only exposes three options: service-stopped, old platform, and new platform. When selecting a target version, the user must first select service-stopped and then select the target platform version, ensuring the rigor of the control logic from the operational process perspective.

[0059] In this application, the scanning of unfinished orders on the other side and the mutual exclusion pre-allocation of resources on the target platform are performed. Before switching to the target platform, the system performs order scanning and resource pre-allocation on the other side according to the switching direction. When switching to the old platform, the system queries the computing power usage orders in the new platform whose status is not finished, extracts the physical resource identifier associated with the usage order, and updates the resource status field of the corresponding host on the old platform to occupied status, so that the old platform scheduler skips the locked host when allocating the host. When switching to the new platform, the system queries the computing power usage orders with a successful status on the old platform, extracts the physical resource identifier associated with the usage order, and updates the reserved status field of the corresponding bare metal resource on the new platform to reserved, so that the new platform scheduler skips the reserved resource when allocating bare metal. The pre-allocation method is declared as a synchronous method to ensure mutual exclusion safety when multiple usage orders are locked concurrently.

[0060] In this application, the persistent record of the order-resource lock relationship is maintained by appending the order identifier and resource identifier to the local persistent lock file in the format of order ID=MAC address key-value pairs after each resource pre-allocation operation. The same MAC address can correspond to multiple lock records from different time-switching operations, and the lock file retains a complete historical lock chain. The lock file is automatically created upon first access, ensuring that the locking process is not interrupted after a new deployment or accidental deletion of the lock file. Lock file reading, record deduplication and write-back operations are all performed under synchronous protection, ensuring safe concurrent writes.

[0061] In this application, order status is continuously unlocked driven by periodic tasks. The system deploys two independent periodic timed tasks, one responsible for scanning the old platform lock file and the other for the new platform lock file. The unlocking task reads all locked records from the lock file at configurable intervals, querying each computing power usage order to obtain its current usage status. The unlocking determination process only begins when the usage order status is "end"; otherwise, the lock remains and waits for the next cycle. If there is an error in reading the lock file or querying the usage order, the timed task skips the current locked record and continues processing the next one without performing any resource status changes, thus avoiding erroneous unlocking due to anomalies.

[0062] In this application, regarding the subsequent occupancy judgment and locking relay of MAC resources, after confirming that the usage order has ended, the system does not immediately release the resource. Instead, it performs a resource relay check: it iterates backward from the end of the lock file to determine if there is a newer usage order record that also locks the same physical resource identifier. If so, it means that the locking responsibility for the resource has been taken over by the locking record generated by the subsequent switching operation, and the current record is only cleaned up from the lock file without actually unlocking the resource. Only when there are no newer locking records for the same resource identifier in the lock file does the system perform actual resource release, restore the old platform resource status to available or restore the new platform resource reservation status to unreserved, and remove the corresponding locking record from the lock file. This mechanism implements a resource-level relay strategy where subsequent locking takes over from preceding locking, avoiding premature unlocking in continuous switching scenarios that could cause subsequent usage order protection to fail.

[0063] Compared to relying on manual verification and resource locking before and after a switchover, this application upgrades resource mutual exclusion protection during the switching between old and new platforms from manual operation to automated closed-loop control driven by order status. By persisting lock files and using periodic unlocking tasks, the problem of resource locking being disconnected from the order lifecycle is solved. A MAC relay check mechanism addresses the issues of lock overwriting and accidental release in continuous switching scenarios.

[0064] The following section uses the example of resource locking and unlocking in a scenario of continuous switching between old and new platforms to explain in detail the specific implementation process of this resource management method.

[0065] Suppose a physical computing node (resource identifier M1) in a data center undergoes multiple scheduling version changes during the transition between old and new platforms. Initial state: The scheduling version points to the old platform; M1 is idle on the old platform and unreserved on the new platform. The system has deployed two independent periodic scanning tasks, responsible for scanning and unlocking lock records on the host side and bare metal side respectively, both running at a frequency of once per minute. Initially, both lock files are empty.

[0066] Step 1: When switching to the new platform for the first time, perform a service shutdown verification and use a single scan on the other side.

[0067] The operations and maintenance personnel select "service shutdown" through the management page, confirm, and then select the new platform, triggering a switchover request. Upon receiving the request, the system queries the current scheduling version. If the current version is not in a shutdown state, the direct switchover is rejected. If the current version is in a shutdown state, the verification is passed, and the resource pre-allocation process for switching to the new platform is executed. The system queries for computing power usage orders still in effect on the old platform. Assuming a usage order (i.e., computing power order) O1 (order number S001, associated resource identifier M1) is found, it means that a computing power usage order is occupying M1 on the old platform. On the new platform side, the system marks the corresponding bare metal resource as reserved based on resource identifier M1. After successful pre-allocation, a locking relationship in the form of O1=M1 is appended to the bare metal lock file. The system then notifies the edge area nodes to update the scheduling route, completing the switchover.

[0068] Step 2: Continuous monitoring and status determination of bare metal side scanning tasks.

[0069] The bare metal side scan task is executed once per minute. The task first checks if the bare metal lock file exists and contains content. After reading the lock record O1=M1, it parses the usage unit identifier O1 and queries the current status of that usage unit on the old platform side. If the usage unit O1 is still active, the task skips and waits for the next cycle. This process may take several minutes to tens of minutes, depending on the remaining execution time of the usage unit O1.

[0070] Step 3: Migration failure, switch back to the old platform, and use single scan and resource locking on the other side.

[0071] Suppose that during the migration process, an abnormal network configuration is discovered on the new platform, and the operations and maintenance personnel decide to switch back to the old platform. First, service is suspended to interrupt the scheduling route, and then the old platform is selected. At this point, a usage order O2 (order number S002, associated resource identifier M1) has already been generated on the new platform. The system queries the new platform for unfinished computing power usage orders and finds usage order O2. On the old platform side, resource M1 is marked as occupied. After successful pre-occupancy, O2=M1 is appended to the host lock file. The system then updates the scheduling route, and the switch back to the old platform takes effect.

[0072] Step 4: Two-way locking coexists with independent monitoring of each.

[0073] At this point, two lock files manage locks in different directions: the bare metal lock file stores the single lock record (O1) used by the old platform when switching to the new platform; the host lock file stores the single lock record (O2) used by the new platform when switching back to the old platform. The two scanning tasks run independently, with the bare metal task continuously monitoring the state of O1 and the host task continuously monitoring the state of O2, without interference. In this scenario, from the perspective of the old platform scheduler, M1 is in an occupied state (locked by O2) and will not be allocated; from the perspective of the new platform scheduler, M1 is in a reserved state (locked by O1) and will also not be allocated. The same physical node is in an unallocable state in both platform schedulers.

[0074] Step 5: Use a single-end trigger to unlock the relay.

[0075] After a period of time, the usage unit O1 on the old platform completed its execution, and its status changed to "completed." During the next scan of the bare metal side, the scan task reads the lock file and finds the record O1=M1, confirming that the usage unit O1's status is complete. The task performs a resource relay check: it iterates backwards from the end of the lock file records, checking for any updated lock records containing the resource identifier M1 but with a different usage unit identifier. Currently, the bare metal lock file only has the record O1, and there are no subsequent records to overwrite it, so it is determined that unlocking is possible. On the new platform side, the task restores resource M1 from a reserved state to a non-reserved state. After a successful update, O1=M1 is added to the list to be cleared, and under the protection of the synchronization lock, this entry is removed from the lock file and the lock file is rewritten. At this point, the bare metal lock file becomes empty.

[0076] Step 6: Switch back to the new platform and lock the relay verification.

[0077] After the maintenance personnel fixed the network issue, they switched back to the new platform. The service was stopped first, then the new platform was selected. At this point, the old platform might have generated a new usage order O3 (order number S003, associated resource identifier M1). The system queries the active usage orders on the old platform and finds O3. On the new platform, M1 is marked as reserved again, and O3=M1 is appended to the bare metal lock file. The host lock file still retains the O2 lock record written during the previous switch back to the old platform. The host-side scanning task continues scanning. When the O2 usage order status changes to "end," a relay check for the same resource is performed. Since the host lock file only has one record for O2 and no updated record for the same resource, the task determines that the resource is actually unlocked: the resource M1 on the old platform is restored to a usable state, and the record is removed from the host lock file. At this point, all host-side locks are released, and M1 becomes usable again on the old platform. The O3 lock record in the bare metal lock file remains active, and the bare metal side scanning task continues to monitor the O3 status until O3 ends and is also released.

[0078] Corresponding to the above method embodiments, this application also provides a resource management device, and the resource management device described below can be referred to in correspondence with the resource management method described above.

[0079] See Figure 2 As shown, the device includes the following modules: The request response module 101 is used to respond to the switching request and obtain the unfinished computing power orders and their physical resource identifiers in the first computing power scheduling platform; Resource locking module 102 is used to lock the computing resources with physical resource identifiers in the second computing power scheduling platform and then append a locking record to the first lock file. The periodic query module 103 is used to periodically read the lock records of the first lock file and query the order status of the computing power orders corresponding to the lock records; The resource unlocking module 104 is used to, if the order status is closed, traverse backwards from the end of the first lock file to determine if there is an updated lock record with the same resource identifier that was written later than the lock record; if there is, delete the lock record in the first lock file and maintain the lock of the computing power resources by the second computing power scheduling platform; otherwise, release the lock of the computing power resources by the second computing power scheduling platform and delete the lock record in the first lock file.

[0080] The method provided in this application embodiment, in response to a switching request, obtains unfinished computing power orders and their physical resource identifiers in the first computing power scheduling platform; in the second computing power scheduling platform, after locking the computing power resources with the physical resource identifiers, appends a locking record to the first lock file; periodically reads the locking records in the first lock file and queries the order status of the computing power orders corresponding to the locking records; if the order status is finished, iterates backward from the end of the first lock file to determine whether there is an updated locking record with the same resource identifier that was written later than the locking record; if it exists, the locking record in the first lock file is deleted and the second computing power scheduling platform maintains the locking of the computing power resources; otherwise, the second computing power scheduling platform releases the locking of the computing power resources and deletes the locking record in the first lock file.

[0081] During the corresponding switchover request process, the system first retrieves unfinished computing power orders and their physical resource identifiers from the first computing power scheduling platform. Then, it performs a locking operation on the resource in the second computing power scheduling platform and writes the locking record to the first lock file. Based on the computing power orders from the first computing power scheduling platform, the corresponding resources are locked in the second computing power scheduling platform. This ensures that the same physical resource is pre-marked as unallocable in the second computing power scheduling platform, avoiding the problem of the same physical resource being repeatedly allocated by the two computing power scheduling platforms during the switchover. By periodically reading the locking records in the first lock file and querying the order status from the first computing power scheduling platform, the system only initiates the unlocking process when the order ends. This achieves dynamic binding between the lock lifecycle and the order execution progress, avoiding the problems of premature resource release or long-term idleness caused by static locking. By performing a resource relay check by traversing backwards from the end of the first lock file, if a subsequent lock record (i.e., an updated lock record) exists, only the current record is cleared without releasing the resource. Only when the subsequent lock record does not exist is the resource actually unlocked on the second computing power scheduling platform. This achieves resource-level relay protection where the subsequent lock takes over the preceding lock in a continuous switching scenario, avoiding the situation where the resource is incorrectly released due to the end of the preceding order but is still locked by the resources required by the subsequent order.

[0082] Therefore, this application can manage resources in an orderly, dynamic and reliable manner when switching computing power scheduling platforms.

[0083] In one specific embodiment of this application, the resource locking module is specifically used to construct key-value pairs using order identifiers and physical resource identifiers; and to append the key-value pairs one by one to the first lock file.

[0084] In one specific embodiment of this application, the request response module is further configured to receive a switchback request to switch the scheduling from the second computing power scheduling platform to the first computing power scheduling platform when the second computing power scheduling platform malfunctions; and to query the computing power orders and their physical resource identifiers that are in an unfinished state in the second computing power scheduling platform. The resource locking module is also used to lock the computing resources identified by the physical resource identifier within the first computing power scheduling platform, and then append a lock record to the second lock file.

[0085] In one specific embodiment of this application, the first lock file and the second lock file are managed independently by their respective periodic tasks.

[0086] In one specific embodiment of this application, the periodic query module is specifically used to read all the locked records in the first lock file at preset periods and query the order status of the corresponding computing power order from the first computing power scheduling platform one by one; If the first lock file read fails or the computing power order status query fails, skip the currently locked record and continue processing the next one.

[0087] In one specific embodiment of this application, the first computing power scheduling platform is a host scheduling platform or a bare metal orchestration platform; the lock file of the host scheduling platform is a host lock file; and the lock file of the bare metal orchestration platform is a bare metal lock file.

[0088] In one specific embodiment of this application, the resource unlocking module is specifically used to perform a reverse search from the end to the beginning of the first lock file to filter out all lock records that have the same physical resource identifier as the current lock record; if a lock record with the same resource located after the current lock record is found, it is determined that there is an updated lock record.

[0089] Corresponding to the above method embodiments, this application also provides an electronic device. The electronic device described below can be referred to in correspondence with the resource management method described above.

[0090] See Figure 3 As shown, the electronic device includes: Memory 332 is used to store computer programs; The processor 322 is used to implement the steps of the resource management method in the above method embodiments when executing a computer program.

[0091] For details, please refer to Figure 4 , Figure 4 This is a schematic diagram of the specific structure of an electronic device provided in this embodiment. The electronic device can vary significantly due to differences in configuration or performance. It may include one or more central processing units (CPUs) (e.g., one or more processors) and a memory 332. The memory 332 stores one or more computer programs 342 or data 344. The memory 332 can be temporary or permanent storage. The program stored in the memory 332 may include one or more modules (not shown in the diagram), each module may include a series of instruction operations on the data processing device. Furthermore, the processor 322 may be configured to communicate with the memory 332 and execute the series of instruction operations stored in the memory 332 on the electronic device 301.

[0092] Electronic device 301 may also include one or more power supplies 326, one or more wired or wireless network interfaces 350, one or more input / output interfaces 358, and / or one or more operating systems 341.

[0093] The steps in the resource management method described above can be implemented by the structure of an electronic device.

[0094] Corresponding to the above method embodiments, this application also provides a readable storage medium. The readable storage medium described below can be referred to in conjunction with the resource management method described above.

[0095] A readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the resource management method described in the above method embodiments.

[0096] The readable storage medium can specifically be a USB flash drive, external hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk, or any other readable storage medium capable of storing program code.

[0097] 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.

[0098] 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.

[0099] 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.

[0100] Finally, it should be noted that in this document, relationships such as "first" and "second" are used merely 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 "include," "contain," or any other variations 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.

[0101] This document uses specific examples 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 resource management method, characterized in that, include: In response to the switching request, obtain the unfinished computing power orders and their physical resource identifiers in the first computing power scheduling platform; Within the second computing power scheduling platform, after locking the computing power resources identified by the physical resource identifier, a lock record is appended to the first lock file. Periodically read the lock records of the first lock file and query the order status of the computing power orders corresponding to the lock records; If the order status is closed, then traverse backwards from the end of the first lock file to determine if there is an update lock record with the same resource identifier that was written later than the lock record. If it exists, delete the lock record in the first lock file and maintain the second computing power scheduling platform's lock on the computing power resource; otherwise, release the second computing power scheduling platform's lock on the computing power resource and delete the lock record in the first lock file.

2. The method according to claim 1, characterized in that, The mapping relationship between the order identifier of the computing power order and the physical resource identifier is appended to the first lock file, including: Construct key-value pairs using the order identifier and the physical resource identifier; The key-value pairs are appended one by one to the first lock file.

3. The method according to claim 1, characterized in that, Also includes: When the second computing power scheduling platform malfunctions, a switchback request is received to switch the scheduling from the second computing power scheduling platform back to the first computing power scheduling platform. Query the computing power orders that are in an unfinished state and their physical resource identifiers in the second computing power scheduling platform; Within the first computing power scheduling platform, after locking the computing power resource identified by the physical resource identifier, a lock record is appended to the second lock file.

4. The method according to claim 3, characterized in that, The first lock file and the second lock file are managed independently by their respective periodic tasks.

5. The method according to claim 1, characterized in that, Periodically read the lock records of the first lock file and query the order status of the computing power orders corresponding to the lock records, including: Read all locked records in the first lock file at preset intervals, and query the order status of the corresponding computing power order from the first computing power scheduling platform for each record; If the first lock file reading fails or the computing power order status query fails, the current locked record is skipped and the next record is processed.

6. The method according to claim 5, characterized in that, The first computing power scheduling platform is either a host scheduling platform or a bare metal orchestration platform; the lock file of the host scheduling platform is a host lock file; the lock file of the bare metal orchestration platform is a bare metal lock file.

7. The method according to claim 1, characterized in that, Traverse backwards from the end of the first lock file to determine if there exists an update lock record with the same resource identifier that was written later than the lock record, including: Search backwards from the end to the beginning of the first lock file to filter out all lock records that have the same physical resource identifier as the current lock record; If a lock record for the same resource is found after the current lock record, it is determined that the updated lock record exists.

8. A resource management device, characterized in that, include: The request and response module is used to respond to switching requests and obtain unfinished computing power orders and their physical resource identifiers in the first computing power scheduling platform; The resource locking module is used to lock the computing resources identified by the physical resource identifier in the second computing power scheduling platform and then append a locking record to the first lock file. The periodic query module is used to periodically read the lock records of the first lock file and query the order status of the computing power orders corresponding to the lock records; The resource unlocking module is used to, if the order status is closed, traverse backwards from the end of the first lock file to determine whether there is an update lock record with the same resource identifier that is written later than the lock record. If it exists, delete the lock record in the first lock file and maintain the second computing power scheduling platform's lock on the computing power resource; otherwise, release the second computing power scheduling platform's lock on the computing power resource and delete the lock record in the first lock file.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the resource management method as described in any one of claims 1 to 7.

10. A readable storage medium, characterized in that, The readable storage medium stores a computer program that, when executed by a processor, implements the steps of the resource management method as described in any one of claims 1 to 7.

Images