A cloud instance reuse method based on physical machine local storage and object storage

Abstract

This invention provides a cloud instance reuse method based on physical machine local storage and object storage, relating to the field of virtualization technology. The method includes: adding a server to a platform and performing capacity planning upon addition; allocating N virtual instances of fixed specifications to the server; and allocating M additional free disks in the server's local storage to reserve storage space for unbinding operations of virtual instance disks. Based on the reserved storage space, when a virtual instance on the server is detected to meet inactivity conditions, the disk data of the inactive virtual instance is backed up to object storage, the association between the inactive virtual instance and the local disk is unbound, and the local disk is used as the unbound disk associated with the user. This invention achieves a balance between low-cost resource utilization and a high-quality user experience.

Description

Technical Field

[0001] This invention relates to the field of virtualization technology, and in particular to a cloud instance reuse method based on physical machine local storage and object storage. Background Technology

[0002] In the cloud phone scenario, to meet the demand of a large number of users for lightweight cloud phones, a cloud service provider uses an existing solution that stores virtual instance disks on the server's local storage and backs up user data to object storage to achieve instance time-sharing reuse. That is, users are allocated standardized lightweight cloud phone instances with configurations that can meet the needs of daily office work and short video editing. The high read and write performance of local storage ensures the smoothness of user operation. When a user does not access the device for a set period of time, the instance disk data is fully backed up to object storage and the instance is then released for new users to use.

[0003] For example, after editing and storing a large number of work documents and video materials on the cloud phone, user Zhang logged out. The platform backed up the data to object storage according to the procedure. The next day, when Zhang needed to urgently view the documents and logged back in, the platform allocated a new idle instance for him and restored the data from object storage. The entire restoration process took a long time. During this time, Zhang missed the document transmission node due to the long wait and eventually switched to another cloud service platform.

[0004] The solution has technical flaws. Although object storage is low-cost and local storage has excellent performance, the recovery time increases with the amount of user data as the full data is restored from object storage to the instance's local disk. This results in high latency and poor user experience when users try to reuse the data. Furthermore, frequent large file backup and recovery operations consume server bandwidth resources, indirectly reducing the operational stability of other active instances. It is difficult to balance the need for low-cost storage with the need for rapid instance reuse. Summary of the Invention

[0005] The technical problem to be solved by this invention is to provide a cloud instance reuse method based on physical machine local storage and object storage, so as to achieve a balance between low-cost resource utilization and high-quality user experience.

[0006] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:

[0007] Firstly, a cloud instance reuse method based on physical machine local storage and object storage, the method comprising:

[0008] Add the server to the platform and perform capacity planning when adding the server to the platform. Allocate N virtual instances of fixed specifications to the server and allocate M additional free disks in the server's local storage to reserve storage space for the disk unbinding operation of virtual instances.

[0009] Based on the reserved storage space, when a virtual instance on the server is detected to meet the inactive condition, the disk data of the inactive virtual instance is backed up to object storage, the association between the inactive virtual instance and the local disk is unbound, and the local disk is used as the unbound disk associated with the user; and an idle disk is rebound for the inactive virtual instance so that the inactive virtual instance returns to an idle state.

[0010] Based on the user-associated unbound disk, when a user requests to use a virtual instance, it checks whether the user has an unbound disk that is retained on the original server's local storage. If so, and there is an idle virtual instance on the server where the unbound disk is located, an idle virtual instance is allocated for the user on the server, and the user's associated unbound disk is bound to the idle virtual instance. If not, an idle virtual instance is allocated for the user from the global server pool, and the user data is restored from object storage to the local disk of the idle virtual instance, completing the virtual instance restoration.

[0011] Based on the virtual instance recovery requirements, a virtual instance allocation rate threshold is set. When the virtual instance allocation rate on the server exceeds the preset threshold, it is prohibited to allocate virtual instances to users who are using the platform for the first time, so as to keep idle virtual instances on the server to bind the unbound disk associated with the user.

[0012] Furthermore, the server is added to the platform, and capacity planning is performed during the addition process. N virtual instances of a fixed size are allocated to the server, and M additional free disks are allocated in the server's local storage to reserve storage space for virtual instance disk unbinding operations. This includes:

[0013] Determine the maximum number of virtual instances that the server's local storage can support based on the server's total local storage capacity and the disk specifications of a single virtual instance;

[0014] Based on the maximum number and in combination with the preset resource reuse strategy, calculate and determine the number N of fixed-size virtual instances allocated to the server, where N is less than the maximum number. Based on the expected user instance switching frequency of the resource reuse strategy, calculate and determine the number of free disks M that need to be reserved to support unbinding disk retention operations.

[0015] In the server's local storage, the disk space required for the operation of the determined N virtual instances is allocated. Based on the value of M, the storage space of M additional free disks is allocated, and the free disk resource pool is obtained through initialization.

[0016] Furthermore, based on the reserved storage space, when a virtual instance on the server is detected to meet the inactive condition, the disk data of the inactive virtual instance is backed up to object storage, the association between the inactive virtual instance and the local disk is unbound, and the local disk is used as the unbound disk associated with the user, including:

[0017] The monitoring platform detects that a virtual instance on the server has been inactive for a period of time with no user access.

[0018] For virtual instances that are determined to be inactive, all data in the local disk currently used by the virtual instance is backed up to remote object storage for persistent storage; after the backup operation is completed, based on the backup completion status, the disk unbinding operation is performed to remove the binding relationship between the virtual instance and the current local disk, so as to obtain a local disk that is separated from the instance.

[0019] By marking the local disk as the only unbound disk uniquely associated with the user corresponding to the inactive virtual instance, and keeping the unbound disk in the local storage of the original server, the mapping relationship between the user and the unbound disk is updated.

[0020] Furthermore, to restore the inactive virtual instance to an idle state, a free disk is re-bound for the inactive virtual instance, including:

[0021] By allocating a new free disk from the server's free disk resource pool for the virtual instance that has completed the disk unbinding operation and binding it, the status of the virtual instance is updated to free.

[0022] Based on the idle state, continuously monitor the number of available idle disk resources in the server's idle disk resource pool; when it is determined that the number of available idle disks is lower than the preset stock threshold, trigger the disk cleanup process;

[0023] Based on the disk cleanup process, multiple user-associated unbound disks retained in the server's local storage are evaluated, and according to the preset cleanup strategy, data on some unbound disks is selected to be cleared, restored to free disks, and the free disks are reclaimed into the free disk resource pool.

[0024] When there is not enough free disk space on the server, multiple user-associated unbound disks and free disk resource pools are combined to form a local disk pool for rapid recovery.

[0025] Furthermore, based on the user-associated unbound disk, when a user requests to use a virtual instance, it checks whether the user has an unbound disk retained on the original server's local storage. If so, and the server where the unbound disk is located has an idle virtual instance, then an idle virtual instance is allocated for the user on the server, and the user's associated unbound disk is bound to the idle virtual instance, including:

[0026] Based on the user's associated unbound disk, respond to the user's request to use the virtual instance, and query whether the user has a reserved unbound disk associated in the local disk pool according to the mapping relationship between the user and the unbound disk, so as to obtain the query result;

[0027] If the query result is yes, locate the physical server where the unbound disk is located, and check if there is a virtual instance on the server that is in an idle state;

[0028] If it exists, allocate an idle virtual instance for the user on the server, unbind the currently bound disk of the allocated instance, and bind the unbound disk associated with the user to the virtual instance to complete the fast recovery.

[0029] Furthermore, if not, an idle virtual instance is allocated to the user from the global server pool, and the user data is restored from object storage to the local disk of the idle virtual instance to complete the virtual instance restoration, including:

[0030] If the query result is negative, it is determined that a quick recovery based on the locally unbound disk cannot be performed, thus triggering the regular recovery process;

[0031] Based on triggering the regular recovery process, select a server with an idle virtual instance from the global server resource pool and allocate an idle virtual instance on the server to the user;

[0032] Based on an idle virtual instance, the system retrieves the user's backup data in object storage and restores the backup data to the local disk currently bound to the allocated idle virtual instance, thus completing the rapid recovery of the virtual instance.

[0033] Furthermore, based on virtual instance recovery needs, a virtual instance allocation rate threshold is set. When the virtual instance allocation rate on the server exceeds the preset threshold, allocating virtual instances to users using the platform for the first time is prohibited. This ensures that idle virtual instances are reserved on the server to bind user-associated unbound disks, including:

[0034] During the platform scheduling process, the ratio between the number of virtual instances allocated to users on each server and the total number of virtual instances N on the server is continuously monitored and calculated as the virtual instance allocation rate of the server.

[0035] Based on the virtual instance allocation rate, determine whether the instance allocation rate exceeds a preset scheduling threshold to obtain the determination result;

[0036] Based on the judgment results, if the server allocation rate exceeds the threshold, a scheduling restriction policy will be implemented on the server to prohibit the allocation of idle virtual instances on the server to new users using the platform.

[0037] By implementing restriction policies, idle virtual instance resources on the server are reserved. These reserved resources are prioritized for historical users who have retained unbound disks locally and are reusing them, so as to ensure the availability of local fast recovery paths through rapid binding operations.

[0038] Secondly, a cloud instance reuse system based on physical machine local storage and object storage includes:

[0039] The acquisition module is used to add servers to the platform and perform capacity planning when servers are added to the platform. It allocates N virtual instances of fixed specifications to the servers and additionally allocates M free disks in the local storage of the servers to reserve storage space for the unbinding operation of virtual instance disks.

[0040] The detection module is used to back up the disk data of the inactive virtual instance to object storage when it detects that the virtual instance on the server meets the inactive condition, based on the reserved storage space; unbind the inactive virtual instance from the local disk and set the local disk as the unbound disk associated with the user; and rebind an idle disk for the inactive virtual instance so that the inactive virtual instance returns to an idle state.

[0041] The unbinding module is used to unbind disks associated with users. When a user requests to use a virtual instance, it checks whether the user has an unbinded disk that is stored on the original server's local storage. If so, and there is an idle virtual instance on the server where the unbinded disk is located, an idle virtual instance is allocated for the user on the server, and the user's associated unbinded disk is bound to the idle virtual instance. Otherwise, an idle virtual instance is allocated for the user from the global server pool, and the user data is restored from object storage to the local disk of the idle virtual instance, completing the virtual instance restoration.

[0042] The processing module is used to set a virtual instance allocation rate threshold based on the virtual instance recovery requirements. When the virtual instance allocation rate on the server exceeds the preset threshold, it prohibits the allocation of virtual instances to users who are using the platform for the first time, so as to keep idle virtual instances on the server to bind the unbound disk associated with the user.

[0043] Thirdly, a computing device includes:

[0044] One or more processors;

[0045] A storage device for storing one or more programs that, when executed by one or more processors, cause the one or more processors to implement the method.

[0046] Fourthly, a computer-readable storage medium storing a program that, when executed by a processor, implements the method.

[0047] The above-described solution of the present invention has at least the following beneficial effects:

[0048] This method effectively overcomes the technical problems of existing local storage and object storage solutions having long recovery times that are positively correlated with user data volume, and network shared storage solutions having high costs and poor disk access performance. It achieves the technical effect of enabling rapid instance recovery through disk binding operations in most scenarios, eliminating reliance on high-cost distributed storage, maintaining excellent read / write performance of virtual instances based on local storage, and ensuring a smooth recovery experience for historical users and efficient server resource reuse through resource reservation strategies. Furthermore, it employs capacity planning and additional M free disks to reserve unbound storage space when a server instance allocation rate exceeds a preset threshold, and prohibits the allocation of instances to first-time users to reserve resources for rapid binding by historical users. Attached Figure Description

[0049] Figure 1 This is a flowchart illustrating a cloud instance reuse method based on physical machine local storage and object storage, provided by an embodiment of the present invention.

[0050] Figure 2 This is a schematic diagram of a cloud instance reuse system based on physical machine local storage and object storage, provided by an embodiment of the present invention. Detailed Implementation

[0051] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0052] like Figure 1 As shown, an embodiment of the present invention proposes a cloud instance reuse method based on physical machine local storage and object storage, the method comprising the following steps:

[0053] Step 1: Add the server to the platform and perform capacity planning when adding the server to the platform. Allocate N virtual instances of fixed specifications to the server and allocate M additional free disks in the server's local storage to reserve storage space for the unbinding operation of virtual instance disks.

[0054] Step 2: Based on the reserved storage space, when the virtual instance on the server is detected to meet the inactive condition, back up the disk data of the inactive virtual instance to object storage, unbind the association between the inactive virtual instance and the local disk, and use the local disk as the unbound disk associated with the user; and rebind an idle disk for the inactive virtual instance so that the inactive virtual instance returns to the idle state.

[0055] Step 3: Based on the user's associated unbound disk, when a user requests to use a virtual instance, check whether the user has an associated unbound disk stored on the original server's local storage. If so, and the server where the unbound disk is located has an idle virtual instance, then allocate an idle virtual instance for the user on the server and bind the user's associated unbound disk to the idle virtual instance; otherwise, allocate an idle virtual instance for the user from the global server pool, and restore the user's data from object storage to the local disk of the idle virtual instance, completing the virtual instance restoration.

[0056] Step 4: Based on the virtual instance recovery requirements, set a virtual instance allocation rate threshold. When the virtual instance allocation rate on the server exceeds the preset threshold, it is prohibited to allocate virtual instances to users who are using the platform for the first time, so as to keep idle virtual instances on the server to bind the unbound disk associated with the user.

[0057] In this embodiment of the invention, because the invention employs capacity planning when the server joins the platform, allocates N virtual instances of fixed specifications and reserves M additional free disks to support disk unbinding operations, backs up the disk data of inactive virtual instances to object storage and retains the unbound disk associated with the user, prioritizes checking and binding the user's associated unbound disk when the user requests an instance, and prohibits the allocation of instances to first-time users when the server instance allocation rate exceeds a preset threshold in order to reserve resources for quick binding, the invention effectively overcomes the technical problems of long recovery time of existing local storage and object storage solutions that are positively correlated with the amount of user data, and high cost and poor disk access performance of network shared storage solutions. Thus, it achieves the technical effect of completing the rapid recovery of instances in most scenarios through disk binding operations alone, without relying on high-cost distributed storage, and virtual instances maintaining excellent read and write performance by relying on local storage. At the same time, the resource reservation strategy ensures the recovery experience of historical users and the efficiency of server resource reuse.

[0058] In a preferred embodiment of the present invention, step 1 above may include:

[0059] Step 1.1: Based on the server's total local storage capacity and the disk specifications of a single virtual instance, determine the maximum number of virtual instances that the server's local storage can support. Specifically, this includes: verifying the local storage capacity of the target server used to host the lightweight cloud phone instances. Using the server's built-in hardware management tools or third-party storage testing software, read the actual available total capacity of the server's local storage, excluding unavailable space occupied by system files, drivers, etc., to determine the total storage available for allocation to virtual instances. Next, considering the core usage scenarios of lightweight cloud phones—namely, users need to install office software, store work documents, and edit and save short video materials—after multiple scenario tests and evaluations, determine the disk specifications of a single virtual instance. The disk specifications must be able to accommodate commonly used office software installation packages, a certain number of work documents, and short video files to avoid insufficient capacity preventing normal user operation. Divide the previously determined total available local storage capacity of the server by the disk specifications of a single virtual instance to calculate the maximum number of virtual instances that the server's local storage can stably support. Ensure that the calculation result matches the server's hardware operating load and does not cause instance lag due to excessive storage allocation.

[0060] Step 1.2: Based on the maximum number and combined with the preset resource reuse strategy, calculate and determine the number N of fixed-specification virtual instances allocated to the server, where N is less than the maximum number. Based on the expected user instance switching frequency of the resource reuse strategy, calculate and determine the number M of additional free disks that need to be reserved to support unbinding disk retention operations. Specifically, this includes: first obtaining the calculated maximum number of virtual instances, then analyzing it in conjunction with the resource reuse strategy formulated by the platform for lightweight cloud phone scenarios. The resource reuse strategy needs to comprehensively consider user activity patterns. For example, historical data from the platform shows that most users frequently use cloud phones only during weekdays, with significantly reduced usage at night and on weekends, resulting in a large number of instances being inactive. At the same time, the strategy needs to also consider the access needs of new users, avoiding situations where the number of instances is insufficient to support the desired virtual instances. If too many virtual instances are allocated, new users may not be able to access resources in a timely manner. Based on the premise that the number N of fixed-specification virtual instances allocated to the server must be less than the maximum number, some storage resources are reserved for configuring additional free disks to ensure the stability of current active users and to leave enough space for subsequent disk unbinding operations. Then, calculations are performed based on the expected user instance switching frequency in the resource reuse strategy. The user instance switching frequency is obtained by statistically analyzing the average number of times a user goes from an active instance to an inactive instance and then re-logs in to reactivate the instance over a period of time. For example, historical data from the platform shows that users serving this server will have multiple instance switching needs per day. Based on the switching frequency, the number M of additional free disks that need to be reserved to support unbinding disk retention operations is determined to ensure that the number of M can cover the demand for free disks during each instance switch.

[0061] Step 1.3: In the local storage of the server, allocate the disk space required for the operation of the determined N virtual instances. Based on the value M, additional storage space is allocated to M free disks. This is done through initialization to obtain a free disk resource pool. Specifically, in the local storage of the target server, according to the determined disk specifications of a single virtual instance, independent disk space is allocated to each of the N virtual instances. The disk space of each instance is specifically used to store data generated during its operation, including user-installed office software, created work documents, edited short video materials, and application cache files. This ensures that the storage resources of different instances are independent of each other, avoiding data interference. The remaining available space in the local storage of the server... During this process, M independent storage spaces are additionally allocated according to the same disk specifications. These storage spaces are dedicated to the subsequent unbinding of instances. Initialization operations are performed on the idle disks: a unique identification code is assigned to each idle disk to facilitate accurate location by the platform's storage management system; read and write access permissions compatible with the lightweight cloud phone virtual instance operating system are configured to ensure that the disk can establish a normal binding relationship with the instance; the initial idle status of each disk is recorded and marked, and basic information such as the disk's code, specifications, and status is entered into the platform's storage management database to obtain a unified pool of idle disk resources, providing resource support for the unbinding and rebinding of disks for inactive instances.

[0062] In this embodiment of the invention, because the maximum number of virtual instances that the server's local storage can support is determined based on the total capacity of the server's local storage and the disk specifications of a single virtual instance, the number of fixed-specification virtual instances N (less than the maximum number) is determined based on the maximum number of virtual instances and a preset resource reuse strategy, and the number of additional free disks M (supporting unbinding disk retention operations) is determined based on the expected user instance switching frequency of the strategy, and then the disk space required for the operation of N virtual instances is allocated in the server's local storage, and the storage space of M additional free disks is allocated and initialized to obtain a free disk resource pool, the technical means overcome the problem of the lack of targeted server storage capacity planning in the prior art. This addresses the technical issues that arise when there are no extra free disks available for unbinding instances to retain local disks, forcing reliance on object storage for data recovery, or when high-cost network shared storage is used to ensure switching speed. Furthermore, unreasonable allocation of instance numbers can lead to wasted or insufficient storage resources. This solution precisely matches the server's local storage resources with the operational and unbinding / retention needs of virtual instances. It provides ample disk space for the stable operation of N virtual instances while using M additional free disks to lay the foundation for unbinding and retaining inactive instances and enabling rapid disk recovery. Simultaneously, it avoids excessive or idle storage resources, achieving the technical effect of controlling storage costs while ensuring the availability of local disk resources during instance reuse.

[0063] In a preferred embodiment of the present invention, step 2 above may include:

[0064] Step 2.1: Monitor the user access status of each virtual instance within the monitoring platform. When the time during which no user access is detected on a virtual instance on the server exceeds a preset threshold, the virtual instance is determined to be an inactive instance. Specifically, this includes: deploying a dedicated virtual instance access status monitoring component on each server of the cloud phone platform. The monitoring component needs to establish a continuous and stable communication connection with each standardized lightweight cloud phone virtual instance running on the server to ensure that it can capture the user access dynamics of the instance in real time. The monitoring component will collect various user access signals of the instance, including but not limited to keyboard input operations, mouse click operations, screen touch interaction behavior, application startup and switching records, file read and write operation records, etc., to determine whether the user is using the instance. The monitoring component is configured with an independent timing function for each virtual instance, which will accurately record the time point when each instance last detected a valid user access signal, and continuously accumulate the duration of no access signal from that time point. The platform analyzes the daily usage habits of lightweight cloud phone users. For example, through historical operational data, it is found that if most users do not access the instance within 2 hours after using it once, it is likely that the instance is temporarily not in use. Therefore, the preset threshold for the duration of no access is set to 2 hours. The monitoring component will compare the cumulative duration of no access for each instance with the preset 2-hour threshold in real time. Once it is detected that the cumulative duration of no access for a virtual instance exceeds 2 hours, it will immediately generate a judgment result that the virtual instance is an inactive instance and synchronize the judgment result of the inactive instance to the platform.

[0065] Step 2.2: For virtual instances deemed inactive, back up all data on the local disk currently used by the virtual instance to remote object storage for persistent storage. After the backup operation is complete, based on the backup completion status, perform a disk unbinding operation to remove the binding relationship between the virtual instance and the current local disk, resulting in a local disk separate from the instance. Specifically, after the platform's instance management module receives the determination result that a virtual instance is an inactive instance, it starts a full backup task of the local disk data of the inactive instance. The backup task will traverse all data stored on the local disk currently used by the virtual instance. This data includes work documents created and saved by the user in the instance, short video materials edited and generated, installation package files of daily office software and short video editing tools, application configuration files generated during instance operation, user personalized settings data, and temporary cache files, ensuring that no user-related data is missed. During the backup process, the platform will synchronously transmit all the traversed and collected data to remote object storage through a pre-built dedicated data transmission channel. This dedicated transmission channel can ensure the stability and security of data transmission, and the transmission target path will be associated with the user's unique identity identifier for quick location of the user's backup data later. Once all data transfers are complete, the platform will immediately initiate a data integrity verification mechanism. By comparing key information such as the number of files, individual file size, and file checksum of the original data on the local disk with the backup data in the remote object storage, the platform confirms that the backup data is not lost, damaged, or tampered with. Only if the data integrity verification result is passed will the platform, based on the state that the backup is complete and the data is error-free, execute the unbinding operation between the virtual instance and the current local disk. This is done by calling the server storage management interface to send an unbinding command, ultimately resulting in a local disk that is completely separated from the original inactive instance and has complete data.

[0066] Step 2.3 involves updating the mapping relationship between users and unbound disks by marking the local disk as the unique unbound disk associated with the user corresponding to the inactive virtual instance, and retaining the unbound disk in the local storage of its original server. Specifically, after completing the unbinding operation between the virtual instance and the local disk, the platform performs a dedicated marking operation on the separated local disk. During the marking process, the local disk is bound to the unique identifier of the user corresponding to the original inactive instance. For example, information such as the user account ID and user identification code are associated with the hardware identifier of the local disk, ensuring that the local disk becomes the unique unbound disk corresponding to that user and avoiding confusion with disks belonging to other users. Simultaneously, the platform retains the marked unbound disk in the local storage of its original server, without migrating it across servers or deleting the user data stored on the disk. This ensures that users can directly access the local disk when they reuse the instance. In addition, the platform will synchronously update the mapping relationship between users and unbound disks, and uniformly record key information such as the user's unique identity, the hardware identifier of the unbound disk, the location information of the server where the unbound disk is located, and the last update time of the data in the disk into the platform's storage resource management database to obtain a complete record of the association between users, disks, and servers.

[0067] In this embodiment of the invention, by monitoring the user access status of each virtual instance within the monitoring platform, virtual instances with no user access time exceeding a preset threshold are determined to be inactive instances. For inactive instances, all data in their currently used local disk is backed up to remote object storage to achieve persistent data storage. After the backup is completed, a disk unbinding operation is performed to remove the binding relationship between the instance and the local disk. The unbound local disk is marked as the unique unbound disk associated with the user corresponding to the inactive instance and retained in the local storage of the original server. At the same time, the mapping relationship between the user and the unbound disk is updated. Therefore, this method overcomes the technical problems of existing local storage and object storage solutions, which only back up data to object storage when the user is inactive but do not retain the local disk, resulting in the need to fully restore the data from object storage when the user resumes use, as well as the high cost and poor disk access performance of network shared storage solutions. Thus, it achieves the technical effect of ensuring data security through object storage backup, laying the foundation for subsequent rapid recovery by retaining the unbound disk associated with the user on the original server, and maintaining excellent read and write performance by relying on the local disk, thus balancing data security, rapid instance recovery, and low-cost storage.

[0068] In a preferred embodiment of the present invention, step 2 above may include:

[0069] Step 2.4 involves allocating a new free disk from the server's free disk resource pool to the virtual instance that has completed the disk unbinding operation, binding it, and updating the virtual instance's status to idle. Specifically, this includes: first, identifying the virtual instance that has completed the disk unbinding operation. These instances are lightweight cloud phone instances that were previously deemed inactive due to a set period of inactivity, and have completed local disk data backup to object storage and unbinded from their original disk. Their specifications meet the needs of daily office work and short video editing. The platform's storage management module reads the real-time status of the server's free disk resource pool, filters out free disks that perfectly match the virtual instance's specifications, ensuring that the disk capacity and performance can support the instance's subsequent operation. Storage management establishes a binding relationship between the selected new free disk and the unbound virtual instance through the server's disk binding interface, completing the disk mounting configuration. Finally, the instance management module updates the virtual instance's status from pending disk binding to idle and synchronizes it to the platform's instance scheduling system, making the instance available for allocation by new users and ensuring rapid reuse of instance resources.

[0070] Step 2.5: Based on the idle state, continuously monitor the available number of idle disk resources in the server's idle disk resource pool. When it is determined that the number of available idle disks is lower than the preset inventory threshold, trigger the disk cleanup process. Specifically, the platform deploys a dedicated idle disk monitoring module. This module establishes a real-time data connection with the server's idle disk resource pool and continuously counts the number of available idle disks in the pool. Combining the instance reuse requirements in the cloud phone scenario, the platform sets an idle disk inventory threshold based on historical operational data. For example, by analyzing the average daily instance unbinding demand generated by the server in the past month, the inventory threshold is set to 50 to ensure that the threshold is higher than the average daily demand and to reserve sufficient buffer space. The monitoring module compares the real-time count of available idle disks with the preset threshold at fixed intervals. When it detects that the number of available disks is lower than 50, it immediately sends a trigger signal to the platform's storage management module to start the disk cleanup process. This avoids the inability to bind new disks in time after inactive instances are unbound due to insufficient idle disks, forcing reliance on object storage to recover data.

[0071] Step 2.6: Based on the disk cleanup process, evaluate the multiple user-associated unbound disks retained in the server's local storage. According to the preset cleanup strategy, select and clear the data on some of the unbound disks, restoring them to free disks, and then reclaim the free disks into the free disk resource pool. Specifically, this includes: First, conducting a comprehensive evaluation of all user-associated unbound disks retained in the server's local storage. The evaluation dimensions include two aspects: one is the likelihood of future user usage instances, determined by combining user historical access patterns. For example, by analyzing a user's access records over the past three months, if a user consistently uses a cloud phone to process office documents and edit short videos from Monday to Friday each week, or recently... If a user still logs in within 7 days after unbinding, it's determined that the user is highly likely to use the service again in the future, and the associated unbound disks should be skipped from cleanup. Secondly, the disk unbinding duration is recorded, tracking the cumulative time each unbound disk has been freed from the instance. Then, a pre-defined cleanup strategy is executed: disks with the longest unbinding duration and low likelihood of future user use are prioritized. For example, disks unbound for more than 30 days with no login or access records from the user in the past 30 days are considered low-reuse-value disks. Data erasure is performed on these disks, deleting user office documents, short video materials, and other data stored on them, restoring the disks to a blank, idle state without any user association. Finally, the restored idle disks are re-entered into the server's idle disk resource pool through the storage management module, updating the disk quantity statistics in the pool and replenishing available disk resources.

[0072] Step 2.7: When there is insufficient free disk space on the server, a local disk pool for rapid recovery is formed by combining multiple user-associated unbound disks and a pool of free disk resources. Specifically, after disk cleanup and free disk reclamation, two parts of disk resources are integrated for management: one part consists of user-associated unbound disks retained after evaluation. These disks still store the corresponding user's office data, short video materials, etc., and are marked with a unique user identifier for quick matching when the user logs in again. The other part is a pool of free disk resources containing the original remaining free disks and reclaimed free disks. These disks are blank, without user association information, and can be used for rebinding to new inactive instances or allocating new user instances. The platform establishes a unified management directory for these two parts of disks through the storage management module, recording the status, specifications, server location, and associated user information of each disk, forming a local disk pool for rapid recovery. When a user subsequently requests to use a cloud phone instance, the platform can directly query this local disk pool to see if a user-associated unbound disk exists. If it does, the platform directly binds the instance to complete rapid recovery without reading data from object storage, effectively shortening recovery time.

[0073] In this embodiment of the invention, because a new free disk is allocated and bound to a virtual instance that has completed disk unbinding operation from the server's free disk resource pool based on its idle state, and the virtual instance's state is updated to free, the available number of free disk resources in the free disk resource pool is continuously monitored, and a disk cleanup process is triggered when the number falls below a preset stock threshold. Based on the cleanup process, multiple user-associated unbound disks retained in the server's local storage are evaluated, and data on some disks is cleared according to a preset strategy to restore them to free disks and reclaim them into the free disk resource pool. At the same time, the retained user-associated unbound disks and the free disk resource pool together constitute a local disk pool serving rapid recovery. Therefore, this overcomes the technical means of existing local storage and object storage methods. The solution addresses the technical issues of lacking a dynamic allocation mechanism for free disks, which leads to the inability to quickly reuse unbound instances; lacking a disk cleanup strategy, which easily results in insufficient free disks; and the high cost of network shared storage solutions. It also solves the problem of wasted disk resources or accidental deletion of critical unbound disks due to unplanned management. This ensures that unbound virtual instances can be quickly bound to new free disks for immediate reuse, maintains sufficient free disk resources through a dynamic cleanup mechanism to ensure the effective retention of user-associated unbound disks, and relies on a local disk pool to balance the need for rapid recovery with efficient use of disk resources. It maintains the excellent read and write performance of local storage while avoiding reliance on high-cost network shared storage, ultimately achieving a balance between low-cost storage and rapid instance reuse.

[0074] In a preferred embodiment of the present invention, step 3 above may include:

[0075] Step 3.1: Based on the user's associated unbound disk, respond to the user's request to use the virtual instance. According to the mapping relationship between the user and the unbound disk, query whether the user has a reserved unbound disk associated in the local disk pool to obtain the query result. Specifically, after the user logs into the cloud phone platform and clicks the "Enter Cloud Phone" button to initiate a request to use the virtual instance, the platform's instance scheduling function unit receives the request and initiates the response process. First, it's important to clarify that the response is based on the local disk pool, which consists of two parts: one part is the unbound disk associated with the user's identity, retained after unbinding when the user instance was inactive, storing data such as work documents and short video materials from the user's previous use of the cloud phone; the other part is cleaned-up and reclaimed blank free disks, and all disks belong to the local storage of each server within the platform. Next, the platform's instance scheduling function unit calls the query interface of the storage management database, inputting the unique identifier of the requesting user, such as the user's registered account or the user ID assigned by the platform. It matches the mapping entries between the user and the unbound disk that are pre-recorded in the database. The mapping entries include the user's identity identifier, the unique hardware identifier of the unbound disk, such as the disk serial number, the server information where the disk is located, and the disk status, such as reserved or pending cleanup. The platform's instance scheduling function unit compares the entries to determine whether there is an unbound disk with a reserved status that belongs to the local disk pool. If it exists, the query result is yes; if it does not exist, the query result is no. The query result is then fed back to the platform's instance scheduling function unit.

[0076] Step 3.2: If the query result is yes, locate the physical server where the unbound disk is located and check if there are any idle virtual instances on the server. Specifically, if the query result is yes, the platform's instance scheduling unit extracts the physical server identifier corresponding to the unbound disk from the mapping entry between the user and the unbound disk, such as the server IP address or device number, to locate the physical server where the unbound disk is actually stored. The platform's instance scheduling unit sends a query request to the instance management unit on that physical server to obtain the status information of all current virtual instances on the server. After receiving the request, the instance management unit on the server filters out virtual instances that meet the lightweight cloud phone specifications. These specifications can meet the needs of daily office work and short video editing, such as fixed CPU, memory, and disk configurations, and these instances are in an idle state, that is, not allocated to any user and can be directly bound to the disk for use. The number of such instances is counted. If the count is greater than 0, the instance management unit on the server returns feedback to the platform's instance scheduling unit that there are idle virtual instances, along with the unique identifier of the idle instance, such as the instance number; if the count is 0, feedback is returned that there are no idle virtual instances.

[0077] Step 3.3: If an available virtual instance exists, allocate an idle virtual instance to the user on the server, unbind the currently bound disk from the allocated instance, and bind the user's associated unbound disk to the virtual instance to complete the rapid recovery. Specifically, if the feedback result indicates that an idle virtual instance exists, the platform's instance scheduling function unit randomly selects an instance that meets the lightweight cloud phone specifications from the returned list of idle instances and allocates it to the current user. It then sends a disk unbinding instruction to the storage management function unit on the server to which the instance belongs. Upon receiving the instruction, the storage management function unit on the server first performs the disk unbinding operation: through the server's local storage control interface, it unbinds the currently bound blank idle disk from the allocated idle instance. This disk was rebound when the instance was previously inactive and contains no user data. The unbound blank disk is then... The disk is marked as awaiting reallocation and stored back in the server's free disk resource pool. Next, the storage management unit on the server performs a disk binding operation: based on the hardware identifier of the user-associated unbound disk, the disk is located in the server's local storage. Through the same storage control interface, the unbound disk is bound to the allocated free instance, completing the disk mounting configuration. This process only requires establishing an access link between the instance and the disk, without transferring user data on the disk, such as work documents or short video materials. The storage management unit on the server sends a signal to the instance scheduling unit on the platform that the disk binding is complete. The instance scheduling unit on the platform then sends a notification to the user that the cloud phone is ready. After clicking to enter, the user can directly use the cloud phone instance with historical data to quickly restore the virtual instance.

[0078] In this embodiment of the invention, because the user-associated unbound disk is used to respond to the user's request to use the virtual instance, the system queries whether the user has a reserved unbound disk associated with the local disk pool based on the mapping relationship between the user and the unbound disk to obtain the query result. If the query result is yes, the physical server where the unbound disk is located is located, and it is checked whether there is an idle virtual instance on the server. If there is, an idle virtual instance is allocated to the user on the server, the currently bound disk of the allocated instance is unbound, and the queried user-associated unbound disk is bound to the virtual instance to complete the recovery. Therefore, this technical means overcomes the technical problems of existing local storage and object storage solutions, which require users to fully restore data from object storage when reusing the instance, and network shared storage solutions, which are costly and have poor disk access performance. Thus, in most scenarios, the virtual instance can be quickly restored by simply unbinding and rebinding the disk, while maintaining excellent disk read and write performance by relying on the physical machine's local storage, without relying on high-cost network shared storage. This effectively balances the platform's low-cost storage requirements with the user's experience requirements for quickly using the instance.

[0079] In a preferred embodiment of the present invention, step 3 above may include:

[0080] Step 3.4: If the query result is negative, it is determined that a fast recovery based on the locally unbound disk cannot be executed, triggering the regular recovery process. Specifically, after querying whether the user has associated a locally unbound disk, if the query result is negative, meaning the user does not have an associated unbound disk in the local disk pool, it means that fast recovery cannot be achieved by directly binding the local disk. At this point, the platform's instance scheduling unit will determine the current recovery conditions and clarify that due to the lack of the user-associated locally unbound disk—a crucial resource—the fast recovery process based on the locally unbound disk cannot be executed. To ensure that users can use the cloud phone instance normally, the platform's instance scheduling unit immediately triggers the regular recovery process. This process is based on user data backups in remote object storage, combined with global server resource scheduling, to complete instance recovery as a fallback when the local fast recovery conditions are not met, preventing users from being unable to use the service due to missing local resources.

[0081] Step 3.5: Based on the triggered routine recovery process, select a server with an idle virtual instance from the global server resource pool and allocate one idle virtual instance from the server to the user. Specifically, based on the triggered routine recovery process, the platform first retrieves the real-time status information of the global server resource pool. The resource pool covers all servers within the platform capable of running lightweight cloud phone instances, and each server supports the binding and operation of local storage and virtual instances. The platform's instance scheduling unit filters the servers in the global server resource pool. The filtering criteria are that the server has an idle virtual instance that meets the specifications of a lightweight cloud phone. These specifications need to meet the user's daily office work and short video editing needs, such as having a fixed number of CPU cores, memory capacity, and disk space configuration. After filtering, prioritize servers with lower current load from the qualified servers to ensure the smooth operation of the instance. Then, allocate an idle virtual instance from the server on that server to the current user and record the server identifier, hardware configuration parameters, and currently bound local disk information of the virtual instance to prepare for data recovery operations.

[0082] Step 3.6: Based on an idle virtual instance, retrieve the user's backup data in object storage and restore the backup data to the local disk currently bound to the allocated idle virtual instance. This completes the rapid recovery of the virtual instance. Specifically, the platform's storage management unit retrieves the cloud phone instance disk backup data corresponding to the user in remote object storage based on the user's unique identifier. This backup data is the data that the platform fully backed up to object storage when the user's instance was inactive, including work documents created by the user in the instance, edited short video materials, installed office and editing software, and personalized configuration information. After the backup data is matched, the platform uses a pre-built dedicated data transmission channel to transfer the backup data from the object storage to the local disk currently bound to the idle virtual instance allocated to the user. During the transmission process, the verification information of the transmitted data and the backup data is compared in real time to ensure the integrity of the data transmission and avoid data loss or corruption. Once all backup data has been transferred to the local disk and verified to be correct, the virtual instance loads all the data and configurations previously used by the user. The platform then sends a notification to the user that the instance is ready. After clicking to enter, the user can use the lightweight cloud phone instance with historical data normally and complete the normal recovery of the virtual instance.

[0083] In this embodiment of the invention, when a user's associated local unbound disk cannot be found, it is determined that local fast recovery cannot be performed and a regular recovery process is triggered. Based on this regular process, a server with idle virtual instances is selected from the global server resource pool, and one of these idle virtual instances is allocated to the user. Then, the user's backup data is retrieved from object storage and restored to the local disk currently bound to the allocated idle virtual instance. Therefore, this invention overcomes the technical problems of existing technologies, such as the lack of an effective fallback recovery solution if the local unbound disk is missing, the reliance on a single server leading to recovery failure due to insufficient resources, the chaotic recovery process of local storage and object storage solutions when no local disk is available, and the high cost of network shared storage solutions. This invention achieves the technical effect of ensuring that users can recover instances regardless of whether a local unbound disk exists, improving resource utilization through allocation from the global server resource pool, and balancing storage costs and instance performance in fallback recovery scenarios by leveraging the low-cost advantages of object storage and the high-performance characteristics of local disks. This prevents users from being unable to use instances due to the absence of local disks and ensures the overall user experience.

[0084] In a preferred embodiment of the present invention, step 4 above may include:

[0085] Step 4.1: During platform scheduling, continuously monitor and calculate the ratio between the number of virtual instances allocated to users on each server and the total number of virtual instances N on the server. This ratio serves as the server's virtual instance allocation rate. Specifically, during the daily scheduling of the cloud phone platform, the resource monitoring unit deployed on the platform continuously monitors the virtual instance allocation on each server. First, this unit determines the total number of virtual instances N on each server. This number N is determined through capacity planning when the server joins the platform and corresponds only to standardized, lightweight cloud phone instance specifications that can meet the needs of daily office work and short video editing. For example, the total number of virtual instances N on a certain server is set to 100. Next, the resource monitoring unit will count in real time the number of virtual instances allocated to users on each server, including instances actively used by users and instances allocated to users but temporarily inactive. Subsequently, the resource monitoring unit will calculate the ratio between the number of virtual instances allocated to users on each server and the total number of virtual instances N on that server. This ratio is the server's virtual instance allocation rate. To ensure data real-time performance, the resource monitoring unit will repeatedly perform the above statistical and calculation operations at fixed time intervals, update the virtual instance allocation rate of each server in a timely manner, and synchronize the latest allocation rate data to the platform's instance scheduling unit to provide a basis for subsequent scheduling decisions.

[0086] Step 4.2: Based on the virtual instance allocation rate, determine whether the instance allocation rate exceeds a preset scheduling threshold to obtain a judgment result. Specifically, after receiving the virtual instance allocation rate of each server synchronized by the resource monitoring function unit, the platform's instance scheduling function unit will perform a judgment operation based on the allocation rate. First, the instance scheduling function unit will call the platform's preset scheduling threshold. This threshold is determined by combining the instance reuse requirements of the cloud phone scenario with historical operational data, for example, it is set to 80%. The purpose is to ensure server resource utilization while reserving enough idle instances for the rapid local recovery of historical users. The instance scheduling function unit will compare the real-time virtual instance allocation rate of each server with the preset scheduling threshold one by one. If the virtual instance allocation rate of a server is less than or equal to the preset scheduling threshold, the judgment result is that the threshold has not been exceeded, and the server can still allocate instances according to the regular scheduling rules. If the virtual instance allocation rate of a server is greater than the preset scheduling threshold, the judgment result is that the threshold has been exceeded. The instance scheduling function unit will associate the server's identifier with the corresponding judgment result and send the association information to the platform's scheduling control function unit to trigger the scheduling restriction operation.

[0087] Step 4.3: Based on the judgment result, if the server's allocation rate exceeds the threshold, a scheduling restriction policy is implemented on the server, prohibiting the allocation of idle virtual instances on the server to new users of the platform. After receiving the associated information from the instance scheduling function unit that the server's allocation rate exceeds the threshold, the platform's scheduling control function unit will implement the scheduling restriction policy for that server. First, the scheduling control function unit will update the allocation rules of that server in the platform's scheduling system, explicitly excluding new users of the platform from the instance allocation targets of that server. Here, new users refer to users who register and use the cloud phone platform for the first time and have not previously obtained virtual instances on the platform. When a new user initiates a request to use a lightweight cloud phone instance, the platform's instance scheduling function unit will automatically skip the server with an allocation rate exceeding the threshold when matching available servers, and instead filter and allocate idle instances for the new user from other servers whose virtual instance allocation rates do not exceed the threshold. At the same time, the scheduling control function unit will record the time when the scheduling restriction policy is implemented, the current allocation rate, and the restriction content in the platform's resource management log, which is convenient for subsequent tracking and optimization of the scheduling policy's effect, and to prevent new users from occupying the server's idle instance resources and affecting the local rapid recovery of historical users.

[0088] Step 4.4: By implementing a restriction policy, idle virtual instance resources on the server are reserved. The reserved resources are specifically allocated to historical users who have retained unbound disks locally and reused them, so as to ensure the availability of the local fast recovery path through fast binding operations. Specifically, after implementing a scheduling restriction policy on a server whose allocation rate exceeds the threshold, the remaining idle virtual instance resources on that server will be automatically reserved. The platform's instance scheduling unit specially marks these reserved idle instance resources, indicating that they are reserved for historical users who have retained unbound disks locally and are reusing them. When a user initiates a request to use a cloud phone instance, the instance scheduling unit first checks whether the user is a historical user, and further checks whether the historical user has retained any unbound disks that have not been cleared in the local storage of the server. If the query result is yes, that is, the user is a historical user and has retained unbound disks locally on the server, the instance scheduling unit will prioritize allocating the reserved idle virtual instance on the server to the user. After the allocation is completed, the platform's storage management unit will quickly perform a disk binding operation to bind the unbound disk associated with the user to the allocated idle virtual instance. The entire process does not require data recovery from object storage; instance recovery can be completed solely through disk binding, thereby ensuring the availability of the local fast recovery path and preventing historical users from being forced to use object storage to recover data due to the lack of available idle instances. This solves the problems of long recovery time and poor experience for historical users in the existing solution.

[0089] In this embodiment of the invention, the virtual instance allocation rate is obtained by continuously monitoring and calculating the ratio of the number of virtual instances allocated to users on each server to the total number of virtual instances N on the server during the platform scheduling process. Based on this allocation rate, it is determined whether a preset scheduling threshold is exceeded. If the threshold is exceeded, a scheduling restriction policy is implemented on the server, and idle virtual instance resources on the server are reserved through this restriction policy for priority allocation to historical users who have retained unbound disks locally and are reusing them. Therefore, this invention overcomes the technical problem in the prior art where the lack of differentiated restrictions on server instance allocation leads to new users occupying idle server instance resources, preventing historical users who have retained unbound disks locally from obtaining idle instances on the original server for quick binding and recovery. They are forced to go through the object storage recovery process, which in turn fails to guarantee the availability of the local quick recovery path. This invention achieves the technical effect of prioritizing historical users to quickly bind their local unbound disks with the idle instances reserved on the original server, stably achieving local quick recovery, while avoiding new users occupying critical resources and causing the quick recovery path to fail. It further consolidates the balance between low-cost storage and quick instance reuse while maximizing server resource reuse efficiency, and improves the user experience of historical users.

[0090] like Figure 2 As shown, embodiments of the present invention also provide a cloud instance reuse system based on physical machine local storage and object storage, comprising:

[0091] The acquisition module is used to add servers to the platform and perform capacity planning when servers are added to the platform. It allocates N virtual instances of fixed specifications to the servers and additionally allocates M free disks in the local storage of the servers to reserve storage space for the unbinding operation of virtual instance disks.

[0092] The detection module is used to back up the disk data of the inactive virtual instance to object storage when it detects that the virtual instance on the server meets the inactive condition, based on the reserved storage space; unbind the inactive virtual instance from the local disk and set the local disk as the unbound disk associated with the user; and rebind an idle disk for the inactive virtual instance so that the inactive virtual instance returns to an idle state.

[0093] The unbinding module is used to unbind disks associated with users. When a user requests to use a virtual instance, it checks whether the user has an unbinded disk that is stored on the original server's local storage. If so, and there is an idle virtual instance on the server where the unbinded disk is located, an idle virtual instance is allocated for the user on the server, and the user's associated unbinded disk is bound to the idle virtual instance. Otherwise, an idle virtual instance is allocated for the user from the global server pool, and the user data is restored from object storage to the local disk of the idle virtual instance, completing the virtual instance restoration.

[0094] The processing module is used to set a virtual instance allocation rate threshold based on the virtual instance recovery requirements. When the virtual instance allocation rate on the server exceeds the preset threshold, it prohibits the allocation of virtual instances to users who are using the platform for the first time, so as to keep idle virtual instances on the server to bind the unbound disk associated with the user.

[0095] In the embodiments provided by this invention, a virtual instance reuse method combining server local storage and public backup storage is proposed. Based on Scheme 1, the virtual instance's disk is still stored in the server's local storage, and user data is still stored in object storage. Simultaneously, each server is allocated more local disks than the number of virtual instances on that server. When a user is inactive, in addition to backing up the disk data of the virtual instance the user is currently using from the server's local storage to object storage, the local disk of that virtual instance is unbound from the virtual instance and retained on the server's local storage. The virtual instance is then remounted with an idle local disk or the local disk of another user awaiting recovery. When the user resumes use, if the previously retained local disk is still on the original server, and there are still idle virtual instances on that server, an idle instance is allocated to the user on that server, and the user's retained local disk is mounted to this virtual instance, thus restoring usage. The entire recovery process is simply a disk mounting process. If the previously reserved local disk does not exist, or if the server where the previously reserved local disk is located does not have a free virtual instance, then fall back to Option 1, which allocates a free virtual instance for the user globally and restores the user data from object storage to the local disk of that instance.

[0096] The specific implementation process is as follows:

[0097] Server preparation: When a server is added to the platform, capacity planning is required first. A server can only be allocated one type of virtual instance, such as CPU: 4c, memory: 8g, disk: 64g, network bandwidth: 100Mbps, and the number of virtual instances of this type running is N. In addition to the disks that come with the virtual instances, M unbound disks are stored locally on the server. For example, a server can be allocated 100 4c 8g 64g 100Mbps virtual instances and additionally store 400 64g unbound disks.

[0098] The process for clearing inactive virtual instances involves the following steps: A virtual instance that has been assigned users is marked as inactive after meeting certain conditions. These conditions include: the cloud instance is not on the whitelist; the cloud instance specification is not a high-value specification; or the cloud instance has not been accessed by users for more than a certain time threshold. The platform periodically scans the server and cleans up inactive virtual instances. The cleanup process for inactive cloud mobile instances on a server is as follows: If the number of virtual instances with assigned users on the server exceeds a threshold (e.g., 80%) and there are still virtual instances marked as inactive on the server, all inactive virtual instances are sorted according to the time of the user's last access, and the oldest inactive virtual instance is cleared first.

[0099] The process of clearing an inactive virtual instance involves backing up the virtual instance's disk contents to backup storage, unbinding the virtual instance's disk from the virtual instance, removing the user's binding relationship with the virtual instance, finding a free disk on the server's local disk, binding it to the virtual instance, and marking the virtual instance as free and available for allocation to a new user. If there are no free disks on the server, a disk cleanup process is required. If a user is unbound from the instance, the disk corresponding to that user is skipped. All disks on the server are sorted by the time they were unbound from the instance, from earliest to latest, and each disk is checked individually. If a user associated with a disk is predicted to restart using the instance within a certain period of time, that disk is skipped; otherwise, the disk with the earliest unbound time is cleared first, restoring it to a state without user binding. This process is repeated until a free disk is found on the server. Upon reaching threshold K, the process for restoring inactive cloud phone instances is as follows: After a user logs into the platform, the following steps are executed: The system retrieves the user's virtual instance, checks if the user has an associated virtual instance, and if so, returns that virtual instance to the user. Otherwise, it checks if the user has an associated unbound disk. If so, it checks if there is a free virtual instance on the server where the unbound disk is located. If so, it allocates a virtual instance to the user, unbounds the disk of the virtual instance, binds the user's corresponding disk to the virtual instance, and returns that virtual instance to the user. Otherwise, it checks if the user has an associated disk backup. If so, it allocates a free virtual instance to the user on any server, restores the backup to the disk of that virtual instance, and returns that virtual instance to the user. Otherwise, it allocates a free virtual instance to the user and returns that virtual instance to the user.

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

Claims

1. A cloud instance multiplexing method based on physical machine local storage and object storage, characterized in that, The method comprises: Joining a server to a platform and performing capacity planning when the server joins the platform, allocating N virtual instances of a fixed specification to the server, and additionally allocating M idle disks in the local storage of the server to reserve storage space for virtual instance disk unbinding operations; According to the reserved storage space, when it is detected that a virtual instance on the server meets the inactive condition, backing up the disk data of the inactive virtual instance to an object storage, unbinding the association between the inactive virtual instance and the local disk, and associating the local disk as a user-associated unbound disk; and re-binding an idle disk to the inactive virtual instance to restore the inactive virtual instance to an idle state; Based on the user-associated unbound disk, when a user requests to use a virtual instance, it is checked whether the user is associated with an unbound disk reserved on the local storage of the original server, and if so and the server where the unbound disk is located has an idle virtual instance, an idle virtual instance is allocated to the user on the server, and the user-associated unbound disk is bound to the idle virtual instance; if not, an idle virtual instance is allocated to the user from a global server pool, and user data is restored from the object storage to the local disk of the idle virtual instance, completing the restoration of the virtual instance; According to the virtual instance restoration requirement, a virtual instance allocation rate threshold is set, and when the virtual instance allocation rate on the server exceeds the preset threshold, the virtual instance is prohibited from being allocated to a user who uses the platform for the first time, so that an idle virtual instance is left on the server to bind the user-associated unbound disk.

2. The cloud instance multiplexing method based on physical machine local storage and object storage according to claim 1, characterized in that, Joining a server to a platform and performing capacity planning when the server joins the platform, allocating N virtual instances of a fixed specification to the server, and additionally allocating M idle disks in the local storage of the server to reserve storage space for virtual instance disk unbinding operations, comprising: According to the total capacity of the local storage of the server and the disk specification of a single virtual instance, the maximum number of virtual instances that can be carried by the local storage of the server is determined; Based on the maximum number and in combination with a preset resource reuse strategy, the number N of virtual instances of a fixed specification allocated to the server is calculated and determined, wherein N is less than the maximum number, and the number M of idle disks required to be additionally reserved for supporting unbound disk reservation operations is calculated and determined according to the expected user instance switching frequency of the resource reuse strategy; In the local storage of the server, the disk space required for the determined N virtual instances is allocated, M idle disk storage spaces are additionally divided according to the M value, and an idle disk resource pool is obtained through initialization. 3.The cloud instance multiplexing method based on physical machine local storage and object storage according to claim 2, characterized in that, According to the reserved storage space, when it is detected that a virtual instance on the server meets the inactive condition, backing up the disk data of the inactive virtual instance to an object storage, unbinding the association between the inactive virtual instance and the local disk, and associating the local disk as a user-associated unbound disk, comprising: Monitoring the user access state of each virtual instance in the platform, and when it is detected that a virtual instance on the server has no user access for more than a preset threshold, the virtual instance is determined to be an inactive instance; For the virtual instance determined to be inactive, backup all data in the local disk currently used by the virtual instance to the remote object storage for persistent storage; after the backup operation is completed, based on the backup completion status, perform a disk unbinding operation to remove the binding relationship between the virtual instance and the current local disk, to obtain a local disk separated from the instance; By marking the local disk as an unbound disk unique to the user of the inactive virtual instance, and updating the mapping relationship between the user and the unbound disk in the local storage of the original server where the unbound disk is retained.

4. The cloud instance multiplexing method based on physical machine local storage and object storage according to claim 3, characterized in that, And rebind an idle disk to the inactive virtual instance to restore the inactive virtual instance to an idle state, including: By allocating a new idle disk from the idle disk resource pool of the server to the virtual instance that has completed the disk unbinding operation and binding it, update the state of the virtual instance to an idle state; Based on the idle state, continuously monitor the available number of idle disk resource pool of the server; when it is determined that the number of available idle disks is lower than the preset inventory threshold, trigger the disk cleaning process; Based on the disk cleaning process, evaluate the multiple user-associated unbound disks retained in the local storage of the server, and according to the preset cleaning strategy, select to clear some data on the unbound disks to restore them to idle disks, and recycle the idle disks to the idle disk resource pool; When there are not enough idle disks on the server, based on the multiple user-associated unbound disks retained and the idle disk resource pool, together form a local disk pool serving fast recovery.

5. The cloud instance multiplexing method based on physical machine local storage and object storage according to claim 4, characterized in that, Based on the user-associated unbound disk, when the user requests to use a virtual instance, check whether the user is associated with an unbound disk retained on the local storage of the original server, if yes and the server where the unbound disk is located has an idle virtual instance, allocate an idle virtual instance to the user on the server, and bind the user-associated unbound disk to the idle virtual instance, including: Based on the user-associated unbound disk, respond to the user's request to use a virtual instance, and according to the mapping relationship between the user and the unbound disk, query whether the user is associated with a retained unbound disk in the local disk pool to obtain a query result; If the query result is yes, locate the physical server where the unbound disk is located, and check whether there is a virtual instance with an idle state on the server; If yes, allocate an idle virtual instance to the user on the server, remove the currently bound disk of the allocated instance, and bind the user-associated unbound disk to the virtual instance to complete the fast recovery. 6.The cloud instance multiplexing method based on physical machine local storage and object storage according to claim 5, wherein, If no, allocate an idle virtual instance to the user from the global server pool, and restore the user data from the object storage to the local disk of the idle virtual instance to complete the recovery of the virtual instance, including: When the query result is no, determine that the fast recovery based on the local unbound disk cannot be performed, to trigger the regular recovery process; Based on triggering the regular recovery process, select a server with an idle virtual instance from the global server resource pool, and allocate an idle virtual instance on the server to the user; Based on an idle virtual instance, the backup data of the user in the object storage is obtained, and the backup data is restored to the local disk currently bound to the allocated idle virtual instance, and the quick recovery of the virtual instance is completed.

7. The physical machine local storage and object storage based cloud instance multiplexing method of claim 6, wherein, According to the virtual instance recovery requirement, a virtual instance allocation rate threshold is set, and when the virtual instance allocation rate on the server exceeds the preset threshold, the virtual instance is prohibited from being allocated to the user who uses the platform for the first time, so that an idle virtual instance is left on the server to bind the user-associated unbound disk, including: During platform scheduling, the proportion between the number of virtual instances allocated to users on each server and the total number of virtual instances N on the server is continuously monitored and calculated as the virtual instance allocation rate of the server; Based on the virtual instance allocation rate, it is determined whether the instance allocation rate exceeds the preset scheduling threshold to obtain a determination result; According to the determination result, if the allocation rate of the server exceeds the threshold, a scheduling restriction strategy is executed on the server to prohibit the allocation of idle virtual instances on the server to new users using the platform; By executing the restriction strategy, the idle virtual instance resources on the server are reserved; the reserved resources are exclusively allocated to historical users who have a locally retained unbound disk and are reused, so as to guarantee the availability of the local quick recovery path through the quick binding operation.

8. A cloud instance multiplexing system based on physical machine local storage and object storage, the system implements the method of any one of claims 1 to 7, characterized in that, Including: The acquisition module is configured to add the server to the platform and perform capacity planning when the server is added to the platform, allocate N virtual instances of a fixed specification to the server, and additionally allocate M idle disks in the local storage of the server to reserve storage space for the virtual instance disk unbinding operation; The detection module is configured to, according to the reserved storage space, when it is detected that the virtual instance on the server meets the inactive condition, backup the disk data of the inactive virtual instance to the object storage, unbind the inactive virtual instance from the local disk, and bind the local disk as a user-associated unbound disk; and rebind an idle disk to the inactive virtual instance to restore the idle state of the inactive virtual instance. The unbinding module is configured to, based on the user-associated unbound disk, when a user requests to use a virtual instance, check whether the user is associated with an unbound disk retained on the local storage of the original server, if yes and the server where the unbound disk is located has an idle virtual instance, allocate an idle virtual instance to the user on the server, and bind the user-associated unbound disk to the idle virtual instance; if not, allocate an idle virtual instance to the user from a global server pool, and restore the user data from the object storage to the local disk of the idle virtual instance to complete the recovery of the virtual instance. The processing module is configured to, according to the virtual instance recovery requirement, set a virtual instance allocation rate threshold, and when the virtual instance allocation rate on the server exceeds the preset threshold, prohibit the allocation of virtual instances to users who use the platform for the first time, so that an idle virtual instance is left on the server to bind the user-associated unbound disk.

9. A computing device, comprising: One or more processors; ​ A storage device for storing one or more programs, which when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a program, which when executed by a processor, implements the method of any one of claims 1-7.

Images